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 don't have generated HTML documentation uploaded anywhere at the moment. However, most declarations are annotated with DDoc comments, and the unittest blocks work as examples.
Re: Article: Functional image processing in D
On Saturday, 22 March 2014 at 11:25:05 UTC, Phil wrote: This is very cool. What are the performance implications of treating colour images as arrays of tuples rather than a flat array? For example, if I wanted to iterate through every channel of every pixel in an RGB image or modify the R channel of every pixel, could I generally expect the compiler to optimise the extra overhead away? Also, do you have any ideas on how you could vectorise code like this while still providing a nice API? One might say that this approach has the innate benefit that the loop (to iterate over each channel) will be unrolled explicitly :) However, if you need to perform operations on individual channels, it would probably be worthwhile to unpack a multi-channel image into several images with just one channel. I'm not familiar enough with vector instruction sets of current CPUs to answer this confidently. E.g. if there exists an integer vector multiply-and-add operation, then that could be used for fast software alpha blending. That operation's restrictions would dictate the optimal memory layout of the image. E.g. if the operation requires that the bytes to multiply and add are contiguous in memory, then it follows that the image should be represented with each channel as a separate sub-image.
Re: Article: Functional image processing in D
On Sunday, 23 March 2014 at 08:22:32 UTC, Vladimir Panteleev wrote: I'm not familiar enough with vector instruction sets of current CPUs to answer this confidently. E.g. if there exists an integer vector multiply-and-add operation, then that could be used for fast software alpha blending. That operation's restrictions would dictate the optimal memory layout of the image. E.g. if the operation requires that the bytes to multiply and add are contiguous in memory, then it follows that the image should be represented with each channel as a separate sub-image. There is the PMADDWD instruction that can be used for 8-bit blending. I don't think it requires a particular layout from the implementation, blending would probably be dominated by memory accesses.
Re: 1st draft of complete class-based std.random successor
On Saturday, 22 March 2014 at 23:56:35 UTC, bearophile wrote: They seem good. Excellent! There may need to be some attention to the internals of uniform01. Its correctness depends on whether one can always trust a float-based RNG to return values in [min, max) or whether [min, max] is also going to be supplied by some. More ideas: Three suggestions for std.random: https://d.puremagic.com/issues/show_bug.cgi?id=4851 I think all std.random functions now support a default RNG. There were some bugs related to that (e.g. the can't use Xorshift one) that I fixed last year. The problem you identify with, int r = randomCover(data, rndGen).front; always returning the same value, is down to the fact that rndGen is being copied inside the RandomCover struct by value, so of course the original rndGen is never updated and each of these calls will produce the same result. The new std.random2 fixes that, because the RNGs are reference types. However, I'd have thought that int r = data.sample(1, rndGen).front; would have been a more efficient way to implement choice, as it can operate on any input range, as long as it has the .length property; and it ought to be _much_ faster than even a single call to randomCover. One could always use this as a default option, with a specialization where data is a RandomAccessRange to use the more efficient int r = data[uniform![)(0, data.length)]; Strongly pure random generator: https://d.puremagic.com/issues/show_bug.cgi?id=5249 .front and .popFront at least are pure for _all_ the RNGs currently implemented in std.random2.generator. See e.g.: https://github.com/WebDrake/std.random2/blob/master/std/random2/generator.d#L266-L272 https://github.com/WebDrake/std.random2/blob/master/std/random2/generator.d#L506-L517 https://github.com/WebDrake/std.random2/blob/master/std/random2/generator.d#L821-L834 Of course this is not strongly pure in line with your request, but it should enable use of these RNGs in many other scenarios where purity is important. I hope a gaussian (normal distribution) generator is planned or present. https://github.com/WebDrake/std.random2/blob/master/std/random2/distribution.d#L326 This is a range implementation; there will also be a function implementation, which will probably follow the inefficient Box-Muller variant that uses 2 uniform random variates to generate a single normal variate (as per the example you posted in your feature request).
Re: Happy Tenth Birthday, GDC!
On 23 March 2014 02:05, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Hello everyone, Today GDC celebrates 10 years of existence. Please join me in expressing sincere congratulations to everyone who contributed to the project. I would like to emphasize that GDC is a key component of D's present and future success, and I am looking forward to more awesome progress from Iain, Johannes and hopefully an ever-growing gang! Happy Birthday! Andrei Thanks Andrei. I'm look forward to seeing people wishing to get onboard too. :) For those who are into nostalgia, here's the original release/announcement. http://forum.dlang.org/thread/c3mnst$2htg$1...@digitaldaemon.com http://forum.dlang.org/thread/c3nk2h$11ha$1...@digitaldaemon.com
Re: 1st draft of complete class-based std.random successor
Joseph Rushton Wakeling: int r = data[uniform![)(0, data.length)]; D also accepts: immutable r = data[uniform![)(0, $)]; Bye, bearophile
Re: 1st draft of complete class-based std.random successor
Joseph Rushton Wakeling: I think all std.random functions now support a default RNG. Is the issue is already fixed in std.random you can close it :-) However, I'd have thought that int r = data.sample(1, rndGen).front; would have been a more efficient way to implement choice, as it can operate on any input range, as long as it has the .length property; and it ought to be _much_ faster than even a single call to randomCover. One could always use this as a default option, with a specialization where data is a RandomAccessRange to use the more efficient int r = data[uniform![)(0, data.length)]; The best thing is to add an efficient choice() function, so no efficiency mistake happens :-) Strongly pure random generator: https://d.puremagic.com/issues/show_bug.cgi?id=5249 .front and .popFront at least are pure for _all_ the RNGs currently implemented in std.random2.generator. See e.g.: https://github.com/WebDrake/std.random2/blob/master/std/random2/generator.d#L266-L272 https://github.com/WebDrake/std.random2/blob/master/std/random2/generator.d#L506-L517 https://github.com/WebDrake/std.random2/blob/master/std/random2/generator.d#L821-L834 Of course this is not strongly pure in line with your request, but it should enable use of these RNGs in many other scenarios where purity is important. So you are saying that those RNGs are already weakly pure and they can't become strongly pure because they take the engine as mutable class reference. And even if you design a very small random engine that can be created every time you call a random generator, the API of all the random functions is not compatible with it. So it's not a simple problem... This is a range implementation; there will also be a function implementation, which will probably follow the inefficient Box-Muller variant that uses 2 uniform random variates to generate a single normal variate (as per the example you posted in your feature request). A possibility is to also add a less precise (more approximate) but faster function implementation. Are the ddocs produced by std.random2 online somewhere? Bye, bearophile
Re: 1st draft of complete class-based std.random successor
On Sun, Mar 23, 2014 at 11:17 AM, bearophile bearophileh...@lycos.com wrote: Joseph Rushton Wakeling: int r = data[uniform![)(0, data.length)]; D also accepts: immutable r = data[uniform![)(0, $)]; Really? The '$' part works?
Re: 1st draft of complete class-based std.random successor
On Sunday, 23 March 2014 at 10:15:32 UTC, bearophile wrote: Is the issue is already fixed in std.random you can close it :-) Well, your request for a choice method is still open ... :-) The best thing is to add an efficient choice() function, so no efficiency mistake happens :-) Sure, I'm simply raising a couple of simple internal implementations that could be used for an effective first draft of that function. So you are saying that those RNGs are already weakly pure and they can't become strongly pure because they take the engine as mutable class reference. And even if you design a very small random engine that can be created every time you call a random generator, the API of all the random functions is not compatible with it. So it's not a simple problem... I think I need to make some detailed research into how Haskell and other functional languages handle randomness before commenting here. What it does seem to me at this stage is that while a weakly pure range-based RNG is readily possible (as implemented in std.random2.generator now), I'm not sure that the range-based approach typical of Phobos plays nicely with strong purity where random number generation is concerned. A possibility is to also add a less precise (more approximate) but faster function implementation. Again, this is something I'll look into. I need to re-read the paper on gaussian-distribution algorithms that I linked to earlier in this thread, but my recollection is that the speed/precision tradeoff is something of a false dichotomy given the algorithms out there now; so a good range-based solution (which stores internal state) will probably be able to provide high-quality normal variates faster than a low-quality, purely function-based implementation. Are the ddocs produced by std.random2 online somewhere? Not yet. I can make that happen :-)
Re: GDC ARM beta #1 (with binary releases!)
On 17 March 2014 14:05, Johannes Pfau nos...@example.com wrote: I'm happy to announce the first GDC ARM beta on behalf of the GDC team :) Johannes, I just looked at the permissions of two randomly tested tarballs, and I see the extracted contents is absent of any write permissions. More of an annoyance if you install via extract + move. No one likes a permission denied error when doing an operation from their own home directory. :o) Regards Iain.
Experimental win32 OMF linker written in D now on github
So a couple of years ago I had too much free time and wrote a linker. It's now on github: https://github.com/yebblies/ylink Pros: - Written in D - Not written in assembly - Not written before I was born - Boost license - Usually produces working executables Cons: - No debug information (yet) - Slower than optlink - Uses more memory than optlink (cannot run with 64k of ram) - Cannot produce DLLs (yet) - Not really tested It still needs a lot of work, but it's functional. Potential uses: - Replace optlink - Replace microsoft linker (we could ship this with dmd) - Call from dmd to do in-memory linking - Experiment with linker optimizations Enjoy!
Re: GDC ARM beta #1 (with binary releases!)
By the way, I verified this can also be used for bare metal ARM programming as described in https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.0-Introduction Very very cool, ian On Monday, 17 March 2014 at 14:07:13 UTC, Johannes Pfau wrote: I'm happy to announce the first GDC ARM beta on behalf of the GDC team :) ARM support is now at a point where the automated tests (test suite, unit tests) pass and we're ready for feedback from real world usage. All changes have been fully integrated into the standard GDC sources which also means we're currently using the 2.064 frontend. ARM support is currently limited to ARM/GNU Linux, i.e. GlibC. (This especially means Android and bare metal programming are not officially supported). Please report all bugs to http://bugzilla.gdcproject.org/ If you're sure that the bug is a bug in phobos/druntime/DMD frontend and not GDC specific please report it to https://d.puremagic.com/issues Getting the ARM beta * All necessary code changes have been merged into Druntime, Phobos and GDC and you can simply get the latest GDC sources and build them on ARM. ( http://wiki.dlang.org/GDC/Installation/Generic ) * GDC is also part of the official Archlinux ARM repositories. To get GDC for Archlinux ARM, simply use these commands: pacman -S gdc libgphobos-devel You can also get dub on Archlinux ARM by executing pacman -S dub Many thanks to Dicebot for maintaining the Archlinux packages. * We provide binary cross compilers for windows X86 (32/64bit) and Linux x86 (32/64bit). We also provide 'native' compilers which run directly on ARM machines. http://gdcproject.org/downloads/ Note: Linux distribution packages or building from source should be preferred. Precompiled GDC binaries Precompiled toolchains are available for ARM hardfloat and ARM softfloat systems. These toolchains target systems with relatively recent glibc and linux kernel (GlibC = 2.14, Linux = 2.6.32). To check if you need the hard- or softfloat version run gcc -v where gcc is a working gcc for your ARM target. Then look for --with-float= in the output: --with-float=soft == softfloat --with-float=hard == hardfloat --with-float=softfp: We have no special binaries for these systems. Either compile GDC from sources or use the softfloat binaries. The softfloat binaries should work in 99% of all cases. The only known exception is using floating point functions in fibers, a 'softfp' toolchain is required in this case. To compile for ARM simply use this gdc executable: ./arm-gdcproject-linux-gnueabi[hf]/bin/arm-gdcproject-linux-gnueabi[hf]-gdc Note: The toolchain directories are write protected. If you want to change this, use chmod +w -R arm-gdcproject-linux-gnueabi[hf]. For more information on how to use additional libraries with the cross compilers, see http://crosstool-ng.org/hg/crosstool-ng/raw-file/e11a8a2e225d/docs/5%20-%20Using%20the%20toolchain.txt Known issues Known ARM-specific issues * std.internal.math.gammafunction.d is not ported yet (Help here is very appreciated!) * Array ops are evaluated in reverse order (WIP, FE 2.065) http://bugzilla.gdcproject.org/show_bug.cgi?id=8 Known issues with the binary builds * If you extract 7z files and are asked if you want to overwrite files, answer yes (toolchains are built on case sensitive filesystems, extracting on case insensitive filesystems will cause this warning) * Use the arm-...-gdc.exe executables and not bin/arm.../gdc.exe. * Unfortunately there's no multilib support for now. We use crosstool-NG to build these toolchains and multilib support in crosstool-NG is broken. However, this might change in the next few months.
Re: GDC ARM beta #1 (with binary releases!)
Am Sun, 23 Mar 2014 20:20:09 + schrieb Iain Buclaw ibuc...@gdcproject.org: On 17 March 2014 14:05, Johannes Pfau nos...@example.com wrote: I'm happy to announce the first GDC ARM beta on behalf of the GDC team :) Johannes, I just looked at the permissions of two randomly tested tarballs, and I see the extracted contents is absent of any write permissions. More of an annoyance if you install via extract + move. No one likes a permission denied error when doing an operation from their own home directory. :o) Regards Iain. crosstool-NG does that by default to prevent people from installing libraries into the sysroot. But if you think the we should set the write permissions it's a simple change in the configuration, I just kept the default.
Re: Article: Functional image processing in D
On Friday, 21 March 2014 at 11:16:31 UTC, Andrea Fontana wrote: Very interesting! Do you know http://www.antigrain.com/ ? It is (was?) a very efficent c++ 2d library, heavily based on templates. Something like this in D with templates and lazy ranges should be impressive. On Friday, 21 March 2014 at 11:04:58 UTC, Vladimir Panteleev 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. I've got an AGG inspired 2D rasterizer on github. https://github.com/finalpatch/dagger it's not as template heavy or making extensive use of ranges as the OP's.
DSFML to recieve many updates soon!
Hey all! With my term now finished I have loads of free time over the next two weeks, so I decided to devote a nice chunk of that to DSFML, specifically updating it to version 2.1. For those of you that aren't familiar, DSFML is a binding and wrapper for SFML, a multimedia library centered around game development. The reason I am announcing it now is because I will be making changes to not only the D front end, but also to the C/C++ back end. Some of these changes will be breaking changes to the current API. I'm assuming that a majority of people that use DSFML also use DUB, so I want them to be aware of this. Very soon I'll have a specific branch for DSFML 2.0, and I will post another announcement once it is up, which will also mark when development on. Should be tomorrow or the next day. -Jeremy
