Re: Article: Functional image processing in D
On Saturday, 22 March 2014 at 13:35:01 UTC, Philippe Sigaud wrote: On Fri, Mar 21, 2014 at 12:04 PM, Vladimir Panteleev vladi...@thecybershadow.net wrote: http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/ Some highlights from a recent overhaul of the graphics package from my D library. It makes use of a number of D-specific language features, so I've tried to make the article accessible to people new to D as well. The article is wonderful, very clear and a good introduction to many D idioms. I'd like to use your graphics package as well, but I don't see any documentation (ddoc, wiki?). Is there some somewhere? I think this is it: https://github.com/CyberShadow/ae Graham
Re: DConf 2013 Day 2 Talk 6: Higgs, an experimental JIT compiler written in D by Maxime Chevalier-Boisvert
On Friday, 7 June 2013 at 15:05:15 UTC, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/ Hackernews: https://news.ycombinator.com/item?id=5839283 Twitter: https://twitter.com/D_Programming/status/343019685744369664 Facebook: http://facebook.com/dlang.org/posts/652988644714820 Youtube: http://youtube.com/watch?v=hJUNHX0vakI Please drive discussions on the social channels, they help D a lot. Andrei I've also cross-posted it to /r/d_language: http://redd.it/1fv8y2 /r/programming is great for PR and engagement, but I like /r/d_language for its very high signal:noise (for one thing, it's easier to find past posts!). /r/d_language currently has 857 subscribers (http://stattit.com/r/d_language/). Looking forward to some growth there, as all these videos attract interested newcomers. Regards, Graham
Re: DConf 2013 Day 2 Talk 4: Web Development in D by Vladimir Panteleev
On Monday, 3 June 2013 at 22:11:39 UTC, Nick Sabalausky wrote: Referring to the last question: Hibernate-D is *not* based on Vibe.d. But I have already been looking into the idea of using Hibernate-D and Vibe.d together. In fact, my recent commits to mysql-native adding support for Phobos sockets was a big part of that. The main issue is that Vibe.d programs should be using Vibe.d sockets instead of ordinary sockets (I don't know what would happen if you don't use Vibe.d sockets. My guess is it just wouldn't happen asynchronously, but Sonke could answer that better). But Hibernate-D aims to be usable even without Vibe.d, so it uses Phobos sockets for MySQL (via a modified fork of an older mysql-native), and for PostgreSQL and SQLite it just uses the C libs. I've already converted mysql-native to support both Vibe.d and Phobos sockets, and I've already created a branch of Hibernate-D that makes Hibernate-D use the new official mysql-native and therefore automatically switch to Vibe.d sockets whenever Vibe.d is being used (detected by -version=Have_vibe_d, which is automatically added by DUB is you're using both Vibe.d and DUB). But G^DF*^@CKD*#MMIT I *just now* noticed that commit (and the pull request I could have sworn I made) seems to have completely disappeared without a trace...Shit, I gotta figure out what happened and where the hell it went... Ugh, anyway, I've been digging through Hibernate-D's source the last couple days checking out what else might be needed. As long as I get my magical disappearing commit resurrected, it *looks* to me like the only other thing that might be needed is to bypass Hibernate-D's built-in connection pool. Even that might still work as-is (I haven't tried), but it's not really necessary for Vibe.d users since Vibe.d has its own fiber-safe connection pool system. But it's pretty easy to bypass Hibernate-D's connection pool in favor of Vibe.D's connection pool in user-code without even patching Hibernate-D. AFAICT so far, it looks like everything else in Hibernate-D should work fine with Vibe.d. tl;dr: Hibernate-D does not use Vibe.d, but I have personal interest in using them together and I've been checking into it. Not sure what can be done about PostgreSQL and SQLite (I *think* they'll work but just not asynchronously - not sure what else can/should be done, I'd have to ask Sonke). But for MySQL, all you *should* need is a patch or two that I've been working on. Regarding PostgreSQL, keep in mind that it has an async API, which would be handy in building a Vibe-friendly wrapper: http://www.postgresql.org/docs/devel/static/libpq-async.html Graham
Re: DConf 2013 Day 1 Talk 7: Panel with Walter Bright and Andrei Alexandrescu
On Wednesday, 22 May 2013 at 13:08:50 UTC, Andrei Alexandrescu wrote: Destroy: http://www.reddit.com/r/programming/comments/1etxqy/dconf_2013_day_1_talk_7_panel_with_walter_bright/ Andrei A request, sir: When posting these videos to /r/programming, would you mind also posting them to /r/d_language ? As a lower-volume, targetted subreddit, the links will stay near the top for longer there, and will be easier to find. Regards, Graham
Re: DConf 2013 Day 1 Talk 7: Panel with Walter Bright and Andrei Alexandrescu
On Wednesday, 22 May 2013 at 19:06:14 UTC, Graham Fawcett wrote: On Wednesday, 22 May 2013 at 13:08:50 UTC, Andrei Alexandrescu wrote: Destroy: http://www.reddit.com/r/programming/comments/1etxqy/dconf_2013_day_1_talk_7_panel_with_walter_bright/ Andrei A request, sir: When posting these videos to /r/programming, would you mind also posting them to /r/d_language ? As a lower-volume, targetted subreddit, the links will stay near the top for longer there, and will be easier to find. Regards, Graham I've just posted the first seven videos there. Graham
Re: vibe.d 0.7.14 and DUB 0.9.12 released
On Friday, 22 March 2013 at 08:46:23 UTC, Sönke Ludwig wrote: Apart from some fixes vibe.d received some performance tuning and multi-threaded request processing (thanks to Dicebot for digging up some documents of how Nginx does this). Awesome! I had hoped you would add multi-threaded processing. I'm looking forward to playing with this. Graham The result is a nice increase in performance (~48 kreq/s vs. 25 kreq/s top) and 10k parallel connections can now easily be handled, at least on 64-bit systems (the needed _virtual_ memory can grow quite large, but real memory use stays low). DUB has received a number of fixes for bugs that were introduced in the previous release and some smaller enhancements. It now also has Debian packages maintained by Jordi Sayol available. vibe.d change log and download: http://vibed.org/blog/posts/vibe-release-0.7.14 http://vibed.org/download DUB change log: https://github.com/rejectedsoftware/dub/blob/master/CHANGELOG.md http://registry.vibed.org/download
Re: Crystal
On Sunday, 17 February 2013 at 06:28:09 UTC, Ary Borenszweig wrote: Hello everyone :-) I follow this newsgroup from time to time. I like D templates. I like the auto keyword. I like auto in templates. I love efficiency and expressiveness. I believe in smart compilers. (you might remember me: I'm the author of Descent) I *really* like D, because it cares about one thing I care about: *performance*. Let's save this world's energy. Let's make a better world. Let's make users' life more enjoyable. Let's be happy :-) But... do we really have to specify const pure safe nothrow and whatnot? Can't the compiler be smarter? I'm sure there must be a better way. Most new programming languages look like older ones. Newness comes slowly... One time I asked in this newsgroup if it was possible to have an auto keyword for function/method arguments. And... why not make all functions/methods be templates on the type of its arguments? I think nobody liked this idea. I said Ruby is like this: you never specify types in method definitions. But Ruby is not efficient. Ruby is a dynamic language. D is compiled, so it's faster. Don't make the mistake of comparing a dynamic language with a static/systems programming language. This were some of the answers I got. I started thinking about this idea: a compiled language that looked like a dynamic language. Is it possible? Today, I'd like you to take a look at what me and my friend Juan have been working on for the last half month or so. It's a new programming language which aims to be efficient, have similar syntax to Ruby, and where you never have to specify types of variables and arguments. https://github.com/manastech/crystal/wiki/Introduction I'd also like to ask you: 1. Do you know whether a similar language exists? It's not Ruby-like, but Julia has some similarities: http://julialang.org/ Best, Graham
Re: Short article on std.parallism
On Sun, 29 May 2011 18:18:14 -0700, Jeremy Wright wrote: I implemented bucket sort in D to demonstrate how easy it is to use std.parallelism. I welcome any feedback. http://www.codestrokes.com/archives/116 Haven't read it yet, but: like many faucets -- like many facets Best, Graham
Re: D rpm packages for Linux
On Fri, 25 Jun 2010 17:45:00 +0200, Jordi Sayol i salomó wrote: En/na Ellery Newcomer ha escrit: And My preferred solution, create a i386 chroot machine inside Your x86_64 system, install dmd package on it and compile Yours D programs on it too. I've never found a need to do this (and I also don't know how). Try it! is clean, easy and faster than other virtual machines, for text mode. I don't know how to install it in Fedora. In Ubuntu just install debootstrap. On Debian-like systems, chroot is used to build/compile packages for other architecturesthan the host system, if it is possible. +1 for this. On Debian/Ubuntu systems, I find that 'schroot' makes it very easy to manage and work with chroots, including running chrooted programs from the host system. Best, Graham
File.byLine ought to return dups?
Hi folks,
I expected the following program to print the lines of a file in
reverse:
// bad.d
import std.stdio;
import std.range;
void main() {
auto f = File(bad.d);
foreach(char[] line; retro(array(f.byLine(
writeln(line);
}
However, this produces very unusual output: fragments of the same
lines are printed repeatedly. I suspect it's because the byLine()
'generator' is not dup'ing the arrays it reads from the file.
This works as expected:
// good.d
import std.stdio;
import std.range;
Retro!(char[][]) retroLines(File f) {
char[][] lines;
foreach(line; f.byLine())
lines ~= line.dup; // note the .dup
return retro(lines);
}
void main() {
auto f = File(good.d);
foreach(line; retroLines(f))
writeln(line);
}
If you remove the '.dup', then this behaves badly as well.
So is this a bug in File.byLine, or am I just using it badly? :)
Thanks,
Graham
Re: File.byLine ought to return dups?
Sorry for the double-post to .announce -- I had deleted my .announce
post, but obviously not thoroughly enough. I'll follow up on the list.
Graham
On Fri, 04 Jun 2010 15:41:43 -0400, Steven Schveighoffer wrote:
On Fri, 04 Jun 2010 15:27:03 -0400, Graham Fawcett fawc...@uwindsor.ca
wrote:
Hi folks,
I expected the following program to print the lines of a file in
reverse:
// bad.d
import std.stdio;
import std.range;
void main() {
auto f = File(bad.d);
foreach(char[] line; retro(array(f.byLine(
writeln(line);
}
However, this produces very unusual output: fragments of the same lines
are printed repeatedly. I suspect it's because the byLine() 'generator'
is not dup'ing the arrays it reads from the file.
This works as expected:
// good.d
import std.stdio;
import std.range;
Retro!(char[][]) retroLines(File f) {
char[][] lines;
foreach(line; f.byLine())
lines ~= line.dup; // note the .dup
return retro(lines);
}
void main() {
auto f = File(good.d);
foreach(line; retroLines(f))
writeln(line);
}
If you remove the '.dup', then this behaves badly as well.
So is this a bug in File.byLine, or am I just using it badly? :)
The latter. File is re-using the buffer for each line, so you are
seeing the data get overwritten. This is for performance reasons. Not
everyone wants incur heap allocations for every line of a file ;) As
you showed, it's possible to get the desired behavior if you need it.
The reverse would be impossible.
Now, that being said, a nice addition would be to create a duper range
that allows you to do one expression:
foreach(char[] line; retro(array(duper(f.byLine()
-Steve
Re: dcollections 1.0 and 2.0a beta released
Hi Steven, On Wed, 19 May 2010 12:09:11 -0400, Steven Schveighoffer wrote: After much work and toil, I have created dcollections for D2. I think I can say that this is the first collection package available for D2. I still hold hope that it will be used as the standard collection package for phobos for D2. Cool! In case anyone's interested, I tried out dcollections using my very alpha 'd-build' script, and it works just fine: http://github.com/gmfawcett/d-build/tree/dcollections-test tarball of the dcollections test branch: http://github.com/gmfawcett/d-build/tarball/dcollections-test Checking out the 'dcollections-test' branch of that git project, you should be able to just run './d-build test.d' and it will first download dcollections and then compile it along with the test program. There are several limitations; see the README for details. There's a long way to go before d-build is more than a toy. But I'd like to keep it on people's radars, and am interested in your thoughts and feedback. See the envy for go packages threads on this list for context. Regards, Graham Please visit http://www.dsource.org/projects/dcollections for details. Some VERY IMPORTANT notes for this release: 1. it is very beta software. Although the implementation has changed very little from the 1.0 version, not everything will properly compile. I have filed several compiler bugs to fix some problems I had while porting, and inserted workarounds for things I could work around. Please use the LATEST compiler (currently 2.046) because some very important features have been added that dcollections relies on. Although it is beta, the algorithms and implementation is largely unchanged so functionality should be pretty solid. 2. the docs are not online for d2. Unfortunately, dsource's auto-doc-generator that I was using for the 1.0 version is based on a 1.0 compiler, so it will not automatically generate the d2 docs. However, I have included some basic ddoc generated docs in the download package, don't expect them to be very fun to use :) 3. The docs are not fully updated, so they might be just flat out wrong! I plan to update the docs completely for the next beta release. So, for the good stuff... here are some notes for differences between 1.0 and 2.0: * Ranges! * Filled out slicing for all containers * Cursors are now non-movable. Use ranges for safe iteration. * The interfaces have been cut down significantly. The question I asked myself when deciding whether I wanted to keep an interface is would anyone use this interface? * Functions that should be fast but can be slow (O(n)) have been removed from all interfaces, and in most cases, from the containers. Notably missing is searching a non-quick lookup container for a value. Use std.algorithm.find for that. * ArrayMultiset has been removed -- it's complexity functions did not fit with the multiset requirements (specifically, quick lookup of an element's presence). * ArrayList slicing now simply returns a range instead of a live slice. Note that an ArrayList range is aliased to a D array. * Full unit tests added for all container types. I have also changed the license from BSD to Boost. I have also formally released version 0.03 as version 1.0, nothing has changed there, including the license. However, no new features will be added to dcollections version 1.0, only bug fixes will be done. Please, file tickets on dsource for any problems you have. And let me know if there are any ideas you think would be useful. -Steve
Re: dcollections 1.0 and 2.0a beta released
On Wed, 19 May 2010 20:27:17 +, Graham Fawcett wrote: Hi Steven, On Wed, 19 May 2010 12:09:11 -0400, Steven Schveighoffer wrote: After much work and toil, I have created dcollections for D2. I think I can say that this is the first collection package available for D2. I still hold hope that it will be used as the standard collection package for phobos for D2. Cool! In case anyone's interested, I tried out dcollections using my very alpha 'd-build' script, and it works just fine: http://github.com/gmfawcett/d-build/tree/dcollections-test tarball of the dcollections test branch: http://github.com/gmfawcett/d-build/tarball/dcollections-test Checking out the 'dcollections-test' branch of that git project, you should be able to just run './d-build test.d' and it will first download dcollections and then compile it along with the test program. There are several limitations; see the README for details. There's a long way to go before d-build is more than a toy. But I'd like to keep it on people's radars, and am interested in your thoughts and feedback. See the envy for go packages threads on this list for context. Apologies; the envy for go packages thread is on the D list, not on D.announce. Graham
