Re: input completion system
On Wednesday, 16 May 2012 at 02:27:26 UTC, Katayama Hirofumi MZ wrote: Hi, everyone! Could you make input completion system for D? Hi Katayama Hirofumi, welcome to the D community. I notice that your last two posts have a tone of expectation to them. Now I'm not saying that you are demanding or even expecting people to do things, but asking Could you make input completion system for D? is not helpful. D is a programming language, so something like an input completion system makes no sense. I assume you are talking about an IDE, in which case you want to look at Mono-D or Visual D. Anyway, making these short requests is not considered to be good form, since they add little to the community. Ignoring the irrelevance of the question, there is no place for discussion, no reasoning or explanation, it is a simple yes or no question at best, and an expectant demand at worst. I hope that helps. -- James Miller
Re: Introducing vibe.d!
On Monday, 7 May 2012 at 18:51:26 UTC, Sönke Ludwig wrote: I think one of us (Jan) has something for better form handling locally, not yet committed, and I would count that as something that would still fit well into the core package. But in general, I think the number of features should not grow too much anymore - the core should contain all that is necessary for _most_ applications and that with an interface that is as comfortable as possible. The main scope of modules, I would say, are higher level features, features that are not as widely used or those which provide alternatives to the functions in the core library. Basic, common functionality, however, is always a candidate for the core (OAuth(2) is on the way for example). Another - quite banal - criterion could be if we would actually use a feature ourselves, at least a bit; simply because if we don't use it, we cannot test it without further time investments and it could be unclear (to us) how well such a component actually works (e.g. wrt. stable releases). Also, the implementation/API style of a feature should match the rest of the core library. The MySQL driver would be an example that currently fails both criterions and thus is a module. Maybe it would also be good to establish a defined procedure such as: New features are implemented as modules first and after a review it's decided if they should go in for the next release. I don't have a real opinion on this yet and I'm basically completely open for suggestions. Sound good, now I'm just hoping that porting my forms stuff to the core forms isn't going to be too hard :D. Otherwise it seems you have a rough idea of what constitutes a module and what is a feature, and that is a good start. I think an informal review process for module - feature promotion would be good, since then the code can be available for use earlier. Also, there is something to be said for making official vibe modules, ones maintained, or at least, approved by the vibe team and given slightly more prominence. This can keep the core system small, but still allow the vibe team to provide more functionality, especially if it is common functionality. -- James Miller
Re: Introducing vibe.d!
I'm currently building a site in vibe and love it. There are still a few bugs around, and a few useful features to come, but I've been patching and writing features as I go, so its all good. I am curious about your policy on big features though, I have been working an implementation for using forms simply. Its nowhere near being ready for release yet, but is it the kind of thing you'd want as a module, or as a part of the main vibe codebase? There are also a lot of more producing-friendly features that could be done (IOW, allowing fine-grained configuration of server params, and supporting 8 different load-balancing schemes is great, but doesn't help me produce a website...), would they be mostly modules, or more core parts? -- James Miller
Re: nginx reverse proxy for vibe tutorial
On Sunday, 6 May 2012 at 13:47:27 UTC, David wrote:
Am 06.05.2012 03:00, schrieb James Miller:
On Friday, 4 May 2012 at 11:54:04 UTC, David wrote:
* using `try_files`, nginx complains that you can't use
proxy_pass
inside a named location (like `@vibe`), which means you
can't use
try_files to serve arbitrary static files, hence the massive
list of
extensions.
why not doing:
root /path/to/static
location / {
try_files $uri @app_proxy
}
location @app_proxy {
...
}
I tried that, nginx complained endlessly about it. I'm not
sure why and
I would prefer to use that version.
Also, I need to make an adjustment to my configuration, the
$body_bytes_sent doesn't work the way I thought, so you
actually need to do
server {
...
proxy_set_body $request_body;
...
// Remove proxy_set_header Content-length... line
}
Well this works perfectly for me (not with vibe, with gunicorn)
I thought it should work, and I'm probably missing something, but
here:
nginx: [emerg] proxy_pass cannot have URI part in location
given by regular expression, or inside named location, or inside
if statement, or inside limit_except block in
/etc/nginx/conf/nginx.conf:87
nginx: configuration file /etc/nginx/conf/nginx.conf test failed
Thats what I get at the Checking configuration stage.
For the record, using a named section works perfectly for my php
configuration section, so I'm wondering if its something to with
proxy_pass?
--
James Miller
Re: nginx reverse proxy for vibe tutorial
On Sunday, 6 May 2012 at 22:32:16 UTC, James Miller wrote:
I thought it should work, and I'm probably missing something,
but here:
nginx: [emerg] proxy_pass cannot have URI part in location
given by regular expression, or inside named location, or
inside if statement, or inside limit_except block in
/etc/nginx/conf/nginx.conf:87
nginx: configuration file /etc/nginx/conf/nginx.conf test failed
Thats what I get at the Checking configuration stage.
For the record, using a named section works perfectly for my
php configuration section, so I'm wondering if its something to
with proxy_pass?
--
James Miller
Well a bit of googling reveals this annoying problem:
using `proxy_pass http://localhost:8080/;` is an error, where
using `proxy_pass http://localhost:8080;` is fine.
I think FUU is the most appropriate sentiment here.
For the record: the most recent, working, version of the
configuration is. Its also more flexible and secure, which is
nice.
server {
listen 80;
server_name vibe.mysite.com;
location / {
root /path/to/statics;
try_files $uri @vibe;
}
location @vibe {
proxy_pass http://localhost:8080;
proxy_redirect off;
proxy_pass_request_body on;
proxy_http_version 1.1;
proxy_set_body $request_body;
proxy_set_header Host $host;
proxy_set_header X-Real-IP$remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Re: R suffix for reals
On Sunday, 6 May 2012 at 22:49:13 UTC, bearophile wrote:
R suffix for reals
This is small enhancement suggestion :-) (Issue 8049).
The f suffix turns a number literal without . into a float,
while L requires a . in the number literal, otherwise you
have defined a literal of type long:
void main() {
auto x1 = 1f;
static assert(is(typeof(x1) == float));
auto x2 = 1L;
static assert(is(typeof(x2) == long));
auto x3 = 1.0L;
static assert(is(typeof(x3) == real));
}
D has auto for local inferencing, so this suffix is able to
cause some problems.
So what do you think about introducing a more specific and less
bug-prone suffix like R (eventually using L to denote
longs only):
void main() {
auto x = 1R;
static assert(is(typeof(x) == real));
}
Bye,
bearophile
I agree with this proposal, phasing out 'L' for reals seems like
a good idea, I didn't even know that it was possible until now,
so I imagine it can't be stepping on many people's toes.
--
James Miller
Re: nginx reverse proxy for vibe tutorial
On Sunday, 6 May 2012 at 22:50:56 UTC, David Nadlinger wrote: On Sunday, 6 May 2012 at 22:42:21 UTC, James Miller wrote: I think FUU is the most appropriate sentiment here. Wait till you try using conditional blocks in Lighty's configuration files… [1] David [1] lighttpd supports conditional blocks for a number of predefined variables, including http host, … – but only evaluates the first (or was it: last?) one of a kind, and silently discards the other ones. Especially funny if you use a Debian-style configuration where configuration is split over a number of files (conf-available/conf-enabled directories). I think I remember that from when I was running Lighty, it seemed awesome at first, then quickly became a nightmare to manage. Yeah, I went Apache - Lighttpd - nginx for webservers, nginx is definitely the best so far. Not as many features as Apache, but I find it suitable, and (F)CGI is plenty fast enough using a local socket. -- James Miller
Re: nginx reverse proxy for vibe tutorial
On Friday, 4 May 2012 at 11:54:04 UTC, David wrote:
* using `try_files`, nginx complains that you can't use
proxy_pass
inside a named location (like `@vibe`), which means you can't
use
try_files to serve arbitrary static files, hence the massive
list of
extensions.
why not doing:
root /path/to/static
location / {
try_files $uri @app_proxy
}
location @app_proxy {
...
}
I tried that, nginx complained endlessly about it. I'm not sure
why and I would prefer to use that version.
Also, I need to make an adjustment to my configuration, the
$body_bytes_sent doesn't work the way I thought, so you actually
need to do
server {
...
proxy_set_body $request_body;
...
// Remove proxy_set_header Content-length... line
}
Array type inference
I am using an array of objects, all of which have a common type (They are all sub classes of Field). If I declare an array of these objects, D seems to try to cast them all to the last type in the array, rather than picking a common supertype. This happens even if I specify a type for the array, D still doesn't cast the types properly. In the error message it also seems that it casts _some_ types properly, but others not, resulting in some very strange error messages. I can work around this by casting all of the elements to the common supertype, but this is not ideal. Is this a known bug, expected functionality, or should I file a bug request? -- James Miller
nginx reverse proxy for vibe tutorial
I have spent some time setting up nginx as a reverse proxy for
vibe, and I thought I might share some of my issues here for now,
just in case it helps someone.
I will assume that you are generally familiar with configuring
nginx, where the files are, how server directives work etc.
The basic setup is the same as any other reverse proxy:
server {
listen 80;
server_name dev.mysite.com;
location / {
proxy_pass http://localhost:8080/;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP$remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_set_header Content-Length $body_bytes_sent;
}
}
The important things to note are that you need nginx version
1.1.4 at least. Vibe doesn't seem to work correctly with HTTP 1.0
requests in this configuration. Also, the line `proxy_set_header
Content-Length $body_bytes_sent;` is necessary because vibe
will wait for a body, for some reason when being proxied, this
results in both nginx and vibe waiting for each other, with nginx
eventually timing out. The Content-Length line sets the correct
Content-Length for the request, allowing vibe to skip reading the
body if it needs to.
I also have this section in my server config:
location ~*
^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|woff|eof|ttf)$
{
root /path/to/statics;
}
which means that nginx serves the static files directly, skipping
vibe. This seems like the best setup to me.
Things that should be improved are:
* More security! While this set up isn't actually insecure, I'm
sure something could be done to make it better.
* using `try_files`, nginx complains that you can't use
proxy_pass inside a named location (like `@vibe`), which means
you can't use try_files to serve arbitrary static files, hence
the massive list of extensions.
So far I'm loving vibe.d, it is fast and flexible and just works
(mostly). With nginx serving the static files out the front, the
speed of the setup is incredible.
I hope that people find this helpful.
--
James Miller
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On Thursday, 3 May 2012 at 06:09:31 UTC, Jakob Ovrum wrote: On Thursday, 3 May 2012 at 05:14:43 UTC, James Miller wrote: On Wednesday, 2 May 2012 at 18:26:11 UTC, Jakob Ovrum wrote: This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. I would make a minor change that lets you see the function tree near the top. On my laptop screen (about a standard size) I have to scroll down about an entire screen to see it. How this is implemented is up to you, but being able to collapse to module view might be enough. -- James Miller Packages in the module view are collapsable, just click on them. Having the module list in its entirety collapsable might be an idea, but unless your project has a ton of top-level packages and modules, it won't help much with your specific problem (the situation would be almost the same). I am considering putting the module tree and symbol tree in tabs instead of below each other. Ahh, I missed that, sorry. Nevermind me, carry on, you're awesome. -- James Miller
Re: D3 is potentially damaging
On Wednesday, 2 May 2012 at 01:11:52 UTC, Alex Rønne Petersen wrote: On 02-05-2012 03:08, ixid wrote: The idea of D3 is a worrying one- it suggests a number of things that would not be good for the success and adoption of the language. That the language is experimental and more of a pet project, that D2 has a shelf-life and will be abandoned. I can see D going in two directions: it can gradually grow and progressively gain areas where it's the standard choice or it will be a fairly small community of fans of an eternal language project. Python 2 and 3 has been a very messy split, while languages with a greater sense of continuity do better for it in my view, having one standard version of that language. Breaking changes may be desirable but I don't think labelling that as v2/v3 is a good idea, make it one thing with one suggested version. I agree wholeheartedly. This whole D3 excuse for not fixing design issues in the language is going to hurt us in the long run. What are the aims of D3 that aren't aims of D2? What could be done then that can't be done now? Wouldn't it be better to make breaking changes sooner rather than later? Yes and no. In theory, it's good to stabilize the language now and make a new version of it later which has breaking changes. In practice, that's annoying as hell. We've already seen how slow the transition from D1 to D2 is (not was; it's still happening!). D2 to D3 is going to be even slower (see in particular your Python 2 vs 3 example) simply because more and more people are going to be using D2 and therefore can't afford to port their applications to D3. Honestly I think that the big problem going from D1 - D2 was the issues with Tango. Hell, Tango in general seemed to just cause problems, what with the incompatible runtime and all. D3 would be fine, iff it was easy to port D2 across and easy to continue using D2 code. A big problem with Python2 - Python3 is the fact that it is a nightmare to have both running side-by-side. I don't really think that D3 is a good idea, it would probably be better to gradually deprecate code going forward and replace the broken syntax and non backwards-compatible code. Another useful could be to have a pragma(version, 2) so the compiler compiles with version 2 rules, no porting needed, just a single line near the top. -- James Miller
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On Wednesday, 2 May 2012 at 18:26:11 UTC, Jakob Ovrum wrote: This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. I would make a minor change that lets you see the function tree near the top. On my laptop screen (about a standard size) I have to scroll down about an entire screen to see it. How this is implemented is up to you, but being able to collapse to module view might be enough. -- James Miller
Re: luajit-ffi
Just pitching in as somebody that has worked on a few C bindings, some small some big (current one is XCB, which has the lovely xproto.h file coming to over 15000 lines). Doing automatic conversion of C headers, properly, is difficult, if not impossible. There are all sorts of gotchas and strange things that make trying to write bindings difficult to automate. A lot of APIs rely on the CPP, as part of the API itself. This is an issue because you generally need to replicate those parts of the API in some D way, without completely mangling the original API, generally you want to be able to copy-and-paste C code and have it work as D code. Not all defines can, or should, be converted to enums, even if you distinguish macros and constants. Not all typedefs can be converted to aliases. Different libraries use different ways of typedef'ing their structs and the like. Each library needs a specific touch to make the D bindings as true to the original as possible, and a tool cannot do that well. Manually writing bindings is boring, but also quite medatitive. It is simple enough that you can just shut off, or you can make it a challenge to find the best macro for converting a certain construct in this library. But it is generally not that difficult. The difference between using bindings and FFI is that bindings are compile time and you get all the advantages from that, such as type checking and the like. FFI is all runtime, so you don't get that, unless you do some crazy CTFE magic. -- James Miller
Oddness with C binding
I'm writing bindings to XCB right now, and its mostly going smoothly. However I have encountered a very strange problem. This bit of code segfaults with DMD: auto connection = xcb_connect(null, null); auto setup = xcb_get_setup(connection); auto iter = xcb_setup_roots_iterator(setup); auto screen = iter.data; But it doesn't segfault with LDC2. This is odd to me because as far as I am aware LDC2 uses the same front end at DMD. This must mean that there is a bug in the dmd backend. I thought it could be related to const optimizations, but I removed all the const declarations from the appropriate C bindings and the same thing happened. I don't have the time to create a minimal test case for this, so I can't really file a bug report on it. I was also wondering what could cause this problem. I am using dmd 2.059 and the latest ldc from the arch repositories. -- James Miller
extern and opaque structs
I'm doing C bindings and I have an opaque struct and an extern'd variable of the type of that struct. The problem is that dmd is complaining that the struct has no definition (which is true). Making it a pointer works (expected) but i can't do that because the interface is expecting an full struct. Adding __gshared doesn't help. I assume this is bug, since usage of extern means that I don't need to know the size, since it will be allocated in the C code, not the D code. -- James Miller
Re: More bugs...
On Saturday, 28 April 2012 at 09:36:55 UTC, Timon Gehr wrote:
On 04/28/2012 08:03 AM, Mehrdad wrote:
You expected that to work?
Uhm, why not?
templateclass T
struct F
{
FFT f() { return FFT (); }
};
int main()
{
Fint().f().f().f().f().f(); // etc.
return 0;
}
D templates are analysed eagerly upon instantiation, whereas
C++ templates are analysed lazily. This is not a bug, it is a
feature.
Furthermore, eager analysis is necessary for other D features
like CTFE and compile-time reflection. Honestly, in C++ I would
stay away from code like the above anyway, irrelevant of whether
it compiles, seems too magic-y for my tastes. I don't like
things not being explicit.
--
James Miller
Re: Cairo Deimos bindings
On Friday, 27 April 2012 at 09:50:21 UTC, Dejan Lekic wrote: James Miller wrote: I am currently writing D bindings for Cairo for submission into Deimos, could somebody please make the repository so I can fork it? Thanks -- James Miller Is it a binding, or a wrapper? It is a binding. There are some very minor cosmetic changes that will be detailed, but otherwise you can just copy-paste a C example into D, make it D-compatible and it will work as intended. -- James Miller
Re: Cairo Deimos bindings
On Friday, 27 April 2012 at 20:49:54 UTC, Andrej Mitrovic wrote: On 4/27/12, Marco Leise marco.le...@gmx.de wrote: In C: STATUS_SUCCESS In D unmodified: cairo_status_t.STATUS_SUCCESS In D with cosmetic changes: cairo_status_t.SUCCESS cairo_status_t.SUCCESS is like going halfway there but stopping. It looks rather ugly imo. I think you either want the existing C names, or names that *fully* fit the D coding style. So maybe the choice should be between this: cairo_status_t.STATUS_SUCCESS and this: CairoStatus.Success I'm going for the second one, due mostly to the fact that if I'm going to change the enum to fit in with D, I might make it fit in with D style-wise. The difference in style should help to make it obvious to spot. Also, most functions would get covered by a wrapper, but there is little use to wrapping enums, so it is worthwhile making it nice to work with in normal D code. -- James Miller
Re: More bugs...
On Saturday, 28 April 2012 at 04:45:59 UTC, Mehrdad wrote:
Okay, final exams are coming up again, and so are my bugs (I
have no idea what the correlation is, don't ask...)
I guess I should post this on bugzilla, but oh well... I
continued the thread instead.
Try compiling this (I did this on Windows, DMD 2.059):
void main() { Foo!(int[])([[1], [2]]); }
struct Foo(T) { auto foo() { Foo!(T[]) t; return t; } }
You expected that to work? Extra extra, infinite recursion is
infinite! You are asking the compiler to instantiate Foo with the
type int[], then use that type to instantiate Foo with int[][],
which then instantiates Foo with type int[][][].
Try thinking about your code before mouthing off here. Would you
fault C for causing a stack overflow in this case:
int rec(int a){
return rec(a + 1);
}
I mean what did you expect, that the compiler could magically
create infinite types? I can't even see where you might have gone
wrong here, since the code is so simple. What I can see is that
the constructor wouldn't work because there are no fields. I can
see that you have some very strange ideas about templates, Foo(T)
instantiates Foo(T[]), which is a different type, so it goes
through and instantiates Foo(T[][]) which is, again, a different
type.
Think before declaring D to have bugs.
--
James Miller
Cairo Deimos bindings
I am currently writing D bindings for Cairo for submission into Deimos, could somebody please make the repository so I can fork it? Thanks -- James Miller
Cross module version specs
I'm trying to write a binding that has conditional sections where some features have to be enabled. I am using version statements for this. I have a list of version specs in a module by themselves. When I try to compile another module that imports this module, it acts as if the version was never specified. I have tried wrapping the specs inside a version block, then setting that from the command but that doesn't work. Setting the version manually works as expected. I have also tried including the versions file on the command line. All I can think is that version specifiers aren't carried across modules, which pretty much makes them completely useless unless you only use the built-in versions. -- James Miller
Re: Cross module version specs
On Thursday, 26 April 2012 at 10:20:37 UTC, Jonathan M Davis wrote: On Thursday, April 26, 2012 12:09:19 James Miller wrote: which pretty much makes them completely useless unless you only use the built-in versions. That's not true at all. It just means that versions are either useful for something within a module or they're intended for your program as a whole and passed on the command line (e.g. StdDdoc is used by Phobos, and it's not standard at all; the makefile adds it to the list of compiler flags). But yes, it's true that if you want to define a version in one module which affects another, you can't do it. Is there any reason for that limitation? Seems like an arbitrary limit to me. The library I am binding to uses ifdefs to let the compiler see the appropriate declarations in the header files. It would be nice in general for D to be able to mimic that capability, as it means you can have a configuration file with a list of specs that can be generated at build-time by something like autoconf. -- James Miller
Re: Cairo Deimos bindings
On Thursday, 26 April 2012 at 18:20:01 UTC, David Nadlinger wrote: On Thursday, 26 April 2012 at 18:15:49 UTC, Andrej Mitrovic wrote: Is there really a need to write it manually? All I had to do to use the C library directly is call HTOD on the headers. Otherwise I use CairoD. I'd say that usable htod generated headers still are a welcome addition to Deimos. David On top of that htod doesn't work on linux AFAIK. Also there are alot of header files missing from that, probably due to people not realising that not all installations install all the headers. I have the headers for the following surfaces: beos, cogl, directfb, drm, gl, os2, pdf, ps, qt, quartz, quartz-image, script, skia, svg, tee, vg, wind32, xcb, xlib and xml. There are also the extra headers like the core cairo, gobject support, hardware-specific definitions and so on. I am also slightly altering some of the code (in a well-documented manner) to reflect the difference between the usage of similar constructs in C. So, un-namespacing enums because you access the values as TypeName.Member, rather than just Member, as in C. Also replacing ifdef blocks with conditional compilation so I can replicate, in D, similar error messages to the C headers. There is alot that is difficult to do with automated tools, and it would be nice if this was properly complete, I plan on actually writing a proper install for this so your installed D bindings reflect the available C functions. -- James Miller
Re: Cross module version specs
On Thursday, 26 April 2012 at 12:37:44 UTC, Steven Schveighoffer wrote: On Thu, 26 Apr 2012 06:32:58 -0400, James Miller ja...@aatch.net wrote: On Thursday, 26 April 2012 at 10:20:37 UTC, Jonathan M Davis wrote: On Thursday, April 26, 2012 12:09:19 James Miller wrote: which pretty much makes them completely useless unless you only use the built-in versions. That's not true at all. It just means that versions are either useful for something within a module or they're intended for your program as a whole and passed on the command line (e.g. StdDdoc is used by Phobos, and it's not standard at all; the makefile adds it to the list of compiler flags). But yes, it's true that if you want to define a version in one module which affects another, you can't do it. Is there any reason for that limitation? Seems like an arbitrary limit to me. The library I am binding to uses ifdefs to let the compiler see the appropriate declarations in the header files. It would be nice in general for D to be able to mimic that capability, as it means you can have a configuration file with a list of specs that can be generated at build-time by something like autoconf. No, it would not be nice, it would be horrible. C's preprocessor is one of the main reasons I sought out something like D. The fact that you can include files in a different order and get a completely different result is not conducive to understanding code or keeping code sane. The correct thing to use for something like this is enums and static ifs. They work because enums are fully qualified within the module they are defined, and you can't define and use the same unqualified enums in multiple places. [snip] These kinds of decoupled effects are what kills me when I ever read a heavily #ifdef'd header file. versions should be defined for the *entire program*, not just for certain files. And if they are defined just for certain files, define them in the file itself. -Steve I didn't think about it like that, thanks. I'm planning on just using enums and static ifs in this case now, since it certainly makes more sense and I can achieve the same effect. Thanks all -- James Miller
Re: Cairo Deimos bindings
On Thursday, 26 April 2012 at 22:45:01 UTC, Trass3r wrote:
I'd say that usable htod generated headers still are a welcome
addition to Deimos.
David
Even using some regex's is better than htod. It drops const,
removes or messes up the comments etc.
There are also many things that should be changed in a binding to
make it more D compatible, without affecting the C binding. Many
C libraries define their own bool type, but D has a bool type
that can be used just as easily, also making it easier to write D
using native types.
Lots of C code has extraneous typedefs that are only there to
strip out struct and union keywords, so they can be rewritten.
enums cause issues because the C enum:
enum Status {
STATUS_SUCCESS
}
has type enum Status and the members are access like
STATUS_SUCCESS. The same enum in D is
enum Status {
STATUS_SUCCESS
}
has type Status and the members are accessed using
Status.STATUS_SUCCESS, which can be very bloated when converting
heavily-namespaced code into D, because accessing the member
CAIRO_STATUS_NO_MEMORY from the enum cario_status_t is fine in C,
and neccessary because of the lack of modules, but the same in D
is cario_status_t.CAIRO_STATUS_NO_MEMORY, which is very verbose.
Consider that this is one of the shorter enums in cairo, then it
becomes a problem.
Sometimes code will rely on specific, extra, headers to determine
what to do, further complicating bindings, especially when you
need to check for certain functionality.
htod is not a useful tool, especially if you want to do any sort
of cross-platform, robust binding, manual binding is really the
only way to do it properly and properly reflect the original
binding and api of the library.
It doesn't take that long, I did the binding for the 3000 line
cairo.h file in about 3 hours, through judicious use of regex
replaces and macros (I love Vim).
--
James Miller
Re: Cairo Deimos bindings
On Thursday, 26 April 2012 at 23:28:19 UTC, Trass3r wrote:
enums cause issues because the C enum:
enum Status {
STATUS_SUCCESS
}
has type enum Status and the members are access like
STATUS_SUCCESS. The same enum in D is
enum Status {
STATUS_SUCCESS
}
has type Status and the members are accessed using
Status.STATUS_SUCCESS
//! bring named enum members into current scope
string flattenNamedEnum(EnumType)()
if (is (EnumType == enum))
{
string s = ;
foreach (i, e; __traits(allMembers, EnumType))
{
s ~= alias ~ EnumType.stringof ~ . ~
__traits(allMembers, EnumType)[i] ~ ~ __traits(allMembers,
EnumType)[i] ~ ;\n;
}
return s;
}
I proposed 'extern(C) enum' to get rid of all those manual
aliases but as always nothing happened.
Exactly.
I like that, its cool, but I figured just doing a minor rewrite
of the enum would suffice. Its not that hard since Vim has a
block select, and cairo has some pretty consistent naming that
makes doing macros easy for them, the last step is just to check
that everything gets renamed properly.
--
James Miller
Re: ^^ limitation
On Friday, 27 April 2012 at 00:56:13 UTC, Tryo[17] wrote: D provides an auto type facility that determins which the type that can best accommodate a particular value. What prevents the from determining that the only type that can accommodate that value is a BigInt? The same way it decides between int, long, ulong, etc. Because the compiler doesn't know how to make a BigInt, BigInt is part of the library, not the language. Why couldn't to!string be overloaded to take a BigInt? It is, its the same overload that takes other objects. The point is this, currently 2^^31 will produce a negative long value on my system. Not that the value is wrong, the variable simply cannot support the magnitude of the result for this calculation so it wraps around and produces a negative value. However, 2^^n for n=32 produces a value of 0. Why not produce the value and let the user choose what to put it into? Why not make the he language BigInt aware? What is the negative effect of taking BigInt out of the library and make it an official part of the language? Because this is a native language. The idea is to be close to the hardware, and that means fixed-sized integers, fixed-sized floats and having to live with that. Making BigInt part of the language opens up the door for a whole host of other things to become part of the language. While we're at it, why don't we make matrices part of the language, and regexes, and we might aswell move all that datetime stuff into the language too. Oh and I would love to see all the signals stuff in there too. The reason we don't put everything in the language is because the more you put into the language, the harder it is to move. There are more than enough bugs in D right now, and adding more features into the language means a higher burden for core development. There is a trend of trying to move away from tight integration into the compiler, and by extension the language. Associative arrays are being worked on to make most of the work be done in object.d, with the end result being the compiler only has to convert T[U] into AA(T, U) and do a similar conversion for aa literals. This means that there is no extra fancy work for the compiler to do to support AA's Also, D is designed for efficiency, if I don't want a BigInt, and all of the extra memory that comes with, then I would rather have an error. I don't want what /should/ be a fast system to slow down because I accidentally type 1 33 instead of 1 23, I want an error of some sort. The real solution here isn't to just blindly allow arbitrary features to be in the language as it were, but to make it easier to integrate library solutions so they feel like part of the language. -- James Miller
Re: Cairo Deimos bindings
On Friday, 27 April 2012 at 01:45:20 UTC, Walter Bright wrote: On 4/26/2012 1:28 AM, James Miller wrote: I am currently writing D bindings for Cairo for submission into Deimos, could somebody please make the repository so I can fork it? I need: library file name cairo (that is it) description Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output. Experimental backends include OpenGL, BeOS, OS/2, and DirectFB. Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (eg. through the X Render Extension). (From the web page) home page url for the library http://www.cairographics.org/
Notice/Warning on narrowStrings .length
I'm writing an introduction/tutorial to using strings in D, paying particular attention to the complexities of UTF-8 and 16. I realised that when you want the number of characters, you normally actually want to use walkLength, not length. Is is reasonable for the compiler to pick this up during semantic analysis and point out this situation? It's just a thought because a lot of the time, using length will get the right answer, but for the wrong reasons, resulting in lurking bugs. You can always cast to immutable(ubyte)[] or immutable(short)[] if you want to work with the actual bytes anyway.
Re: Notice/Warning on narrowStrings .length
On Monday, 23 April 2012 at 23:52:41 UTC, bearophile wrote: James Miller: I realised that when you want the number of characters, you normally actually want to use walkLength, not length. As with strlen() in C, unfortunately the result of walkLength(somestring) is computed every time you call it... because it's doesn't get cached. A partial improvement for this situation is to assure walkLength(somestring) to be strongly pure, and to assure the D compiler is able to move this invariant pure computation out of loops. Is is reasonable for the compiler to pick this up during semantic analysis and point out this situation? This is not easy to do, because sometimes you want to know the number of code points, and sometimes of code units. I remember even a proposal to rename the length field to another name for narrow strings, to avoid such bugs. I was thinking about that. This is quite a vague suggestion, more just throwing the idea out there and seeing what people think. I am aware of the issue of walkLength being computed every time, rather than being a constant lookup. One option would be to make it only a warning in @safe code, so worst case scenario is that you mark the function as @trusted. I feel this fits in with the idea of @safe quite well, since you have to explicitly tell the compiler that you know what you're doing. Another option would be to have some sort of general lint tool that picks up on these kinds of potential errors, though that is a lot bigger scope... -- James Miller
Re: Is the use of .di depreceated ?
On Tuesday, 24 April 2012 at 01:51:54 UTC, Adam Wilson wrote: Where DI files come in handy is for commercial libraries that don't want to hand out their source, without DI's that's impossible, therefore for D to be a commercially acceptable language, DI's must work, unfortunately, DI's do not auto-generate to the this requirement right now, I have a patch to fix that. But if you are OSS, you don't really care, just deliver the source as the library. DI files are sufficiently auto generated now. Templated functions have to be part of the source code because, well, *they're templates* the compiler needs the source code. Otherwise .di files are just .d files with a different name, you can do forward declarations for defining the interface with a library, I've used it several times. There is a build tool that will generate the interface files and use those when actually compiling in order to speed up compilation times when doing incremental compilation (don't have to parse as much code). -- James Miller
Re: Foreach Closures?
* Jacob Carlborg d...@me.com [2012-04-13 08:40:39 +0200]: On 2012-04-13 06:50, Matt Peterson wrote: I agree with that, nothing will quite be the same as a full compiler-as-a-library (CAAL?). But in the meantime, there is a working compiler now, and isn't it better to get some kind of IDE-like functionality sooner rather than waiting for a long time with nothing? When you say there is a working compiler now, which on is you referring to. DMD, LDC, GDC, SDC or any other? As far as I know neither DMD, LDC or GDC is usable as a library. I have no experience of SDC and don't know in what state it is. But I guess we would have to do some investigation and figure out what the best to do this would be. BTW, there are already IDE's with some kind of frontends available. MonoD, VisualD, Descent (now old) and possibly others. I think he means that while there isn't a suitable CaaL, there are working compilers that can be improved to supply enough information to atleast start on IDE integration, even if it isn't as robust or efficient as an actual library. From what I can tell, LDC would probably be the best for the kind of code analysis an IDE would need, since it is has an LLVM backend. SDC would be good too, but SDC is probably the best one to try to move towards adding this functionality. -- James Miller
Re: Precise GC
On 2012-04-13 16:54:28 +0300 Manu turkey...@gmail.com wrote: While I'm at it. 'final:' and 'virtual' keyword please ;) Hmmm, I thought we decided that was a good idea, anybody in the know if this going to happen or not? -- James Miller
Re: FormatSpec struct
* Paul D. Anderson paul.d.removethis.ander...@comcast.andthis.net [2012-04-13 07:50:31 +0200]: I'm trying to add formatted output to my decimal arithmetic module. Decimals should format like floating point, using 'E', 'F' and 'G', etc. I would expect a format string like %9.6e to parse as width = 9, precision = 6, using exponential notation. In std.format there is a FormatSpec struct that looks as if it will do the parsing for me. As far as I can tell the usage is: auto spec = std.format.FormatSpec!char(9.6e); writeln(fmtspec = , fmtspec); But it doesn't do what I think it should do. The output of the method is: fmtspec = address = 1637116 width = 0 precision = 2147483646 spec = s indexStart = 0 indexEnd = 0 flDash = false flZero = false flSpace = false flPlus = false flHash = false nested = trailing = 9.6e The width field should be 9, the precision field should be 6, and the spec field should be 'e'. Instead it seems to disregard the input string and return a default FormatSpec, with only the 'trailing' field populated, containing the input. What am I missing here? I've tried variations -- %9.6e, s, %s, etc, but the input is always relegated to the trailing field. Paul Hey Paul, so some investigation has led me to believe that FormatSpec is really just for internal usage. The documentation is a bit misleading (to the point of being possibly completely false). FormatSpec, AFAICT, is essentially just a parser for the standard format specifier, but its not very clear as to proper usage. I'm going to try to improve it and submit a pull request, until then looking at the source code for std.format should give you some idea of how to best use it. -- James Miller
Re: FormatSpec struct
* James Miller ja...@aatch.net [2012-04-13 19:16:48 +1200]: * Paul D. Anderson paul.d.removethis.ander...@comcast.andthis.net [2012-04-13 07:50:31 +0200]: I'm trying to add formatted output to my decimal arithmetic module. Decimals should format like floating point, using 'E', 'F' and 'G', etc. I would expect a format string like %9.6e to parse as width = 9, precision = 6, using exponential notation. Hey Paul, so some investigation has led me to believe that FormatSpec is really just for internal usage. The documentation is a bit misleading (to the point of being possibly completely false). FormatSpec, AFAICT, is essentially just a parser for the standard format specifier, but its not very clear as to proper usage. I'm going to try to improve it and submit a pull request, until then looking at the source code for std.format should give you some idea of how to best use it. -- James Miller So I made the pull request, the documentation you need to read is here: https://github.com/Aatch/phobos/commit/cda3c079ee32d98a017f88949c10097840baa075 Hopefully it helps. -- James Miller
Re: Is anyone hacking on druntime in a widespread fashion atthemoment?
* H. S. Teoh hst...@quickfur.ath.cx [2012-04-11 22:28:32 -0700]: On Thu, Apr 12, 2012 at 12:59:06AM -0400, Nick Sabalausky wrote: James Miller ja...@aatch.net wrote in message news:mailman.1640.1334189880.4860.digitalmar...@puremagic.com... I don't trust computers, I've spent too long programming to think that they can get anything right. Quote of the year, right there. while(true) vote++; I need that on a T-Shirt, or tattooed somewhere, or something. [...] I'm stealing that quote for my quotes file. :-) I am honored sir. -- James Miller
Re: The Downfall of Imperative Programming
* Russel Winder rus...@winder.org.uk [2012-04-10 21:02:03 +0100]: On Tue, 2012-04-10 at 21:22 +0200, Gour wrote: [...] In any case, as it is often said, I got a feeling that despite its potential cleanliness, the real-world Haskell code was not so readable. That probably comes down to familiarity and personal taste. By deploying some coding discipline, we tend to believe that D can serve well as FP-language for the masses. :-) Hummm... the really core issue is whether the language supports tail call optimization. Functional programming languages demand it, C, C++, Java, Go, Python definitely don't have it, D... I used Haskell a bit a while back, and while I enjoyed using it, and was quite capable of writing in proper functional style, I found reasoning about the programs tedious and difficult. Due to the nature of Everything is a function (mostly), you end up with an incredible amount of functions for the simplest tasks. And some of the most common tasks in real-world programming, string processing and IO, are significantly more difficult in Haskell. Monads aren't a problem, the discussion of monads, by functional programmers is a problem. The moment some snobby functional programmer comes along and starts talking about category theory and some esoteric aspect of Type Algebra generalized of some field of Assholery, most people's brains turn off. It gets worse when you go: How does this help read from a file and they give you a long stare and start all over again, I just want to know how to read from a goddamn file! I wish I could love Haskell, and for pure computer science, it's fine, amazing even, but for real-world programming, it just doesn't cut it. The concepts are too difficult and not explained well enough, code rapidly becomes unreadable unless you maintain super-human discipline and broken code is difficult to fix. Case in point is darcs, which is a perfect application of real-word usage, and the GHC developers are complaining of it being unstable, bloated and impossible to fix, so they are moving to git (written in C no less). -- James Miller
Re: The Downfall of Imperative Programming
* bearophile bearophileh...@lycos.com [2012-04-12 15:14:37 +0200]: James Miller: I wish I could love Haskell, and for pure computer science, it's fine, amazing even, but for real-world programming, it just doesn't cut it. Haskell contains some ideas worth copying even in non-functional languages (or in mixed languages as D). Enforced purity and immutability, lazy immutable lists, pattern matching, tuples and their various unpacking syntax, list comprehension, structural algebraic types, built-in currying and partial application, and so on, are handy and allow to express certain computing idioms in a succinct and clear way (and not every part of a program needs the same runtime efficiency). Scala language shows that you can put several of those things in a language that supports mutability too. Bye, bearophile I like Scala, didn't really get it when I first looked at it, but that was a while ago, and I have learned Haskell since then, so I might give it another look. As I said, Haskell is a fine language, and the features are very useful. My favorites are: partial function application, currying, list comprehension and lazy lists. There are others, but these are things that I miss the most from my time using Haskell -- James Miller
Re: Measuring the page generation of the forum
* Somedude lovelyd...@mailmetrash.com [2012-04-13 04:25:19 +0200]: Well, it's not really urgent. It's fast enough. Still, collecting statistics over time would have been nice, so that one could analyse the general behaviour of the GC, for instance, by getting an idea of the standard deviation and maximum response time over weeks of use. I guess since it can handle much larger loads, the forum server is not stressed enough to give very meaningful insight under heavy load. But I have experienced a response of several seconds once, I don't know where this comes from (although it's most likely one of your reasons). So collecting real time data would have to be done for each component of the chain (SQLite, cache, D generated page). Such data would be useful for any web server anyway. I doubt that the GC is the source of any real problems. As a web developer (in PHP no less :S) I can say with authority that most slow downs are due to waiting on external services and data processing. Some of the slowest parts of our site are due to heavy database usage where we have to perform over 100 SQL queries to generate a page. Other slowdowns are caused by the need to process the data. I understand that you want to see how the GC affects the server performance, but it will be so small that it will be lost in the noise, a blip in traffic because it's lunchtime and people are watching youtube in your area will cause a bigger delay than the GC kicking in. -- James Miller
Re: Passing function as values and returning functions
* Xan xancor...@gmail.com [2012-04-11 20:28:38 +0200]: On Wednesday, 11 April 2012 at 13:04:01 UTC, Steven Schveighoffer wrote: On Wed, 11 Apr 2012 08:53:00 -0400, Xan xancor...@gmail.com wrote: [snip] writeln(g(f)(1)); Unlike C, you *must* take the address of a function symbol to get a function pointer. -Steve Yes, it works, finally. Thanks, Steve. Xan. Glad you got help Xan, but for future reference can you please keep questions to D.learn? It is somewhat frustrating to see the question How do I do that? on this list, since it is for discussion, and high-level questions, not for people that are learning D. (High level questions being along the lines of What changes need to be made in dmd to support the new AA implementation?) -- James Miller
Re: Passing function as values and returning functions
* James Miller ja...@aatch.net [2012-04-13 02:49:03 +1200]: Glad you got help Xan, but for future reference can you please keep questions to D.learn? It is somewhat frustrating to see the question How do I do that? on this list, since it is for discussion, and high-level questions, not for people that are learning D. (High level questions being along the lines of What changes need to be made in dmd to support the new AA implementation?) And now I look like an asshole because I wasn't paying attention to the mailbox I was in. Ignore me, I'm an idiot... -- James Miller
Re: Sampling algorithms for D
* Joseph Rushton Wakeling joseph.wakel...@webdrake.net [2012-04-12 16:45:34 +0200]: (3) Uniform random number on (0,1) The algorithms' specification explicitly refers to uniform random numbers on the open interval, which I take to mean (0,1) i.e. excluding zero. Phobos currently provides only a half-open uniform distribution on [a,b). I've implemented a simple uniform_open() function which should return a uniform distribution on (a,b). The question is, are there any plans for an open-interval uniform distribution in Phobos? Can I rely on this functionality being provided in the long term in D's standard library? There is support for fully all 4 types of intervals using std.random.uniform. You just specify the type of interval using a template parameter. The default is this: uniform!([))(a,b); And you want this: uniform!([])(a,b); You can also do () and (] to obtain the other two intervals -- James Miller
Re: Is anyone hacking on druntime in a widespread fashion at themoment?
* Nick Sabalausky seewebsitetocontac...@semitwist.com [2012-04-11 16:08:05 -0400]: Kevin Cox kevincox...@gmail.com wrote in message news:mailman.1599.1334099575.4860.digitalmar...@puremagic.com... I was wondering why they could not be implied from the code itself. That question comes up a lot. The thing is, that would completely defeat the point. The point is that you want the compiler to *guarantee* that certain specific functions are pure/@safe/const/nothrow, etc. If you make a change that prevents a function from being pure/@safe/const/nothrow, and the compiler just simply accepted it and internally considered it non-pure/non-whatever, then you haven't gained anything at all. It'd be no different from not even having any pure/@safe/const/nothrow system in the first place. At *best* it would just be a few optimizations here and there. But if the compiler tells you, Hey, you said you wanted this function to be pure/whatever, but you're doing X which prevents that, then you can actually *fix* the problem and go make it pure/whatever. At any rate, inference would probably end up being more trouble than its worth, or as you said, useless. Me: I know this function can throw Compiler: But I don't think so, so I'm gonna mark it nothrow Me: No! You idiot! Compiler: Herp-Derp, code-breaking optimization based on incorrect assumptions Me: FUU I don't trust computers, I've spent too long programming to think that they can get anything right. -- James Miller
Re: Multiple %s format specifiers with a single argument
* Mike Parker aldac...@gmail.com [2012-04-10 18:46:42 +0900]: On 4/10/2012 3:43 AM, Ali Çehreli wrote: On 04/09/2012 10:35 AM, Andrej Mitrovic wrote: On 4/9/12, Jonathan M Davisjmdavisp...@gmx.com wrote: Posix positional arguments seem to work for writefln but not format for whatever reason. Report it as a bug. Thanks, http://d.puremagic.com/issues/show_bug.cgi?id=7877 Thanks. I hadn't seen this branch of the thread before sending my response. Some newsgroup software break threads into multiple branches. Could be my Thunderbird... (?) Ali It's not Thunderbird. IIRC it's an issue with some users posting via the email interface. Its less using the email interface, and more people using braindead email clients. Gmail and Mutt (the two I use most) seem to handle replying well, setting the correct headers to indicate things. But I've seen some odd postings from people posting using things like Windows Live Mail. And it seems that Outlook Express is better at mailing lists than Outlook, which is strange... -- James Miller
Re: The Downfall of Imperative Programming
* Marco Leise marco.le...@gmx.de [2012-04-10 05:57:52 +0200]: Am Tue, 10 Apr 2012 12:50:32 +1200 schrieb James Miller ja...@aatch.net: Slightly OT: With the unstoppable march of parallel programming, does anybody else find node.js incredibly infuriating, since it is single-core. Don't blame the library. EcmaScript was designed to be single-core. I imagine that web scripting language to be much more complex with multi-threading in user code. You are using the wrong tool for the job ;) -- Marco I meant that the fact that node.js is gaining popularity, despite the fact that we want to move away from single-threaded applications, is incredibly backwards. I'm not using node, I have to use PHP at work, which at the very least gets help from the webserver in terms of parallel processing. -- James Miller
Re: The Downfall of Imperative Programming
* Sean Cavanaugh worksonmymach...@gmail.com [2012-04-09 16:09:03 -0500]: On 4/9/2012 3:28 PM, Mirko Pilger wrote: i guess this might be of interest to some. http://fpcomplete.com/the-downfall-of-imperative-programming/ http://www.reddit.com/r/programming/comments/s112h/the_downfall_of_imperative_programming_functional/ I would counter a flow based programming approach solves a lot of the same concurrency problems and doesn't tie you to a programming style for the actual code (functional vs declarative) as each module can be made to do whatever it wants or needs to do. On top of that, while functional languages are cool, they tend to fall down when you have to write more complex programs. I've seen Haskell code that it incredibly verbose, simply because of it functional nature. Pure functional is great, until you need a usable program, because eventually you will want IO, and IO is unpure, you cannot predict it. The better way is to have more of a sandbox model. IO and the like are managed by a single thread (per object, so per file etc), that recieves commands (I don't care how) to do things. Everything else is written however you want, functional, imperative, declarative, whatever. You then make all memory thread-local, no global memory at all, except through a specific, controlled system that carefully controls access. Ideally this system would only be used to pass around very large data structures between threads. This way, you get the advantages of pure functional, but don't miss the advantages of mutable variables and being able to write in the imperative style. Slightly OT: With the unstoppable march of parallel programming, does anybody else find node.js incredibly infuriating, since it is single-core. -- James Miller
Re: Operator Overloading with class template
* Eyyub eyyub.pangeara...@gmail.com [2012-04-09 01:14:32 +0200]:
Hello,
How can I rewrite the exemple 2 (http://pastebin.com/q50903Zh) in D
lang. ?
This source code doesn't work...why ?
http://paste.pocoo.org/show/wy1kDIpqTi2ApRuOxRRb/
Thx. :)
What you want is something like this:
class Value(int M, int K, int S)
{
private
{
float _value;
}
public
{
this(float val)
{
_value = val;
}
auto opBinary(string op : /, int MO, int KO, int SO)(Value(MO,
KO, SO) other) {
return new Value!(M-MO, K-KO, S-SO)(_value/other.value);
}
}
}
A Few notes:
1. This isn't tested, might not work, but thats where you should aim...
2. Operator overloading is implemented as a lowering (as far as I'm aware) the
compiler emits a template instantiation of opBinary(/) for the type. That
means that you can add on more template arguments.
3. Using `auto` means that the compiler works out the type, so you don't have
to add extra template arguments to calculate the correct type.
Hope that helps.
--
James Miller
Re: UFCS for D
On 3 April 2012 19:58, Rory McGuire rjmcgu...@gmail.com wrote: Andrei and Walter's proposal does not break existing code because it makes folders into modules. Completely off topic, but can you please refrain from top-posting? Its not a big deal, just generally quoting above you is preferred. Because it breaks the natural flow of conversation Why shouldn't you top-post? -- James Miller
Re: Nested functions should be exempt from sequential visibility rules
Sorry, I didn't mean this to go into D.announce. Reposting in the proper place... Can this one be deleted? Off Topic: In Gmail, it applied both labels to the one email, which is cool :D. Otherwise I think that the C-like workaround should be ok, the issue is with closures, what values should be visible to the closures? -- James Miller
Re: making args global
On 4 April 2012 10:32, jicman cabr...@wrc.xerox.com wrote: How can I make args global? thanks, In D, technically the only way is to use Runtime, as Andrej mentioned. As an aside, it is worth noting there is no global scope in D, module is as high as you go.
Re: Add Element to list not Working
On 2 April 2012 17:45, Chris Pons cmp...@gmail.com wrote: I'm trying to add an element to a list with insert but that doesn't seem to do anything at all. If I try using ~= it says that Error: cannot append type Node to type SList!(Node). I'm pretty confused about using ~= because it works fine for arrays but apperantly not for lists. How do I add an element to a list? opAppend (or whatever it is) isn't defined for alot of types that it probably should be. There should be an append method that you can use though. -- James Miller
Re: Equivalents to policy classes in D
On 3 April 2012 12:24, Cristi Cobzarenco cristi.cobzare...@gmail.com wrote:
Mixins templates would be the answer:
import std.exception;
mixin template UncheckedIndices( T ) {
ref T opIndex( int i ) {
return this.get_( i );
}
}
mixin template CheckedIndices( T ) {
ref T opIndex( int i ) {
enforce( i 0 i this.size );
return this.get_( i );
}
}
struct Array( T, alias IndexPolicy ) {
private T* array;
private int size_;
this( size_t n ) {
array = (new T[ n ]).ptr;
}
@property size_t size() {
return size_;
}
private ref T get_( size_t i ) {
return array[ i ];
}
mixin IndexPolicy!T;
}
void main() {
auto arr1 = Array!(int, UncheckedIndices)( 10 );
auto arr2 = Array!(int, CheckedIndices)( 10 );
arr2[ 11 ] = 5;
}
Another option is to use alias this to forward method calls on.
Currently you can only have 1 alias this in a class/struct, but that
is a temporary and D is supposed to allow multiple alias this
declarations.
Depending on the scope of your situation, you could also use
conditional compilation in conjunction with templates to implement
your policies, often interfaces aren't needed when you only want/need
a minor change, I only use them for polymorphism in D.
--
James Miller
Custom Allocators
I've been doing some reading on dlang.org and the newsgroup archives and have seen talk about allocators and things around the garbage collector. I have a few questions about the entire thing: - I understand that allocators are all about memory management, but how does this affect D and the way allocators are integrated into the language? - How are allocators supposed to work with the GC? I know that you can manually allocate memory and add the range to the GC, but why do you have to do this? - I've read that custom allocators aren't implemented, but I see references to using new() and delete() in classes in the docs? Is this one of the cases where the docs are what it should be and the reality is different? If there aren't custom allocators, then are there any major blockers to the addition (or is it just because nobody has added it?)? - Would it be possible to use custom allocators to write a completely GC-free application (using ref-counting instead for example)? Or would the GC still be used anyway? If I'm way off base on anything, feel free to say so, memory management and garbage collection aren't exactly my strong suits. Thanks -- James Miller
Re: traits getProtection
On 2 April 2012 06:27, Adam D. Ruppe destructiona...@gmail.com wrote:
I've prepared a dmd pull request to add a new __trait:
getProtection.
It is meant to be used along with getMember() to add to
the reflection capabilities, letting us use the existing
protection qualifiers as strings.
From the test:
==
class Test {
public int a;
private int b;
export string c;
protected int d;
package void e() {}
}
void main() {
Test t;
static assert(__traits(getProtection, __traits(getMember, t, a)) ==
public);
static assert(__traits(getProtection, __traits(getMember, t, b)) ==
private);
static assert(__traits(getProtection, __traits(getMember, t, c)) ==
export);
static assert(__traits(getProtection, __traits(getMember, t, d)) ==
protected);
static assert(__traits(getProtection, __traits(getMember, t, e)) ==
package);
}
==
This will help D automatically generate things like
external interfaces that use the protections.
For instance, I plan to use it in my web.d to only
make functions marked export available via the
web interface. Currently, you have to use a naming
convention to hide functions - a leading underscore -
even on private members. This is ok, but not great.
But with the protection trait, we can mark it with
a much more natural private, or any of the other
specifiers D has.
I'm sure other uses will come up too.
Looks good, adds a lot to the compile-time reflection capabilities. My
thoughts for it are similar to yours, generating bindings from
exported members, so you don't need to maintain separate lists or
use a naming convention.
--
James Miller
Re: Compiler development
On 2 April 2012 10:02, foobar f...@bar.com wrote: Or in other words you did regression testing. Regarding DMD - Walter has a test suite for it for the same purpose. I don't know the specifics of it as I never looked at it and not even sure whether it's open source or not. The core devs would be able to provide more specifics. Please note that while Walter writes in c++ he has a unique style of it - some claim it's very D like. There are unit tests in D for almost all features and bug fixes. Sometimes there is a regression, if it's found a test for it is added when the fix is pushed, to make sure that it doesn't happen again. If the tests don't compile, that's very bad and all the tests have to pass before a release. D's development is pretty solid, there are very, very, few breaking changes that aren't explicit and most people don't have the compiler suddenly pull the rug from underneath them (unless they were relying on the buggy behaviour). In general, the actual output of the compiler doesn't matter that much, its the behaviour of the code that matters, so that is why the tests are in D, it doesn't matter if the codegen changes, as long as the software still functions the same. That is why we have several thousand tests for the compiler that check various behaviours. -- James Miller
Re: Keeping imports clean
On 2 April 2012 10:12, Guillaume Chatelet chatelet.guilla...@gmail.com wrote: In C++ it clearly matters to have very clean dependencies to keep compilation time as low as possible ( Google even built a tool to check unused #include - http://code.google.com/p/include-what-you-use ). So I was telling to myself it would be great to have the D compiler report about unused import because it might already have all the necessary information. But maybe such a tool already exists ? Or maybe this is simply irrelevant ? D doesn't have includes, importing a module that you don't use doesn't matter because D only needs the imports to find function declarations. This is clear in the import syntax: import std.random : uniform //import only uniform from the std.random module so it is a symbolic import, not a textual import. Also note that while D has .di (D Interface) files, they are not required, and often people don't even bother with them, merely distributing the source. So in short, it isn't relevant at all, since there is no preprocessor to f**k things up. -- James Miller
Re: D for a Qt developer
On 1 April 2012 22:12, Davita dato1...@hotmail.com wrote: Well, that's what i'm talking about. D is such a wonderful language that it should scream on different forums and sites such as stackoverflow or codeproject, but instead it's very quite, passive. And I think this is due to the lack of quality development tools. :( None of the companies or organizations I know would never start development on DWT or QtD. Shouldn't D team address those issues? I mean, only enthusiasmic community can't do much here. I think a sponsor or some commercial interest is a must, or as I already mentioned above, to work with Nokia guys and bring D with QtCreator. Or maybe to work with MS and integrate D in VS and WinRT api. If one big organization starts using D, then more and more people will have trust in D and start using it. Otherwise I don't think the future of D will be as bright as it should :( Please don't assume that all people using D want big IDEs and toolchains, I'm perfectly happy with Vim + dmd, and I know several people that work in similar ways (substitute Vim with another editor, dmd with gdc, ldc2 or sdc). As for the D Team, there isn't really one. There's Walter, the creator of the language and dmd, Andrei, a signficant contributor to several key language features. There are several people that have contributed heavily, Jonathon Davis, Brad Roberts, David Simcha wrote the Garbage collector, Steven Schveighoffer does a lot, and other that I can't remember right now. But all of these people have day jobs. Walter does... whatever he does, Andrei works for Facebook. So its not like there's a dedicated team of people working hardcore on this, so they focus on what is worth focusing on, like compiler bugs and broken features (like AA's that H.S. Teoh is writing a replacement for). So IDE's and gui support isn't something that the D Team is working on, and it isn't what they should be working on. Other people should work on IDE's and graphics libraries, and they are. Andrej is working on wxD, somebody could pick up the QtD project and get that back up and running, there's VisualD which gives Visual Studio D support and MonoD which adds D support to MonoDevelop. As for working with other companies, what is the reason for these people to do that? MS are focused on .NET and C#, they don't want to promote and improve D, for free. There is a business aspect to all of this, and D isn't a money making venture. It is pretty much a charity, people donate their time and don't expect anything concrete back. But businesses don't do charity, it's just not good sense. I guess I'm just concerned that there are developers that think IDEs and fancy toolchains are what makes a language, but it's the requirement of an IDE that shows a language's flaws and faults. Ideally you should be able to write code in a simple text editor without much issue, and that is what you can do in D, because that is what I do in D. -- James Miller
Re: UFCS for types?
On 31 March 2012 21:37, simendsjo simend...@gmail.com wrote:
Is is possible to use UFCS for types to simulate static members?
struct S {
static void f();
}
void ext(S)() {
S.f();
}
void main() {
ext!S(); // ok
S.ext(); // Error: no property 'ext' for type 'S'
}
As far as I know UFCS just rewrites `a.f(b,c)` to `f(a,b,c)`, so
probably not, since `S.ext()` would be re-written to `ext(S)`, which
obviously makes no sense. Its pretty much just syntatic sugar with a
few disambiguation rules.
Basically you're asking for UFCS for template parameters, but that
would introduce too many ambiguities, especially considering things
like alias parameters:
ext(alias T, U)(U a);
int foo = 1;
foo.ext() //does the alias T get the value, or the U a?
If you just remember that UFCS is just for functions, not templates,
or rather its Uniform Function-Call Syntax, not Uniform
Template-Instantiation Syntax (UTIS?). Because even ext(T)(); is just
sugar for:
template ext(T) {
void ext();
}
--
James Miller
Re: std.typecons.Ref(T).opImplicitCastTo()
On 31 March 2012 06:28, Jonathan M Davis jmdavisp...@gmx.com wrote: it also has opDot, which is being removed from the language. Out of curiosity, what was opDot? -- James Miller
Re: Linux and D wallpaper :)
On 29 March 2012 17:48, F i L witte2...@gmail.com wrote: Don't know if this is the place for this sort of announcement Found a great looking Linux logo over at gnome-look.org by kodama (http://gnome-look.org/content/show.php/Linux+Logo?content=142418). So I thought I'd modify it a bit and make some wallpapers. D sounded like a great place to start. Here's the first go (1080p): http://reign-studios.com/d-wallpapers/LinuxAndD.png I'll make a few more and post them here (suggestions welcome). Also, if anyone wants the original Inkscape files just let me know. Looks awesome. Although, while I like the Men are from Mars quote, I can see it being taken the wrong way... -- James Miller
Documentation Layout
this extra information adds a new problem: filtering. If you have a lot of code in one file, then trying to reduce the noise of things you don't want to deal with is necessary. So we need collapsible sections, they don't have to be fancy, and they can be an add-on, so no javascript simply means no collapsing. This means that I can look at something, collapse it to indicate that it isn't relevant, then move on. When flicking around the page, it's easier to see what I have already looked at in this case. There are a multitude of other UX enhancements you can make, but this one is simple and efficient. Expanding on point 3, basically, if a search exactly matches a function, then you should get taken straight to the documentation for that function, PHP is a brilliant example for that, since that is exactly what it does. It assumes you are looking for a function/class, and if it can't find it, gives you close-match suggestions at the top and then general results near the bottom. This is incredibly efficient, since sometimes I know the name of the function and just want to see argument order, or I might have an idea of the function I want, but can't remember the exact name, PHP knows better what functions it provides than Google, so it doesn't use Google. We could also do the Wikipedia trick of We couldn't find a function/class by that name, did you mean list of options? Otherwise search the entire site and that last bit can still be Google. Point 5 is pretty self explanatory, when trying to figure out how to use a module, you might need to look at several different Types and functions, all related, but they don't get linked to each other much, you just have to guess. Other things that would be awesome would be having a separate Concepts section, like the articles, but specifically for concepts, especially if they are D related. Ideally each module would have its own concepts page, but that isn't always reasonable or feasible. Being able to manually assign importance to certain items in code, for example in std.random, the first item is the struct LinearCongruentialEngine, but most people probably just want rndGen + usage or uniform + usage, they are far more useful in most cases and should be nearer the top. On a related note, providing alternative usage declarations for things would be useful, especially complex templated functions where all the templated arguments are inferred most of the time, even if this one of the javascript-enabled features, so by default the standard declaration could be shown, then if javascript is enabled, they get replaced with alternative declarations and you get a button to switch. Similarly, skipping or hiding unnecessary functions and classes that are only useful for advanced usage (like the RNG engines, most people are fine with MT19937) would be good for newer users, since often they lower the signal-to-noise ratio for all users, and more so for newbies. Some of these things are things that need to be changed, some are just fancy wishlist-type items. Mostly, better discoverability is the top priority overall, so newer members (which may include me, depending on who you ask) don't get frustrated trying to figure out how to do otherwise simple things. I understand that a lot of this due to the limitations of DDoc, so either that needs improving, or we need to make a new tool, even if it is just for Phobos, or other large projects. The standard library is supposed to be a showcase of some of our best work, but right now the case is old and busted, we need to make it the new hotness. -- James Miller
Re: Documentation Layout
On 29 March 2012 13:58, Nathan M. Swan nathanms...@gmail.com wrote: On Wednesday, 28 March 2012 at 22:43:19 UTC, foobar wrote: Categories - worst idea ever. What's better: int a; // this is size OR int size; Same thing applies here - code MUST be self documenting as much as possible. But categories are still useful, e.g., when you want a function in std.algorithm that looks for a specific element. It could be search or find or firstElemSatisfyingCondition, and even though those are all self documenting, it would be a pain to look through the list of functions in alphabetical order. The use of categories narrows your search for the function down 20%. NMS Exactly my point. There is a line between code must be self documenting and I need to read the code to understand what this does. Self documenting code is more about removing the cognitive stress of reading code. Actual documentation needs the whys and wherefores about everything. std.string is a brilliant example, with a list of 68 functions at the top, and a total of 89 anchors (presumably just overloads), there is no easy way to quickly find a function for a purpose. You have indexOf - a searching function - next to insert - a manipulation function - next to isNumeric - a property testing function. Each of those functions are self-documenting but that doesn't mean they wouldn't benefit from categorization. -- James Miller
Re: Documentation Layout
On 29 March 2012 18:26, Jakob Ovrum jakobov...@gmail.com wrote: There is a simple project called cuteDoc (name comes from the old candyDoc theme) which has a demo using the Phobos documentation: http://robik.github.com/phobos/ Project home page: https://github.com/robik/cuteDoc It looks ok, still a little too cluttered for my liking. Also, serif fonts on a web page... It has some rudimentary JavaScript for a module list and a generated jump-to table. I would love to see the Phobos documentation on dlang.org do something similar; there's so much low-hanging fruit for D's documentation that I wish someone with some web savvy would pick up on. It's pretty baffling to think that some Phobos modules have *manually maintained* table headers, what the heck were people thinking? What happened to automation? I would, but I don't have the time. I've thought about it, but I work long days. -- James Miller
Re: Get indexes of character in array
On 28 March 2012 19:35, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: I'd like to get a list of indexes into an array that matches a character. E.g.: a foo a bar a.indexes(a) == [0, 6, 12] Anything like that in Phobos? std.regex might be able to produce something like it. -- James Miller
Re: std.conv length=0
On 29 March 2012 16:03, cc c...@nevernet.com wrote: On Tuesday, 10 April 2007 at 07:46:35 UTC, Bill Baxter wrote: I too thought this behavior was silly, so I wrote a little wrapper for it (replying 5 years after the fact because someone'll probably stumble onto this question through Google like I did): I award thee the Necromancer badge, for reviving a long-dead thread. -- James Miller
Re: std.conv length=0
On 29 March 2012 17:05, Jesse Phillips jessekphillip...@gmail.com wrote: On Thursday, 29 March 2012 at 03:40:55 UTC, James Miller wrote: I award thee the Necromancer badge, for reviving a long-dead thread. -- James Miller I find the distaste of reviving a thread strange. It would be like removing the reopened feature of bug tracking software (who wants to transpose all that information). I have no problem with it, if I did, I would have said so. -- James Miller
std.containers - WAT
In helping someone in D.learn, I ended up looking through the
documentation and code for std.containers.
There is a lot wrong with whats going on there right now.
For a start, the documentation is pretty unclear, The table for the
container primitives is poorly explained, and the complexity columns
wraps on most screen sizes, making understanding them a nightmare. The
explanations for what things are, and what they do is pretty unclear,
and since its not completely standardized over the different
containers, you end up with some truly mindboggling documentation. A
good example is this: c.removeAny()- Removes some element from c and
returns it., what some element at random? Or does it take an argument
that isn't show like what is implied by this: c.stableRemoveAny(v) -
Same as c.removeAny(v), but is guaranteed to not invalidate any
iterators., but that doesn't seem right because SList has T
removeAny() - Picks one value from the front of the container, removes
it from the container, and returns it. which doesn't take a value.
This is endless confusing, and I ended up consulting the unittests in
order to understand what the hell was going on.
Then there are the strange input and output types/value for the
arguments. For example, why does SList.linearRemove return an empty
Range on the Take!Range overload, and an empty Range on the Range
overload? In fact, why are any of the functions accepting and
returning /Ranges/ which are internal types specific to the container?
Why don't they all just take a type that can be converted to a range?
As is stands, you end up with ridiculous requirements like:
//Remove a single element from an SList, given its index
size_t index = 5;
SList!int s = [0,1,2,3,4,5,6,7,8,9];
auto r = s[0..index-1];
auto r1 = take(r, 1);
s.linearRemove(r1);
assert(equal(s, [0,1,2,3,5,6,7,8,9]);
Which could be replaced with an overload for linearRemove that looks like this:
/** Removes the element at index, return false if the element
could not be removed **/
bool linearRemove(size_t index){...}
Almost all of the primitives seem to be based around adding or
removing from the front or back of the container, but there's no
random-access removal. And since the behaviour is Container specific,
its impossible to figure out what a function does anyway! For example,
SList's linearRemove(Range) just removes the front elements from the
container, not obvious.
Is there any reason why things are the way they are? Because all I see
are people getting exited about ranges and operator overloading and
not really thinking about what a useful set of features any given
container should have.
--
James Miller
P.S. I'm happy to help out improving the documentation, but I have no
idea what these things are supposed to do in the first place...
Re: std.containers - WAT
On 28 March 2012 15:28, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: In fact, why are any of the functions accepting and returning /Ranges/ which are internal types specific to the container? Ranges are not internal to containers, they are the way containers are manipulated. But there is a Range struct inside each container, it implements the Range interface, but as far as I am aware, it is its own type, and therefore anything that explicitly expects a Range is going to expecting its own internal type. From what I can tell, the internal Range struct on each container is just the underlying storage mechanism for that container, and you can even have more than one defined internal Range for a container. The issue comes about that several methods want that type. Now there may be some voodoo going on that I don't understand, but it seems to me that I can't do some thing like: SList!int s = [1,2,3,4,5,6,7]; s.linearRemove([4]) // Arrays are ranges To remove a certain value, because [4] is not a valid type, despite the fact that isForwardRange!(int[]) returns true. This is because although int[] is a range, it is not a Range (as in the inner type inside SList named Range). This is incredibly confusing to people reading the documentation, since Range and range could mean anything. I guess what I want is the why's for everything, why do things return certain values? Why do certain methods only accept data that was pulled from the container in the first place? Simply saying that some generally returns some value doesn't help, I need to know the whys behind it. Is is because the common use case is that, is it because it was the easiest way to do it, is it because you just randomly decided to because you felt that void was a cop-out? I just feel that the documentation could do with some work in this regard, but I wasn't there when this was being designed, I don't know the whys behind the decisions. If I point out where I think the documentation is lacking, simply in a That is completely useless kind of way, could somebody either update the documentation, or provide me with better explanations. I have also attached the screenshot you asked for, sorry for the quality, I don't have the tools on my machine to deal with images properly right now. -- James Miller attachment: screengrab.jpg
Re: std.containers - WAT
On 28 March 2012 17:00, H. S. Teoh hst...@quickfur.ath.cx wrote: Anyway, it would be great if more people can help with the docs. Just create an account on github and fork D-Programming-Language/phobos and D-Programming-Language/d-programming-language.org, run `git clone` on both repositories in the same directory, create a new branch, and edit away. When you're ready to test, run a `make html` in the phobos directory. This will generate a copy of the docs on your local machine under ../web/phobos-prerelease/, which you can point your browser at. When you're happy with your changes, go to github and initiate a pull request on phobos from your working branch. Lol, I am doing my best, I currently have a pull request for a typo (not exactly a massive change, but every bit helps) and I will probably contribute more when I have more experience with what is there. I would say that I could improve the documentation for std.algoritm, since I'm using it a lot right now, but its actually pretty good, so that's kinda out of the question. Knowing more about ranges would be very useful for people, since while people have the understand that a range is a sequence of values between two values, its not that obvious how that affects the programming side of it. While Andrei's article is good, the audience is clearly not people that just want to know what is a Range, and how do I use it. I think one more thing that needs some changing is the usability of the documentation, right now you get a dense list at the top, in mostly-alphabetical order (I think it puts caps first, then lower case) and then you get a massive list of classes and functions that are difficult to navigate. -- James Miller
Re: How to remove element from an SList?
On 28 March 2012 13:02, Chris Pons cmp...@gmail.com wrote: Right now i'm struggling with trying to understand how to remove an element from a n SList. I only want to remove one element, not a range of elements. I also don't want to use an Array because I will have to reshuffle elements to take care of the empty spot when I remove it. The only thing I've seen so far is find from std. algorithm and linearRemove. However I can't get find to work and I don't exactly believe linearRemove will work either because afaik that removes up to the index specified? I'm not to clear on this. Here's a simplified example of what I was trying: SList!int intList; intList.insert( 1 ); auto a = find( intList, 1 ); intList.linearRemove( a ); The documentation is very unclear, I had to figure out what linearRemove did from the unittest for it. This example (comments are mine) should help: auto s = SList!int(1, 2, 3, 4, 5, 6, 7, 8, 9, 10); auto r = s[]; // Slice of the original list popFrontN(r, 3); // Removes the first 3 elements auto r1 = take(r, 4); // returns the first 4 elements assert(equal(r1, [4, 5, 6, 7])); auto r2 = s.linearRemove(r1); //removes the range [4,5,6,7] assert(s == SList!int(1, 2, 3, 8, 9, 10)); assert(equal(r2, [8, 9, 10])); The docs mention that the range you use to remove, should be sourced from the original list. Also, you actually need to use take(), since the only to remove from the middle is with a Take!Range, its not very clear, or understandable, but that's the way you have to do it. Also, you are right the the other linearRemove does remove upto the element, however, it works by again, passing a range. std.containers is an odd beast, and I might do some more investigation. However, all you need to know is that in order to remove, say the 5th element from a SList, you need to do this: SList!int s = [1,2,3,4,5,6,7,8,9,0]; auto r = s[0..4]; auto r1 = take(1, r); s.linearRemove(r1) Not the most intuitive way in the world... -- James Miller
Re: Regex performance
On 27 March 2012 11:05, Ali Çehreli acehr...@yahoo.com wrote: My unofficial results comparing 2.056 to 2.058 on 64 bits: shakespeare.txt, 2.056 - 1868 msecs shakespeare.txt, 2.058 - 632 msecs data.csv, 2.056 - 51953 msecs data.csv, 2.058 - 1329 msecs That last line is pretty impressive. :) Dmitry did impressive work over those few version of Phobos/DMD. The performance is even more impressive when you consider that std.regex supports things like named matching and lookbehind that often slow down a regex (also kinda removes the regular from the name regular expression, technically) -- James Miller
Re: D web apps: cgi.d now supports scgi
On 26 March 2012 08:37, dnewbie r...@myopera.com wrote: On Sunday, 25 March 2012 at 19:22:02 UTC, Adam D. Ruppe wrote: On Sunday, 25 March 2012 at 19:14:32 UTC, dnewbie wrote: I wonder how can I generate unique, non predictable session ids. In web.d, there's a Session class that generates them with std.random.uniform. I suspect this isn't the best possible, but it's worked pretty well so far. The session class also uses a file to store persistent string key/value data. This is what I was looking for. Rock'n'roll!! Slightly off-topic, but what is your policy of derivative works Adam? So if I built something similar off your work, but gave you credit, and pushed any changes/bugfixes/improvements back to you, that would be ok? Basically, if I build my own libraries off yours, I assume that fine. Since I don't really want to repeat all the work you have done already. -- James Miller
Re: D web apps: cgi.d now supports scgi
On 26 March 2012 09:28, Adam D. Ruppe destructiona...@gmail.com wrote: I don't really care; you can do whatever you want with it. I figured, but its nice to ask first :D. -- James Miller
Re: BitC, Rust, dog food and more
On 26 March 2012 08:41, Nick Sabalausky a@a.a wrote: Because you're cleverly using very D-like C++ ;) Unsurprising from, you know, the creator of D... That said, having a D compiler in D would be cool, simply because every language needs a bootstrapped compiler :P. Also, their are other arguments that apply well to bootstrapped compilers, like improving the language improves the compiler, which improves the language. It's also a complicated enough endeavour that it showcases D well. I don't think that we should replace DMD with it, but it would be a cool project. -- James Miller
Re: BitC, Rust, dog food and more
On 26 March 2012 09:49, deadalnix deadal...@gmail.com wrote: ddmd seems to provide a working frontend written in D. I think this project should be more promoted (eventually become the main d frontend ?). I have seen it, and it looks good. But there are reasons why the DMD front-end is in C++, I think Walter has explained why on occasion before, but it basically boils down to: its easier for other compiler developers to understand + integrate with C++ code when building the compiler back-end than if they had to interface with D code. -- James Miller
Re: How to use D for cross platform development?
On 26 March 2012 09:44, Iain Buclaw ibuc...@ubuntu.com wrote: A spork of druntime, yes. A spork? I've never heard that before... -- James Miller
Re: Getting around the non-virtuality of templates
On 26 March 2012 11:36, Stewart Gordon smjg_1...@yahoo.com wrote: I'm coming up against some interesting challenges while porting stuff in my utility library to D2. Firstly, D2 uses opBinary and opOpAssign, rather than the operator-specific op* and op*Assign. While the latter still work, they aren't mentioned in the current D2 docs. Which would imply that they're on the way out; however, there's no mention at https://github.com/D-Programming-Language/d-programming-language.org/blob/master/deprecate.dd (See also http://d.puremagic.com/issues/show_bug.cgi?id=7779 ) Still, it seems clear that opBinary/opOpAssign is the D2 way of doing it. But it has the drawback that, because it's a template, it isn't virtual. One way about it is to keep the D1-style op functions and make opUnary/opBinary/opOpAssign call these. But is there a better way? The other isn't a D2-specific issue, though D2 increases the significance of it. I have a method with the signature Set opAnd(bool delegate(Element) dg) I would like to enable a user of the library to pass in a delegate whose parameter is any type to which Element is implicitly convertible. This could be the same type as Element with the top-level constancy changed (probably the main use case), or a type that is distinct beyond the constancy level. Turning it into a template Set opAnd(E)(bool delegate(E) dg) would address this, but prevent overriding with the appropriate code for each set implementation. Who else has been faced with this problem? Have you found a good way of dealing with it? Stewart. Non-virtuality of templates is a general problem at the moment. The issues seem to be around how to handle inheritance of template arguments, and how to dispatch the functions based on a combination of template arguments and class hierarchy. This is a hard problem with no obvious answer. in terms of trying to work around it, perhaps compile-time reflection could help, I haven't encountered this before, but that's where I would start. -- James Miller
Re: When do you use templates instead of CTFE?
On 26 March 2012 12:35, Jonathan M Davis jmdavisp...@gmx.com wrote: On Sunday, March 25, 2012 17:55:56 Nick Sabalausky wrote: Yea, the general rule of thumb is If you can do it with CTFE, then do so, otherwise use templates. Generally, you end up having to use templates for stuff that operates on types, whereas CTFE works for stuff that can be normal functions. - Jonathan M Davis Often I end up using the same function in CTFE and runtime. -- James Miller
Re: Poll of the week - How long have you been in the D world?
On 26 March 2012 14:18, dnewbie r...@myopera.com wrote: Just out of curiosity, is D attracting new users? Are the old users running? Place your vote here http://www.easypolls.net/poll.html?p=4f6fb7e5e4b04f389e5eb66f Looks like a fairly even spread so far, (27 votes). The higher bracket is low, but it is also 6-10 years, D hasn't been around much longer than that . -- James Miller
Re: opDispatch(string name, E...) (E e) question.
On 26 March 2012 09:45, bls bizp...@orange.fr wrote: How do I call opDispatch(string name, E...)(E elements) ? What I want to archive is to call f.i. fm.list with an arbitrary number of arguments without using fm.list(1, abc, 4L, 3.33); Instead I would prefer fm.list = (1, abc, 4L, 3.33); You can use @property on opDispatch to use setter/getter notation, however I wouldn't rely on that functionality long-term if you want to keep the same function-call syntax (since -property flag is supposed to enforce proper parenthesis use on `@property`s). fm.list = (1, abc, 4L, 3.33); I'm hoping you mean `fm.list = [1, abc, 4L, 3.33];` I think that using the right template parameters, you can use the same code for (T...)(T el) and (T)(T[]), I just can't remember what that is... Another question : How do I bring in : opDispatch(string name, T) (T[] t) -- James Miller
Re: opDispatch(string name, E...) (E e) question.
On 26 March 2012 10:34, bls bizp...@orange.fr wrote:
(T) (T[] t) AND (T) (T t) seems not to work.
Ok, so looking here: http://dlang.org/function.html, I have determined
that, if you are using Variant arrays (though I'm not sure if you can
do that using literals...) you can use the syntax from this example:
int test() {
return sum(1, 2, 3) + sum(); // returns 6+0
}
int func() {
int[3] ii = [4, 5, 6];
return sum(ii); // returns 15
}
int sum(int[] ar ...) {
int s;
foreach (int x; ar)
s += x;
return s;
}
You'll probably need to do some experimentation to figure out how
Variant fits into that properly, but it shouldn't be too hard.
Also, remember that opDispatch takes the name of the function as the
last parameter, so watch out for that.
--
James Miller
Re: avgtime - Small D util for your everyday benchmarking needs
On 23 March 2012 17:53, Juan Manuel Cabo juanmanuel.c...@gmail.com wrote: But I think the most important change is that I'm now showing the 95% and 99% confidence intervals. (For the confidence intervals to mean anything, please everyone, remember to control your variables (don't defrag and benchmark :-) !!) so that apples are still apples and don't become oranges, and make sure N30). More info on histogram and confidence intervals in the usage help. Dude, this is awesome. I tend to just use time, but if I was doing anything more complicated, I'd use this. I would suggest changing the name while you still can. avgtime is not that informative a name given that it now does more than just Average times. -- James Miller
Re: avgtime - Small D util for your everyday benchmarking needs
On 23 March 2012 21:37, Juan Manuel Cabo juanmanuel.c...@gmail.com wrote: PS: I should use the t student to make the confidence intervals, and for computing that I should use the sample standard deviation (/n-1), but that is a completely different story. The z normal with n30 aproximation is quite good. (I would have to embed a table for the t student tail factors, pull reqs velcome). If its possible to calculate it, then you can generate a table at compile-time using CTFE. Less error-prone, and controllable accuracy. -- James Miller
Re: Wrong lowering for a[b][c]++
On 23 March 2012 19:15, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: I've no idea. It's probably a front-end bug and the cast forces the compiler to.. come to its senses? `cast()` is the compiler equivalent to a slap with a wet fish? -- James Miller
Re: Vector operations optimization.
On 23 March 2012 18:57, Comrad comrad.karlov...@googlemail.com wrote:
On Thursday, 22 March 2012 at 10:43:35 UTC, Trass3r wrote:
What is the status at the moment? What compiler and with which compiler
flags I should use to achieve maximum performance?
In general gdc or ldc. Not sure how good vectorization is though, esp.
auto-vectorization.
On the other hand the so called vector operations like a[] = b[] + c[];
are lowered to hand-written SSE assembly even in dmd.
I had such a snippet to test:
1 import std.stdio;
2 void main()
3 {
4 double[2] a=[1.,0.];
5 double[2] a1=[1.,0.];
6 double[2] a2=[1.,0.];
7 double[2] a3=[0.,0.];
8 foreach(i;0..10)
9 a3[]+=a[]+a1[]*a2[];
10 writeln(a3);
11 }
And I compared with the following d code:
1 import std.stdio;
2 void main()
3 {
4 double[2] a=[1.,0.];
5 double[2] a1=[1.,0.];
6 double[2] a2=[1.,0.];
7 double[2] a3=[0.,0.];
8 foreach(i;0..10)
9 {
10 a3[0]+=a[0]+a1[0]*a2[0];
11 a3[1]+=a[1]+a1[1]*a2[1];
12 }
13 writeln(a3);
14 }
And with the following c code:
1 #include stdio.h
2 int main()
3 {
4 double a[2]={1.,0.};
5 double a1[2]={1.,0.};
6 double a2[2]={1.,0.};
7 double a3[2];
8 unsigned i;
9 for(i=0;i10;++i)
10 {
11 a3[0]+=a[0]+a1[0]*a2[0];
12 a3[1]+=a[1]+a1[1]*a2[1];
13 }
14 printf(%f %f\n,a3[0],a3[1]);
15 return 0;
16 }
The last one I compiled with gcc two previous with dmd and ldc. C code with
-O2
was the fastest and as fast as d without slicing compiled with ldc. d code
with slicing was 3 times slower (ldc compiler). I tried to compile with
different optimization flags, that didn't help. Maybe I used the wrong ones.
Can someone comment on this?
The flags you want are -O2, -inline -release.
If you don't have those, then that might explain some of the slow down
on slicing, since -release drops a ton of runtime checks.
Otherwise, I'm not sure why its so much slower, the druntime array ops
are written using SIMD instructions where available, so it should be
fast.
--
James Miller
Re: Windows Socket Timeout
On 23 March 2012 12:52, David Nadlinger s...@klickverbot.at wrote: On Thursday, 22 March 2012 at 23:36:03 UTC, Paulo Pinto wrote: If you really want performant sockets on Windows, you need to make use of the Windows specific APIs, and use IO completion ports not select. Depending on what you are trying to achieve, you could always consider using enet or (parts of) RakNet. David Ideally, no matter what platform you're on, you want some form of non-blocking or asynchronous networking. The easiest way would be a seperate thread for all networking logic. Especially since you should probably have a separate thread for your rendering code anyway. -- James Miller
Re: Mono-D@GSoC - Mentor needed
On 21 March 2012 03:22, alex i...@alexanderbothe.com wrote: I actually found myself using Mono-D for the nice completion and VisualD for debugging, which is a total pain and probably more effort than its worth :) Beta as hell ;D But nevertheless it'd be nice if there was a mentor for this project :) A bit of a side note, but is there any way that some of this work could be made more standalone, even if somebody else has to take up the work to finish it and make it truly standalone. I personally can't stand fully integrated environments, but I do like things like code completion and the like, so it would be nice to be able to use these features in, for example, vim. I don't know how feasible this is, but it's worth mentioning. -- James Miller
Re: Three Unlikely Successful Features of D
On 21 March 2012 11:49, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Now a real one: auto type inference. Could you possibly imagine what the type name should be on the left-hand side? ? x = retro(stride(chain([1, 2], [3, 4]), 2)); Who knows. auto is great for these higher-level types. Also when dealing with complex parameterized types, so when I have a function that gives me the type foo!(bar!(int, 5), baz!string) I don't have to know that, I can just use `auto` instead. -- James Miller
Re: Proposal: user defined attributes
Sorry for not quoting, but I'm not sure who to quote...
I think people are over-thinking this issue. Adam's initial proposal
was simply to be able to add compile-time checkable data to data
structures and functions. I think this works well at this level. As he
demonstrated, string mixins and ctfe only get you so far in this
instance.
The idea that in order to replicate this functionality, you need to
actually parse the D code to get what you want, is horrific. Relying
on naming conventions for functionality is horrendous, especially when
a simple @note(data1,data2=val) can solve all of the issues. And if
they're only compile time, then it can all be discarded when you get
to code-gen, and if you deliberately limit the scope of them, then you
aren't fostering the new language features will solve all my
problems.
Looking at other languages is a good start for ideas, but ultimately
we need a D-flavoured solution, and using simple `__trait`-inspectable
annotations is a good way of doing it. As Teoh said, think of it as a
hook into Typeinfo, allowing the programmer to alter it at compile
time.
I don't care about Aspect-Oriented programming, or anything like that,
I just want to be able write:
@note(GET,POST)
auto myClassFunction(arg1, arg2, arg3) { ... }
without having to use templates that break inheritance, or doing
checks in the function for the request type, that could be handled in
a library. There's already a mechanism for seeing what attributes that
function has, so why can't I have some code that does this:
template hasAnnotation(alias data, string an) {
enum hasAnnotation = __traits(hasAnnotation, data, an);
}
(Or something, my template-fu leave something to be desired, not the
point though). It already looks like idiomatic D code.
Its not some big change that massively overhauls the way code is
written, the same way annotations in Java haven't meant that people
suddenly write Java completely differently. They do what they look
like they do, they add some extra information to the thing in
question that allow for some more advanced decision making.
Going back to the Web-based example, if I use an opDispatch system to
forward requests to the appropriate controller, I can use compile-time
reflection to generate checking code for the handlers, based , this
means that a simple annotation makes reading the function code much
simpler, since boiler-plate checking code has been removed, I can
implement a white-list based policy for request-type access, rather
than a blacklist that using isPost or isGet methods to check
in-handler. This is more secure, since if I forget to add /any/
annotations, then it wont receive /any/ requests. Lo and behold, I can
now have secure inter-controller communication without needing 1. a
naming convention, 2. an access control list or 3. boilerplate code.
I could go on a similar rant about serialization, but I think my point is made.
deadalnix is talking about being able to re-write language features in
terms of this system, but that's taking it too far, like a lot of
people, he wants D to be all thing to all people. The original idea
was to just to be able to add simple attributes to functions. Other
people sought to extend this unnecessarily, but everything else is
just templates, mixins and CTFE, nothing else.
The real discussion that need to be going on is: How far do notes
extend? (can you have arbitrary expressions annotated?) What data can
be packed into annotations? (Can i put any data into annotations, or
only internal types?) Syntax details, obviously using the @-syntax,
but specific naming, so @note, or @annotation? for example.
Scoping/Collision, I don't think this will be an issue, but if two
libraries are looking for the same annotation name, then there could
be some issues.
I think there is merit in having a Java/C# @myannotation, but I
don't think it is needed for D, everything that those annotations
cover can be done using CTFE and mixins, with the minor addition
above.
--
James Miller
Re: Mono-D@GSoC - Mentor needed
On 21 March 2012 12:08, Adam D. Ruppe destructiona...@gmail.com wrote: On Tuesday, 20 March 2012 at 22:52:13 UTC, James Miller wrote: features in, for example, vim. I use this script called supertab.vim that maps tab to vim's control+p and control+n completition. I find it works really well, and for virtually everything too, not just code. I've seen that, but its not very smart. I'm ok with that, but I've been spoiled by clang_complete, which makes C++ development bearable, but uses clang to give only valid options for the context. I'd love something like that for D. -- James Miller
Re: regex issue
On 21 March 2012 04:26, Jay Norwood j...@prismnet.com wrote: yes, thanks. I read your other link and that was helpful. I think I presumed that the escape handling was something belonging to stdio, while regex would have its own valid escapes that would include \p. But I see now that the string literals have their own set of escapes. Can you imagine the madness if escapes were specific to stdio, or some other library! Ok, and I'll just send this newline over the network... Dammit, std.network doesn't escape \n. Also means that you have perfect consistency between usages of strings, no strange other usages of the same escape sequence... -- James Miller
Re: Interesting Memory Optimization
On 20 March 2012 01:33, Derek ddparn...@bigpond.com wrote: Is the effort to do this really an issue with today's vast amounts of RAM (virtual and real) available? How much memory are you expecting to 'save'? And is RAM address alignment an issue here also? Currently most literals are aligned on a 4 or 8-byte boundary but with this sort of pooling, some literals will not be so aligned any more. That might not be an issue but I'm just curious. Gah, I hate this sentiment! It encourages lazy, poor design and practice simply because RAM/CPU is cheap, dev time is expensive. Yes, RAM and CPU /are/ cheap, and dev time is expensive, but so is losing millions of dollars of revenue because your loading times on your app are 100ms too slow, and your conversion rate drops. This is the one thing that i hate about the Rails community, since it is their motto. Sites should be blazingly fast with today's computing power, but a ridiculous focus on Developer productivity has meant that no change has happened. I love it when D threads talk about whether or not the compiler does inlining, or loop unrolling, or whether it does, or should, use the correct instructions for the target. Not because I get off on talking about optimisation, but because it shows that there are still people care about squeezing every last instruction of performance, without compromising on productivity. Resources cost money, any saving of resources saves money. -- James Miller
Re: Interesting Memory Optimization
On 20 March 2012 13:17, H. S. Teoh hst...@quickfur.ath.cx wrote: Sites should be blazingly fast with today's computing power, but a ridiculous focus on Developer productivity has meant that no change has happened. Exactly! In spite of the fact that CPU speed has increased on the order of a millionfold since the old days, and in spite of the fact that memory capacity has increased by several orders of magnitude, today's software is STILL taking forever and two days just to load, and we STILL run out of memory and thrash to swap on almost exactly the same tasks that we did 10 years ago. Where has all the performance boost drained into? Into bloated code with over-complex designs that suck resources like a sponge due to lack of concern with resource usage, that's what. And whats more, developer productivity is not a function of the tools they use, its a function of how they use them. Sure, some tools make you more productive than others, but I swear by (g)vim for everything and it hasn't let me down. I use the command line, ssh where I need to go, all tasks that should make me less productive but I'm good at what i do, so there's no difference. I still spend my time in PHP dealing with platform differences between my local environment and the server environment, I still have to write checks for things that are local-only and things that are server-only. Difference is that these checks exist in production code, compiled code can cut them out. Ideally, 99% of web-apps out there would be CGI/FastCGI processes running behind light webservers like nginx. They would be compiled, native code (maybe byte-code like .NET or Java if you need something special that needs it) and run at the speed of fucking light. But they aren't. You have servers running a virtual machine, running a framework, running a web app that isn't optimized because hey, RAM is cheap. You have scripting languages running applications that have the scope of massive enterprise software, and they aren't designed for it. I hate working with PHP, not because the language sucks (though it does) but because I know that every time someone loads a page, a ton of redundant work is done, work that could be done once, on startup, then never done again. Silverstripe has to scan the directory tree to build a manifest file to get decent performance out of what they do. But they still have to check that the files exist every time the file loads. They still have to read the file and parse it. It makes me feel ill thinking about it. Anyway, I should probably stop ranting about this. -- James Miller
Comparison issue
Hey, I'm trying to do some vector based code, and my unittests started
to fail on testing normalize. I'm using the standard algorithm, but
the assert is always return false. I did some investigation, and can
show that this program causes failure:
import std.math : sqrt;
import std.stdio : writeln;
T size(T)(T[] t){
T val = 0;
for(size_t i = 0; i t.length; i++) {
val += t[i]*t[i];
}
return sqrt(val);
}
void normalize(T)(ref T[] t) {
auto s = size(t);
foreach(ref v; t) {
v /= s;
}
}
void main() {
float[] vector = [1,2,3,4];
normalize(vector);
auto v1 = size!float(vector);
writeln(v1 == 1); //false
writeln(v1 == 1.0); //false
writeln(v1 == 1.0f); //false
writeln(v1+1 == 2.0f); //true
}
I used typeid and can show that the type of `v1` is `float`, as you'd
expect. And the last one passes fine, as does doing `(v1+1)-1 == 1`.
I'm not sure what could be causing this. I believe it may be a bug,
but I would like to see if I'm just wrong instead.
--
James Miller
Re: Comparison issue
On Mar 20, 2012 1:50 AM, bearophile bearophileh...@lycos.com wrote: James Miller: writeln(v1 == 1); //false writeln(v1 == 1.0); //false writeln(v1 == 1.0f); //false writeln(v1+1 == 2.0f); //true Maybe I'd like to deprecate and then statically forbid the use of == among floating point values, and replace it with a library-defined function. Bye, bearophile I wouldn't mind if it was just type weirdness, but its not. It appears that 1 does not equal 1.
StackOverflow Chat Room
Hey guys, I made a StackOverflow chat room. You don't have to use it or anything, but at least it exists now. Its called Dlang, http://chat.stackoverflow.com/rooms/9025/dlang -- James Miller
Re: Implicit integer casting
On 19 March 2012 08:53, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Another classic which fails to compile is: import std.random; ubyte c = uniform(0, 256); In the call uniform returns a number anywhere from 0 to and including 255, which can fit perfectly in a ubyte. But I have to use a cast (which is error-prone if I change the right interval), or use a to!ubyte call (which is verbose). Granted for simple-purpose random number generation a cast might be safe.. Another thing I have noticed, is that that compared to a cast, to!type is incredibly slow. Most of the time it doesn't matter, but I was doing some work with noise generation, and found that casting the floats to integers was an order of magnitude faster than using to!int. Now I understand that this is about auto-casting, but I thought I'd add the knowledge that to!type is slow, since it does runtime checks on things like range, though I know that it cannot be outside certain ranges. Not that to!type is actually slow in the general case, but the difference is significant when doing on the order of 10^6 casts. -- James Miller
Re: virtual-by-default rant
On 19 March 2012 06:41, David Nadlinger s...@klickverbot.at wrote: On Sunday, 18 March 2012 at 17:24:15 UTC, F i L wrote: […] I know LDC has a LTO flag. Unfortunately it doesn't (-O4/-O5 are defunct), but working on seamless LTO integration (and better optimization pass scheduling in general) would be low-hanging fruit for anybody wanting to join LDC development. David I think that simply adding a `virtual` keyword that explicitly makes things virtual, even if they would otherwise be final, makes sense. Keep all the current semantics the same, relegate use of `virtual` to the 'advanced' section of D usage, everybody is happy. I'm with Manu in the case of I don't trust the compiler. I'm perfectly happy for the compile to optimize short sections of code that I probably could optimize myself, but its not much of an issue, but I am reluctant to rely on the tooling to make decisions for me. For small programs, where it doesn't matter if it's half as fast as it could be, but that just means 2ms vs 1ms, I don't care. But in intensive programs, then I want to be sure that the compiler will do what I want. -- James Miller
Re: Implicit integer casting
Another thing I have noticed, is that that compared to a cast, to!type is incredibly slow. Most of the time it doesn't matter, but I was doing some work with noise generation, and found that casting the floats to integers was an order of magnitude faster than using to!int. There's a check involved, and possibly inlining doesn't make it for whatever reason. Andrei Oh, I wasn't complaining, more just making an observation that the safe to!type is slower than an unsafe cast. Probably obvious, but worth mentioning nonetheless. -- James Miller
