Re: Why and How the External STG interpreter is Useful (Online presentation, Dec 2, Friday, 17:00 UTC)

2021-12-02 Thread YueCompl via ghc-devs
This sounds pretty exciting! Can we expect a full fledged stepping debugger integrated with IDEs via https://github.com/phoityne/haskell-debug-adapter ? https://github.com/phoityne/ghci-dap is still qui

Re: Potential improvement in compacting GC

2021-07-14 Thread YueCompl via ghc-devs
Greetings! I'd like to take this opportunity to ask you experts about feasibility / technology-readiness of distributed GC, that I've recently been pondering with the idea to have a distributed GC managing shared heap across multiple server nodes, those inter-connected through fast ethernet.

Re: What's the modern way to apply a polymorphic function to a Dynamic value in GHC 8.8 and onwards?

2021-04-13 Thread YueCompl via ghc-devs
to reach the solution? I anticipate improvements but apparently lack expertise for progress, I tried `Just {}` and it won't compile already... I mean, things are already great as far, well, maybe the learning experience can be made even better. Best, Compl > On 2021-04-13, at 22:07

Re: What's the modern way to apply a polymorphic function to a Dynamic value in GHC 8.8 and onwards?

2021-04-13 Thread YueCompl via ghc-devs
After struggled this far, I decide that I can neither trivially understand `pattern TypeRep`, nor the `withTypeable` at core. But this is what really amazing with Haskell, GHC and the community here - I can get my job done even without full understanding of what's going on under the hood, so lon

Re: What's the modern way to apply a polymorphic function to a Dynamic value in GHC 8.8 and onwards?

2021-04-12 Thread YueCompl via ghc-devs
Dynamic (App eventSink TypeRep) evs' -> | ^^^... ``` I need to work out some extra stuff to test the solution in real case, meanwhile this warning seems worrying ... > On 2021-04-13, at 00:27, YueCompl via ghc-devs wrote: > > Thanks

Re: What's the modern way to apply a polymorphic function to a Dynamic value in GHC 8.8 and onwards?

2021-04-12 Thread YueCompl via ghc-devs
pe-Reflection.html#v:eqTypeRep> > [2] > https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Dynamic.html#v:dynApply > > <https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Dynamic.html#v:dynApply> > On Mon, 12 Apr 2021 at 16:15, YueCompl via ghc-devs <mail

Re: What's the modern way to apply a polymorphic function to a Dynamic value in GHC 8.8 and onwards?

2021-04-12 Thread YueCompl via ghc-devs
``` > > Cheers, > > Jaro > On 2021-04-12, at 21:06, Vladislav Zavialov wrote: > > Would something like this work for you? > > import Type.Reflection > import Data.Dynamic > > apD :: Typeable f => (forall a. a -> f a) -> Dynamic -> Dynamic

What's the modern way to apply a polymorphic function to a Dynamic value in GHC 8.8 and onwards?

2021-04-12 Thread YueCompl via ghc-devs
Dear Cafe and GHC devs, There used to be a "principled way with pattern match on the constructor": ```hs data Dynamic where Dynamic :: Typeable a => a -> Dynamic apD :: Typeable f => (forall a. a -> f a) -> Dynamic -> Dynamic apD f (Dynamic a) = Dynamic $ f a ``` Source: https://www.reddit.c

Re: How to ensure optimization for large immutable vectors to be shared w.r.t. Referential Transparency

2021-04-06 Thread YueCompl via ghc-devs
ng by it, right. But I still think that with a single piece of `let-in` construct, types are better to be inferred as specific as possible, then the result would not be affected by some extension's semantics modification. Here v's type can obviously be inferred to `VS.Vector Int` accordi

Re: How to ensure optimization for large immutable vectors to be shared w.r.t. Referential Transparency

2021-04-06 Thread YueCompl via ghc-devs
;ve learned it today :D > On 2021-04-06, at 21:51, Viktor Dukhovni wrote: > > On Tue, Apr 06, 2021 at 07:12:51PM +0800, YueCompl via ghc-devs wrote: > >> λ> import Control.Monad.ST >> λ> import qualified Data.Vector.Storable as VS >> λ> >> λ>

Re: [Haskell-cafe] How to ensure optimization for large immutable vectors to be shared w.r.t. Referential Transparency

2021-04-06 Thread YueCompl via ghc-devs
Appears it'd work as expected when the immutable vector is originally created from foreign ptr, I think it'll work for my cases. (Though it's still strangely unexpected for ad hoc immutable vectors unshared when wrapped.) ```hs λ> :set -XBangPatterns λ> λ> :set -package vector package flags ha

Re: [Haskell-cafe] How to ensure optimization for large immutable vectors to be shared w.r.t. Referential Transparency

2021-04-06 Thread YueCompl via ghc-devs
```hs λ> let !v = VS.fromList [3,2,5] in isSameVector (SomeVector v) (SomeVector v) False λ> λ> let !v = SomeVector (VS.fromList [3,2,5]) in isSameVector v v True λ> ``` > On 2021-04-06, at 20:34, Henning Thielemann > wrote: > > > On Tue, 6 Apr 2021, YueCompl wrote: > >> Thanks, it's a good

Re: [Haskell-cafe] How to ensure optimization for large immutable vectors to be shared w.r.t. Referential Transparency

2021-04-06 Thread YueCompl via ghc-devs
Thanks, it's a good idea. Unfortunately the result remains, making me even more curious. ```hs λ> :set -XBangPatterns λ> λ> :set -package vector package flags have changed, resetting and loading new packages... λ> λ> import Prelude λ> λ> import Control.Monad.ST λ> import qualified Data.Vector.

How to ensure optimization for large immutable vectors to be shared w.r.t. Referential Transparency

2021-04-06 Thread YueCompl via ghc-devs
Hello Cafe and respected GHC Devs, I would like to ensure some immutable vectors (can be quite large) are always shared instead of copied, and I think that should be straight forward w.r.t. referential transparency we enjoy. In an attempt to determine whether two immutable vectors can be treate

How to get dwarf stack trace of all live threads (HECs) on demand (e.g. SIGQUIT)?

2021-01-07 Thread YueCompl via ghc-devs
Dear GHC devs, I recently encountered 100% ~ 400% CPU hogging situations to trouble-shoot, I managed to build and use a dwarf enabled GHC-8.10.3 on Ubuntu 18.04 and 20.04 for that, then I find it seemingly dumps only the main thread's stack trace when I press Ctrl+\, but my program is a concurr

Re: [Haskell-cafe] For STM to practically serve large in-mem datasets with cyclic structures WAS: STM friendly TreeMap (or similar with range scan api) ? WAS: Best ways to achieve throughput, for larg

2020-07-30 Thread YueCompl via ghc-devs
n't imagine even feasibility of this technique. And even the new > nonmoving GC may have similar difficulty to jump out of a circle when > following pointers. FYI > On 2020-07-30, at 21:53, YueCompl via ghc-devs wrote: > > Dear GHC Devs, > > I realize I should seek

Fwd: [Haskell-cafe] For STM to practically serve large in-mem datasets with cyclic structures WAS: STM friendly TreeMap (or similar with range scan api) ? WAS: Best ways to achieve throughput, for lar

2020-07-30 Thread YueCompl via ghc-devs
Dear GHC Devs, I realize I should seek your helps regarding my current situation. TL;DR the most serious suffering is: After the heap loaded with many TVars with cyclic structures, GC will dominate my CPU utilization with little business progressing. Nonmoving GC `-xn` with 8.10.1 helps, but t