Re: Dconf Hotel?
On 22 February 2014 03:23, Manu turkey...@gmail.com wrote: On 22 February 2014 01:22, Steven Schveighoffer schvei...@yahoo.com wrote: Last year, at the conference, after the sessions everyone met up at the Aloft hotel near Facebook's HQ to have passionate and fruitful discussions about D and I think a lot of good came out of it. As someone who was NOT staying at Aloft (and who was fortunate enough to have a speaker taxiing me around, thanks Ali!), I made it a point to try and stay this year at the location that would allow me to engage in the discussions and just be able to walk to my bed (I was in no shape to drive at least one of those nights, thanks again Ali!). I know that Andrei is now living in the area, and he was the one who picked Aloft. I'm assuming Andrei's house is likely not the new location ;) Where is the hot spot this year going to be? I want to book soon :) Yeah, it was definitely worth staying at the Aloft. I had the feeling last year that it might have been better to make the 'in' spot on the other side of the bay though... people can potentially walk/ride if it's closer to town/transport/trains. Aloft was a bit inconvenient for any without cars and not staying at Aloft. Speaking of which - have you got hotel covered Manu - I always try to be economical and am willing to book a room to share. :)
1st draft of complete class-based std.random successor
Hello all,
As some of you may already know, monarch_dodra and I have spent
quite a lot of time over the last year discussing the state of
std.random. To cut a long story short, there are significant
problems that arise because the current RNGs are value types
rather than reference types. We had quite a lot of back and
forth on different design ideas, with a lot of helpful input from
others in the community, but at the end of the day there are
really only two broad approaches: create structs that implement
reference semantics internally, or use classes. So, as an
exercise, I decided to create a class-based std.random.
The preliminary (but comprehensive) results of this are now
available here:
https://github.com/WebDrake/std.random2
Besides re-implementing random number generators as classes
rather than structs, the new code splits std.random2 into a
package of several different modules:
* std.random2.generator, pseudo-random number generators;
* std.random2.device, non-deterministic random sources;
* std.random2.distribution, random distributions such as
uniform,
normal, etc.;
* std.random2.adaptor, random adaptors such as randomShuffle,
randomSample, etc.
* std.random2.traits, RNG-specific traits such as isUniformRNG
and isSeedable.
A package.d file groups them together so one can still import all
together via import std.random2. I've also taken the liberty
of following the new guideline to place import statements as
locally as possible; it was striking how easy and clean this made
things, and it should be easy to port that particular change back
to std.random.
The new package implements all of the functions, templates and
range objects from std.random except for the old
std.random.uniformDistribution, whose name I have cannibalized
for better purposes. Some have been updated: the
MersenneTwisterEngine has been tweaked to match the corresponding
code from Boost.Random, and this in turn has allowed the
definition of a 64-bit Mersenne Twister (Mt19937_64) and an
alternative 32-bit one (Mt11213b).
There are also a number of entirely new entries.
std.random2.distribution contains not just existing functions
such as dice and uniform, but also range-based random
distribution classes UniformDistribution, NormalDistribution and
DiscreteDistribution; the last of these is effectively a
range-based version of dice, and is based on Chris Cain's
excellent work here:
https://github.com/D-Programming-Language/phobos/pull/1702
The principal weak point in terms of functionality is
std.random2.device, where the implemented random devices (based
on Posix' /std/random and /std/urandom) are really very primitive
and just there to illustrate the principle. However, since their
API is pretty simple (they're just input ranges with min and max
defined) there should be plenty of opportunity to improve and
extend the internals in future. Advice and patches are welcome
for everything, but particularly here :-)
What's become quite apparent in the course of writing this
package is how much more natural it is for ranges implementing
randomness to be class objects. The basic fact that another
range can store a copy of an RNG internally without creating a
copy-by-value is merely the start: for example, in the case of
the class implementation of RandomSample, we no longer need to
have complications like,
@property auto ref front()
{
assert(!empty);
// The first sample point must be determined here to avoid
// having it always correspond to the first element of the
// input. The rest of the sample points are determined
each
// time we call popFront().
if (_skip == Skip.None)
{
initializeFront();
}
return _input.front;
}
that were necessary to avoid bugs like
https://d.puremagic.com/issues/show_bug.cgi?id=7936; because the
class-based implementation copies by reference, we can just
initialize everything in the constructor. Similarly, issues like
https://d.puremagic.com/issues/show_bug.cgi?id=7067 and
https://d.puremagic.com/issues/show_bug.cgi?id=8247 just vanish.
Obvious caveats about the approach include the fact that classes
need to be new'd, and questions over whether allocation on the
heap might create speed issues. The benchmarks I've run (code
available in the repo) seem to suggest that at least the latter
is not a worry, but these are obviously things that need to be
considered. My own feeling is that ultimately it is a
responsibility of the language to offer nice ways to allocate
classes without necessarily relying on new or the GC.
A few remarks on design and other factors:
* The new range objects have been implemented as final classes
for
speed purposes. However, I tried another approach where the
RNG
class templates were abstract classes, and the individual
parameterizations were
Re: 1st draft of complete class-based std.random successor
Out of interest but, shouldn't in the device module have a static assert(0, Not implemented yet) type of deal with the version(Posix) block?
Re: 1st draft of complete class-based std.random successor
Joseph Rushton Wakeling: Few first comments: * std.random2.adaptor, random adaptors such as randomShuffle, randomSample, etc. Please don't use stuttering names like std.random2.randomShuffle. std.random2.shuffle is enough. My own feeling is that ultimately it is a responsibility of the language to offer nice ways to allocate classes without necessarily relying on new or the GC. I don't think the language is yet there. So I think currently this is not a good idea. Do you have a simple but very fast function that generates uniforms in [0.0, 1.0]? :-) Bye, bearophile
Re: 1st draft of complete class-based std.random successor
On Wednesday, 19 March 2014 at 23:58:36 UTC, Rikki Cattermole wrote: Out of interest but, shouldn't in the device module have a static assert(0, Not implemented yet) type of deal with the version(Posix) block? Not really. There's still usable functionality in there for all architectures (although I'm not sure how practically useful).
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 00:09:51 UTC, bearophile wrote: Do you have a simple but very fast function that generates uniforms in [0.0, 1.0]? :-) No, but it's planned. Jerro wrote quite a nice one in the course of his work on the Ziggurat algorithm, and I'm sure he'd be happy for me to adapt it accordingly.
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 00:09:51 UTC, bearophile wrote: Please don't use stuttering names like std.random2.randomShuffle. std.random2.shuffle is enough. I don't object to rewriting the names if there's a valid case for it, but it does seem to me to be important to try and match as much as possible the names that are already out there in std.random. The idea is to minimize the amount of rewriting anyone will have to do to adapt their code, and as far as I can tell where the contents of std.random2.adaptor are concerned (randomShuffle, randomCover, randomSample) it should require no rewriting at all. Besides, while std.random2.adaptor.randomShuffle may be the fully-qualified name, in practice, no one will write all that out, so the redundancy is less bad; and in any case, as any magician will tell you, a shuffle is not necessarily random ;-) I don't think the language is yet there. So I think currently this is not a good idea. If the aim were to overwrite std.random, I would agree with you, but there is no need to do that. It's named std.random2 for a reason :-) However, I do think that merging it into Phobos (assuming all other factors are OK) may have to be conditional on improvements in the available allocation strategies.
Re: 1st draft of complete class-based std.random successor
Joseph Rushton Wakeling: No, but it's planned. Jerro wrote quite a nice one in the course of his work on the Ziggurat algorithm, and I'm sure he'd be happy for me to adapt it accordingly. Note: I meant a simple but very fast function that generates just one value in [0.0, 1.0] (not a range). I don't object to rewriting the names if there's a valid case for it, but it does seem to me to be important to try and match as much as possible the names that are already out there in std.random. 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 The idea is to minimize the amount of rewriting anyone will have to do to adapt their code, If you want you can keep a deprecated randomShuffle alias name for some time in std.random2. Besides, while std.random2.adaptor.randomShuffle may be the fully-qualified name, in practice, no one will write all that out, so the redundancy is less bad; I agree. But better to improve names when you have a (the only) chance. However, I do think that merging it into Phobos (assuming all other factors are OK) may have to be conditional on improvements in the available allocation strategies. We will probably have the nice Andrei's allocators in Phobos, but not in a short time. So I suggest to not rely on them for std.random2. Bye, bearophile
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 00:39:43 UTC, bearophile wrote: Note: I meant a simple but very fast function that generates just one value in [0.0, 1.0] (not a range). There will be both. :-) Off the top of my head I'm not sure whether the interval will be [0.0, 1.0], [0.0, 1.0) or whether it might be possible to make it work with arbitrary boundaries. If I recall right, most uniform01 implementations are [0.0, 1.0) ... ? 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 If you want you can keep a deprecated randomShuffle alias name for some time in std.random2. Yes, in that case, I'd be happy to make the change (and maintain the old names via aliases). Thanks for pointing me to the bug report; I'd forgotten that this was an open issue :-) We will probably have the nice Andrei's allocators in Phobos, but not in a short time. So I suggest to not rely on them for std.random2. No, I don't intend to rely on them arriving soon. But while of course a random3 is always possible too, I'd rather not be faced with the situation of needing breaking changes to handle support for alternative allocation strategies. So if necessary, I'd rather maintain std.random2 outside of Phobos for a while and get things right when it finally lands, than push it in too early and need to make breaking changes.
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 00:15:22 UTC, Joseph Rushton
Wakeling wrote:
On Thursday, 20 March 2014 at 00:05:20 UTC, Joseph Rushton
Wakeling wrote:
Not really. There's still usable functionality in there for
all architectures (although I'm not sure how practically
useful).
Just to expand on that remark: my impression is that individual
random devices are inevitably going to be
architecture-dependent.
/dev/random and /dev/urandom are Posix devices; Windows AFAIK
has its own alternative. So the broad idea is that you'd have
as much generic functionality as possible available to all
architectures (mostly related to what sources you read from; a
file, a socket, something else?), and then individual
architecture-dependent aliases would map this to particular
random sources available to them.
Then, finally, you'd have some default alias RandomDevice that
would point to an appropriate architectural default; so e.g.
version (Posix)
{
alias RandomDevice = DevURandom!uint;
}
else version (Windows)
{
alias RandomDevice = ...
}
// etc.
... so, unless you were quite specific about your requirements,
90% of the time you could just use RandomDevice and expect it
to Just Work whatever your platform.
But as random devices are not my strongest area of expertise,
I'll happily take advice here.
For version blocks of code, I try to make sure they implement the
same interfaces like this one. To limit the possible issues.
It just makes things a little more cleaner for API users.
In the case that this isn't production ready the static assert
can be used as a TODO type of thing. Forcibly telling you it
isn't done yet. Its better than silently going into production
and finding out that a main platform isn't ready.
But this is just my preference.
Re: 1st draft of complete class-based std.random successor
Joseph Rushton Wakeling: Thanks for pointing me to the bug report; I'd forgotten that this was an open issue :-) In Bugzilla probably there are many bug reports/enhancement requests about std.random, so I suggest you to read them. Some of them can be useful, while other are probably already addressed in the current (or planned) std.random2. Another random one that was just commented by Infiltrator: https://d.puremagic.com/issues/show_bug.cgi?id=5901 Bye, bearophile
Re: 1st draft of complete class-based std.random successor
On Wednesday, 19 March 2014 at 23:49:41 UTC, Joseph Rushton Wakeling wrote: Hello all, As some of you may already know, monarch_dodra and I have spent quite a lot of time over the last year discussing the state of std.random. To cut a long story short, there are significant problems that arise because the current RNGs are value types rather than reference types. Any chance that you could describe them? I was about to resume porting the dcrypt library into Phobos, and had intended to flip the classes into structs, to match what the rest of the library was doing.
Re: IupSetCallback function passing
On Wednesday, 19 March 2014 at 02:21:18 UTC, James Wirth wrote:
When trying to associate an Icallback function to a button in
the IUP GUI
API using the IupSetCallback function, the D compiler seems to
insist on evaluating that callback in order to pass its value
rather than passing the function itself.
I get this dmd compiler error (the source is named hitmeiup.d) :
Error: function hitmeiup.hitMeAct (Ihandle_* dmy) is not
callable using argument types ()
hitmeiup.d(41): Error: expected 1 function arguments, not 0
for this line calling the IupSetCallback:
IupSetCallback(btn,ACTION,hitMeAct);
The callback function was named hitMeAct as follows:
extern(C) {
int hitMeAct(Ihandle *dmy) {
sayHit();
return 0;
}
}
I have also tried it with hitMeAct being a D function instead
of extern(C).
It is as if the call to IupSetCallback is interpreting hitMeAct
to be a property function and that the call was meant to be:
IupSetCallback(btn,ACTION,hitMeAct());
It there someway to force D to consider the hitMeAct parameter
to be passing a function and NOT calling it? I tried prefixing
a - no go.
Would welcome any hints.
Yes I have already looked at the .d files purporting to provide
access to IUP.
And a more or less equivalent C program works fine.
Using to get the function pointer is correct in this case.
You may need to do a cast for the pointer to what c expects.
However it will work fine.
The brackets forces it to call it. Don't.
Re: How to make a global immutable associative array?
On Wednesday, 19 March 2014 at 04:10:21 UTC, Meta wrote: On Wednesday, 19 March 2014 at 01:56:35 UTC, Rikki Cattermole wrote: Is an enum not appropriate? Because it can be used to push constants and available at ctfe. enum int[int] aa = [1: 2, 3: 4]; pragma(msg, aa); This will create a new associative array at runtime wherever aa is used, rather than creating only one instance at compile time and referring to it wherever aa is used. This is also the case with normal arrays, and possibly objects... I can't remember. Okay, well I learnt something.
Re: inlining...
On Wednesday, 19 March 2014 at 01:28:48 UTC, Manu wrote:
In the case you do want to inline the whole tree, you can just
cascade the
mixin through the stack. In the case you suggest which flattens
the tree by
default, we've lost control; how to tell it only to do it for
one level
without hacks? And I believe this is the common case.
You could provide it with a recursion level parameter or
parameters for cost level heuristics.
It could also be used to flatten tail-call recursion.
As the one that requested it, I have numerous uses for it to
mixin just the
one level. I can't imagine any uses where I would ever want to
explicitly
inline the whole tree, and not be happy to cascade it manually.
In innerloops to factor out common subexpressions that are
otherwise recomputed over and over and over.
When the function is generated code (not hand written).
noninline_func(){ inline_func();}
Why? This is really overcomplicating a simple thing. And I'm
not quite sure
what you're suggesting this should do either. Are you saying
the call tree
is flattened behind this proxy non-inline function?
No, I am saying that the one level mixin doesn't provide you with
anything new. You already have that. It is sugar.
Re: A simple sieve in Phobos?
On Wednesday, 19 March 2014 at 01:29:16 UTC, bearophile wrote: I suggest a Phobos module named combinatorics (or just combs?). It's not meant to be a complete library of combinatorics algorithms, nor to contain the most optimized algorithms around. It's meant to be a collection of efficient but sufficiently short implementations of the few algorithms/ranges you need most often. Everything else, including the most efficient code, I my opinion should be left to specialized numerical libraries external to Phobos (or could be added later if Phobos gains more developers). I think the most commonly useful functions are: - A lazy range (a simple unbounded segmented Sieve) that generates primes numbers very quickly, in a given range, or from 2; - A isPrime() function. Probably it should cache some of its computations. - A function to compute the GCD on ulongs/longs/bigints is useful. (Issues 4125 and 7102). - An efficient and as much as possibly overflow-safe binomial(n,k) that returns a single number. I'd also like permutations/combinations/pairwise ranges (Phobos already has a permutations, but it's designed on the legacy C++ style of functions, so it's not good enough). (See ER issue 6788 for pairwise. A the moment I can't find my Bugzilla ER entry for permutations/combinations, but you can see the good API for the permutations/combinations ranges in the code I have written here: http://rosettacode.org/wiki/Permutations#Fast_Lazy_Version See also the good API of the Python combinations/permutations here: http://docs.python.org/3/library/itertools.html#itertools.permutations note also the useful r and repeat arguments). With such 7 functions/ranges you can do lot of things :-) Bye, bearophile I've wanted exactly this. I was doing the euler project problems and had to implement my own prime sieve, isPrime range, GCD, binomial, and combination function (I used Phobos' permutation function, but was a bit disappointed that it wasn't implemented as a range). Being familiar with the Python combinations/permutations functions, I was looking for similar functionality in Phobos and was sad to find it missing. So +1 for a combinatorics module, and for a numerical/prime module.
Re: Appropriateness of posts
On 3/18/2014 10:24 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: However, I am upset about the widespread US term caucasian, not because it is a bad word, but because of the Aryan connotations that has some seriously bad vibes to it after 2WW and the nazi worship of scandinavian genes. The term caucasian is incredibly bad taste, and I find it offensive. I cringe when I cross off caucasian on US papers. It is if I am forced to declare myself Aryan. I find that interesting. This is the first I've ever heard of caucasian being even potentially offensive. In the US, referring to an ethnicity by the name of a color is somewhat borderline on the offensive/inoffensive scale. And by that I mean, nobody really knows whether or not they should avoid saying it. Two specific colors, yellow and red, are pretty much accepted as you just don't say it because they (apparently - it was well before my time) had a history of being used as derogatory. But black and white are less clear. Ever since the US civil rights movement, colored has become accepted as a term that you just don't say (despite still being used as the C in the NAACP, confusingly enough). So black was used to replace it. But then for some reason I'm completely ignorant of, many people started considering black to be taboo too, and started insisting people say African American, which I find rather goofy since not everyone of that apperently-unnameable ethnicity is American at all. So americans never know whether it's ok to say black. And they know it's not ok to say red or yellow (unless you simply mean yellow as afraid, but you better make darn sure nobody's going to misunderstand you, which is probably why even though green and blue are still occasionally used to mean jealous and sad, yellow is no longer used as afraid unless pronounced in a clearly Wild West accent like yelluh). So all that question and taboo about colors leads to uncertainty about whether it's still ok to say white, even though white is still used all the time anyway and I've never seen anyone get offended. So that uncertainty leads americans to use caucasion (apparently derived from the extremely academic term caucasoid, or so I've been told) just out of paranoia, since it's seen as far too pedantic and technical to possibly be offensive. But then, the African-descendent counterparts of caucasion and caucasoid, ie negro and negroid, are taboo because they sound too much like the word we're expected to refer to as the N word (even though rappers of that ethnicity have famously tossed it around like it's nothing - which I always assumed was partly done to dispel the negative connotations, but I guess some people would rather keep it as offensive - personally I don't give a crap, I just wish people would make up their minds). But of course, in many languages, negro is literally the word for the color black, so go figure. It's all a rediculous mess, really. I say we just refer to ALL groups as jackass, because I think really we all deserve it :) the world: Uhh, what's the big deal? Personally, I think it's positively bonkers to worry about kids being scarred by seeing something they themselves used to suck on, but whatever. Actually kids are more scarred by being told that such things are taboo. Being relaxed about the human body of others is a good path to feeling good about your own body. Yea, but according to some, we're supposed to feel ashamed of our bodies. ;) (Again, just about all american I've met has expressed that they have no problems with nudity themselves, and I believe them. Heh, There was one time I was in the locker room for some swimming pool, and an elderly gent was right in the middle of changing. He was in no hurry to finish, either. There were similar situations with my first college roommate too, an [american-]football player who wasn't exactly shy before/after showering. I actually found both of those cases slightly disturbing and the mental images still haunt me ;) But that said, I still find both examples as completely insufficient justification for bans on nudity. Fact of the matter is, I like to use both as shining examples of Just because you don't want to see something doesn't mean it should be banned. But I've been told that I cannot go swimming in my boxer shorts that look like swimming trunks because they are underwear and I could get into trouble over that… i.e. someone MIGHT be offended. Which is kinds of odd, cause in my own country I can go swimming naked and basically nobody would be offended, if spotted they might be amused, but not offended.) Yea, I find your stance on that much more sensible. I guess one could make an argument about questions of sanitation, but in a pool, if someone isn't clean I'm not sure swimming apparel is really going to make a huge difference. Admittedly, certain parts of the US are moving around to a more
Re: inlining...
On 19 March 2014 16:18,
7d89a89974b0ff40.invalid@internationalized.invalidwrote:
On Wednesday, 19 March 2014 at 01:28:48 UTC, Manu wrote:
In the case you do want to inline the whole tree, you can just cascade the
mixin through the stack. In the case you suggest which flattens the tree
by
default, we've lost control; how to tell it only to do it for one level
without hacks? And I believe this is the common case.
You could provide it with a recursion level parameter or parameters for
cost level heuristics.
Again, I think this is significantly overcomplicating something which see
is being extremely simple.
It could also be used to flatten tail-call recursion.
I don't think it's valid to inline a tail call recursion, because the
inlined call also wants to inline another call to itself...
You can't know how fer it should go, so it needs to be transformed into a
loop, and not we're talking about something completely different than
inlining.
As the one that requested it, I have numerous uses for it to mixin just the
one level. I can't imagine any uses where I would ever want to explicitly
inline the whole tree, and not be happy to cascade it manually.
In innerloops to factor out common subexpressions that are otherwise
recomputed over and over and over.
This is highly context sensitive. I would trust the compiler heuristics to
make the right decision here.
The idea of eliminating common sub-expressions suggests that there _are_
common sub-expressions, which aren't affected by the function arguments.
This case is highly unusual in my experience. And I personally wouldn't
depend on a feature such as this to address that sort of a problem in my
codegen. I would just refactor the function a little bit to call the common
sub-expression ahead of time.
When the function is generated code (not hand written).
I'm not sue what you mean here?
noninline_func(){ inline_func();}
Why? This is really overcomplicating a simple thing. And I'm not quite
sure
what you're suggesting this should do either. Are you saying the call tree
is flattened behind this proxy non-inline function?
No, I am saying that the one level mixin doesn't provide you with anything
new.
It really does provide something new. It provides effectively, a type-safe
implementation of something that may be used in place of C/C++ macros. I
think that would be extremely useful in a variety of applications.
You already have that. It is sugar.
I don't already have it, otherwise I'd be making use of it. D has no
control over the inliner. GDC/LDC offer attributes, but then it's really
annoying that D has no mechanism to make use of compiler-specific
attributes in a portable way (ie, attribute aliasing), so I can't make use
of those without significantly interfering with my code.
I also don't think that suggestion of yours works. I suspect the compiler
will see the outer function as a trivial wrapper which will fall within the
compilers normal inline heuristics, and it will all inline anyway.
Re: Appropriateness of posts
On 3/18/2014 12:20 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Monday, 17 March 2014 at 23:02:13 UTC, Nick Sabalausky wrote: People see that software development is predominately male, and they assume Oh, it *MUST* be because those EVIL, SEXIST men are TRYING to keep women out! That genuinely pisses me off, what the hell is this, 1920? When people actually *wanted* to As a student I taught introductory courses in programming. There was a reasonable number of females because they needed the course for biology etc. I think the programming talent was fairly evenly distributed. But your average female student value belonging to a group of other females so when the ratio fall below a threshold only the determined, tomboyish, selfconfident or very smart females will persist. And my impression is that they tend to gravitate either towards the social side of IT or towards the mathematical side, but fewer go for the tinkering fields? Yea, there's always been one or two women in almost any computer science class or programming team I've been in. I've never taken a programming course that was required for people outside the CS major, although from what I remember of the intro to programming tutoring I did, there does tend to be a...less uneven...mix in the introductory courses. In any case, there's definitely a group effect regardless of gender. Men do become nurses these days, but most people who pursue nursing are still women. And yet, I've never heard of anything actually trying to keep nursing a women's club. I suspect that some people misinterpret their own natural, often subconscious, apprehension towards entering a predominantly different from me group as being They don't want me there. And then sometimes they may try to over-compensate for that, which in and of itself can be rather off-putting to other people (perhaps triggering a negative feedback cycle?) Of course, among the males the tinkerers start out in their nerdy teens in social boyish groups. So they have a five year+ head start. Female teens will have problem accessing those groups if they don't have a nerdy big brother who is kind or a very nerdy dad… Are teenagers sexist? Of course… Heh, teenagers can be all sorts of unsavory adjectives ;) I was quite uncomfortable around teens back when I was one - many of them were real...well, better not to finish that thought. Ehh, but it's true of adults, too. The local public libraries around here intentionally segregate off the teenagers (which is asinine in and of itself) citing concerns over noise. And yet, I've been a *very* frequent patron of those libraries for several years and the *only* people I've ever seen failing to grasp the whole library == quiet notion were middle-aged. One of them was even some upper-manager for the very library he was loudly blathering on in. Even more bizarre was the nature of his noise: He was very loudly boasting how he'd arranged the library so that the noisy teenagers were shoved off into a remote corner. And yet, at no point had I ever come across noisy teens there despite, for several years, being regularly there (including visiting the teen section because that's where the library decided manga belongs) twice a week at exactly the time of day when teenage traffic was at a peak. The teenagers: Dead silent. Various parents: BLAH BLAH BLAH BLAH BLAH!!! And then I see people carefully whispering in bookstores, or order McNuggets at Wendy's, etc, and loose all hope for humanity... rule against women. And yet somehow programming is allegedly full of women-hating men? Fucking crock of shit. Yeah, but programming is full of awkward teenage boys who lock themselves up in their basements where the girls cannot find them. ;-) Hmm, something about that sounds very familiar...almost as if I know someone...someone I know very, *VERY* well who...oh wait...nevermind. ;)
Re: Not the last breakage (Was: TLBB: The Last Big Breakage)
On Sunday, 16 March 2014 at 13:55:24 UTC, bearophile wrote: Benjamin Thaut: Could you please explain in a bit more detail why you think opApply should be deprecated? To replace it with something better. Don't even think, ranges are not better.
Re: Most basic nothrow, pure, @safe functions?
On 19/03/14 00:20, Steven Schveighoffer wrote: I think we all agree that there are some things that the compiler simply cannot prove are nothrow, but to be able to write useful nothrow code, we have to paste nothrow on there anyway. Just to clarify my understanding here: exactly how much compiler checking _is_ done of nothrow? Is it simply to confirm that whatever is called by the function contains no throw statements (hopefully all the way down ...), or is there more ... ? What I'm wondering is whether just as we have @safe and @trusted for the situations where the compiler can verify and where the programmer has verified, is there a case for complementing nothrow with another attribute (wontthrow?) that's a programmer assurance rather than a compiler-checked guarantee? I imagine if that was worthwhile someone would already have done it, but I'm curious.
Re: How to make a global immutable associative array?
On Wednesday, 19 March 2014 at 02:52:23 UTC, bearophile wrote: Rikki Cattermole: Is an enum not appropriate? Because it can be used to push constants and available at ctfe. enum int[int] aa = [1: 2, 3: 4]; pragma(msg, aa); This is bad from an efficiency point of view. I think Don even suggested to disallow it. Bye, bearophile It still only existing way to define compile-time usable AA value, disallowing it without fixing alternatives is not an option.
Re: inlining...
On Wednesday, 19 March 2014 at 08:35:53 UTC, Manu wrote: The idea of eliminating common sub-expressions suggests that there _are_ common sub-expressions, which aren't affected by the function arguments. This case is highly unusual in my experience. Not if you delay optimization until profiling and focus on higher level structures during initial implementation. Or use composing (like generic programming). If you hand optimize right from the start then you might be right, but if you never call a function with the same parameters then you are doing premature optimization IMHO. When the function is generated code (not hand written). I'm not sue what you mean here? Code that is generated by a tool (or composable templates or whatever) tend to be repetitive and suboptimal. I.e. boiler plate code that looks like it was written by a monkey… You already have that. It is sugar. I don't already have it, otherwise I'd be making use of it. D has no control over the inliner. I meant that if you have explicit inline hints like C++ then you also have call-site inlining if you want to. I also don't think that suggestion of yours works. I suspect the compiler will see the outer function as a trivial wrapper which will fall within the compilers normal inline heuristics, and it will all inline anyway. That should be considered a bug if it is called from more than one location.
Re: How to make a global immutable associative array?
On Wednesday, 19 March 2014 at 09:12:53 UTC, Dicebot wrote:
On Wednesday, 19 March 2014 at 02:52:23 UTC, bearophile wrote:
Rikki Cattermole:
Is an enum not appropriate? Because it can be used to push
constants and available at ctfe.
enum int[int] aa = [1: 2, 3: 4];
pragma(msg, aa);
This is bad from an efficiency point of view. I think Don even
suggested to disallow it.
Bye,
bearophile
It still only existing way to define compile-time usable AA
value, disallowing it without fixing alternatives is not an
option.
There might be another way depending on how good the compiler is
at optimizing out pure functions.
Because in theory it'll only call it once (did test in this
context). But I don't know how it handles it within memory.
@property pure int[int] test() {
pragma(msg, hit);
return [1 : 2, 3 : 4];
}
pragma(msg, test);
pragma(msg, test);
hit
[1:2, 3:4]
[1:2, 3:4]
Re: Appropriateness of posts
On Wednesday, 19 March 2014 at 07:51:06 UTC, Nick Sabalausky wrote: But black and white are less clear. Ever since the US civil rights movement, colored has become accepted as a term that you just don't say (despite still being used as the C in the NAACP, confusingly enough). So black was used to replace it. But then for some reason I'm completely ignorant of, many people started considering black to be taboo too, and started insisting people say African American, which I find rather goofy since not everyone of that apperently-unnameable ethnicity is American at all. Nor is everyone who is African black in the sense outlined above (cf. Northern Africa). The problem is that as long as a group is discriminated against (overtly or covertly), it doesn't matter what new name you make up in order to sound less offensive, it will soon be perceived as derogatory. That's why you have negro colored black African American. It only shows that discrimination has never really stopped. [...] even though white is still used all the time anyway and I've never seen anyone get offended. QED. white has no negative connotations simply because the majority of people are white. The thing is as long there is racism and discrimination against minorities (be it ethnicity or sexual orientation or religion), people will always feel uneasy about it and it will always result in twisted minds (political correctness is a symptom, and proof, of the madness of racism and discrimination). There is no way out _within_ this framework (that's why pc has failed), the only way out is to leave the framework. Yes, we are all jackasses!
Re: How to make a global immutable associative array?
On Wednesday, 19 March 2014 at 09:12:53 UTC, Dicebot wrote: On Wednesday, 19 March 2014 at 02:52:23 UTC, bearophile wrote: Rikki Cattermole: Is an enum not appropriate? Because it can be used to push constants and available at ctfe. enum int[int] aa = [1: 2, 3: 4]; pragma(msg, aa); This is bad from an efficiency point of view. I think Don even suggested to disallow it. Bye, bearophile It still only existing way to define compile-time usable AA value, disallowing it without fixing alternatives is not an option. The only thing I've said we should disallow, is creating a runtime reference to a value which only exists at compile-time. I think it is logically nonsensical. I don't see any problem at all with creating a compile-time AA, and then looking up an index in it at compile time.
Re: A simple sieve in Phobos?
Meta: If all that complexity is nicely encapsulated from the user, then why not put it in some theoretical Phobos package? For practical reasons. You have to maintain Phobos code. So you need people that understands the code. A very complex implementation is understood only by few persons. Also a very long piece of code needs more work to be maintained. Every line of code has a live cost. Bye, bearophile
Re: Not the last breakage (Was: TLBB: The Last Big Breakage)
Kagamin: Don't even think, ranges are not better. I am thinking about syntax sugar that the compiler uses to create a input/forward range similar to this: http://forum.dlang.org/post/awabysprjjnrxrhgq...@forum.dlang.org Bye, bearophile
Re: A simple sieve in Phobos?
I miss so much a std.geometry library with operations on 1d 2d and 3d objects (intersections, unions, difference, and so on...) in d style... It would open a whole new world for me :) On Wednesday, 19 March 2014 at 01:42:38 UTC, bearophile wrote: - A function to compute the GCD on ulongs/longs/bigints is useful. (Issues 4125 and 7102). A GCD is already in Phobos but it doesn't work with bigints. And putting it in the std.combinatorics is better. Bye, bearophile
Re: Good name for f.byLine.map!(x = x.idup)?
On Tue, 18 Mar 2014 15:03:16 -, Dicebot pub...@dicebot.lv wrote: On Tuesday, 18 March 2014 at 14:57:30 UTC, Regan Heath wrote: Why this fixation on by? lines allLines eachLine everyLine R range vs container. I expect file.lines to be separate fully allocated entity that can be assigned and stored. file.byLines implies iteration without any guarantees about collection as a whole. So by has come to signify range then? eachLine does not imply a container but an iteration/range.. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: std.utf.toUTF16z and windows unicode path limits
How funny ... The win7 gui copy and paste failed to copy a folder with a deep directory structure ... putting up a message dialog about the pathnmames being too long! A d parallel copy rewrite works.
Re: inlining...
On 19 March 2014 19:16, 7d89a89974b0ff40.invalid@internationalized.invalidwrote: On Wednesday, 19 March 2014 at 08:35:53 UTC, Manu wrote: The idea of eliminating common sub-expressions suggests that there _are_ common sub-expressions, which aren't affected by the function arguments. This case is highly unusual in my experience. Not if you delay optimization until profiling and focus on higher level structures during initial implementation. Or use composing (like generic programming). If you hand optimize right from the start then you might be right, but if you never call a function with the same parameters then you are doing premature optimization IMHO. Okay, do you have use cases for any of this stuff? Are you just making it up, or do you have significant experience to say this is what you need? I can say for a fact, that recursive inline would make almost everything I want it for much more annoying. I would find myself doing stupid stuff to fight the recursive inliner in every instance. When the function is generated code (not hand written). I'm not sue what you mean here? Code that is generated by a tool (or composable templates or whatever) tend to be repetitive and suboptimal. I.e. boiler plate code that looks like it was written by a monkey… I'm not sure where the value is... why would you want to inline this? You already have that. It is sugar. I don't already have it, otherwise I'd be making use of it. D has no control over the inliner. I meant that if you have explicit inline hints like C++ then you also have call-site inlining if you want to. I still don't follow. C++ doesn't have call-site inlining. C/C++ has macros, and there is no way to achieve the same functionality in D right now, that's a key motivation for the proposal. I also don't think that suggestion of yours works. I suspect the compiler will see the outer function as a trivial wrapper which will fall within the compilers normal inline heuristics, and it will all inline anyway. That should be considered a bug if it is called from more than one location. Seriously, you're making 'inline' about 10 times more complicated than it should ever be. If you ask me, I have no value in recursive inlining, infact, that would anger me considerably. By making this hard, you're also making it equally unlikely. Let inline exist first, then if/when it doesn't suit your use cases, argue for the details.
Re: Appropriateness of posts
On 3/19/2014 6:08 AM, Chris wrote: On Wednesday, 19 March 2014 at 07:51:06 UTC, Nick Sabalausky wrote: [...] even though white is still used all the time anyway and I've never seen anyone get offended. QED. white has no negative connotations simply because the majority of people are white. The majority of people are Asian. The majority of Americans are white. But I'm being pedantic. :) Of course, if I want get *really* pedantic, I'm not certain if those are actual majorities (ie 50%) or simply just the largest (erm, I mean most numerous) ethnic groups. But I don't want to get that pedantic ;) But you make a good point. If one group has historically been treated badly, then any reference to them has a certain chance of being interpreted as derogatory. I've noticed that the more fresh the memory of ill-treatment, or the more such memory is maintained and cultivated, the more likely things will be interpreted, or misinterpreted, as offensive. Interestingly enough, it makes no difference whether the discrimination is still happening or not: As long as people remember that is *has* happened, there will *always* be a higher chance of someone interpreting a statement as derogatory, even if it wasn't intended to be. Choose to believe discrimination exists and it will *always* be found *somewhere*, even if it has to be subconsciously fabricated in order to fulfill the preconceived belief that it still exists. Great example of this phenomenon is Resident Evil: Several games, one after another, involving battle for survival against hordes of people-turned-bloodthirty-zombies (infected by an evil entity). First game set in an American mansion, battling white American zombies, everything's ok. Next game set in an American town, battling more white American zombies, everything's ok. Three more games, all fine. Then one set in Spain with (obviously) Spanish zombies. Everything's *still* good. Then, the same *non-American* developer, Capcom, makes the unfortunate mistake of doing a North American release of a new Resident Evil taking place in...Africa. Obviously, any zombies in Africa would be...uhh...African? Oh, holy shit, *now* all hell breaks loose. Surprise, surprise, *now* some crazed fucking nutjob climbs out of the woodwork and starts squawking all over about how overtly racist this game suddenly is. Same fucking game as the rest of the decade-old series, just different location. But no, *now* it's racist. So where the fuck was she when the rest of the series was made? Off deciding Oh, well it's obviously ok if they're killing whiteys! or some such? Bah. In any case, so much for equality. Nobody (at least in the US) discriminates against Italians or Irish anymore. Oh, they used to get a lot of crap. Hell, they got *plenty* of shit from people. All ethnic groups in the US did at some point in time. But then it was dwarfed by the whole African slavery thing, and civil rights and women's lib, etc so everyone forgot to continue worrying about Irish discrimination, Italian discrimination, etc. *That's* what killed it off. Not some idiotic, self-perpetuating, discrimination witch hunt. Anti-white derogatory stuff no longer exists *because* we all just shrug it off. Nobody's choosing to be offended, therefore it can't offend. It has no teeth. Because we've given it none. This happened for one reason: Because we lost all our remaining excuses to be offended. Hell, as americans, we're all too busy playing guilt trip anyway over some crap that was pulled (in *part* of the country) by some grossly unethical asshats who none of us have ever even met (let alone *been* one) because they've all been dead and gone for over a century. Point of all this being, and history has proved this, discrimination will always be kept alive in the hearts of people who insist on forever being offended by it. It might still exist. Or it might not. But whether or not it exists has long since stopped being relevant, and if/when it ends we'll never even notice anyway. Because as soon as it does go away, it will only continue living on as a specter, built and maintained by those who choose to believe in it, all because they're too afraid to relinquish their comfortable, familiar self-identity as a victim of some vague, conveniently hidden, indentity-less, anyone-or-anything villain.
Re: A simple sieve in Phobos?
Dan Killebrew: and had to implement my own prime sieve, isPrime range, The sieve is a range, but isPrime() is just a predicate function (possibly only logically pure, to store some precedent computation), it's not a range. Bye, bearophile
Re: Good name for f.byLine.map!(x = x.idup)?
Am Tue, 18 Mar 2014 09:49:32 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: On 3/18/14, 6:49 AM, Steven Schveighoffer wrote: byStringLines First one I like. Andrei Also consider the consistency. The function does byLine() + a copy, right? Not something entirely different. byLine byLine[Copy/Dup/...] would also show up in order on lists like Phobos documentation or IDE completion lists, so it cannot be missed. Which is important, because the obvious choice has the unexpected buffer reuse. Consistency, consistency, consistency. That's how Java got big. How PHP made it, I don't know. -- Marco
Re: A simple sieve in Phobos?
Am Wed, 19 Mar 2014 10:39:36 + schrieb bearophile bearophileh...@lycos.com: Meta: If all that complexity is nicely encapsulated from the user, then why not put it in some theoretical Phobos package? For practical reasons. You have to maintain Phobos code. So you need people that understands the code. A very complex implementation is understood only by few persons. Also a very long piece of code needs more work to be maintained. Every line of code has a live cost. Bye, bearophile For starters there are a lot of code blocks that differ only in 1 or 2 values. These should be extracted into inline functions with a nice name. -- Marco
Re: A simple sieve in Phobos?
Am Wed, 19 Mar 2014 11:22:55 + schrieb Andrea Fontana nos...@example.com: I miss so much a std.geometry library with operations on 1d 2d and 3d objects (intersections, unions, difference, and so on...) in d style... It would open a whole new world for me :) I wonder if we could finally have that experimental package, call it ext or etc or whatever that has only one barrier to entry: the intent of the module must pass review. The API and code can build up over time as people start using it. At some point it can be called finished and thoroughly reviewed. I think the barrier of entry is currently very high since the reviews expect perfect quality from the start, but good things need time to collect corner cases and use cases that might cause major refactorings. It's straight forward to implement for rectangles or circles, but would any design still be good when someone tries to implement a 2D physics engine on top of that? Would CSG operations be part of the module? What about paths, curves and loading from and saving to vector graphics (SVG)? (I.e. you could literally draw the collision shape of a tree bitmap in Inkscape and load it as 2D geometry.) -- Marco
Re: Appropriateness of posts
On Wednesday, 19 March 2014 at 13:08:00 UTC, Nick Sabalausky wrote: On 3/19/2014 6:08 AM, Chris wrote: On Wednesday, 19 March 2014 at 07:51:06 UTC, Nick Sabalausky wrote: [...] even though white is still used all the time anyway and I've never seen anyone get offended. QED. white has no negative connotations simply because the majority of people are white. The majority of people are Asian. The majority of Americans are white. But I'm being pedantic. :) Of course, if I want get *really* pedantic, I'm not certain if those are actual majorities (ie 50%) or simply just the largest (erm, I mean most numerous) ethnic groups. But I don't want to get that pedantic ;) The dominant culture is white, or rather WASP. It doesn't matter if the majority is actually white. The WASP culture is still the one that defines that standards. But you make a good point. If one group has historically been treated badly, then any reference to them has a certain chance of being interpreted as derogatory. I've noticed that the more fresh the memory of ill-treatment, or the more such memory is maintained and cultivated, the more likely things will be interpreted, or misinterpreted, as offensive. Interestingly enough, it makes no difference whether the discrimination is still happening or not: As long as people remember that is *has* happened, there will *always* be a higher chance of someone interpreting a statement as derogatory, even if it wasn't intended to be. Choose to believe discrimination exists and it will *always* be found *somewhere*, even if it has to be subconsciously fabricated in order to fulfill the preconceived belief that it still exists. Great example of this phenomenon is Resident Evil: Several games, one after another, involving battle for survival against hordes of people-turned-bloodthirty-zombies (infected by an evil entity). First game set in an American mansion, battling white American zombies, everything's ok. Next game set in an American town, battling more white American zombies, everything's ok. Three more games, all fine. Then one set in Spain with (obviously) Spanish zombies. Everything's *still* good. Then, the same *non-American* developer, Capcom, makes the unfortunate mistake of doing a North American release of a new Resident Evil taking place in...Africa. Obviously, any zombies in Africa would be...uhh...African? Oh, holy shit, *now* all hell breaks loose. Surprise, surprise, *now* some crazed fucking nutjob climbs out of the woodwork and starts squawking all over about how overtly racist this game suddenly is. Same fucking game as the rest of the decade-old series, just different location. But no, *now* it's racist. So where the fuck was she when the rest of the series was made? Off deciding Oh, well it's obviously ok if they're killing whiteys! or some such? Bah. In any case, so much for equality. Nobody (at least in the US) discriminates against Italians or Irish anymore. Oh, they used to get a lot of crap. Hell, they got *plenty* of shit from people. All ethnic groups in the US did at some point in time. But then it was dwarfed by the whole African slavery thing, and civil rights and women's lib, etc so everyone forgot to continue worrying about Irish discrimination, Italian discrimination, etc. *That's* what killed it off. Not some idiotic, self-perpetuating, discrimination witch hunt. One of the reasons why Irish (and Italian) immigrants stopped being discriminated against was because they would find the lowest (indeed very low) common denominator, i.e. giving out about blacks. At least they were white (the Italians less so, but still not really black), albeit Catholic. Anti-white derogatory stuff no longer exists *because* we all just shrug it off. Nobody's choosing to be offended, therefore it can't offend. It has no teeth. Because we've given it none. That's easy, if you are part of the dominant culture. Also, white is too broad a term so every white person can choose not to identify with it and point somewhere else (we're not rednecks here in NY!). But if you attack a certain set of beliefs held by the dominant culture, hell will break loose. Within the dominant group, it's not an ethnic thing, it's about beliefs. If you question them, you won't have an easy life. This happened for one reason: Because we lost all our remaining excuses to be offended. Hell, as americans, we're all too busy playing guilt trip anyway over some crap that was pulled (in *part* of the country) by some grossly unethical asshats who none of us have ever even met (let alone *been* one) because they've all been dead and gone for over a century. Point of all this being, and history has proved this, discrimination will always be kept alive in the hearts of people who insist on forever being offended by it. It might still exist. Or it might not. But whether or not it exists has long since stopped being relevant, and
Re: Not the last breakage (Was: TLBB: The Last Big Breakage)
On Wednesday, 19 March 2014 at 10:41:59 UTC, bearophile wrote: Kagamin: Don't even think, ranges are not better. I am thinking about syntax sugar that the compiler uses to create a input/forward range similar to this: http://forum.dlang.org/post/awabysprjjnrxrhgq...@forum.dlang.org There is, however, a fundamental difference between ranges and opApply: Ranges use external iteration, whereas in opApply, it is the collection object that controls how iteration is performed. Features like transparent parallelization in std.parallelism would not be possible without this. David
Re: A simple sieve in Phobos?
On 3/19/14, 7:07 AM, Marco Leise wrote: I wonder if we could finally have that experimental package, call it ext or etc or whatever that has only one barrier to entry: the intent of the module must pass review. I think it's time to add an experimental package. Andrei
Ruby-style each in D?
Pros and cons are already being discussed. Destroy! https://github.com/D-Programming-Language/phobos/pull/2024 Andrei
Re: A simple sieve in Phobos?
I don't need a package to build an engine on top of it. If you're going to write a game with 3d and physic probably you're going to use ogre, irrlicht, physx or everything else. And they have their own optimized implementation of these objects. But a geometry package is not only for game or physics. Just an example: I wrote (in c++) an app to merge two images. Here a test: http://www.e-nuts.net/test2.jpg (the right image is an automatic merge of the other two). In this case a geometry package would simplify my life a lot :) Another thing I would like to do is a generator of solids to print with a 3d printer. Some strange math objects. Or maybe a slicer for 3d printer's software stack. Or something like openscad. Here we need productivity rather than realtime performance. On Wednesday, 19 March 2014 at 14:05:19 UTC, Marco Leise wrote: Am Wed, 19 Mar 2014 11:22:55 + schrieb Andrea Fontana nos...@example.com: I miss so much a std.geometry library with operations on 1d 2d and 3d objects (intersections, unions, difference, and so on...) in d style... It would open a whole new world for me :) I wonder if we could finally have that experimental package, call it ext or etc or whatever that has only one barrier to entry: the intent of the module must pass review. The API and code can build up over time as people start using it. At some point it can be called finished and thoroughly reviewed. I think the barrier of entry is currently very high since the reviews expect perfect quality from the start, but good things need time to collect corner cases and use cases that might cause major refactorings. It's straight forward to implement for rectangles or circles, but would any design still be good when someone tries to implement a 2D physics engine on top of that? Would CSG operations be part of the module? What about paths, curves and loading from and saving to vector graphics (SVG)? (I.e. you could literally draw the collision shape of a tree bitmap in Inkscape and load it as 2D geometry.)
Re: Ruby-style each in D?
On Wednesday, 19 March 2014 at 15:06:40 UTC, Andrei Alexandrescu wrote: Pros and cons are already being discussed. Destroy! https://github.com/D-Programming-Language/phobos/pull/2024 Andrei Very similar to one of the additions I proposed awhile ago. The only difference is that my each() didn't call popFront(). http://forum.dlang.org/thread/ovbjcmogezbvsxrwf...@forum.dlang.org#post-mailman.621.1370146215.13711.digitalmars-d:40puremagic.com
Re: A simple sieve in Phobos?
Andrei Alexandrescu píše v St 19. 03. 2014 v 08:02 -0700: On 3/19/14, 7:07 AM, Marco Leise wrote: I wonder if we could finally have that experimental package, call it ext or etc or whatever that has only one barrier to entry: the intent of the module must pass review. I think it's time to add an experimental package. Andrei +1 it will be improvement
Re: Ruby-style each in D?
Andrei Alexandrescu: Pros and cons are already being discussed. Destroy! https://github.com/D-Programming-Language/phobos/pull/2024 I proposed the same function in D.learn, but this discussion needs a list of use cases and usage examples, otherwise you can't decide in vacuum. It's named foreach in Scala: http://twitter.github.io/scala_school/collections.html#foreach Elsewhere I suggested a function that could be named tap() that's usable to debug UFCS chains, interspersing it in the chain, to add imperative calls to writeln. You can replace a each() with a tap + some kind of eager consumer. In many cases what I want to put in each() is a writef/writefln, you can do it like this (binaryReverseArgs is in std.functional): foo .bar .spam .binaryReverseArgs!writefln(%(%s-%): %d, 5); With a shorter flipping name it gets better: foo .bar .spam .flipTwoArgs!writefln(%(%s-%): %d, 5); or even (http://zvon.org/other/haskell/Outputprelude/flip_f.html ) (flips only the first two args and doesn't flip the successive ones): foo .bar .spam .flip!writefln(%(%s-%): %d, 5); Let's say in each() you want to do something different, like incrementing a variable: foo .bar .spam .each!(n = x += n); Is this good enough? If you want to double the contents of an array: myArray.each((ref x) = x * 2); But in D you can also use: myArray[] *= 2; I guess you can't use each() on opApply-based iterables, while you can with foreach(). This makes each() less useful. Is the following code supported? And what is each() receiving from the associative array? int[string] aa; aa.each(...); Perhaps you must use: int[string] aa; aa.byKey.each(...); aa.byValue.each(...); aa.byPair.each(...); While arrays should be OK, but there is no index support: int[] arr; arr.each(...); If you need dynamic array index support: int[] arr; arr.enumerate.each(...); Is this supported? int[10] arr2; arr2.each(...); Or do you have to use this? int[10] arr2; arr2[].each(...); Bye, bearophile
Re: A simple sieve in Phobos?
On Wednesday, 19 March 2014 at 15:02:55 UTC, Andrei Alexandrescu wrote: On 3/19/14, 7:07 AM, Marco Leise wrote: I wonder if we could finally have that experimental package, call it ext or etc or whatever that has only one barrier to entry: the intent of the module must pass review. I think it's time to add an experimental package. Andrei I am against it. It gives nothing over dub and creates confusion.
Re: Ruby-style each in D?
On 3/19/14, 9:03 AM, Dicebot wrote: On Wednesday, 19 March 2014 at 16:01:06 UTC, Andrei Alexandrescu wrote: On 3/19/14, 8:55 AM, Dicebot wrote: I would have supported if it was lazy. Not in its proposed form. Good point. Maybe forall would be a better name. Andrei I think each is a good name but it should instead return range that calls predicate function upon popFront and proxies input argument further from front. bearophile has been proposing it under name tap, but I like each more. tee is already being discussed -- Andrei
Re: Ruby-style each in D?
On Wednesday, 19 March 2014 at 16:01:06 UTC, Andrei Alexandrescu wrote: On 3/19/14, 8:55 AM, Dicebot wrote: I would have supported if it was lazy. Not in its proposed form. Good point. Maybe forall would be a better name. Andrei I think each is a good name but it should instead return range that calls predicate function upon popFront and proxies input argument further from front. bearophile has been proposing it under name tap, but I like each more.
Re: Ruby-style each in D?
On 03/19/2014 05:01 PM, Andrei Alexandrescu wrote: On 3/19/14, 8:55 AM, Dicebot wrote: I would have supported if it was lazy. Not in its proposed form. Good point. Maybe forall would be a better name. Andrei http://en.wikipedia.org/wiki/Forall
Re: Ruby-style each in D?
On 3/19/14, 8:55 AM, Dicebot wrote: I would have supported if it was lazy. Not in its proposed form. Good point. Maybe forall would be a better name. Andrei
Re: A simple sieve in Phobos?
On 3/19/14, 8:45 AM, Dicebot wrote: On Wednesday, 19 March 2014 at 15:02:55 UTC, Andrei Alexandrescu wrote: On 3/19/14, 7:07 AM, Marco Leise wrote: I wonder if we could finally have that experimental package, call it ext or etc or whatever that has only one barrier to entry: the intent of the module must pass review. I think it's time to add an experimental package. Andrei I am against it. It gives nothing over dub and creates confusion. Who'd be confused? Andrei
Re: Ruby-style each in D?
I would have supported if it was lazy. Not in its proposed form.
Re: Ruby-style each in D?
On Wednesday, 19 March 2014 at 16:04:16 UTC, Andrei Alexandrescu wrote: tee is already being discussed -- Andrei On this topic, do we have something like consume in Phobos to eagerly iterate through the supplied range? Don't see anything similar at first glance and it will be needed to express same idiom via tap/tee in a readable form.
Re: A simple sieve in Phobos?
On Wednesday, 19 March 2014 at 15:58:43 UTC, Andrei Alexandrescu wrote: Who'd be confused? Andrei Users who see find it in Phobos will be confused about how experimental exactly it is and what to expect from it. Developers will be confused about what is expected from them maintenance-wise starting from this point and what to do with reported bugs / issues. Don't put stuff which is naturally bleeding edge into scheduled controlled distributions. dub has special category for Phobos proposals, we need to better popularize it.
Re: Ruby-style each in D?
On Wednesday, 19 March 2014 at 16:09:31 UTC, Dicebot wrote: On Wednesday, 19 March 2014 at 16:04:16 UTC, Andrei Alexandrescu wrote: tee is already being discussed -- Andrei On this topic, do we have something like consume in Phobos to eagerly iterate through the supplied range? I had proposed walk, which would be consistent with the already existing walkLength. An each() with no arg could also do the trick, but that would also call the front, which means it's not the exact same behavior (not better or worst, just different).
Re: A simple sieve in Phobos?
Am Wed, 19 Mar 2014 16:06:44 + schrieb Dicebot pub...@dicebot.lv: On Wednesday, 19 March 2014 at 15:58:43 UTC, Andrei Alexandrescu wrote: Who'd be confused? Andrei Users who see find it in Phobos will be confused about how experimental exactly it is and what to expect from it. Developers will be confused about what is expected from them maintenance-wise starting from this point and what to do with reported bugs / issues. Why was that never a problem for OpenGL ? Don't put stuff which is naturally bleeding edge into scheduled controlled distributions. dub has special category for Phobos proposals, we need to better popularize it. That much is true. Last time I checked it wasn't there. Then again everyone can add categories there. I added two myself. Everyone can tag their package as Phobos candidate. But I cannot imagine random packages on dub getting the same exposure as modules included in Phobos. They will be auto-tested, the idea has the approval of the community and they are ready to use when you install the compiler. Personally I avoid dub, so to that end I'm probably biased. -- Marco
Re: A simple sieve in Phobos?
On Wed, 2014-03-19 at 15:45 +, Dicebot wrote: On Wednesday, 19 March 2014 at 15:02:55 UTC, Andrei Alexandrescu wrote: On 3/19/14, 7:07 AM, Marco Leise wrote: I wonder if we could finally have that experimental package, call it ext or etc or whatever that has only one barrier to entry: the intent of the module must pass review. I think it's time to add an experimental package. Andrei I am against it. It gives nothing over dub and creates confusion. The experimental package was removed from Go once the importing from repositories worked properly. The core had only in it that which had been agreed by the process, nothing experimental. This made everything a lot cleaner. So I think keeping Phobos with only vetted and approved code is a better solution. -- 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: Ruby-style each in D?
On 3/19/14, 9:10 AM, Timon Gehr wrote: On 03/19/2014 05:01 PM, Andrei Alexandrescu wrote: On 3/19/14, 8:55 AM, Dicebot wrote: I would have supported if it was lazy. Not in its proposed form. Good point. Maybe forall would be a better name. Andrei http://en.wikipedia.org/wiki/Forall Never mind, each is better :o) -- Andrei
Re: Ruby-style each in D?
On 3/19/14, 9:09 AM, Dicebot wrote: On Wednesday, 19 March 2014 at 16:04:16 UTC, Andrei Alexandrescu wrote: tee is already being discussed -- Andrei On this topic, do we have something like consume in Phobos to eagerly iterate through the supplied range? A default each would do that. Andrei
Re: A simple sieve in Phobos?
On 3/19/14, 9:06 AM, Dicebot wrote: On Wednesday, 19 March 2014 at 15:58:43 UTC, Andrei Alexandrescu wrote: Who'd be confused? Andrei Users who see find it in Phobos will be confused about how experimental exactly it is and what to expect from it. Developers will be confused about what is expected from them maintenance-wise starting from this point and what to do with reported bugs / issues. Don't put stuff which is naturally bleeding edge into scheduled controlled distributions. dub has special category for Phobos proposals, we need to better popularize it. Ionno. To me experimental sounds as informative and self-explanatory as it gets, and puts things up for experimentation with the distribution and without requiring users to take special steps. Andrei
Cannot cast X to Y at compile time...?
I have a function called at CTFE which includes the lines:
97 if(conjunction exp = cast(conjunction)this_exp) {
98 inner_substitutions!(first,conjunction)(exp, map);
99 } else if(disjunction exp = cast(disjunction)this_exp) {
100 inner_substitutions!(first,disjunction)(exp, map);
101 }
Here, this_exp is a reference of type expression to an object
whose CTFE-runtime-type is of type disjunction. conjunction
and disjunction are both descendent classes of expression.
This code produces the following compilation error:
source/cfgparse.d(97): Error: cannot cast [...] to
cfgparse.conjunction at compile time.
([...] stands in for a very long string which I think is some
sort of representation of this_exp)
Just for the hell of it, I tried moving the assignment out of the
conditional, and something very strange happens.
97 if(cast(conjunction)this_exp) {
98 conjunction exp = cast(conjunction)this_exp;
99 inner_substitutions!(first,conjunction)(exp, map);
100 } else if(cast(disjunction)this_exp) {
101 disjunction exp = cast(disjunction)this_exp;
102 inner_substitutions!(first,disjunction)(exp, map);
103 }
source/cfgparse.d(101): Error: cannot cast [...] to
cfgparse.disjunction at compile time
Both the conditions compile properly, and now only the assignment
fails. Why is this happening and how can I avoid it?
Re: Most basic nothrow, pure, @safe functions?
On Tue, 18 Mar 2014 21:56:54 -0400, Mike Parker aldac...@gmail.com wrote: On 3/19/2014 8:20 AM, Steven Schveighoffer wrote: We all agreed that nothing that assumeSafeAppend did should really throw, and so the pull just used c linkage to add nothrow to an otherwise unmarked function. Does this mean that extern(C) functions are automatically considered nothrow? That is not my current understanding. No, but extern C functions are not mangled. Therefore, the declaration can be nothrow, but the implementation not have that attribute, and linking still works. It's a way to work around the compiler checks. -Steve
Re: A simple sieve in Phobos?
On Wednesday, 19 March 2014 at 01:44:16 UTC, bearophile wrote: Chris Williams: Yeah, several methods work just fine if you change their declaration to isIntegral!T || is(typeof(T) == BigInt). gcd() is one of them. Unfortunately, I don't trust rewriting isIntegral, so this sort of change would need to be on a function-by-function basis. Don explained me that a GCD on BigInts should use a more efficient algorithm. Bye, bearophile There's a couple algorithms on the Wikipedia, but when I profiled them on some -very large- values, they all had similar performance times, including the ones that were just a few lines of simple code. It's possible that there's an optimized variant somewhere on the greater internet, but that might take some hunting to track down. Ultimately, it's probably better to expose functionality in Phobos, even if they're simple implementations. Eventually, some enterprising person will find and implement an optimized version, and in the meantime, everyone has a working, tested version that they didn't have to write nor validate themselves.
Re: Appropriateness of posts
On Wed, 19 Mar 2014 09:07:54 -0400, Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: Of course, if I want get *really* pedantic, I'm not certain if those are actual majorities (ie 50%) or simply just the largest (erm, I mean most numerous) ethnic groups. But I don't want to get that pedantic ;) The word you are looking for is plurality -Steve
Re: Ruby-style each in D?
On Wednesday, 19 March 2014 at 16:46:41 UTC, Dicebot wrote: No, I don't mean iterate with predicate. I mean /dev/null thing. My point is that `range.each!predicate` is much better replaced with `range.tap!predicate.consume`. It keeps general rule of range stuff being lazy and only single exception to bail out of it has very readable clear name. One can argue that consume is same as proposed each with no-op predicate but I think it is very important for readability to keep exceptional behavior (eager consumption) separated from utility behavior (tapping with a predicate). I also proposed this in the thread I linked, but it was also rejected. I remember Andrei saying that consume should really just be reduce called with no predicate, but I think that wouldn't work for some reason...
Re: A simple sieve in Phobos?
On Wednesday, 19 March 2014 at 16:42:43 UTC, Andrei Alexandrescu wrote: Ionno. To me experimental sounds as informative and self-explanatory as it gets, and puts things up for experimentation with the distribution and without requiring users to take special steps. Andrei If it is in Phobos repo, it: - floods Phobos notifications / activity list - gets bug reports into D bugzilla ..except author does not have direct access to it anymore. And if author decides it is not worth pursuing anymore, unsupported module will still be kept in distribution. experimental by definition implies that author is supposed to tinker about it and it needs rapid edit-feedback cycle. You can't get it if put code out of authors control into Phobos. It will be same problem as with Deimos - stuff just rots there. With only exception that you don't need to change C bindings often, contrary to experimental Phobos modules. Also different people have different expectation of experimental stability. Some may think it is something almost fleshed in stone (it is going to be proposed to Phobos after all!) but with occasional tweaks. In practice it is something that can be completely re-written or even disappear by next Phobos release.
Re: Appropriateness of posts
On Monday, 17 March 2014 at 21:01:24 UTC, Andrei Alexandrescu wrote: snip Heh, case in point - there was a gentleman going by Ramon at a point in this forum who flew off the handle taking offense at something I said (no idea what exactly that was). Destroy was the offending expression I believe. Now, why can I remember that, but I have to constantly use Google to look up any programming structure that I use only semi-frequenlty? :o(
Re: Ruby-style each in D?
On 3/19/14, 9:46 AM, Dicebot wrote: On Wednesday, 19 March 2014 at 16:40:24 UTC, Andrei Alexandrescu wrote: On 3/19/14, 9:09 AM, Dicebot wrote: On Wednesday, 19 March 2014 at 16:04:16 UTC, Andrei Alexandrescu wrote: tee is already being discussed -- Andrei On this topic, do we have something like consume in Phobos to eagerly iterate through the supplied range? A default each would do that. Andrei No, I don't mean iterate with predicate. I mean /dev/null thing. So did I - each could take a default alias. -- Andrei
Re: A simple sieve in Phobos?
On 3/19/14, 10:01 AM, Dicebot wrote: I avoid it too but it is my personal problem to deal with. dub is de-facto standard in D tool chain and I am pretty sure eventually will be distributed with dmd. It may be time to look into this. Who wants to champion this effort? -- Andrei
Re: Appropriateness of posts
On 3/19/14, 10:13 AM, Craig Dillabaugh wrote: On Monday, 17 March 2014 at 21:01:24 UTC, Andrei Alexandrescu wrote: snip Heh, case in point - there was a gentleman going by Ramon at a point in this forum who flew off the handle taking offense at something I said (no idea what exactly that was). Destroy was the offending expression I believe. Now, why can I remember that, but I have to constantly use Google to look up any programming structure that I use only semi-frequenlty? :o( Same here. I do remember that wasn't the peak of it. That happened when I tried to explain something as a cultural difference. Probably it was taken as cultural inferiority/superiority. Andrei
Re: A simple sieve in Phobos?
On Wed, 2014-03-19 at 17:01 +, Dicebot wrote: […] I know nothing about OpenGL but it was (and is) huge problem for Java. Well sort of. Calling from Java into any C, C++ or D library can be a bit of a pain, involving JNI (or possibly JNA). JOGL has shown that Java calling OpenGL is doable and works. Likewise JavaFX connects into the OpenGL infrastructure. So this is now essentially a solved problem. What is much more of a problem for Java is GPGPU parallelism. There are a couple of groups working on this and there will be a solution. There has to be as the team members of one of the teams actually have to make it work or start losing money. […] Personally I avoid dub, so to that end I'm probably biased. I avoid it too but it is my personal problem to deal with. dub is de-facto standard in D tool chain and I am pretty sure eventually will be distributed with dmd. SCons currently has no real play in this dependency management area and given that all the support in the D community appears to be for Dub, there seems no point in adding the features to SCons. Gradle has all the dependency management stuff sorted already and now has C and C++ build capability. I wonder if it might be worth adding D support to that? -- 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: Appropriateness of posts
On Wednesday, 19 March 2014 at 17:43:03 UTC, Andrei Alexandrescu wrote: Same here. I do remember that wasn't the peak of it. That happened when I tried to explain something as a cultural difference. Probably it was taken as cultural inferiority/superiority. Andrei Talk about projection...
Re: A simple sieve in Phobos?
On Wednesday, 19 March 2014 at 16:35:15 UTC, Marco Leise wrote: Users who see find it in Phobos will be confused about how experimental exactly it is and what to expect from it. Developers will be confused about what is expected from them maintenance-wise starting from this point and what to do with reported bugs / issues. Why was that never a problem for OpenGL ? I know nothing about OpenGL but it was (and is) huge problem for Java. Don't put stuff which is naturally bleeding edge into scheduled controlled distributions. dub has special category for Phobos proposals, we need to better popularize it. That much is true. Last time I checked it wasn't there. Then again everyone can add categories there. I added two myself. Everyone can tag their package as Phobos candidate. There is no point in implementing moderated category until it is not abused. If it will attract abuse, we will add moderation. But I cannot imagine random packages on dub getting the same exposure as modules included in Phobos. The problem is exactly that those are random package right now. Instead those should be cleanly visible in code.dlang.org interface and possibly also linked from dlang.org main page. Linked from distributed Phobos documentation. Everything should beg user to go and try it. Personally I avoid dub, so to that end I'm probably biased. I avoid it too but it is my personal problem to deal with. dub is de-facto standard in D tool chain and I am pretty sure eventually will be distributed with dmd.
Re: Ruby-style each in D?
On Wednesday, 19 March 2014 at 17:39:16 UTC, Andrei Alexandrescu wrote: So did I - each could take a default alias. -- Andrei We could have saved some time if you have replied directly to my objection to your objection I have foreseen :P (see last part of the comment)
Re: A simple sieve in Phobos?
Chris Williams: Here's a straightforward implementation, if you don't already have one (I assume you're doing this for Rosetta Code). RosettaCode has already several sieves in D. I am not doing this for RosettaCode. What I am doing in this thread is to ask if there's desire for a efficient (quite more than your version) but still sufficiently simple implementation of a unbounded lazy Sieve range for Phobos. Bye, bearophile
Re: A simple sieve in Phobos?
On Tuesday, 18 March 2014 at 14:23:32 UTC, bearophile wrote:
There is a efficient Sieve implementation in C++ here:
http://code.activestate.com/recipes/577966-even-faster-prime-generator/?in=lang-cpp
There are of course far faster implementations, but its
performance is not bad, while being still simple and quite
short.
Here's a straightforward implementation, if you don't already
have one (I assume you're doing this for Rosetta Code). I had to
decrease your MAX_N by 100-fold to get a similar runtime, but
it's a fairly faithful implementation of Eratosthenes' method as
written.
enum uint MAX_N = 10_000_000U;
void calcPrimes() pure nothrow {
uint[][uint] markers;
for (uint L = 2; L MAX_N; L++) {
uint[]* pList = (L in markers);
if (pList is null) {
markers[L + L] = [L];
}
else {
uint[] list = *pList;
size_t len = list.length - 1;
for (uint L2 = 0; L2 len; L2++) {
uint val = list[L2];
markers[ L + val ] ~= val;
}
// reuse the current list for the last item to save
allocations
list[0] = list[len];
list.length = 1;
markers[ L + list[len] ] = list;
}
}
}
void main() {
calcPrimes;
}
Re: A simple sieve in Phobos?
On Wednesday, 19 March 2014 at 18:40:49 UTC, Chris Williams wrote:
enum uint MAX_N = 10_000_000U;
void calcPrimes() pure nothrow {
uint[][uint] markers;
for (uint L = 2; L MAX_N; L++) {
uint[]* pList = (L in markers);
if (pList is null) {
markers[L + L] = [L];
}
else {
uint[] list = *pList;
size_t len = list.length - 1;
for (uint L2 = 0; L2 len; L2++) {
uint val = list[L2];
markers[ L + val ] ~= val;
}
// reuse the current list for the last item to save
allocations
list[0] = list[len];
list.length = 1;
markers[ L + list[len] ] = list;
}
}
}
void main() {
calcPrimes;
}
Well bummer, my quick and easy optimization broke the result for
some reason. Here's a version that actually produces the correct
answers, while I try and debug:
enum uint MAX_N = 10_000_000U;
void calcPrimes() {
uint[][uint] markers;
for (uint L = 2; L MAX_N; L++) {
uint[]* pList = (L in markers);
if (pList is null) {
markers[L + L] = [L];
}
else {
uint[] list = *pList;
for (uint L2 = 0; L2 list.length; L2++) {
uint val = list[L2];
markers[ L + val ] ~= val;
}
}
}
}
void main() {
calcPrimes;
}
Re: Ruby-style each in D?
On Wednesday, 19 March 2014 at 16:40:24 UTC, Andrei Alexandrescu wrote: On 3/19/14, 9:09 AM, Dicebot wrote: On Wednesday, 19 March 2014 at 16:04:16 UTC, Andrei Alexandrescu wrote: tee is already being discussed -- Andrei On this topic, do we have something like consume in Phobos to eagerly iterate through the supplied range? A default each would do that. Andrei No, I don't mean iterate with predicate. I mean /dev/null thing. My point is that `range.each!predicate` is much better replaced with `range.tap!predicate.consume`. It keeps general rule of range stuff being lazy and only single exception to bail out of it has very readable clear name. One can argue that consume is same as proposed each with no-op predicate but I think it is very important for readability to keep exceptional behavior (eager consumption) separated from utility behavior (tapping with a predicate).
Re: Ruby-style each in D?
On Wednesday, 19 March 2014 at 15:55:14 UTC, Dicebot wrote: I would have supported if it was lazy. Not in its proposed form. How would it work in lazy form? Or do you mean the tee we are talking about in the discussion? The fact that it *isn't* lazy is part of the design (AFAIK). I can't see it work without it.
Re: Appropriateness of posts
On Wednesday, 19 March 2014 at 17:43:03 UTC, Andrei Alexandrescu wrote: Same here. I do remember that wasn't the peak of it. That happened when I tried to explain something as a cultural difference. Probably it was taken as cultural inferiority/superiority. Andrei More like feigned idiocy on Ramon's part. There was the whole windoze debacle with him as well. I was never sure if he was here to discuss D or just subtly troll.
Re: A simple sieve in Phobos?
Am Wed, 19 Mar 2014 16:45:45 + schrieb Russel Winder rus...@winder.org.uk: The experimental package was removed from Go once the importing from repositories worked properly. The core had only in it that which had been agreed by the process, nothing experimental. This made everything a lot cleaner. So I think keeping Phobos with only vetted and approved code is a better solution. Wait, what? Because Go has special infrastructure in the compiler front-end that enables it to import directly from repositories like this import ( fmt github.com/user/newmath ) we should also keep experimental modules out of the standard library? Shouldn't we first get this technology? It's a whole different story if the compiler front-end seamlessly downloads missing imports in the background, than if you have to install dub and create a project file first. Besides you are relying on a third party tool you may or may not plan to use for building. Anyways, I just thought an experimental package right in Phobos would be the straight forward way to give the most exposure to new modules that we want tried in the field before inclusion. That's where my vote goes. -- Marco
Re: inlining...
On Wednesday, 19 March 2014 at 12:35:30 UTC, Manu wrote: Okay, do you have use cases for any of this stuff? Are you just making it up, or do you have significant experience to say this is what you need? I don't need anything, I hand optimize prematurely. And I don't want to do that. But yes, inner loops benefits from exhaustive inlining because you get to move common expressions out of the loop or change them to delta increments. It is only when you trash the caches that inlining does not pay off. I do it by hand. I don't want to do it by hand. If you ask me, I have no value in recursive inlining, infact, that would anger me considerably. Why? You could always set the depth to 1, or make 1 the default. And it isn't difficult to implement.
Re: Final by default?
On Monday, 17 March 2014 at 01:05:09 UTC, Manu wrote: Whole program optimisation can't do anything to improve the situation; it is possible that DLL's may be loaded at runtime, so there's nothing the optimiser can do, even at link time. With everything being exported by default, this is true. But should DIP45 be implemented, LTO/WPO will be able to achieve a lot more, at least if the classes in question are not (or not fully) exported.
Re: Cannot cast X to Y at compile time...?
On Wednesday, 19 March 2014 at 16:57:38 UTC, dnspies wrote:
I have a function called at CTFE which includes the lines:
97 if(conjunction exp = cast(conjunction)this_exp) {
98 inner_substitutions!(first,conjunction)(exp, map);
99 } else if(disjunction exp = cast(disjunction)this_exp) {
100 inner_substitutions!(first,disjunction)(exp, map);
101 }
Here, this_exp is a reference of type expression to an object
whose CTFE-runtime-type is of type disjunction. conjunction
and disjunction are both descendent classes of expression.
This code produces the following compilation error:
source/cfgparse.d(97): Error: cannot cast [...] to
cfgparse.conjunction at compile time.
([...] stands in for a very long string which I think is some
sort of representation of this_exp)
Just for the hell of it, I tried moving the assignment out of
the conditional, and something very strange happens.
97 if(cast(conjunction)this_exp) {
98 conjunction exp = cast(conjunction)this_exp;
99 inner_substitutions!(first,conjunction)(exp, map);
100 } else if(cast(disjunction)this_exp) {
101 disjunction exp = cast(disjunction)this_exp;
102 inner_substitutions!(first,disjunction)(exp, map);
103 }
source/cfgparse.d(101): Error: cannot cast [...] to
cfgparse.disjunction at compile time
Both the conditions compile properly, and now only the
assignment fails. Why is this happening and how can I avoid
it?
I ran up to a similar situation when the thing trying to be cast
was not what I thought it was. I.e., the error is exactly what it
means. Try to create a this_exp that is a conjunction explicitly
to see if that is the problem.
Re: Ruby-style each in D?
On Wednesday, 19 March 2014 at 16:46:41 UTC, Dicebot wrote: My point is that `range.each!predicate` is much better replaced with `range.tap!predicate.consume`. It keeps general rule of range stuff being lazy and only single exception to bail out of it has very readable clear name. One can argue that consume is same as proposed each with no-op predicate but I think it is very important for readability to keep exceptional behavior (eager consumption) separated from utility behavior (tapping with a predicate). This. I fully agree.
Re: Proposal for fixing dchar ranges
19-Mar-2014 18:42, Marco Leise пишет: Am Tue, 18 Mar 2014 23:18:16 +0400 schrieb Dmitry Olshansky dmitry.o...@gmail.com: Related: - What normalization do D strings use. Both Linux and MacOS X use UTF-8, but the binary representation of non-ASCII file names is different. There is no single normalization to fix on. D programs may be written for Linux only, for Mac-only or for both. Normalizations C and D are the non lossy ones and as far as I understood equivalent. So I agree. Right, the KC KD ones are really all about fuzzy matching and searching. IMO we should just provide ways to normalize strings. (std.uni.normalize has 'normalize' for starters). I wondered if anyone will actually read up on normalization prior to touching Unicode strings. I didn't, Andrei didn't and so on... So I expect strA == strB to be common enough, just like floatA == floatB until the news spread. If that of any comfort other languages are even worse here. In C++ your are hopeless without ICU. Since == is supposed to compare for equivalence, could we hide all those details in an opaque string type and offer correct comparison functions? Well, turns out the Unicode standard ties equivalence to normalization forms. In other words unless both your strings are normalized the same way there is really no point in trying to compare them. As for opaque type - we could have say String!NFC and String!NFD or some-such. It would then make sure the normalization is the right one. - How do we handle sorting strings? Unicode collation algorithm and provide ways to tweak the default one. I wish I didn't look at the UCA. Jz... But yeah, that's the way to go. Needless to say I had a nice jaw-dropping moment when I realized what elephant I have missed with our std.uni (somewhere in the middle of the work). Big frameworks like Java added a Collate class with predefined constants for several languages. That's too much work for us. But the API doesn't need to preclude adding those. Indeed some kind of Collator is in order. On the use side of things it's simply a functor that compares strings. The fact that it's full of tables and the like is well hidden. The only thing above that is caching preprocessed strings, that maybe useful for databases and string indexes. The topic matter is complex, but not difficult (as in rocket science). If we really want to find a solution, we should form an expert group and stop talking until we read the latest Unicode specs. Well, I did. You seem motivated, would you like to join the group? Yes, I'd like to see a Unicode 6.x approved stamp on D. I didn't know that you already wrote all the simple algorithms for 2.064. Those would have been my candidates to work on, too. Is there anything that can be implemented in a day or two? :) Cool, consider yourself enlisted :) I reckon word and line breaking algorithms are piece of cake compared to UCA. Given the power toys of CodepointSet and toTrie it shouldn't be that hard to come up with prototype. Then we just move precomputed versions of related tries to std/internal/ and that's it, ready for public consumption. D (or any library for that matter) won't ever have all possible tinkering that Unicode standard permits. So I expect D to be done with Unicode one day simply by reaching a point of having all universally applicable stuff (and stated defaults) plus having a toolbox to craft your own versions of algorithms. This is the goal of new std.uni. Sorting strings is a very basic feature, but as I learned now also highly complex. I expected some kind of tables for download that would suffice, but the rules are pretty detailed. E.g. in German phonebook order, ä/ö/ü has the same order as ae/oe/ue. This is tailoring, an awful thing that makes cultural differences what they are in Unicode ;) What we need first and furthermost DUCET based version (default Unicode collation element tables). -- Dmitry Olshansky
Re: Good name for f.byLine.map!(x = x.idup)?
On Wednesday, 19 March 2014 at 13:44:35 UTC, Marco Leise wrote: Am Tue, 18 Mar 2014 09:49:32 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: On 3/18/14, 6:49 AM, Steven Schveighoffer wrote: byStringLines First one I like. Andrei asString(s) byString(s) my 2 cents
Re: Good name for f.byLine.map!(x = x.idup)?
On Sunday, 16 March 2014 at 16:58:36 UTC, Andrei Alexandrescu wrote: A classic idiom for reading lines and keeping them is f.byLine.map!(x = x.idup) to get strings instead of the buffer etc. f.readLines
Re: Proposal for fixing dchar ranges
Am Thu, 20 Mar 2014 01:55:08 +0400 schrieb Dmitry Olshansky dmitry.o...@gmail.com: Well, turns out the Unicode standard ties equivalence to normalization forms. In other words unless both your strings are normalized the same way there is really no point in trying to compare them. As for opaque type - we could have say String!NFC and String!NFD or some-such. It would then make sure the normalization is the right one. And I thought of going the slow route where normalized and unnormalized strings can coexist and be compared. No NFD or NFC, just UTF8 strings. Pros: + Learning about normalization isn't needed to use strings correctly. And few people do that. + Strings don't need to be normalized. Every modification to data is bad, e.g. when said string is fed back to the source. Think about a file name on a file system where a different normalization is a different file. Cons: - Comparisons for already normalized strings are unnecessarily slow. Maybe the normalization form (NFC, NFD, mixed) could be stored alongside the string. Cool, consider yourself enlisted :) I reckon word and line breaking algorithms are piece of cake compared to UCA. Given the power toys of CodepointSet and toTrie it shouldn't be that hard to come up with prototype. Then we just move precomputed versions of related tries to std/internal/ and that's it, ready for public consumption. Would a typical use case be to find the previous/next boundary given a code unit index? E.g. the cursor sits on a word and you want to jump to the start or end of it. Just iterating the words and lines might not be too useful. D (or any library for that matter) won't ever have all possible tinkering that Unicode standard permits. So I expect D to be done with Unicode one day simply by reaching a point of having all universally applicable stuff (and stated defaults) plus having a toolbox to craft your own versions of algorithms. This is the goal of new std.uni. Sorting strings is a very basic feature, but as I learned now also highly complex. I expected some kind of tables for download that would suffice, but the rules are pretty detailed. E.g. in German phonebook order, ä/ö/ü has the same order as ae/oe/ue. This is tailoring, an awful thing that makes cultural differences what they are in Unicode ;) What we need first and furthermost DUCET based version (default Unicode collation element tables). Of course. -- Marco
Re: Appropriateness of posts
On 3/19/2014 12:43 PM, Meta wrote: There was the whole windoze debacle with him as well. The windoze thing was tired and old in 1990. So was Micro$oft.
Re: Appropriateness of posts
On 19 March 2014 19:43, Meta jared...@gmail.com wrote: On Wednesday, 19 March 2014 at 17:43:03 UTC, Andrei Alexandrescu wrote: Same here. I do remember that wasn't the peak of it. That happened when I tried to explain something as a cultural difference. Probably it was taken as cultural inferiority/superiority. Andrei More like feigned idiocy on Ramon's part. There was the whole windoze debacle with him as well. I was never sure if he was here to discuss D or just subtly troll. Oh, *that* Ramon. I was trying to remember who he was. :-) I seem to recall people being rather unfairly direct towards him on that, which in turn made the quality of his responses drop tenfold. Though I'm biased, I think my initial response to him was subtle, fair and justified. If he continues to blindly ignore expressed wishes on netiquette, then simply don't response - or *do* respond, but save it in your drafts. ;-)
Re: Ruby-style each in D?
On 3/19/2014 8:06 AM, Andrei Alexandrescu wrote: Pros and cons are already being discussed. Destroy! I don't have a solid enough experience with this style of programming, but one opportunity of 'each' could be that it could be specialized and achieve greater speed for some arguments.
Re: Ruby-style each in D?
On 3/19/2014 8:55 AM, Dicebot wrote: I would have supported if it was lazy. Not in its proposed form. Also if it is implicitly parallelizable or not, i.e. are there traversal order dependencies?
Re: Appropriateness of posts
On Wed, Mar 19, 2014 at 10:41:26PM +, Iain Buclaw wrote: On 19 March 2014 19:43, Meta jared...@gmail.com wrote: On Wednesday, 19 March 2014 at 17:43:03 UTC, Andrei Alexandrescu wrote: Same here. I do remember that wasn't the peak of it. That happened when I tried to explain something as a cultural difference. Probably it was taken as cultural inferiority/superiority. Andrei More like feigned idiocy on Ramon's part. There was the whole windoze debacle with him as well. I was never sure if he was here to discuss D or just subtly troll. Oh, *that* Ramon. I was trying to remember who he was. :-) I seem to recall people being rather unfairly direct towards him on that, which in turn made the quality of his responses drop tenfold. Though I'm biased, I think my initial response to him was subtle, fair and justified. If he continues to blindly ignore expressed wishes on netiquette, then simply don't response - or *do* respond, but save it in your drafts. ;-) I had quite a few responses to him that sat in the =postponed file that eventually I deleted, because I realized that it would only set him off even more. Sometimes, the only way to win is to not play. T -- Try to keep an open mind, but not so open your brain falls out. -- theboz
Re: Good name for f.byLine.map!(x = x.idup)?
On Wednesday, 19 March 2014 at 22:30:55 UTC, Peter Alexander wrote: On Sunday, 16 March 2014 at 16:58:36 UTC, Andrei Alexandrescu wrote: A classic idiom for reading lines and keeping them is f.byLine.map!(x = x.idup) to get strings instead of the buffer etc. f.readLines What about a simpler f.iter() or f.lineIter()?
Re: Good name for f.byLine.map!(x = x.idup)?
On 3/19/14, 4:53 PM, Meta wrote: On Wednesday, 19 March 2014 at 22:30:55 UTC, Peter Alexander wrote: On Sunday, 16 March 2014 at 16:58:36 UTC, Andrei Alexandrescu wrote: A classic idiom for reading lines and keeping them is f.byLine.map!(x = x.idup) to get strings instead of the buffer etc. f.readLines What about a simpler f.iter() or f.lineIter()? Ideally it would be a variation of byLine. -- Andrei
Re: inlining...
On 20 March 2014 06:23, 7d89a89974b0ff40.invalid@internationalized.invalidwrote: On Wednesday, 19 March 2014 at 12:35:30 UTC, Manu wrote: Okay, do you have use cases for any of this stuff? Are you just making it up, or do you have significant experience to say this is what you need? I don't need anything, I hand optimize prematurely. And I don't want to do that. But yes, inner loops benefits from exhaustive inlining because you get to move common expressions out of the loop or change them to delta increments. It is only when you trash the caches that inlining does not pay off. I do it by hand. I don't want to do it by hand. If you ask me, I have no value in recursive inlining, infact, that would anger me considerably. Why? You could always set the depth to 1, or make 1 the default. And it isn't difficult to implement. The problem is upside down. If you want to inline multiple levels, you start from the leaves and move downwards, not from the root moving upwards (leaving a bunch of leaves perhaps not inlined), which is what you're really suggesting. Inlining should be strictly deliberate, there's nothing to say that every function called in a tree should be inlined. There's a high probability there's one/some that shouldn't be among a few that should. Remember too, that call-site inlining isn't the only method, there would also be always-inline. I think always-inline is what you want for some decidedly trivial functions (although these will probably be heuristically inlined anyway), not call-site inlining. I just don't see how recursive call-site inlining is appropriate, considering that call trees are often complex, subject to change, and may even call functions that you don't have source for. You can cascade the mixin keyword if you want to, that's very simple. I'd be highly surprised if you ever encountered a call tree where you wanted to inline everything (and the optimiser didn't do it for you). As soon as you encounter a single function in the tree that shouldn't be inlined, then you'll be forced to do it one level at a time anyway.
Re: Possible change to array runtime?
On Sunday, March 16, 2014 13:14:15 Joseph Rushton Wakeling wrote: Problem is, this still seems like safety-by-programmer-virtue. It's far too easy to write .length = 0 casually and without any attention to consequences one way or the other. Isn't the whole point of the requirement to use assumeSafeAppend that it really forces the user to say, Yes, I want to do away with the contents of the array and I take full responsibility for ensuring there's nothing else pointing to it that will break ... ? I must say that personally I'd rather have the safety-by-default and the obligation to write assumeSafeAppend (or use Appender!T) where performance needs it, than risk code breaking because someone's function accidentally throws away stuff that I still had a slice of. I tend to agree with this. Setting an array's length to 0 with the expectation that you will then reuse that memory is inherently unsafe. What if there are other arrays still referring to the same data? They'll be stomped, which could do some very nasty things - especially if we're talking about structs rather than strings. assumeSafeAppend is explicitly unsafe and makes it clear what you're doing, whereas while setting an array's length to 0 may be generally nonsensical if you're not intending to reuse the memory again, having that essentially call assumeSafeAppend for you could result in very pernicious bugs when someone is foolish enough to set an array's length to 0 when they still have other slices to some or all of that array. I really think that the assumeSafeAppend needs to be explicit. - Jonathan M Davis
Re: Possible change to array runtime?
On Friday, March 14, 2014 14:50:43 Dicebot wrote: It has not been mentioned as example of blocker but example of most horrible breaking change that can happen if dmd user is not aware of it before upgrade. I think only practical thing that blocks D2 transition right now is that no one can afford to work on it full-time and amount of changes needed is too big to be done as a side work - array stomping is not only problematic area, I personally think const will cause much more problems. Really hope that with recent hires doing a focused porting effort will soon become a real option. D1 is so D1 :P Just a thought for this particular case. You could write a clearForAppend for D1 which simply sets the array length to 0 and slowly change your current code to use that instead of setting the array length to 0 directly. Then when you do go to port to D2, you can simply change clearForAppend's behavior so that it also calls assumeSafeAppend. That would allow you to do this particular change as a side project rather than focusing on it full time, which obviously isn't enough on its own, but it could help. - Jonathan M Davis
Why does the following program write the message 'Foo' twice?
Why does the following program write the message 'Foo' twice?
void main(string[] args)
{
pragma(msg, Foo);
}
