Re: What type does byGrapheme() return?
On Sat, Jan 04, 2020 at 08:19:14PM +0100, Robert M. Münch via Digitalmars-d-learn wrote: > On 2019-12-31 21:36:56 +, Steven Schveighoffer said: > > > The fact that a Grapheme's return requires you keep the grapheme in > > scope for operations seems completely incorrect and dangerous IMO > > (note that operators are going to always have a ref this, even when > > called on an rvalue). So even though using ref works, I think the > > underlying issue here really is the lifetime problem. > > Thanks for all the answers, pretty enlighting even I'm not sure I get > everything 100%. > > So, what to do for now? File a bug-report? What needs to be fixed? At a minimum, I think we should file a bug report to investigate whether Grapheme.opSlice can be implemented differently, such that we avoid this obscure referential behaviour that makes it hard to work with in complex code. I'm not sure if this is possible, but IMO we should at least investigate the possibilities. > I'm using the ref approach for now, in hope it will be OK for my > use-case, which is converting a wstring to a grapheme[], alter the > array, and map it back to a wstring. Sounds like a lot of porcessing > for handling unicode text, but I don't think it gets a lot simpler > than that. [...] Unicode is a beast. Be glad that you can even do this in the first place. If I were writing this in C, I wouldn't even know where to begin! T -- No! I'm not in denial!
Re: Multi-threaded sorting of text file
On 1/3/20 11:51 PM, MGW wrote: Need help: There' s a large text file (hundreds of thousands of lines). How long are the lines? If 1K bytes, 100M would fit in memory just fine. There is a parallel quick sort example on the std.parallelism page: https://dlang.org/phobos/std_parallelism.html The structure is as follows: 2345|wedwededwedwedwe .. 872625|rfrferwewweww . 23|rergrferfefer . It is necessary to sort this file by the first field having received: 23|rergrferfefer... 2345|wedwededwedwedwe... 872625|rfrferwewweww... Are you going to write the result back to a file? Then you would hardly notice any improvement from parallelism because relative slowness of I/O would determine the overall performance. There are also N CPU (from 4 to 8) and 16 Gb of Memory. Necessary come up with an algorithm in D for fast sorting using multithreading. Ali
Re: decodeGrapheme & static array
On Saturday, 4 January 2020 at 19:56:54 UTC, Robert M. Münch wrote: But it doesn't seem to be an L-value... which I don't understand. I thought buf[] returns a temporary dynamic array initialized with the buf content. The problem here is indeed ref, the function there tries to update the slice so it point to the next element and that requires a named variable. Generally speaking, if your thing is not tied directly to a named variable it can update, it cannot be ref. So your buf[] there refers to a named variable, which is good enough... but the [] cannot possibly update because buf is statically sized. Just assigning to a temporary in the middle can fix this for you: dchar[] remainingItems = buf[]; decode(remainingItems); // note that length of remainingItems will now be smaller than it started
decodeGrapheme & static array
I have: Grapheme[] gr; dchar[1] buf; encode(buf, cast(dchar)myData); gr =~ decodeGrapheme(buf[]); Which gives: Error: template std.uni.decodeGrapheme cannot deduce function from argument types !()(dchar[]), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\uni.d(7164,10): decodeGrapheme(Input)(ref Input inp) I some how need an InputRange for buf and though that buf[] should work. But it doesn't seem to be an L-value... which I don't understand. I thought buf[] returns a temporary dynamic array initialized with the buf content. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: What type does byGrapheme() return?
On 2019-12-31 21:36:56 +, Steven Schveighoffer said: The fact that a Grapheme's return requires you keep the grapheme in scope for operations seems completely incorrect and dangerous IMO (note that operators are going to always have a ref this, even when called on an rvalue). So even though using ref works, I think the underlying issue here really is the lifetime problem. Thanks for all the answers, pretty enlighting even I'm not sure I get everything 100%. So, what to do for now? File a bug-report? What needs to be fixed? I'm using the ref approach for now, in hope it will be OK for my use-case, which is converting a wstring to a grapheme[], alter the array, and map it back to a wstring. Sounds like a lot of porcessing for handling unicode text, but I don't think it gets a lot simpler than that. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Project setup for DUB
On Wednesday, 1 January 2020 at 13:19:20 UTC, Andre Pany wrote: In addition to that, there are different ways how you can contribute to Dub: - enhancing the dub help on code.dlang.org Does anyone know dub well enough to do this? :)
Re: Project setup for DUB
On Wednesday, 1 January 2020 at 13:19:20 UTC, Andre Pany wrote: On Wednesday, 1 January 2020 at 08:37:43 UTC, rikki cattermole wrote: In addition to that, there are different ways how you can contribute to Dub: - enhancing the dub help on code.dlang.org - finding duplicate/already solved issues on the github issue tracker Especially the issues list is a good starting point for new contributors to get some ideas how to contribute. Kind regards Andre Thanks. I'll definitely look at some issues on the issue tracker.
Re: Mimicking a shell
On Saturday, 4 January 2020 at 18:43:13 UTC, Jan wrote: I am using Linux (Fedora). ok, the starting point is `openpty` which gives you a communication pipe that the other program sees as a terminal. from there if you are just forwarding you can perhaps shoot bytes to and from without interpreting them. but if you want to send like a synthetic arrow keystroke, well, things get ugly again, it will need to send the right series of bytes based on what terminal the program thinks you are. Like "\033[C" is right arrow on xterm, probably a reasonably safe bet you can make that work. hit ctrl+v then a key in your terminal to see the output. ^[ == "\033" btw there. Thanks, @angel. I'll take a look at your suggestion :) yes good luck!
Re: Project setup for DUB
On Wednesday, 1 January 2020 at 08:37:43 UTC, rikki cattermole wrote: On 01/01/2020 9:11 PM, Ankush Bhardwaj wrote: I am now stuck here not knowing what should I do next or how should I compile. Compile what? You successfully compiled and ran your dub build. Please note the default action is to run, so using `dub` by itself is equivalent to `dub run`. Hence the recursive executions. Use `dub build` if all you want to do is build. Oops, my bad. For some reason, `build` happened again and again. It didn't stop after building once. Anyways `dub build` worked. Thanks :D
Re: Mimicking a shell
On Sunday, 29 December 2019 at 19:21:53 UTC, Adam D. Ruppe wrote: On Sunday, 29 December 2019 at 17:03:14 UTC, Jan wrote: Is there a way to forward all input and output from a shell? yes, but it is platform specific and can be a decent amount of code. what OS are you on? I am using Linux (Fedora). Thanks, @angel. I'll take a look at your suggestion :)
Re: Using tasks without GC?
Creates a Task on the GC heap that calls an alias.
If possible, there's also scopedTask, which allocates on the stack:
https://dlang.org/phobos/std_parallelism.html#.scopedTask
So my question is: Has anyone done any analysis over how "dangerous" it is to use GC'd tasks for
_small_ tasks (in terms of milliseconds)?
Nothing major, but https://github.com/mratsim/weave/tree/master/benchmarks/fibonacci puts quite a
bit of pressure on various implementations. You might want to profile ./pfib 40:
import std;
ulong fib(uint n) {
if (n < 2) return n;
auto x = scopedTask!fib(n-1); // vs. Task!fib(n-1);
taskPool.put(x);
auto y = fib(n-2);
return x.yieldForce + y; // {yield,spin,work}Force
}
void main(string[] args) {
enforce(args.length == 2, "Usage: fib ");
auto n = args[1].to!uint;
// defaultPoolThreads(totalCPUs);
writefln!"fib(%d) = %d"(n, fib(n));
}
At least D isn't locking up beyond 12 tasks; looking at you, stdlib-nim. :)
Re: Multi-threaded sorting of text file
On Saturday, 4 January 2020 at 07:51:49 UTC, MGW wrote: Need help: There' s a large text file (hundreds of thousands of lines). The structure is as follows: 2345|wedwededwedwedwe .. 872625|rfrferwewweww . 23|rergrferfefer It is necessary to sort this file by the first field having received: 23|rergrferfefer... 2345|wedwededwedwedwe... 872625|rfrferwewweww... There are also N CPU (from 4 to 8) and 16 Gb of Memory. Necessary come up with an algorithm in D for fast sorting using multithreading. As far as I know, there isn't any native in D. Maybe I overlooked some at code.dlang.org. But there are plenty out there in the wild. Found this on the first shoot: https://stackoverflow.com/questions/23531625/multithreaded-sorting-application/23532317
