Re: Phab: conditional approval
On 19 August 2017 at 03:56, Richard Eisenberg wrote: > Hi devs, > > When reviewing a diff on Phab, I can "accept" or "request changes". > Sometimes, though, I want to do both: I suggest very minor (e.g., typo) > changes, but then when these changes are made, I accept. I'm leery of > making the suggestions and saying "accept", because then someone working > quickly may merge without noticing the typos. Does Phab have such an option? > "Accept with nits" is standard practice, but you're right it can go wrong when someone else is merging accepted diffs. We could adopt a standard comment keyword, e.g. "NITS" that indicates you'd like the nits to be fixed before committing, perhaps? Also, I don't think it's a good idea to merge commits when the author is a committer, they can land themselves. Cheers Simon > Thanks, > Richard > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Semigroup repeat (base package)
No. Functions like foldl1 are named such because they start building a value with the first (“1”) value of a list and consequently do not work with empty lists. They have counterparts without the “1” in their names, which receive the initial value as an extra argument. Things are completely different with cycle1, which does not even take a list. All the best, Wolfgang Am Dienstag, den 12.09.2017, 09:19 +0200 schrieb Sebastian Graf: > It's the same convention as with other Semigroup-like functions, such > as `foldl1`, `scanl1`, etc. > Doesn't really makes sense to distinguish between `cycle` and `cycle1` > in this case, but that's just bike shedding. > > Also, at some point in the future, `cycle` can go in `Data.OldList` > and be replaced by `cycle1`, renamed accordingly. > > On Mon, Sep 11, 2017 at 10:12 PM, Wolfgang Jeltsch > h.info> wrote: > > Am Montag, den 11.09.2017, 06:55 +0530 schrieb Harendra Kumar: > > > On 11 September 2017 at 02:46, Wolfgang Jeltsch wrote: > > > > Am Sonntag, den 10.09.2017, 10:39 +0200 schrieb Herbert Valerio > > > > Riedel: > > > > > What you seem to be searching for looks more like what we know > > as > > > > > `cycle :: [a] -> [a]`, and in fact there is its generalisation > > at > > > > > > > > > > http://hackage.haskell.org/package/base-4.10.0.0/docs/Data-Sem > > igroup.html#v:cycle1 > > > > > > > > Why is this function called cycle1, not cycle? What does the “1” > > > > stand for? > > > > > > I guess this is not named "cycle" to avoid conflict with > > > "Data.List.cycle". > > > > Why? We have qualified imports. It seems very wrong to add single > > characters to identifiers to denote name spaces. > > > > > I was also wondering why it is "cycle1" instead of, say "scycle". > > It > > > can be thought of as cycling just one value instead of cycling a > > list > > > in case of "Data.List.cycle". > > > > Also Data.List.cycle cycles only one value. It is just that this > > single > > value happens to be a list. If you specialize cycle1 to the list > > monoid, > > you get exactly Data.List.cycle. > > > > All the best, > > Wolfgang > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC Threads affinity
Hi, Here is a simple diagram of forkIO, forkOn and forkOS: https://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=69 Regards, Takenobu 2017-09-11 21:54 GMT+09:00 Michael Baikov : > > >> I'm developing a program that contains several kinds of threads - those > that do little work and sensitive to latency and those that can spend more > CPU time and less latency sensitive. I looked into several cases of > increased latency in those sensitive threads (using GHC eventlog) and in > all cases sensitive threads were waiting for non-sensitive threads to > finish working. I was able to reduce worst case latency by factor of 10 by > pinning all the threads in the program to specific capability but manually > distributing threads (60+ of them) between capabilities (several different > machines with different numbers of cores available) seems very fragile. > World stopping GC is still a problem but at least in my case is much less > frequently so. > > > > If you have a fixed set of threads you might just want to use > -N -qn, and then pin every thread to a different > capability. This gives you 1:1 scheduling at the GHC level, delegating the > scheduling job to the OS. You will also want to use nursery chunks with > something like -n2m, so you don't waste too much nursery space on the idle > capabilities. > > > > Even if your set of threads isn't fixed you might be able to use a > hybrid scheme with -N -qn and pin the high-priority threads > on their own capability, while putting all the low-priority threads on a > single capability, or a few separate ones. > > There's about 80 threads right now and some of them are very short lived. > Most of them are low priority and require lots of CPU which means having to > manually distribute them over several capabilities - this process I'd like > to avoid. > > >> It would be nice to be able to allow GHC runtime to migrate a thread > between a subset of capabilities using interface similar to this one: > >> > >> -- creates a thread that is allowed to migrate between capabilities > according to following rule: ghc is allowed to run this thread on Nth > capability if Nth `mod` size_of_word bit in mask is set. > >> forkOn' :: Int -> IO () -> IO ThreadId > >> forkOn' mask act = undefined > >> > >> This should allow to define up to 64 (32) distinct groups and allow > user to break down their threads into bigger number of potentially > intersecting groups by specifying things like capability 0 does latency > sensitive things, caps 1..5 - less sensitive things, caps 6-7 bulk things. > > > > > > We could do this, but it would add some complexity to the scheduler and > load balancer (which has already been quite hard to get right, I fixed a > handful of bugs there recently). I'd be happy review a patch if you want to > try it though. > > > I guess I'll start by studying the scheduler and load balancer in more > details. Thank you for your input Simon! > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Semigroup repeat (base package)
It's the same convention as with other Semigroup-like functions, such as `foldl1`, `scanl1`, etc. Doesn't really makes sense to distinguish between `cycle` and `cycle1` in this case, but that's just bike shedding. Also, at some point in the future, `cycle` can go in `Data.OldList` and be replaced by `cycle1`, renamed accordingly. On Mon, Sep 11, 2017 at 10:12 PM, Wolfgang Jeltsch wrote: > Am Montag, den 11.09.2017, 06:55 +0530 schrieb Harendra Kumar: > > On 11 September 2017 at 02:46, Wolfgang Jeltsch wrote: > > > Am Sonntag, den 10.09.2017, 10:39 +0200 schrieb Herbert Valerio > > > Riedel: > > > > What you seem to be searching for looks more like what we know as > > > > `cycle :: [a] -> [a]`, and in fact there is its generalisation at > > > > > > > > http://hackage.haskell.org/package/base-4.10.0.0/docs/ > Data-Semigroup.html#v:cycle1 > > > > > > Why is this function called cycle1, not cycle? What does the “1” > > > stand for? > > > > I guess this is not named "cycle" to avoid conflict with > > "Data.List.cycle". > > Why? We have qualified imports. It seems very wrong to add single > characters to identifiers to denote name spaces. > > > I was also wondering why it is "cycle1" instead of, say "scycle". It > > can be thought of as cycling just one value instead of cycling a list > > in case of "Data.List.cycle". > > Also Data.List.cycle cycles only one value. It is just that this single > value happens to be a list. If you specialize cycle1 to the list monoid, > you get exactly Data.List.cycle. > > All the best, > Wolfgang > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
