Re: D-Day for DMD is today!
On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Many, many thanks to Daniel Murphy for slaving away for 2.5 years to make this happen. More thanks to Martin Nowak for helping shepherd it through the final stages, and to several others who have pitched in on this. This is a HUGE milestone for us. Much work remains to be done, such as rebasing existing dmd pull requests. Thanks in advance for the submitters who'll be doing that. I hope you aren't too unhappy about the extra work - it's in a good cause! Awesome! Thanks to Daniel and people who working on this. This is a great step for D :)
Re: Performance of std.json
On Monday, 2 June 2014 at 00:18:19 UTC, David Soria Parra wrote:
Hi,
I have recently had to deal with large amounts of JSON data in
D. While doing that I've found that std.json is remarkable slow
in comparison to other languages standard json implementation.
I've create a small and simple benchmark parsing a local copy
of a github API call
https://api.github.com/repos/D-Programming-Language/dmd/pulls;
and parsing it 100% times and writing the title to stdout.
My results as follows:
./d-test /dev/null 3.54s user 0.02s system 99% cpu 3.560
total
./hs-test /dev/null 0.02s user 0.00s system 93% cpu 0.023
total
python test.py /dev/null 0.77s user 0.02s system 99% cpu
0.792 total
The concrete implementations (sorry for my terrible haskell
implementation) can be found here:
https://github.com/dsp/D-Json-Tests/
This is comapring D's std.json vs Haskells Data.Aeson and
python standard library json. I am a bit concerned with the
current state of our JSON parser given that a lot of
applications these day use JSON. I personally consider a high
speed implementation of JSON a critical part of a standard
library.
Would it make sense to start thinking about using ujson4c as an
external library, or maybe come up with a better
implementation. I know Orvid has something and might add some
analysis as to why std.json is slow. Any ideas or pointers as
to how to start with that?
I don't know the status of another D based JSON library.
If you can install yajl library, then yajl-d is an another
candidate.
% time ./yajl_test /dev/null
./yajl_test /dev/null 0.42s user 0.01s system 99% cpu 0.434
total
% time python test.py /dev/null
python test.py /dev/null 0.65s user 0.02s system 99% cpu 0.671
total
% time ./test /dev/null
./test /dev/null 3.10s user 0.02s system 99% cpu 3.125 total
import yajl.yajl, std.datetime, std.file, std.stdio;
void parse() {
foreach(elem; readText(test.json).decode.array) {
writeln(elem.object[title]);
}
}
int main(string[] args) {
for(uint i = 0; i 100; i++) {
parse();
}
return 0;
}
http://code.dlang.org/packages/yajl
NOTE: yajl-d doesn't expose yajl's SAX style API unlike Sean's
implementation
Re: Performance of std.json
On Monday, 2 June 2014 at 00:18:19 UTC, David Soria Parra wrote: Hi, I have recently had to deal with large amounts of JSON data in D. While doing that I've found that std.json is remarkable slow in comparison to other languages standard json implementation. I've create a small and simple benchmark parsing a local copy of a github API call https://api.github.com/repos/D-Programming-Language/dmd/pulls; and parsing it 100% times and writing the title to stdout. My results as follows: ./d-test /dev/null 3.54s user 0.02s system 99% cpu 3.560 total ./hs-test /dev/null 0.02s user 0.00s system 93% cpu 0.023 total python test.py /dev/null 0.77s user 0.02s system 99% cpu 0.792 total The concrete implementations (sorry for my terrible haskell implementation) can be found here: https://github.com/dsp/D-Json-Tests/ This is comapring D's std.json vs Haskells Data.Aeson and python standard library json. I am a bit concerned with the current state of our JSON parser given that a lot of applications these day use JSON. I personally consider a high speed implementation of JSON a critical part of a standard library. Would it make sense to start thinking about using ujson4c as an external library, or maybe come up with a better implementation. I know Orvid has something and might add some analysis as to why std.json is slow. Any ideas or pointers as to how to start with that? BTW, my acquaintance points out your haskell code is different from other samples. Your haskell code parses JSON array only once. This is why so fast. He uploads same behaviour code which parses JSON array at each loop. Please check it. https://gist.github.com/maoe/e5f72c3cf3687610fe5c On my env result: % time ./new_test /dev/null ./new_test /dev/null 1.13s user 0.02s system 99% cpu 1.144 total % time ./test /dev/null ./test /dev/null 0.02s user 0.00s system 91% cpu 0.023 total
Re: std.serialization
On Sunday, 16 February 2014 at 22:48:51 UTC, Andrej Mitrovic wrote: On 2/16/14, Dicebot pub...@dicebot.lv wrote: No, it should just serialize the pointed value and make the same difference upon deserialization - if it is a value, write to it, otherwise allocate new instance on heap and assign its address. Speaking of related things like pointers and cyclic references I have support for this in my fork of msgpack, but the problem is that msgpack is a defined format, so you can't arbitrarily implement your own features without breaking the format: https://github.com/msgpack/msgpack-d/issues/7 It's 11:48 PM here in case I'm completely off topic. :P I just commented. Maybe, we can support cyclic references by using ext type. https://github.com/msgpack/msgpack-d/issues/7#issuecomment-35230360 I will try it.
Re: Scott Meyers will deliver a keynote talk at DConf 2014
On Tuesday, 4 February 2014 at 20:34:29 UTC, Andrei Alexandrescu wrote: I'm happy to announce that Scott Meyers will deliver a keynote talk at the upcoming DConf 2014. Details of the talk are forthcoming. Scott Meyers (http://aristeia.com) is one of the best experts worldwide in all aspects of software development using C++. He authored the best-selling Effective C++ series (Effective C++, More Effective C++, and Effective STL) and founded the Effective Software Development Series at Addison Wesley, where he acts as a Consulting Editor. Scott holds a M.Sc. from Stanford University and a Ph.D. from Brown University. Andrei Awesome! I read several his books in Japanese :) Masahiro
Re: Facebook is using D in production starting today
On Friday, 11 October 2013 at 00:36:12 UTC, Andrei Alexandrescu wrote: Today I committed the first 5112 lines of D code to Facebook's repository. The project is in heavy daily use at Facebook. Compared to the original version (written in C++) we've measured massive wins in all of source code size, build speed, and running speed. In all likelihood we'll follow up with a blog post describing the process. Andrei Awesome news! Cl!
Re: TDPL Japanese Edition
All, Thank you for the reply! Today, just delivered to Japanese programmers :) April 8th was the presale date. Masahiro On Thursday, 4 April 2013 at 05:51:03 UTC, Masahiro Nakagawa wrote: Hi guys, I and Kenji are happy to announce TDPL Japanese edition will be published on April 8th in Japan. We are translation supervisor of this book. Sample picture is here: https://pathakacdn-a.akamaihd.net/photos2/7ace5e69-4d3c-497f-87fc-4fbd97c7ad8f/original.jpg The official web page of the publisher Shoeisha: http://books.shoeisha.co.jp/book/b108222.html (in japanese) Of course, we applied latest changes and added some columns for new features, e.g. CTFE, lambda syntax and more. In addition, we strived to maintain Andrei's distinctive and lively language even through translation :) Thanks to Andrei for writing TDPL and D community for keeping an active development. We hope this book becomes a stepping stone to further development. Thanks, Masahiro and Kenji
TDPL Japanese Edition
Hi guys, I and Kenji are happy to announce TDPL Japanese edition will be published on April 8th in Japan. We are translation supervisor of this book. Sample picture is here: https://pathakacdn-a.akamaihd.net/photos2/7ace5e69-4d3c-497f-87fc-4fbd97c7ad8f/original.jpg The official web page of the publisher Shoeisha: http://books.shoeisha.co.jp/book/b108222.html (in japanese) Of course, we applied latest changes and added some columns for new features, e.g. CTFE, lambda syntax and more. In addition, we strived to maintain Andrei's distinctive and lively language even through translation :) Thanks to Andrei for writing TDPL and D community for keeping an active development. We hope this book becomes a stepping stone to further development. Thanks, Masahiro and Kenji
Re: D = asm.js for the web?
ABA-san tried LDC+Emscripten+asm.js. http://d.hatena.ne.jp/ABA/20130331#p1 (in japanese) LDC has some limitations but this SDL code works :) Masahiro On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote: So given the LDC2 project, maybe with LDC+Emscripten+asm.js there is a chance to see D on the web. I think someone will be happy to use D instead of C/C++ on the web for performance-sensitive code, like games. This is a small window of opportunity for D. Bye, bearophile
Re: D = asm.js for the web?
On Sunday, 31 March 2013 at 12:56:46 UTC, bearophile wrote: Masahiro Nakagawa: ABA-san tried LDC+Emscripten+asm.js. http://d.hatena.ne.jp/ABA/20130331#p1 (in japanese) LDC has some limitations but this SDL code works :) Masahiro Very good. Is is visible the resulting javascript able to run on the browswer? Yes. The window which has Nightly menu in top picture is his browser. This is a part translated with Google Translate: Problem of the time being, where is moss Emscripten writing class as I wrote at the beginning. The moss just write an empty class that does not contain anything that I downright difficult. I guess the difference is the treatment of class in Clang and LDC. What's the problem with classes and LDC? I'm not sure. He tried to use D's class but translating LLVM to JavaScript via Emscripten failed. He guesses internal class representation is different between LDC and Clang.
Re: msgpack unresolved question
Hi Dan, Sorry for the delay. Your mail is referred to as spam in Gmail... I also got same error in compare_json.d, and I agree with Jesse. pragma(msg, typeof(via.map.length)); returns 'ulong' during compilation. But the linker error occurred in the runtime. Now, I have no idea to resolve it in library. Give me some time to think it over. Thanks, Masahiro On Thursday, 25 October 2012 at 18:50:55 UTC, Dan wrote: On Thursday, 25 October 2012 at 17:59:40 UTC, Jesse Phillips wrote: It is a linker error. You need to compile the msgpack.d file and tell the linker where to find it. The simplest way is to just throw the file on the command line. dmd compare_json.d msgpack.d Thanks. I tried your suggestion but had no luck (same link error). It could be my command is still wrong. Or maybe it is something related to associative arrays? The reason I suggest this is there is another example in the directory (custom.d) which uses functionality in msgpack and builds and runs fine without my specifying msgpack.d on the command line. Thanks Dan dmd /.../msgpack-d/example/compare_json.d /.../msgpack-d/src/msgpack.d compare_json.o: In function `_D7msgpack5Value83__T9toMsgpackTS7msgpack50__T6PackerTS3std5array16__T8AppenderTAhZ8AppenderZ6PackerZ9toMsgpackMxFNeKS7msgpack50__T6PackerTS3std5array16__T8AppenderTAhZ8AppenderZ6PackerZv': /.../msgpack-d/src/msgpack.d:(.text._D7msgpack5Value83__T9toMsgpackTS7msgpack50__T6PackerTS3std5array16__T8AppenderTAhZ8AppenderZ6PackerZ9toMsgpackMxFNeKS7msgpack50__T6PackerTS3std5array16__T8AppenderTAhZ8AppenderZ6PackerZv+0x1aa): undefined reference to `_D6object55__T16AssociativeArrayTS7msgpack5ValueTxS7msgpack5ValueZ16AssociativeArray6lengthMFNdZm' collect2: ld returned 1 exit status --- errorlevel 1
Re: #d_lang ---- #dlang on Twitter?
On Thursday, 19 July 2012 at 21:35:19 UTC, Andrei Alexandrescu wrote: Whaddaya think? Andrei No, problem. Our official website is dlang.org :) If hashtag changed to #dlang, I announce this change to other Japanese programmers.
Re: D versionning
On Monday, 16 July 2012 at 01:38:38 UTC, Alex Rønne Petersen wrote: On 16-07-2012 03:11, Andrei Alexandrescu wrote: On 7/15/12 7:44 PM, Adam Wilson wrote: I should note that we use this exact model for every project we have where I work and that it is been highly successful at keeping those five points of tension moderated. And our users can actually get work done without waiting for weeks and months because thing X is just plain broken, which in turn makes us look good. (Improving Loyalty) Allow me to propose something. Right now all dmd changes get merged in the head. Suppose we find a volunteer in the community who is: 1. Highly motivated 2. With a good understanding of D 3. Expert with git 4. Reliable I wonder if it's possible that that person cherry-picks commits from HEAD into two separate branches: bugfixes and unstable. It should be easy to create installers etc. for those. If we see this works well and gathers steady interest, we can improve it and make it the practice of the entire team. Would this be possible? Andrei I propose a slight variation: * master: This is the 'incoming' branch. Unstable, in-dev, etc. It's easier this way since pull requests will usually target this branch and build bots will test this. * stable: This branch contains only bug fixes to existing language features, and enhancements that do not in any way impact existing features (or break code). Should be manually maintained based on master. That's it. I don't see a need for any added complexity to this simple model. Feel free to destroy as you see fit, though! git-flow is the other candidate. https://github.com/nvie/gitflow/ See more detail: http://nvie.com/posts/a-successful-git-branching-model/
Re: Vote for std.uuid
On Tuesday, 19 June 2012 at 11:24:50 UTC, Dmitry Olshansky wrote: As been mentioned previously, std.uuid is quite small so we've settled for shorter review period. That period ended as of some hours ago. It's time to start voting on its inclusion into Phobos. The voting ends at 25-26 June. --- Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html --- The rules are as usual: only one one vote. Leaving a one-line short reason note is encouraged. Let's reuse the old review thread for further discussions if any, as thread pooling is more efficient :) Yes! Good work :)
Re: New hash API: Update
On Sunday, 24 June 2012 at 15:23:19 UTC, Johannes Pfau wrote: I'm mostly finished with my hash API proposal. I also ported the existing crc, md5 and the proposed sha1 hash to this new API. Great! I will read docs and souce code later. I changed the namespace to std.util.digest. Andrei once said he thinks std.digest/std.hash is a too narrow package and someone else said putting crc into std.crypto.digest is ridiculous. So I did what tango and other libraries do and created a std.util module. I think std.uuid would also fit well into std.util so it'd become std.util.uuid. I disagree this point. The name 'util' does not make any sense. 'util' seems to be very subjective.
Re: stream interfaces - with ranges
On Friday, 18 May 2012 at 19:18:21 UTC, Artur Skawina wrote: On 05/18/12 20:18, Artur Skawina wrote: On 05/18/12 17:43, kenji hara wrote: I'm designing experimental IO primitives: https://github.com/9rnsr/dio It has a sample benchmark to compare performance with std.stdio for line iteration. It's not exactly what i had i mind, but i tried to build it; it wants a 'io/wrapper.d' module which can not be found. And is apparently windows-only; missing HANDLE type, non- existent TextOutputRange. I gave up after running into: io/file.d:263: Error: static assert (isSource!(File)) is false Current dio is PoC for new IO design. If we go with such design, I will add Linux/Mac support to dio. Masahiro
Re: stream interfaces - with ranges
Please add README to top directory. (Contents are benchmark command, support environment and etc) We can see such information on web browser ;) P.S. I want to do pull request for supporting other environments. But I'm busy right now... Masahiro On Saturday, 19 May 2012 at 15:22:37 UTC, kenji hara wrote: Sorry, I have updated it. Run 'make runbench' or 'make runbench_opt'. Kenji Hara 2012/5/19 Artur Skawina art.08...@gmail.com: On 05/18/12 17:43, kenji hara wrote: I'm designing experimental IO primitives: https://github.com/9rnsr/dio It has a sample benchmark to compare performance with std.stdio for line iteration. It's not exactly what i had i mind, but i tried to build it; it wants a 'io/wrapper.d' module which can not be found. artur
D on AOJ
AOJ, Aizu Online Judge, also supports D programming language with dmd 2.059 :) http://judge.u-aizu.ac.jp/onlinejudge/system_info.jsp See Judge Server #3 (2012-). On Saturday, 14 April 2012 at 10:22:18 UTC, Masahiro Nakagawa wrote: This announcement is mainly for Japanese programmers. AtCoder is a new programming contest site in Japan. I and other D programmers begged AtCoder team to support D. In the result, AtCoder supports D (dmd 2.058) officially. Thanks to AtCoder team! Today, 1st contest will be held. http://arc001.contest.atcoder.jp/ Available languages are on the foot of a page. D community in Japan is spreading year by year :)
denv - D version of rbenv
I use rbenv to manage multiple versions of Ruby. So, I ported rbenv to D. https://github.com/repeatedly/denv I tested dmd on Linux and Mac. (Sorry, I am not GDC and LDC user) I will port ruby-build If necessary. Regards, Masahiro
Re: denv - D version of rbenv
On Friday, 4 May 2012 at 17:54:35 UTC, simendsjo wrote: On Fri, 04 May 2012 17:54:11 +0200, Masahiro Nakagawa repeate...@gmail.com wrote: I use rbenv to manage multiple versions of Ruby. So, I ported rbenv to D. https://github.com/repeatedly/denv I tested dmd on Linux and Mac. (Sorry, I am not GDC and LDC user) I will port ruby-build If necessary. Regards, Masahiro Sounds very similar to, but more complete than, dvm: https://github.com/jacob-carlborg/dvm Yes. But I don't know the detail of dvm implementation. rbenv is a small and compact version manager than rvm. (If you want to know more comparison of rbenv and rvm, See https://github.com/sstephenson/rbenv ) I like rbenv, so I ported.
Re: denv - D version of rbenv
On Friday, 4 May 2012 at 19:09:01 UTC, Jacob Carlborg wrote: On 2012-05-04 19:54, simendsjo wrote: On Fri, 04 May 2012 17:54:11 +0200, Masahiro Nakagawa repeate...@gmail.com wrote: I use rbenv to manage multiple versions of Ruby. So, I ported rbenv to D. https://github.com/repeatedly/denv I tested dmd on Linux and Mac. (Sorry, I am not GDC and LDC user) I will port ruby-build If necessary. Regards, Masahiro Sounds very similar to, but more complete than, dvm: https://github.com/jacob-carlborg/dvm Seems a lot more complicated as well. A big part of DVM is to easily install a compiler, which is done manually with denv. I will port ruby-install to D if needed. Oh, my. Everything is written in shell script. DVM works on Windows as well, thanks to Nick :) Yeah. denv does not directly support Windows same as other xxenv.
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On Wednesday, 2 May 2012 at 18:26:11 UTC, Jakob Ovrum wrote: This project is finally published and documented, so here's an announcement. https://github.com/JakobOvrum/bootDoc bootDoc is a configurable DDoc theme, with advanced JavaScript features like a package tree and module tree, as well as fully qualified symbol anchors. The style itself and some of the components come from Twitter's Bootstrap framework. Demonstration of Phobos documentation using bootDoc http://jakobovrum.github.com/bootdoc-phobos/ LuaD's official documentation also uses bootDoc http://jakobovrum.github.com/LuaD/ bootDoc is designed to be easily usable with any project. It is used as a git-submodule in both of the above sample scenarios. All project-specific settings are provided by a separate configuration file (settings.ddoc), which is documented on the project's Github wiki. bootDoc includes a general-purpose generation script. See the readme on Github for usage information. The script uses a candyDoc-style modules.ddoc as input, making the transition from candyDoc projects easy. Note about noscript: JavaScript is used to get around the static nature of DDoc. The sidebar does not work without JavaScript, and neither do fully qualified anchor names. However, anchors with ambiguous names (such as those usable for symbols on dlang.org) work both with and without JavaScript, with the same limitations. Comments, issues, enhancement requests, questions or rants about JavaScript - all feedback is much appreciated! Great! I will try this :) Masahiro
Re: D scored well in the Google CodeJam Qualification Round
On Monday, 16 April 2012 at 13:31:32 UTC, Somedude wrote: Although there was very few D contestants (only 15 out of 18365 contestants used D), D scored number 1. http://go-hero.net/jam/?repost2012 It was only the qualification round, and admittedly, 3 out of 4 problems were not extremely interesting. Still, congrats to hos.lyric, - whoever that is (Kenji ?) -, who managed to submit a perfect solution in 1h55, more than 46 mn before the rank 2. Yeah! hos.lyric is a great coder. He is a university student, not Kenji.
Re: D scored well in the Google CodeJam Qualification Round
On Monday, 16 April 2012 at 14:02:21 UTC, bearophile wrote: Somedude: Although there was very few D contestants (only 15 out of 18365 contestants used D), D scored number 1. This is very good advertisement for D. A D user (group) has to reach a good score in the ICFP Programming Contest too :-) And why is D so popular in Japan? :-) We supports D newbies in many scenes. See this reply http://forum.dlang.org/thread/CAJ85NXCWkmo0y8cSZz+mtq+x3Kxv7-eJ6Gw4XDier=e+ti-...@mail.gmail.com#post-xkrxexychkfodzrfgkgh:40forum.dlang.org In my personal activities, I talked about D in some meetups, e.g. D Kaigi, RubyKaigi, Kernel/VM, Boost.meetup, LL Nagoya, and etc. In addition, kinaba sometimes talked about D and wrote the blog titled D for contest programming recently.
Re: Serialization woes
On Wednesday, 18 April 2012 at 15:02:39 UTC, Andrej Mitrovic wrote: On 4/18/12, Masahiro Nakagawa repeate...@gmail.com wrote: You can use direct-conversion deserialize Foo foo2; msgpack.unpack(data, foo2); instead of msgpack.unpack(data).as!(typeof(foo)); I tested your code on my Mac. Direct-conversion deserialize is 2x or 3x faster. Wow, I had no idea there was a direct-conversion routine. On my machine here's the results, first the indirect conversion: globals.d(358): saved headers in 2327 msecs globals.d(364): loaded headers in 82058 msecs then the direct conversion: globals.d(358): saved headers in 2581 msecs globals.d(364): loaded headers in 4260 msecs That's almost a 20x speed improvement! Fantastic, this solves my problems! I'm glad to hear that :) But deserialization is still slower than serialization. I will try to improve the performance. But what exactly is the difference between the two deserialization routines except the speed itself? The main reason is the backward compatibility. First implementation of msgpack-d didn't have the direct-conversion deserializer. Yes, msgpack.unpack isn't a streaming deserialization, so msgpack.unpack for streaming deserializer is not needed. I plan to clean up the API, but I need some more time.
Re: Serialization woes
On Wednesday, 18 April 2012 at 16:08:34 UTC, David Nadlinger wrote: On Wednesday, 18 April 2012 at 15:51:00 UTC, Andrej Mitrovic wrote: On 4/18/12, Masahiro Nakagawa repeate...@gmail.com wrote: I plan to clean up the API, but I need some more time. No problem, I'm a happy msgpack user again. :-) Are there some good public msgpack-d benchmarks? I'd be interested how Thrift fares against it (which has also been built with performance in mind). Nothing. Currently, correct benchmark with Thrift is difficult. Because current msgpack-d does not provide RPC.
Re: Serialization woes
On Thursday, 19 April 2012 at 00:00:32 UTC, Robert Jacques wrote:
On Wed, 18 Apr 2012 10:05:57 -0500, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 4/18/12, Robert Jacques sandf...@jhu.edu wrote:
here are some results for your benchmark on
my own serializers:
JSON serialize: 0.331831 s
JSON deserialize: 0.243893 s
Hey Robert, I was trying out your JSON library a while ago ago
(I
didn't find a repository but just a newsgroup link to the
sources),
and the library seemed to be missing the JSON.to! template,
even
though it was documented. Maybe you have a link to the newer
sources?
Thanks.
Thank you. Sorry, the example code got stale. When I switched
to using a Variant for JSON, the to! moved into Variant. So the
documentation example should read:
Json json = JSON.parse( [1,2,3] );// Parse an input
range
MyStruct var = json.to!MyStruct(); // De-serialize a
type
json = JSON.from(var); // Serialize a type
enforce(JSON.isValid(json));// Validate the
serialization
write(var.json, JSON.toStringHR(json)); // Write in a
pretty format
json = JSON.parse( {x:1,y:2,z:3} );
assert( json.x + json.y == 3 ); // Perform
operations on a Json
What is the status of this json module?
I am now working on new D library and
its library needs JSON data format.
std.json is not usable at hard-use.
I want your json library as a std.json.
Re: Serialization woes
On Wednesday, 18 April 2012 at 03:32:47 UTC, Andrej Mitrovic wrote: On 4/18/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 4/17/12, Jacob Carlborg d...@me.com wrote: Feel free to use my serialization library and see what it can handle: https://github.com/jacob-carlborg/orange Simple test-case: http://pastebin.com/dcnm4nmA That's around 15k keys. It takes 31 seconds to serialize. And my structures are full of these hashes, so it would likely take an eternity to serialize my structures with Orange. Here's msgpack-d: http://pastebin.com/wsRQPiDJ 6.3 milliseconds to serialize. But it takes 32 milliseconds to unserialize, which is 5x slower. On big data structures this difference becomes quite noticeable. You can use direct-conversion deserialize Foo foo2; msgpack.unpack(data, foo2); instead of msgpack.unpack(data).as!(typeof(foo)); I tested your code on my Mac. Direct-conversion deserialize is 2x or 3x faster.
D on AtCoder
This announcement is mainly for Japanese programmers. AtCoder is a new programming contest site in Japan. I and other D programmers begged AtCoder team to support D. In the result, AtCoder supports D (dmd 2.058) officially. Thanks to AtCoder team! Today, 1st contest will be held. http://arc001.contest.atcoder.jp/ Available languages are on the foot of a page. D community in Japan is spreading year by year :)
Re: D on AtCoder
On Saturday, 14 April 2012 at 11:28:46 UTC, Olivier Pisano wrote: Le 14/04/2012 12:22, Masahiro Nakagawa a écrit : D community in Japan is spreading year by year :) Subarashi ! :) Arigatou!
Re: D on AtCoder
On Saturday, 14 April 2012 at 12:14:34 UTC, Trass3r wrote: I and other D programmers begged AtCoder team to support D. In the result, AtCoder supports D (dmd 2.058) officially. Now get them to update to 2.059 so you will get UFCS ;) Yeah. I continue to help the AtCoder team :)
Re: D on AtCoder
On Saturday, 14 April 2012 at 14:11:00 UTC, Chad J wrote: On 04/14/2012 06:22 AM, Masahiro Nakagawa wrote: This announcement is mainly for Japanese programmers. AtCoder is a new programming contest site in Japan. I and other D programmers begged AtCoder team to support D. In the result, AtCoder supports D (dmd 2.058) officially. Thanks to AtCoder team! Today, 1st contest will be held. http://arc001.contest.atcoder.jp/ Available languages are on the foot of a page. D community in Japan is spreading year by year :) 404 not found. :/ At the peak time, contest server was down ;-(
Re: MessagePack
On Tuesday, 10 April 2012 at 19:31:49 UTC, Andrej Mitrovic wrote: On 4/10/12, Masahiro Nakagawa repeate...@gmail.com wrote: Hi Andrej, Sorry, I wasn't aware that this thread. I just deleted the old repository ;) Great! In japan, many companies use MessagePack to reduce the processing time. That's really cool. So D is popular in Japan? Now increasing. I wrote D article titled The Design and Evolution of D at programming magazine. (See http://longgate.co.jp/books/grimoire-vol2.html . Currently, I am working on new article for vol.3) I sometimes translate other language scripts into D for spreading how to write D. In addition, we(Me, SHOO, Kenji and other D programmers) help the D newbies in d-users, weblog and Twitter. Yesterday, one game developer started D instead of Ruby! And kaz uses D for developing product at usagee company :)
Re: MessagePack
Hi Andrej, Sorry, I wasn't aware that this thread. I just deleted the old repository ;) On Saturday, 24 March 2012 at 05:31:10 UTC, Andrej Mitrovic wrote: On 3/24/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: https://github.com/msgpack/msgpack-d Btw, thank you very much for your hard work Masahiro Nakagawa! Your serialization library has reduced my waiting time by over 20 seconds (I used Json before even though I didn't need a human-readable format). Thanks! In japan, many companies use MessagePack to reduce the processing time. I also use MessagePack in companies job and communicate other languages :) Masahiro
Re: Three Unlikely Successful Features of D
On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu wrote: I plan to give a talk at Lang.NEXT (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with the subject above. There are a few features of D that turned out to be successful, in spite of them being seemingly unimportant or diverging from related consecrated approaches. What are your faves? I have a few in mind, but wouldn't want to influence answers. Thanks, Andrei 1. Compile time reflection This feature enables MessagePack to (de)serialize existing class and struct :) 2. Template friends Easy syntax, static if(and is), alias, mixin and other features are very useful. An essential parts ingredient to write D program. 3. Built-in array and slice I heavily use this feature in many cases. Template engine, complex computation and network programming :) Masahiro
Re: GDC goes github
On Monday, 19 March 2012 at 22:39:18 UTC, Iain Buclaw wrote: On Monday, 19 March 2012 at 00:45:44 UTC, Iain Buclaw wrote: On Monday, 19 March 2012 at 00:22:48 UTC, Walter Bright wrote: On 3/18/2012 5:39 AM, Iain Buclaw wrote: I've been told to cue Walter asking to rename the organisation to D-Programming-GDC. :o) Done. I must admit I did not anticipate you creating a new repository. Thanks! I'll be sure to move the bits I need across. OK, repository moved: https://github.com/D-Programming-GDC Apologies for anyone who started following the other. I promise I shan't do it again. ;) Great!! I am watching this repository :)
Re: D Conference 2012 - Sep 26-29 at the Banker's Suite and Ballroom in Astoria, Oregon
Good news! I plan to travel abroad :) Masahiro On Wednesday, 22 February 2012 at 22:07:26 UTC, Walter Bright wrote: Pricing isn't set yet, nor has a web site been set up yet, this is just a heads up to reserve the dates on your calendar, and start thinking about that presentation you want to do! The general idea is: Wed evening - meet greet at the Banker's Suite Thu-Fri - presentations at the Banker's Ballroom Sat - discussion groups If your company wants to set up a booth or a table, or be a sponsor, please contact me.
Released fluent-logger-d
Hi guys, I announce the client library for Fluentd. Fluentd is a missing log collector. It's a hot project. If you want to know the overview of Fluentd, the slide is on slideshare. http://www.slideshare.net/treasure-data/fluentd-meetup-in-japan-11410514 And document is here: http://fluentd.org/doc/ I wrote a client library for D. https://github.com/fluent/fluent-logger-d Now, Fluentd has many plugins (mongodb, couchdb, scribe, s3 and more). Using this client, we can write a structured event to some sources via Fluentd. Simple example is below: https://github.com/fluent/fluent-logger-d/blob/master/example/post.d If you design a architecture, please consider Fluentd to collect logs :) Masahiro
Re: D1, D2 and the future of libraries
My existing and developing libraries support only D2 :) Masahiro On Sun, 22 Jan 2012 01:07:49 +0900, Stewart Gordon smjg_1...@yahoo.com wrote: For the last however long, I've been still programming mostly in D1, but aiming to keep my libraries compatible with both D1 and D2. But changes in D2 have made this more of a challenge. I've also been put off switching to D2 by the wait for D1 to be finished. Now the plan to discontinue D1 at the end of the year has been announced. And I'm wondering what to do with my libraries. How many people here are still using D1? What are those of you who write libraries mainly doing? (a) supporting only D1? (b) supporting only D2? (c) releasing separate D1 and D2 versions? (d) using versioning to support both with one set of code files? If practically everyone's using D2 now, maybe I'll migrate my libraries to it. If, OTOH, there's still real demand for D1 libraries, I'll continue to support D1. I might have to see how supporting D2 as well works out. It seems I'll have to abandon the idea of keeping the code compatible with the D spec as of DMD 1.00. It seems the reasons for doing this never happened anyway, and there doesn't seem to be an equivalent milestone in D2. Thoughts? Stewart.
Re: A nice way to step into 2012
On Tuesday, 27 December 2011 at 04:25:00 UTC, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc Andrei This change is cool! Masahiro
Re: CURL Wrapper: Vote Thread
Yes! Masahiro On Sun, 18 Dec 2011 04:36:15 +0900, dsimcha dsim...@yahoo.com wrote: The time has come to vote on the inclusion of Jonas Drewsen's CURL wrapper in Phobos. Code: https://github.com/jcd/phobos/blob/curl-wrapper/etc/curl.d Docs: http://freeze.steamwinter.com/D/web/phobos/etc_curl.html For those of you on Windows, a libcurl binary built by DMC is available at http://gool.googlecode.com/files/libcurl_7.21.7.zip. Voting lasts one week and ends on 12/24.
Re: Garbage collection book
On Wed, 05 Oct 2011 15:06:35 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: http://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795/ref=sr_1_1?s=booksie=UTF8qid=1317790242sr=1-1 I heard it's good. Narihiro Nakamura (a.k.a author of japanese GC book) said This is great book!. I want to read this book if time permits. Masahiro
Re: Clean-up of std.socket
On Tue, 13 Sep 2011 04:13:47 +0900, Sean Kelly s...@invisibleduck.org wrote: Looks much nicer than the current std.socket. A few random comments from a quick scan of the code: [snip] As an aside… From your comments, I gather that you're not terribly happy with certain design requirements imposed by the existing std.socket. Why not create an entirely new API in std.socket2 and not worry about it? Would your design change enough to warrant doing this? I think we should create new Socket API(My old post at Phobos ML was the first step). I will restart more rewrite with new project. Of course, this patch is useful to improvement current std.socket.
Re: D async I/O library by Matt Jones
On Sun, 11 Sep 2011 09:37:28 +0900, Vladimir Panteleev vladi...@thecybershadow.net wrote: On Sat, 10 Sep 2011 20:23:44 +0300, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Just found this: https://launchpad.net/diohelper D1/Tango. Surprising, D2's closures would be a boon for something like this (and allow writing code in true NodeJS-like manner). I don't like Node.js approach. It causes callback hell ;( I like Haskell's IO. But, we need smart IO manager if implement such IO. Unfortunately, it is very difficult...
Re: Allocators/region allocator proposal overhaul
On Mon, 12 Sep 2011 01:51:02 +0900, dsimcha dsim...@yahoo.com wrote: 8. The high-level, templated allocator functions now have a default implementation in terms of lower-level allocator functionality, provided by the TypedAllocatorMixin mixin in std.allocators.allocator. The idea is that an allocator may have better ways of accomplishing this stuff, but this mixin is usually a reasonable default and will avoid code duplication across allocators. I'm leery of including it in the DynamicAllocator interface, though, because for some allocators it's just plain wrong. For example, the default array() implementation just plain wouldn't work with RegionAllocator for huge ranges. I think Default(Templated)AllocatorFunctions are better than TypedAllocatorMixin. TypedAllocator is not clear for me. I will read documents and codes later.
Re: Allocators/region allocator proposal overhaul
On Mon, 12 Sep 2011 04:37:17 +0900, dsimcha dsim...@yahoo.com wrote: == Quote from dsimcha (dsim...@yahoo.com)'s article == Quote from Masahiro Nakagawa (repeate...@gmail.com)'s article On Mon, 12 Sep 2011 01:51:02 +0900, dsimcha dsim...@yahoo.com wrote: 8. The high-level, templated allocator functions now have a default implementation in terms of lower-level allocator functionality, provided by the TypedAllocatorMixin mixin in std.allocators.allocator. The idea is that an allocator may have better ways of accomplishing this stuff, but this mixin is usually a reasonable default and will avoid code duplication across allocators. I'm leery of including it in the DynamicAllocator interface, though, because for some allocators it's just plain wrong. For example, the default array() implementation just plain wouldn't work with RegionAllocator for huge ranges. I think Default(Templated)AllocatorFunctions are better than TypedAllocatorMixin. TypedAllocator is not clear for me. I will read documents and codes later. If you mean just making functions like T newArray(Allocator)(Allocator allocator, size_t size), etc., I've mentioned before that having the type available to the allocator is often useful and therefore these defaults need to be overrideable. Otherwise, please clarify. Oh wait a minute, do you just mean the name of the mixin template? If so, I completely agree that your suggested name is better. Yes. I mentioned the name of mixin template.
Re: Orange 1.0.0 beta - serialization library
On Sun, 21 Aug 2011 02:45:20 +0900, dsimcha dsim...@yahoo.com wrote: On 8/20/2011 12:50 PM, Andrej Mitrovic wrote: Masahiro Nakagawa seems to be working on msgpack: https://bitbucket.org/repeatedly/msgpack4d/ Yeah, this does look quite useful. I tried it a few weeks ago and ran into a couple showstopper bugs. I filed them and he fixed them, but I never got around to trying it again. I actually think that since both are very commonly needed things and satisfy completely different niches, Orange and msgpack4d might both eventually have a rightful place in Phobos. I agree. In the past, I mentioned this point ;) Orange would be recommended when portability and serializing as many types as possible are important, and msgpack4d would be recommended when speed and space efficiency are the primary concerns. Yes for MessagePack. In addition, communicating other language is important like JSON. P.S. My D libraries moved to github. msgpack4d is here. https://github.com/msgpack/msgpack-d FTTB, bitbucket is available.
Re: Orange 1.0.0 beta - serialization library
On Sun, 21 Aug 2011 05:28:33 +0900, Jacob Carlborg d...@me.com wrote: On 2011-08-20 19:45, dsimcha wrote: On 8/20/2011 12:50 PM, Andrej Mitrovic wrote: Masahiro Nakagawa seems to be working on msgpack: https://bitbucket.org/repeatedly/msgpack4d/ Yeah, this does look quite useful. I tried it a few weeks ago and ran into a couple showstopper bugs. I filed them and he fixed them, but I never got around to trying it again. I actually think that since both are very commonly needed things and satisfy completely different niches, Orange and msgpack4d might both eventually have a rightful place in Phobos. Orange would be recommended when portability and serializing as many types as possible are important, and msgpack4d would be recommended when speed and space efficiency are the primary concerns. If it's possible to extract a value given a key with messagepack I think it would be possible to use messagepack as an archive for Orange. Since messagepack supports maps every type Orange can serialize should be possible serialize with messagepack, although probably not as efficient as regular messagepack. I agree. Unfortunately, Orange with MessagePack decreases MessagePack merits...
Re: Std.path: Final Vote
On Fri, 05 Aug 2011 22:26:39 +0900, dsimcha dsim...@yahoo.com wrote: My apologies for not announcing this yesterday. For some reason I thought today was the official end of review. Anyhow, Lars Kyllingstad's new std.path module, which has been in review for the past 3 weeks, is up for vote. Please vote yes or no in this thread. Code: https://github.com/kyllingstad/phobos/blob/std-path/std/path.d Docs http://www.kyllingen.net/code/std-path/phobos-prerelease/std_path.html Voting ends next Friday, August 12, since it started a day late. Yes!!
Re: std.concurrency wrapper over MPI?
On Mon, 08 Aug 2011 01:08:39 +0900, dsimcha dsim...@yahoo.com wrote: On 8/7/2011 12:01 PM, Lutger Blijdestijn wrote: dsimcha wrote: On 8/7/2011 11:36 AM, Jacob Carlborg wrote: Currently, the only available format is XML. Ok, I'll look into writing a binary archiver that assumes that the CPU architecture on the deserializing end is the same as that on the serializing end. If it works, maybe Orange is a good choice. Just in case you missed it, the messagepack protocol has a D implementation which seems to be what you're looking for: http://msgpack.org/ The last commit on bitbucket reveals it should be compatible with 2.054. Perhaps it can be adapted as an archiver for Orange. Ok, this sounds great. Again, though, it would be great to get serialization into Phobos. (I don't know whether messagepack is suitable in its current form, because I haven't looked in detail.) I was vaguely aware of a messagepack implementation for D, but I didn't realize it was still maintained and didn't know where it was hosted. I maintain MessagePack for D and use this library as internal tool of my job. I will move from bitbucket to github. D programmer mainly uses git and github is more useful than bitbucket. Masahiro
Re: Has anyone ever tested CDGC (Concurrent D GC)?
On Tue, 19 Jul 2011 21:53:01 +0900, Trass3r u...@known.com wrote: I made sure it was functional back when I added the branch. The runtime code is horribly out of date though. What needs to happen is for the branch to be re-created from main. I also need to see if Leandro has updated his CDGC since the branch was created. What we really need is to put it into the master branch in its own directory and add some makefile magic so you can easily switch GCs when compiling druntime (just like Tango does) instead of having it rot in some branch that nobody even knows about. I'm already working on this and managed to compile CDGC with latest druntime. Now it needs extensive testing and bug fixing. I am interested in Concurrent GC. But, I have a question about CDGC. AFAIK, other language runtimes use thread for concurrent processing. Why use fork()? What is the merit of fork() approach? Masahiro
Re: Has anyone ever tested CDGC (Concurrent D GC)?
On Tue, 19 Jul 2011 22:57:47 +0900, Trass3r u...@known.com wrote: I am interested in Concurrent GC. But, I have a question about CDGC. AFAIK, other language runtimes use thread for concurrent processing. Why use fork()? What is the merit of fork() approach? I don't know. On Windows you can't use fork anyway and we have to figure out an alternative way. Maybe he explains it in his thesis, but it's only available in Spanish: http://www.llucax.com.ar/proj/dgc/index.html Thanks for the link! But, I didn't read Spanish...
Re: Has anyone ever tested CDGC (Concurrent D GC)?
On Wed, 20 Jul 2011 00:25:58 +0900, Robert Jacques sandf...@jhu.edu wrote: On Tue, 19 Jul 2011 10:19:09 -0400, Masahiro Nakagawa repeate...@gmail.com wrote: On Tue, 19 Jul 2011 22:57:47 +0900, Trass3r u...@known.com wrote: I am interested in Concurrent GC. But, I have a question about CDGC. AFAIK, other language runtimes use thread for concurrent processing. Why use fork()? What is the merit of fork() approach? I don't know. On Windows you can't use fork anyway and we have to figure out an alternative way. Maybe he explains it in his thesis, but it's only available in Spanish: http://www.llucax.com.ar/proj/dgc/index.html Thanks for the link! But, I didn't read Spanish... snapshot GC I have heard this by A Real-Time Garbage Collection for Java using Snapshot Algorithm. I understand a basic mechanism(above article uses a thread instead of fork()). Hmm... I want to see a comparison of fork() and thread. There are two other alternative, modern GCs that I know of which fit system programming languages like D. One used a kernel patch to trap hardware writes efficiently, allowing one to bolt a traditional concurrent GC onto a system's language. Which, while cool, isn't practical until OS APIs support it out of the box. The other is thread-local GCs, which according to Apple, have roughly equivalent performance to existing concurrent GCs. Given shared and immutable, thread-local GC's make a lot of sense for D and can be combined with other concurrent options should they be/become available. I didn't know the former. Thanks for the information. Latter approach is similar to Erlang. Erlang provides GC per-process and I like this approach. Is Thread-local GC in D realistic? D allows global mutable state...
Re: D2 Web-Framework
Hi Robert, On Thu, 14 Jul 2011 19:49:10 +0900, Robert M. Münch robert.mue...@robertmuench.de wrote: dynamic content and simple output generation. In this point, I implement simple template engine called Mustache(Pure D and single file). https://bitbucket.org/repeatedly/mustache4d/overview Sorry, I don't have other libraries. Masahiro
Re: Curl wrapper
On Tue, 24 May 2011 04:50:10 +0900, jdrewsen jdrew...@nospam.com wrote: Den 23-05-2011 21:02, Masahiro Nakagawa skrev: On Wed, 18 May 2011 20:07:01 +0900, Jonas Drewsen jdrew...@nospam.com wrote: On 18/05/11 10.09, Johannes Pfau wrote: jdrewsen wrote: But I would rather stop here feature wise and wrap this thing up. I would like to focus my efforts on a candidate for std.net.event/reactor/proactor module. Have you already started working on std.net.event? Do you plan to base that on libev / libevent? I'll finish the curl wrapper before starting on it. I have had a look at libev/event before and they are very nice libs. But I think I'll have to implement it from scratch for two reasons: 1, AFAIK we cannot include code in std phobos that is not boost licensed or a license as liberal. libev for example requires you to distribute the license with your software. 2, It introduces a dependency to an external project in phobos. Currently no dependencies are present. This makes phobos very easy to install and use out of the box. The optimal solution to these problems from my point of view would be to get that much discussed package tool in place soon (CPAN,apt alike). Heck, now I think about it maybe I should do that before any std.net stuff. Let's see how the wind blows - many interesting projects :) Good! Last year, I tried to implement std.event. In Windows, using IOCP with Overlapped-IO for proactor. Others, IO multiplexing with worker-thread for proactor emulation. But Johannes already started implementing event module using libev, so I deleted this task from my tasks. If you have any code for inspiration or that could be used as a base I would very much like to see/use it. Especially if it is under Boost license. My old design is based on Boost/Asio. After I rewrote std.socket(including other utilities such as DNS, IPAddresses), I stopped implementing task. I would like to create reactor initially and proceed to build the proactor on top of that (not on top for windows and IOCP of course). Reactor and proactor designs each have their forces and therefore I do not think targeting a proactor only design is the way to go. I agree. General library should provides two approaches. My main purpose is high-performance RPC. In such cases, Proactor is better(Java's Netty provides good abstraction APIs).
Re: std.log available for viewing
On Sun, 29 May 2011 08:40:16 +0900, Jose Armando Garcia jsan...@gmail.com wrote: The implementation and documentation for std.log is ready for viewing. You can take a look at the doc at http://jsancio.github.com/phobos/phobos/std_log.html. The source code is at https://github.com/jsancio/phobos/blob/master/std/log.d. I had to make some changes to druntime to get the thread id. The module will work without the changes but you wont to see thread ids in your log messages. I will look into sending a pull request to druntime, in the meantime you can apply the attached patch to your druntime if you want to see thread ids in the log. Let me know if you have any comments or suggestions! Thanks, - every, first, after These are useful? I can't image the use cases. I think 'when(cond)' is enough. - fatal, error and other global variables 'logger.error(hoge)' seems to be better than 'error(hoge)'. error(hoge) is not clear in complicated context. In addition, I think defining general name variables on global scope is bad. Masahiro
Re: Curl wrapper
On Wed, 18 May 2011 20:07:01 +0900, Jonas Drewsen jdrew...@nospam.com wrote: On 18/05/11 10.09, Johannes Pfau wrote: jdrewsen wrote: But I would rather stop here feature wise and wrap this thing up. I would like to focus my efforts on a candidate for std.net.event/reactor/proactor module. Have you already started working on std.net.event? Do you plan to base that on libev / libevent? I'll finish the curl wrapper before starting on it. I have had a look at libev/event before and they are very nice libs. But I think I'll have to implement it from scratch for two reasons: 1, AFAIK we cannot include code in std phobos that is not boost licensed or a license as liberal. libev for example requires you to distribute the license with your software. 2, It introduces a dependency to an external project in phobos. Currently no dependencies are present. This makes phobos very easy to install and use out of the box. The optimal solution to these problems from my point of view would be to get that much discussed package tool in place soon (CPAN,apt alike). Heck, now I think about it maybe I should do that before any std.net stuff. Let's see how the wind blows - many interesting projects :) Good! Last year, I tried to implement std.event. In Windows, using IOCP with Overlapped-IO for proactor. Others, IO multiplexing with worker-thread for proactor emulation. But Johannes already started implementing event module using libev, so I deleted this task from my tasks. My pending projects need event module. I expect your efforts! Masahiro P.S. cURL wrapper is nice. I wait this :)
Re: [GSOC] Database API draft proposal
On Wed, 06 Apr 2011 05:38:02 +0900, Christian Manning
cmanning...@gmail.com wrote:
Hello all,
This is the second draft and a lot of changes have been made. Hopefully
it's a better overall proposal and I look forward to anybody's feedback
:)
-
Synopsis
An API for databases is a common component of many languages' standard
library, though Phobos currently lacks this. This project will remedy
this by providing such an API and also begin to utilise it with
interfaces for some Database Management Systems (DBMS). I believe this
will benefit the D community greatly and will help bring attention and
developers to the language.
Details
---
Piotr Szturmaj has began working on DDB [1] which has a PostgreSQL
clietn written in D as well as some database neutral features such as
the DBRow type for storing rows from a database. Piotr and I have agreed
to collaborate such that DDB will continue with Piotr at the helm, and I
will begin implementing other DBMS clients based around his work. Once
there is another implementation, work will then begin on extracting a
common interface which will form the API.
For example:
module database;
interface DBConnection {
//method definitions for connecting to databases go here.
}
Then in an implementation of MySQL:
module mysql;
import database;
class Connection : DBConnection {
//implement defined methods tailoring to MySQL.
}
Exactly what will go in to these interfaces will depend on the
differences between the DBMSs, but they all share many things. The API
should also be developed in conjunction with the D community to minimise
any fallout of decisions made.
The DBMSs I plan to implement are MySQL and SQLite. Unlike PostgreSQL,
MySQL doesn't seem to have a long-term and stable client-server
protocol. As a result of this I will be wrapping around the MySQL C API
(v5.1) to bring it to D. SQLite will also undergo the same process.
Because of this, these clients are not likely to get into Phobos and so,
if the API does then these will be an external package.
If this project is completely successful, there will be a database API
and at least three DBMS clients ready for use in D applications. The
minimum amount of functionality for this to be considered successful
would be an API that is mostly utilised by the PostgreSql and MySQL
clients. In this scenario there will still be two usable clients,
however, perhaps the API is not totally complete and neither is the
SQLite client.
[snip]
References
--
[1] https://github.com/pszturmaj/ddb
http://pszturmaj.github.com/ddb/db.html
Hmm.. In what way is your new module different from DDBI?
What's the new features?
Masahiro
Re: [GSOC] Database API
On Sun, 27 Mar 2011 07:11:01 +0900, David Nadlinger s...@klickverbot.at wrote: On 3/26/11 12:44 AM, Masahiro Nakagawa wrote: Currently, many databases exist. * SQL based: MySQL, PostgresSQL, SQLite, etc.. * KVS: Cassandra, HBase, Kumofs, Redis, etc... * Document Oriented: MongoDB, CouchDB, etc... I think next Database API should support these types. I don't think this is the way to go, as there is a huge conceptional difference between relational database systems and »NoSQL« systems such as, say, CouchDB or Cassandra. It's an open question. Ruby / Rails has Arel (note that Arel is data access abstraction, not database access abstraction. But Database access is a part of data access). Haskell has Database.Persistent. I think other languages will support similar library in the future. How would such a unified API look like? I don't have a detail. I already implemented it if I had a detailed design. In my D tasks, database related task is low priority...
Re: TempAlloc (Was: Library Development: What to finish/flesh out?)
On Sun, 27 Mar 2011 12:09:03 +0900, dsimcha dsim...@yahoo.com wrote: On 3/18/2011 2:56 AM, Don wrote: 3. TempAlloc: A memory allocator based on a thread-local segmented stack, useful for allocating large temporary buffers in things like numerics code. Also comes with a hash table, hash set and AVL tree optimized for this allocation scheme. The advantages over plain old stack allocation are that it's independent of function calls (meaning you can return pointers to TempAlloc-allocated memory from a function, etc.) and it's segmented, meaning you can allocate huge buffers w/o risking stack overflow. Its main weakness is that this stack is not scanned by the GC, meaning that you can't store the only reference to a GC-allocated piece of memory here. However, in practice large arrays of primitives are an extremely common case in performance-critical code. I find this module immensely useful in dstats and Lars Kyllingstad uses it in SciD. Getting it into Phobos would make it easy for other scientific/numerics code to use it. Completion state: Working and used. Needs a litte cleanup and documentation. (Phobos candidate) This is #1. Far and away. Belongs in druntime. I would use it instantly in BigInt. This is not up for official review yet because std.net.isemail and std.parallelism (and possibly more stuff depending on how we manage the review queue) are ahead of it. If you want a sneak preview: Code: https://github.com/dsimcha/TempAlloc Docs: http://cis.jhu.edu/~dsimcha/d/phobos/core_tempalloc.html I put in a few small, tangentially related memory allocation functions that I've wanted in druntime/Phobos for awhile in this proposal, too. alignedMalloc() and alignedFree() are used by TempAlloc but can be made private if people don't like them. newVoid() is not used by TempAlloc and might fit better in std.array, but I think it belongs somewhere in Phobos or druntime. Now, I am thinking of light-weight process for concurrency. Your TempAlloc(segmented stack) seems to be a good parts for implementing such feature :) Masahiro
Re: [GSOC] Database API
On Fri, 25 Mar 2011 02:48:14 +0900, Christian Manning cmanning...@gmail.com wrote: Hi, I'm a second year student at De Montfort University studying Computer Science. I am very much interested in working on the database API idea that is proposed at http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas#DatabaseAPI (I was also quite interested in the containers idea, but it looks like someone else wants to do that) I have limited experience with database libraries but have begun to study the JDBC API (in my small amount of spare time only as term doesn't finish for another 2 weeks for me and I still have assignments). 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? Currently, many databases exist. * SQL based: MySQL, PostgresSQL, SQLite, etc.. * KVS: Cassandra, HBase, Kumofs, Redis, etc... * Document Oriented: MongoDB, CouchDB, etc... I think next Database API should support these types. AFAIK, DDBI supports only SQL based interface. In Ruby, Rails 3 has Arel. Arel seems to be a good query abstraction. https://github.com/rails/arel Arel's concept may help you :) Masahiro
Re: Google Summer of Code 2011 application
On Wed, 09 Mar 2011 04:37:43 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I just submitted an application for GSoC 2011 on behalf of Digital Mars. Please review and contribute to the project ideas page: http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas Bindings to popular IPC/RPC protocols such as Protocol Buffers and Apache Thrift Key Skills: Intimate knowledge of cross-machine communication protocols. Large-scale programming using D requires bindings to cross-machine and cross-language communication protocols. Such include Google's Protocol Buffers, Apache Thrift, and others. D's standard library currently includes no such protocol implementation. Providing such would motivate adoption of D for large-scale development. Protocol Buffers and Thrift need code generation using IDL unlike MessagePack, BERT, etc. Such protocols are acceptable to Phobos?
Re: Google Summer of Code 2011 application
On Wed, 09 Mar 2011 04:37:43 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I just submitted an application for GSoC 2011 on behalf of Digital Mars. Please review and contribute to the project ideas page: http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas Networking I think high level networking is a part of IO. But unfortunately, Phobos does not have IO model. Does this idea include new IO model discussion?
Re: Mustache template engine
On Fri, 25 Feb 2011 17:29:53 +0900, dennis luehring dl.so...@gmx.net
wrote:
Am 24.02.2011 18:57, schrieb Masahiro Nakagawa:
3 weeks ago, I discussed template engine with Goro Fuji(a.k.a Xslate
author).
In the process, I noticed D does not have template engine library.
So I wrote the D version of Mustache.
https://bitbucket.org/repeatedly/mustache4d/src
would be great to have this available at compiletime - something like an
write(ln) with typeckecks and block functionality :)
with a nice inner mixin that generates an frontend for the template-vars
a little bit like the
http://www.digitalmars.com/d/2.0/phobos/std_bitmanip.html bitfield!
template
example-style refering to your basic.d example
--- basic.mustache ---
Hello {{name:%s}}
You have just won ${{value:%i}}!
{{#in_ca}}
Well, ${{taxed_value:%f}}, after taxes.
{{/in_ca}}
---
alias MustacheEngine!(string,import(basic.mustache))
My_Special_Template;
void main()
{
My_Special_Template my_special_template;
my_special_template.name = Chris;
my_special_template.value = 1;
auto in_ca_section = my_special_template.in_ca.create();
in_ca_section.taxted_value = 1 - (1 * 0.4);
write(my_special_template.render());
}
In the old days, I implemented the compile-time template engine using
similar approch :)
Re: Mustache template engine
On Fri, 25 Feb 2011 22:04:50 +0900, dennis luehring dl.so...@gmx.net wrote: In the old days, I implemented the compile-time template engine using similar approch :) the old days (of D)? A year and a half. why the switch to pure runtime based? When CMS using compile-time template exists, how does user update template file? Masahiro
Re: Mustache template engine
On Sat, 26 Feb 2011 01:08:06 +0900, dennis luehring dl.so...@gmx.net wrote: Am 25.02.2011 15:26, schrieb Masahiro Nakagawa: the old days (of D)? A year and a half. code available? No. It was a joke program for me. why the switch to pure runtime based? When CMS using compile-time template exists, how does user update template file? ok but when used as (for example) debugging help is no need for runtime loading, for example i use templates likes this for graph debugging - but it would be nice to reduce the runtime loading (even my large string) to compile-time :) I agree this point.
Mustache template engine
3 weeks ago, I discussed template engine with Goro Fuji(a.k.a Xslate author). In the process, I noticed D does not have template engine library. So I wrote the D version of Mustache. https://bitbucket.org/repeatedly/mustache4d/src Mustache is a logic-less template. http://mustache.github.com/ Implementing this library was nice for a change. P.S. I don't test on Windows and 64bit Linux... Masahiro
Re: std.xml should just go
On Thu, 03 Feb 2011 08:33:42 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: For a while we've espoused the strategy of keeping std.xml in Phobos until something better comes along. But recently we've started to rethink that. Pretty much everyone who tries std.xml ends up disappointed. Anyone who wants to bash D has std.xml as an easy pick. Anyone who looks at speed comparisons sees std.xml there like a sore thumb. Finally, the mere existence of a package, no matter how inadequate, stifles the initiative of others working on it. This all makes std.xml a net liability. It's not better than nothing; it's worse than nothing. Should we nuke it? Good! Masahiro
Re: std.unittests [updated] for review
On Mon, 24 Jan 2011 23:34:49 +0900, Jonathan M Davis jmdavisp...@gmx.com wrote: In case you didn't know, I have a set of unit test helper functions which have been being reviewed for possible inclusion in phobos. Here's an update. Most recent code: http://is.gd/F1OHat Okay. I took the previous suggestions into consideration and adjusted the code a bit more. However, most of the changes are to the documentation (though there are some changes to the code). Some of the code duplication was removed, and the way that some of the assertPred functions' errors are formatted has been altered so that values line up vertically, making them easier to compare. The big change is the docs though. There's now a fake version of assertPred at the top with an overall description for assertPred followed by the individual versions with as little documentation as seemed appropriate while still getting all of the necessary information across. A couple of the functions still have irritatingly long example sections, but anything less wouldn't get the functionality across. In any case. Here's the updated code. Review away. Andrei set the vote deadline for February 7th, at which point, if it passes majority vote, then it will go into Phobos. The number of functions is small enough now (thanks to having consolidated most of them into the fantastically versatile assertPred) that it looks like it will likely go in std.exception if the vote passes rather than becoming a new module. So, the std.unittests title has now become a bit of a misnomer, but that's what I've been calling it, so it seemed appropriate to continue to label it that way in the thread's title. I vote Andrei's suggestion, std.exception is better than new std.unittests. I think testing module should provide more features(e.g. Mock, Stub...). Your helpers help assert writing style but not help testing. In addition, std.exception already defined similar functions. Masahiro
Re: eliminate junk from std.string?
On Wed, 12 Jan 2011 08:00:51 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: 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. ++vote :) Masahiro
Re: Helper unit testing functions in Phobos (possible std.unittests)
On Sat, 06 Nov 2010 13:37:02 +0900, Jonathan M Davis jmdavisp...@gmx.com wrote: I'm proposing a possible new module for phobos which would be called std.unittests. The code and DDoc file can be found here: http://is.gd/gLH9Q Or you can look at the code here directly (though it has poor highlighting): http://ideone.com/EOlod The module contains a set of helper functions for unit tests which are an improvement over simply using assert. I have them to be very helpful in the unit tests in my proposal for std.datetime. My unit tests are more concise, easier to read, and much easier to debug because of them. assertEqual() and assertExcThrown() have been particularly useful. assert is a great tool, but simply telling you that an assertion failed is not as useful as telling you _how_ it failed, and a function like assertExcThrown() (which, as you may guess, asserts that a particular exception was thrown by a particular function call) really reduces the boiler plate code that you have to write for testing what it tests. So, I find such helper functions are extremely useful. Because I have used them so extensively in std.datetime, they are pretty much either going to have to be added as a module to Phobos or added as private helper functions in std.datetime. Personally, I think that they (or something very similar to them) merit being added as a new module in Phobos, which can be expanded upon as others come up with particularly useful unit testing functions. So, I'm requesting that the folks here on the list have a look at my module and review it for possible inclusion in Phobos. I don't know what Andrei's position on them is (he rightly focused his review of my datetime code on the date/time functionality and API rather than its unit tests and didn't mention my unit testing functions at all), but I think that such a module would be of great worth and would like other's opinions on it. - Jonathan M Davis I don't know this module's usability, but is getExcMsg useful? I can't imagine useful situation. In addition, I grepped your datetime.d and getExcMsg not found :( If possible, I want the mock, stub and related features. Masahiro
Re: First big PITA in reallife D project
On Tue, 19 Oct 2010 20:33:29 +0900, Stephan s...@extrawurst.org wrote: Hey guys I wanted to discuss my first major depressing experience with D in a reallife project. First off here is the according bug report : http://d.puremagic.com/issues/show_bug.cgi?id=4951 I think this bug is related to http://d.puremagic.com/issues/show_bug.cgi?id=4344 I replied similar post in NG. http://lists.puremagic.com/pipermail/digitalmars-d/2010-September/082814.html I want to know the best solution.
Re: Weird writeln behavior with associative arrays
On Sat, 16 Oct 2010 00:04:22 +0900, Jens Mueller jens.k.muel...@gmx.de
wrote:
Hi,
this program
import std.stdio;
void main() {
double[string] foo;
foo[test] = 10;
foo[atadfest] = 10;
// fails if foo.length 1
writeln(foo);
}
fails with:
phobos/std/format.d(1088): Enforcement failed
Am I not allowed to to this? If I have only one element, then it works
as expected. If I change double to int, then I get test:10 a:10. So
somehow only the first character is displayed. Maybe a phobos bug? Any
ideas?
I'm using Linux and latest dmd.
$ dmd | head -n1
Digital Mars D Compiler v2.049
Jens
SHOO has already fixed this problem.
http://www.dsource.org/projects/phobos/changeset/2030
Re: bash completion for dmd and rdmd
On Mon, 13 Sep 2010 01:54:16 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 9/12/10 10:48 CDT, Lutger wrote: It's ugly but it seems to work: http://dl.dropbox.com/u/6777848/d-completion.sh Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc or ~/.bash_profile: .. d-completion.sh It will enable autocomplete for dmd and rdmd in bash. You may need to install the bash-completion package of your distro. Cool! This should be on D's website. Any zsh completion experts to provide something similar for zsh? I'm not a zsh completion experts, but I use following script. http://dl.dropbox.com/u/374829/_dmd
Re: Thread + socket = (shared) problem? (2.048)
On Tue, 07 Sep 2010 18:48:22 +0900, Bane branimir.milosavlje...@gmail.com wrote: Please show your environment. Windows? WinXP sp2, phenom quad core. Current std.socket uses static ~this for WSACleanup. In this case, main thread calls static ~this before MyThread executes new TcpSocket. std.socket workarounds: 1. static ~this - shared static ~this Main thread calls WSAStartup and WSACleanup. 2. Create reference count sample code - http://ideone.com/vRMO0 3. other? I don't know the best way.
Re: forks/pipes and std.socket
On Mon, 06 Sep 2010 05:32:28 +0900, Nick Sabalausky a...@a.a wrote:
This may be a stupid question:
Does std.socket encorporate or replace pipe usage? Ie, if I'm going to do
something along the lines of (psuedo-code):
auto parentToChild = pipe();
auto childToParent = pipe();
if(fork())
{
// talk to other process
}
else
{
// talk to other process
}
Is there anything in std.socket, or any way of using it that would aid in
this sort of thing (ideally in a cross-platform way), or is it entirely
orthogonal to this?
Does anyone who's done this sort of thing in D before, on Win or Lin,
know
of anything else in particular to be aware of?
Unix domain socket?
http://lists.puremagic.com/pipermail/phobos/2010-July/001171.html
This socket I rewrote can communicate with other processes using
LocalEndpoint.
(Sorry, I don't know Windows environment).
Re: Using glog's design for Phobos?
On Thu, 26 Aug 2010 12:59:19 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Hello, At my workplace we're using Google's logging library glog (http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the more I use it, the more I like it. It's simple, to the point, and effective. I was thinking it would be great to adapt a similar design into Phobos. There will be differences such as use of regular argument lists instead of etc., but the spirit will be similar. What do you think? I am using glog and gtest in my project. These tools are very useful :) I think we need useful and handy logging module for Phobos. Yeah, glog is one of the candidates. Masahiro
Re: Orange - a serialization library
On Wed, 28 Jul 2010 06:10:21 +0900, Jacob Carlborg d...@me.com wrote: On 2010-07-27 15:13, BLS wrote: On 25/07/2010 16:08, Jacob Carlborg wrote: This if the first release of the Orange serialization library XML D2/Phobos problem solved ? Bjoern Yes, it's fixed. I'm including a modified version of the whole std.xml module, not pretty but it works. One question. http://dsource.org/projects/orange/browser/orange/xml/PhobosXML.d Why use string mixin? Masahiro
Re: Orange - a serialization library
On Wed, 28 Jul 2010 12:36:34 +0900, g g f...@spamme.cocor wrote: Masahiro Nakagawa Wrote: On Wed, 28 Jul 2010 06:10:21 +0900, Jacob Carlborg d...@me.com wrote: On 2010-07-27 15:13, BLS wrote: On 25/07/2010 16:08, Jacob Carlborg wrote: This if the first release of the Orange serialization library XML D2/Phobos problem solved ? Bjoern Yes, it's fixed. I'm including a modified version of the whole std.xml module, not pretty but it works. One question. http://dsource.org/projects/orange/browser/orange/xml/PhobosXML.d Why use string mixin? Masahiro Cause it isn't necessary for tango or even lexicaly incorrect for some versions of the compiler Thanks. I didn't know this technique. Hmm...
Re: Review: std.msgpack
Sorry for the delay. On Tue, 22 Jun 2010 13:47:19 +0900, Robert Jacques sandf...@jhu.edu wrote: Other little things, -Why isn't nil mapped to null? Where? MsgPack has a nil type which I assume is equivalent to null. So why isn't it simply included in the object serializer (and arguably also in the array and map serializer as well)? Sorry, I can't understand this statement. Nullable types(class, array and associative-array) is serialized to nil if null. Sorry. The comment was about redundancy. i.e. packNil = pack(null). I added pointer type (de)serialization. For that matter, packNil, packTrue, packFalse, etc are all redundant with pack(T). I removed packTrue, packFalse. Furthermore, stream, packArray, packMap and packRaw all should be internal routines. (Though, a rawPack(T)(T value) routine might not go amiss) I moved packRaw to internal method, but packArray and packMap should be public. MessagePack's array and map can contain any type. I can see the usefulness of the functionality, but for an end-user API, it is brittle and error-prone. For example: p.packArray(3).pack(5).pack(six); produces an incorrect msgPack stream. A better syntax would be: p.pack(5,six); or p.packArray(5,six); I know you're using pack(Types...) to mean pack(Types[0]).pack(Types[1])... but using it for variable type arrays is worth considering. For packMap, pack( [key: value], [5:six] ) could work, but packMap( [key: value], [5:six] ) or packMap(key,value,5,six) would avoid confusion with pack(Types...). I have thought about this point. In the result, I changed (Un)Packer API. It's true that your suggested syntax is better. Old packArray was renamed to beginArray and new packArray serializes container type using variadic arguments. Of course, Map too. - /* old */ packer.packArray(2).pack(true, 10); /* new */ packer.packArray(true, 10); // == packer.beginArray(2).pack(true, 10) - Thanks for pointing out this. Masahiro
Re: Forking problems on OS X 2.047
On Tue, 22 Jun 2010 06:32:21 +0900, Byron Heads wyverex.cyp...@gmail.com
wrote:
When I use fork I am getting a core.thread.ThreadException: Unable to
load thread state exception.
This is dmd 2.047 on OS X
I am trying to convert a small C application.
module fork;
import core.sys.posix.unistd,
std.stdio;
void main()
{
auto pid = fork();
if( pid 0 ) {
writeln( Parent );
} else if( pid == 0 ) {
writeln( Child );
} else {
writeln( Failed to fork! );
}
}
$ ./fork
Parent
Child
core.thread.ThreadException: Unable to load thread state
5 fork0x6de9 thread_suspendAll + 85
6 fork0xaff0
D2gc3gcx3Gcx11fullcollectMFPvZk + 32
7 fork0xafbd
D2gc3gcx3Gcx16fullcollectshellMFZk + 41
8 fork0xa0a2
D2gc3gcx2GC18fullCollectNoStackMFZv + 54
9 fork0x803c gc_term + 44
10 fork0xcef6
D2rt6dmain24mainUiPPaZi6runAllMFZv + 90
11 fork0xcdc6
D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv + 42
12 fork0xcd54 main + 168
13 fork0x1a85 start + 53
I tried different flags but the output is the same.
My environment too. Please put this bug into bugzilla.
Masahiro
Re: Review: std.msgpack
On Sun, 20 Jun 2010 04:27:08 +0900, Jacob Carlborg d...@me.com wrote: Serialization from base class was one of my goals when I implemented Orange. Good. But you need to register a function for that, until D2 fixes the getMembers method in TypeInfo_Class. You reported this bug? I couldn't find closest bug in bugzilla. Masahiro
Re: Review: std.msgpack
On Sun, 20 Jun 2010 02:08:07 +0900, Robert Jacques sandf...@jhu.edu
wrote:
On Sat, 19 Jun 2010 00:02:28 -0400, Masahiro Nakagawa
repeate...@gmail.com wrote:
mp_Object is based on std.json.JSONValue.
Variant can't have mp_pack method.
Hmm..., I check Variant again.
Well, std.json is an incomplete, alpha library that's buggy and
unreviewed. For example, the design is currently very C-ish with
structs, enums, functions and exceptions all being independent top level
constructs.
I checked Variant, but Variant[Variant] doesn't work... :(
If Phobos has std.serializer like Orange(or Doost.Serialization?),
I will implement MsgPackArchive.
But general serializer usually is low-performance and lacks some
features.
So when user wants performance, user will use Packer and Unpacker
directly.
I'd disagree, with regard to performance: there's no reason why a
general (cycle free) serializer would be slower than your direct
routines. A serializer's only job is to pack/unpack complex objects
correctly: the key advantage is that polymorphic objects/struct only
have to support one custom serialization routine/mixin. Also, separating
physical-encoding from logical-encoding allows for some very powerful
idioms. You could, for example, add cycle detection/support to msgpack
by having the serializer write in a micro-format on-top of msgpack.
Another, more important example is letting the user decide between an
array and a map representation for structs/objects. Using arrays for
objects is extremely brittle. If say, a new hire refactors a class from
A{ int x; int y;} to A{ int y; int x; } you now have an extremely hard
to find and track down logic bug in your program. To say nothing about
trying to upgrade an implementation. On the other hand, using maps for
objects adds a decent amount of overhead to the total serialized length.
Yeah, It's a implementation-dependent problem. So I wrote usually.
If Phobos supports good serializer, I will remove Packer and
direct-conversion Unpacker.
Other little things,
-Why isn't nil mapped to null?
Where?
MsgPack has a nil type which I assume is equivalent to null. So why
isn't it simply included in the object serializer (and arguably also in
the array and map serializer as well)?
Sorry, I can't understand this statement. Nullable types(class, array and
associative-array)
is serialized to nil if null.
For that matter, packNil, packTrue, packFalse, etc are all redundant
with pack(T).
I removed packTrue, packFalse.
Furthermore, stream, packArray, packMap and packRaw all should be
internal routines. (Though, a rawPack(T)(T value) routine might not go
amiss)
I moved packRaw to internal method, but packArray and packMap should be
public.
MessagePack's array and map can contain any type.
(Returns: this to method chain. = Returns: self. i.e. for method
chaining )
Changed.
Oh, as for packing real you'll need to use CustomFloat!(80) for cross
platform inter-op. Also, it shouldn't be @system: there's nothing
memory-unsafe about writing or reading them. Please don't abuse @system,
etc for meanings other their intended meanings.
I forgot this. CutstomFloat was already fixed by you and David in trunk.
I added 80bit floating point support for non-x86 environment.
Masahiro
Re: Review: std.msgpack
On Fri, 18 Jun 2010 23:05:45 +0900, Graham Fawcett fawc...@uwindsor.ca wrote: On Thu, 17 Jun 2010 21:29:50 -0700, Andrei Alexandrescu wrote: There's one larger submission that needs review - Masahiro Nakagawa's std.msgpack. I think it would be great if this community established a review process. +1! To do so, we should abstract away starting from at least one review :o). Here's Masahiro's work: code: https://dl.dropbox.com/u/374829/std/msgpack.d doc: https://dl.dropbox.com/u/374829/std/msgpack.html zip: https://dl.dropbox.com/u/374829/std_msgpack.zip (archives code and doc) Feel free to comment here. Nice! The docs should link to the MessagePack Format Spec page in the first paragraph. I had not known that MessagePack was an existing binary serialization format. http://redmine.msgpack.org/projects/msgpack/wiki/FormatSpec I was going to complain that this module didn't handle D-specific types like Variants, but now I see that this is out of scope. All right. I moved link to See_Also section in 1st paragraph. Just curious, why have MessagePack support in Phobos, instead of Packed Encoding Rules, BERT, BSON, Protocol Buffers, etc.? Not that this isn't a very useful module, but I'm curious about why this particular binary encoding. If it's a 'batteries included' thing (let's put as many useful modules as possible in the stdlib), then maybe a dotted name like 'std.serializer.msgpack' might be better, to give a proper home for 'std.serializer.per', etc.? I'm not sure this deserves the same 'top level billing' as, say, std.stdio or std.range; and eventually the toplevel namespace will be very cluttered (c.f. Python's stdlib). I like 'batteries included' approach(Python supports a diversity of modules). Of course, quality is the most important thing. I agree std.serializer.msgpack. In a perfect world, I would see this as an excellent member of a CPAN-like system for D, rather than a stdlib module. Since that doesn't exist yet, +1, but with a nested module name. D doesn't have CPAN-like system :'( Masahiro
Re: Review: std.msgpack
On Fri, 18 Jun 2010 23:36:54 +0900, Rory McGuire rmcgu...@neonova.co.za wrote: I would prefer to see something like this as standard: http://www.dsource.org/projects/orange/ I think Doost.serialization is one of candidates for std.serializer(serialization?). But I don't know current status. In addition, Michel has serialization module. I don't know module detail, but he mentioned at d.announce. http://lists.puremagic.com/pipermail/digitalmars-d-announce/2010-April/015271.html I don't know other general serialization modules. Masahiro
Re: Review: std.msgpack
On Fri, 18 Jun 2010 23:47:38 +0900, Robert Jacques sandf...@jhu.edu wrote: Second, a lot of the design and examples are very similar to the MsgPack reference implementations, which are all Apache licensed. Since some of these design decisions seem to not be 'D'-ish (more on that later) this raises questions on just how clean room the implementation was. The author of MessagePack allows this module to apply Boost Software License. Third, there's a lot of things that shouldn't be in the final module. -Should be removed: SimpleBuffer, VRefBuffer/vRefBuffer, -Redundant with other parts of phobos: BinaryFileWriter = LockingTextWriter, mp_Type/mp_Object/mp_KeyValue = std.variant BinaryFileWriter removed. mp_Object is based on std.json.JSONValue. Variant can't have mp_pack method. Hmm..., I check Variant again. -Should be moved elsewhere DeflateFilter/deflateFilter = zip/zlib I agree. Forth, msgpack was designed to be a simple, wire level encoding of some higher structure. As opposed to JSON or XML, you are not going to be modifying it dynamically. The very concept that it would use buffers internally, particularly the existence of the zero-copy buffer, baffles me. (Not to mention it leaves one open to aliasing bugs.) MsgPack has to decorate every single type it stores, so there is nothing zero-copy about it. To that end, I think MsgPack/MsgUnPack should wrap an input or output range as appropriate and be able to be used by a general serialization library such as Orange. If Phobos has std.serializer like Orange(or Doost.Serialization?), I will implement MsgPackArchive. But general serializer usually is low-performance and lacks some features. So when user wants performance, user will use Packer and Unpacker directly. Other little things, -Why isn't nil mapped to null? Where? -Why isn't there any big warnings about serializing cycles? Oops. Current implementation can't deal with a circular reference. I added NOTE section to Packer's comment. Masahiro
Re: Tuple to tuple conversion
On Tue, 08 Jun 2010 19:39:43 +0900, Simen kjaeraas simen.kja...@gmail.com wrote: Simen kjaeraas simen.kja...@gmail.com wrote: Lars T. Kyllingstad pub...@kyllingen.nospamnet wrote: FWIW, I've run across the same error, while writing code that had nothing to do with tuples. And I've seen others complaining about it too. It seems to be a rather elusive bug in Phobos. This has now been tracked down to the importing of std.typecons in two included files. Test case: // module a; import std.typecons; alias Tuple!( float ) foo; // module b; import std.typecons; Forgot to mention, this only happens with -unittest. http://d.puremagic.com/issues/show_bug.cgi?id=4294 Same issue? http://d.puremagic.com/issues/show_bug.cgi?id=4003
Re: Binary data-structure serialization
On Mon, 31 May 2010 22:36:13 +0900, Robert robert.mue...@robertmuench.de wrote: On 2010-05-31 11:09:54 +0200, Masahiro Nakagawa repeate...@gmail.com said: I may not be right about your question, but I am writing msgpack4d. http://www.bitbucket.org/repeatedly/msgpack4d This library will be available in Phobos(see d.announce). Now, I fix bugs and improve some features. Hi, does it support data-structures like trees, lists etc. or is the focus to transfer plain types? I'm looking for a way, where I can save and load complex data-structures like graphs, b-trees etc. to a file. You can define mp_pack / mp_unpack if need(Complex data-structure requires specified routines). I added simple b-tree example to example/custom.d. If you want more efficient serialization library for complex data-structures, you will need to create like existing DBMs. Masahiro
Re: Binary data-structure serialization
On Wed, 02 Jun 2010 06:29:12 +0900, Robert M. Münch robert.mue...@robertmuench.de wrote: On 2010-05-31 17:01:16 +0200, Trass3r said: Isn't http://digitalmars.com/d/2.0/class.html#ClassAllocator what you want? Ah, that's cool. Didn't saw it. This looks very good. Will those clases be GCed? Default no. Documentation is here: http://digitalmars.com/d/2.0/memory.html#newdelete NOTE: This info is a bit outdated. std.gc was moved to core.memory and std.outofmemory was moved to onOutOfMemoryError in core.exception.
Re: new layout on wiki4d
On Sat, 29 May 2010 07:47:50 +0900, Matthias Pleh matthias.p...@gmx.at wrote: I have renewed the layout of the wiki4d-site. It's not finished, but I think it is already useable! Content itself hasn't changed! Any thoughts? Please check also the links on the sidebar! I have taken this from a template from Justin Calvarese (thanks), so maybe some links should changed, reordered or even removed! greets Matthias New design is good! I have a suggestion. Now, Japanese site on Other Languages is inactive. Could you please change link? New link: http://dusers.dip.jp/ Masahiro
Re: Binary data-structure serialization
Hi Robert, On Sun, 30 May 2010 19:38:10 +0900, Robert robert.mue...@robertmuench.de wrote: Hi, are there are any projectes / snippets / prototypes where someone tried to serializa D run-time data-structures (like an associative array) into a file? I may not be right about your question, but I am writing msgpack4d. http://www.bitbucket.org/repeatedly/msgpack4d This library will be available in Phobos(see d.announce). Now, I fix bugs and improve some features. Hope this helps. Masahiro
Re: The last changes to range
On Sun, 30 May 2010 01:45:54 +0900, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
I plan to make two more (hopefully the last two) changes to the range
abstraction this morning.
1. First, I want to define this:
// inside range type SomeRange
@property SomeRange save();
That simply returns a copy of the range. Most implementations look like
this:
// inside range type SomeRange
@property SomeRange save() { return this; }
If SomeRange is a class or interface, you'd write:
// inside range type SomeRange
@property SomeRange save() { return this-clone(); }
The idea is that save() provides a guaranteed means to take a snapshot
in a range's state. The notable absents are input ranges - they are
unable to define save(), and therefore some algorithms won't apply to
them.
I also want save.
It allows you to treat some ranges in a unified way.
Masahiro
Re: Bug fix week
On Sun, 23 May 2010 22:50:14 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: We've had a tremendous infusion of talent and energy in Phobos, and lately work has picked up in unprecedented ways, both in terms of new features and bug fixes. I can't say how happy I am about that! At the end of this starting week, on Friday May 28, TDPL will be out on trucks to bookstores. Let's make this week a bug fixing week for both dmd and Phobos, and issue a release on Monday. We're going public! Andrei I think we need improvement of DDoc. Current DDoc doesn't keep up with D Spec(e.g. ignore @attribute, pure, etc...).
Re: Bug fix week
On Thu, 27 May 2010 05:47:50 +0900, Brad Roberts bra...@slice-2.puremagic.com wrote: On Thu, 27 May 2010, Masahiro Nakagawa wrote: On Sun, 23 May 2010 22:50:14 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: We've had a tremendous infusion of talent and energy in Phobos, and lately work has picked up in unprecedented ways, both in terms of new features and bug fixes. I can't say how happy I am about that! At the end of this starting week, on Friday May 28, TDPL will be out on trucks to bookstores. Let's make this week a bug fixing week for both dmd and Phobos, and issue a release on Monday. We're going public! Andrei I think we need improvement of DDoc. Current DDoc doesn't keep up with D Spec(e.g. ignore @attribute, pure, etc...). Fixes are generated at the rate Walter plus several other volunteers generate them. Care to add yourself to that set of volunteers? The source is fully available.. Bugzilla has a lot of issues to choose your favorite(s) from... Later, Brad Yes. I would like to fix dmd bugs. But, I don't understand dmd internal now :( Give me a more time.
Re: Bug fix week
On Sun, 23 May 2010 22:50:14 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: We've had a tremendous infusion of talent and energy in Phobos, and lately work has picked up in unprecedented ways, both in terms of new features and bug fixes. I can't say how happy I am about that! At the end of this starting week, on Friday May 28, TDPL will be out on trucks to bookstores. Let's make this week a bug fixing week for both dmd and Phobos, and issue a release on Monday. We're going public! Andrei I think we need improvement of DDoc. Current DDoc doesn't keep up with D Spec(e.g. ignore @attribute, pure, etc...).
Re: Bug fix week
On Thu, 27 May 2010 05:47:50 +0900, Brad Roberts bra...@slice-2.puremagic.com wrote: On Thu, 27 May 2010, Masahiro Nakagawa wrote: On Sun, 23 May 2010 22:50:14 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: We've had a tremendous infusion of talent and energy in Phobos, and lately work has picked up in unprecedented ways, both in terms of new features and bug fixes. I can't say how happy I am about that! At the end of this starting week, on Friday May 28, TDPL will be out on trucks to bookstores. Let's make this week a bug fixing week for both dmd and Phobos, and issue a release on Monday. We're going public! Andrei I think we need improvement of DDoc. Current DDoc doesn't keep up with D Spec(e.g. ignore @attribute, pure, etc...). Fixes are generated at the rate Walter plus several other volunteers generate them. Care to add yourself to that set of volunteers? The source is fully available.. Bugzilla has a lot of issues to choose your favorite(s) from... Later, Brad Yes. I would like to fix dmd bugs. But, I don't understand dmd internal now :( Give me a more time.
Re: Logger for D
Hi, On Wed, 12 May 2010 07:54:23 +0900, sybrandy sybra...@gmail.com wrote: Hello, I just wanted to let everyone know that I created a simple logging library for D. I wrote it as I wanted to debug my programs without having to deal with standard output and have used it for several little coding adventures. https://launchpad.net/dlogger The main features are: - Supports trace, info, dbug (debug), error, and fatal log errors. - Logging levels can be changed while the program is running - Is thread safe (hopefully) - If compiled with -version=nologger, it's like you never included it. Besides satisfying my own needs, I felt that a logging library of some sort would be good for Phobos, hence why I'm making this available. Please report any issues/suggestions to the launchpad site. I want two features. - file-size or time-based rotation Manual management is very bother. - filter I think message customization is useful(e.g. coloring for terminal). Some loggers support this functionality(Log4j, Boost.log, etc...). I once wrote a logger. My logger is here. http://www.bitbucket.org/repeatedly/scrap/src/tip/logger.d This logger supports above features(Rotation is file-size only). Hope this helps.
Re: d2tags - converts DMD2's JSON output to Exuberant Ctags format
On Fri, 07 May 2010 01:48:59 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: MIURA Masahiro wrote: Hi, Being happy to see issue 3415 (broken JSON format) fixed, I have written a utility to convert DMD2's JSON output to Exuberent Ctags format. This enables you to tagjump in Vim and other editors/IDEs. It's just 150+ lines, thanks to D2's powerful string handling. Enjoy! http://github.com/Dubhead/d2tags usage: % dmd -Xftags.json foo.d % d2tags tags.json tags Very useful, and a beautiful example of D scripting. I wonder if this is of enough general utility to warrant inclusion within the D distribution, along with rdmd. Thoughts? vote++
Re: Tuple unittests
On Tue, 04 May 2010 13:21:46 +0900, Ellery Newcomer ellery-newco...@utulsa.edu wrote: lately I've been getting a lot of screwy error messages whenever I try to compile with -unittest: /home/ellery/Downloads/dmd2044/linux/bin/../../src/phobos/std/typecons.d(425): Error: static assert (is(Tuple!(string,float) == Tuple!(string,float))) is false /home/ellery/Downloads/dmd2044/linux/bin/../../src/phobos/std/typecons.d(413): instantiated from here: Tuple!(string,float) /home/ellery/Downloads/dmd2044/linux/bin/../../src/phobos/std/typecons.d(424): instantiated from here: slice!(1,3) /home/ellery/Downloads/dmd2044/linux/bin/../../src/phobos/std/typecons.d(421): instantiated from here: Tuple!(int,string,float,double) src/dxl/util/Blit.d(554):instantiated from here: Tuple!(int,i,int,j) Actually, it's just this one. I haven't tried working it down to something small, but I have noted that the order in which I send files to dmd affects whether this happens. any ideas why this is happening? I once hit the same bug. SHOO has been reported this bug. http://d.puremagic.com/issues/show_bug.cgi?id=4003 I don't know the solution to fix :(
Re: Masahiro Nakagawa and SHOO invited to join Phobos developers
On Thu, 29 Apr 2010 22:21:04 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 04/29/2010 04:55 AM, Masahiro Nakagawa wrote: On Wed, 28 Apr 2010 22:49:56 +0900, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Hello, Following the great work that Masahiro Nakagawa and SHOO offered to Phobos, we are inviting them to join the Phobos developer ranks. Once the community review of the proposed libraries concludes with approval, Masahiro and SHOO will be able to commit the modules to Phobos themselves. In case you two accept the invitation, please create accounts on dsource.org if you don't have and the let me know of your IDs. I am delighted to accept your invitation. My ID on dsource is 2849. http://www.dsource.org/forums/profile.php?mode=viewprofileu=2849 Perfect, thank you! Added. Welcome to Phobos! Thank you for adding me to Phobos! I'm so glad :)
