Re: DConf 2015 livestreaming day 1: post feedback here
On Wednesday, 4 May 2016 at 15:26:18 UTC, Vladimir Panteleev wrote: On Thursday, 28 May 2015 at 00:54:30 UTC, Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei Just a FYI to everyone posting in this thread, this thread was originally posted in 2015, and the first 7 posts were regarding DConf 2015. Thanks for pointing that out :) :)
Re: DConf 2015 livestreaming day 1: post feedback here
On Thursday, 28 May 2015 at 00:54:30 UTC, Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei The chat for UStream is sporadic and mostly broken. I wanted to ask Steven a question and I don't have a twitter, so I wanted to use the integrated chat, but it had serious problems loading. Once it did load, when I posted something it would tell me my post failed to be sent. My question for Steve: "Can I use inout to make a length function for a range that is automatically const if the underlying data/range's length function is const? It would need to go all the way down for composed ranges."
Re: DConf 2015 livestreaming day 1: post feedback here
On Thursday, 28 May 2015 at 00:54:30 UTC, Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei Just a FYI to everyone posting in this thread, this thread was originally posted in 2015, and the first 7 posts were regarding DConf 2015.
Re: DConf 2015 livestreaming day 1: post feedback here
On Thursday, 28 May 2015 at 00:54:30 UTC, Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei I don't know if it's the camera or the streaming site you're using, but having the stream in standard definition kind of sucks. Not a huge problem but it would be nice if it was in HD.
Re: DConf 2015 livestreaming day 1: post feedback here
On Thursday, 28 May 2015 at 00:54:30 UTC, Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei There should be a prominent link on the dconf website http://dconf.org/2016/index.html The Chat function does not work for me, but our IRC channel is a good substitute. Make the slides available beforehand. E.g. the fonts in Watson's slides was too small to read. Thanks for making streaming possible! Enables me to participate at least a little.
Re: DConf 2015 livestreaming day 1: post feedback here
On Thursday, 28 May 2015 at 00:54:30 UTC, Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei Relevant post at Reddit : https://www.reddit.com/r/programming/comments/4hti33/dconf_2016_is_streaming_right_now/
Re: DConf 2015 livestreaming day 1: post feedback here
On Thursday, 28 May 2015 at 03:17:20 UTC, Rikki Cattermole wrote: On 28/05/2015 12:54 p.m., Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei Just a thought, livecoding.tv would be interested in hosting a live stream for e.g. a conference. Declaration: I've been live streaming there since February! If people are having issues viewing the live stream on Android devices please refer to this Tweet: https://twitter.com/DLangConf/status/727791188368035840 Apologies for any inconvenience! Keep sending Dicebot your feedback! ;)
Re: Dconf 2015 talks...
On Monday, 8 February 2016 at 19:46:19 UTC, Joseph Rushton Wakeling wrote: [snip] This might be a stupid idea, but perhaps there's something useful in it: Determinism isn't the same thing as "one long chain of numbers that everybody reads from". It can be acceptable to seed a set of reasonable pseudo-random number generators with consecutive integers (indeed seeding randomly can be dangerous because of the birthday problem). More generally, any change of the state of the rng in "seed-space" should produce an output equivalent to taking a sample from the output distribution. Can you not have a random number generator make a copy of itself like this: struct RNG { State state; static State.ModifierT modifier; this(this) { this.state.alterBy(modifier++); //recalculate output sample etc... } } Then any time you copy a RNG, the copy is kicked on to a new path in state-space. Basically we're deterministically re-seeding on copy.
Re: Dconf 2015 talks...
On Monday, 8 February 2016 at 00:54:24 UTC, Era Scarecrow wrote: Either they use more stack space, or they act normally after their call is done and are deallocated normally (automatically, unless they are passed outside of the scope where they were generated). It's that "passed outside of the scope where they were generated" that is bothering me. Consider: auto foo (Range) (Range r) if (isInputRange!Range) { return r.randomSample(100).take(10); } void main () { iota(1000).foo.writeln; } If the RandomSample internals are allocated on the stack using the technique you propose, what's going to happen here? True; Perhaps have one RNG for seeding and one RNG for passing, then reseed after passing the function off, although how far deep some of this could go with it's deeper copying; I don't know. No, I really don't think that's an approach that's worth pursuing, except as a desperate workaround for the faults of the existing design. RNGs should as much as possible "just work" and the user shouldn't have to concern themselves like this with Perhaps RNG should be a class outright, which probably removes a lot of these problems. It does indeed give you the desired reference semantics very cheaply. But now suppose you have lots of RandomSamples being instantiated in the inner loop of your program. If _they_ are also a class, how do you handle their instantiation and deallocation?
Re: Dconf 2015 talks...
On Sunday, 7 February 2016 at 22:27:40 UTC, Joseph Rushton Wakeling wrote: On Monday, 25 January 2016 at 22:06:31 UTC, Era Scarecrow wrote: What you describe makes sense, but I don't quite follow what you mean in one particular case: Technically alloca simply returns the current sp, then adds to it the number of bytes you requested. This means you have to run it at the function stack where you want to use it (and not in a called function, otherwise corruption). So inlined functions where alloca's data would remain would be a must. That's the low level assembly language that's generated i'm referring to; At least based on what i've read and seen for code output from a compiler to a .s file or similar. I don't quite follow your remark about inlined functions; do you mean that the function where the RNG instance is generated must be inlined? (That would make sense in order to avoid the internal state being deallocated immediately.) Assuming alloca moves to the inlined function. Although i had another idea thrown in my head where the memory would be pre-allocated and you could just point to it when requested via an allocator. So assume @alloca(sizeof(int)) struct RNG { During instantiation it would know the size ahead of time and just append that to the end of the structure. That extra padding space could be handled manually instead. this(int seed) { state = cast(void*)(this+1); } But this forced type breaking is quite clunky (and obviously the wrong way to write it). I recall in C there was suppose to be a way to attach an array (of unknown size) immediately following a struct by making the length of the array 0, then accessing it directly. But you'd still need to guarantee somehow that the access rights are in place and not referencing other data which you could screw up (via optimizations or something). I think there might be more complications here than just allocating individual RNG instances, though (which can happen quite early on in the program); what about stuff like random algorithms (RandomCover, RandomSample) which might be generated deep in internal loops, passed to other functionality as rvalues, etc. etc.? Either they use more stack space, or they act normally after their call is done and are deallocated normally (automatically, unless they are passed outside of the scope where they were generated). It might be simpler, in practice, to just have the state refcounted. I suppose the alternate is an option to skip/throw-away some numbers that should've been consumed I'm not sure I follow what you mean here or why you think this would work? Could you give a concrete example? void skip(int x) {assert(x>0); while(x--) popfront();} rnd.take(10).writeln; //loosely based on talk examples rnd.skip(10); //skips the 'consumed' numbers. rnd.take(10).writeln; //won't have identical output I'm afraid that's not really viable :-( But the problem is, in the general case, you can't anticipate how many random variates may be popped from your random number generator inside a function. True; Perhaps have one RNG for seeding and one RNG for passing, then reseed after passing the function off, although how far deep some of this could go with it's deeper copying; I don't know. Perhaps RNG should be a class outright, which probably removes a lot of these problems.
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 22:06:31 UTC, Era Scarecrow wrote: On Monday, 25 January 2016 at 21:22:13 UTC, Joseph Rushton Wakeling wrote: I have been wondering about how allocators could help to deal with these problems. Could you put forward a minimal example of how you would see it working? Most likely alloca would have to be built into the compiler. Here's a crash course in how the stack memory management works. sp=stack pointer, bp=base pointer (more relevant pre 386). Apologies for the delay in writing back about this. What you describe makes sense, but I don't quite follow what you mean in one particular case: Technically alloca simply returns the current sp, then adds to it the number of bytes you requested. This means you have to run it at the function stack where you want to use it (and not in a called function, otherwise corruption). So inlined functions where alloca's data would remain would be a must. I don't quite follow your remark about inlined functions; do you mean that the function where the RNG instance is generated must be inlined? (That would make sense in order to avoid the internal state being deallocated immediately.) I think there might be more complications here than just allocating individual RNG instances, though (which can happen quite early on in the program); what about stuff like random algorithms (RandomCover, RandomSample) which might be generated deep in internal loops, passed to other functionality as rvalues, etc. etc.? Then it comes down to a simple: [code] struct RNG { int *state; //add assert to functions that this isn't null this(int seed) { state = alloca(sizeof(int)); *state = seed; } } [/code] Yes, missing your understanding of the details of how it would have to happen, this is pretty much what I had in mind for random ranges; a pointer to internal state nevertheless allocated on the stack. But the already-mentioned concerns about some of the ways that stack could be deallocated make for some concerns. It might be simpler, in practice, to just have the state refcounted. I suppose the alternate is an option to skip/throw-away some numbers that should've been consumed (assuming you want to keep using the same seed), or seeding each per use. I'm not sure I follow what you mean here or why you think this would work? Could you give a concrete example? certainly. [code] struct RNG { ... void skip(int x) {assert(x>0); while(x--) popfront();} } RNG rnd = RND(seed); rnd.take(10).writeln; //loosely based on talk examples rnd.skip(10); //skips the 'consumed' numbers. rnd.take(10).writeln; //won't have identical output [/code] I'm afraid that's not really viable :-( In the best case, it's just working around the fundamental design problem via programmer virtue. But the problem is, in the general case, you can't anticipate how many random variates may be popped from your random number generator inside a function (it might depend on other input factors over which you as programmer have no control).
Re: Dconf 2015 talks...
On Tuesday, 26 January 2016 at 12:07:59 UTC, Andrei Alexandrescu wrote: I think a pseudo-rng as a forward range is useful. It's good in testing and experimentation to fork a sequence of pseudo-random numbers, turn the clock back, etc. Essentially I see no harm in it; it's always easy to make a forward range into an input range, it's the opposite that's hard. -- Andrei Yes, but there are other ways to fork that sequence that don't involve implementing the .save primitive. That's why in my talk (and here) I distinguish between the .save primitive versus some other possible primitive -- say, .dup -- whose promise is, "You can use me to duplicate the state of this range, but you must use me carefully and in an appropriate context." This is important, because if you just define pseudo-RNGs as forward ranges, most people won't read the small print about when you need to wrap it in an input range (which is pretty much any time you want to pass it into phobos code and have it behave like an actual source of randomness). As a result, they'll get unintended and possibly unnoticed statistical correlations -- annoying for something like a computer game, possibly a serious consequence if occurring in something like a research simulation.
Re: Dconf 2015 talks...
On 01/26/2016 02:07 AM, Joseph Rushton Wakeling wrote: On Monday, 25 January 2016 at 23:34:56 UTC, Andrei Alexandrescu wrote: I see no problem with adding a category of rngs that are not forward. Naming is of course the hardest problem in our community :o). A good stard would be a /dev/random wrapper. -- Andrei It's not about different categories of RNG in this case -- really, NO RNGs should be forward ranges. I think a pseudo-rng as a forward range is useful. It's good in testing and experimentation to fork a sequence of pseudo-random numbers, turn the clock back, etc. Essentially I see no harm in it; it's always easy to make a forward range into an input range, it's the opposite that's hard. -- Andrei
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 23:37:25 UTC, Andrei Alexandrescu wrote: On 01/25/2016 05:05 PM, Joseph Rushton Wakeling wrote: One option would be to implement the basic RNG data structor à la C++, as a functor That's semantically the same as an input range. -- Andrei “Yes, but...” :-P There are actually some interesting subtleties required for the input range design, not just for RNGs but for ANY range whose elements are generated randomly. I will try and write this up properly later, but the TL;DR is, it involves doing extra work to ensure every element is _truly_ lazily evaluated. To some extent, splitting into functor and range wrapper can help clarify the code design there (even if the functor stays hidden as an implementation detail).
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 23:34:56 UTC, Andrei Alexandrescu wrote: I see no problem with adding a category of rngs that are not forward. Naming is of course the hardest problem in our community :o). A good stard would be a /dev/random wrapper. -- Andrei It's not about different categories of RNG in this case -- really, NO RNGs should be forward ranges. If ONLY it was just a naming problem... :-(
Re: Dconf 2015 talks...
On 01/25/2016 05:05 PM, Joseph Rushton Wakeling wrote: One option would be to implement the basic RNG data structor à la C++, as a functor That's semantically the same as an input range. -- Andrei
Re: Dconf 2015 talks...
On 01/25/2016 04:20 PM, Joseph Rushton Wakeling wrote: I thought that too, for a long time, but I came to the conclusion it's not the case. I see no problem with adding a category of rngs that are not forward. Naming is of course the hardest problem in our community :o). A good stard would be a /dev/random wrapper. -- Andrei
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 22:06:31 UTC, Era Scarecrow wrote: Most likely alloca would have to be built into the compiler. Here's a crash course in how the stack memory management works. sp=stack pointer, bp=base pointer (more relevant pre 386). An apology in advance: I have an early start tomorrow, and a busy few days coming up, so I probably won't be able to follow up on this discussion until the weekend. In the meantime, thanks for the food for thought. I'll try to be in touch about this topic soon :-)
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 21:30:47 UTC, Era Scarecrow wrote: So in short, the RNG shouldn't be a range at all. Of course it could be a struct (for sanity and other reasons), but not a range. I wonder then, assuming we remove RNG from being a range, the a RNG could give out a delegate of it's current data, and that delegate get passed to a range-like wrapper? Or maybe the RNG returns a Voldemort range that referrs to the original RNG which isn't a range anymore... Actually that sounds promising. Aliasing could deal with it automatically converting/creating the range. Well, an idea that was suggested to me at DConf (by several people; thanks in particular to Steve S. and to DiceBot!) was indeed to separate RNG state from the range interface, and to disable copy-by-value for the state data structure. One option would be to implement the basic RNG data structor à la C++, as a functor: so it'd be something like: struct SomeRNG(UIntType, ...) { private: // the RNG state variables public: UIntType opCall() { // returns a random variate } } ... and again, you'd disable copy-by-value for this entity. I had some fun a while ago playing with this and the appropriate technique to wrap it into a range (it's not as trivial as you think, because you need to use some tricks to ensure truly lazy evaluation of the range, where D ranges typically evaluate the first element eagerly). Where I ran into trouble was considering how to extend this approach in a viable way to stuff like randomSample, i.e. the stuff which wraps randomness, which also needs to ensure its internal state is never copied by value, and yet which needs (ideally) to fit nicely into a UFCS chain of ranges: someInput.filter!(WHATEVER).randomSample(n, rng).map!(...).writeln; I suppose it might be possible to implement a functor-based approach for this, that could be wrapped in a range, but it feels nasty for something which really ought to fit more naturally into the range syntax: a random sample is just an algorithm (similar to those in std.algorithm), but one whose elements need to be truly lazily evaluated and whose values are not deterministic but depend on a source of randomness. The entire complication comes out of the fact that in order to play nice in a statistical sense, you need the RandomSample range to be a reference type, but in order to play nice with the kind of in-the-middle-of-the-inner-loop use above, you need it to be cheap and quick to instantiate and destroy (so classes and heap allocation are a problem). Basically, what you probably want is for RandomSample to be a struct, but with a reference-type internal state that is nevertheless allocated on the stack and that is cheap to create and let go of when you're done with it.
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 21:22:13 UTC, Joseph Rushton Wakeling wrote: On Monday, 25 January 2016 at 20:26:12 UTC, Era Scarecrow wrote: What about an alternative allocator? Specifically I'm thinking in C's equivalent which is alloca (allocates directly on the stack with the rest of the variables). If the constructor is a function then that won't work; but if it's inlined then it should work. I have been wondering about how allocators could help to deal with these problems. Could you put forward a minimal example of how you would see it working? Most likely alloca would have to be built into the compiler. Here's a crash course in how the stack memory management works. sp=stack pointer, bp=base pointer (more relevant pre 386). When you prepare to enter a function (or block) the bp register is backed up, the sp is saved in the bp register, then you add your arguments, then the function is entered. After the function is entered it adds to the sp register which give it a block of space for all known local variables at once; then does any assignments it needs to. When you leave the function/block you simply replace the sp register with your backup the bp register. Once you return you restore the old bp register. So something close to this: [code] ... push bp push calling_argument(s) call func sub sp, -N //size of total arguments pushed pop bp //completely done with function call. ... func: mov bp, sp add sp, +N //size of local variables // setup variables // code // cleanup/return mov sp, bp ret [/code] Technically alloca simply returns the current sp, then adds to it the number of bytes you requested. This means you have to run it at the function stack where you want to use it (and not in a called function, otherwise corruption). So inlined functions where alloca's data would remain would be a must. Then it comes down to a simple: [code] struct RNG { int *state; //add assert to functions that this isn't null this(int seed) { state = alloca(sizeof(int)); *state = seed; } } [/code] I suppose the alternate is an option to skip/throw-away some numbers that should've been consumed (assuming you want to keep using the same seed), or seeding each per use. I'm not sure I follow what you mean here or why you think this would work? Could you give a concrete example? certainly. [code] struct RNG { ... void skip(int x) {assert(x>0); while(x--) popfront();} } RNG rnd = RND(seed); rnd.take(10).writeln; //loosely based on talk examples rnd.skip(10); //skips the 'consumed' numbers. rnd.take(10).writeln; //won't have identical output [/code]
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 21:30:47 UTC, Era Scarecrow wrote: On Monday, 25 January 2016 at 21:20:09 UTC, Joseph Rushton Wakeling wrote: Right -- non-PRNGs must be input ranges by design. I came to the conclusion that pseudo-RNGs need to be input ranges, but that implement an alternative to .save: a .dup method whose promise is, "You can duplicate the state and hence behaviour of this range, but you can't make any assumptions that this is a safe or sane thing to do." So in short, the RNG shouldn't be a range at all. Of course it could be a struct (for sanity and other reasons), but not a range. Why? They work fine as input ranges regardless of whether having them be forward ranges make sense. By its very nature, an input range cannot be saved, and it's not assumed that it's deterministic. The issue that we run into isn't that they're ranges but that they're not implemented as reference types, and copies of them accidentally get used, resulting in subtle bugs. But I'd strongly argue that we should at least consider requiring that all input ranges be reference types, since they don't make sense as value types, and pseudo-reference types are just plain buggy. That's a wider discussion than random number generator ranges though. - Jonathan M Davis
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 21:20:09 UTC, Joseph Rushton Wakeling wrote: I thought that too, for a long time, but I came to the conclusion it's not the case. That's fine if you're dealing with something whose behaviour is meant to be deterministic, but if you call this with a pseudo-random sequence, than every time you call it, you will get the same result. It won't matter if what you pass is a reference-type -- the .save (which is correct behaviour for handling a forward range) means you're just repeatedly using a copy of the random sequence. Right -- non-PRNGs must be input ranges by design. I came to the conclusion that pseudo-RNGs need to be input ranges, but that implement an alternative to .save: a .dup method whose promise is, "You can duplicate the state and hence behaviour of this range, but you can't make any assumptions that this is a safe or sane thing to do." So in short, the RNG shouldn't be a range at all. Of course it could be a struct (for sanity and other reasons), but not a range. I wonder then, assuming we remove RNG from being a range, the a RNG could give out a delegate of it's current data, and that delegate get passed to a range-like wrapper? Or maybe the RNG returns a Voldemort range that referrs to the original RNG which isn't a range anymore... Actually that sounds promising. Aliasing could deal with it automatically converting/creating the range.
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 18:40:59 UTC, Jonathan M Davis wrote: As long as the numbers are pseudo-random, then in theory, there's no problem with a range of random numbers being a forward range. I thought that too, for a long time, but I came to the conclusion it's not the case. Here's the essence of the problem: a forward range is a promise to the code that uses it, "I am a deterministic sequence." But the whole point of pseudo-random sequences is that you're not supposed to be able to tell them from actual randomness. If you _tell_ downstream code "I am deterministic", that code may make assumptions about how it can use you, that are valid for "normal" deterministic sequences, but aren't valid for what are supposedly random sequences. Consider the typical handling of forward ranges: auto foo (R) (R range) if (isForwardRange!R) { auto rcopy = range.save; // do something with rcopy } That's fine if you're dealing with something whose behaviour is meant to be deterministic, but if you call this with a pseudo-random sequence, than every time you call it, you will get the same result. It won't matter if what you pass is a reference-type -- the .save (which is correct behaviour for handling a forward range) means you're just repeatedly using a copy of the random sequence. That could be useful upon occasion (similar to how it can be useful that the same seed results in the same sequence of numbers). Right, but the point is that re-use of a pseudo-random sequence should happen at programmer request only, not under the hood in library code they call -- which is what unfortunately happens if you implement RNGs and other random sequences as forward ranges :-( The problem is that if they're a forward range, then you tend to get code that accidentally ends up reusing numbers in the sequence and that definitely is a problem. So ultimately, they probably should be input ranges rather than forward ranges, but I think that it's more of an issue with human error than with what makes sense from a technical perspective. Again, I thought that too, but I came to the conclusion that I'd been wrong. It's not about fallible humans, it's about the promise a forward range makes. Superficially, it looks like that promise is: "You can use my deterministic nature if you need to." But actually, I think it is really something stronger: "You can use my deterministic nature freely and nothing will go wrong in doing so." That's a much stronger promise than can be allowed for a pseudo-RNG, and I think it's borne out in the way in which e.g. phobos functionality makes use of forward ranges. Regardless, non-pseudo random number generators obviously can't be forward ranges though, since their state isn't savable or repeatable. Right -- non-PRNGs must be input ranges by design. I came to the conclusion that pseudo-RNGs need to be input ranges, but that implement an alternative to .save: a .dup method whose promise is, "You can duplicate the state and hence behaviour of this range, but you can't make any assumptions that this is a safe or sane thing to do."
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 20:26:12 UTC, Era Scarecrow wrote: What about an alternative allocator? Specifically I'm thinking in C's equivalent which is alloca (allocates directly on the stack with the rest of the variables). If the constructor is a function then that won't work; but if it's inlined then it should work. I have been wondering about how allocators could help to deal with these problems. Could you put forward a minimal example of how you would see it working? I suppose the alternate is an option to skip/throw away some numbers that should've been consumed (assuming you want to keep using the same seed), or seeding each per use. I'm not sure I follow what you mean here or why you think this would work? Could you give a concrete example?
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 17:19:05 UTC, Joseph Rushton Wakeling wrote: Implementing the random algorithms/other wrappers as a class is problematic because then you get into the hassle of potentially having to new/free a lot of individual heap objects deep in the inner loop of your program. I already tried this in hap.random, and came to the conclusion that it wasn't a valid approach. What about an alternative allocator? Specifically I'm thinking in C's equivalent which is alloca (allocates directly on the stack with the rest of the variables). If the constructor is a function then that won't work; but if it's inlined then it should work. I suppose the alternate is an option to skip/throw away some numbers that should've been consumed (assuming you want to keep using the same seed), or seeding each per use.
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 17:19:05 UTC, Joseph Rushton Wakeling wrote: On Monday, 25 January 2016 at 15:38:45 UTC, Era Scarecrow wrote: Hmm i wonder... If recognizes it as infinite, could it avoid treating them as forward ranges? As a struct it still wouldn't work, but as a class/reference type it would work then... They shouldn't be forward ranges anyway, because if their content is randomly generated then it's not legit for them to implement the .save property. The whole implementation of stuff in std.random via forward ranges is a massive design mistake. As long as the numbers are pseudo-random, then in theory, there's no problem with a range of random numbers being a forward range. That could be useful upon occasion (similar to how it can be useful that the same seed results in the same sequence of numbers). The problem is that if they're a forward range, then you tend to get code that accidentally ends up reusing numbers in the sequence and that definitely is a problem. So ultimately, they probably should be input ranges rather than forward ranges, but I think that it's more of an issue with human error than with what makes sense from a technical perspective. Regardless, non-pseudo random number generators obviously can't be forward ranges though, since their state isn't savable or repeatable. - Jonathan M Davis
Re: Dconf 2015 talks...
BTW, I apologize for the rather terse replies so far; busy day :-) I'll try and write out a more complete summary of the problem at some point in the near future (though it might have to wait 'til the weekend). Thanks for the interest in contributing to solving this problem :-)
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 15:38:45 UTC, Era Scarecrow wrote: Hmm i wonder... If recognizes it as infinite, could it avoid treating them as forward ranges? As a struct it still wouldn't work, but as a class/reference type it would work then... They shouldn't be forward ranges anyway, because if their content is randomly generated then it's not legit for them to implement the .save property. The whole implementation of stuff in std.random via forward ranges is a massive design mistake. Implementing the random algorithms/other wrappers as a class is problematic because then you get into the hassle of potentially having to new/free a lot of individual heap objects deep in the inner loop of your program. I already tried this in hap.random, and came to the conclusion that it wasn't a valid approach.
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 14:31:12 UTC, Joseph Rushton Wakeling wrote: It's all the functionality that _wraps_ RNGs, such as random algorithms like randomCover and randomSample, or a D equivalent of C++'s random distributions. These need to also be reference types (for their internal state as well as the RNG they wrap), and here it gets very tricky to avoid nasty situations with lots of allocations and frees (when ideally, you'd like stuff like this to be stack only). Hmm i wonder... If recognizes it as infinite, could it avoid treating them as forward ranges? As a struct it still wouldn't work, but as a class/reference type it would work then...
Re: Dconf 2015 talks...
On Monday, 25 January 2016 at 13:05:46 UTC, Era Scarecrow wrote: Finally getting around to watching all the talks, all good stuff :) Figured I'd make a thread talking about things I came across and perhaps get into a discussion on them in detail. Anyways I'm watching the talk with Joseph Wakeling involving RNG and I wonder, is that still a problem or not? It's still an issue, at least partly because amid all other things in life, I haven't had much opportunity to sit down and focus on it :-( I ask since the simplest and most correct thing I can think of is to use the heap for a referenced state, and dup would then duplicate the state properly while otherwise the RNG problems go away that most of the talk went on about. It's possible I've been out of the loop and this has already been solved. Not sure yet, I haven't looked closely at any of the sources or the language updates. So... time for some rusty D prototyping. [code] struct RNG { int* state; this(int seed) { state = new int; *state = seed; } //if you provide a pointer, we don't rely on the heap/gc at all... //maybe a small stack based allocator could be useful for this? this(int* seed) { state = seed; } //dup instead of save, so it's not a forward range RNG dup() { return RNG(*state); } //popfront, front & empty as expected } [/code] The major problems are not so much with RNGs per se (note that your approach can actually be much more nicely implemented as a final class). It's all the functionality that _wraps_ RNGs, such as random algorithms like randomCover and randomSample, or a D equivalent of C++'s random distributions. These need to also be reference types (for their internal state as well as the RNG they wrap), and here it gets very tricky to avoid nasty situations with lots of allocations and frees (when ideally, you'd like stuff like this to be stack only). Don't even ask about how complicated a `.dup` method gets when you start trying to extend to such entities. :-(
Re: Dconf 2015 talks...
Main problem is with both making it @safe and avoid unforced allocations (i.e. allowing shared state to be kept on stack of `main`).
Re: DConf 2015 Video
On Sunday, 14 June 2015 at 14:27:57 UTC, Andrei Alexandrescu wrote: On 6/14/15 5:42 AM, Frank Fuente wrote: Any news of the release date for the video from DConf 2015? Got word from Chuck that they've had an urgent project until now. They're starting working on the videos this week and will make them available one by one as each is ready. -- Andrei Excellent. That's great news.
Re: DConf 2015 Video
On 6/14/15 5:42 AM, Frank Fuente wrote: Any news of the release date for the video from DConf 2015? Got word from Chuck that they've had an urgent project until now. They're starting working on the videos this week and will make them available one by one as each is ready. -- Andrei
Re: DConf 2015 livestreaming day 1: post feedback here
On 28/05/2015 12:54 p.m., Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei Just a thought, livecoding.tv would be interested in hosting a live stream for e.g. a conference. Declaration: I've been live streaming there since February!
Re: DConf 2015 livestreaming day 1: post feedback here
On Thursday, 28 May 2015 at 01:11:16 UTC, Meta wrote: On Thursday, 28 May 2015 at 01:09:42 UTC, Meta wrote: Does anyone have the links to Kenji's tuple pull and the fixes for the module system? https://github.com/D-Programming-Language/dmd/pull/3407 Can't find the tuple PR https://github.com/D-Programming-Language/dmd/pull/341 ? also, DIP32.
Re: DConf 2015 livestreaming day 1: post feedback here
On Thursday, 28 May 2015 at 01:00:26 UTC, Ali Çehreli wrote: Thank you for doing this! The slides will be easier to read if the camera can be a little closer. +1 On Thursday, 28 May 2015 at 00:54:30 UTC, Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei Thank you for streaming! It would be nice if you and Walter would be paid after DConf 20 minutes of questions from users of YouTube. I think there is still a lot of interesting questions, including me.
Re: DConf 2015 livestreaming day 1: post feedback here
On Thursday, 28 May 2015 at 01:09:42 UTC, Meta wrote: Does anyone have the links to Kenji's tuple pull and the fixes for the module system? https://github.com/D-Programming-Language/dmd/pull/3407 Can't find the tuple PR
Re: DConf 2015 livestreaming day 1: post feedback here
On Thursday, 28 May 2015 at 01:00:26 UTC, Ali Çehreli wrote: On 05/27/2015 05:54 PM, Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei Thank you for doing this! The slides will be easier to read if the camera can be a little closer. Ali Does anyone have the links to Kenji's tuple pull and the fixes for the module system?
Re: DConf 2015 livestreaming day 1: post feedback here
On 05/27/2015 05:54 PM, Andrei Alexandrescu wrote: John Colvin's experiment is great and we want to make it a full success. Please post here feedback and suggestions for tomorrow's DConf streaming. Thanks! -- Andrei Thank you for doing this! The slides will be easier to read if the camera can be a little closer. Ali
Re: DConf 2015 Livestreaming?
On Wednesday, 27 May 2015 at 19:17:31 UTC, Jacob Carlborg wrote: On 2015-05-27 20:24, weaselcat wrote: Let me rephrase it for him, "I hope there is at least downloadable videos within the next month instead of last year's fiasco." 20 talks, one talk per week, that is five months for all talks. It was absolutely horrible PR for D last year.
Re: DConf 2015 Livestreaming?
On 2015-05-27 20:24, weaselcat wrote: Let me rephrase it for him, "I hope there is at least downloadable videos within the next month instead of last year's fiasco." 20 talks, one talk per week, that is five months for all talks. -- /Jacob Carlborg
Re: DConf 2015 Livestreaming?
On 5/27/15, Dicebot via Digitalmars-d wrote: > Inofficial ad-hoc stream : > https://www.youtube.com/watch?v=-OCl-jWyT9E > (may randomly stop and get restarted) > (thanks John Colvin) Nice! Btw, youtube preemptively blocks this in Germany, only because it is a live-stream and I guess they're just scared they'll get sued. Luckily VPN here is to save the day. :)
Re: DConf 2015 Livestreaming?
Inofficial ad-hoc stream : https://www.youtube.com/watch?v=-OCl-jWyT9E (may randomly stop and get restarted) (thanks John Colvin)
Re: DConf 2015 Livestreaming?
On Wednesday, 27 May 2015 at 18:06:31 UTC, extrawurst wrote: On Wednesday, 27 May 2015 at 17:32:06 UTC, Gary Willoughby wrote: On Wednesday, 27 May 2015 at 10:32:32 UTC, Liam McSherry wrote: On Wednesday, 27 May 2015 at 10:20:04 UTC, Per Nordlöw wrote: Isn't there any live-streaming of DConf this year? Unfortunately, there doesn't seem to be any streaming this year: http://forum.dlang.org/thread/zpwxvgiaigdbweach...@forum.dlang.org I hope there is at least downloadable videos. That has always been the case.. Let me rephrase it for him, "I hope there is at least downloadable videos within the next month instead of last year's fiasco."
Re: DConf 2015 Livestreaming?
On Wednesday, 27 May 2015 at 17:32:06 UTC, Gary Willoughby wrote: On Wednesday, 27 May 2015 at 10:32:32 UTC, Liam McSherry wrote: On Wednesday, 27 May 2015 at 10:20:04 UTC, Per Nordlöw wrote: Isn't there any live-streaming of DConf this year? Unfortunately, there doesn't seem to be any streaming this year: http://forum.dlang.org/thread/zpwxvgiaigdbweach...@forum.dlang.org I hope there is at least downloadable videos. Yes, the university organizing the event is recording videos that will be put online at some point.
Re: DConf 2015 Livestreaming?
On Wednesday, 27 May 2015 at 17:32:06 UTC, Gary Willoughby wrote: On Wednesday, 27 May 2015 at 10:32:32 UTC, Liam McSherry wrote: On Wednesday, 27 May 2015 at 10:20:04 UTC, Per Nordlöw wrote: Isn't there any live-streaming of DConf this year? Unfortunately, there doesn't seem to be any streaming this year: http://forum.dlang.org/thread/zpwxvgiaigdbweach...@forum.dlang.org I hope there is at least downloadable videos. That has always been the case..
Re: DConf 2015 Livestreaming?
On Wednesday, 27 May 2015 at 10:32:32 UTC, Liam McSherry wrote: On Wednesday, 27 May 2015 at 10:20:04 UTC, Per Nordlöw wrote: Isn't there any live-streaming of DConf this year? Unfortunately, there doesn't seem to be any streaming this year: http://forum.dlang.org/thread/zpwxvgiaigdbweach...@forum.dlang.org I hope there is at least downloadable videos.
Re: DConf 2015 Livestreaming?
On Wednesday, 27 May 2015 at 10:20:04 UTC, Per Nordlöw wrote: Isn't there any live-streaming of DConf this year? Unfortunately, there doesn't seem to be any streaming this year: http://forum.dlang.org/thread/zpwxvgiaigdbweach...@forum.dlang.org
Re: DConf 2015 talk quota
On Saturday, 7 March 2015 at 08:13:34 UTC, Daniel Murphy wrote: "Philpax" wrote in message news:zhxwmatecvtmormmm...@forum.dlang.org... The last bit of news I saw suggested that DConf 2015 hadn't met its talk quota in time; is this still the case, or have a suitable number of talks been sent in? I had an idea for a talk, but wasn't sure if it was interesting/unique enough. Andrei confirmed there were enough submissions. http://forum.dlang.org/post/md20ov$30d2$1...@digitalmars.com Awesome, looking forward to the talks this year :)
Re: DConf 2015 talk quota
"Philpax" wrote in message news:zhxwmatecvtmormmm...@forum.dlang.org... The last bit of news I saw suggested that DConf 2015 hadn't met its talk quota in time; is this still the case, or have a suitable number of talks been sent in? I had an idea for a talk, but wasn't sure if it was interesting/unique enough. Andrei confirmed there were enough submissions. http://forum.dlang.org/post/md20ov$30d2$1...@digitalmars.com
Re: DConf 2015?
On Tuesday, 6 January 2015 at 21:05:57 UTC, Chuck Allison wrote: Just so you all know, DConf 2015 is scheduled when Utah is it's most beautiful. Not too hot, everything green, perfect for hiking, whatever. If you have never been to Southern Utah before, you might want to consider scheduling some time to see the National Parks and other like places before or after the conference. Will the ski hills still be open?
Re: DConf 2015?
Just so you all know, DConf 2015 is scheduled when Utah is it's most beautiful. Not too hot, everything green, perfect for hiking, whatever. If you have never been to Southern Utah before, you might want to consider scheduling some time to see the National Parks and other like places before or after the conference. On Tuesday, 30 December 2014 at 03:38:08 UTC, Walter Bright wrote: On 12/29/2014 3:37 AM, Kingsley wrote: I'm interested in coming to the next D conference. Please let me know if there is anything I can do to help out. I've been working on IDE support for intellij here: https://github.com/kingsleyh/DLanguage The best thing you can do is submit a speaking proposal. which I thought might be an interesting topic for a brief presentation. Although I guess it depends on the audience at these conferences. Will the next one be in the same place? I'm based in London - I guess it's not going to be in London? It'll be at Utah Valley University: http://www.uvu.edu/visitors/aboutuvu/
Re: DConf 2015?
No tie required, Adam (you'd be the only one :-). Chuck On Tuesday, 30 December 2014 at 03:47:17 UTC, Adam D. Ruppe wrote: On Tuesday, 30 December 2014 at 03:38:08 UTC, Walter Bright wrote: It'll be at Utah Valley University: OOh, I might not be the only person there wearing a tie this time!
Re: DConf 2015?
On 30 Dec 2014 08:59, "Iain Buclaw" wrote: > > > On 30 Dec 2014 03:40, "Walter Bright via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > > > On 12/29/2014 3:37 AM, Kingsley wrote: > >> > >> I'm interested in coming to the next D conference. Please let me know if there > >> is anything I can do to help out. I've been working on IDE support for intellij > >> here: https://github.com/kingsleyh/DLanguage > > > > > > The best thing you can do is submit a speaking proposal. > > > > > >> which I thought might be an interesting topic for a brief presentation. Although > >> I guess it depends on the audience at these conferences. > >> > >> Will the next one be in the same place? I'm based in London - I guess it's not > >> going to be in London? > > > > > > It'll be at Utah Valley University: > > > > http://www.uvu.edu/visitors/aboutuvu/ > > Where's the announcement? (sorry if you already have, I am yet to see it). > > Iain. Even a new frontpage at dconf.org with new Dconf2015 stripes, current proposed location and date (even if still not finalized - emphasis on *to be confirmed*), and early request for speakers would be great. Infact, even just an early request for speakers *before* any finalized plans for date and location would be beneficial for those wanting to take part. :-) Iain.
Re: DConf 2015?
On 30 Dec 2014 03:40, "Walter Bright via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On 12/29/2014 3:37 AM, Kingsley wrote: >> >> I'm interested in coming to the next D conference. Please let me know if there >> is anything I can do to help out. I've been working on IDE support for intellij >> here: https://github.com/kingsleyh/DLanguage > > > The best thing you can do is submit a speaking proposal. > > >> which I thought might be an interesting topic for a brief presentation. Although >> I guess it depends on the audience at these conferences. >> >> Will the next one be in the same place? I'm based in London - I guess it's not >> going to be in London? > > > It'll be at Utah Valley University: > > http://www.uvu.edu/visitors/aboutuvu/ Where's the announcement? (sorry if you already have, I am yet to see it). Iain.
Re: DConf 2015?
On Tuesday, 30 December 2014 at 03:38:08 UTC, Walter Bright wrote: It'll be at Utah Valley University: OOh, I might not be the only person there wearing a tie this time!
Re: DConf 2015?
On 12/29/2014 3:37 AM, Kingsley wrote: I'm interested in coming to the next D conference. Please let me know if there is anything I can do to help out. I've been working on IDE support for intellij here: https://github.com/kingsleyh/DLanguage The best thing you can do is submit a speaking proposal. which I thought might be an interesting topic for a brief presentation. Although I guess it depends on the audience at these conferences. Will the next one be in the same place? I'm based in London - I guess it's not going to be in London? It'll be at Utah Valley University: http://www.uvu.edu/visitors/aboutuvu/
Re: DConf 2015?
On Tuesday, 23 December 2014 at 00:25:33 UTC, Walter Bright wrote: On 12/22/2014 12:59 PM, Iain Buclaw via Digitalmars-d wrote: On 22 December 2014 at 20:52, Walter Bright via Digitalmars-d wrote: On 12/22/2014 9:40 AM, Adam D. Ruppe wrote: By this time last year, dconf 2014 preparations were already under way but I haven't heard anything this year. Is another one planned? Yes. Still working on getting confirmation of the date. You mean to say that it's moving from it's usual time slot next year? (Weekend before spring bank holiday) Looks like it'll be May 27-29. Hi I've recently started programming in D and I have set up a London meetup group - http://www.meetup.com/London-D-Programmers/ I'm interested in coming to the next D conference. Please let me know if there is anything I can do to help out. I've been working on IDE support for intellij here: https://github.com/kingsleyh/DLanguage which I thought might be an interesting topic for a brief presentation. Although I guess it depends on the audience at these conferences. Will the next one be in the same place? I'm based in London - I guess it's not going to be in London?
Re: DConf 2015?
On Wednesday, 24 December 2014 at 16:19:16 UTC, Kagamin wrote: Just make opDispatch accept zero or more arguments, when zero arguments are passed, it works as a property, when more arguments are passed, it works like a method call, no need for @property. That doesn't work with functions that take zero or one arguments: obj.foo(); // still calls opDispatch, not the returned property obj.foo(bar); // indistinguishable from obj.foo = bar With the ref return getter, pretty much everything else works right, but these two cases are still ambiguous.
Re: DConf 2015?
Just make opDispatch accept zero or more arguments, when zero arguments are passed, it works as a property, when more arguments are passed, it works like a method call, no need for @property.
Re: DConf 2015?
On Wednesday, 24 December 2014 at 09:22:17 UTC, Kagamin wrote: According to javascript convention, if you stored a delegate in object's property, d.foo.bar("hello! ") is still a method `bar` called on a value from property `foo`, it's forwarded internally to the delegate when `bar` happens to be a property. Yeah, it doesn't exactly work like that in D though due to this and @property being different. I do have a way to handle the this: foo.bar._function = (var _this, var[] args) { }; The _function is the internal representation - that's what's auto-generated when you assign a regular D function to it. But since D doesn't have a dynamic this keyword like javascript (which is good btw!), you can't access it unless you write a function in that form directly. Like JS though, the var type does have a .apply() method which calls in that form. My little script language does have a JS style this which works the same way. (My language isn't javascript - I changed a few things, removed some, added others, but it is close enough that it shouldn't be too surprising to a javascript user.) What's disappointing with D's @property is that it doesn't actually do anything. All the foo.bar on var calls @property ref var opDispatch(string name)(). That way, it can get and set a value in a single go (returning ref means some things look silly, like returning null is done as var a = new var; *a = null; return *a; yes, a heap allocated null. But then it can be returned as ref and reassigned etc. without extra work. If you want efficiency, keep away from the dynamic type!) But then calling the returned var takes the extra parens since the first set just calls opDispatch... which is what we need to do anyway to just get the var!
Re: DConf 2015?
On Tuesday, 23 December 2014 at 17:19:23 UTC, Adam D. Ruppe wrote: var d = json!q{ "foo": { "bar": 10.2 } }; writeln(d.foo); // {"bar":10.2} d.foo.bar = (var a) => a ~ b; writeln(d.foo.bar()("hello! ")); // double parens cuz @property isn't right // hello! 20 According to javascript convention, if you stored a delegate in object's property, d.foo.bar("hello! ") is still a method `bar` called on a value from property `foo`, it's forwarded internally to the delegate when `bar` happens to be a property.
Re: DConf 2015?
On 12/23/2014 9:19 AM, Adam D. Ruppe wrote: I haven't decided if I'd do a submission this year or not yet (and even if I did, there's of course no guarantee it would be accepted!). That's one of the reasons I was asking, last year the deadline was in January so if I do decide to do it, I'll have to start thinking about it soon! Yes, please submit one!
Re: DConf 2015?
On Tuesday, 23 December 2014 at 17:19:23 UTC, Adam D. Ruppe wrote: The templates and operator overloads did all the work in showing the web responses. That's kinda cool. Indeed very cool, well done! Matheus.
Re: DConf 2015?
On Tuesday, 23 December 2014 at 16:58:28 UTC, Mattcoder wrote: Are you going to present us with more classics slides? :) I haven't decided if I'd do a submission this year or not yet (and even if I did, there's of course no guarantee it would be accepted!). That's one of the reasons I was asking, last year the deadline was in January so if I do decide to do it, I'll have to start thinking about it soon! I'm kinda tempted to talk about my jsvar.d and script.d this time. I might also blab about web.d, but the var+script thing is kinda interesting at a quick glimpse: // this is valid D code! var a = 10; var b = "20"; var c = a + b; var d = json!q{ "foo": { "bar": 10.2 } }; writeln(d.foo); // {"bar":10.2} d.foo.bar = (var a) => a ~ b; writeln(d.foo.bar()("hello! ")); // double parens cuz @property isn't right // hello! 20 You might remember a thread I made a year or two ago asking "is this D or is it javascript?". That kind of thing I think lends itself fairly well to slides. I wrote this program yesterday: https://github.com/adamdruppe/inspector And even I was amazed with how integrating my http2.d - a pretty traditional D module with no special scriptable code - just worked when I plugged it into a var and ran it from my little script language. The templates and operator overloads did all the work in showing the web responses. That's kinda cool.
Re: DConf 2015?
On Monday, 22 December 2014 at 17:40:13 UTC, Adam D. Ruppe wrote: By this time last year, dconf 2014 preparations were already under way but I haven't heard anything this year. Is another one planned? Are you going to present us with more classics slides? :) http://m.imgur.com/hHCN3OL Matheus.
Re: DConf 2015?
On Tuesday, 23 December 2014 at 00:25:33 UTC, Walter Bright wrote: On 12/22/2014 12:59 PM, Iain Buclaw via Digitalmars-d wrote: On 22 December 2014 at 20:52, Walter Bright via Digitalmars-d wrote: On 12/22/2014 9:40 AM, Adam D. Ruppe wrote: By this time last year, dconf 2014 preparations were already under way but Looks like it'll be May 27-29. By the way, who ever is co-coordinating this can also get help from SV D meetup and likely Berlin and help each other.
Re: DConf 2015?
On 12/22/2014 12:59 PM, Iain Buclaw via Digitalmars-d wrote: On 22 December 2014 at 20:52, Walter Bright via Digitalmars-d wrote: On 12/22/2014 9:40 AM, Adam D. Ruppe wrote: By this time last year, dconf 2014 preparations were already under way but I haven't heard anything this year. Is another one planned? Yes. Still working on getting confirmation of the date. You mean to say that it's moving from it's usual time slot next year? (Weekend before spring bank holiday) Looks like it'll be May 27-29.
Re: DConf 2015?
On 22 December 2014 at 20:52, Walter Bright via Digitalmars-d wrote: > On 12/22/2014 9:40 AM, Adam D. Ruppe wrote: >> >> By this time last year, dconf 2014 preparations were already under way but >> I >> haven't heard anything this year. Is another one planned? > > > Yes. Still working on getting confirmation of the date. You mean to say that it's moving from it's usual time slot next year? (Weekend before spring bank holiday)
Re: DConf 2015?
On 12/22/2014 9:40 AM, Adam D. Ruppe wrote: By this time last year, dconf 2014 preparations were already under way but I haven't heard anything this year. Is another one planned? Yes. Still working on getting confirmation of the date.