Re: [GSoC Proposal draft] High-Level Networking
On 2011-03-30 17:48:59 +0300, Jonas Drewsen said: On 30/03/11 03.04, Max Klyga wrote: snip Great to see that you're interested in improving the Phobos library! There already is some work being done on this. I've created bindings for libcurl that was accepted into Phobos a couple of days ago (see etc.c.curl module). This is the foundation of some network client classes that I'm doing. I intent to submit this to Phobos when I've implemented the last of the suggestions that I received from the community earlier. Could you give links to that suggestions? Is your work on network-clients avaliable online? My initial target is FTP and HTTP support. See: https://github.com/jcd/phobos/blob/curl/etc/curl.d This does have some overlap with your proposal but that doesn't have to be a bad thing. If this proposal gets accepted you have the libcurl bindings already as a kickstart. Some other options are to extend the client classes that I'm doing. Or to implement the network server classes. RFC compilant HTTP-server is very hard to implement, so one solution might be to implement different protocol clients (SMTP, ...) so our work will not overlap. /Jonas
Re: [GSoC’11] Lexing and parsing
On 2011-03-23 00:27:51 +0200, Ilya Pupatenko said: Hi, First of all, I want to be polite so I have to introduce myself (you can skip this paragraph if you feel tired of newcomer-students’ posts). My name is Ilya, I’m a Master student of IT department of Novosibirsk State University (Novosibirsk, Russia). In Soviet period Novosibirsk became on of the most important science center in the country and now there are very close relations between University and Academy of Science. That’s why it’s difficult and very interesting to study here. But I’m not planning to study or work this summer, so I’ll be able to work (nearly) full time on GSoC project. My primary specialization is seismic tomography inverse problems, but I’m also interested in programming language implementation and compilation theory. I have good knowledge of C++ and C# languages and “intermediate” knowledge of D language, knowledge of compilation theory, some experience in implementing lexers, parsers and translators, basic knowledge of lex/yacc/antlr and some knowledge of Boost.Spirit library. I’m not an expert in D now, but I willing to learn and to solve difficult tasks, that’s why I decided to apply on the GSoC. I’m still working on my proposal (on task “Lexing and Parsing”), but I want to write some general ideas and ask some questions. 1. It is said that “it is possible to write a highly-integrated lexer/perser generator in D without resorting to additional tools”. As I understand, the library should allow programmer to write grammar directly in D (ideally, the syntax should be somehow similar to EBNF) and the resulting parser will be generated by D compiler while compiling the program. This method allows integration of parsing in D code; it can make code simpler and even sometimes more efficient. There is a library for C++ (named Boost.Spirit) that follows the same idea. It provide (probably not ideal but very nice) “EBNF-like” syntax to write a grammar, it’s quite powerful, fast and flexible. There are three parts in this library (actually there are 4 parts but we’re not interested in Spirit.Classic now): • Spirit.Qi (parser library that allows to build recursive descent parsers); • Spirit.Karma (generator library); • Spirit.Lex (library usable to create tokenizers). The Spirit library uses “C++ template black magic” heavily (for example, via Boost.Fusion). But D has greater metaprogramming abilities, so it is possible to implement the same functionality in easier and “clean” way. So, the question is: is it a good idea if at least parser library architecture will be somewhat similar to Spirit one? Of course it is not about “blind” copying; but creating architecture for such a big system completely from scratch is quite difficult indeed. If to be exact, I like an idea of parser attributes, I like the way semantic actions are described, and the “auto-rules” seems really useful. 2. Boost.Spirit is really large and complicated library. And I doubt that it is possible to implement library of comparable level in three months. That’s why it is extremely important to have a plan (which features should be implemented and how much time will it take). I’m still working on it but I have some preliminary questions. Should I have a library that is proposed and accepted in Phobos before the end of GSoC? Or there is no such strict timeframe and I can propose a library when all features I want to see are implemented and tested well? And another question. Is it ok to concentrate first on parser library and then “move” to other parts? Of course I can choose another part to start work on, but it seems to me that parser is most useful and interesting part. 3. Finally, what will be next. I’ll try to make a plan (which parts should be implemented and when). Then I guess I need to describe the proposed architecture in more details, and probably provide some usage examples(?). Is it ok, if I publish ideas there to get reviews? Anyway, I’ll need some time to work on it. Ilya. P.S. The funny thing is that I found minor bug in Phobos (#5736) while trying (just for fun) to implement some tiny part of Spirit in D. Submitting bugs seems to be important part of the task too. Mimicking spirit might not be a good idea. It looks sort of like BNF grammar, but because of operator abuse, there is just so many noise. A better idea might be using D compile time function evaluation to parse strings with grammars
Re: Digital Mars has been accepted for Google Summer of Code 2011
On 2011-03-18 22:01:38 +0200, Andrei Alexandrescu said: We have just got word from Google - Digital Mars has been accepted as a mentoring organization for Google Summer of Code 2011. Thanks to Trass3r for bringing up this idea, to Jens Mueller for reiterating it, and to the people who added to the project ideas wiki. These are heady times. Let's spread the word to friends and colleagues! If you're a student, consider embarking on a project. If you're experienced with D, consider applying for mentorship. Walter, please announce this on digitalmars.com and link to the project ideas page. Thanks, Andrei This is absolutely awesome!
Potential patent issues
I spotted some patents that can theaten current DMD implementation. Wanted to clarify things. http://www.freepatentsonline.com/6185728.pdf - this patent describes method pointers implementation (delegates) http://www.freepatentsonline.com/5628016.pdf - describes compiler support for SEH, also this is the reason GNU toolchain does not support SEH right now Both patents were owned by Borland, right now, I believe Microsoft owns them. Walter, could you give some comments about this? Does dmd violate anything?
Re: Potential patent issues
On 2011-01-19 01:15:03 +0200, Daniel Gibson said: This is trivial, what idiot grants these kind of patents? And were there really no delegates before Jan. 31 1996 when this was filed? If I'm not mistaken, Oberon-2 implemented pointers to record-bound procedures as fat-pointers
Re: How to use std.bind?
On 2011-01-17 19:03:15 +0200, Sean Eskapp said:
I used to use boost::bind all the time, but std.bind has me stumped, as I keep
getting static asserts with a cryptic argument has no parameters message. At
this point, the code is just:
class Foo
{
void bar(int i) { writeln(i); }
}
void main()
{
auto foobar = new Foo;
bind(foobar.bar, 5)();
}
I've tried a myriad of different ways, but keep coming up with the same error.
Using bindAlias gives me an error that std.bind.bindAlias(alias FT) is not a
function template.
I'm using DMD v2.051 on a Windows platform. Help anybody?
std.bind is scheduled for deprecation, use lambda-expressions instead
Re: eliminate junk from std.string?
On 2011-01-12 01:00:51 +0200, Andrei Alexandrescu said: On 1/11/11 11:21 AM, Ary Borenszweig wrote: Why care where they come from? Why not make them intuitive? Say, like, Always camel case? If there's enough support for this, I'll do it. Andrei ++vote. Uniformity in how functions are named will improve readibility.
Re: Issue 1323
On 2011-01-09 01:20:17 +0200, bearophile said: Andrei has recently closed issue 1323, it's a small but very useful feature, so I suggest some public discussion: http://d.puremagic.com/issues/show_bug.cgi?id=1323 Lines like this is present thousands of time in my Python code: n in [1, 2, 3] c in hello llo in some_string Bye, bearophile This feature was discussed before. If 'in' operator was overladable, users would expect it to have some known complexity. Having sintactic sugar for some operation means that it is supposed to be used widely, and using O(n) operations all over the place is not a good idea. Also, IMO, it has no real advantage, why not use std.algorithm.find instead ?
Re: Patterns of Bugs
On 2011-01-06 21:38:38 +0200, Walter Bright said: http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html (dedicated to bearophile!) Anyone want to post it on reddit? http://www.reddit.com/r/programming/comments/exfnb/patterns_of_bugs/ done!
