Re: dpj for Windows
On 5/20/12 10:37 PM, dnewbie wrote: On Sunday, 20 May 2012 at 03:53:43 UTC, Nick Sabalausky wrote: dnewbie r...@myopera.com wrote in message news:qufvdhexcdzabuzqr...@forum.dlang.org... dpj is a mini-ide for the D programming language. http://my.opera.com/run3/blog/2012/05/20/dpj That's a good start! Not bad. Is it written in D? It started as a D project, then I've moved it to C. o_O Why?
Re: Visual D 0.3.32 maintenance release
On 5/13/12 7:31 PM, Rainer Schuetze wrote: resending due to NNTP error, sorry if it causes duplicates. On 5/13/2012 2:01 PM, Jonathan M Davis wrote: On Sunday, May 13, 2012 13:48:39 Rainer Schuetze wrote: On 5/11/2012 9:49 PM, Walter Bright wrote: On 5/1/2012 9:46 AM, Rainer Schuetze wrote: The Visual D installer can be downloaded from its website at http://www.dsource.org/projects/visuald Can you please move it to github? I considered that aswell recently, but I'm not yet convinced. I see the increase in contributions to dmd after the move to github, but my own experience with it has not been too positive: making patches for dmd is rather time consuming, I always have to struggle to get the simple stuff done (while it was just adding a diff to the bugzilla in the subversion times). As a result, the number of patches that I have provided has dropped considerably. My feeling is that git allows a lot of complex things at the cost of making standard operations much more complicated than necessary. Using git/github is probably less work for you compared to svn, but this also depends on a rather large infrastructure like the auto tester. I'm not sure it does actually help for a project with very few contributors. There haven't been a lot of community contributions to Visual D so far. To everybody interested: Would a move to github change that? You actually find patches to be easier than using github? That strikes me as odd. I've always found patches to be a pain to deal with and git and github have been really easy overall. You just make your changes on another branch, push them up to github, and then create a pull request. If you're the one merging in the changes, it's as easy as pushing the merge button the pull request, and it's in the main repository. Now, I don't deal with Visual D at all (I'm always on Linux, if nothing else), so I wouldn't be a contributor, and I have no idea if very many more people would be contribute if it were on github, but I'd definitely expect it to be easier for people to contribute if it were up on github than it would be for them to create patches and send those to you. - Jonathan M Davis The problem is that I need/want to use a branch of dmd that incorporates a number of patches, and that is where I start making additional changes. To send a pull request, I have to create a new branch, copy the changes into it, push it and make the pull request. I have created a batch to do that, but every other pull request something breaks and I start cursing... With the workflow of bugzilla/svn it was just copy and pasting the diff into the bug report. I understand it is easier on Walter's side, though. But where did you get the diff from? I'm sure you checked out the project and made the changes on it. If that's the case, then it's the same as forking and cloning. I *do* expect contributions to appear in Visual D. Since it's so easy to contribute in github, and it is standarized: people know how to do it: fork, work, make a pull request (as opposed to making a patch, sending it... mmm... is that the author's email? I hope it does work. And I hope it checks emails and mine doesn't go to the spam folder! Um, maybe I should post in the forums... but does he read them? Ah, maybe I will leave the patch for another day).
Re: DCT: D compiler as a collection of libraries
On 5/12/12 12:17 PM, Roman D. Boiko wrote:
On Saturday, 12 May 2012 at 03:32:20 UTC, Ary Manzana wrote:
As deadalnix says, I think you are over-complicating things.
I mean, to store the column and line information it's just:
if (isNewLine(c)) {
line++;
column = 0;
} else {
column++;
}
(I think you need to add that to the SourceRange class. Then copy line
and column to token on the Lexer#lex() method)
Do you really think it's that costly in terms of performance?
I think you are wasting much more memory and performance by storing
all the tokens in the lexer.
Imagine I want to implement a simple syntax highlighter: just
highlight keywords. How can I tell DCT to *not* store all tokens
because I need each one in turn? And since I'll be highlighting in the
editor I will need column and line information. That means I'll have
to do that O(log(n)) operation for every token.
So you see, for the simplest use case of a lexer the performance of
DCT is awful.
Now imagine I want to build an AST. Again, I consume the tokens one by
one, probably peeking in some cases. If I want to store line and
column information I just copy them to the AST. You say the tokens are
discarded but their data is not, and that's why their data is usually
copied.
Would it be possible for you to fork my code and tweak it for
comparison? You will definitely discover more problems this way, and
such feedback would really help me. That doesn't seem to be inadequately
much work to do.
Any other volunteers for this?
Sure, I'll do it and provide some benchmarks. Thanks for creating the issue.
Re: DCT: D compiler as a collection of libraries
On 5/11/12 4:22 PM, Roman D. Boiko wrote: What about line and column information? Indices of the first code unit of each line are stored inside lexer and a function will compute Location (line number, column number, file specification) for any index. This way size of Token instance is reduced to the minimum. It is assumed that Location can be computed on demand, and is not needed frequently. So column is calculated by reverse walk till previous end of line, etc. Locations will possible to calculate both taking into account special token sequences (e.g., #line 3 ab/c.d), or discarding them. But then how do you do to efficiently (if reverse walk is any efficient) compute line numbers? Usually tokens are used and discarded. I mean, somebody that uses the lexer asks tokens, process them (for example to highlight code or to build an AST) and then discards them. So you can reuse the same Token instance. If you want to peek the next token, or have a buffer of token, you can use a freelist ( http://dlang.org/memory.html#freelists , one of the many nice things I learned by looking at DMD's source code ). So adding line and column information is not like wasting a lot of memory: just 8 bytes more for each token in the freelist.
Re: DCT: D compiler as a collection of libraries
On 5/11/12 10:14 PM, Roman D. Boiko wrote:
On Friday, 11 May 2012 at 15:05:19 UTC, deadalnix wrote:
Le 11/05/2012 16:02, Roman D. Boiko a écrit :
Technically, I'm trading N*0(1) operations needed to track line and
column while consuming each character to M*0(log(n)) operations when
calculating them on demand. N = number of characters, n is number of
lines and M is number of actual usages of Location. My assumption is
that M N (M is much smaller than N).
N can easily be number of tokens.
Yes, if you are looking for the token by its index, not for location.
E.g., for autocompletion it is needed to find the last token before
cursor location. But that is not related to location search.
Also please note that I oversimplified formula for complexity. It also
has other components. My reply was just an additional minor comment.
Motivation is design, not performance.
One additional reason for such separation: with my approach it is
possible to calculate Location both taking into account infromation from
special token sequences, or ignoring it. How would you do that for eager
calculation? Calculate only one category? Or track and store both?
Unnecessary complexity will eventually find a way to shoot your leg :)
Real-world usage (at least, anticipated scenarios) should be the basis
for designing. Sometimes this contradicts intuition and requires you to
look at the problem from a different side.
As deadalnix says, I think you are over-complicating things.
I mean, to store the column and line information it's just:
if (isNewLine(c)) {
line++;
column = 0;
} else {
column++;
}
(I think you need to add that to the SourceRange class. Then copy line
and column to token on the Lexer#lex() method)
Do you really think it's that costly in terms of performance?
I think you are wasting much more memory and performance by storing all
the tokens in the lexer.
Imagine I want to implement a simple syntax highlighter: just highlight
keywords. How can I tell DCT to *not* store all tokens because I need
each one in turn? And since I'll be highlighting in the editor I will
need column and line information. That means I'll have to do that
O(log(n)) operation for every token.
So you see, for the simplest use case of a lexer the performance of DCT
is awful.
Now imagine I want to build an AST. Again, I consume the tokens one by
one, probably peeking in some cases. If I want to store line and column
information I just copy them to the AST. You say the tokens are
discarded but their data is not, and that's why their data is usually
copied.
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On 5/3/12 1:23 PM, Jakob Ovrum wrote: On Thursday, 3 May 2012 at 05:44:47 UTC, Ary Manzana wrote: On 5/3/12 1:26 AM, 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. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ Very nice! But why the symbols inside std.algorithm, for instance, are not sorted? http://jakobovrum.github.com/bootdoc-phobos/std.algorithm.html (they are kind of sorted by chunks...) The symbols in the symbol tree appear in the order the symbols appear in the documentation, which is the order of declaration in the original source (DMD does it this way). I think it would be a little confusing if the symbol tree was alphabetically sorted, while the main documentation was in order of declaration. It is possible to rearrange everything with JavaScript of course, but... I think this might be going a little bit too far. What do you think? I don't think the main documentation order is right in the first place. If a module provides many functions, like std.algorithm, I don't see how there could possibly be an intended order, like these are more likely to be used. In any case, if I want to quickly find a function, for example remove or insert or something I think might have the name I'm looking for, alphabetical order is the best way to go. Now if it only had cross references... :-P If I understand you correctly, any kind of automatic cross-referencing would need post-processing of DMD's generated output. I am considering such post-processing, but it would massively change the project (a lot less would require JavaScript), and completely bind the project to the included generator tool. I think the tool needs more trial-by-fire testing to determine whether it's good enough to be mandatory. Oh, I just said that because I have a pull request waiting for that feature to be incorporated in DMD... but I don't think it'll happen...
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On 5/3/12 2:10 PM, Jacob Carlborg wrote: On 2012-05-03 08:09, Jakob Ovrum wrote: I am considering putting the module tree and symbol tree in tabs instead of below each other. I think that would be a good idea. I'm not sure. I'd like the symbols to be under the same tree. With tabs you'd have to click twice to go from one place to another.
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On 5/3/12 6:41 PM, Jacob Carlborg wrote: On 2012-05-03 10:09, Ary Manzana wrote: I'm not sure. I'd like the symbols to be under the same tree. With tabs you'd have to click twice to go from one place to another. I didn't even know the symbols where there until a scrolled down. The same happened to me. What I meant with under the same tree is + std + algorithm * map * reduce * ...
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On 5/3/12 1:26 AM, 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. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ Very nice! But why the symbols inside std.algorithm, for instance, are not sorted? http://jakobovrum.github.com/bootdoc-phobos/std.algorithm.html (they are kind of sorted by chunks...) Now if it only had cross references... :-P
Re: Introducing vibe.d!
On 4/27/12 4:46 AM, Sönke Ludwig wrote: During the last few months, we have been working on a new framework for general I/O and especially for building extremely fast web apps. It combines asynchronous I/O with core.thread's great fibers to build a convenient, blocking API which can handle insane amounts of connections due to the low memory and computational overhead. Some of its key fatures are: Impressive. The website also looks really nice, and it's very fast. I'll definitely play with it and slowly try to make it into my workplace, hehe.
Re: Introducing vibe.d!
On 4/27/12 2:50 PM, Brad Anderson wrote: On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote: During the last few months, we have been working on a new framework for general I/O and especially for building extremely fast web apps. It combines asynchronous I/O with core.thread's great fibers to build a convenient, blocking API which can handle insane amounts of connections due to the low memory and computational overhead. Some of its key fatures are: - Very fast but no endless callback chains as in node.js and similar frameworks - Concise API that tries to be as efficient and intuitive as possible - Built-in HTTP server and client with support for HTTPS, chunked and compressed transfers, keep-alive connections, Apache-style logging, a reverse-proxy, url routing and more - Jade based HTML/XML template system with compile-time code generation for the fastest dynamic page generation times possible - Built-in support for MongoDB and Redis databases - WebSocket support - Natural Json and Bson handling - A package manager for seemless use of extension libraries See http://vibed.org/ for more information and some example applications (there are some things in the works such as an etherpad clone and an NNTP server). vibe.d is in a working state and enters its first beta-phase now to stabilize the current feature set. After that, a small list of additional features is planned before the 1.0 release. The framework can be downloaded or GIT cloned from http://vibed.org/ and is distributed under the terms of the MIT license. Note that the website including the blog is fully written in vibe and provides the first stress test for the implementation. Regards, Sönke I had to copy the included .lib files into bin in order to build the examples but so far, so good. This is awesome. How did you install it? I can't find the install.sh script anywhere...
Re: Introducing vibe.d!
On 4/28/12 8:12 AM, Ary Manzana wrote: On 4/27/12 4:46 AM, Sönke Ludwig wrote: During the last few months, we have been working on a new framework for general I/O and especially for building extremely fast web apps. It combines asynchronous I/O with core.thread's great fibers to build a convenient, blocking API which can handle insane amounts of connections due to the low memory and computational overhead. Some of its key fatures are: Impressive. The website also looks really nice, and it's very fast. I'll definitely play with it and slowly try to make it into my workplace, hehe. How to use it? ./bin/vibe usage: dirname path sh: /vpm.d.deps: Permission denied Failed: 'dmd' '-g' '-w' '-property' '-I/../source' '-L-levent' '-L-levent_openssl' '-L-lssl' '-L-lcrypto' '-Jviews' '-Isource' '-v' '-o-' '/vpm.d' '-I/' Error: cannot read file source/app.d Failed: 'dmd' '-g' '-w' '-property' '-I/../source' '-L-levent' '-L-levent_openssl' '-L-lssl' '-L-lcrypto' '-Jviews' '-Isource' '-v' '-o-' 'source/app.d' '-Isource' I also can't find the install.sh script...
Re: D web apps: cgi.d now supports scgi
On 3/25/12 12:43 PM, Adam D. Ruppe wrote: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff some docs: http://arsdnet.net/web.d/cgi.html http://arsdnet.net/web.d/cgi.d.html Very nice! I'd recommend moving those two html pages to github's wiki, or some other wiki. If people start using your library they can contribute with explanations, example usages, etc. I also see many empty or short sections in those documents, which again I think is asking for a wiki. I'm also not sure about the format you provide for getting the code: many unrelated modules all in a single directory. If I want to start developing web apps using your framework I need to clone that repo, think which files to import, etc. If all the related web stuff were in a separate repository, I could just clone it, import an all file and that's it. (well, the last point isn't really your fault, something like Jacob Carlborg's Orbit is really needed to make D code universally accessible and searchable)
Re: avgtime - Small D util for your everyday benchmarking needs
On 3/23/12 4:11 PM, Juan Manuel Cabo wrote: On Friday, 23 March 2012 at 06:51:48 UTC, James Miller wrote: 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 Dude, this is awesome. Thanks!! I appreciate your feedback! I would suggest changing the name while you still can. Suggestions welcome!! --jm give_me_d_average
Re: D web apps: cgi.d now supports scgi
On 3/27/12 10:25 AM, Adam D. Ruppe wrote: On Tuesday, 27 March 2012 at 00:53:45 UTC, Ary Manzana wrote: I'd recommend moving those two html pages to github's wiki, or some other wiki. If people start using your library they can contribute with explanations, example usages, etc. Yeah, I started that for the dom.d but haven't gotten around to much yet. (snip) (well, the last point isn't really your fault, something like Jacob Carlborg's Orbit is really needed to make D code universally accessible and searchable) I could add my build.d up there too... which offers auto downloading and module adding, but it is kinda slow (it runs dmd twice). How slow is it comparing it to a developer doing it manually? :-)
Re: avgtime - Small D util for your everyday benchmarking needs
On Tuesday, 27 March 2012 at 01:19:22 UTC, Juan Manuel Cabo wrote: On Tuesday, 27 March 2012 at 00:58:26 UTC, Ary Manzana wrote: On 3/23/12 4:11 PM, Juan Manuel Cabo wrote: On Friday, 23 March 2012 at 06:51:48 UTC, James Miller wrote: 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 Dude, this is awesome. Thanks!! I appreciate your feedback! I would suggest changing the name while you still can. Suggestions welcome!! --jm give_me_d_average Hahahah, naahh, prefiero avgtime o timestats, porque timestab autocompletaría a timestats. Qué hacés tanto tiempo? Gracias por mencionarme D hace años. Me quedó en la cabeza, y el año pasado cuando empecé un laburo nuevo tuve oportunidad de meterme con D. Saludos Ary, espero que andes bien!! --jm El nombre lo dije en broma :-P Me sorprendió muchísimo verte en la lista! Pensé Juanma?. Qué loco que te guste D. A mí me gusta también, pero tiene algunas cosas feas y que lamentablemente no veo que vayan a cambiar pronto... (o nunca). So you are using D for work?
Re: D to Javascript converter (a hacked up dmd)
On 2/29/12 2:34 PM, Alex Rønne Petersen wrote: On 29-02-2012 18:32, Andrei Alexandrescu wrote: On 2/26/12 9:51 PM, Adam D. Ruppe wrote: https://github.com/downloads/adamdruppe/dtojs/dtojs.zip [snip] That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei Avoiding writing JS directly in web apps comes to mind. I think it's cool you can convert D to JS, but I don't see why anyone would want to do it. 1. JS is a superior language: variables are dynamic and are not bound to just one single type during their lifetime. JS objects can store any property. 2. JS funcions are much easier to write (no need to declare types) and also to pass around (no need to write ). If you'd like to annotate variables, you could use Closure: https://developers.google.com/closure/compiler/docs/js-for-compiler 3. With JS you don't have to compile and run your code (well, I guess you could make something smart in D for that). 4. If you write JS you can debug it in the browser. No need to track back to the original source code. 5. If you don't like JS syntax or verbosity, you can use CoffeeScript, which is just a syntax rewriter, not a language/paradigm shift: http://coffeescript.org/ 6. Javascript objects have some built-in properties that are different from D. So implementing those in D would make their performance worse (but you can always hard-code those functions into the compiler and translate them directly to their JS equivalent). The good thing about writing in D is that you could probably get some IDE for autocompletion and such. You might also like to type things instead of using dynamic types.
Re: Mozilla Rust 0.1
On 1/24/12 4:50 AM, dennis luehring wrote:
The Rust compiler 0.1 is unleashed
http://www.reddit.com/r/programming/comments/opgxd/mozilla_and_the_rust_community_release_rust_01_a/
looks nice - but rusts #fmt macro is nothing compared to std.metastrings
and is not even library based :)
I can't believe people are still creating languages with curly-brace syntax.
And also, what's the advantage of the language? Having to type fn
instead of function or def? Having to type iface instead of
interface? Just look at this:
fn mk_appender(suffix: str) - fn@(str) - str {
let f = fn@(s: str) - str { s + suffix };
ret f;
}
YUCK!
/rant
Re: TDPL is an Amazon Kindle bestseller
On 6/20/11 10:56 AM, Andrej Mitrovic wrote: They won't die out. They'll just become rarer. Just like vinyl (and you can still buy vinyl!). I hope you are not talking about the trees! ;-)
