Article: Functional image processing in D
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.
Re: Article: Functional image processing in D
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.
Re: Article: Functional image processing in D
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. Are you planning on adding a font rasterizer and can it work at CTFE? If it does both I have some neat ideas for exporting of UML diagrams.
Re: Article: Functional image processing in D
Wow, great stuff here. If anybody else asks me What is D good for? again I'll point them to this. Atila 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.
Re: Article: Functional image processing in D
On Friday, 21 March 2014 at 12:27:57 UTC, Rikki Cattermole wrote:
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.
Are you planning on adding a font rasterizer
Parsing vector font files is a big undertaking. I'd likely use a
text rendering library, such as FreeType. Hardcoding a small
bitmap font for ASCII only is also a possibility.
and can it work at CTFE?
This program almost works:
string drawSmiley()
{
import std.range;
import std.math;
import ae.utils.graphics.draw;
import ae.utils.graphics.image;
auto smiley = Image!char(20, 20);
smiley.fill(' ');
smiley.fillCircle(10, 10, 10, '#');
smiley.fillCircle( 6, 6, 2, ' ');
smiley.fillCircle(14, 6, 2, ' ');
smiley.fillSector(10, 10, 6, 8, 0, PI, ' ');
return smiley.h.iota.map!(y =
smiley.scanline(y)).join(\n).idup;
}
pragma(msg, drawSmiley);
almost because fillSector calls atan2, which doesn't work in
CTFE. :(
(And yeah, I totally did just declare an image with a colorspace
of char.)
Re: Article: Functional image processing in D
Vladimir Panteleev: http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/ It looks nice. I suggest to not pack too much the code of the examples, so I suggest to put spaces around operators, etc. It can be useful to add some benchmarks to compare its performance to equivalent regular foreach-based processing code in C/D. Bye, bearophile
Re: Article: Functional image processing in D
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. That's awesome. When I see examples of some of the amazing stuff you can do with D, I wonder if D is the new Lisp. Hugely under-appreciated and immensely powerful. Now if we can just correct the former...
Re: Article: Functional image processing in D
Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/2101ti/functional_image_processing_in_d/ But I have suggested some improvements of the article :-( Bye, bearophile
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 21:17:33 UTC, Joseph Rushton Wakeling wrote: On Thursday, 20 March 2014 at 08:30:09 UTC, ponce wrote: Related: please consider using parts of SimpleRNG the excellent work of John D. Cook which provides many random distributions in a compact and documented way. https://github.com/p0nce/gfm/blob/master/math/gfm/math/simplerng.d (here a port) Good call, I'll take a close look at that. Can you provide me with a link to the original project too? (Yes, I can just Google it, I'm being lazy:-) http://www.johndcook.com/SimpleRNG.h http://www.johndcook.com/SimpleRNG.cpp You will find that there is no license information. But the author intended this as public domain, he will confirm if send an e-mail.
Re: Article: Functional image processing in D
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. That's really cool. I have some notes though: * All the function templates separate the template declaration from the function declaration, when they can just use the function template syntax. * Any type is accepted for the colour type, even though certain basic assumptions are made, such as the colour type being assignable to itself. * Image.w/h/pixels should probably be read-only properties in the public interface. * Any particular reason that coordinate integers are signed? `isView` seems to prefer `size_t`. * `Warp` should probably have a `if (isView!V)` constraint. * `warp` exclusively uses string expression arguments... * I'd recommend sticking to structs (often with AliasThis) over mixins for as far as it goes, as it's much more structured, thus easier to read and reason with. * The most common style for template parameter names (Phobos uses it, too) is just `Color`, not `COLOR`. * I know w and h are common abbreviations used in C, but they seem unnecessary in D - detrimental rather - if your code examples are anything to go by. It's always nice to know examples of high performance range-based code. I noticed that the `View` concept does not have the concept of stride or access to pixels using a single absolute coordinate; maybe if that was the case, the `blitTo` algorithm could be optimized to its conclusion, instead of copying scanlines one by one.
Re: 1st draft of complete class-based std.random successor
On Friday, 21 March 2014 at 16:01:28 UTC, ponce wrote: On Thursday, 20 March 2014 at 21:17:33 UTC, Joseph Rushton Wakeling wrote: On Thursday, 20 March 2014 at 08:30:09 UTC, ponce wrote: Related: please consider using parts of SimpleRNG the excellent work of John D. Cook which provides many random distributions in a compact and documented way. https://github.com/p0nce/gfm/blob/master/math/gfm/math/simplerng.d (here a port) Good call, I'll take a close look at that. Can you provide me with a link to the original project too? (Yes, I can just Google it, I'm being lazy:-) http://www.johndcook.com/SimpleRNG.h http://www.johndcook.com/SimpleRNG.cpp You will find that there is no license information. But the author intended this as public domain, he will confirm if send an e-mail. Hey he uses MWC algorithm! (but not the improved CMWC)
Re: Article: Functional image processing in D
On Fri, 21 Mar 2014 11:04:57 +, 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. Good writeup. Excellent job linking to the Phobos docs and other articles. I can see people clicking through to Voldemort Types, etc., making your article a gateway to the world of interesting things that D has to offer.
Re: Article: Functional image processing in D
On Friday, 21 March 2014 at 16:21:18 UTC, Jakob Ovrum wrote: 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. That's really cool. I have some notes though: * All the function templates separate the template declaration from the function declaration, when they can just use the function template syntax. Where this is done, it is on purpose. For example, the invert declaration as it appears in the article wouldn't be possible with the shorthand function template syntax. * Any particular reason that coordinate integers are signed? Yes. I've tried using unsigned coordinates in the past. It was awful. My conclusion is that if you ever need to subtract values, you should use signed types. `isView` seems to prefer `size_t`. int implicitly casts to size_t but not the other way around. * `warp` exclusively uses string expression arguments... Yeah. A lambda would need to receive x, y, w and h, and we don't have naryFun in Phobos. (It's there but commented out for some reason.) To a small extent, I made some compromises for the first iteration for the sake of code looking good for the article, and maybe with the help of feedback improve on that. For example, a problem I've struggled with is avoiding having two overloads for almost every function in image.d. I've tried multiple approaches: default arguments (in the form of *new Image!COLOR), templates, string mixins, UDAs, pointers, but they all were rather ugly or impractical. Some related compiler issues are 8074, 12386, 12425 and 12426 - fixing those might make some of those approaches more feasible. * I'd recommend sticking to structs (often with AliasThis) over mixins for as far as it goes, as it's much more structured, thus easier to read and reason with. That doesn't work if you need two-way communication. Although you can pass outer methods as aliases to the inner struct, but then you have to use crazy tricks to make methods of the inner struct static in respect to the inner struct but bound to the outer one via the alias. I've played with this quite a bit for ae.utils.serialization, but I don't think it fits here. Unless I'm missing something? It's always nice to know examples of high performance range-based code. I noticed that the `View` concept does not have the concept of stride or access to pixels using a single absolute coordinate; maybe if that was the case, the `blitTo` algorithm could be optimized to its conclusion, instead of copying scanlines one by one. That's what my previous design used. But ultimately, unless you're dealing with very narrow images, I don't think there will be a noticeable difference in performance. This design is more flexible, though (e.g. vjoiner can serve scanlines from different sources). Thanks for the feedback.
Re: Article: Functional image processing in D
On Friday, 21 March 2014 at 17:03:17 UTC, Vladimir Panteleev wrote: Where this is done, it is on purpose. For example, the invert declaration as it appears in the article wouldn't be possible with the shorthand function template syntax. Right, I only skimmed over the various aliases. It looks like only `parallel` does not use such an alias in the article, but as a higher order algorithm it's perfectly justified to use the separated style, especially when all the other higher order algorithms do it. Yes. I've tried using unsigned coordinates in the past. It was awful. My conclusion is that if you ever need to subtract values, you should use signed types. What happens if negative values sneak into the code? Sounds dangerous. Yeah. A lambda would need to receive x, y, w and h, and we don't have naryFun in Phobos. (It's there but commented out for some reason.) To a small extent, I made some compromises for the first iteration for the sake of code looking good for the article, and maybe with the help of feedback improve on that. Bleh, I hope we can figure out some notion of lambda equality soon; string lambdas are terrible in so many ways. For example, a problem I've struggled with is avoiding having two overloads for almost every function in image.d. I've tried multiple approaches: default arguments (in the form of *new Image!COLOR), templates, string mixins, UDAs, pointers, but they all were rather ugly or impractical. Some related compiler issues are 8074, 12386, 12425 and 12426 - fixing those might make some of those approaches more feasible. Referring to the overload sets with the `target` parameter? (Looking at the source I also noticed some `isInputRange` checks are missing; `ElementType` only checks for a `front` property.) That doesn't work if you need two-way communication. Although you can pass outer methods as aliases to the inner struct, but then you have to use crazy tricks to make methods of the inner struct static in respect to the inner struct but bound to the outer one via the alias. I've played with this quite a bit for ae.utils.serialization, but I don't think it fits here. Unless I'm missing something? Aye, to be a sane hierarchy it would need to be redesigned so there are no circular dependencies, which does look rather non-trivial. That's what my previous design used. But ultimately, unless you're dealing with very narrow images, I don't think there will be a noticeable difference in performance. This design is more flexible, though (e.g. vjoiner can serve scanlines from different sources). Maybe parallelized blitting makes sense, though it would really require a use case where blit speed is a bottleneck to matter in the first place.
Re: Article: Functional image processing in D
On Friday, 21 March 2014 at 17:24:02 UTC, Jakob Ovrum wrote: What happens if negative values sneak into the code? Sounds dangerous. Well, working with unsigned values correctly complicates the code by a good deal, for one. For example, if you want to draw a circle at (x,y) with radius r, then the first column of the bounding box is max(x-r,0). If you use unsigned coordinates, you have to write x-min(r,x) instead, which is a lot less intuitive. Not to mention, that it makes sense to draw a circle with negative center coordinates (you'll only see the fragment with non-negative coordinates). There's also tricky bits like if you ever need to subtract a value from another, divide the result, then add something back. With a signed type you can get the expected positive number, even if the number being divided was negative. With an unsigned type, the subtraction can cause an underflow, with the (unsigned) division interpreting the result with a very large positive number instead of a small negative one. For example, a problem I've struggled with is avoiding having two overloads for almost every function in image.d. I've tried multiple approaches: default arguments (in the form of *new Image!COLOR), templates, string mixins, UDAs, pointers, but they all were rather ugly or impractical. Some related compiler issues are 8074, 12386, 12425 and 12426 - fixing those might make some of those approaches more feasible. Referring to the overload sets with the `target` parameter? Yes. (Looking at the source I also noticed some `isInputRange` checks are missing; `ElementType` only checks for a `front` property.) Thanks. That's what my previous design used. But ultimately, unless you're dealing with very narrow images, I don't think there will be a noticeable difference in performance. This design is more flexible, though (e.g. vjoiner can serve scanlines from different sources). Maybe parallelized blitting makes sense, though it would really require a use case where blit speed is a bottleneck to matter in the first place. I agree, I think in most cases it makes sense to parallelize on a higher level. Searching the web for parallel memcpy seems to confirm my suspicion that it's not practical, at least not for conventional CPUs.
Re: Article: Functional image processing in D
On Friday, 21 March 2014 at 18:40:10 UTC, ponce wrote: 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. One more remarks: Have you considered infinite View which, much like infinite InputRanges would lack lacking the w and h property? It would allow: - infinite procedural() - support different border-modes when sampling outside of the allowed rectangle (eg. mirror, repeat, clamp_to_edge like OpenGL does with textures). This could be done with a function taking a View and returning an infinite View from it. - probably other uses I don't think of Erm, so much typos. Corrected. --- One more remark: Have you considered an infinite View which, much like infinite InputRanges would lack the w and h properties? It would allow: - infinite procedural() View - support for different border-modes when sampling outside of the allowed rectangle (eg. mirror, repeat, clamp_to_edge like OpenGL does with textures). This could be done with a function taking a View and returning an infinite View from it. - probably other uses I don't think of. ---
Re: Article: Functional image processing in D
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. One more remarks: Have you considered infinite View which, much like infinite InputRanges would lack lacking the w and h property? It would allow: - infinite procedural() - support different border-modes when sampling outside of the allowed rectangle (eg. mirror, repeat, clamp_to_edge like OpenGL does with textures). This could be done with a function taking a View and returning an infinite View from it. - probably other uses I don't think of
Re: Article: Functional image processing in D
On 3/21/2014 4:04 AM, 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. Very, very nice.
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 00:39:43 UTC, bearophile wrote: It's the best chance to improve naming, so do not throw it away for nothing: https://d.puremagic.com/issues/show_bug.cgi?id=9106 I think the following patch should fix that for you: https://github.com/WebDrake/std.random2/commit/fb5429de77b3c1f7fe3968fd0bd92209c9021f31 I've also made shuffle composable as per your request. Looks good? :-)
Re: 1st draft of complete class-based std.random successor
Joseph Rushton Wakeling: I think the following patch should fix that for you: https://github.com/WebDrake/std.random2/commit/fb5429de77b3c1f7fe3968fd0bd92209c9021f31 I've also made shuffle composable as per your request. Looks good? :-) Seems good. Onward! :-) Bye, bearophile
Re: Article: Functional image processing in D
On Friday, 21 March 2014 at 13:54:25 UTC, Vladimir Panteleev
wrote:
On Friday, 21 March 2014 at 12:27:57 UTC, Rikki Cattermole
wrote:
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.
Are you planning on adding a font rasterizer
Parsing vector font files is a big undertaking. I'd likely use
a text rendering library, such as FreeType. Hardcoding a small
bitmap font for ASCII only is also a possibility.
Yeah it is quite a big one. But it may be well worth it to have
it generate code at CTFE per font. Would be more efficient
probably.
and can it work at CTFE?
This program almost works:
string drawSmiley()
{
import std.range;
import std.math;
import ae.utils.graphics.draw;
import ae.utils.graphics.image;
auto smiley = Image!char(20, 20);
smiley.fill(' ');
smiley.fillCircle(10, 10, 10, '#');
smiley.fillCircle( 6, 6, 2, ' ');
smiley.fillCircle(14, 6, 2, ' ');
smiley.fillSector(10, 10, 6, 8, 0, PI, ' ');
return smiley.h.iota.map!(y =
smiley.scanline(y)).join(\n).idup;
}
pragma(msg, drawSmiley);
almost because fillSector calls atan2, which doesn't work in
CTFE. :(
(And yeah, I totally did just declare an image with a
Yeah I've noticed that some of phobos wasn't really designed with
CTFE in mind *grumbles*. Maybe one day I'll look into getting
that sorted out.
colorspace of char.)
Re: Article: Functional image processing in D
On Friday, 21 March 2014 at 18:40:10 UTC, ponce wrote: 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. One more remarks: Have you considered infinite View which, much like infinite InputRanges would lack lacking the w and h property? It would allow: - infinite procedural() - support different border-modes when sampling outside of the allowed rectangle (eg. mirror, repeat, clamp_to_edge like OpenGL does with textures). This could be done with a function taking a View and returning an infinite View from it. - probably other uses I don't think of I've thought about it. Ultimately you'll want to crop it at some point or another, so I think it makes sense if there were operations you'd want to do on an infinite view where cropping will get in the way. The library has a tiling view, which is infinite in concept but currently in effect it immediately crops the infinite view it creates. I would probably have to rename the isView template to isFiniteView, and many operations expect a finite view...
Re: Most basic nothrow, pure, @safe functions?
On Friday, 21 March 2014 at 03:04:36 UTC, Steven Schveighoffer
wrote:
Thinking about it some more, I see what you mean -- an unshared
mutex is useless.
But at the same time, some logically pure functions cannot be
so without mutexes. E.g. memory allocation.
Since when does shared = impure ?
If the function takes a pointer to shared data, then you are
explicitly saying this function depends on this shared data.
But as long is it isn't referencing some *other* global directly,
it is perfectly pure.
For example:
//
int i = 5;
void foo(int* p) pure
{++p;}
void main() pure
{
foo(p);
}
//
This is textbook of a pure function changing global state.
So the way I see it: shared = pinter to mutex = touching it is
fair game = can be legit pure (IMO).
Re: Most basic nothrow, pure, @safe functions?
On 3/21/2014 12:03 AM, monarch_dodra wrote: On Friday, 21 March 2014 at 03:04:36 UTC, Steven Schveighoffer wrote: Thinking about it some more, I see what you mean -- an unshared mutex is useless. But at the same time, some logically pure functions cannot be so without mutexes. E.g. memory allocation. Since when does shared = impure ? If the function takes a pointer to shared data, then you are explicitly saying this function depends on this shared data. But as long is it isn't referencing some *other* global directly, it is perfectly pure. We've been using 'shared' here to mean shared with another piece of code that looks at the state, not 'shared' as in data shared amongst multiple threads.
Re: Most basic nothrow, pure, @safe functions?
On 3/20/2014 7:02 PM, deadalnix wrote: On Friday, 21 March 2014 at 02:00:11 UTC, Walter Bright wrote: Mutexes implicitly share state. It's the reason they exist. They can't be pure, because pure functions don't share state. If you got that road, you can't allow memory allocators to be used in pure code. That isn't a good argument. The analogy doesn't apply. Operator new is regarded as supplying memory from an infinite reservoir. There is no implicit global state. The whole point of a mutex is to change state and share it. It's utterly different.
New guideline to place import statements as locally as possible
Can someone tell me where this is written up? Thanks Steve
Re: Most basic nothrow, pure, @safe functions?
On Friday, 21 March 2014 at 07:14:47 UTC, Walter Bright wrote: On 3/21/2014 12:03 AM, monarch_dodra wrote: On Friday, 21 March 2014 at 03:04:36 UTC, Steven Schveighoffer wrote: Thinking about it some more, I see what you mean -- an unshared mutex is useless. But at the same time, some logically pure functions cannot be so without mutexes. E.g. memory allocation. Since when does shared = impure ? If the function takes a pointer to shared data, then you are explicitly saying this function depends on this shared data. But as long is it isn't referencing some *other* global directly, it is perfectly pure. We've been using 'shared' here to mean shared with another piece of code that looks at the state, not 'shared' as in data shared amongst multiple threads. Ok. That's a fair point. So in that case, our function is pointing at data, and is allowed to mutate it, and observe its state. Now, if *another* piece of code is doing the same thing at the same time (potentially mutating data, does that still violate purity? As long a the function doesn't access/mutate something via direct global state, it's pure, isn't it? I think... it's tough to wrap your head around the issue.
Re: New guideline to place import statements as locally as possible
On Friday, 21 March 2014 at 07:24:43 UTC, Steve Teale wrote: Can someone tell me where this is written up? Thanks Steve You mean generally, or in phobos? The rational in phobos is that since it is heavily templated, it makes sense to pull the imports on a as needed basis. If we placed all the imports needed *anywhere* in the module at the top, in *all* modules, then importing *anything* in std would import the world. for example, something as dumb as TypeTuple: = need std.typetuple = pulls traits = pulls typecons and algorithm = pulls array, string, uni, ascii, utf, conv = pulls everything remaining The new scheme allows massively reducing these dependencies. At least, that's the point. cross-module aliasing, and template constraints tend to make this as smooth as we'd like it. In end user code, or in non-template code, there is less rational for doing this. At that point, it only becomes a style, issue, of whether or not you want to pollute your namespace with imported symbols.
Re: Handling invalid UTF sequences
On Thursday, 20 March 2014 at 23:34:02 UTC, Brad Anderson wrote: I'm a fan of this approach but Timon pointed out when I wrote about it once that it's rather trivial to get an invalid string through slicing mid-code point so now I'm not so sure. It's just as easy to slice mid-codepoint as it is to access a range out of bounds. In both cases, it's a programming error. The only excuse I see for throwing an exception for slicing mid-codepoint, is that 1. programmers are less aware of the issue, so it's more forgiving in a released program (nobody likes a crash). 2. arguably, it's not the *program* state that's bad. It's the *data*. Well, in regards to 2, you could argue that program state and data state is one and the same. I think I'm still in favor of it because you've obviously got a logic error if that happens so your program isn't correct anyway (it's not a matter of bad user input). If I remember correctly, with a specially written UTF string, it *was* possible to corrupt program state. I think. I need to double check. I didn't give it much thought then (it should virtually never happen), but it could be used as deliberate security vulnerability.
Re: Handling invalid UTF sequences
On Thu, 20 Mar 2014 22:39:50 -, Walter Bright newshou...@digitalmars.com wrote: Currently we do it by throwing a UTFException. This has problems: 1. about anything that deals with UTF cannot be made nothrow 2. turns innocuous errors into major problems, such as DOS attack vectors http://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences One option to fix this is to treat invalid sequences as: 1. the .init value (0xFF for UTF8, 0x for UTF16 and UTF32) 2. U+FFFD I kinda like option 1. What do you think? In window/Win32.. WideCharToMultiByte has flags for a bunch of similar behaviours and allows you to define a default char to use as a replacement in such cases. swprintf when passed %S will convert a wchar_t UTF-16 argument into ascii, and replaces invalid characters with ? as it does so. swprintf_s (the safe version), IIRC, will invoke the invalid parameter handler for sequences which cannot be converted. I think, ideally, we want some sensible default behaviour but also the ability to alter it globally, and even better in specific calls where it makes sense to do so (where flags/arguments can be passed to that effect). So, the default behaviour could be to throw (therefore no breaking change) and we provide a function to change this to one of the other options, and another to select a replacement character (which would default to .init or U+FFFD). R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: New guideline to place import statements as locally as possible
On Friday, 21 March 2014 at 08:05:09 UTC, monarch_dodra wrote: On Friday, 21 March 2014 at 07:24:43 UTC, Steve Teale wrote: Can someone tell me where this is written up? Thanks Steve You mean generally, or in phobos? The rational in phobos is that since it is heavily templated, it makes sense to pull the imports on a as needed basis. If we placed all the imports needed *anywhere* in the module at the top, in *all* modules, then importing *anything* in std would import the world. for example, something as dumb as TypeTuple: = need std.typetuple = pulls traits = pulls typecons and algorithm = pulls array, string, uni, ascii, utf, conv = pulls everything remaining The new scheme allows massively reducing these dependencies. At least, that's the point. cross-module aliasing, and template constraints tend to make this as smooth as we'd like it. In end user code, or in non-template code, there is less rational for doing this. At that point, it only becomes a style, issue, of whether or not you want to pollute your namespace with imported symbols. OK, so what happens that's different when I pull in std.typetuple at the point where I need it? Does that avoid pulling in all the other stuff? How does this problem manifest itself - code bloat, or slower compilations, or what? Thanks Steve
Re: Handling invalid UTF sequences
21.03.2014 12:25, monarch_dodra пишет: On Thursday, 20 March 2014 at 23:34:02 UTC, Brad Anderson wrote: I'm a fan of this approach but Timon pointed out when I wrote about it once that it's rather trivial to get an invalid string through slicing mid-code point so now I'm not so sure. It's just as easy to slice mid-codepoint as it is to access a range out of bounds. In both cases, it's a programming error. The only excuse I see for throwing an exception for slicing mid-codepoint, is that 1. programmers are less aware of the issue, so it's more forgiving in a released program (nobody likes a crash). 2. arguably, it's not the *program* state that's bad. It's the *data*. Well, in regards to 2, you could argue that program state and data state is one and the same. I think I'm still in favor of it because you've obviously got a logic error if that happens so your program isn't correct anyway (it's not a matter of bad user input). If I remember correctly, with a specially written UTF string, it *was* possible to corrupt program state. I think. I need to double check. I didn't give it much thought then (it should virtually never happen), but it could be used as deliberate security vulnerability. Almost nothing to add here. We already have `-noboundscheck` which can dramatically increase performance, throwing `UTFError` should either use same mechanics (`-noutfcheck`?) or just be stripped in release. Personally I'd choose the latter as there are lots of (sometimes very slow) assertions stripped with `-release` in real programs, which indicates same critical data corruption. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: New guideline to place import statements as locally as possible
On Friday, 21 March 2014 at 10:03:20 UTC, Steve Teale wrote:
OK, so what happens that's different when I pull in
std.typetuple at the point where I need it? Does that avoid
pulling in all the other stuff?
The difference is whether or not the import gets executed at all.
For *you*, it doesn't make much difference where you do your
import, it only impacts the people that are *importing you*.
A trivial example is this:
//
module someModule;
void foo(T)(T t)
{
import someOtherModule1;
}
void bar(T)(T t)
{
import someOtherModule2;
}
//
Now imagine you need to use someModule.foo. You don't need
someOtherModule2, since that's only needed by baz. So this
approach means you don't import it. someOtherModule1.
//
If the functions are not template, or in end user code, it
doesn't change much where you do the imports, since they'll
happen anyways. The only difference is which symbols are visible
where.
How does this problem manifest itself - code bloat, or slower
compilations, or what?
I can't answer that personally. I just know there was a pretty
big push from the dmd guys to cleanup the phobos code. I don't
know what the actual impacts are.
Re: Ruby-style each in D?
On Friday, 21 March 2014 at 00:42:00 UTC, Walter Bright wrote:
On 3/20/2014 5:33 PM, bearophile wrote:
As I explained in a precedent post in this thread it's hard to
design something
if you don't try to use it, even something simple as a each().
Right on.
So I toyed around a little. I played with mostly tee/tap and
each. The first observation is that both can help make a 2D
ufcs chain, which is pretty nice. It makes more sense (IMO) to
code it that way, than to use awkward join, to concatenate the
2D range into a continuous 1D range, eg: join(lines, \n);
First: tee.
I wanted to try to experience the multiple tees approach. I
made the code purposefully verbose, so as to better test it.
Because I wanted to process each item once, and only once, I used
the default policy of `Yes.pipeOnPop`. I did some tests with both
tee!pred and tee(range, output), but they were functionally
equivalent. Anyways, here was my first iteration:
//
size_t N = 5;
chain(iota(0, N), only(N), iota(0, N).retro) //0 .. N .. 0
.tee!((a)=' '.repeat(N - a).write())() //leading spaces
.tee!((a)='*'.repeat(a).write())() //first half of
stars
.tee!((a)='*'.write())()//middle star
.tee!((a)='*'.repeat(a).write())() //second half
.tee!((a)=writeln())() //linefeed
.reduce!0(0); //or consume/walk
//
Surprise! It's wrong!
each tee triggers on the call to `popFront`. It does its job
(calls pred(r.front)), and then push the pop down the chain.
What this means is that my tee's are actually executed right to
left! Talk about counter intuitive.
So *this* is correct:
//
size_t N = 5;
chain(iota(0, N), only(N), iota(0, N).retro) //0 .. N .. 0
.tee!((a)=writeln())() //linefeed
.tee!((a)='*'.repeat(a).write())() //second half
.tee!((a)='*'.write())()//middle star
.tee!((a)='*'.repeat(a).write())() //first half of
stars
.tee!((a)=' '.repeat(N - a).write())() //leading spaces
.reduce!0(0); //or
consume/walk/each()
//
Odd!
Second:
Each tee pipes a call to front, and *then* calls front again when
popped. Effectively, if you have *N* tee's in your range, you'll
call fun roughly N*N/2 times. Not great.
This might be an unfair assesment of tee, because I over-used
it on purpose, but I think it *does* show that it's not scaling
well, and that it is triggering in a confusing order.
Also:
//
size_t N = 5;
foreach ( a ; chain(iota(0, N), only(N), iota(0, N).retro))
{
' '.repeat(N - a).write();
'*'.repeat(a).write();
'*'.write();
'*'.repeat(a).write();
writeln();
}
//
Just saying. Why would I use tee when I have that?
But I think I'm using tee wrong: The idea is to hook it into
a chain that actually does something. It shouldn't be the main
doer.
-
What about each?
I wrote this:
//
chain(iota(0, N), only(N), iota(0, N).retro)
.each!(
(a) = writeln(' '.repeat(N - a), '*'.repeat(a*2+1))
)();
//
I think this is a fair assesment of how each would be used? It
looks nice, and is relatively short. But then I wrote this:
//
foreach ( a ;
chain(iota(0, N), only(N), iota(0, N).retro) )
{
writeln(' '.repeat(N - a), '*'.repeat(a*2+1)))
}
//
Hum... you still get the same functional initial declaration, but
the foreach doesn't get in the way, while still keeping a clear
functional/imperative distinction.
--
Si that's my initial assessment.
I'm not really sold on each. I think it'll be abused by those
that want a 1-liner at all cost, leading to an image that D is
nothing but horrible 1 liners!, all that without providing any
real functionality.
As for tee: I'm convinced I didn't use it for its intended
function, but I think it shows its function can easily be
hijacked to do things it wasn't meant for.
Re: Cannot cast X to Y at compile time...?
On 03/21/2014 06:12 AM, Kapps wrote:
On Thursday, 20 March 2014 at 21:32:08 UTC, dnspies wrote:
Sorry, I don't understand. When I cast something to the wrong
type, I should just get a null reference, shouldn't I? It
shouldn't throw an error.
If the compiler can statically determine that the cast is invalid you
get an error instead.
No.
class C{}
class D{}
void main(){
C c=new C;
D d=cast(D)c; // no error
assert(c !is null);
assert(d is null);
}
(In any case, his problem is that the cast fails in CTFE.)
You can use something like 'static if(is(T :
Foo))' to test at compile-time if T is implicitly convertible to Foo
(I'm not certain the exact semantics) or 'static
if(is(typeof(cast(Foo)T.init)))'.
There's probably better ways to do it, and I recommend asking on D.learn
to figure out how to do what you're looking for.
I guess it might be a compiler bug, but it is hard to tell lacking a
complete example.
Re: Ruby-style each in D?
monarch_dodra:
chain(iota(0, N), only(N), iota(0, N).retro)
.each!(
(a) = writeln(' '.repeat(N - a), '*'.repeat(a*2+1))
)();
//
Something like this seems better (untested):
chain(N.iota, N.only, N.iota.retro)
.each!(a = '*'.replicate(a * 2 + 1).center(N).writeln);
I think this is a fair assesment of how each would be used?
This UFCS chain is just 2 lines long, it's not the best usage
example of each().
I'm not really sold on each.
...
As for tee: I'm convinced I didn't use it for its intended
function, but I think it shows its function can easily be
hijacked to do things it wasn't meant for.
You have used tee for something you think it's not very well
designed, and you have given only one usage example of each(),
and it's not the most common example.
So before taking any decision on the matter, more experiments and
usage examples are necessary, where you have longer chains. If
you have a longer chain:
items
.sort()
.group
.map!(g = g[1] / double(s.length))
.map!(p = -p * p.log2)
.sum
.each(...);
using a each() allows you to keep a nice column. If you use
foreach your formatting and your logic has a hiccup, because you
are mixing two different styles:
foreach (item; items
.sort()
.group
.map!(g = g[1] / double(s.length))
.map!(p = -p * p.log2)
.sum) {
// Do something imperative here.
}
But this is not a real example (it computes the entropy of items,
and you usually don't need an each there), so more usage examples
are needed. Taking a look at real world usages of foreach() in
Scala could be useful.
I think it'll be abused by those that want a 1-liner at all
cost, leading to an image that D is nothing but horrible 1
liners!, all that without providing any real functionality.
I think each() is meant for longer chains as you see in F#
languages.
Some possible usage examples for each():
import std.stdio, std.algorithm, std.string, std.exception,
std.file;
void main() {
string[][ubyte[]] an;
foreach (w; unixdict.txt.readText.splitLines)
an[w.dup.representation.sort().release.assumeUnique] ~= w;
immutable m = an.byValue.map!q{ a.length }.reduce!max;
writefln(%(%s\n%), an.byValue.filter!(ws = ws.length ==
m));
}
auto mode(T)(T[] items) pure nothrow {
int[T] aa;
foreach (item; items)
aa[item]++;
immutable m = aa.byValue.reduce!max;
return aa.byKey.filter!(k = aa[k] == m);
}
double equalBirthdays(in uint nSharers, in uint groupSize,
in uint nRepetitions, ref Xorshift rng) {
uint eq = 0;
foreach (immutable j; 0 .. nRepetitions) {
uint[365] group;
foreach (immutable i; 0 .. groupSize)
group[uniform(0, $, rng)]++;
eq += group[].any!(c = c = nSharers);
}
return (eq * 100.0) / nRepetitions;
}
Bye,
bearophile
Re: Ruby-style each in D?
On Friday, 21 March 2014 at 00:42:00 UTC, Walter Bright wrote: Right on. I'm using Ruby every day. I don't really see much point in having each in D. We already have foreach. Ruby uses each since it doesn't have foreach. It to have a for, which is a form of foreach, but that is just lowered to each anyway. Also, I don't see a point in having each which is lazy. -- /Jacob Carlborg
Re: Ruby-style each in D?
On Friday, 21 March 2014 at 11:03:01 UTC, monarch_dodra wrote:
each tee triggers on the call to `popFront`. It does its job
(calls pred(r.front)), and then push the pop down the chain.
What this means is that my tee's are actually executed right
to left! Talk about counter intuitive.
What's the purpose of tee, is it the same as tap? tap in
Ruby just returns the receiver after executing a block. This
would be the implementation in D:
T tap (alias block, T) (T t)
{
block(t);
return t;
}
--
/Jacob Carlborg
Re: Ruby-style each in D?
On Friday, 21 March 2014 at 12:55:09 UTC, Jacob Carlborg wrote: What's the purpose of tee, is it the same as tap? tap in Ruby just returns the receiver after executing a block. This would be the implementation in D: Yeah tee is a horrible name, no chance I would have guess what it means just by the name. tap is much better.
Re: Ruby-style each in D?
Vladimir Panteleev: Dicebot: Yeah tee is a horrible name, no chance I would have guess what it means just by the name. tap is much better. I think it's meant to mimic the UNIX command with the same name? If you know about the command, the function's purpose seems obvious. See also the Python function tee(): http://docs.python.org/2/library/itertools.html#itertools.tee Bye, bearophile
Re: Ruby-style each in D?
On Friday, 21 March 2014 at 13:24:50 UTC, Dicebot wrote: On Friday, 21 March 2014 at 12:55:09 UTC, Jacob Carlborg wrote: What's the purpose of tee, is it the same as tap? tap in Ruby just returns the receiver after executing a block. This would be the implementation in D: Yeah tee is a horrible name, no chance I would have guess what it means just by the name. tap is much better. I think it's meant to mimic the UNIX command with the same name? If you know about the command, the function's purpose seems obvious.
Re: Ruby-style each in D?
On Friday, 21 March 2014 at 13:27:04 UTC, Vladimir Panteleev wrote: On Friday, 21 March 2014 at 13:24:50 UTC, Dicebot wrote: On Friday, 21 March 2014 at 12:55:09 UTC, Jacob Carlborg wrote: What's the purpose of tee, is it the same as tap? tap in Ruby just returns the receiver after executing a block. This would be the implementation in D: Yeah tee is a horrible name, no chance I would have guess what it means just by the name. tap is much better. I think it's meant to mimic the UNIX command with the same name? If you know about the command, the function's purpose seems obvious. ...and has pretty much nothing in common with it! Also I don't see requires UNIX familiarity to be used intuitively warning in Phobos docs. Actually for similar reasons tap is also inferior to each.
Re: Ruby-style each in D?
On 3/21/14, 4:02 AM, monarch_dodra wrote: So I toyed around a little. I played with mostly tee/tap and each. The first observation is that both can help make a 2D ufcs chain, which is pretty nice. It makes more sense (IMO) to code it that way, than to use awkward join, to concatenate the 2D range into a continuous 1D range, eg: join(lines, \n); First: tee. Nice work! This convinced me that tee should call the lambda only upon the first call to .front on each iteration. Andrei
Re: Most basic nothrow, pure, @safe functions?
On Friday, 21 March 2014 at 02:00:11 UTC, Walter Bright wrote:
On 3/20/2014 6:40 PM, Steven Schveighoffer wrote:
How do they affect global state?
Mutexes implicitly share state. It's the reason they exist.
They can't be pure, because pure functions don't share state.
Locking a monitor is also a mutating operation and yet I believe
you can have const synchronized methods. They live somewhat
outside the normal type system. I don't see any point in having
pure class methods, but what about:
pure int add(T)(const(T) a, const(T) b) {
return a + b;
}
Where the variables above are instances of a synchronized class?
The operation would implicitly lock their monitors to perform the
addition.
Re: Ruby-style each in D?
On Friday, 21 March 2014 at 12:29:31 UTC, bearophile wrote:
So before taking any decision on the matter, more experiments
and usage examples are necessary, where you have longer chains.
If you have a longer chain:
items
.sort()
.group
.map!(g = g[1] / double(s.length))
.map!(p = -p * p.log2)
.sum
.each(...);
using a each() allows you to keep a nice column. If you use
foreach your formatting and your logic has a hiccup, because
you are mixing two different styles:
foreach (item; items
.sort()
.group
.map!(g = g[1] / double(s.length))
.map!(p = -p * p.log2)
.sum) {
// Do something imperative here.
}
But this is not a real example (it computes the entropy of
items, and you usually don't need an each there), so more usage
examples are needed. Taking a look at real world usages of
foreach() in Scala could be useful.
The former example doesn't become functional just because you
managed to use UFCS, it's just imperative code deceptively
disguised as functional code. The clear separation in the latter
example is a *good thing*.
Re: DDT in Eclipse
On Thursday, 20 March 2014 at 12:14:09 UTC, Russel Winder wrote: I am finding that I have to remove DDT from Eclipse in order to get the latest CDT. Is this to be expected? Thanks. I had to do the same. It has something to do with the required version for the GDB plugin. I ended up just keeping two separate installations of eclipse (one for CDT and everything else, and one for DDT). This seems a little wasteful, but it's not that uncommon (NSight Eclipse for CUDA and Octclipse for Octave are two examples of other eclipse-mods that work in a standalone copy of Eclipse)
Re: Handling invalid UTF sequences
21-Mar-2014 02:39, Walter Bright пишет: Currently we do it by throwing a UTFException. This has problems: 1. about anything that deals with UTF cannot be made nothrow 2. turns innocuous errors into major problems, such as DOS attack vectors http://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences One option to fix this is to treat invalid sequences as: 1. the .init value (0xFF for UTF8, 0x for UTF16 and UTF32) If we talk decoding then only dchar is relevant. If transcoding then, having 0xFF makes for broken UTF-8 encoding so I see no sense in going for it. 2. U+FFFD Also has the benefit of being recommended by the standard specifically for the case of substitution for bad encoding. Details: https://d.puremagic.com/issues/show_bug.cgi?id=12113 I kinda like option 1. Not enough of an argument ;) -- Dmitry Olshansky
Re: Most basic nothrow, pure, @safe functions?
On 3/21/2014 12:59 AM, monarch_dodra wrote: Ok. That's a fair point. So in that case, our function is pointing at data, and is allowed to mutate it, and observe its state. Now, if *another* piece of code is doing the same thing at the same time (potentially mutating data, does that still violate purity? A mutex essentially reads and writes a global flag, which other functions can also read and write. That makes it NOT pure.
Re: Most basic nothrow, pure, @safe functions?
On Fri, 21 Mar 2014 14:18:05 -0400, Walter Bright newshou...@digitalmars.com wrote: On 3/21/2014 12:59 AM, monarch_dodra wrote: Ok. That's a fair point. So in that case, our function is pointing at data, and is allowed to mutate it, and observe its state. Now, if *another* piece of code is doing the same thing at the same time (potentially mutating data, does that still violate purity? A mutex essentially reads and writes a global flag, which other functions can also read and write. That makes it NOT pure. No, that's not the case. A mutex does not write a global flag, it writes a shared flag. And the flag is passed into it. I still think straight locking and unlocking of mutexes should be pure, because of the exclusive nature of the data protected by them. -Steve
Re: Most basic nothrow, pure, @safe functions?
On 3/21/2014 9:28 AM, Sean Kelly wrote:
On Friday, 21 March 2014 at 02:00:11 UTC, Walter Bright wrote:
On 3/20/2014 6:40 PM, Steven Schveighoffer wrote:
How do they affect global state?
Mutexes implicitly share state. It's the reason they exist. They can't be
pure, because pure functions don't share state.
Locking a monitor is also a mutating operation and yet I believe you can have
const synchronized methods. They live somewhat outside the normal type system.
I don't see any point in having pure class methods, but what about:
pure int add(T)(const(T) a, const(T) b) {
return a + b;
}
Where the variables above are instances of a synchronized class? The operation
would implicitly lock their monitors to perform the addition.
Yes, I think the pairing of lock/unlock of a mutex can be pure, but just a lock
or just an unlock cannot be.
Re: Ruby-style each in D?
On Friday, 21 March 2014 at 11:03:01 UTC, monarch_dodra wrote:
//
foreach ( a ;
chain(iota(0, N), only(N), iota(0, N).retro) )
{
writeln(' '.repeat(N - a), '*'.repeat(a*2+1)))
}
//
I don't think it's so complicated. It's just taking this.
someRange.mungeItHowever.each!useIt;
Instead of writing this.
foreach(someThing; someRange.mungeItHowever) someThing.useIt;
Maybe it's like the difference between writing foo(bar) and
bar.foo. It can just look a little nicer.
Improve D's syntax to make it more python like
Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks.
Re: Improve D's syntax to make it more python like
On 03/21/2014 07:47 PM, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. http://delight.sourceforge.net/
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. Why not just learn the correct syntax instead of perpetuating ignorance? Python syntax is not modern. COBOL just needs to go away...
Re: Improve D's syntax to make it more python like
Pedro Larroy: As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? You have to revive this project to port it to D2: http://delight.sourceforge.net/ Bye, bearophile
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? I don't think it would be really hard to do in the compiler, you could probably make it work by hacking up the lexer. But I'm totally against it, Python has hideous syntax.
Re: Handling invalid UTF sequences
On Thursday, March 20, 2014 15:39:50 Walter Bright wrote: Currently we do it by throwing a UTFException. This has problems: 1. about anything that deals with UTF cannot be made nothrow 2. turns innocuous errors into major problems, such as DOS attack vectors http://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences One option to fix this is to treat invalid sequences as: 1. the .init value (0xFF for UTF8, 0x for UTF16 and UTF32) 2. U+FFFD I kinda like option 1. What do you think? After a discussion on this a few weeks back (where I was in favor of the current behavior when the discussion started), I'm now completely in favor of making it so that std.utf.decode simply replaces invalid code points with U+FFFD per the standard. Most code won't care and will continue to work as before. The main difference is that invalid Unicode would then fall in the same category as when a program is given a string with characters that it's not supposed to be given. Any code that checks for that sort of thing will then treat invalid Unicode as it would have treated other invalid strings, and code that doesn't care will continue to not care except that now it will work with invalid Unicode instead of throwing. A prime example is something like find. What does it care if it's given invalid Unicode? It will simply look for what you tell it to look for, and if it's not there, it won't find it. U+FFFD will just be one more character that doesn't match what it's looking for. The few programs that really care about whether a string that they're given contains any invalid Unicode can simply validate the string ahead of time. The main problem there is that we need to replace std.utf.validate with something like std.utf.isValidUnicode, because validate makes the horrendous decision of throwing rather than returning a bool (which is what triggered the previous discussion on the topic IIRC). There may be some concern about this change silently changing behavior, but I think that the reality is that the vast majority of programs will continue to work just fine, and our string processing code will be that much cleaner and faster as a result. So, I'm very much inclined to take the path of making this change and putting a warning about it in the changelog rather than not making the change or trying to do this alongside what we currently have. - Jonathan M Davis
Re: Most basic nothrow, pure, @safe functions?
On 3/21/2014 11:23 AM, Steven Schveighoffer wrote:
On Fri, 21 Mar 2014 14:18:05 -0400, Walter Bright newshou...@digitalmars.com
wrote:
On 3/21/2014 12:59 AM, monarch_dodra wrote:
Ok. That's a fair point. So in that case, our function is pointing at data,
and is allowed to mutate it, and observe its state.
Now, if *another* piece of code is doing the same thing at the same time
(potentially mutating data, does that still violate purity?
A mutex essentially reads and writes a global flag, which other functions can
also read and write.
That makes it NOT pure.
No, that's not the case. A mutex does not write a global flag, it writes a
shared flag. And the flag is passed into it.
Here's a litmus test you can use for purity. Consider:
int foo() pure;
{
auto a = foo();
}
Now, since 'a' is never used, we can delete the assignment, and since foo is
pure, we can delete foo():
{
}
Is this program distinguishable from the former? If not, then foo() is not pure.
Re: Improve D's syntax to make it more python like
On Fri, 2014-03-21 at 18:55 +, Frustrated wrote: […] Why not just learn the correct syntax instead of perpetuating ignorance? Python syntax is not modern. COBOL just needs to go away... D syntax is of course less modern than that of Python: Python syntax is 1980s, D syntax is rooted in C syntax which is 1970s. It is an error to equate the quality of a programming language with the age of the base syntax: D and Python are both good programming languages, different agreed. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Improve D's syntax to make it more python like
On Fri, 2014-03-21 at 19:13 +, Adam D. Ruppe wrote: […] But I'm totally against it, Python has hideous syntax. I would leave D syntax as it is. Python syntax is not hideous, it is good; very Pythonic, unlike D. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Handling invalid UTF sequences
On 3/21/2014 10:14 AM, Dmitry Olshansky wrote: 21-Mar-2014 02:39, Walter Bright пишет: Currently we do it by throwing a UTFException. This has problems: 1. about anything that deals with UTF cannot be made nothrow 2. turns innocuous errors into major problems, such as DOS attack vectors http://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences One option to fix this is to treat invalid sequences as: 1. the .init value (0xFF for UTF8, 0x for UTF16 and UTF32) If we talk decoding then only dchar is relevant. If transcoding then, having 0xFF makes for broken UTF-8 encoding so I see no sense in going for it. 2. U+FFFD Also has the benefit of being recommended by the standard specifically for the case of substitution for bad encoding. Details: https://d.puremagic.com/issues/show_bug.cgi?id=12113 Ah, that's what I was looking for. The wikipedia article was a bit wishy-washy about the whole thing. I kinda like option 1. Not enough of an argument ;)
Re: [Proposal] Add module for C-strings support in Phobos
Going slightly beyond a new module code, it might, possibly, be useful to enable zero-terminated string creation on the core language level, with: auto mystr = helloz; The 'z' in the end is much the same as 'L' in a '5L' ...
Re: Ehem, ARM
On Saturday, 28 December 2013 at 22:21:46 UTC, Joakim wrote: I finished porting most of druntime to Android/x86 and have started trying to run the tests: I just got 31 out of 38 druntime modules' unit tests to pass. :) I figured out the segfault mentioned above was because TLS is done differently on Android- flags[] is a global when outside main and thread-local by default as a result, adding a shared attribute makes it work again- and I was getting a lot of segfaults on the unit tests for the same reason. After making all the simple globals in the unit tests, like cpuid in rt.arrayfloat/int/etc., into shared variables, only 8 modules' unittests segfault, one after passing. Bionic doesn't support __thread for TLS, but it does let you use the pthread_key_(create|delete)/pthread_(set|get)specific APIs, just as druntime does on OS X. Here's the bionic implementation: https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_key.cpp I haven't completely grasped TLS and how it's done on OS X yet, but I get the sense I'll have to modify dmd a little to get TLS working with bionic. It appears that Martin and Johannes have looked into this before, so if you two have any feedback, let me know. I'm hoping TLS is the last remaining piece for druntime to be finished porting to Android/x86, then I want to try Phobos, which I'm guessing shouldn't be as bad. Been awhile since I updated on the Android effort: I'm now able to get all 38 druntime modules' unit tests to pass on Android/x86... under somewhat random conditions. It's finicky and some of the tests start failing and many segfaulting on exit, as mentioned before, if I make minor changes to the unit tests, like changing some TLS globals to shared. I'm guessing this is because I don't really have TLS working yet, I'm just taking advantage of the fact that the baked-in TLS in linux kinda sorta still works on Android. As long as it's local-exec, uninitialized TLS mostly works if it's less than 4-5 KB, while initialized TLS doesn't get initialized correctly. Of course, it's possible that I'm hitting some other codegen incompatibility altogether, unrelated to TLS, but the fact that it sometimes works depending on the number of TLS variables makes me think it's a TLS issue. I also got a bit more than half of the Phobos unit tests to pass, with a lot of seg faults there too. Android is going to need a packed TLS approach, similar to what Walter implemented for OS X with dmd: http://www.drdobbs.com/architecture-and-design/implementing-thread-local-storage-on-os/228701185 I've been looking into doing something similar for ELF, but this is the first time hacking on a compiler for me. If someone else more familiar with dmd or ldc could put packed TLS for ELF together more quickly, that would certainly speed things up. If not, I'll have something together eventually. ;)
Re: Most basic nothrow, pure, @safe functions?
On Friday, 21 March 2014 at 19:19:06 UTC, Walter Bright wrote:
Here's a litmus test you can use for purity. Consider:
int foo() pure;
{
auto a = foo();
}
Now, since 'a' is never used, we can delete the assignment, and
since foo is pure, we can delete foo():
{
}
Is this program distinguishable from the former? If not, then
foo() is not pure.
Consider this:
int foo(int* pa) pure
{
if (pa)
{
*pa = foo();
}
}
This is also pure according to D's type system, but it fails your
litmus test. This, however, passes:
int foo(immutable(int)* pa) pure
{
pa = pfoo();
}
I think the case of a monitor is closer to the first example.
Re: [Proposal] Add module for C-strings support in Phobos
On Friday, 21 March 2014 at 19:59:51 UTC, angel wrote:
Going slightly beyond a new module code, it might, possibly, be
useful to enable zero-terminated string creation on the core
language level, with:
auto mystr = helloz;
The core language already knows zero-terminated strings:
void main() {
immutable(char)* s = lol;
}
Regular 8-bit strings implicitly convert to pointers without
needing to explicitly call the .ptr property and they are always
zero terminated automatically.
This is why you can write printf(foo); in D and have it just
work without complaining about needing toStringz.
You can also write:
const char* s = lol;
and that works too. Not quite auto, but not a big hassle.
Re: [Proposal] Add module for C-strings support in Phobos
You could also write: alias toStringz z; auto foo = bar.z; and that would work too!
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:51:46 UTC, bearophile wrote: Pedro Larroy: As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? You have to revive this project to port it to D2: http://delight.sourceforge.net/ Bye, bearophile It's already in progress: https://github.com/pplantinga/delight http://pplantinga.github.io/
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. I don't think it's so difficult but it will increase a lot of code. Also, I don't believe the community will like something this. I'm not sure how accepted is python to most of this C/C++ guys. I personally don't like python/ruby/perl syntax.
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. What draws you to D, if not the syntax? If you're looking for a fast, Python-like language, and you don't mind dependence on the CPython runtime, I'd suggest looking into Cython (http://cython.org/). If you're interested in modern language features and expressive metaprogramming with a Python-like syntax, I'd recommend Julia (http://julialang.org/). You might also be interested in Dylan (https://opendylan.org/), though I don't know much about it.
Re: Improve D's syntax to make it more python like
Am 21.03.2014 21:43, schrieb Mason McGill: On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. What draws you to D, if not the syntax? If you're looking for a fast, Python-like language, and you don't mind dependence on the CPython runtime, I'd suggest looking into Cython (http://cython.org/). If you're interested in modern language features and expressive metaprogramming with a Python-like syntax, I'd recommend Julia (http://julialang.org/). You might also be interested in Dylan (https://opendylan.org/), though I don't know much about it. Dylan could have been a great language. A lisp for systems programming with algol syntax. Developed at Apple, originally targeted at the Newton. Since it was newly released as open source it has got some followers, but I am not sure if it will ever manage to get out of could have been great status. -- Paulo
Re: Improve D's syntax to make it more python like
The Guest: It's already in progress: https://github.com/pplantinga/delight http://pplantinga.github.io/ Some design decision are bad, like less for , or the function definition syntax function add(int a, b - int):. Bye, bearophile
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 20:43:24 UTC, Mason McGill wrote: On Friday, 21 March 2014 at 18:47:49 UTC, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks. What draws you to D, if not the syntax? Definitely not the syntax! The promise of a relatively high level statically typed language with low level control and C/C++ levels of performance. That's what I'm looking for with D. I choke down the syntax, telling myself at least it's better than C++. If you're looking for a fast, Python-like language, and you don't mind dependence on the CPython runtime, I'd suggest looking into Cython (http://cython.org/). If you're interested in modern language features and expressive metaprogramming with a Python-like syntax, I'd recommend Julia (http://julialang.org/). You're wrong about Julia. The syntax is most reminiscent of MATLAB and Octave. Others are wrong comparing Ruby/Perl/whatever to Python, at least the syntax. I find Python syntax very readable, it's the type system and semantics of Python that I dislike. Closest language to D with a Pythonesque syntax is Nimrod, nimrod-lang.org It's author, Araq, sometimes reads this forum. I believe that Haskell is the most popular statically typed language with indentation sensitive syntax. But Haskell is a lazy functional language where programming with side effects is more difficult. That's not like D. I doubt there's much interest in a new syntax for D. You may as well find or create a different language if it bothers you. I empathize, but I'm certain you'd be better off just getting used to the existing D syntax.
Walter's DConf 2014 Talks - Topics in Finance
Walter, I see that you will be discussing High Performance Code Using D at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. Just a thought. Best, TJB
Re: Improve D's syntax to make it more python like
Whether or not white space is significant is a _very_ subjective matter. It's not a given that it's a universal improvement. D is a C language family member and that's not going to change, including it's treatment of whitespace and use of braces. On 3/21/14, 11:47 AM, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Thanks.
Re: Improve D's syntax to make it more python like
A Python syntax wrapper around D is a fun thing. It's also suggested as a fun project to work in the D Programming Language book by Andrei. [1] If you're coming to D from Python though, I suppose my suggestion would to try and get used to the C-like syntax. If C-like syntax is unusual for you, you'll get used to it eventually. It is nice sometimes in D to be able to use braces to declare an arbitrary scope and so on, and the braces tie in pretty well with closure syntax. You'll get used to it. [1] http://books.google.co.uk/books?id=bn7GNq6fiIUCpg=PT47dq=d+programming+language+pythonhl=ensa=Xei=Eq4sU-rREOOt7QaTzoCQBgredir_esc=y#v=onepageq=d%20programming%20language%20pythonf=false
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote: Walter, I see that you will be discussing High Performance Code Using D at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. Heh, right before I read this, I stumbled across this snippet from Miguel De Icaza's blog from a couple months back, where he regretted using C++ to build Moonlight, their Silverlight implementation: But this would not be a Saturday blog post without pointing out that Cairo's C-based API is easier and simpler to use than many of those C++ libraries out there. The more sophisticated the use of the C++ language to get some performance benefit, the more unpleasant the API is to use. The incredibly powerful Antigrain sports an insanely fast software renderer and also a quite hostile template-based API. We got to compare Antigrain and Cairo back when we worked on Moonlight. Cairo was the clear winner. We built Moonlight in C++ for all the wrong reasons (better performance, memory usage) and was a decision we came to regret. Not only were the reasons wrong, it is not clear we got any performance benefit and it is clear that we did worse with memory usage. But that is a story for another time. http://tirania.org/blog/archive/2014/Jan-04.html
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 21:30:29 UTC, Joakim wrote: Heh, right before I read this, I stumbled across this snippet from Miguel De Icaza's blog from a couple months back, where he regretted using C++ to build Moonlight, their Silverlight implementation: But this would not be a Saturday blog post without pointing out that Cairo's C-based API is easier and simpler to use than many of those C++ libraries out there. The more sophisticated the use of the C++ language to get some performance benefit, the more unpleasant the API is to use. The incredibly powerful Antigrain sports an insanely fast software renderer and also a quite hostile template-based API. We got to compare Antigrain and Cairo back when we worked on Moonlight. Cairo was the clear winner. We built Moonlight in C++ for all the wrong reasons (better performance, memory usage) and was a decision we came to regret. Not only were the reasons wrong, it is not clear we got any performance benefit and it is clear that we did worse with memory usage. But that is a story for another time. http://tirania.org/blog/archive/2014/Jan-04.html That is a really strange argument. Let's break it down into stages. 1. Use C++ for better performance. 2. Find C++ library with better performance, but it's ugly. 3. Use C library in C++ instead because it's less ugly. 4. Conclude that C++ can't deliver better performance. That is really weak. This is why the industry needs salvation from C++ with D. It would mostly be then, Oh it has better performance with these template things... and it's not a pain in the ass to use.
Re: Walter's DConf 2014 Talks - Topics in Finance
Am 21.03.2014 22:39, schrieb w0rp: On Friday, 21 March 2014 at 21:30:29 UTC, Joakim wrote: Heh, right before I read this, I stumbled across this snippet from Miguel De Icaza's blog from a couple months back, where he regretted using C++ to build Moonlight, their Silverlight implementation: But this would not be a Saturday blog post without pointing out that Cairo's C-based API is easier and simpler to use than many of those C++ libraries out there. The more sophisticated the use of the C++ language to get some performance benefit, the more unpleasant the API is to use. The incredibly powerful Antigrain sports an insanely fast software renderer and also a quite hostile template-based API. We got to compare Antigrain and Cairo back when we worked on Moonlight. Cairo was the clear winner. We built Moonlight in C++ for all the wrong reasons (better performance, memory usage) and was a decision we came to regret. Not only were the reasons wrong, it is not clear we got any performance benefit and it is clear that we did worse with memory usage. But that is a story for another time. http://tirania.org/blog/archive/2014/Jan-04.html That is a really strange argument. Let's break it down into stages. 1. Use C++ for better performance. 2. Find C++ library with better performance, but it's ugly. 3. Use C library in C++ instead because it's less ugly. 4. Conclude that C++ can't deliver better performance. That is really weak. This is why the industry needs salvation from C++ with D. It would mostly be then, Oh it has better performance with these template things... and it's not a pain in the ass to use. I would take Miguel's comments about C++ with a grain of salt. Back when I participated in Gtkmm (early 200x), there were the occasional C++ bashes coming from the Gtk+ guys and Miguel was never found of C++. -- Paulo
Re: Improve D's syntax to make it more python like
On Friday, March 21, 2014 18:47:47 Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? *shudder* Python is more like the antithesis of good syntax IMHO. Sure, you could have a language with D's capabilities where the syntax had been adjusted to be more python-like, but I don't know what the benefit would be. Regardless, it's not like we're going to change D's syntax at this point. That would be king of breaking changes which wasn't worth what it cost. I expect that the closest you would get would be some project which essentially created its own language and simply converted it to D when compiling. - Jonathan M Davis
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 21:39:54 UTC, w0rp wrote: On Friday, 21 March 2014 at 21:30:29 UTC, Joakim wrote: Heh, right before I read this, I stumbled across this snippet from Miguel De Icaza's blog from a couple months back, where he regretted using C++ to build Moonlight, their Silverlight implementation: But this would not be a Saturday blog post without pointing out that Cairo's C-based API is easier and simpler to use than many of those C++ libraries out there. The more sophisticated the use of the C++ language to get some performance benefit, the more unpleasant the API is to use. The incredibly powerful Antigrain sports an insanely fast software renderer and also a quite hostile template-based API. We got to compare Antigrain and Cairo back when we worked on Moonlight. Cairo was the clear winner. We built Moonlight in C++ for all the wrong reasons (better performance, memory usage) and was a decision we came to regret. Not only were the reasons wrong, it is not clear we got any performance benefit and it is clear that we did worse with memory usage. But that is a story for another time. http://tirania.org/blog/archive/2014/Jan-04.html That is a really strange argument. Let's break it down into stages. 1. Use C++ for better performance. 2. Find C++ library with better performance, but it's ugly. 3. Use C library in C++ instead because it's less ugly. 4. Conclude that C++ can't deliver better performance. That is really weak. This is why the industry needs salvation from C++ with D. It would mostly be then, Oh it has better performance with these template things... and it's not a pain in the ass to use. The removal of pain points is indeed, in my mind, the main issue. :-)
Re: Improve D's syntax to make it more python like
On Fri, Mar 21, 2014 at 05:47:03PM -0400, Jonathan M Davis wrote: On Friday, March 21, 2014 18:47:47 Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? *shudder* Python is more like the antithesis of good syntax IMHO. Sure, you could have a language with D's capabilities where the syntax had been adjusted to be more python-like, but I don't know what the benefit would be. Regardless, it's not like we're going to change D's syntax at this point. That would be king of breaking changes which wasn't worth what it cost. I expect that the closest you would get would be some project which essentially created its own language and simply converted it to D when compiling. [...] I'm disappointed about how many discussions revolve around superficial things such as syntax, while neglecting weightier matters such as semantics and expressiveness. T -- What doesn't kill me makes me stranger.
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 20:52:54 UTC, bearophile wrote: The Guest: It's already in progress: https://github.com/pplantinga/delight http://pplantinga.github.io/ Some design decision are bad, like less for , or the function definition syntax function add(int a, b - int):. Bye, bearophile I agree with you. They should stick to PEP-3107 style def add(a, b: int) - int:.
Re: Walter's DConf 2014 Talks - Topics in Finance
On 3/21/2014 2:14 PM, TJB wrote: I see that you will be discussing High Performance Code Using D at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. It's a good thought, but I have zero knowledge of how C++ is used for high frequency trading.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 22:28:36 UTC, Walter Bright wrote: On 3/21/2014 2:14 PM, TJB wrote: I see that you will be discussing High Performance Code Using D at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. It's a good thought, but I have zero knowledge of how C++ is used for high frequency trading. I would be happy to help you with an option pricing example that is commonly used. Let me know if you are interested.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 22:28:36 UTC, Walter Bright wrote: It's a good thought, but I have zero knowledge of how C++ is used for high frequency trading. Reading through the Wikipedia article on Computational Finance, it looks like it's basically performing simulations where some data is known but other is not. Random numbers are generated for the unknown data and the simulations are run several times to find the range of possible outcomes given the known values.
Re: Improve D's syntax to make it more python like
I don't know if significant whitespace is actually improving the syntax. As a simple, self-contained example, consider the representation of program structure. Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks. Source: http://talks.golang.org/2012/splash.article -- Ziad
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 19:23:34 UTC, Russel Winder wrote: On Fri, 2014-03-21 at 18:55 +, Frustrated wrote: […] Why not just learn the correct syntax instead of perpetuating ignorance? Python syntax is not modern. COBOL just needs to go away... D syntax is of course less modern than that of Python: Python syntax is 1980s, D syntax is rooted in C syntax which is 1970s. It is an error to equate the quality of a programming language with the age of the base syntax: D and Python are both good programming languages, different agreed. Um, ALGOL was created in the early 60's of which python's spacing scheme is based on. Just because python came out after C does not change that. Do you think it might have been possible that Ritchie learned the lessons of ALGOL of which Rossum spat in his face? Some people just never learn from history... Python mandates a convention that programmers in ALGOL-style languages often follow. http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Indentation
Re: Improve D's syntax to make it more python like
On Friday, March 21, 2014 14:51:13 H. S. Teoh wrote: I'm disappointed about how many discussions revolve around superficial things such as syntax, while neglecting weightier matters such as semantics and expressiveness. I suspect that a lot of it just comes down to bikeshedding. Syntax is something that pretty much everyone can discuss, whereas semantics get a lot more complicated and require a much greater understanding. - Jonathan M Davis
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote: Walter, I see that you will be discussing High Performance Code Using D at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. Just a thought. Best, TJB Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately. Thanks Dan
Re: Improve D's syntax to make it more python like
On Friday, 21 March 2014 at 21:52:47 UTC, H. S. Teoh wrote: I'm disappointed about how many discussions revolve around superficial things such as syntax, while neglecting weightier matters such as semantics and expressiveness. T http://www.haskell.org/haskellwiki/Wadler%27s_Law People love to debate syntax. Semantics are much more interesting and worth talking about.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Saturday, 22 March 2014 at 00:14:11 UTC, Daniel Davidson wrote: On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote: Walter, I see that you will be discussing High Performance Code Using D at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. Just a thought. Best, TJB Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately. Thanks Dan Dan, Why a tough sell? Please explain. TJB
Re: Walter's DConf 2014 Talks - Topics in Finance
TJB: Why a tough sell? Please explain. That code must always be hard-real time. So a GC is allowed only during startup time (unless it's a quite special GC), hidden heap allocations are forbidden, data access patterns need to be carefully chosen, you even have to use most of the hot part of the stack, etc. Bye, bearophile
Re: Improve D's syntax to make it more python like
On 03/22/2014 12:47 AM, Frustrated wrote: D syntax is of course less modern than that of Python: Python syntax is 1980s, D syntax is rooted in C syntax which is 1970s. It is an error to equate the quality of a programming language with the age of the base syntax: D and Python are both good programming languages, different agreed. Um, ALGOL was created in the early 60's of which python's spacing scheme is based on. =D. http://en.wikipedia.org/wiki/ALGOL#Examples_and_portability_issues Just because python came out after C does not change that. Do you think it might have been possible that Ritchie learned the lessons of ALGOL of which Rossum spat in his face? No way. Some people just never learn from history... Python mandates a convention that programmers in ALGOL-style languages often follow. http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Indentation Yup. ALGOL-style languages such as D.
Re: Walter's DConf 2014 Talks - Topics in Finance
On 3/21/2014 5:39 PM, bearophile wrote: That code must always be hard-real time. So a GC is allowed only during startup time (unless it's a quite special GC), hidden heap allocations are forbidden, data access patterns need to be carefully chosen, you even have to use most of the hot part of the stack, etc. These are all very doable in D, and I've written apps that do so. The fear of GC is completely overblown. However, I do recognize that Phobos can be made a lot more non-GC friendly, and I am working on PR's to do that. For example, https://github.com/D-Programming-Language/phobos/pull/2014
Re: Improve D's syntax to make it more python like
On 3/21/14, 11:47 AM, Pedro Larroy wrote: Hi As a newcomer to D, I wonder, how difficult would be and would it be welcome by the D community to have D's syntax with significant whitespace and without brackets more like python? Hey Pedro, I think some (including possibly myself) could enjoy a D dialect with Python indentation quite a bit. Given D's compilation speed, that can be achieved as a dialect without much aggravation by using a preprocessor. In fact I considered writing such a preprocessor as a running example through the chapters of TDPL, but didn't get around to it. Andrei
Re: Improve D's syntax to make it more python like
On 3/21/14, 5:18 PM, w0rp wrote: On Friday, 21 March 2014 at 21:52:47 UTC, H. S. Teoh wrote: I'm disappointed about how many discussions revolve around superficial things such as syntax, while neglecting weightier matters such as semantics and expressiveness. T http://www.haskell.org/haskellwiki/Wadler%27s_Law People love to debate syntax. Semantics are much more interesting and worth talking about. Well, one issue that's happening is that every so often github pull requests that are simple but important (such as documentation) sit there without getting due review. The regular contributors are spending time looking into them, with takes away time from more important issues they could work on. A dozen people are doing the simple work and the complicated work, while the rest of the forum sits on the sidelines wringing hands about what to do about the future of D. Andrei
Re: Improve D's syntax to make it more python like
On Fri, Mar 21, 2014 at 06:47:28PM -0700, Andrei Alexandrescu wrote: On 3/21/14, 5:18 PM, w0rp wrote: On Friday, 21 March 2014 at 21:52:47 UTC, H. S. Teoh wrote: I'm disappointed about how many discussions revolve around superficial things such as syntax, while neglecting weightier matters such as semantics and expressiveness. T http://www.haskell.org/haskellwiki/Wadler%27s_Law People love to debate syntax. Semantics are much more interesting and worth talking about. Well, one issue that's happening is that every so often github pull requests that are simple but important (such as documentation) sit there without getting due review. The regular contributors are spending time looking into them, with takes away time from more important issues they could work on. A dozen people are doing the simple work and the complicated work, while the rest of the forum sits on the sidelines wringing hands about what to do about the future of D. [...] Perhaps we should be talking about how more people can make github contributions instead. ;-) T -- Why are you blatanly misspelling blatant? -- Branden Robinson
Re: Walter's DConf 2014 Talks - Topics in Finance
On Saturday, 22 March 2014 at 00:34:22 UTC, TJB wrote: On Saturday, 22 March 2014 at 00:14:11 UTC, Daniel Davidson wrote: On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote: Walter, I see that you will be discussing High Performance Code Using D at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. Just a thought. Best, TJB Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately. Thanks Dan Dan, Why a tough sell? Please explain. TJB Well, I am a fan of D. That said, there is a ton of money that goes into the HFT low latency arms race. I felt they were always willing to spend whatever it takes - but they had to make choices. First, I know for several firms there was a history the C++ vs Java back and forth until it was clear that the lowest latency systems were C/C++. The difference was attributed to many causes, but garbage collection always came up as a big one. I think just that association of C++ beating Java because of garbage collection will be enough to prevent many HFT shops from considering D for a long while, even if you could get rid of the gc entirely. Additionally, many of the advantages firms get come from dealing intelligently with the kernel and lowest level networking techniques which implies expertise in C and that often comes with a well-deserved pride in knowing how to make things run fast in specific ways. Further they are pushing even lower into custom hardware which is expensive. With the money to throw at it and the various alternatives to choose from there is a go big or go home mentality. They are not as worried about how fun it is to code in, how ugly your templates are, or how it might take longer to do something or to build something. I agree if you could get the finance industry interested in D that would be great. These are just my opinions and I left HFT a couple years back now. But, in this field, to expect a firm to get behind something like D you would need demonstrable improvements in performance irrespective of cost to develop. If they can do equivalent or better performance in C++ with more time to develop - then C++ still wins. Now if D can actually beat C++ significantly in quant programming performance things might change. Do you have ideas on how that could be done? If you consider automated, black box trading, most firms roll their own options infrastructure and these days QuantLib would not make the cut. But if you could demonstrate same functionality with improved performance by using D you could make a case. Thanks Dan
Inline New Class
OK, so I don't even know what it's actually called, but for
example, in Java:
exitItem.addSelectionListener(new SelectionAdapter() {
@Override
public void widgetSelected(SelectionEvent e) {
shell.getDisplay().dispose();
System.exit(0);
}
});
You can create a new subclass of one you want to use in a
function, with subclass function overrides such as this, but yet
I can't seem to figure out how to do this in D. The first
bracket always has a red underline telling me it's expecting a
')' (or a ';' in the case of trying to declare the listener
before using it in addSelectionListener).
Re: Inline New Class
On Saturday, 22 March 2014 at 04:35:57 UTC, Malkierian wrote:
OK, so I don't even know what it's actually called, but for
example, in Java:
exitItem.addSelectionListener(new SelectionAdapter() {
@Override
public void widgetSelected(SelectionEvent e) {
shell.getDisplay().dispose();
System.exit(0);
}
});
You can create a new subclass of one you want to use in a
function, with subclass function overrides such as this, but
yet I can't seem to figure out how to do this in D. The first
bracket always has a red underline telling me it's expecting a
')' (or a ';' in the case of trying to declare the listener
before using it in addSelectionListener).
That does already exists in D.
