- Haskell-Cafe - Haskell.org

Dependent types, weak references, and stable names
by David Feuer 29 Aug '18

29 Aug '18

I just realized that dependent types should let us do some things with weak references and stable names less awkwardly. In particular, there are two invariants that are not (and cannot be) expressed in the type system at present: 1. If two stable names are equal, then their underlying objects are equal. 2. If a weak reference was built using a key and a value, and the key is alive, then the value is also alive. I hope we'll be able to express these with Dependent Haskell, using whatever the real syntax will be. data Weak :: k -> Type -> Type mkWeak :: (key :: k) -> v -> IO () -> IO (Weak key v) deRefWeakSurely :: (key :: k) -> Weak key v -> IO v -- Intentionally omitted: finalize data StableName :: k -> Type makeStableName :: (key :: k) -> IO (StableName key) eqStableName :: StableName x -> StableName y -> Maybe (x :~: y) The idea is that we can calculate the StableName of a key, look for that that in a hash table of weak pointers, and if we find it, we get evidence that we can use to dereference the weak pointer (deRefWeakSurely would use touch# under the hood, but that's not our concern).

2 1

Setting RTS thread names useful?
by Viktor Dukhovni 28 Aug '18

28 Aug '18

The RTS sets thread names on Linux, but not other POSIX platforms. FreeBSD has the requesite functionality, and the patch below can enable it. Not sure whether this is in fact useful, since all threads would get the same name ("ghc_worker"): diff --git a/rts/posix/OSThreads.c b/rts/posix/OSThreads.c index 7dcf0eed15..9d2d9a897e 100644 --- a/rts/posix/OSThreads.c +++ b/rts/posix/OSThreads.c @@ -139,6 +139,9 @@ createOSThread (OSThreadId* pId, char *name STG_UNUSED, pthread_detach(*pId); #if defined(HAVE_PTHREAD_SETNAME_NP) pthread_setname_np(*pId, name); +#elif defined(freebsd_HOST_OS) + /* Since FreeBSD 5.1 */ + pthread_set_name_np(*pId, name); #endif } return result; On Linux the thread name is taken from the static variable "program_invocation_short_name", which is again the same for all threads of each program, but is not globally the same. FreeBSD could get the same result with getprogname(3). The question still remains as to whether setting such thread names is useful or pointless... -- Viktor.

2 1

Re: [Haskell-cafe] Ghc error messages on Windows
by Olaf Klinke 28 Aug '18

28 Aug '18

Kees, the strange symbols are escape codes for coloring the output. Newer GHCs color the error messages, and what you see is when GHC thinks it prints to a color terminal but the terminal can not handle colors. I don't know how to switch that off, though. Olaf

1 0

Mapping of async tasks to threads?
by Viktor Dukhovni 28 Aug '18

28 Aug '18

I have an application that is largely latency-bound, it operates on hundreds of concurrent DNS lookup tasks, to process workloads of millions to tens of millions such tasks. Each task is spawned via Control.Concurrent.Async.async, and the code is compiled with "-threaded", and runs with the "capability" count set to 4: $ ps -o command= -p $(pgrep -x danescan) danescan ... +RTS -N4 ... The main task collects batches of outputs from the worker tasks and stores the results in a database. With the worker count set to 350, looking at per-thread "ps" output on FreeBSD, I see 24 threads of which 3 look idle, 20 seem to be doing the DNS work (with a few noticeably less than the rest), and one is the main thread doing the database updates: $ ps -o pid,lwp,time,mwchan,msgrcv,msgsnd,state -H -p $(pgrep -x danescan) | sort -k5n PID LWP TIME MWCHAN MSGRCV MSGSND STAT 38083 100763 0:00.00 uwait 0 0 I+ 38083 101152 0:00.00 uwait 0 0 I+ 38083 101922 0:00.00 uwait 0 0 I+ 38083 101343 0:02.29 uwait 27194 27627 I+ 38083 101335 0:04.30 uwait 51689 52517 I+ 38083 101391 0:13.33 uwait 173618 177160 S+ 38083 101917 0:22.63 kqread 295420 300894 S+ 38083 101362 0:28.73 uwait 371419 378350 I+ 38083 101349 0:46.11 uwait 594307 604816 I+ 38083 101352 0:49.65 uwait 641703 653557 S+ 38083 101370 0:53.93 select 699057 712217 S+ 38083 101358 0:58.15 uwait 757636 771437 S+ 38083 101376 1:00.84 kqread 794335 809328 S+ 38083 101375 1:02.31 uwait 806276 821284 S+ 38083 101342 1:02.34 uwait 809367 823963 S+ 38083 101244 1:03.26 select 812395 827329 S+ 38083 101360 1:03.47 uwait 815955 831710 S+ 38083 101356 1:03.03 uwait 818215 833649 I+ 38083 101364 1:03.54 uwait 825807 841300 S+ 38083 101347 1:03.89 uwait 832981 848893 S+ 38083 101334 1:04.42 kqread 836132 851386 S+ 38083 101357 1:06.04 uwait 859308 875754 S+ 38083 101134 1:06.67 kqread 859410 875176 S+ 38083 100655 5:36.98 uwait 11780649 11780685 S+ The number of open UDP DNS query sockets matches what I expect (each active query uses a fresh socket, closing it when the results arrive): $ lsof -n -P -i -a -p $(pgrep -x danescan) | egrep -c '(TCP|UDP).*:53$' 349 How is the actual thread count related to the RTS "-N" option? I did not expect to see 20 threads... -- Viktor.

1 0

Re: [Haskell-cafe] Alternative instance for non-backtracking parsers
by Olaf Klinke 28 Aug '18

28 Aug '18

Thanks to Doaitse for the example. I yet have to wrap my head around it (since I don't know how pChainr is related to <|>) but playing with q parsing the empty string is a good start. When you said > One might expect <|> to be associative, but even that is in no way guaranteed. I suppose you meant that type class laws can not be enforced, because the documentation of Alternative states that <|> should be associative. It would be quite horrible if the Alternative instances of parsers weren't. @Paul: I think that parser combinator libraries are one of the most wonderful things functional programming has given us. How else would you parse your input data? Anything cobbled together manually with the help of some Read instances is bound to be unmaintainable and does not yield good error messages. What would you suggest as a replacement? How would you write composable parsers for a complicated file type? Today I added a 'try' method to my MonadParse type class. This lets me write (try p <|> q) generically. An instance for Attoparsec would declare try=id, since it always backtracks. We'll see how this goes. What I learned form this thread is: * arrange your usages of <|> so that both sides can never share a common prefix, then no backtracking will be necessary * for that reason, some parsers like Megaparsec define their Alternative instances the way they do, without backtracking. Please allow one more question: Is the backtracking performance penalty linear in the amount of backtracking? That is, suppose that p = char '-' >> someHugeParser q = char '-' >> anotherHugeParser Could (try p <|> q) decide after seeing two characters that p fails and commit to the second branch, freeing memory? Thanks, Olaf

3 2

Ghc error messages on Windows
by Kees Bleijenberg 28 Aug '18

28 Aug '18

I've installed stack on Windows 7 64 bits. When I do "stack build" I get the output below. It looks like a character encoding problem. The generated executable is okay. This problems exists with all projects. Stack uses ghc version 8.4.3? Kees d:\haskell\Sudoku>stack build [0mSudoku-0.1.0.0: unregistering (local file changes: src\CalcSudoku.hs)[0m [0mSudoku-0.1.0.0: build (lib + exe)[0m [0mPreprocessing library for Sudoku-0.1.0.0..[0m [0mBuilding library for Sudoku-0.1.0.0..[0m [0m[2 of 3] Compiling SudokuTypes ( src\SudokuTypes.hs, .stack-work\dist\7 d103d30\build\SudokuTypes.o )[0m [0m[3 of 3] Compiling CalcSudoku ( src\CalcSudoku.hs, .stack-work\dist\7d 103d30\build\CalcSudoku.o )[0m [0m[0m [0m[;1msrc\CalcSudoku.hs:181:1: [;1m[31merror:[0m[0m[;1m[0m[0m[;1m[0m [0m parse error (possibly incorrect indentation or mismatched brackets)[0m [0m[0m [0m[;1m[34m |[0m[0m[0m [0m[;1m[34m181 |[0m[0m [;1m[31mg[0m[0metMin :: [a] -> [a -> Int] -> a [0m[;1m[34m |[0m[0m[;1m[31m ^[0m[0m[0m [0m[0m[0m[0m[0m

2 1

Does GADTs imply ExistentialQuantification?
by Cosmia Fu 27 Aug '18

27 Aug '18

Hey everyone, I found that it seems that GADTs implies ExistentialQuantification, but not mentioned in the manual. Is it a bug? https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs -XExplicitForAll Prelude> data Q = forall a. Q a Prelude> ---- Cosmia Fu

4 4

Munich Haskell Meeting, 2018-08-30 @ 19:30
by Leah Neukirchen 27 Aug '18

27 Aug '18

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, August 30 at Cafe Puck at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-aug-2018/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

1 0

OT: compiler writing like company from EU like country having made more than 3e6 sales?
by Marc Weber 26 Aug '18

26 Aug '18

Eventually its possible to get 150K of funding from EU to move 'knowledge' into Kosovo/Albania. I've been missing a simple compiler with some features for a long time. This might be a chance to get it done. By features I mean - discus like region typing - ur like mixing of server/client lanugage - quick and dirty way to implement type level type deducations. Eg matrix * matrix => new type so that you also can type databases and the like. I know that Haskell is touring complete in this regard, but it also should be fast. - macro programming Reply to this thread or private message if you think you own a company which have been working in hosting or package management or the like and is located within Europe including Switzerland. Marc Weber

1 0

Blog post about modelling state machines with free categories
by Marcin Szamotulski 25 Aug '18

25 Aug '18

Hello, I wrote a blog post about modelling state machines with free categories: https://marcinszamotulski.me/posts/finite-state-machines.html Best regards, Marcin Sent with ProtonMail Secure Email.

1 0