Re: grep library?
On Sunday, 27 October 2013 at 02:59:58 UTC, Andrei Alexandrescu wrote: Hello, A coworker implemented a system that spawns grep to rummage through a large log file. Apparently doing so is quite a bit faster than using a regex. This is because grep is highly specialized and optimized. I was wondering if we could implement a grepping library that builds on regex's strengths and also grep's many optimization tricks: http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html Andrei Great idea, The author of The Silver Searcher, a similar text search tool, has also posted some information on how to make a fast search tool. It seems to use Boyer-Moore-Horspool for literal searches (similar to grep); however, regex searches are done using PCRE. http://geoff.greer.fm/2011/12/27/the-silver-searcher-better-than-ack/ https://github.com/ggreer/the_silver_searcher
Re: dmd 2.065 - Agenda
Are there any plans for adding compile-time checking or recursive data types to std.variant's Algebraic? I think algebraic data types are important and the current implementation is not suitable to solve a good portion of problems that the intended implementation could. Could this be a possible goal for 2.065? If not, are we lacking demand? Lacking someone willing to work on it?
Re: [RFC] ∅MQD, a ∅MQ wrapper for D
On Sunday, 22 December 2013 at 00:18:51 UTC, Lars T. Kyllingstad
wrote:
I've been working on a D wrapper for the ∅MQ (aka. ZMQ/ZeroMQ)
messaging library, and I think it's nearly ready for an
"official release". However, I would immensely appreciate some
feedback on the API first.
Code: https://github.com/kyllingstad/zmqd
Docs: http://kyllingstad.github.io/zmqd
I've tried to stay as close as possible to the design of the C
library, while adding a distinct D "feel". Details are in the
documentation.
Note that my library is different from the ZeroMQ bindings in
Deimos, which are simple D bindings to the C API. (In fact,
∅MQD depends on the Deimos bindings.)
Thanks,
Lars
Hi Lars, I've actually never used ZeroMQ but it seems
interesting. There exists a binding called dzmq[1], but there are
no immediate examples.
Anyhow, if I may, I'd like to suggest a few things:
* Add a license file to your repository. I see that it's under
the Boost Software License from the documentation, though.
* Create a package.json and add it to the DUB registry[2]. I have
taken the liberty at making a simple package.json that may work
but is untested[3].
[1]: https://github.com/kyphelps/dzmq
[2]: http://code.dlang.org/
[3]: $ cat package.json
{
"name": "zmqd",
"targetType": "sourceLibrary",
"description": "a ZeroMQ wrapper for the D programming
language",
"homepage": "https://github.com/kyllingstad/zmqd";,
"copyright": "Copyright (c) 2013, Lars Kyllingstad",
"license": "Boost Software License, version 1.0",
"authors": [ "Lars Kyllingstad" ],
"importPaths": ["."],
"sourcePaths": ["."],
"excludedSourceFiles": ["examples/*"],
"dependencies": {
"zeromq": "~master"
}
}
Regards,
Kelet
Re: [RFC] ∅MQD, a ∅MQ wrapper for D
On Sunday, 22 December 2013 at 00:18:51 UTC, Lars T. Kyllingstad wrote: I've tried to stay as close as possible to the design of the C library, while adding a distinct D "feel". Details are in the documentation. After reviewing the API and comparing it to the C API, I think you did a fine job accomplishing this. Regards, Kelet
Re: UniquePtr in D
On Sunday, 22 December 2013 at 13:19:48 UTC, Benjamin Thaut wrote: When working with C-libraries in D I often wish for a equivalent of the C++11 unique_ptr. Unfortunately this is not possible in D. Consider the following source code: http://dpaste.dzfl.pl/6e71c815 Is error 1 a bug? Because there should cleary not be any copy at this point. Should we implement moving of u so that error 2 goes away? The compiler could move u into the function and move back out afterwards, but that would mean that the contents of u would be invalid for the duration of the function call (unsafe?) Kind Regards Benjamin Thaut Is std.typecons.Unique[1] not the equivalent of unique_ptr? [1]: http://dlang.org/phobos/std_typecons.html#.Unique Regards, Kelet
Re: D - Unsafe and doomed
On Saturday, 4 January 2014 at 02:09:51 UTC, NoUseForAName wrote: This piece (recently seen on the Hacker News front page): http://rust-class.org/pages/using-rust-for-an-undergraduate-os-course.html .. includes a pretty damning assessment of D as "unsafe" (compared to Rust) and generally doomed. I remember hearing Walter Bright talking a lot about "safe code" during a D presentation. Was that about a different kind of safety? Is the author just wrong? Basically I want to hear the counterargument (if there is one). Disclaimer: I only have a cursory understanding of the subject. With Rust, there are no dangling or null pointers. This means that if a pointer exists, it points to a valid object of the appropriate type. When a pointer does not point to a valid object of the appropriate type, accessing the content at the pointer results in undefined behavior or an error in languages that allow it. Rust implements all of these pointer safety checks at compile time, so they do not incur a performance penalty. While `@safe` helps reduce this class of logic errors, it does not go so far as Rust -- you can still have null and dangling pointers, hence it is usually considered inferior with regards to safety. There was a SafeD[1] subset of D being worked on, but I'm not sure if it is active anymore. As for D slowly dying, I would say it is not true. It has been growing by all measures lately. With projects like DUB and Derelict making progress, the ecosystem is more inviting to users. I think a lot of people have a bad taste in their mouth from D1 with Phobos/Tango. D exceeds Rust in some aspects, but my understanding is that Rust is a more safe language. Anyhow, my analysis may be wrong, so I expect that someone may correct it. Regards, Kelet
Re: D - Unsafe and doomed
On Saturday, 4 January 2014 at 04:20:30 UTC, David Nadlinger wrote: On Saturday, 4 January 2014 at 02:27:24 UTC, Kelet wrote: While `@safe` helps reduce this class of logic errors […] you can still have […] dangling pointers, hence it is usually considered inferior with regards to safety. This is not true. While it _is_ possible to get null pointers in @safe code, they are not a safety problem, as the first page is never mapped in any D processes (yes, I'm aware of the subtle issues w.r.t. object size here, c.f. Bugzilla). And if you find a way to obtain a dangling pointer in @safe code, please report it to the bug tracker, this is not supposed to happen. There was a SafeD[1] subset of D being worked on, but I'm not sure if it is active anymore. SafeD is D in @safe mode. Cheers, David Thanks for the corrections. Ultimately, it sounds like Rust primarily takes the 'default on' approach for things like safety and immutability, whereas D takes the 'default off' approach. Regards, Kelet
Re: Is it possible for the deimos repositories to be added to the dub registry please?
On Sunday, 5 January 2014 at 20:48:00 UTC, Gary Willoughby wrote: Is it possible for the deimos[1] repositories to be added to the dub registry[2] please? I'm working on a project that uses the deimos x11 bindings and it would be nice to handle building the project using dub. Also, i won't have to distribute the x11 bindings with my project. [1]: https://github.com/D-Programming-Deimos [2]: http://code.dlang.org/ Yes, A lot of Deimos repositories are already in the DUB registry. I think they are handled individually and not collectively. I would imagine forking the repository, creating a DUB package configuration, and submitting a pull request would be the best course of action here. If the pull request is not accepted in a reasonable and timely manner I don't think anyone would object to you adding the forked repository to the DUB registry. Regards, Kelet
Re: Is it possible for the deimos repositories to be added to the dub registry please?
It is also worth noting that specifying git repository URLs rather than being locked into the registry should be added to DUB eventually[1]. Until then, you can always fork it, add a DUB package configuration, and install the package locally or use the "complex variant"[2] of DUB version specifications to use a local path. [1]: https://github.com/rejectedsoftware/dub/issues/104 [2]: http://code.dlang.org/package-format Search for "complex variant" Regards, Kelet
Re: Where is contribution most needed to the D community?
On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote: So, what I actually wanted to ask, which part/project do you think mostly needs contribution? Hello, Given the low frequency of issue reports on some projects, I've definitely noticed a new face in the D ecosystem. I've thought about this problem a little bit as well. The D documentation on this page? For the most part, I've been satisfied with D documentation on the official website. My only general gripe is that there are many outdated pages – sometimes to the point of irrelevance. This can confuse people, given it is on the official website and not marked as outdated. For example: http://dlang.org/safed.html confused me the other day. I did not know it had evolved into @safe. Mono-D (I’ll be using that, already contributed to an issue)? Mono-D is by far my favorite IDE for D. It is cross-platform, free as in speech/beer, and supports DUB package files. Unfortunately, there are a lot of unreported issues or non-reproducable issues which tends to happen when a development team is small. I believe Mono-D and D_Parser are written in C# and not D though. One thing that may be possible and worth doing in the future is using DCD (mentioned later) with Mono-D and combining efforts. Though that is more of a major undertaking. DUB? Sönke is moving along pretty quickly with DUB. I would say having a well fleshed out tutorial or more examples could do it well though. More tutorials on a seperate blog? A lot of D language tutorials and informational resources pander to C++ programmers. I think that we should be more focused on attracting new users or perhaps people who tend to use interpreted languages. See: http://www.rustforrubyists.com/. A lot of people would like a more performant, statically checked, compiled language. D is expressive enough to intersect with a lot of the use cases of a scripting language.
Re: Where is contribution most needed to the D community?
And to expand a bit on my previous post with things I personally thing are important and rather low hanging: - Create style and layout templates for ddox to help us non-designers - Make DCD plugins for editors so they can autocomplete, go to definition, etc. - Create idiomatic D wrappers around deimos/derelict or any other direct C bindings But most of all, the D ecosystem simply needs users who are willing to generate activity in the form of: - Usage of D libraries - Willingness to file issues and follow up on them should a problem arise - Release of software built using D - Discussion within (mailing list, IRC) and beyond (reddit, HN) the D community - Documenting your experiences and creating said discussion - Openness to test drive prospective "big players" in the environment To expand on that last point: I mean using things like DUB, ddox, Mono-D or Pegged early on if possible. This makes them viable that much faster, and we need an ecosystem that makes it simple for a new user to come in and set up a project. Regards, Kelet
Re: Idiomatic D
On Friday, 10 January 2014 at 22:52:36 UTC, NoUseForAName wrote: I want to implement a small program in D for a personal comparison of various programming languages. Given that I am already quite familiar with C/C++ (from K&R C to C++11) I could probably start write working D code right away by just looking up a few basic syntax/standard library things. However, I would like to write idiomatic D code, not "C++ in D". Is there any guide for this? If not, I would like to say that I think having one would be very useful. Assuming a lack of an extensive guide could someone please just give me the cliff notes on how to D properly? I'm pretty new to D myself, but I always strive to write reasonably idiomatic code. So here's more or less what I've picked up: - Use type inference (auto) when possible - Use variable, function, and parameter qualifiers[1] - Use compile time function execution[2] - Constrain templates as much as possible - foreach or higher-order functions are preferred over for/while loops[3] - Do not overuse OOP[4] - Use uniform function call syntax when it makes sense to chain calls or increase readability - Know `alias this` and operator overloads - Put unit tests under each function if you choose to make them - Use Ddoc-style documentation - Many of the examples on Rosetta Code are well-written http://rosettacode.org/wiki/Category:D I think bearophile did many of them. [1]: Some Qualifiers to note - Function: - auto: infer return type - ref: returns a reference, not a value - inout: Deduce immutability (mutable, const, immutability) by parameters - pure: does not modify or use global state or impure functions - nothrow: No possibility to throw an exception - @safe: No operation may corrupt memory - @trusted – consider function safe, even if it cannot be verified so - @system – default, all @safe and @trusted functions are also @system Variable: - const: this reference to the variable is unchangeable - const is nice in function parameters because it can accept mutable, const, and immutable parameters - immutable: all references to the variable are unchangeable - shared: requires that variable is sharable between threads Parameter/Argument: - scope: no reference to variable can be leaked outside of function - in: equivalent to const scope - out: like ref, but gives default value, can be used for multiple returns - inout: see function qualifier definition - lazy: calculate only on usage (can duplicate calculations) Mostly, I find myself trying to use `pure @safe nothrow` in functions, `immutable` in variables, and `in` in parameters as much as possible without modifying semantics too much. [2]: See last example here http://en.wikipedia.org/wiki/Compile_time_function_execution [3]: for(int i = 0; i < 20; i++) => foreach(immutable i = 0; 0..20) OR Use some higher-order function from std.algorithm or whatnot instead [4]: D is not Java. Modules can have their own constructors and private variables and such. Regards, Kelet
Re: Idiomatic D
On Friday, 10 January 2014 at 23:16:10 UTC, Kelet wrote: foreach(immutable i = 0; 0..20) OR Oops, meant foreach(immutable i; 0..20)
Re: Aurora Graphics Library Initial Design Discussion
On Sunday, 19 January 2014 at 06:02:13 UTC, Kelet wrote: My thoughts: ARM support is abysmal in D, IIRC. Realized I may have used strong wording here when a lot of fine work is currently being done. My apologizes, I'm not well-researched into this area of D. Regards, Kelet
Re: Aurora Graphics Library Initial Design Discussion
On Sunday, 19 January 2014 at 05:23:24 UTC, Elvis Zhou wrote: https://github.com/Zoadian/aurora Oops, I thought this is the official repo!! It's a new package added to code.dlang.org yesterday. Doh, I made the same mistake. On Sunday, 19 January 2014 at 03:38:30 UTC, Adam Wilson wrote: System 2D API / 3D API Linux X11 / OpenGL 4.3 Android Canvas / OpenGL ES 3.0 OSX Quartz2D / OpenGL 4.3 iOS Quartz2D / OpenGL ES 3.0 Windows Direct2D / Direct3D 11 Windows RT Direct2D / Direct3D 11 My thoughts: ARM support is abysmal in D, IIRC. This rules out most of the mobile devices until that situation is relieved. In the meantime, the code should be tested on LDC and GDC regularly. Once ARM support is mature on one of the aforementioned backend, it shouldn't be difficult to finalize support. I'm not convinced of two things: - OpenGL should not be used for the 2D API - Direct3D should be a backend Ideally, 2D and 3D graphics should be a specific case of a generalized system which utilizes OpenGL. Thus, there is no need for a separate backend API for 2D graphics. I've done 2D in OpenGL and it was not very painful, although it was not a substantial project. I've used a ton of OpenGL software on a lot of hardware running Windows and never encountered a problem or major deficiency which is not present in Direct3D, hence I don't know why extra effort should be expended to support it as a backend. Backends in order of importance, IMO: - OpenGL 2.0 - OpenGL 2.0 ES - OpenGL 1.1 - Software - OpenGL 4.3 There are a surprising amount of people still on OpenGL 2.0 and 1.1. For everything else: Software backend. It wouldn't hurt to have a 'state of the art' OpenGL 4.3 backend either, but only after all else is done. However, my forays into graphics are mainly hobby game development so I may be missing some elements here. Regards, Kelet
Re: Two Questions
On Tuesday, 4 February 2014 at 16:18:24 UTC, Steve Teale wrote: Popped into my head today. What proportion of the D community develops on Linux of some sort, and what proportion works with a 64 bit OS? And why? My main development platform is x86_64 Linux, because it was free and well-supported so I downloaded it for my laptop which is my main development machine. My laptop has an AMD64 processor, so why not use the proper OS architecture for it? I use Windows 7 on my Desktop, which I do a fair amount of development on, and have a few OSes set up in VirtualBox (a VM) to ensure my software works on most major operating system setups if necessary. Regards, Kelet
Re: RFC: Units of measurement for D (Phobos?)
Tangentially related: https://github.com/biozic/quantities
A minor mention of D
Was watching a YouTube video, and was pleasantly surprised when Minecraft's lead developer and designer made a (albeit small) mention of D as a possible language for game development. https://www.youtube.com/watch?v=cPk6UPVqUJs#t=713
Re: A simple sieve in Phobos?
I've had good luck with Stephan Brumme's block-wise sieve[1], also based on the Sieve of Eratosthenes. It's best when calculating several blocks in parallel, of course. But it's still pretty fast even when used sequentially. [1]: http://create.stephan-brumme.com/eratosthenes/
Re: Typo in Types page
On Sunday, 6 April 2014 at 09:30:47 UTC, Gustavo wrote: In the page http://dlang.org/type.html I believe there is a typo stating that bool is 1 byte instead of 1 bit. I don't think it's a typo. Memory is typically byte-addressable and thus data types are either a byte or larger. Having a data type smaller than a byte means reading or writing to that variable will have to involve bit-twiddling operations which can make operations more expensive. There are bitfields[1] and BitArrays[2] if you really need control of a data type on the bit level. [1]: http://dlang.org/phobos/std_bitmanip.html#.bitfields [2]: http://dlang.org/library/std/bitmanip/BitArray.html
Re: Why aren't you using D at work?
For a small amount of software at work I'm able to use D. Most recently, I used D & vibe.d to communicate with a conveyor belt system for a warehouse. I'd use it more but most of our code and data is tied into a proprietary ecosystem (language, database, etc.). Slowly, we're moving away from this ecosystem toward the JVM, but I will use D where native code makes sense. Thanks, Kelet
Re: Why aren't you using D at work?
On Wednesday, 3 June 2015 at 03:47:00 UTC, Rikki Cattermole wrote: On 3/06/2015 3:35 p.m., Kelet wrote: For a small amount of software at work I'm able to use D. Most recently, I used D & vibe.d to communicate with a conveyor belt system for a warehouse. I'd use it more but most of our code and data is tied into a proprietary ecosystem (language, database, etc.). Slowly, we're moving away from this ecosystem toward the JVM, but I will use D where native code makes sense. Thanks, Kelet Okay, just so I know you haven't had to deal with one of the worst languages ever. It's not jade is it? No, our ecosystem revolves around a proprietary and archaic dialect of COBOL. Thanks, Kelet
Re: Naming things
I agree with Vladimir -- There should be a naming convention for identifying whether a function is eager or lazy. Learning a naming convention once and applying it repeatedly is a better process than repeatedly referencing documentation. A programming language should have built-in functionality that is named in such a way that it clearly expresses its intent. For newbies, it can be very off-putting to be introduced to a language where this is not the case. Perhaps some veterans of the D language can't clearly see this. There is no good reason that the new introduction of built-ins should not follow a well-defined naming scheme. I'd actually go a bit further and deprecate old functions that do not meet the scheme and phase them out over time. Bikeshedding is arguing over trivial naming schemes. Choosing to adhere to a naming scheme is not bikeshedding, IMHO. Thanks,
Re: I released my first library!
On Thursday, 25 June 2015 at 14:56:34 UTC, Vladde Nordholm wrote: For the past week I've been working on my first small cross-platform gamedev-ish console rendering library for d, and I call it clayers. It has been a fun learning process, as I've used many new programs and features. The whole thing is written in vim, which I've never used until now. I got a better understanding of how git works by using the terminal, instead of a GUI. For the first time I used version() for different functions. Finally, I added a releasetag, and then registered it to dub. While I didn't think about it while writing the code, I've gotten a better knowledge of how all of these things work. And this extra stuff I learnt without even thinking about it. GC is something I've never though about before, but thanks to people from #d I now have a better understanding of how it works. Thanks! As for actually writing code: I've gotten to design the library myself, debugged it, and everything that comes with making an library. I've had discussions with people about the rendering and generally come to good terms with many in the #d channel. Thanks to the whole D community it became more fun than I'd ever imagine. Thanks for being here D-people! --- The dub package: http://code.dlang.org/packages/clayers Awesome, congrats on releasing your first library. If you intend to work on it further, I'd like to see: - A way to call a function when a specific key is pressed (key binding) - More portability, better support for other terminals; see termbox source code for a reasonable level of portability - Colors! But I guess we could probably combine your library with the "color" library for that, right? I do enjoy the gif that shows the functionality. I bet using Unicode characters for borders and such would look nice.
