Re: Request for review: std.net.isemail
On 3/22/2011 3:04 PM, Jacob Carlborg wrote: I've now finished the port of Dominic Sayers' PHP is_email function (http://www.dominicsayers.com/isemail) and sending it for review. I think it looks nice. I'd add a note saying it is derived from Dominic's php code, I'd add your name to the copyright for the derived D version. The Link: should be placed under the References: instead. It'll be a valuable addition to Phobos, and a good start on net support.
Re: Managing the review queue
On 2011-03-27 20:53, dsimcha wrote: > From observing the review processes for std.parallelism and > std.net.isemail, I think our review process needs some tweaking. There > are two key issues: > > 1. The pace of reviews is glacial unless there's a vote date near. > Only 4 people have reviewed std.net.isemail, and that's counting any > participation in the discussion as "review". This module doesn't have a > vote date yet. IIRC only two people reviewed std.parallelism during its > first two weeks of review. Furthermore, it took some time after I > requested review for the "official" review period to start. As a > solution all requests for review should come with a tentative vote date > to prevent the module from being held in limbo indefinitely and move the > review queue along. > > 2. Reviews that prompt major changes right before the vote date are > stressful. A looming deadline is not conducive to careful discussion > and consideration of suggestions, especially those that are non-trivial > to understand and/or implement. > > I propose that all review periods last one week for small modules or two > weeks for large modules, subject to extension if the review process is > still yielding good discussion near the vote date or "stashing" if the > author needs time to discuss specific issues that were raised and/or > design and implement changes. When a module is stashed, it is no longer > officially in review and the next item in the review queue, if any, can > begin the process. As soon as this item is done, review of the stashed > item is resumed. Right now, std.parallelism is stashed until > std.net.isemail is finished. > > To prevent the community from being overwhelmed, multiple reviews may > not take place concurrently but a review may take place concurrently > with a vote. Contention for the review queue is an issue in theory, but > that's a problem we'd like to have and can work out on an ad-hoc basis > should it arise. > > More specifically, the pace of reviews for std.net.isemail has been > glacial. If everyone who intends to review it has done so, we should > move on to a vote. If anyone intends to review this module but hasn't > yet, please do so or at least state your intention to do so. Overall, your suggestions are good. Personally, my problem with reviews is that I have enough going on and they take enough time and concentration to do that I end up setting them aside to do later and then have trouble getting around to them. I've been intending to look at both std.parallelism and std.net.isemail (Am I the only one who thinks Ishmael when I see that? LOL), but I've been busy. Shorter review periods are both good and bad, because they force you to take the time to review them rather than putting it off, thereby actually encouraging reviews, but if they're too short, some folks will miss them entirely or not have the time to come up with solid feedback. Overall, I think that what you're suggesting is solid. - Jonathan M Davis
Re: "body" keyword is unnecessary
On 2011-03-27 22:23, Walter Bright wrote: > On 3/23/2011 3:17 PM, Alvaro wrote: > > D already has a long list of keywords, reserved words can't be used as > > identifiers, which can be annoying. "body" in particular is a common noun > > that programmers would gladly use as a variable name in physics > > simulation, astronomy, mechanics, games, health, etc. I think "body" can > > be removed from D with no harm, and with the benefit of allowing the > > name as identifier. > > Body is not strictly necessary to parse it. But it makes for a nice > "anchor" when the in and out clauses get long. > > In any case, we are currently working on getting temp destruction to work > correctly, and after that we'll work on fixing issues with const. I think > these are the most important things we should be working on at the moment. I'll be _very_ excited to have both the destructor issues and the const issues sorted out. They are some of the more annoying quality of implementation issues at the moment. I'm not against body no longer being a keyword if it's reasonable to leave the language as-is, as has been suggested here, and not have body be a keyword, but I have to concur that it's not exactly a high priority issue. However, it's much easier to discuss, which is probably part of the reason that it's being discussed so much. Then again, in many cases at this point, what we need isn't really more suggestions on how to improve the language or libraries but help in implementing improvements. Suggestions are by no means bad, but given everything else that needs doing and how few people there are to do it, suggestions are not likely to be implemented soon, even if they're good. If no one has done so already, this suggestion would be worth creating an enhancement request in bugzilla for, but I'd much rather see other quality of implementation issues fixed rather than have such an enhancement implemented right now. The enhancement is nicely backwards compatible, so it can be done at any point in time later without breaking any code or having to way for a possible D3. - Jonathan M Davis
Re: "body" keyword is unnecessary
On 3/23/2011 3:17 PM, Alvaro wrote: D already has a long list of keywords, reserved words can't be used as identifiers, which can be annoying. "body" in particular is a common noun that programmers would gladly use as a variable name in physics simulation, astronomy, mechanics, games, health, etc. I think "body" can be removed from D with no harm, and with the benefit of allowing the name as identifier. Body is not strictly necessary to parse it. But it makes for a nice "anchor" when the in and out clauses get long. In any case, we are currently working on getting temp destruction to work correctly, and after that we'll work on fixing issues with const. I think these are the most important things we should be working on at the moment.
Re: how to use a lib in d
So what's the point of compiling all those files to a lib if you can't use that lib anymore? Is there some documentation on this?
Managing the review queue
From observing the review processes for std.parallelism and std.net.isemail, I think our review process needs some tweaking. There are two key issues: 1. The pace of reviews is glacial unless there's a vote date near. Only 4 people have reviewed std.net.isemail, and that's counting any participation in the discussion as "review". This module doesn't have a vote date yet. IIRC only two people reviewed std.parallelism during its first two weeks of review. Furthermore, it took some time after I requested review for the "official" review period to start. As a solution all requests for review should come with a tentative vote date to prevent the module from being held in limbo indefinitely and move the review queue along. 2. Reviews that prompt major changes right before the vote date are stressful. A looming deadline is not conducive to careful discussion and consideration of suggestions, especially those that are non-trivial to understand and/or implement. I propose that all review periods last one week for small modules or two weeks for large modules, subject to extension if the review process is still yielding good discussion near the vote date or "stashing" if the author needs time to discuss specific issues that were raised and/or design and implement changes. When a module is stashed, it is no longer officially in review and the next item in the review queue, if any, can begin the process. As soon as this item is done, review of the stashed item is resumed. Right now, std.parallelism is stashed until std.net.isemail is finished. To prevent the community from being overwhelmed, multiple reviews may not take place concurrently but a review may take place concurrently with a vote. Contention for the review queue is an issue in theory, but that's a problem we'd like to have and can work out on an ad-hoc basis should it arise. More specifically, the pace of reviews for std.net.isemail has been glacial. If everyone who intends to review it has done so, we should move on to a vote. If anyone intends to review this module but hasn't yet, please do so or at least state your intention to do so.
Re: i like cakes
On Sun, Mar 27, 2011 at 8:45 PM, Gary Whatmore wrote: > Hello again > > I've stayed quiet for a long time because people started accusing me of > trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME > CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE > HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE > BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY > TROLL! :-( The problem with trolls is that when you do this, they win. No one likes them, but you've just got to learn to ignore them or you just make things worse.
i like cakes
Hello again I've stayed quiet for a long time because people started accusing me of trolling. But now, I REALLY HATE THIS IDIOT IN REDDIT HE IS DRIVING ME CRAZY. ASSHOLE ASSWIPE SHITHOLE LUNATIC. I HATE HIM. BASHING D JUST BECAUSE HE'S SOME MENTALLY ILL PSYCHOPATE WANTING TO KILL ANDREI AND WALTER :-( THE BEST WE CAN DO IS FIND I LIKE CAKES AND DOWNVOTE ALL HIS VOTES. GO AWAY TROLL! :-( - G.W.
[GSOC Draft Proposal] ANTLR and Java based D parser for IDE usage
Sorry for my late draft proposal, I'm currently moving so I didn't have enough time this days. I would be glad to have your opinion. Thank you Rationale - There are different IDEs for the D programming language. The purpose of this project proposal is to write a parser for the D programming language (v1 and v2) that is tailored for IDEs needs. The new parser will be designed to be modular and abstracted from any particular IDE implementation detail, so that it can be used in different IDEs or with tools that need an abstract syntax tree of the source code for further analysis. Particular care will be taken to integrate the new parser with the DDT Eclipse-based IDE so that this project will be useful in the short-term. The DDT project needs a new parser up-to-date with the latest D syntax, with a better error recovery and improved performance. Thanks to this integration it will be possible to understand the appropriate interface for the parser so that in the long-term the same code could be used in different projects. I will use the ANTLR parser generator for this project. This parser generator has been proven to be a valuable tool with advanced features for tree construction and tree manipulations that cuts development time [1]. The LL(*) parsing algorithm on which ANTLR is based upon allows efficient parsing of complex grammar with good error handling and unrestricted grammar actions [2]. The use of a parser generator allows the creations of parsers in different programming languages. This project will focus on the creation of a Java parser. Since ANTLR support many target languages [3], it will not be so difficult to generate a parser in the original implementation language of the IDE. Eg. Generate a C++ parser for the D language that will be used in the IDE written in C++. Furthermore, updates of the D grammar are reflected in a more convenient way through modifications of the ANTLR grammar of D, than through a modification of a hand-written parser. In particular, one of the problems faced by DDT developers was to keep their parser up-to-date with the reference one (DMD parser) [4]. It is time-consuming and error-prone to manually port the DMD parser written in C++ to another language, instead most of the modification will be handled by ANTLR. In addition, easy modification of the D language syntax encourages experimentation for the benefit of the language's evolution. Finally in the process of writing a new parser eventual misunderstanding or inconsistency of the D language reference and documentations will be addressed. A good set of test will be created to guarantee the compatibility of the new parser with the official language definition and the DMD parser. Timeline This is a tentative timeline to be further discussed with the help of the community. I'm committed to dedicate substantially to this project knowing that I also have to pass some exams. I estimate that I could spend initially approximately 25h/week. After the exam session I will work full-time on this project. * April 25 – May 23: Community Bonding Period Since I am new in the D community I will spend some time learning how to contribute while following the guideline of the community and the DDT project. I will start reviewing the language reference asking for clarifications when needed. Once I have got an overall understanding I will write the production rules of the D grammar (v1 and v2) in the ANTLR grammar notation (similar to EBNF). * May 23 – July 11: Developing phase I The correctness of the parser is of paramount importance. I will create many tests to exercise the parser (at this point just a "recognizer") obtained as output from ANTLR. Once I am confident with the parser conforms to the language reference and recognizes the same language as the parser in DMD, I will enhance it with AST construction rules. At this point, I need to discuss with the DDT team the type of AST that has to be built for IDEs purposes, and confirm which annotations are most useful (eg. source ranges). * July 11 – August 15: Developing phase II In this phase I will create unit tests to verify the correctness of the generated trees and I will focus on the integration of the parser with the DDT project. In the remaining time I will provide good error recovery to the parser and I will improve the overall performance. * August 15 - August 22: Final phase I will use this last week to polish the code and improve the documentation. As a final task, I will think about how support for incremental parsing can be added in the future. About me - I am Luca Boasso, I am a computer engineering student of Polytechnic University of Turin [5]. I won a scholarship for a double-degree program and obtained the first master in France under Telecom ParisTech [6] in 2010. After having an internship in Panasonic R&D in Cupertino [7], I am currently finishing my last semester in Italy to re
Re: expression templates
On Sun, 27 Mar 2011 15:46:54 -0400, enuhtac wrote:
Hello everyone,
I'm new to D and to this list (although I've had a look onto D a few
years ago). I hope you guys can help me with my questions.
At the moment I'm trying to implement some expression template stuff. My
first goal is to encode an expression into a type representing that
expression without any additional functionality (like the possibility to
evaluate that expression). Actually this is very simple and short in D.
This is my approach:
struct OpBinary( string Op, R1, R2 )
{
alias typeof( mixin( "R1.EvalT.init" ~ Op ~ "R2.EvalT.init" ) )
EvalT;
enum string Operator = Op;
};
struct Constant( T, T v )
{
alias T EvalT;
enum T value = v;
};
struct Expr( R )
{
auto opBinary( string Op, R2 )( Expr!R2 )
{
return Expr!( OpBinary!( Op, R, R2 ) )();
}
auto opBinary( string Op, T )( T v ) if( isNumeric!T )
{
return Expr!( OpBinary!( Op, R, Constant!( T, v ) ) )();
}
auto opBinaryRight( string Op, T )( T v ) if( isNumeric!T )
{
return Expr!( OpBinary!( Op, Constant!( T, v ), R ) )();
}
};
But I cannot figure out how to implement expression templates for
comparison operators, which is crucial for my purpose. The opCmp
function is great for implementing comparison functionality, but when
building an expression template tree the information on the actual
comparison operator is needed. opCmp just knows that a comparison is
going on, the actual type of comparison is unknown.
What I would like to have is something like this:
auto opCmp( string Op, R2 )( Expr!R2 )
{
return Expr!( OpBinary!( Op, R, R2 ) )();
}
So opCmp knows about the actual operator and would just use my OpBinary
struct to encode it. But this is not possible.
The only workaround for I this problem I can imagine is using my own
comparison functions instead of the comparison operators:
op!"<"( a, b ) instead of a < b.
Another possibility would be to call opBinary explicitly:
a.opCmp!"<"( b )
In this case I would not even have to write additional code.
But these workarounds are ugly, if would greatly prefer the normal
comparison operators.
Does anyone has an idea how to use them?
Regards,
enuhtac
Hmm... I don't know you're use case exactly, but it sounds like a case of
operator overload abuse. The design of opCmp was inspired by the amount of
bug prone repetition that happens with C++ style comparison operators.
Furthermore, both opCmp and opEquals have fixed return types in order to
limit abuse. (D also prevents the overload of certain operators for the
same reason). The main reason behind expression templates is to avoid
costly intermediates, but the expression is always going to be heavier
weight than an int, so why can't you evaluated the expression then and
there?
Re: [GSOC] Database API
On 03/25/2011 09:02 AM, Christian Manning wrote: On 24/03/2011 17:58, Trass3r wrote: Has this idea/project been assigned a mentor? I'd like to ask them and the list, what's the best thing for me to do right now to prepare for this? You could also have a look at http://dsource.org/projects/ddbi This shows some past efforts to create database interfaces. This can be of some inspiration and also brings up a point about how this project would be executed, ie. is this to be part of phobos or a totally separate project? I'm guessing to be Digital Mars supported it's more likely wanted to be a part of phobos, but could someone clarify on this? Either way would be acceptable. Another question about Digital Mars' GSOC involvement: when it's application time do I submit a proposal to someone directly, to this list, or to the GSOC site at http://www.google-melange.com ? You'll submit via Google's interface. See http://d-programming-language.org/gsoc2011.html for details. Submission opens tomorrow. Andrei
A few thoughts on the existing GSoC student proposals
Hello everyone, I've been following with interest the three preliminary proposals made so far: ANTLR grammar by Luca Boasso, containers by Ishan Thilina, Thrift bindings by David Nadlinger aka klickverbot, and database API by Christian Manning. There are many issues to consider when looking over such a project proposal, and there's no quick and easy formula. The considerations include: - Project impact: what would be the impact of the project? What consequences for D's adoption can be expected following the project? - Project's chances of succeeding: what is the assessment that the project can be completed within the timeframe? - Student match: what is the match between the student's initial skill set and the project? - Mentor match: is there a strong mentor for the project? Here are a few considerations regarding the three pre-submission proposals discussed herein: 1. ANTLR grammar for D I think this is a feasible project. My main concern remains the projected impact. If the project is meant to build an ANTLR parser on the off chance that someone will later use it for Eclipse integration or otherwise, then there are serious concerns about the impact. If, on the other hand, the project is focused on Eclipse integration (perhaps starting from an existing similar project) and uses an ANTLR-based parser as a mechanism to achieve that goal, then the impact would be significant. However, there is the concern that the scope of the project might be too large to be finished in time. So I recommend attention in defining the definition and scope of the project when writing the proposal. The fact that we already have a good, supporting mentor in Bruno for an Eclipse project should help a lot. 2. Containers I'd need to hear a lot more about this proposal before making an impression of it. From the little I gathered so far, I think this would be a difficult project to carry through. At this point D's containers need less solid coding but more design. Such design artifacts are most likely to come from an experienced member of the community. Starting from scratch in understanding the issues involved up to the level of making a solid contribution is possible, but difficult. 3. Thrift bindings This is by far the best proposal we have so far. It comes from an established member of the community who has a good understanding of D, and is likely to boost adoption of D at companies that use service-oriented architectures, and Facebook in particular. If the project will be of adequate quality, I should be able to contribute it to the Thrift mainline. The impact could be decisive. 4. Database API This is a high impact item. I'd need to collect more information about the specifics of the application before creating an opinion about its chances of success. I see Piotr and others have some related ideas; I suggest them to apply appropriately (either as mentors or students). A solid mentor(s)/student(s) combo is a key ingredient of a successful project. Thanks, Andrei
Re: Strategies for resolving cyclic dependencies in static ctors
I sounds like we actually agree with each other on all the important points - its just the different starting positions made our near-identical ideas about testing to look different. Thanks for the discussion. -- Graham St Jack
Re: how to use a lib in d
Wow, thank you for the fast reply. Winbase.d is compiled in win32.lib or am i really getting confused? Op 27-mrt.-2011 om 22:25 heeft Jacob Carlborg het volgende geschreven: > On 2011-03-27 22:03, maarten van damme wrote: >> Hello everyone, >> I've succesfully compiled the win32.lib file from the bindings project. >> For a fun little project I need to call the windows function >> "writeprocessmemory/readprocessmemory" in winbase.d . >> I loved to use the eclipse ide to use with it but I kept getting the >> same error over and over again so I installed the entice ide. >> This gave more control over the compile command. But the error persisted. >> >> /"Error module winbase is in file win32/winbase.d which cannot be found..."/ >> The contents of the file I'm trying to compile: >> >> /"pragma(lib,"win32.lib");/ >> / >> / >> /import win32.winbase;"/ >> >> The compile command is: >> /"dmd.exe common.d main.d win32.lib -ofediting.exe -inline -O -release >> -w -version=Unicode -version=WindowsVista"/ >> / >> / >> So it looks as if the modules from win32.lib do not get used when I try >> to import. >> >> Thanks in advance, >> Maarten > > Seems the compiler can't find win32.winbase. Add this to compile command: > > -I/path/to/parent_of_win32 > > Example: > > say that winbase.d is located at: > > C:\d\imports\win32\winbase.d > > Then add this to the command: > > -IC:\d\imports > > -- > /Jacob Carlborg
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
Congratulations! :) On 3/27/11, Ary Manzana wrote: > On 3/27/11 3:57 PM, Andrei Alexandrescu wrote: >> Bruno Medeiros from Google has been accepted as a mentor for the Google >> Summer of Code 2011 program for Digital Mars. >> >> Please join me in congratulating and wishing the best to Bruno. >> >> We have three mentors and two pending applications. We are always >> looking for mentor and student applications. Please refer to this page >> for how to apply: >> >> http://d-programming-language.org/gsoc2011.html >> >> >> Andrei > > Yeah! Congratulations, Bruno! >
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
On 3/27/11 3:57 PM, Andrei Alexandrescu wrote: Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. We have three mentors and two pending applications. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Andrei Yeah! Congratulations, Bruno!
Re: CTFE Overhaul (Was: RFC: Thrift project proposal (draft))
On 2011-03-27 08:41, Robert Jacques wrote: > On Sun, 27 Mar 2011 06:06:48 -0400, Jacob Carlborg wrote: > > On 2011-03-26 21:16, Don wrote: > >> dsimcha wrote: > >>> On 3/26/2011 12:16 PM, Don wrote: > I'm giving CTFE a *major* overhaul right now. I don't know if I'll be > finished in time for the next compiler release, but definitely by the > release after that. Most importantly, bug 1330, which is the root > cause > of almost all of the problems, will be fixed. I hope to move CTFE out > the "experimental feature" category. > >>> > >>> This is great news, I'm looking forward to it. Thanks for the hard > >>> work. Out of curiosity, can you give a brief overview of what new > >>> things CTFE will be usable for? > >> > >> The basic problem with the current implementation of CTFE is that it > >> uses copy-on-write. This means that references (including dynamic > >> arrays) don't work properly -- they just copy a snapshot of the thing > >> they are referencing. This is bug 1330. It also means it burns up memory > >> like you wouldn't believe. > >> > >> I'm changing CTFE to use in-place modification. This fixes all those > >> issues. But this is obviously a fairly intense change, and will take > >> quite a lot of time to iron out all the corner cases. So that's all I'm > >> planning on doing right now. > >> > >> But once that's done, it will be straightforward to implement other > >> reference types, such as classes and pointers (pointer arithmetic will > >> be restricted to pointers which point to array members). Once classes > >> are implemented, it's straightforward to do exceptions. So, pretty much > >> everything. > >> > >> I've been planning on doing this for over a year, but while Walter was > >> working on 64-bit, I felt that I was the only one working on the > >> showstopper wrong-code bugs and regressions, so I put this > >> important-but-not-urgent stuff aside. > > > > Will the time it takes to compile heavy uses of CTFE be affected by this > > (positive or negative)? > > Any string heavy CTFE should see a major improvement in performance. Yeah. Considering how memory-heavy CTFE tends to be, I'd expect that such a massive drop in memory consumption would almost always result in a performance improvement. However, we could end up being surprised with how it actually performs, since how the performance characteristics of an application change as you change it can sometimes be very surprising. I would generally expect it to improve performance though, not harm it. And it should definitely make some CTFE which currently fails due to a lack of memory actually work. - Jonathan M Davis
Re: Curl support RFC
On 25/03/11 12.07, Johannes Pfau wrote:
Johannes Pfau wrote:
Jonas Drewsen wrote:
Hi,
So I've been working a bit on the etc.curl module. Currently most
of
the HTTP functionality is done and some very simple Ftp.
I would very much like to know if this has a chance of getting in
phobos if I finish it with the current design. If not then it will be
for my own project only and doesn't need as much documentation or all
the features.
https://github.com/jcd/phobos/tree/curl
I do know that the error handling is currently not good enough... WIP.
/Jonas
On 11/03/11 16.20, Jonas Drewsen wrote:
Hi,
So I've spent some time trying to wrap libcurl for D. There is a lot
of things that you can do with libcurl which I did not know so I'm
starting out small.
For now I've created all the declarations for the latest public curl
C api. I have put that in the etc.c.curl module.
On top of that I've created a more D like api as seen below. This is
located in the 'etc.curl' module. What you can see below currently
works but before proceeding further down this road I would like to
get your comments on it.
//
// Simple HTTP GET with sane defaults
// provides the .content, .headers and .status
//
writeln( Http.get("http://www.google.com";).content );
//
// GET with custom data receiver delegates
//
Http http = new Http("http://www.google.dk";);
http.setReceiveHeaderCallback( (string key, string value) {
writeln(key ~ ":" ~ value);
} );
http.setReceiveCallback( (string data) { /* drop */ } );
http.perform;
//
// POST with some timouts
//
http.setUrl("http://www.testing.com/test.cgi";);
http.setReceiveCallback( (string data) { writeln(data); } );
http.setConnectTimeout(1000);
http.setDataTimeout(1000);
http.setDnsTimeout(1000);
http.setPostData("The quick");
http.perform;
//
// PUT with data sender delegate
//
string msg = "Hello world";
size_t len = msg.length; /* using chuncked transfer if omitted */
http.setSendCallback( delegate size_t(char[] data) {
if (msg.empty) return 0;
auto l = msg.length;
data[0..l] = msg[0..$];
msg.length = 0;
return l;
},
HttpMethod.put, len );
http.perform;
//
// HTTPS
//
writeln(Http.get("https://mail.google.com";).content);
//
// FTP
//
writeln(Ftp.get("ftp://ftp.digitalmars.com/sieve.ds";,
"./downloaded-file"));
// ... authenication, cookies, interface select, progress callback
// etc. is also implemented this way.
/Jonas
I looked at the code again and I got 2 more suggestions:
1.) Would it be useful to have a headersReceived callback which would
be called when all headers have been received (when the data callback
is called the first time)? I think of a situation where you don't know
what data the server will return: a few KB html which you can easily
keep in memory or a huge file which you'd have to save to disk. You
can only know that if the headers have been received. It would also be
possible to do that by just overwriting the headerCallback and looking
out for the ContentLength/ContentType header, but I think it should
also work with the default headerCallback.
2.)
As far as I can see you store the http headers in a case sensitive way.
(res.headers[key] ~= value;). This means "Content-Length" vs
"content-length" would produce two entries in the array and it makes
it difficult to get the header from the associative array. It is maybe
useful to keep the original casing, but probably not in the array key.
BTW: According to RFC2616 the only headers which are allowed
to be included multiple times in the response must consist of comma
separated lists. So in theory we could keep a simple string[string]
list and if we see a header twice we can just merge it with a ','.
http://tools.ietf.org/html/rfc2616#section-4.2
Relevant part from the RFC:
--
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of
the message, by appending each subsequent field-value to the first,
each separated by a comma. The order in which header fields with the
same field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST
NOT change the order of these field values when a message is
forwarded.
--
I'm also done with the first pass through the http parsers.
Documentation is here:
http://dl.dropbox.com/u/24218791/std.protocol.http/http/http.html
Code here:
https://gist.github.com/886612
The http.d file is generated from the http.d.rl file.
I added some code to show how I think this could be used in the HTTP
client:
https://gist.github.com/886612#file_gistfile1.d
Like in the .net webclient we'd need two of these collections: one for
received headers and one for headers to be sent.
Thanks!
It wou
Re: Curl support RFC
On 25/03/11 10.54, Johannes Pfau wrote:
Jonas Drewsen wrote:
Hi,
So I've been working a bit on the etc.curl module. Currently most
of
the HTTP functionality is done and some very simple Ftp.
I would very much like to know if this has a chance of getting in
phobos if I finish it with the current design. If not then it will be
for my own project only and doesn't need as much documentation or all
the features.
https://github.com/jcd/phobos/tree/curl
I do know that the error handling is currently not good enough... WIP.
/Jonas
On 11/03/11 16.20, Jonas Drewsen wrote:
Hi,
So I've spent some time trying to wrap libcurl for D. There is a lot
of things that you can do with libcurl which I did not know so I'm
starting out small.
For now I've created all the declarations for the latest public curl
C api. I have put that in the etc.c.curl module.
On top of that I've created a more D like api as seen below. This is
located in the 'etc.curl' module. What you can see below currently
works but before proceeding further down this road I would like to
get your comments on it.
//
// Simple HTTP GET with sane defaults
// provides the .content, .headers and .status
//
writeln( Http.get("http://www.google.com";).content );
//
// GET with custom data receiver delegates
//
Http http = new Http("http://www.google.dk";);
http.setReceiveHeaderCallback( (string key, string value) {
writeln(key ~ ":" ~ value);
} );
http.setReceiveCallback( (string data) { /* drop */ } );
http.perform;
//
// POST with some timouts
//
http.setUrl("http://www.testing.com/test.cgi";);
http.setReceiveCallback( (string data) { writeln(data); } );
http.setConnectTimeout(1000);
http.setDataTimeout(1000);
http.setDnsTimeout(1000);
http.setPostData("The quick");
http.perform;
//
// PUT with data sender delegate
//
string msg = "Hello world";
size_t len = msg.length; /* using chuncked transfer if omitted */
http.setSendCallback( delegate size_t(char[] data) {
if (msg.empty) return 0;
auto l = msg.length;
data[0..l] = msg[0..$];
msg.length = 0;
return l;
},
HttpMethod.put, len );
http.perform;
//
// HTTPS
//
writeln(Http.get("https://mail.google.com";).content);
//
// FTP
//
writeln(Ftp.get("ftp://ftp.digitalmars.com/sieve.ds";,
"./downloaded-file"));
// ... authenication, cookies, interface select, progress callback
// etc. is also implemented this way.
/Jonas
I looked at the code again and I got 2 more suggestions:
1.) Would it be useful to have a headersReceived callback which would be
called when all headers have been received (when the data callback is
called the first time)? I think of a situation where you don't know
what data the server will return: a few KB html which you can easily
keep in memory or a huge file which you'd have to save to disk. You
can only know that if the headers have been received. It would also be
possible to do that by just overwriting the headerCallback and looking
out for the ContentLength/ContentType header, but I think it should
also work with the default headerCallback.
I'm a little confused as to what a headersReceived(string[string]
headers) would give you compared to the onReceiveHeader(const(char)[],
const(char)[])) callback that exists today in the example.
The headersReceived callback would probably lookup the content-length
header and set a flag about whether to save content to file or memory.
The existing onReceiveHeader could do the same by setting the flag when
it receives the content-length field.
Or maybe I'm misunderstanding you?
2.)
As far as I can see you store the http headers in a case sensitive way.
(res.headers[key] ~= value;). This means "Content-Length" vs
"content-length" would produce two entries in the array and it makes
it difficult to get the header from the associative array. It is maybe
useful to keep the original casing, but probably not in the array key.
BTW: According to RFC2616 the only headers which are allowed
to be included multiple times in the response must consist of comma
separated lists. So in theory we could keep a simple string[string]
list and if we see a header twice we can just merge it with a ','.
http://tools.ietf.org/html/rfc2616#section-4.2
Relevant part from the RFC:
--
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.
--
I will surely i
Re: how to use a lib in d
On 2011-03-27 22:03, maarten van damme wrote: Hello everyone, I've succesfully compiled the win32.lib file from the bindings project. For a fun little project I need to call the windows function "writeprocessmemory/readprocessmemory" in winbase.d . I loved to use the eclipse ide to use with it but I kept getting the same error over and over again so I installed the entice ide. This gave more control over the compile command. But the error persisted. /"Error module winbase is in file win32/winbase.d which cannot be found..."/ The contents of the file I'm trying to compile: /"pragma(lib,"win32.lib");/ / / /import win32.winbase;"/ The compile command is: /"dmd.exe common.d main.d win32.lib -ofediting.exe -inline -O -release -w -version=Unicode -version=WindowsVista"/ / / So it looks as if the modules from win32.lib do not get used when I try to import. Thanks in advance, Maarten Seems the compiler can't find win32.winbase. Add this to compile command: -I/path/to/parent_of_win32 Example: say that winbase.d is located at: C:\d\imports\win32\winbase.d Then add this to the command: -IC:\d\imports -- /Jacob Carlborg
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
On 3/27/2011 11:57 AM, Andrei Alexandrescu wrote: Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. Yay Bruno!
Re: GCC 4.6
Walter: > On 3/27/2011 7:30 AM, bearophile wrote: > > In Bugzilla I have proposed that if you call a pure function and you don't > > assign its return value, then you have a bug, like the similar present in D > > for unassigned expressions. > > I think that's a reasonable proposal. :-) Thank you. This is the enhancement request (about one year old): http://d.puremagic.com/issues/show_bug.cgi?id=3882 Bye, bearophile
Re: how to use a lib in d
win32.lib doesn't have any modules, it only has binary code. You need to add an import switch and the location of the win32 project folder. E.g. if you have: C:\win32\win32\winbase.d Then you would add "-IC:\win32\", and the compiler will look for winbase inside the win32 subfolder. So your compile command would look like: "dmd.exe common.d main.d win32.lib -IC:\win32\ -ofediting.exe -inline -O -release -w -version=Unicode -version=WindowsVista" There should be a list of imports you can set in Eclipse, I believe. It is an IDE after all.
Re: CTFE Overhaul (Was: RFC: Thrift project proposal (draft))
I remember a few months ago I've tried using CTFE and import
expressions to load a .def file and generate at compile-time a runtime
DLL loading mechanism in a class which would load a DLL file and
create wrapper functions for DLL functions. It would also add
try{}catch{} blocks based on a naming scheme and if -debug was
enabled. But I've had some big issues with string handling at
compile-time.
I'm not sure if I was doing something wrong or if CTFE was just
inadequate at the time (I do remember having some trouble using
foreach loops and some unfriendly CTFE error messages). I'll give it
another shoot soon. Anyhow, its great seeing someone working to
improve CTFE. Thanks, Don!
expression templates
Hello everyone,
I'm new to D and to this list (although I've had a look onto D a few years
ago). I hope you guys can help me with my questions.
At the moment I'm trying to implement some expression template stuff. My first
goal is to encode an expression into a type representing that expression
without any additional functionality (like the possibility to evaluate that
expression). Actually this is very simple and short in D. This is my approach:
struct OpBinary( string Op, R1, R2 )
{
alias typeof( mixin( "R1.EvalT.init" ~ Op ~ "R2.EvalT.init" ) ) EvalT;
enum string Operator = Op;
};
struct Constant( T, T v )
{
alias T EvalT;
enum T value = v;
};
struct Expr( R )
{
auto opBinary( string Op, R2 )( Expr!R2 )
{
return Expr!( OpBinary!( Op, R, R2 ) )();
}
auto opBinary( string Op, T )( T v ) if( isNumeric!T )
{
return Expr!( OpBinary!( Op, R, Constant!( T, v ) ) )();
}
auto opBinaryRight( string Op, T )( T v ) if( isNumeric!T )
{
return Expr!( OpBinary!( Op, Constant!( T, v ), R ) )();
}
};
But I cannot figure out how to implement expression templates for comparison
operators, which is crucial for my purpose. The opCmp function is great for
implementing comparison functionality, but when building an expression template
tree the information on the actual comparison operator is needed. opCmp just
knows that a comparison is going on, the actual type of comparison is unknown.
What I would like to have is something like this:
auto opCmp( string Op, R2 )( Expr!R2 )
{
return Expr!( OpBinary!( Op, R, R2 ) )();
}
So opCmp knows about the actual operator and would just use my OpBinary struct
to encode it. But this is not possible.
The only workaround for I this problem I can imagine is using my own comparison
functions instead of the comparison operators:
op!"<"( a, b ) instead of a < b.
Another possibility would be to call opBinary explicitly:
a.opCmp!"<"( b )
In this case I would not even have to write additional code.
But these workarounds are ugly, if would greatly prefer the normal comparison
operators.
Does anyone has an idea how to use them?
Regards,
enuhtac
how to use a lib in d
Hello everyone, I've succesfully compiled the win32.lib file from the bindings project. For a fun little project I need to call the windows function "writeprocessmemory/readprocessmemory" in winbase.d . I loved to use the eclipse ide to use with it but I kept getting the same error over and over again so I installed the entice ide. This gave more control over the compile command. But the error persisted. *"Error module winbase is in file win32/winbase.d which cannot be found..."* The contents of the file I'm trying to compile: *"pragma(lib,"win32.lib");* * * *import win32.winbase;"* The compile command is: *"dmd.exe common.d main.d win32.lib -ofediting.exe -inline -O -release -w -version=Unicode -version=WindowsVista"* * * So it looks as if the modules from win32.lib do not get used when I try to import. Thanks in advance, Maarten
Re: GCC 4.6
On 3/27/2011 7:30 AM, bearophile wrote: In Bugzilla I have proposed that if you call a pure function and you don't assign its return value, then you have a bug, like the similar present in D for unassigned expressions. I think that's a reasonable proposal.
Re: CTFE Overhaul (Was: RFC: Thrift project proposal (draft))
Robert Jacques wrote: On Sun, 27 Mar 2011 08:36:39 -0400, spir wrote: On 03/26/2011 09:57 PM, Don wrote: The basic problem with the current implementation of CTFE is that it uses copy-on-write. This means that references (including dynamic arrays) don't work properly -- they just copy a snapshot of the thing they are referencing. This is bug 1330. It also means it burns up memory like you wouldn't believe. Right. IIUC there's also no way to free the memory from copies that are no longer referenced. I can see where this would leak memory like a sieve. That's not the big problem, actually. The issue is that x[7]=6; duplicates x, even if x has 10K elements. Now consider: for(int i=0; i Hello Don, I don't understand your point. I have once implemented a toy dynamic language, using the common trick of boxed elements (à la Lisp). But I wanted to maintain value semantics as standard. A cheap way to do that is copy on write; it is actually cheap since simple, atomic, elements are never copied (since they cannot be changed on place), thus one just just needs to trace complex elements (array-lists & named tuples in my case): x := [1,2,3]// create the array value, assign its ref y := x// copy the ref, mark the value as shared x[1] := 0// copy the value, reassign the ref, then change But the new value is not shared, thus: x[1] := 1// change only So that in your loop example, at most one array copy happens (iff it was shared). This is as far as I know what is commonly called copy-on-write. There is no need to copy the value over and over again on every change if it is not multiple-referenced, and noone does that, I guess. Side-Note: assignments of the form of "y := x" are really special, at least conceptually; but also practically when pointers or refs enter the game. I call them "symbol assignments" as the source is a symbol. Denis Hi Denis, What Don is explaining is not how you should implement copy-on-write, etc., but the actual implementation of arrays in DMD's CTFE system. Exactly. Right now, any access to an array in CTFE causes the entire array to be duplicated, which is a major memory and performance issue, to say nothing of the fact that D arrays are supposed to have reference, not value semantics. I don't know how or why this behavior was ever introduced, only that it is awesome that Don is fixing it. I believe it was a quick hack to get things working. But it needs to disappear.
D's GSoC now on reddit
Discuss and upvote! http://www.reddit.com/r/programming/comments/gcmj1/digital_mars_aka_the_d_programming_language/ Andrei
Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. We have three mentors and two pending applications. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Andrei
Re: GSoC-2011 project:: Containers
Ishan Thilina wrote: > As to my understanding algorithms are seperated from the containers so > that the code is maintainable. But in std.container I can see that all the > algorithms are in the container method definitions. Why is this? Have I > got the things incorrectly? Slightly, D ranges use the same basic principles as the STL so any documentation on that can be used to understand the big picture. You'll see that no container implements all of std.algorithm, in fact containers have a very small interface. Normally algorithms work with different kinds of ranges and containers can provide one or more ranges, thus achieving very loose coupling and reuse. If a container provides a certain range then *all* algorithms which operate on that kind of range will work with the container. For example, any container that can be accessed with a random access range can be used by std.sort. However, containers usually have more to offer than what can be expressed by ranges. std.container documents a large set of methods that particular containers can implement as they see fit, as a convention. These methods are usually specific to a particular container implementation and necessary to use a container or take advantage of it's specific properties.
Re: [GSoC] RFC: Thrift project proposal (draft)
On 03/27/2011 12:25 AM, Don wrote: Andrei Alexandrescu wrote: On 3/26/11 3:01 PM, Don wrote: David Nadlinger wrote: On 3/26/11 5:16 PM, Don wrote: I'm giving CTFE a *major* overhaul right now. I don't know if I'll be finished in time for the next compiler release, but definitely by the release after that. Most importantly, bug 1330, which is the root cause of almost all of the problems, will be fixed. I hope to move CTFE out the "experimental feature" category. That's great news – do you plan to put your work in progress up at GitHub somewhere before the official release? Yes, definitely. All my fixes go into my fork of dmd on github. My CTFE work is progressing quite well. Simple test cases like the one in bug 1330 are working (and all the existing tests still pass, of course). It will be a while before I publish it to github, though -- the code is VERY untidy, and lots of stuff isn't implemented yet. I'm playing around with CTFE quite a bit at the moment and plan to have a stab at making the basic parts of std.algorithm CTFE-able soon (Steve, did you find time to look at the Appender issue yet?), so I'd be glad to test any improvements… My changes will make a *lot* more things work in CTFE. I recommend against spending much time making things CTFE-able right now. This is absolutely awesome. Compile-time evaluation is a key strategic feature of D. Thank you! Two questions - do you plan to allow class object creation a la new Widget? Eventually. That requires some form of class literal to be created inside the compiler, so it's a bit more work. Sounds great. Most of the advanced CTFE applications that I'm thinking of involve referential data types. Right now only arrays offer that in CTFE space, which is quite limiting. Andrei
Re: Proposal: Thread-sealed containers
On 03/26/2011 05:26 PM, dsimcha wrote: I'm thinking about ways to make std.concurrency's model more flexible without compromising safety. It's sometimes useful to cheaply _move_ (as opposed to share or copy) data between threads. I wonder if we could co-opt sealed containers here: 1. Define basic data structures like arrays, hash tables and trees that are otherwise identical to sealed containers, but maintain a _thread-specific_ reference count. This can be naively implemented as a hash table with Thread keys and size_t values, but there's probably a better way. Provisionally call these "thread-sealed containers". A thread-sealed container has the invariant that no two thread-specific reference counts may be simultaneously nonzero. If this becomes untrue, an Error is thrown at runtime. This is not as good as a compile time error, but it's much better than a low-level data race. 2. Restrict the contents of thread-sealed containers to types that can be safely shared/moved between threads: Primitives, shared and immutable data, and other thread-sealed containers. 3. Define a std.concurrency.moveSend() function. This function takes a thread-sealed container by reference, decrements the sending thread's reference count, enforces that it's zero, then sends the container as a message to the receiving thread. The receiving thread increments its reference count of the container. Sounds like a good idea. Given the restriction, instead of one reference count per thread you only need a pair threadid + refcount. Then the refcounts of all other threads are implicitly zero. Andrei
Re: GSoC-2011 project:: Containers
As to my understanding algorithms are seperated from the containers so that the code is maintainable. But in std.container I can see that all the algorithms are in the container method definitions. Why is this? Have I got the things incorrectly?
Re: constexpr and CTFE
bearophile wrote: > This first question is mostly for D.learn, but below I show a partially > related link too, so I put both of them here. > > If you have library code, and the users of your library run one of your > functions at compile time, later if you change your function it may not > run at compile time any more. So isn't the quality of being able to run at > compile time part of the signature of the function? An attribute similar to pure that can be checked by the compiler might be useful. However, the signature affects the type right? I'm not sure that is the intent of ctfe. A simple ddoc annotation and a unittest is probably enough to both ensure and convey the ctfe-ability. > --- > > GCC 4.6 implements the C++0x constexpr. I've found a note about constexpr, > that touches the topic of logic const too, purity, memoization: > > http://stackoverflow.com/questions/4748083/when-should-you-use-constexpr- capability-in-c0x/4750253#4750253 > > Bye, > bearophile
Re: GCC 4.6
KennyTM~: > This should be restricted to *strongly* pure functions. Right, I have added the note. I have written the enhancement request 3882 before the introduction of the weakly pure ones. Bye, bearophile
Re: CTFE Overhaul (Was: RFC: Thrift project proposal (draft))
On Sun, 27 Mar 2011 06:06:48 -0400, Jacob Carlborg wrote: On 2011-03-26 21:16, Don wrote: dsimcha wrote: On 3/26/2011 12:16 PM, Don wrote: I'm giving CTFE a *major* overhaul right now. I don't know if I'll be finished in time for the next compiler release, but definitely by the release after that. Most importantly, bug 1330, which is the root cause of almost all of the problems, will be fixed. I hope to move CTFE out the "experimental feature" category. This is great news, I'm looking forward to it. Thanks for the hard work. Out of curiosity, can you give a brief overview of what new things CTFE will be usable for? The basic problem with the current implementation of CTFE is that it uses copy-on-write. This means that references (including dynamic arrays) don't work properly -- they just copy a snapshot of the thing they are referencing. This is bug 1330. It also means it burns up memory like you wouldn't believe. I'm changing CTFE to use in-place modification. This fixes all those issues. But this is obviously a fairly intense change, and will take quite a lot of time to iron out all the corner cases. So that's all I'm planning on doing right now. But once that's done, it will be straightforward to implement other reference types, such as classes and pointers (pointer arithmetic will be restricted to pointers which point to array members). Once classes are implemented, it's straightforward to do exceptions. So, pretty much everything. I've been planning on doing this for over a year, but while Walter was working on 64-bit, I felt that I was the only one working on the showstopper wrong-code bugs and regressions, so I put this important-but-not-urgent stuff aside. Will the time it takes to compile heavy uses of CTFE be affected by this (positive or negative)? Any string heavy CTFE should see a major improvement in performance.
Re: CTFE Overhaul (Was: RFC: Thrift project proposal (draft))
On Sun, 27 Mar 2011 08:36:39 -0400, spir wrote: On 03/26/2011 09:57 PM, Don wrote: The basic problem with the current implementation of CTFE is that it uses copy-on-write. This means that references (including dynamic arrays) don't work properly -- they just copy a snapshot of the thing they are referencing. This is bug 1330. It also means it burns up memory like you wouldn't believe. Right. IIUC there's also no way to free the memory from copies that are no longer referenced. I can see where this would leak memory like a sieve. That's not the big problem, actually. The issue is that x[7]=6; duplicates x, even if x has 10K elements. Now consider: for(int i=0; i Hello Don, I don't understand your point. I have once implemented a toy dynamic language, using the common trick of boxed elements (à la Lisp). But I wanted to maintain value semantics as standard. A cheap way to do that is copy on write; it is actually cheap since simple, atomic, elements are never copied (since they cannot be changed on place), thus one just just needs to trace complex elements (array-lists & named tuples in my case): x := [1,2,3]// create the array value, assign its ref y := x // copy the ref, mark the value as shared x[1] := 0 // copy the value, reassign the ref, then change But the new value is not shared, thus: x[1] := 1 // change only So that in your loop example, at most one array copy happens (iff it was shared). This is as far as I know what is commonly called copy-on-write. There is no need to copy the value over and over again on every change if it is not multiple-referenced, and noone does that, I guess. Side-Note: assignments of the form of "y := x" are really special, at least conceptually; but also practically when pointers or refs enter the game. I call them "symbol assignments" as the source is a symbol. Denis Hi Denis, What Don is explaining is not how you should implement copy-on-write, etc., but the actual implementation of arrays in DMD's CTFE system. Right now, any access to an array in CTFE causes the entire array to be duplicated, which is a major memory and performance issue, to say nothing of the fact that D arrays are supposed to have reference, not value semantics. I don't know how or why this behavior was ever introduced, only that it is awesome that Don is fixing it.
Re: GCC 4.6
== Quote from bearophile (bearophileh...@lycos.com)'s article
> Iain Buclaw:
> > I think it would be better if it were targeting
> > memory/(re)allocation-related
> > functions.
> >
> > ie:
> > {
> > new int[4096]; // allocation has no effect, other than leaking memory.
> > }
> (The memory does not leak, the GC will deallocate it later).
Assuming you are using the stock implementation that comes bundled with
Druntime,
and not some stub implementation or freestanding environment. :~)
Re: GCC 4.6
On Mar 27, 11 23:19, KennyTM~ wrote:
On Mar 27, 11 22:30, bearophile wrote:
In Bugzilla I have proposed that if you call a pure function and you
don't assign its return value, then you have a bug, like the similar
present in D for unassigned expressions.
This should be restricted to *strongly* pure functions. Weakly pure
functions may have its major effect sent out via the input arguments, so
ignoring the return value could make sense.
import std.stdio;
pure double[] set(double[] x, int index, double e) {
x[index] = e;
return x;
}
void main () {
auto j = new double[](3);
j.set(0, 1.5).set(1, 2.5).set(2, 5.1);
writeln(j);
}
BTW, which Bugzilla entry you are talking about?
OK, I see it is 3882.
http://d.puremagic.com/issues/show_bug.cgi?id=3882
Re: GCC 4.6
On Mar 27, 11 22:30, bearophile wrote:
In Bugzilla I have proposed that if you call a pure function and you don't
assign its return value, then you have a bug, like the similar present in D for
unassigned expressions.
This should be restricted to *strongly* pure functions. Weakly pure
functions may have its major effect sent out via the input arguments, so
ignoring the return value could make sense.
import std.stdio;
pure double[] set(double[] x, int index, double e) {
x[index] = e;
return x;
}
void main () {
auto j = new double[](3);
j.set(0, 1.5).set(1, 2.5).set(2, 5.1);
writeln(j);
}
BTW, which Bugzilla entry you are talking about?
Re: import error and error types
spir: > * The message is wrong: the error is precisely due to the fact no file > 'algorithm.d' was found. The D compilers need to produce good error messages. So I suggest you to perform a search in Bugzilla, if you don't find your problem there (I have a related bug there), then add a new Bugzilla entry. Bye, bearophile
constexpr and CTFE
This first question is mostly for D.learn, but below I show a partially related link too, so I put both of them here. If you have library code, and the users of your library run one of your functions at compile time, later if you change your function it may not run at compile time any more. So isn't the quality of being able to run at compile time part of the signature of the function? --- GCC 4.6 implements the C++0x constexpr. I've found a note about constexpr, that touches the topic of logic const too, purity, memoization: http://stackoverflow.com/questions/4748083/when-should-you-use-constexpr-capability-in-c0x/4750253#4750253 Bye, bearophile
Re: GCC 4.6
Iain Buclaw:
> I think it would be better if it were targeting memory/(re)allocation-related
> functions.
>
> ie:
> {
> new int[4096]; // allocation has no effect, other than leaking memory.
> }
(The memory does not leak, the GC will deallocate it later).
In Bugzilla I have proposed that if you call a pure function and you don't
assign its return value, then you have a bug, like the similar present in D for
unassigned expressions.
If the druntime function to allocate a new array is a pure function, then my
enhancement request catches your bug too :-)
Bye,
bearophile
Re: GCC 4.6
> test.d(4): Error: + has no effect in expression (x + y)
> But currently this gives no errors, despite it's the same situation, so I'd
> like
an error here too (this enhancement request is in Bugzilla already):
> pure int add(int a, int b) { return a + b; }
> void main() {
> int x = 10;
> int y = 20;
> add(x, y);
> }
I think it would be better if it were targeting memory/(re)allocation-related
functions.
ie:
{
new int[4096]; // allocation has no effect, other than leaking memory.
}
Re: GCC 4.6
== Quote from bearophile (bearophileh...@lycos.com)'s article > Walter: > > You quoted a claim saying it was also an optimization. > If GCC devs say so, then I presume they are right. But the main purpose of a warning is to warn the programmer, in this case to avoid some bugs. Warnings have no effect on optimisations. And unused code are later removed via general dead code elimination anyway (how aggressive this is depends on the optimisation level).
import error and error types
Hello, "import algorithm;" generates the error message: test.d(35): Error: module algorithm is in file 'algorithm.d' which cannot be read Three notes: * The message is wrong: the error is precisely due to the fact no file 'algorithm.d' was found. * A nice tip for phobos modules would be to hint "Did you forget the prefix 'std.'?". * There is no mention of import, which would be helpful ;-) More generally, dmd (and build/link) errors have no "type". Giving errors a written type is very helpful (not only to the user, also to organise, name, and formulates error messages properly). test.d(35): Import Error: cannot find module file 'algorithm.d' (in current directory or standard import directories). Did you forget the prefix 'std.' needed to import Phobos modules? (The additional tip only when module name matches a phobos module name.) Denis -- _ vita es estrany spir.wikidot.com
Re: Proposal: Thread-sealed containers
On 3/27/2011 2:47 AM, Jason House wrote: dsimcha Wrote: I'm thinking about ways to make std.concurrency's model more flexible without compromising safety. It's sometimes useful to cheaply _move_ (as opposed to share or copy) data between threads. I wonder if we could co-opt sealed containers here: What definition of sealed are you using? A quick web search mostly brought up C#'s sealed keyword which I think is the same as D's final. I vaguely remember Andrei might have used the term to mean no aliases to the data held by the container? I was using Andrei's definition that had been floated around here previously. For those not already familiar, a sealed container is one where references/pointers to the elements cannot be obtained. This allows things like reference-counted memory management to be done safely. 1. Define basic data structures like arrays, hash tables and trees that are otherwise identical to sealed containers, but maintain a _thread-specific_ reference count. This can be naively implemented as a hash table with Thread keys and size_t values, but there's probably a better way. Provisionally call these "thread-sealed containers". It might be possible to simply store the owning thread id. Since the thread that sent the container will still have a reference to it, you may be forced to do some extra runtime checks on every method call anyway... 3. Define a std.concurrency.moveSend() function. This function takes a thread-sealed container by reference, decrements the sending thread's reference count, enforces that it's zero, then sends the container as a message to the receiving thread. The receiving thread increments its reference count of the container. I like that you're thinking about this kind of stuff. I am over tired right now and haven't really thought this through, but it feels like this could lead to a major safety upgrade for std.concurrency. Now that I think about it some more, we don't need explicit thread-specific reference counts. All we need to prove is that we're dealing with a unique reference, i.e. that the reference count is 1. moveSend() then clears the sending thread's view of the container so that the sending thread no longer has access to it and sends it as a message to the receiving thread. The receiving thread is the new owner. The bottom line concept is that uniqueness is useful but difficult to prove statically. (To refresh people's memory uniqueness in this context means that a piece of data only has one pointer/reference pointing to it.) Static solutions will always be conservative and risk making the type system absurdly complex. Therefore, enforce uniqueness at runtime when it can be determined exactly via reference counting. The same principle may solve the problem of immutable data creation.
Re: CTFE Overhaul (Was: RFC: Thrift project proposal (draft))
On 03/26/2011 09:57 PM, Don wrote: The basic problem with the current implementation of CTFE is that it uses copy-on-write. This means that references (including dynamic arrays) don't work properly -- they just copy a snapshot of the thing they are referencing. This is bug 1330. It also means it burns up memory like you wouldn't believe. Right. IIUC there's also no way to free the memory from copies that are no longer referenced. I can see where this would leak memory like a sieve. That's not the big problem, actually. The issue is that x[7]=6; duplicates x, even if x has 10K elements. Now consider: for(int i=0; i Hello Don, I don't understand your point. I have once implemented a toy dynamic language, using the common trick of boxed elements (à la Lisp). But I wanted to maintain value semantics as standard. A cheap way to do that is copy on write; it is actually cheap since simple, atomic, elements are never copied (since they cannot be changed on place), thus one just just needs to trace complex elements (array-lists & named tuples in my case): x := [1,2,3]// create the array value, assign its ref y := x // copy the ref, mark the value as shared x[1] := 0 // copy the value, reassign the ref, then change But the new value is not shared, thus: x[1] := 1 // change only So that in your loop example, at most one array copy happens (iff it was shared). This is as far as I know what is commonly called copy-on-write. There is no need to copy the value over and over again on every change if it is not multiple-referenced, and noone does that, I guess. Side-Note: assignments of the form of "y := x" are really special, at least conceptually; but also practically when pointers or refs enter the game. I call them "symbol assignments" as the source is a symbol. Denis -- _ vita es estrany spir.wikidot.com
Re: GCC 4.6
Walter:
> You quoted a claim saying it was also an optimization.
If GCC devs say so, then I presume they are right. But the main purpose of a
warning is to warn the programmer, in this case to avoid some bugs.
> As I said, these kinds of error messages are very annoying when developing
> code,
> for example, when enabling and disabling various sections.
Warnings have a cost. Sometimes they are locally wrong, becoming noise, so in
some situations people want to disable specific warnings locally (GCC 4.6 has
added ways to do this).
In some situations I agree that an error is better than a warning message,
indeed D has turned some C warnings into errors. There are even two D warnings
that I want to become errors:
http://d.puremagic.com/issues/show_bug.cgi?id=3836
http://d.puremagic.com/issues/show_bug.cgi?id=4216
Elsewhere you have explained that different compilers have different warnings,
this combined with the choice of many programmers to see warnings as errors
produces incompatible programs, it means that changing the compiler becomes
almost like changing language (a possible solution I see to this problem is to
standardize most warnings in a language. So most warnings are shared between
compilers of the same language).
Regarding what you say here, I agree that when you develop a part of code you
want a little more local freedom. Because you often have some scaffolding code,
variables, etc, that you use to build the main code. This means that in code
that's work in progress you sometimes have duplicated variables, redundancies,
and several other things that are probably seen as problems by a more strict
compiler.
On the other hand, the amount of code you work in a moment is not large, so the
amount of warnings your program generates is not large (assuming most other
part of the code don't generate warnings or have silenced warnings), so I think
such limited amount of warnings is going to be acceptable. Maybe there is a way
to disable the warnings in just the parts of the program you are working now.
But warnings sometimes are useful, so they may catch bugs you are adding in the
new code you are adding/changing now.
The most part of a largish program is not under change in any moment (even if
many people are working on a program at the same time). And experience has
shown me that unused variables in cold code (code you are not modifying right
now) are sometimes associated with bugs or other troubles (this was also the
main point of that paper by Yichen Xie). And removing them helps make the code
shorter, more tidy. It's worse than leaving useless phrases in a text.
> I get told I'm wrong on just about everything I do.
In D language/compiler I have found many good decisions, most of them are good,
that's why I am here :-) But there are things I don't agree with, and I try to
explain why.
Like that section 3 page 2 "Redundant assignments" on the Yichen Xie paper. In
my code and code written by other people I have seen many times little errors
like this, or several similar variations of it:
class Foo {
int x, y, z;
Foo(int x_, int y_, int z_) {
x = x_;
y = y;
z = z_;
}
...
}
If the lint is able to spot redundant assignments, it shows a warning. A
compiler may even turn redundant assignments into errors. D turns unassigned
pure expressions into errors:
void main() {
int x = 10;
int y = 20;
x + y;
}
test.d(4): Error: + has no effect in expression (x + y)
But currently this gives no errors, despite it's the same situation, so I'd
like an error here too (this enhancement request is in Bugzilla already):
pure int add(int a, int b) { return a + b; }
void main() {
int x = 10;
int y = 20;
add(x, y);
}
In the paper by Yichen Xie you see many other interesting cases, that come from
real world code, it's quite interesting stuff.
Bye,
bearophile
Re: CTFE Overhaul (Was: RFC: Thrift project proposal (draft))
On 2011-03-26 21:16, Don wrote: dsimcha wrote: On 3/26/2011 12:16 PM, Don wrote: I'm giving CTFE a *major* overhaul right now. I don't know if I'll be finished in time for the next compiler release, but definitely by the release after that. Most importantly, bug 1330, which is the root cause of almost all of the problems, will be fixed. I hope to move CTFE out the "experimental feature" category. This is great news, I'm looking forward to it. Thanks for the hard work. Out of curiosity, can you give a brief overview of what new things CTFE will be usable for? The basic problem with the current implementation of CTFE is that it uses copy-on-write. This means that references (including dynamic arrays) don't work properly -- they just copy a snapshot of the thing they are referencing. This is bug 1330. It also means it burns up memory like you wouldn't believe. I'm changing CTFE to use in-place modification. This fixes all those issues. But this is obviously a fairly intense change, and will take quite a lot of time to iron out all the corner cases. So that's all I'm planning on doing right now. But once that's done, it will be straightforward to implement other reference types, such as classes and pointers (pointer arithmetic will be restricted to pointers which point to array members). Once classes are implemented, it's straightforward to do exceptions. So, pretty much everything. I've been planning on doing this for over a year, but while Walter was working on 64-bit, I felt that I was the only one working on the showstopper wrong-code bugs and regressions, so I put this important-but-not-urgent stuff aside. Will the time it takes to compile heavy uses of CTFE be affected by this (positive or negative)? -- /Jacob Carlborg
