Re: mime - library for parsing shared MIME database
On Sunday, 16 August 2015 at 03:56:45 UTC, Rikki Cattermole wrote: On 16/08/2015 6:30 a.m., FreeSlave wrote: Currently I'm working on mime library for D. Dub page: http://code.dlang.org/packages/mime It can parse MIME database files, including binary ones, like mime.cache. It also has algorithms for mime type detecting by file name. It's not fully implemented yet and does not have stable API. Issues and goals are listed on the github page: https://github.com/MyLittleRobo/mime If someone is interested in the project, I would be glad to discuss interface and implementation details of the library. If you don't know what is shared MIME database and why does it matter read this: http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html#idm140625831778224 I had an mime implementation in Cmsed that basically was a hard coded file with a whole bunch of mime types along with file extensions. I would be interested in seeing if this can match it 1:1 for features, while not allocating. Say give me the mime type for payload. Possibly with its own override/addition csv files. This library focuses on shared MIME database used in freedesktop systems, usually for detecting file types in file managers to display appropriate icon and make correct choice of default application (well, that's another spec) to run on file. I don't think this suits the web world. Your hardcoded approach is what usually used in web. If I remember correctly mime types are hardcoded in Chromium too. But mime type is not only about extension. Generally pattern can be any glob pattern. That's why file managers can detect Makefile type as text/x-makefile, even though it does not have extension. Same for CMakeLists.txt - the preferred type is text/x-cmake, not just text/plain. Patterns are not alone. There're magic rules for the rescue when mime type can't be detected from the name of file. That's how Linux file managers differ shell script from python script even if both don't have extension (but they have leading comment like #!/bin/sh or #!/usr/bin/python). Also that's how file managers detect file with unknown pk3 extension (used in Quake III based games) as zip file. Because it's really just zip file by its contents. The whole shared MIME database thing is system and user dependent, so again it's not what you want to use for web, probably unless you manage the database yourself on the server. Even in this case patterns and magic rules are just hints. You can't rely on that to check if the uploading file is of the needed type. For example, if you want to validate image file, the only way to do it is to parse the whole file. Still you can use hints to cut off obviously invalid files. I did not target non-allocating code yet, though I believe it's possible to make MimeCache to not allocate when detecting file type.
∅MQD messaging library v1.0 released
I am happy to announce the (somewhat overdue) release of ∅MQD v1.0! ∅MQD is a D library that wraps the low-level C API of the ∅MQ (aka. ZeroMQ) messaging framework. It is a rather thin wrapper that maps closely to the C API, while providing modern D features that make the framework safer, easier and more pleasant to use. (In other words, ∅MQD is not just a plain C binding(*)!) Code: https://github.com/kyllingstad/zmqd Dub package: http://code.dlang.org/packages/zmqd API docs: https://kyllingstad.github.io/zmqd/zmqd_v1.0.html This version works with ∅MQ v4.x, and has 100% support for all ∅MQ v4.0 functionality. A few small ∅MQ 4.1 features are missing, but support for those will be added in an upcoming 1.1 release in the not-too-distant future. Before use, please have a look at the README, specifically the section A word of caution about the C library bindings. The ∅MQ guys have introduced some ABI incompatibilities in recent versions, so it it important that the D-to-C bindings match the library version you have installed. -Lars (*) If plain C bindings are what you want, check out Deimos/ZeroMQ: https://github.com/D-Programming-Deimos/ZeroMQ http://code.dlang.org/packages/zeromq ∅MQD depends on these bindings, so I try to keep them up to date with stable ∅MQ releases.
Re: ∅MQD messaging library v1.0 released
Cool. I haven't actually used ZeroMQ yet, but it's something I've had my eye on.
Re: ∅MQD messaging library v1.0 released
On Sunday, 16 August 2015 at 12:53:39 UTC, Nick Sabalausky wrote: Cool. I haven't actually used ZeroMQ yet, but it's something I've had my eye on. If you want to look into it, I heartily recommend the ZeroMQ Guide: http://zguide.zeromq.org/ In addition to being a comprehensive and well-written (entertaining, even) user's guide for ZeroMQ, it contains a lot of good information and advice on how to build distributed software systems in general. I have translated the examples for the first few chapters to D. You'll find them in the examples subdirectory of the ∅MQD repo. -Lars
SciD has a new home
As of today, the main SciD repository will be hosted under the DlangScience organisation on GitHub: https://github.com/DlangScience/scid SciD is a collection of freely usable numerical routines for, among other things, - numerical integration (quadrature) and differentiation - nonlinear equation solving (one- and multidimensional) - (a little bit of) linear algebra With this move, I hope more people will discover the library, find it useful, and even contribute to it. Documentation: https://dlangscience.github.io/scid Dub package: http://code.dlang.org/packages/scid -Lars
xcb-d - First release
Hi! I've just release the first version of xcb-d. It's a bind for xcb that is generated via d_client.py, a heavy modified c_client.py script from the libxcb repository. This file uses the xml files from the libxcb-proto repository. With this approach it will be really easily updated to the lasted version of xcb when it is released. Currently it's for xcb version 1.11. I'm looking forward to some feedback if there is any. DUB package: http://code.dlang.org/packages/xcb-d Github: https://github.com/Vild/xcb-d -Dan
