Re: Spawning a process: Can I "have my cake and eat it too"?
On Friday, 2 March 2018 at 04:50:06 UTC, Nick Sabalausky (Abscissa) wrote: Launch a process (spawnProcess, pipeShell, etc) so the child's stdout/stderr go to the parent's stdout/stderr *without* the possibility of them getting inadvertently reordered/reinterleaved when viewed on the terminal, *and* still allow the parent to read the child's stdout and stderr? I think it's possible on Linux. 1. Disable buffering on the pipe (see stdbuf etc.) 2. Fake output type to fool isatty (e.g. script -c 'child_program args...' /dev/null)
Re: Spawning a process: Can I "have my cake and eat it too"?
I would suggest redirecting the child to the parent pipe, but then having the parent write the data back out to its own stdout/err. It'd be a bit tricky with just Phobos' file though because it doesn't make it easy to wait for or be notified about input on it, but the underlying OS apis make this reasonably simple (WaitForMultipleObjects or select) if you're willing to write a bit more code to do it yourself or at least pull the underlying handles out of the Phobos file.
Spawning a process: Can I "have my cake and eat it too"?
I'd like to include this functionality in Scriptlike, but I don't know if it's even possible: Launch a process (spawnProcess, pipeShell, etc) so the child's stdout/stderr go to the parent's stdout/stderr *without* the possibility of them getting inadvertently reordered/reinterleaved when viewed on the terminal, *and* still allow the parent to read the child's stdout and stderr? How could this be accomplished? Is it even possible?
Re: Assigning to slice of array
On Thursday, March 01, 2018 23:51:37 Jamie via Digitalmars-d-learn wrote: > On a similar not, is there an accepted way to assign across > arrays? As Steve mentioned, cross-slicing isn't supported, so is > the best way to iterate through the array and assign as necessary? That's what you would have to do. You're basically dealing with stuff like int*** except that it also has its length with it and wraps it in a nicer way, and so each of these buffers that you're dealing with are essentially unrelated. They just have a common root. Even if there were some sort of high level operation that did something along the lines of what you're looking for, it would pretty much have to lower to something along the lines of what you'd be doing to solve the problem on your own. It's not like these are these are buffers which are somehow squares or cubes in memory such that they you could slice along a different dimension. They're still just linear buffers of memory. - Jonathan M Davis
Re: Assigning to slice of array
On Thursday, 1 March 2018 at 23:17:11 UTC, Jonathan M Davis wrote: So, something like auto arr = new int[][][](3, 2, 1); arr.length = 4; arr[0].length = 5; arr[0][0].length = 6; is legal, but something like Thanks Jonathan, this is exactly what I was looking for. I was getting confused with not being able to resize because I was looking at int[] arrays and I guess the way I was defining them caused them both to be dynamic (when I thought one was static). On a similar not, is there an accepted way to assign across arrays? As Steve mentioned, cross-slicing isn't supported, so is the best way to iterate through the array and assign as necessary? Thanks, Jamie
Re: Assigning to slice of array
On Thursday, March 01, 2018 22:57:16 Jamie via Digitalmars-d-learn wrote:
> On Thursday, 1 March 2018 at 21:34:41 UTC, Jonathan M Davis wrote:
> > Don't put the indices within the brackets. What you want is
> >
> > auto arr = new int[][][](3, 2, 1);
>
> Okay thanks, but I don't understand what is the issue with having
> static arrays there instead? My functionality didn't change when
> I replaced the single line with your line?
>
> And I couldn't resize either of them with array.length, which is
> also something I would like.
> Thanks
static arrays have a fixed size, so you can't resize them with any operation
- including setting their length. Static arrays are value types, so when
they're copied, the whole thing is copied, whereas with a dynamic array is
just a pointer and a length, so copying it just slices the dynamic array to
give you another dynamic array. It's just copying the pointer and the
length. A dynamic array is effectively
struct DynamicArray(T)
{
size_t length;
T* ptr;
}
whereas a static array is an actual buffer that sits wherever it's declared
(on the stack if it's a local variable).
So, something like
auto arr = new int[][][](3, 2, 1);
arr.length = 4;
arr[0].length = 5;
arr[0][0].length = 6;
is legal, but something like
auto arr = new int[3][2][1];
arr.length = 4; // this one is still legal, since it's a dynamic array
arr[0].length = 5;
arr[0][0].length = 6;
is not legal.
- Jonathan M Davis
Re: Assigning to slice of array
On Thursday, 1 March 2018 at 21:34:41 UTC, Jonathan M Davis wrote: Don't put the indices within the brackets. What you want is auto arr = new int[][][](3, 2, 1); Okay thanks, but I don't understand what is the issue with having static arrays there instead? My functionality didn't change when I replaced the single line with your line? And I couldn't resize either of them with array.length, which is also something I would like. Thanks
Re: Assigning to slice of array
On 03/01/2018 11:43 PM, Jamie wrote: So if I do arr[0 .. 1][0] = 3; shouldn't this return [[3, 0, 0], [0, 0, 0]] ? Because I'm taking the slice arr[0 .. 1], or arr[0], which is the first [0, 0, 0]? arr[0 .. 1] is not the same as arr[0]. arr[0 .. 1] is not the first element of arr; it's an array that contains the first element of arr. It's not [0, 0, 0]; it's [[0, 0, 0]]. It's not an int[]; it's an int[][]. Then assigning the first element to 3? instead it returns [[3, 3, 3], [0, 0, 0]] Since arr[0 .. 1] is [[0, 0, 0]], arr[0 .. 1][0] is [0, 0, 0]. Assigning 3 to that means assigning to all of its values. And so you get [3, 3, 3].
Re: Assigning to slice of array
On Thursday, 1 March 2018 at 21:31:49 UTC, Steven Schveighoffer wrote: No, I think you did int[3][2], if you got that output. Otherwise it would have been: [[[0,0,0],[0,0,0]]] Yes apologies that was there from a previous attempt, you are correct. Well, that's because that type of slicing isn't supported directly. You can't slice an array cross-wise like that. You may be interested in ndslice inside mir: http://docs.algorithm.dlang.io/latest/mir_ndslice.html Thanks I've just had a quick read and this looks promising for what I want (similar functionality to numpy), but I also want to understand arrays. when I try arr[0 .. 2][0] = 3; // which I think is equivalent to arr[0][0] Consider the array: int[] x = new int[2]; Now, what would the slice x[0 .. 2] be? That's right, the same as x. So when you slice arr[0 .. 2], it's basically the same as arr (as arr has 2 elements). So arr[0 .. 2][0] is equivalent to arr[0]. So if I do arr[0 .. 1][0] = 3; shouldn't this return [[3, 0, 0], [0, 0, 0]] ? Because I'm taking the slice arr[0 .. 1], or arr[0], which is the first [0, 0, 0]? Then assigning the first element to 3? instead it returns [[3, 3, 3], [0, 0, 0]] One thing that is interesting is that you assigned 3 to an array, and it wrote it to all the elements. I did not know you could do that with static arrays without doing a proper slice assign. But it does compile (I learn something new every day). -Steve Well I'm learning a lot today :)
Re: Assigning to slice of array
On 3/1/18 4:16 PM, Jamie wrote: I'm trying to understand arrays and have read a lot of the information about them on this forum. I think I understand that they are set-up like Type[], so that int[][] actually means an array of int[]. I create an array as per the following: auto arr = new int[3][2][1]; which produces: [[0, 0, 0], [0, 0, 0]] No, I think you did int[3][2], if you got that output. Otherwise it would have been: [[[0,0,0],[0,0,0]]] Looking at the rest of your code, I think it wouldn't work if you had done the line above. (for each of the following assignments, assume that the array is set back to zeros) and I can change the 2nd element of the 1st array using: arr[0][1] = 4; which produces: [[0, 4, 0], [0, 0, 0]] and I can change the entire 1st array using: arr[0][0 .. 3] = 5; which produces: [[5, 5, 5], [0, 0, 0,]] Yes, all correct. however when I try and change elements across arrays rather than within arrays my understanding breaks down.. Well, that's because that type of slicing isn't supported directly. You can't slice an array cross-wise like that. You may be interested in ndslice inside mir: http://docs.algorithm.dlang.io/latest/mir_ndslice.html when I try arr[0 .. 2][0] = 3; // which I think is equivalent to arr[0][0] Consider the array: int[] x = new int[2]; Now, what would the slice x[0 .. 2] be? That's right, the same as x. So when you slice arr[0 .. 2], it's basically the same as arr (as arr has 2 elements). So arr[0 .. 2][0] is equivalent to arr[0]. One thing that is interesting is that you assigned 3 to an array, and it wrote it to all the elements. I did not know you could do that with static arrays without doing a proper slice assign. But it does compile (I learn something new every day). -Steve
Re: Assigning to slice of array
On Thursday, March 01, 2018 21:16:54 Jamie via Digitalmars-d-learn wrote: > I'm trying to understand arrays and have read a lot of the > information about them on this forum. I think I understand that > they are set-up like Type[], so that int[][] actually means an > array of int[]. > > I create an array as per the following: > auto arr = new int[3][2][1]; > which produces: Don't put the indices within the brackets. What you want is auto arr = new int[][][](3, 2, 1); With a new expression, unless you only have one dimension, you end up with dynamic arrays of static arrays. e.g. if you use what I wrote there with pragma(msg, typeof(arr).stringof); it prints int[][][] whereas with what you wrote, you get int[3][2][] which is a dynamic array of a static array of length 2 of static arrays of int of length 3 rather than a dynamic array of a dynamic array of a dynamic array of ints. Unfortunately, auto arr = new int[5]; and auto arr = new int[](5); are equivalent, so dealing with just single dimension arrays does not prepare you properly for dealing with multi-dimensional arrays. Arguably, it would have been better to just force using the parens, though that would make the most common case more verbose, so it's debatable. - Jonathan M Davis
Assigning to slice of array
I'm trying to understand arrays and have read a lot of the information about them on this forum. I think I understand that they are set-up like Type[], so that int[][] actually means an array of int[]. I create an array as per the following: auto arr = new int[3][2][1]; which produces: [[0, 0, 0], [0, 0, 0]] (for each of the following assignments, assume that the array is set back to zeros) and I can change the 2nd element of the 1st array using: arr[0][1] = 4; which produces: [[0, 4, 0], [0, 0, 0]] and I can change the entire 1st array using: arr[0][0 .. 3] = 5; which produces: [[5, 5, 5], [0, 0, 0,]] however when I try and change elements across arrays rather than within arrays my understanding breaks down.. when I try arr[0 .. 2][0] = 3; // which I think is equivalent to arr[0][0] and arr[1][0] I'm expecting: [[3, 0, 0], [3, 0, 0]] but it produces: [[3, 3, 3], [0, 0, 0]] showing that arr[0][0 .. 2] is making the same index as arr[0 .. 3][0] ? Instead of using [0 .. 2] I can use the actual indices to get the result I desired: arr[0][0] = 3; arr[1][0] = 3; which produces: [[3, 0, 0], [3, 0, 0]] Could I just get some help with understanding how the slice [0 .. 2] actually works? Thanks
Re: Garbage collected pointers?
On Thursday, March 01, 2018 15:53:08 Steven Schveighoffer via Digitalmars-d- learn wrote: > On 3/1/18 3:33 PM, H. S. Teoh wrote: > > Won't a precise GC scanning for pointers to aligned objects want to skip > > values that can't be an aligned pointer? Though in D's case, being > > required to be conservative would negate this. > > int[] x = [1,2,3]; > void[] y = x; > y = y[1 .. $]; // misaligned pointer. > > It's easy to do, and it's done all over the place (buffers anyone?). Yeah, until recently readText could kill your program because of that, which I found out the hard way when I had to muck around with some UTF-16 files. It's an easy mistake to make. - Jonathan M Davis
Re: Garbage collected pointers?
On 3/1/18 3:33 PM, H. S. Teoh wrote: On Thu, Mar 01, 2018 at 02:52:26PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: [...] There are a few in there, which I think are over-the-top. Such as "don't cast a pointer to a non-pointer", [...] Isn't that necessary for a precise GC? It's not strictly necessary for a precise GC. It's necessary for a copying GC. In that case, if the GC decides to move your object and update all the references, it would miss that one. And even there, it's not necessary that you refrain from casting, it's just necessary to refrain from using that as an actual pointer in the future. I can't see how you might print a pointer value without casting it to an integer ;) What is more important is that you don't use that as the ONLY reference to the object. Also, AIUI the current GC already does not scan size_t[] blocks for pointers, so if you cast a pointer to size_t and put it in such an array with no other references to your object, you stand the chance of the GC collecting your object while it is still live. Again, the key is "no other references". The document referenced above just says you can't cast. or "Do not take advantage of alignment of pointers to store bit flags in the low order bits". [...] Won't a precise GC scanning for pointers to aligned objects want to skip values that can't be an aligned pointer? Though in D's case, being required to be conservative would negate this. int[] x = [1,2,3]; void[] y = x; y = y[1 .. $]; // misaligned pointer. It's easy to do, and it's done all over the place (buffers anyone?). -Steve
Re: Garbage collected pointers?
On Thu, Mar 01, 2018 at 02:52:26PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote: [...] > There are a few in there, which I think are over-the-top. Such as > "don't cast a pointer to a non-pointer", [...] Isn't that necessary for a precise GC? Also, AIUI the current GC already does not scan size_t[] blocks for pointers, so if you cast a pointer to size_t and put it in such an array with no other references to your object, you stand the chance of the GC collecting your object while it is still live. > or "Do not take advantage of alignment of pointers to store bit flags > in the low order bits". [...] Won't a precise GC scanning for pointers to aligned objects want to skip values that can't be an aligned pointer? Though in D's case, being required to be conservative would negate this. T -- There are three kinds of people in the world: those who can count, and those who can't.
Re: Garbage collected pointers?
On Thursday, March 01, 2018 14:52:26 Steven Schveighoffer via Digitalmars-d- learn wrote: > On 3/1/18 2:04 PM, Jonathan M Davis wrote: > > On Thursday, March 01, 2018 10:55:34 Steven Schveighoffer via > > Digitalmars-d-> > > learn wrote: > >> It should really say that it's up to the GC implementation whether it's > >> UB or not. > > > > Well, that arguably makes it UB in general then, because it can't be > > relied on. By putting restrictions on the GC in general based on what > > types of GCs theoretically could be used, it makes it so that D code in > > general could theoretically work with any GC that fits the bill, > > whereas if the rules of what was allowed changed depending on the GC > > being used, what was valid D would effectively change depending on the > > GC. > > There are a few in there, which I think are over-the-top. Such as "don't > cast a pointer to a non-pointer", or "Do not take advantage of alignment > of pointers to store bit flags in the low order bits". I can't conceive > of any GC that would have fits with either of these things without > breaking pretty much everything. While I can't conceive of it, it > doesn't mean there isn't a reason for it. But clearly the reason isn't > currently implemented. It would not surprise me in the least if the list of what's allowed and isn't allowed in there needs an overhaul. I just think that saying that something is okay with one GC and not with another such that whether the code is valid or not depends on which GC is being used is begging for trouble. The approach of saying what's allowed or not in general makes more sense, even if the exact list needs work. And D and the plans for D have changed enough over time that the current list could be making assumptions about what's reasonable that actually aren't at all reasonable at this point, particularly as it's become clearer over time that certain types of GCs probably aren't reasonable, and if officially disallowing some of them simplified things, then that may be a good idea. It hasn't mattered much in practice though, because the work on alternative GCs has been minimal. There have been some, but thus far, we haven't really ended up in a situation where choosing which GC you're doing to use is much of a thing. - Jonathan M Davis
Re: Garbage collected pointers?
On 3/1/18 2:04 PM, Jonathan M Davis wrote: On Thursday, March 01, 2018 10:55:34 Steven Schveighoffer via Digitalmars-d- learn wrote: It should really say that it's up to the GC implementation whether it's UB or not. Well, that arguably makes it UB in general then, because it can't be relied on. By putting restrictions on the GC in general based on what types of GCs theoretically could be used, it makes it so that D code in general could theoretically work with any GC that fits the bill, whereas if the rules of what was allowed changed depending on the GC being used, what was valid D would effectively change depending on the GC. There are a few in there, which I think are over-the-top. Such as "don't cast a pointer to a non-pointer", or "Do not take advantage of alignment of pointers to store bit flags in the low order bits". I can't conceive of any GC that would have fits with either of these things without breaking pretty much everything. While I can't conceive of it, it doesn't mean there isn't a reason for it. But clearly the reason isn't currently implemented. -Steve
Re: Garbage collected pointers?
On Thursday, March 01, 2018 10:55:34 Steven Schveighoffer via Digitalmars-d- learn wrote: > It should really say that it's up to the GC implementation whether it's UB > or not. Well, that arguably makes it UB in general then, because it can't be relied on. By putting restrictions on the GC in general based on what types of GCs theoretically could be used, it makes it so that D code in general could theoretically work with any GC that fits the bill, whereas if the rules of what was allowed changed depending on the GC being used, what was valid D would effectively change depending on the GC. - Jonathan M Davis
Re: Function template declaration mystery...
On 2018-03-01 12:01:19 +, Steven Schveighoffer said: Ok, here it is: https://pastebin.com/tKACi488 See lines 81-84 for how I call it. And the problem I have is that doSubscribe returns "something" I'm not sure what I can do with. But if the scope ends, my subscription seems to be deleted and hence is not called when a message is coming in (see line: 118) Looking through the rx package, it seems that it returns a class instance. That class implements the Disposable interface. Yes, AFAIU this can be kept around for reference. Seems to be intended for later access to the observers. I'm guessing from this observation that the class instance will unregister the subscription if it's destroyed, and because you aren't keeping a reference to that instance, the GC comes along and destroys it at some point. That was my guess too. But it's not the case. The unary is kept, hence I can just ignore the return value. What bite me here was a Windows effect. I subscribed my observer after the call to RegisterClass/CreateWindow. But Windows sometimes calls the window-procedure directly, without going through the message loop. And the messages I want to trigger on, are exactly ones that go directly. So, my code was never triggered because it just wasn't there. And after it was there, no more messages flow in. :-/ After rearranging things a bit it's working. But anyway, learned a lot while digging through the code and your feedback helped too. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Garbage collected pointers?
On 3/1/18 10:35 AM, John Burton wrote: On Thursday, 1 March 2018 at 12:20:08 UTC, Steven Schveighoffer wrote: On 3/1/18 7:05 AM, Gary Willoughby wrote: On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote: My question is how do I tell if a pointer is "garbage collected" or not? You could try `GC.addrOf()` or `GC.query()` in core.memory. I was going to say this, but then I realized, it's not that the pointer points at GC-allocated memory, but that the pointer itself is stored in a location that is scanned by the GC. That's not as easy to figure out, as you have to look at stacks, added ranges, etc. Ah it's where the pointer is stored. That makes some sense. Thanks Yes, the text isn't exactly clear. For instance, C rules apply for a pointer stored in a block allocated by C malloc, even if it points at a GC piece of memory -- as long as the block hasn't been added as a root or range to the GC. Also note that realistically, even though the document talks about a "copying GC", this probably will never happen. Many things that are identified as "undefined behavior" in that doc, are probably going to be fine. I really wish it didn't say UB for a lot of those things. It should really say that it's up to the GC implementation whether it's UB or not. -Steve
Re: Garbage collected pointers?
On Thursday, 1 March 2018 at 12:20:08 UTC, Steven Schveighoffer wrote: On 3/1/18 7:05 AM, Gary Willoughby wrote: On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote: My question is how do I tell if a pointer is "garbage collected" or not? You could try `GC.addrOf()` or `GC.query()` in core.memory. I was going to say this, but then I realized, it's not that the pointer points at GC-allocated memory, but that the pointer itself is stored in a location that is scanned by the GC. That's not as easy to figure out, as you have to look at stacks, added ranges, etc. -Steve Ah it's where the pointer is stored. That makes some sense. Thanks
Re: Slide - what does withPartial do?
On Thursday, 1 March 2018 at 08:31:05 UTC, Piotr Mitana wrote: For some reason this is true: slide!(Yes.withPartial)([1, 2, 3, 4, 5], 3).array == [[1, 2, 3], [2, 3, 4], [3, 4, 5]] Shouldn't it rather return [[1], [1, 2], [1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5], [5]], or at least [[1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5], [5]]? I can see no difference on the result when withPartial is on and off. Is it a bug or I don't understand it correctly? No it's not a bug. Yes.withPartial (the default) means that if the last element in the range doesn't have the full size it still gets printed, with No.withPartial it's not part of the range. It's gets clearer with a different step size: --- foreach (i; 5 .. 10) slide!(Yes.withPartial)(i.iota, 3, 4).writeln; --- --- [[0, 1, 2], [4]] [[0, 1, 2], [4, 5]] [[0, 1, 2], [4, 5, 6]] [[0, 1, 2], [4, 5, 6]] [[0, 1, 2], [4, 5, 6], [8]] --- --- foreach (i; 5 .. 10) slide!(No.withPartial)(i.iota, 3, 4).writeln; --- --- [[0, 1, 2]] [[0, 1, 2]] [[0, 1, 2], [4, 5, 6]] [[0, 1, 2], [4, 5, 6]] [[0, 1, 2], [4, 5, 6]] --- https://run.dlang.io/is/x8Q5x8 In fact for the default step size of 1, this only has effect if the windowSize is larger than the range size. BTW as a recent addition to std.range, it comes with a ton of unittests: https://github.com/dlang/phobos/blob/master/std/range/package.d#L7755 (though I agree that the public documentation could explain No.withPartial better.) > Shouldn't it rather return [[1], [1, 2], [1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5], [5]], or at least [[1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5], [5]]? That wouldn't be a sliding window / rolling window operator. The idea of a sliding / rolling window operator is that all windows have the same size. withPartial just allows you to pick the behavior for how the final element. That's also how other languages implement this. For examples, here's how sliding from Scala's standard library behaves: --- (1 to 5).iterator.sliding(6).withPartial(false).toList // List() (1 to 5).iterator.sliding(6).withPartial(true).toList // List(List(1, 2, 3, 4, 5)) (1 to 5).iterator.sliding(3, 4).withPartial(false).toList // List(List(1, 2, 3)) (1 to 5).iterator.sliding(3, 4).withPartial(true).toList // List(List(1, 2, 3), List(5)) --- https://scastie.scala-lang.org/pR5pH6DRTWuiVR7GNUTbJA
Re: Garbage collected pointers?
On 3/1/18 7:05 AM, Gary Willoughby wrote: On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote: My question is how do I tell if a pointer is "garbage collected" or not? You could try `GC.addrOf()` or `GC.query()` in core.memory. I was going to say this, but then I realized, it's not that the pointer points at GC-allocated memory, but that the pointer itself is stored in a location that is scanned by the GC. That's not as easy to figure out, as you have to look at stacks, added ranges, etc. -Steve
Re: Garbage collected pointers?
On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote: My question is how do I tell if a pointer is "garbage collected" or not? You could try `GC.addrOf()` or `GC.query()` in core.memory.
Re: Function template declaration mystery...
On 2/28/18 3:36 PM, Robert M. Münch wrote: Yes, that's what the docs state. And I can imagin this. Bit this sentence is a bit hard to understand: "If fun is not a string, unaryFun aliases itself away to fun." Whatever this means. It means that it simply becomes the alias you passed in. It means, there's no extra overhead in calling that unaryFun. But if you pass it something that needs some wrapping, it will do the wrapping. This question is a little harder to understand. Perhaps you have real code that shows what you are confused about? Ok, here it is: https://pastebin.com/tKACi488 See lines 81-84 for how I call it. And the problem I have is that doSubscribe returns "something" I'm not sure what I can do with. But if the scope ends, my subscription seems to be deleted and hence is not called when a message is coming in (see line: 118) Looking through the rx package, it seems that it returns a class instance. That class implements the Disposable interface. And the question is now, what do I have to do that subscriptions that are done anywhere in the code survive the scope where they have been created? I'm guessing from this observation that the class instance will unregister the subscription if it's destroyed, and because you aren't keeping a reference to that instance, the GC comes along and destroys it at some point. What I would recommend is you have to keep a reference to that class somewhere. Start out by just assigning it to a global. If that fixes your problem, I suggest you reach out to the author of rx, or read through the docs to see how you should properly use it, and where you need to keep that subscription (and for what purpose). If that *doesn't* fix your problem, then I'm not understanding what is happening, and you should definitely contact the rx author. File an issue in the github project. -Steve
Re: Garbage collected pointers?
On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote: In the language spec here :- https://dlang.org/spec/garbage.html#pointers_and_gc It refers to a distinction between pointers to garbage collected memory and pointers that are not. In particular it says that with a non garbage collected pointer you can do anything that is legal in C but with a garbage collected pointer there are a lot of undefined behaviors if you don't follow some restrictions. Basically you can do whatever you want with pointers, you may twart ability of GC to free an object b/c you constructed some value that points to GC heap. That’s pretty much it. Second side is loosing pointers to GC owned object, this happens when you put pointers into eg malloced chunk of memory. Calling GC.addRange/removeRange you can let GC know that you stored pointers to GC heap in some place other then stack or GC heap.
Re: Garbage collected pointers?
On 01/03/2018 11:10 PM, John Burton wrote: In the language spec here :- https://dlang.org/spec/garbage.html#pointers_and_gc It refers to a distinction between pointers to garbage collected memory and pointers that are not. In particular it says that with a non garbage collected pointer you can do anything that is legal in C but with a garbage collected pointer there are a lot of undefined behaviors if you don't follow some restrictions. My question is how do I tell if a pointer is "garbage collected" or not? For example :- * Do not store magic values into pointers, other than null. So how do I tell if it's safe to do this for any individual pointer? What makes a pointer "garbage collected"? You cannot tell if a random pointer is owned by the GC or not. If a piece of memory is allocated not by the GC in your own function, that's fairly easy. You'll know about it thanks to calling e.g. malloc versus new or .length.
Garbage collected pointers?
In the language spec here :- https://dlang.org/spec/garbage.html#pointers_and_gc It refers to a distinction between pointers to garbage collected memory and pointers that are not. In particular it says that with a non garbage collected pointer you can do anything that is legal in C but with a garbage collected pointer there are a lot of undefined behaviors if you don't follow some restrictions. My question is how do I tell if a pointer is "garbage collected" or not? For example :- * Do not store magic values into pointers, other than null. So how do I tell if it's safe to do this for any individual pointer? What makes a pointer "garbage collected"?
Re: Slide - what does withPartial do?
On Thursday, 1 March 2018 at 08:31:05 UTC, Piotr Mitana wrote: For some reason this is true: slide!(Yes.withPartial)([1, 2, 3, 4, 5], 3).array == [[1, 2, 3], [2, 3, 4], [3, 4, 5]] Shouldn't it rather return [[1], [1, 2], [1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5], [5]], or at least [[1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5], [5]]? I can see no difference on the result when withPartial is on and off. Is it a bug or I don't understand it correctly? It seems it should only do anything when the window size is larger than the range being iterated over. So something like slide!(Yes.withPartial)([0,1,2], 4).array = [[0,1,2]]. -- Simen
Slide - what does withPartial do?
For some reason this is true: slide!(Yes.withPartial)([1, 2, 3, 4, 5], 3).array == [[1, 2, 3], [2, 3, 4], [3, 4, 5]] Shouldn't it rather return [[1], [1, 2], [1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5], [5]], or at least [[1, 2, 3], [2, 3, 4], [3, 4, 5], [4, 5], [5]]? I can see no difference on the result when withPartial is on and off. Is it a bug or I don't understand it correctly?
