Re: Numerical age for D: Mir v0.18.0 is faster then OpenBLAS
On Sunday, 25 September 2016 at 12:11:53 UTC, Lodovico Giaretta wrote: On Friday, 23 September 2016 at 13:25:30 UTC, Ilya Yaroshenko wrote: Mir is LLVM-accelerated Generic Numerical Library for Science and Machine Learning. Benchmark: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html Mir v0.18.0 release notes: https://github.com/libmir/mir/releases/tag/v0.18.0 The release includes Mir's D Foundation GSoC project. Do not forget to star the project: https://github.com/libmir/mir Best regards, Ilya Typo in the title: `than` must be used for comparisons; `then` is for temporal/causal consequence. Same error twice in the conclusion.
Re: Numerical age for D: Mir v0.18.0 is faster then OpenBLAS
On Friday, 23 September 2016 at 13:25:30 UTC, Ilya Yaroshenko wrote: Mir is LLVM-accelerated Generic Numerical Library for Science and Machine Learning. Benchmark: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html Mir v0.18.0 release notes: https://github.com/libmir/mir/releases/tag/v0.18.0 The release includes Mir's D Foundation GSoC project. Do not forget to star the project: https://github.com/libmir/mir Best regards, Ilya Typo in the title: `than` must be used for comparisons; `then` is for temporal/causal consequence.
Re: [OT] LLVM 3.9 released - you can try the release already with LDC!
On Tuesday, 6 September 2016 at 09:21:06 UTC, eugene wrote: On Sunday, 4 September 2016 at 17:18:10 UTC, Kai Nacke wrote: This is the 9th time that LDC and D are mentioned in the LLVM release notes! lol, how does it help?))) There are lot of projects using LLVM [1]. The fact that LDC if often cited in the release notes means that it's one of the best. This is free advertisement, as the LLVM release notes are read by PL people that may not know D. The fact that LDC is recognized as one of the most important LLVM projects also means that the LLVM folks will try to help the LDC folks when needed. [1] http://llvm.org/ProjectsWithLLVM/
Re: [GSoC] std.experimental.xml is now a PR!
On Thursday, 25 August 2016 at 21:36:34 UTC, Lurker wrote: On Wednesday, 24 August 2016 at 09:31:44 UTC, Lodovico Giaretta wrote: [...] Looks good at first glance. How does it compare against established XML parsers performance-wise, e.g. Phobos XML, RapidXML, pugixml etc. Tango claimed to be the fastest XML parser at some point in time, curious how it compares. http://xmlbench.sourceforge.net/ might be a good start. Hi! Sorry for the late reply, I've been quite busy. I didn't perform many comparisons against other APIs. Also, performance has not been the main target. I mean, the infrastructure for making it fast is there. The library contains a small number of string handling functions that can be optimized, leading to great speed improvements in all components. But these functions hasn't been fully optimized yet. About raw performance, the repository contains a simple benchmarking driver which I use to track performance regressions in the code. On my laptop, excluding the time needed to load the input from disk, I can easily process XML with speeds over 50MB/s, which looks like a good start. Easy win comparisons: this library is way faster than Java's built-in XML library and also way faster than the current Phobos std.xml API. http://xmlbench.sourceforge.net/ might be a good start. Thank you for pointing this out. I will have a look.
Re: [GSoC] std.experimental.xml is now a PR!
On Wednesday, 24 August 2016 at 12:00:43 UTC, Suliman wrote: On Wednesday, 24 August 2016 at 10:26:53 UTC, Lodovico Giaretta wrote: [...] IMHO is much better to attend every function with short example of it's usage. For example: https://lodo1995.github.io/experimental.xml/std/experimental/xml/parser.html it's hard to understand what it's doing. Not every D-people are good programmers. A lot of people prefer to look at example to understand what function is doing. And if it's good just copy-past ready to use code. Understood, you are right. I'll work on this. Thank you.
Re: [GSoC] std.experimental.xml is now a PR!
On Wednesday, 24 August 2016 at 10:22:04 UTC, Suliman wrote: Add more examples of usage please. Thank you very much for having a look. Did you see the examples at [1]? I don't want to add other examples to that page, it would become too long, but maybe I could add specific examples in the pages of the various modules. What do you think? [1] https://lodo1995.github.io/experimental.xml/std/experimental/xml.html
[GSoC] std.experimental.xml is now a PR!
Hi! I'm pleased to announce that my GSoC project, a replacement for the outdated std.xml, is now a Phobos PR! [1] It is an (almost complete) mirror of my repository [2], which is also available on DUB [3]. I would like to thank my mentor Robert burner Schadek for his great support and everybody who already gave some feedback during these months. The PR is not meant for immediate merging. Some things still need improvement (docs/unittests/...) while others will come in a second iteration (advanced DTD handling). It is meant to for some reviews, focusing mainly on the design and usability of the library. In the PR description you will find all the details, including a nice "wishlist" of things that I found missing in D during the development and some open questions. So, if you have any consideration/suggestion, drop a line here or on the PR, and if you find bugs, don't hesitate to file an issue on the issue tracker of my repository. Thank you very much! [1] https://github.com/dlang/phobos/pull/4741 [2] https://github.com/lodo1995/experimental.xml [3] https://code.dlang.org/packages/std-experimental-xml
Re: LDC 1.1.0-beta2 has been released!
On Monday, 8 August 2016 at 16:14:44 UTC, David Nadlinger wrote: On Monday, 8 August 2016 at 16:01:29 UTC, Lodovico Giaretta wrote: Is this beta available on Travis, or will it be? The beta is available from https://dlang.org/install.sh as "ldc-1.1.0-beta2", so it should also be accessible on Travis. On [1] the last reported version is 1.1.0-alpha1. This might be due to LDC's LATEST file having been accidentally set to alpha 1 before the actual release – IIRC, that page just periodically scrapes the output of building with "ldc" on Travis. (Users wouldn't usually expect "ldc" to give them an alpha-quality compiler, although it seems we were lucky and the alpha was already stable enough for nobody to really notice.) — David Thank you very much. I will try it as soon as possible.
Re: LDC 1.1.0-beta2 has been released!
On Wednesday, 3 August 2016 at 20:12:59 UTC, Kai Nacke wrote: Hi everyone, LDC 1.1.0-beta2, the LLVM-based D compiler, is available for download! This BETA release is based on the 2.071.1 frontend and standard library and supports LLVM 3.5-3.9. We provide binaries for Linux, OX X, FreeBSD, Win32 & Win64, Linux/ARM (armv7hf), now bundled with DUB. :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/nskepdckljprrxsjb...@forum.dlang.org Regards, Kai Is this beta available on Travis, or will it be? On [1] the last reported version is 1.1.0-alpha1. Thank you very much for your work. [1] http://semitwist.com/travis-d-compilers
Re: std.experimental.xml available on DUB
On Wednesday, 3 August 2016 at 09:04:30 UTC, Jacob Carlborg wrote: On 2016-07-30 11:26, Lodovico Giaretta wrote: Hi, I'm proud to announce that std.experimental.xml v0.1.0 is available on DUB [1]! Another question. I see that there are a couple of different lexers available. Can those be exposed with the same interface/type instead of using different types? Perhaps based on the input type. I don't know if it is what you want, but you can do this: auto lexer = chooseLexer!input; The function chooseLexer creates the most suitable lexer type based on the input type. You can test if a type is a lexer using the trait isLexer defined in std.experimental.interfaces.
Re: std.experimental.xml available on DUB
On Tuesday, 2 August 2016 at 15:32:50 UTC, Jacob Carlborg wrote: * Does it work at CTFE? I don't think so. * I see that it doesn't follow the D naming conventions You are talking about upper/lower cases in the names, right? I will correct them in the Phobos PR.
Re: std.experimental.xml available on DUB
On Monday, 1 August 2016 at 07:38:29 UTC, Guillaume Piolat wrote: On Sunday, 31 July 2016 at 18:56:33 UTC, Lodovico Giaretta wrote: kxml is also way limited with respect to std.experimental.xml. It does not support many features, like custom allocators (because they don't exist in Java). It does not have to strive to be @nogc (because it does not exist in Java). It does not support high customization, with custom lexers, pluggable validations, full DOM Level 3 support, with the ability for the user to provide a custom DOM implementation and have the DOMBuilder use it instead of the default provided DOM implementation. It does not support SAX with DbI on the handler type. It does not support outputting XML using a custom formatter, again with DbI. Okay, just wanted to know what we are buying with (supposedly) more code. For reference I was speaking of the D kxml package, which is a DOM parser than can range-iterate on nodes using XPath. Ouch. Looks like I misunderstood you then. I apologize. I don't know anything about that D package, but I can safely assume that this library will provide more functionalities and (most of all) more customization points. It's designed as a collection of components, each of with can be customized or even substituted with a user defined one. This is what such a big quantity of code will buy. There are various principles one can use when building a library. In this case I didn't choose minimality. I prefered extensibility and customizability.
Re: std.experimental.xml available on DUB
On Sunday, 31 July 2016 at 18:38:32 UTC, Guillaume Piolat wrote: On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta wrote: Hi, I'm proud to announce that std.experimental.xml v0.1.0 is available on DUB [1]! If you find any issue / have any suggestion, please file an issue on Github [3]. Thank you. Why is it 15 files when kxml is only one? kxml is way more than a file. You may say that its parser is just a file. In std.experimental.xml, the parser is at most three files (it depends on what you mean by parser), not fifteen. kxml is also way limited with respect to std.experimental.xml. It does not support many features, like custom allocators (because they don't exist in Java). It does not have to strive to be @nogc (because it does not exist in Java). It does not support high customization, with custom lexers, pluggable validations, full DOM Level 3 support, with the ability for the user to provide a custom DOM implementation and have the DOMBuilder use it instead of the default provided DOM implementation. It does not support SAX with DbI on the handler type. It does not support outputting XML using a custom formatter, again with DbI. Also keep in mind that std.experimental.xml contains LOTS of lines of unittests and some code is there just because Phobos does not provide some essential tools for the job. It is true that I could merge some of these files, as they are almost all quite short, but I prefer them this way, cause they are easier to handle.
Re: std.experimental.xml available on DUB
On Sunday, 31 July 2016 at 15:28:14 UTC, LaTeigne wrote: On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta wrote: Hi, I'm proud to announce that std.experimental.xml v0.1.0 is available on DUB [1]! This is the project I'm working on for GSoC 2016. It aims to become a substitution for Phobos std.xml. Now you can easily try it and provide some feedback. I will soon create a WIP PR on the Phobos repository. I suggest you to depend on ~master instead of v0.1.0, as bugfixes and enhancements are added on a daily basis (v0.1.0 is already one commit behind!) Current limitations: 1) The documentation [2] is very limited; 2) Some advanced DOM methods are not completely implemented; 3) Some advanced features (e.g. DTD validation, namespace checks) are not yet available. If you find any issue / have any suggestion, please file an issue on Github [3]. Thank you. [1] https://code.dlang.org/packages/std-experimental-xml [2] https://lodo1995.github.io/experimental.xml/ [3] https://github.com/lodo1995/experimental.xml I have two comments. What is the plan for the string interner and the allocator-based appender ? They are neither part of the package, nor proposed in phobos, it seems that you'll encounter a problme in the package structure itself. This is also problemtaic now if I want to test it I have to add 3 import paths to sc.conf. I suggest you either to propose them for phobos or to add them in a subpackage "internal" **inside xml** (or in a big internal.d module) like it's done for several phobos packages (algos, ndslices). _ I see a naming problem in you "fast" strings: fastIndexOf, fastEqual etc. This is not good: does it mean that phobos's equivalent are slow ? Does it mean that you'll also propose slow equivalents (This is absurd, but it shows the problem). Thank you for your comments. Talking about your points: 1) the interner shall really go away before inclusion in Phobos; it is unneeded; its code is already partially duplicated in CopyingCursor (std.experimental.xml.cursor); but it would be good to have something like this in Phobos, somewhere in the future. 2) The appender is needed, as the Phobos one does not work with custom allocators; I don't have the time to polish it for Phobos adoption, so putting it in an internal xml submodule may be a great idea. 3) The fastXXX functions are intended for internal usage; they will have package protection in the final library (I really forgot about this thing; thanks). I will tag v0.1.1 late this night, with some fixes based on the feedback from you and Steven. Thank you again.
Re: std.experimental.xml available on DUB
On Sunday, 31 July 2016 at 12:04:18 UTC, Steven Schveighoffer wrote: On 7/30/16 5:26 AM, Lodovico Giaretta wrote: [...] Good to see this advancing! I'm looking at the cursor API and like what I see. Good to know. The cursor API is the central concept of the library, even if it will probably not be directly used by many. A couple things: 1) I see struct Cursor is not tagged for documentation, yet all it's members are. Your docs are missing out on a lot of stuff here! This might be true elsewhere too, make sure you tag types for documentation or the members won't show up in the docs. You are right. Many things are only partially documented. I'm working to improve the situation. For now, you can find the documentation of Cursor in std.experimental.xml.isCursor, as this is in fact where it belongs. I will definitely mark struct Cursor for documentation, and add the relevant link to template isCursor. 2) The function "exit", I don't like. This is bikeshedding, but I just don't like the possibility that to conflate with C exit. I don't have a good replacement name for enter/exit, so this comment is pretty minor. I don't agree with you on this. But I'm not too attached to that name either, so if anyone can suggest a better name pair for enter/exit, I have no problem in changing it. In general, I'm open to every kind of change that would ease usage and understanding. Thank you for your feedback.
std.experimental.xml available on DUB
Hi, I'm proud to announce that std.experimental.xml v0.1.0 is available on DUB [1]! This is the project I'm working on for GSoC 2016. It aims to become a substitution for Phobos std.xml. Now you can easily try it and provide some feedback. I will soon create a WIP PR on the Phobos repository. I suggest you to depend on ~master instead of v0.1.0, as bugfixes and enhancements are added on a daily basis (v0.1.0 is already one commit behind!) Current limitations: 1) The documentation [2] is very limited; 2) Some advanced DOM methods are not completely implemented; 3) Some advanced features (e.g. DTD validation, namespace checks) are not yet available. If you find any issue / have any suggestion, please file an issue on Github [3]. Thank you. [1] https://code.dlang.org/packages/std-experimental-xml [2] https://lodo1995.github.io/experimental.xml/ [3] https://github.com/lodo1995/experimental.xml
Re: DIP1001: Exception Handling Extensions
On Sunday, 10 July 2016 at 19:55:37 UTC, Superstar64 wrote: link: https://github.com/dlang/DIPs/pull/9 file: https://github.com/Superstar64/DIPs/blob/exception_extensions/DIPs/DIP1001.md I'm not convinced by this proposal. Here are some early thoughts: 1) Wouldn't a library solution based on functional-style tagged results achieve the same without changing the language and making things less clear (see my other points)? Something on the lines of variant? 2) Wouldn't this make code quite obscure? I mean, now if you see a throw or a catch you know what's going on. With this proposal, when you see a throw or a catch, you have to go look at the declaration of the thrown or catched type to get what's going on. 3) From your proposal, it seems that current exception handling needs the GC, which is not true; you can already do exception handling in @nogc code, without any extra quirk. 4) C++ deprecated throw lists; while this does not automatically mean that they are bad, we shall learn from others' errors, and be very careful. But all of this is just my opinion based on a fast read of the proposal. P.S.: something went wrong (probably with copy-pasting) here: A function which calls a sub function with a @throws(TypeList) attribute must have alluncaught possible exceptions must be a part of the @throws(TypeList) attribute of the caller function.
Re: GSoC 2016 - std.experimental.xml progress
On Monday, 2 May 2016 at 12:25:03 UTC, 9il wrote: Hello Lodovico, Thank you for working on new xml. Please use size_t and sizediff_t instead of uint and int in your loops: for (auto i = 0; i < t.length; i++) should be replaced with foreach (size_t i; 0 .. t.length) Best regards, Ilya I'll fix this. Thank you very much.
GSoC 2016 - std.experimental.xml progress
Hi, Just a little update about my project... After days of bugfixes, the first almost-high-level API (XMLCursor) is now quite usable. Now I can start working on other APIs (e.g. DOM) based on it. If you're interested you can find some usage examples in files benchmark.d and test.d . Any comment is highly appreciated. (If you missed it, the repo is https://github.com/lodo1995/experimental.xml ). Thank you in advance. Lodovico Giaretta
