From magicloud.magiclouds at gmail.com Wed May 1 06:43:20 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Wed, 1 May 2019 14:43:20 +0800 Subject: [Haskell-cafe] Trying to find a Haskell unikernel project which is not HaLVM. Message-ID: Hi, About half an year ago, while I was digging a sanity check issue in 8.6.1, I accidently got a Trac mentioning a Haskell unikernel project. The name is H prefixed (apparently), and a bit of long. Now I am trying to dig more on that project, but could not find it anywhere. Does anyone have a clue? Thanks. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From ky3 at atamo.com Wed May 1 08:13:45 2019 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 1 May 2019 15:13:45 +0700 Subject: [Haskell-cafe] Trying to find a Haskell unikernel project which is not HaLVM. In-Reply-To: References: Message-ID: On Wed, May 1, 2019 at 1:44 PM Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Hi, > > About half an year ago, while I was digging a sanity check issue in > 8.6.1, I accidently got a Trac mentioning a Haskell unikernel project. > The name is H prefixed (apparently), and a bit of long. Are you thinking of House? https://en.m.wikipedia.org/wiki/House_(operating_system) > > Now I am trying to dig more on that project, but could not find it > anywhere. Does anyone have a clue? Thanks. > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Wed May 1 08:51:57 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Wed, 1 May 2019 16:51:57 +0800 Subject: [Haskell-cafe] Trying to find a Haskell unikernel project which is not HaLVM. In-Reply-To: References: Message-ID: Does not feel like it. And I think I saw somewhere that the one I am looking for is based on Linux, not a whole kernel, especially no GUI. On Wed, May 1, 2019 at 4:13 PM Kim-Ee Yeoh wrote: > > > > On Wed, May 1, 2019 at 1:44 PM Magicloud Magiclouds wrote: >> >> Hi, >> >> About half an year ago, while I was digging a sanity check issue in >> 8.6.1, I accidently got a Trac mentioning a Haskell unikernel project. >> The name is H prefixed (apparently), and a bit of long. > > > Are you thinking of House? > > https://en.m.wikipedia.org/wiki/House_(operating_system) > > >> >> >> Now I am trying to dig more on that project, but could not find it >> anywhere. Does anyone have a clue? Thanks. >> >> -- >> 竹密岂妨流水过 >> 山高哪阻野云飞 >> >> And for G+, please use magiclouds#gmail.com. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -- > -- Kim-Ee -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From sylvain at haskus.fr Wed May 1 10:21:22 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 01 May 2019 12:21:22 +0200 Subject: [Haskell-cafe] Trying to find a Haskell unikernel project which is not HaLVM. In-Reply-To: References: Message-ID: It might be my haskus-system project: https://haskus.org/system/ Sylvain ⁣ Le 1 mai 2019 à 10:53, à 10:53, Magicloud Magiclouds a écrit: >Does not feel like it. And I think I saw somewhere that the one I am >looking for is based on Linux, not a whole kernel, especially no GUI. > >On Wed, May 1, 2019 at 4:13 PM Kim-Ee Yeoh wrote: >> >> >> >> On Wed, May 1, 2019 at 1:44 PM Magicloud Magiclouds > wrote: >>> >>> Hi, >>> >>> About half an year ago, while I was digging a sanity check issue in >>> 8.6.1, I accidently got a Trac mentioning a Haskell unikernel >project. >>> The name is H prefixed (apparently), and a bit of long. >> >> >> Are you thinking of House? >> >> https://en.m.wikipedia.org/wiki/House_(operating_system) >> >> >>> >>> >>> Now I am trying to dig more on that project, but could not find it >>> anywhere. Does anyone have a clue? Thanks. >>> >>> -- >>> 竹密岂妨流水过 >>> 山高哪阻野云飞 >>> >>> And for G+, please use magiclouds#gmail.com. >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> -- >> -- Kim-Ee > > > >-- >竹密岂妨流水过 >山高哪阻野云飞 > >And for G+, please use magiclouds#gmail.com. >_______________________________________________ >Haskell-Cafe mailing list >To (un)subscribe, modify options or view archives go to: >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benl at ouroborus.net Wed May 1 13:34:07 2019 From: benl at ouroborus.net (Ben Lippmeier) Date: Wed, 1 May 2019 23:34:07 +1000 Subject: [Haskell-cafe] Repa array and Data.Vector.Storable.Mutable. In-Reply-To: References: Message-ID: <74DEADD7-93CC-4E67-99A2-939C7C310389@ouroborus.net> > On 26 Apr 2019, at 9:14 am, PICCA Frederic-Emmanuel wrote: > > Hello > > I would like a function which allows to freeze a Mutable Vector into a Repa array. of type Array F DIM2 a > It seems to me that the the foreignPtr ownership should be transfer to the Repa Array, but I can not find a way to do this... > > So what is the proper way to achieve this ? If it’s a boxed Data.Vector then you have to copy it, because the ForeignPtr representation is unboxed. Freeze the mutable vector with Data.Vector.freeze or unsafeFreeze, then apply Data.Array.Repa.Repr.Vector.fromVector. This gives you a boxed Repa representation, then copy it into the unboxed ForeignPtr representation with copyP. If you can build an unboxed Data.Vector.Storable instead, then apply unsafeToForeignPtr to get the guts of it, and give them to Data.Array.Repa.Repr.ForeignPtr.fromForeignPtr. Ben. From benl at ouroborus.net Wed May 1 13:45:07 2019 From: benl at ouroborus.net (Ben Lippmeier) Date: Wed, 1 May 2019 23:45:07 +1000 Subject: [Haskell-cafe] Looking for a paper In-Reply-To: <08980c64-9195-6b48-7f6f-54a58f81bfcb@orlitzky.com> References: <08980c64-9195-6b48-7f6f-54a58f81bfcb@orlitzky.com> Message-ID: <9BBD5F52-13B3-4B66-A927-EE7A954E86F2@ouroborus.net> > On 10 Apr 2019, at 12:00 am, Michael Orlitzky wrote: > > Everyone knows that parentheses suck for function application. > > But I'm looking for a CS paper that argues that function application > should have its own explicit syntax in a functional programming > language. I believe, in the paper, that a dot "." was used, but this > would be analogous to Haskell's "$" function, except that it would be > made part of the language definition. > > I think it came up on this mailing list (where else would I have seen > it?), and if anyone remembers the name or author I'd be grateful. Hi Michael, long time.. Check out: A useful lambda-notation. Fairouz Kamareddine, Rob Nederpelt. Theoretical Computer Science 115 (1996) 85-109 They use “item notation”, and argue that maybe function application isn’t what we should be writing to begin with. Ben. From michael at orlitzky.com Wed May 1 14:24:34 2019 From: michael at orlitzky.com (Michael Orlitzky) Date: Wed, 1 May 2019 10:24:34 -0400 Subject: [Haskell-cafe] Looking for a paper In-Reply-To: <9BBD5F52-13B3-4B66-A927-EE7A954E86F2@ouroborus.net> References: <08980c64-9195-6b48-7f6f-54a58f81bfcb@orlitzky.com> <9BBD5F52-13B3-4B66-A927-EE7A954E86F2@ouroborus.net> Message-ID: On 5/1/19 9:45 AM, Ben Lippmeier wrote: > > Hi Michael, long time.. > > Check out: > > A useful lambda-notation. > Fairouz Kamareddine, Rob Nederpelt. > Theoretical Computer Science 115 (1996) 85-109 > > They use “item notation”, and argue that maybe function application isn’t what we should be writing to begin with. > Thanks! This one's still a bit over my head, but I kept some category theory papers for 10+ years until I was able to read them, so I'm not afraid of this =) From magicloud.magiclouds at gmail.com Wed May 1 15:23:42 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Wed, 1 May 2019 23:23:42 +0800 Subject: [Haskell-cafe] Trying to find a Haskell unikernel project which is not HaLVM. In-Reply-To: References: Message-ID: Yes, it is. Actually, I just found the building tool already exists in my system. Thanks. On Wed, May 1, 2019 at 6:21 PM Sylvain Henry wrote: > > It might be my haskus-system project: > https://haskus.org/system/ > > Sylvain > Le 1 mai 2019, à 10:53, Magicloud Magiclouds a écrit: >> >> Does not feel like it. And I think I saw somewhere that the one I am >> looking for is based on Linux, not a whole kernel, especially no GUI. >> >> On Wed, May 1, 2019 at 4:13 PM Kim-Ee Yeoh wrote: >>> >>> >>> >>> >>> On Wed, May 1, 2019 at 1:44 PM Magicloud Magiclouds wrote: >>>> >>>> >>>> Hi, >>>> >>>> About half an year ago, while I was digging a sanity check issue in >>>> 8.6.1, I accidently got a Trac mentioning a Haskell unikernel project. >>>> The name is H prefixed (apparently), and a bit of long. >>> >>> >>> >>> Are you thinking of House? >>> >>> https://en.m.wikipedia.org/wiki/House_(operating_system) >>> >>> >>>> >>>> >>>> Now I am trying to dig more on that project, but could not find it >>>> anywhere. Does anyone have a clue? Thanks. >>>> >>>> -- >>>> 竹密岂妨流水过 >>>> 山高哪阻野云飞 >>>> >>>> And for G+, please use magiclouds#gmail.com. >>>> ________________________________ >>>> >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view archives go to: >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> Only members subscribed via the mailman list are allowed to post. >>> >>> >>> -- >>> -- Kim-Ee >> >> >> -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From sylvain at haskus.fr Wed May 1 15:33:19 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 01 May 2019 17:33:19 +0200 Subject: [Haskell-cafe] Trying to find a Haskell unikernel project which is not HaLVM. In-Reply-To: References: Message-ID: <0905bb0e-462a-4174-825d-6e9282d5cdcd@haskus.fr> Ok! Any feedback welcome :) You may need to install the git version of the build tool to support latest Linux kernels (>5.0) Le 1 mai 2019 à 17:25, à 17:25, Magicloud Magiclouds a écrit: >Yes, it is. Actually, I just found the building tool already exists in >my system. Thanks. > >On Wed, May 1, 2019 at 6:21 PM Sylvain Henry wrote: >> >> It might be my haskus-system project: >> https://haskus.org/system/ >> >> Sylvain >> Le 1 mai 2019, à 10:53, Magicloud Magiclouds > a écrit: >>> >>> Does not feel like it. And I think I saw somewhere that the one I am >>> looking for is based on Linux, not a whole kernel, especially no >GUI. >>> >>> On Wed, May 1, 2019 at 4:13 PM Kim-Ee Yeoh wrote: >>>> >>>> >>>> >>>> >>>> On Wed, May 1, 2019 at 1:44 PM Magicloud Magiclouds > wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> About half an year ago, while I was digging a sanity check issue >in >>>>> 8.6.1, I accidently got a Trac mentioning a Haskell unikernel >project. >>>>> The name is H prefixed (apparently), and a bit of long. >>>> >>>> >>>> >>>> Are you thinking of House? >>>> >>>> https://en.m.wikipedia.org/wiki/House_(operating_system) >>>> >>>> >>>>> >>>>> >>>>> Now I am trying to dig more on that project, but could not find >it >>>>> anywhere. Does anyone have a clue? Thanks. >>>>> >>>>> -- >>>>> 竹密岂妨流水过 >>>>> 山高哪阻野云飞 >>>>> >>>>> And for G+, please use magiclouds#gmail.com. >>>>> ________________________________ >>>>> >>>>> Haskell-Cafe mailing list >>>>> To (un)subscribe, modify options or view archives go to: >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> Only members subscribed via the mailman list are allowed to post. >>>> >>>> >>>> -- >>>> -- Kim-Ee >>> >>> >>> > > >-- >竹密岂妨流水过 >山高哪阻野云飞 > >And for G+, please use magiclouds#gmail.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa.mchale at iohk.io Wed May 1 21:00:03 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Wed, 1 May 2019 16:00:03 -0500 Subject: [Haskell-cafe] Static linking against X11 Message-ID: <0d891c17-7a52-fc4c-8a75-e42e44c56a96@iohk.io> Hi all, I'm trying to cross-compile xmobar for aarch64-linux-gnu. The cross compiler that comes with my version of Ubuntu works with a later GLIBC than the host platform, so I figured I'd make a static executable instead - this approach had worked with e.g. cabal-install. Unfortunately, I get the following: Resolving dependencies... Build profile: -w ghc-8.6.4 -O1 In order, the following will be built (use -v for more details):  - xmobar-vanessa-0.1.0.0 (exe:xmobar) (first run) Preprocessing executable 'xmobar' for xmobar-vanessa-0.1.0.0.. Building executable 'xmobar' for xmobar-vanessa-0.1.0.0.. Linking /home/vanessa/programming/haskell/done/xmobar-vanessa/dist-newstyle/build/aarch64-linux/ghc-8.6.4/xmobar-vanessa-0.1.0.0/x/xmobar/build/xmobar/xmobar ... /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/local/lib/aarch64-linux-gnu-ghc-8.6.4/rts/libHSrts.a(Linker.o): in function `internal_dlopen': /home/vanessa/cross/ghc-8.6.4/rts/Linker.c:600:0: error:      warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /home/vanessa/.cabal/store/ghc-8.6.4/network-3.1.0.0-b60cf17d11d7eda024959ae28f710f94d7565bcd8e3372f04f32d2600769c2c1/lib/libHSnetwork-3.1.0.0-b60cf17d11d7eda024959ae28f710f94d7565bcd8e3372f04f32d2600769c2c1.a(HsNet.o): in function `hsnet_getaddrinfo': HsNet.c:(.text+0x10): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): in function `require_socket': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:68:0: error:      undefined reference to `xcb_take_socket' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): in function `poll_for_event': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:245:0: error:      undefined reference to `xcb_poll_for_event' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:243: undefined reference to `xcb_poll_for_queued_event' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): in function `poll_for_response': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:284:0: error:      undefined reference to `xcb_poll_for_reply64' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): in function `_XSend': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:499:0: error:      undefined reference to `xcb_writev' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): in function `_XEventsQueued': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:364:0: error:      undefined reference to `xcb_connection_has_error' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): in function `_XReadEvents': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:441:0: error:      undefined reference to `xcb_connection_has_error' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:400: undefined reference to `xcb_wait_for_event' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): in function `_XAllocIDs': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:549:0: error:      undefined reference to `xcb_generate_id' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): in function `_XReply': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:609:0: error:      undefined reference to `xcb_wait_for_reply64' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(ClDisplay.o): in function `XCloseDisplay': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/ClDisplay.c:71:0: error:      undefined reference to `xcb_disconnect' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(OpenDis.o): in function `OutOfMemory': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/OpenDis.c:705:0: error:      undefined reference to `xcb_disconnect' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(OpenDis.o): in function `XOpenDisplay': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/OpenDis.c:255:0: error:      undefined reference to `xcb_get_setup' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/OpenDis.c:498: undefined reference to `xcb_get_maximum_request_length' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_disp.o): in function `_XConnectXCB': /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:69:0: error:      undefined reference to `xcb_parse_display' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:76: undefined reference to `xcb_connect_to_display_with_auth_info' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:81: undefined reference to `xcb_get_file_descriptor' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:84: undefined reference to `xcb_generate_id' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:92: undefined reference to `xcb_connection_has_error' /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:78: undefined reference to `xcb_connect' collect2: error: ld returned 1 exit status `aarch64-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1) I looked in libX11.a with nm /usr/aarch64-linux-gnu/lib/libX11.a | rg 'xcb_take_socket' which yields                  U xcb_take_socket which, as I understand, means that something is screwed up in the X11 static linking (but I know less about systems programming and linkers than Haskell). Does anyone know how to fix such a problem? Cheers, Vanessa McHale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From allbery.b at gmail.com Wed May 1 21:07:13 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 1 May 2019 17:07:13 -0400 Subject: [Haskell-cafe] Static linking against X11 In-Reply-To: <0d891c17-7a52-fc4c-8a75-e42e44c56a96@iohk.io> References: <0d891c17-7a52-fc4c-8a75-e42e44c56a96@iohk.io> Message-ID: The problem is that static archives can't declare implicit dependencies: if you link dynamically, libX11.so will implicitly depend on libxcb.so, but if you link statically you must also explicitly link against -lxcb. On Wed, May 1, 2019 at 5:00 PM Vanessa McHale wrote: > Hi all, > > I'm trying to cross-compile xmobar for aarch64-linux-gnu. The cross > compiler that comes with my version of Ubuntu works with a later GLIBC > than the host platform, so I figured I'd make a static executable > instead - this approach had worked with e.g. cabal-install. > > Unfortunately, I get the following: > > Resolving dependencies... > Build profile: -w ghc-8.6.4 -O1 > In order, the following will be built (use -v for more details): > - xmobar-vanessa-0.1.0.0 (exe:xmobar) (first run) > Preprocessing executable 'xmobar' for xmobar-vanessa-0.1.0.0.. > Building executable 'xmobar' for xmobar-vanessa-0.1.0.0.. > Linking > > /home/vanessa/programming/haskell/done/xmobar-vanessa/dist-newstyle/build/aarch64-linux/ghc-8.6.4/xmobar-vanessa-0.1.0.0/x/xmobar/build/xmobar/xmobar > ... > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > /usr/local/lib/aarch64-linux-gnu-ghc-8.6.4/rts/libHSrts.a(Linker.o): in > function `internal_dlopen': > > /home/vanessa/cross/ghc-8.6.4/rts/Linker.c:600:0: error: > warning: Using 'dlopen' in statically linked applications requires > at runtime the shared libraries from the glibc version used for linking > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /home/vanessa/.cabal/store/ghc-8.6.4/network-3.1.0.0-b60cf17d11d7eda024959ae28f710f94d7565bcd8e3372f04f32d2600769c2c1/lib/libHSnetwork-3.1.0.0-b60cf17d11d7eda024959ae28f710f94d7565bcd8e3372f04f32d2600769c2c1.a(HsNet.o): > in function `hsnet_getaddrinfo': > HsNet.c:(.text+0x10): warning: Using 'getaddrinfo' in statically linked > applications requires at runtime the shared libraries from the glibc > version used for linking > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): > in function `require_socket': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:68:0: error: > undefined reference to `xcb_take_socket' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): > in function `poll_for_event': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:245:0: error: > undefined reference to `xcb_poll_for_event' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:243: undefined > reference to `xcb_poll_for_queued_event' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): > in function `poll_for_response': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:284:0: error: > undefined reference to `xcb_poll_for_reply64' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): > in function `_XSend': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:499:0: error: > undefined reference to `xcb_writev' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): > in function `_XEventsQueued': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:364:0: error: > undefined reference to `xcb_connection_has_error' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): > in function `_XReadEvents': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:441:0: error: > undefined reference to `xcb_connection_has_error' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:400: undefined > reference to `xcb_wait_for_event' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): > in function `_XAllocIDs': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:549:0: error: > undefined reference to `xcb_generate_id' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_io.o): > in function `_XReply': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_io.c:609:0: error: > undefined reference to `xcb_wait_for_reply64' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(ClDisplay.o): > in function `XCloseDisplay': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/ClDisplay.c:71:0: error: > undefined reference to `xcb_disconnect' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(OpenDis.o): > in function `OutOfMemory': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/OpenDis.c:705:0: error: > undefined reference to `xcb_disconnect' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(OpenDis.o): > in function `XOpenDisplay': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/OpenDis.c:255:0: error: > undefined reference to `xcb_get_setup' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/OpenDis.c:498: undefined > reference to `xcb_get_maximum_request_length' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/lib/../lib/libX11.a(xcb_disp.o): > in function `_XConnectXCB': > > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:69:0: error: > undefined reference to `xcb_parse_display' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:76: undefined > reference to `xcb_connect_to_display_with_auth_info' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:81: undefined > reference to `xcb_get_file_descriptor' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:84: undefined > reference to `xcb_generate_id' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:92: undefined > reference to `xcb_connection_has_error' > > /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/ld: > /tmp/cpkg-2c6d48cdbb4678ca/libX11-1.6.7/src/xcb_disp.c:78: undefined > reference to `xcb_connect' > collect2: error: ld returned 1 exit status > `aarch64-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1) > > I looked in libX11.a with > > nm /usr/aarch64-linux-gnu/lib/libX11.a | rg 'xcb_take_socket' > > which yields > > U xcb_take_socket > > > which, as I understand, means that something is screwed up in the X11 > static linking (but I know less about systems programming and linkers > than Haskell). > > Does anyone know how to fix such a problem? > > Cheers, > Vanessa McHale > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Fri May 3 22:05:28 2019 From: gershomb at gmail.com (Gershom B) Date: Fri, 3 May 2019 18:05:28 -0400 Subject: [Haskell-cafe] Call for Participation: Compose Conference [NYC, Jun 22- 23 2019] Message-ID: =============================================== Call for Participation Compose Conference 2019 Mon June 24 - Tue June 25 2019 (Unconference on Sat Jun 22 - Sun Jun 23) New York, NY http://www.composeconference.org/2019 =============================================== The practice and craft of functional programming :: Conference Compose is a conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, SML, and related technologies. Typed functional programming has been taken up widely, by industry and hobbyists alike. For many of us it has renewed our belief that code should be beautiful, and that programming can be as enjoyable as it is practical. Compose is about bringing together functional programmers of all levels of skill and experience — from technical leads to novices, and from long-time hackers to students just getting started. It will feature a two days of great and wide-ranging talks * Invited Keynotes Donya Quick - Making Algorithmic Music David Spivak - Compositional Graphical Logic * Accepted Talks and Tutorials Kenny Foner - Functors of the World, Unite! Phillip Carter - The anatomy of the F# tools for Visual Studio Sebastien Mondet - Genspio: Generating Shell Phrases In OCaml Justin Le - Applicative Regular Expressions using the Free Alternative Gaetano Checinski - Buckaroo SAT - Solving a partially revealed SAT problem for Package Management Richard Feldman - From Rails to Elm and Haskell Samuel Gélineau - Stuck macros: deterministically interleaving macro-expansion and typechecking Vaibhav Sagar - Yes, IHaskell Can Do That! Fintan Halpenny - Bowl Full of Lentils Aditya Siram - A Tase Of ATS Ward Wheeler, Alex Washburn, Callan McGill - Phylogenetic Software in Haskell Igor Trindade Oliveira - Type Driven Secure Enclave Development using Idris David Christiansen - Bidirectional Type Checking Chris Smith - Teaching the intersection of mathematics and functional programming Brandon Kase - Fast Accumulation on Streams James Koppel - The Best Refactoring You’ve Never Heard Of Allister Beharry - Using Dependent Types in an F# DSL for Linear Algebra Diego Balseiro - Bridge Haskell and ReasonML in Production * Full abstracts: http://www.composeconference.org/2019/program * Conference Registration: https://www.eventbrite.com/e/new-york-compose-2019-tickets-56751182314 * Unconference Registration: https://www.eventbrite.com/e/new-york-compose-unconference-2019-tickets-60389859696 * Follow @composeconf on twitter for news: https://twitter.com/composeconf * On freenode irc, chat with fellow attendees at #composeconference * Corporate sponsorships are welcome. Current sponsors list forthcoming. * Policies (diversity and anti-harassment): http://www.composeconference.org/conduct * Email us with any questions at info at composeconference.org * Please forward this announcement to interested parties and lists. From johannes.waldmann at htwk-leipzig.de Mon May 6 11:16:35 2019 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Mon, 6 May 2019 13:16:35 +0200 Subject: [Haskell-cafe] [ANNOUNCEMENT] 11th International School on Rewriting (ISR'19), 1-6 July 2019, MINES ParisTech, France Message-ID: <8b5c2ba7-fa45-b4cd-d842-9c59926b0c3e@htwk-leipzig.de> Dear Cafe - if your're using Haskell, you are using (term) rewriting: both first order (pattern matching on algebraic data types) and higher order (lambda calculus). Here is your chance to get the fundamentals right, and see more applications: the 11th International School on Rewriting (ISR'19), 1-6 July 2019, MINES ParisTech, France. https://isr2019.mines-paristech.fr/ Deadline for early registration: May 17 full text of call for participation http://lists.tcs.ifi.lmu.de/pipermail/loginf/2019/001723.html - J.W. From vanessa.mchale at iohk.io Mon May 6 20:20:59 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Mon, 6 May 2019 15:20:59 -0500 Subject: [Haskell-cafe] ARM builds of GHC Message-ID: <851f9aea-632d-70c1-c699-a5d4f1ae1384@iohk.io> Hi all, Are there any plans to release/distribute ARM builds of GHC for the 8.8.* series? The most recent GHC to have ARM binaries distributed seems to be 8.4.2, which regrettably has a bug that makes it unsuitable for my purposes. Cheers, Vanessa McHale From rae at richarde.dev Tue May 7 02:26:37 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 6 May 2019 22:26:37 -0400 Subject: [Haskell-cafe] Final CFP: Haskell Symposium due this Friday Message-ID: <7D03E356-3CD7-4262-903B-EFE8B12A33AF@richarde.dev> ================================================================================ ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2019 Berlin, Germany 22--23 August, 2019 http://www.haskell.org/haskell-symposium/2019/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2019 will be co-located with the 2019 International Conference on Functional Programming (ICFP). **NEW THIS YEAR**: We will be using a lightweight double-blind reviewing process. See further information below. The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. Submission Details ================== Early and Regular Track ----------------------- The Haskell Symposium uses a two-track submission process so that some papers can gain early feedback. Strong papers submitted to the early track are accepted outright, and the others will be given their reviews and invited to resubmit to the regular track. Papers accepted via the early and regular tracks are considered of equal value and will not be distinguished in the proceedings. Although all papers may be submitted to the early track, authors of functional pearls and experience reports are particularly encouraged to use this mechanism. The success of these papers depends heavily on the way they are presented, and submitting early will give the program committee a chance to provide feedback and help draw out the key ideas. Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2019 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors’ own related work should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Early track: Submission deadline: 15 March 2019 (Fri) Notification: 19 April 2019 (Fri) Regular track and demos: Submission deadline: 10 May 2019 (Fri) Notification: 21 June 2019 (Fri) Camera-ready deadline for accepted papers: 30 June 2019 (Sun) Deadlines are valid anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/), and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism). The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell19.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors are free to upload both anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: Authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the principal editor will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Travel Support ============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC program, see its web page (http://pac.sigplan.org). Proceedings =========== Accepted papers will be included in the ACM Digital Library. Authors must grant ACM publication rights upon acceptance (http://authors.acm.org/main.html). Authors are encouraged to publish auxiliary material with their paper (source code, test data, etc.); they retain copyright of auxiliary material. Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. All accepted papers and proposals will be posted on the conference website one week before the meeting. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Program Committee ================= Ki-Yung Ahn Hannam University Christiaan Baaij QBayLogic B.V. José Manuel Calderón Trilla Galois, Inc Benjamin Delaware Purdue University Richard Eisenberg (chair) Bryn Mawr College Jennifer Hackett University of Nottingham Kazutaka Matsuda Tohoku University Trevor McDonell Utrecht University Ivan Perez NIA / NASA Formal Methods Nadia Polikarpova University of California, San Diego Norman Ramsey Tufts University Christine Rizkallah University of New South Wales Eric Seidel Bloomberg LP Alejandro Serrano Mena Utrecht University John Wiegley Dfinity Foundation Thomas Winant Well-Typed LLP Ningning Xie University of Hong Kong If you have questions, please contact the chair at: rae at richarde.dev ================================================================================ From philipp.hausmann at 314.ch Tue May 7 08:42:15 2019 From: philipp.hausmann at 314.ch (Philipp Hausmann) Date: Tue, 7 May 2019 10:42:15 +0200 Subject: [Haskell-cafe] Haskell Platform / GHC 8.6.5 Message-ID: Hi All I noticed that the Windows Download Link on https://www.haskell.org/platform/windows.html points to the 8.6.3 version. When can we expect an updated Haskell Platform release to be available? To give some background, we had some trouble where students got Access Violation crashes on Windows machines using GHC 8.6.3 which is fixed on GHC 8.6.5. In the end we updated to GHC 8.6.5 using the Binary GHC release, but this is quite ugly as it requires fiddling with the PATH... Best, Philipp From icfp.publicity at googlemail.com Tue May 7 21:03:33 2019 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Tue, 07 May 2019 17:03:33 -0400 Subject: [Haskell-cafe] PLMW at ICFP: Call for Scholarship Applications (due 17 May) Message-ID: <5cd1f2a5d2510_fb52aae625c05b858646@homer.mail> ACM SIGPLAN Programming Languages Mentoring Workshop Co-located with ICFP'19 PLMW web page: https://icfp19.sigplan.org/home/PLMW-ICFP-2019 The purpose of the programming languages mentoring workshop (PLMW) is to encourage senior undergraduate and early career (first or second year) to pursue careers in programming language research. We are specifically interested in attracting groups who have traditionally not had the opportunity to participate in research in functional programming. This workshop will be a combination of learning about the work being done in several areas of programming language research and mentoring with respect to helping students prepare for graduate school and the rest of their career. We will bring together leaders in programming language research from academia and industry to give talks on the kind of research typically performed after obtaining a Ph.D. The workshop will engage students, specifically interested in programming language research, in a process of imagining how they might contribute to the world. We especially encourage women and underrepresented minority students to attend PLMW. This workshop is part of the activities surrounding ICFP, the International Conference on Functional Programming, and takes place the day before the main conference. One goal of the workshop is to make ICFP conference more accessible to newcomers. We hope that participants will stay through the entire conference. ## Travel Scholarship Applications (Due 17 May) Please fill out this form by 17 May to apply for travel funding. https://forms.gle/QEvBateG7PRywB336 See the PLMW web page for additional details. The workshop registration is open to all. Students with alternative sources of funding are welcome. From leopiney at gmail.com Wed May 8 02:27:51 2019 From: leopiney at gmail.com (=?utf-8?Q?Leonardo_Pi=C3=B1eyro?=) Date: Tue, 7 May 2019 23:27:51 -0300 Subject: [Haskell-cafe] ANN: tensor-safe-0.1.0.1 In-Reply-To: <8c750487-9138-4245-99b5-f4ed69e5ccfd@Spark> References: <8c750487-9138-4245-99b5-f4ed69e5ccfd@Spark> Message-ID: <3dba0765-9ee5-4da1-8bf1-dc7c5908a6fe@Spark> Hello everyone, I’m happy to announce a preliminary release of what I called TensorSafe, a library to build structurally correct deep neural networks using dependent types in Haskell. Currently, it also provides the option to compile the models to external frameworks like Keras for Python or Keras JavaScript. I’ve built this as a part of what it is my capstone project to get my degree in computer engineering this year. I’ve learned a ton in a few months, especially thanks to projects like Grenade and the MM Haskell blogs 🙌 I’m still working on details but I think it’s ready for anyone to take a look at it. Any feedback is welcome! • http://hackage.haskell.org/package/tensor-safe • https://github.com/leopiney/tensor-safe Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Wed May 8 07:30:11 2019 From: P.Achten at cs.ru.nl (Peter Achten) Date: Wed, 8 May 2019 09:30:11 +0200 Subject: [Haskell-cafe] [TFP'19] final call for papers (deadline extension): Trends in Functional Programming 2019, 12-14 June 2019, Vancouver, BC, CA Message-ID: <7c7a35a7-6b71-9db4-1c43-30ed40af1cfd@cs.ru.nl> -------------------------------- F I N A L C A L L F O R P A P E R S -------------------------------- ====== TFP 2019 ====== 20th Symposium on Trends in Functional Programming 12-14 June, 2019 Vancouver, BC, CA https://www.tfp2019.org/index.html == Important Dates == Sumbission Deadline for Draft Papers Thursday, May 16, 2019 ** extended deadline ** Notification for Draft Papers Tuesday, May 21, 2019 ** extended deadline ** TFPIE Tuesday, June 11, 2019 Symposium Wednesday, June 12, 2019 – Friday, June 14, 2019 Notification of Student Paper Feedback Friday June 21, 2019 Submission Deadline for revised Draft Papers (post-symposium formal review) Thursday, August 1, 2019 Notification for post-symposium submissions Thursday, October 24, 2019 Camera Ready Deadline (both pre- and post-symposium) Friday, November 29, 2019 The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below at scope). Please be aware that TFP uses two distinct rounds of submissions (see below at submission details). TFP 2019 will be the main event of a pair of functional programming events. TFP 2019 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 11. == Scope == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: Leading-edge, previously unpublished research work Position Articles: On what new trends should or should not be Project Articles: Descriptions of recently started new projects Evaluation Articles: What lessons can be drawn from a finished project Overview Articles: Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2019 program chairs, William J. Bowman and Ron Garcia. == Best Paper Awards == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == Instructions to Author == Papers must be submitted at: https://easychair.org/conferences/?conf=tfp2019 Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. == Pre-symposium formal review == Papers to be formally reviewed before the symposium should be submitted before an early deadline and receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected in this process may still be accepted for presentation at the symposium, but will not be considered for the post-symposium formal review. == Post-symposium formal review == Papers submitted for post-symposium review (draft papers) will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback received at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. == Paper categories == There are two types of submission, each of which can be submitted either for pre-symposium or post-symposium review: Extended abstracts. Extended abstracts are 4 to 10 pages in length. Full papers. Full papers are up to 20 pages in length. Each submission also belongs to a category: research position project evaluation overview paper Each submission should clearly indicate to which category it belongs. Additionally, a draft paper submission—of either type (extended abstract or full paper) and any category—can be considered a student paper. A student paper is one for which primary authors are research students and the majority of the work described was carried out by the students. The submission should indicate that it is a student paper. Student papers will receive additional feedback from the PC shortly after the symposium has taken place and before the post-symposium submission deadline. Feedback is only provided for accepted student papers, i.e., papers submitted for presentation and post-symposium formal review that are accepted for presentation. If a student paper is rejected for presentation, then it receives no further feedback and cannot be submitted for post-symposium review. == Format == Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site (http://www.springer.com/lncs). == Program Committee == Program Co-chairs William J. Bowman University of British Columbia Ronald Garcia University of British Columbia Matteo Cimini University of Massachusetts Lowell Ryan Culpepper Czech Technical Institute Joshua Dunfield Queen's University Sam Lindley University of Edinburgh Assia Mahboubi INRIA Nantes Christine Rizkallah University of New South Wales Satnam Singh Google AI Marco T. Morazán Seton Hall University John Hughes Chalmers University and Quviq Nicolas Wu University of Bristol Tom Schrijvers KU Leuven Scott Smith Johns Hopkins University Stephanie Balzer Carnegie Mellon University Viktória Zsók Eötvös Loránd University -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Wed May 8 08:00:28 2019 From: P.Achten at cs.ru.nl (Peter Achten) Date: Wed, 8 May 2019 10:00:28 +0200 Subject: [Haskell-cafe] [TFPIE'19] Final call for papers: Trends in Functional Programming in Education 2019, 11 June 2019, Vancouver, BC, CA Message-ID: <79423a91-d87d-6cac-6cdd-ea2bff265808@cs.ru.nl> TFPIE 2019 Call for papers http://www.staff.science.uu.nl/~hage0101/tfpie2019/index.html (June 11th, University of British Columbia, Vancouver Canada, co-located with TFP 2019) TFPIE 2019 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: FP and beginning CS students FP and Computational Thinking FP and Artificial Intelligence FP in Robotics FP and Music Advanced FP for undergraduates FP in graduate education Engaging students in research using FP FP in Programming Languages FP in the high school curriculum FP as a stepping stone to other CS topics FP and Philosophy The pedagogy of teaching FP FP and e-learning: MOOCs, automated assessment etc. Best Lectures - more details below In addition to papers, we are requesting best lecture presentations. What's your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. The length of the presentation should be comparable to that of a paper. On top of the lecture itself, the presentation can also provide commentary on the lecture. Submissions Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 16 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2019 After the workshop, presenters will be invited to submit (a revised version of) their article for review. The PC will select the best articles that will be published in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Dates Submission deadline: May 14th 2019, Anywhere on Earth. Notification: May 20th Workshop: June 11th Submission for formal review: August 18th 2019, Anywhere on Earth Notification of full article: October 6th Camera ready: November 1st Program Committee Alex Gerdes - University of Gothenburg / Chalmers Jurriaan Hage (Chair) - Utrecht University Pieter Koopman - Radboud University, the Netherlands Elena Machkasova - University of Minnesota, Morris, USA Heather Miller - Carnegie Mellon University and EPFL Lausanne Prabhakar Ragde - University of Waterloo, Waterloo, Ontario, Canada Simon Thompson - University of Kent, UK Sharon Tuttle - Humboldt State University, Arcata, USA Note: information on TFP is available at https://www.tfp2019.org/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Wed May 8 08:14:49 2019 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Wed, 8 May 2019 08:14:49 +0000 Subject: [Haskell-cafe] Journal of Functional Programming - Call for PhD Abstracts Message-ID: Dear all, If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, deadline 31st May 2019. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st May 2019 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, twice per year the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton by 31st May 2019: o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From johannes.waldmann at htwk-leipzig.de Wed May 8 09:00:41 2019 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Wed, 8 May 2019 11:00:41 +0200 Subject: [Haskell-cafe] how to debug segfaults in ghc-compiled executable? Message-ID: <185a7fdc-f034-597b-4456-3ff27abdc80d@htwk-leipzig.de> Dear Cafe, I keep getting spurious segfaults from a dynamically linked executable compiled by ghc. In dmesg: [402186.145258] pure-matchbox:w[25362]: segfault at 7f98644a5c00 ip 00000000017ab65e sp 00007f98377f9988 error 4 [402186.145262] Code: b8 0a 7e 77 01 48 83 ec 08 48 89 df 48 89 c3 31 c0 ff d3 48 83 c4 08 48 8b 1c 25 50 90 a7 01 48 89 c1 48 6b c9 18 48 83 c1 10 <48> 83 3c 0b 00 74 30 48 8b 1c 25 50 90 a7 01 48 6b c0 18 48 83 c0 How can I find out what part of the program this refers to? The error might be related to external libraries (used by hmatrix-glpk) but I don't know how to verify this. When I look at the output of `nm´ for this executable, I am not seeing any address like 00017ab65e. I do not have a concrete reproducible test case, but the bug happens statistically (say, in one out of 1000 runs). - J. From lonetiger at gmail.com Wed May 8 16:10:22 2019 From: lonetiger at gmail.com (Phyx) Date: Wed, 8 May 2019 17:10:22 +0100 Subject: [Haskell-cafe] how to debug segfaults in ghc-compiled executable? In-Reply-To: <185a7fdc-f034-597b-4456-3ff27abdc80d@htwk-leipzig.de> References: <185a7fdc-f034-597b-4456-3ff27abdc80d@htwk-leipzig.de> Message-ID: Hi, Give addr2line a try, the address may be in an SO. Regards, Tamar Sent from my Mobile On Wed, May 8, 2019, 10:01 Johannes Waldmann < johannes.waldmann at htwk-leipzig.de> wrote: > Dear Cafe, > > I keep getting spurious segfaults from a dynamically > linked executable compiled by ghc. In dmesg: > > [402186.145258] pure-matchbox:w[25362]: segfault at 7f98644a5c00 ip > 00000000017ab65e sp 00007f98377f9988 error 4 > [402186.145262] Code: b8 0a 7e 77 01 48 83 ec 08 48 89 df 48 89 c3 31 c0 > ff d3 48 83 c4 08 48 8b 1c 25 50 90 a7 01 48 89 c1 48 6b c9 18 48 83 c1 > 10 <48> 83 3c 0b 00 74 30 48 8b 1c 25 50 90 a7 01 48 6b c0 18 48 83 c0 > > How can I find out what part of the program this refers to? > > The error might be related to external libraries (used by hmatrix-glpk) > but I don't know how to verify this. > > When I look at the output of `nm´ for this executable, > I am not seeing any address like 00017ab65e. > > I do not have a concrete reproducible test case, > but the bug happens statistically (say, in one out of 1000 runs). > > - J. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Wed May 8 20:28:21 2019 From: gershomb at gmail.com (Gershom B) Date: Wed, 8 May 2019 16:28:21 -0400 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 Message-ID: On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.6.5 Now available at https://www.haskell.org/platform/ This includes GHC 8.6.5, cabal-install 2.4.1.0, and stack 1.9.3. It is an incremental release over 8.6.3 intended mainly to make available bugfixes for windows in subsequent revisions in the 8.6 series and otherwise leave everything the same. These windows fixes are important, and it is recommended all windows users upgrade to 8.6.5 whether through the platform installer or some other mechanism. For detail on these changes and fixes see https://www.haskell.org/ghc/blog/20190305-ghc-8.6.4-released.html https://www.haskell.org/ghc/blog/20190423-ghc-8.6.5-released.html As with the 8.6.3 release, we are only providing core builds. Further, in 8.6.3 we moved from generic linux installers to recommending users install ghc through ghcup. As discussed in the last announcement, we have now moved to recommending os x users also use ghcup rather than a dedicated binary installer. For more details, please see the 8.6.3 announcement at https://mail.haskell.org/pipermail/haskell-cafe/2018-December/130371.html Happy Haskell Hacking all, Gershom From james.faure at epitech.eu Thu May 9 12:54:01 2019 From: james.faure at epitech.eu (james faure) Date: Thu, 9 May 2019 12:54:01 +0000 Subject: [Haskell-cafe] LFVM-STG Compilation Message-ID: Hello, I want to introduce the STG backend I am currently working on: https://github.com/jfaure/lfvm-stg I'd love to see how much interest there is for this, to receive any comments, and find out if I've missed anything ! The goal is to massively speed up compilation times and generate faster and clearer code, and in that respect I am already quite successful. Llvm is very well suited for encoding a (lazy) functional language, however the evaluation mechanism is very different to ghc's stg, there is notably no continuation passing nor result registers. In LFVM, all non constant let bindings are given an llvm function. I believe this approach is more natural, the llvm more accurately reflects the source code and we get proper stack traces in a debugger. Status: The project is barely a month old, and I'm working to support everything ghc's code generation supports. The STG is heavily based on the one found in ghc and, at this time and as far as I can tell, supports everything except multithreading, a gc and lazy evaluation. The current idea I think is very promising is to use an inferred pi calculus to elegantly implement all 3 missing parts at once. Pi calculus [1] (process calculus) In the STG * Multithreading occurs for arguments of functions with >1 arity * Perfect garbage collection is quite probably possible [2], where allocation creates a new pi name, and its uses are modeled by pi calculus communication * Perfect Lazy evaluation (in the sense that the wrapper and associated wrapped type overhead is coerced away after the first evaluation) is possible in the pi calculus and closely linked the gc model. I intend to make strict evaluation the default, If you want lazy (for MonadFix or infinite lists or whatever), you must request it. [1]: https://en.wikipedia.org/wiki/%CE%A0-calculus [2]: https://www.researchgate.net/publication/228514964_Resources_garbage-collection_and_the_pi-calculus James Faure (Discord: J4#0303) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikhil at acm.org Thu May 9 14:30:16 2019 From: nikhil at acm.org (Rishiyur Nikhil) Date: Thu, 9 May 2019 10:30:16 -0400 Subject: [Haskell-cafe] Invititation to provide feedback on RISC-V ISA Formal Specs Message-ID: The RISC-V Foundation (riscv.org) has a task group to develop a Formal Spec for the RISC-V Instruction Set Architecture. The group has been pursuing several approaches: - 3 are written in Haskell - 1 is in SAIL, a DSL with dependent types, intended for ISA specs - 1 is in Kami, a DSL in Coq Most of them are complete enough to boot Linux, i.e., they are not for toy subsets of the ISA. They are expected and intended to become the "official" ISA spec for RISC-V, and to be used in anger, for compliance testing, formal verification of compilers, hardware designs, etc. We would love to get community feedback on these approaches. The following link provides an overview, and links to individual web sites (all on GitHub) for the 5 approaches, and information on how to provide feedback: https://github.com/riscv/ISA_Formal_Spec_Public_Review Thanks very much in advance! Rishiyur Nikhil, Chair, ISA Formal Spec Technical Group -------------- next part -------------- An HTML attachment was scrubbed... URL: From b at chreekat.net Thu May 9 16:58:36 2019 From: b at chreekat.net (Bryan Richter) Date: Thu, 9 May 2019 19:58:36 +0300 Subject: [Haskell-cafe] LFVM-STG Compilation In-Reply-To: References: Message-ID: Speeding up compile times would be excellent! Do you have benchmarks? Estimates? ZuriHac is coming up, and I want to devote my participation time to improving ghc's usability, one way or another. Improving compile times would be the best usability boon I can think of. If there is promise in this project, I'd like to learn about any way I could help out. On Thu, 9 May 2019, 15.54 james faure, wrote: > Hello, > I want to introduce the STG backend I am currently working on: > https://github.com/jfaure/lfvm-stg > I'd love to see how much interest there is for this, to receive any > comments, and find out if I've missed anything ! > > The goal is to massively speed up compilation times and generate faster > and clearer code, and in that respect I am already quite successful. Llvm > is very well suited for encoding a (lazy) functional language, however the > evaluation mechanism is very different to ghc's stg, there is notably no > continuation passing nor result registers. In LFVM, all non constant let > bindings are given an llvm function. I believe this approach is more > natural, the llvm more accurately reflects the source code and we get > proper stack traces in a debugger. > > Status: > The project is barely a month old, and I'm working to support everything > ghc's code generation supports. > The STG is heavily based on the one found in ghc and, at this time and as > far as I can tell, supports everything except multithreading, a gc and > lazy evaluation. The current idea I think is very promising is to use an > inferred pi calculus to elegantly implement all 3 missing parts at once. > > Pi calculus [1] (process calculus) In the STG > > - Multithreading occurs for arguments of functions with >1 arity > - Perfect garbage collection is quite probably possible [2], where > allocation creates a new pi name, and its uses are modeled by pi calculus > communication > - Perfect Lazy evaluation (in the sense that the wrapper and > associated wrapped type overhead is coerced away after the first > evaluation) is possible in the pi calculus and closely linked the gc model. > I intend to make strict evaluation the default, If you want lazy (for > MonadFix or infinite lists or whatever), you must request it. > > [1]: https://en.wikipedia.org/wiki/%CE%A0-calculus > [2]: > https://www.researchgate.net/publication/228514964_Resources_garbage-collection_and_the_pi-calculus > > James Faure (Discord: J4#0303) > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Thu May 9 17:40:26 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 May 2019 13:40:26 -0400 Subject: [Haskell-cafe] LFVM-STG Compilation In-Reply-To: References: Message-ID: <20190509174026.GU67454@straasha.imrryr.org> On Thu, May 09, 2019 at 12:54:01PM +0000, james faure wrote: > Pi calculus [1] (process calculus) In the STG > > * Multithreading occurs for arguments of functions with >1 arity > > * Perfect garbage collection is quite probably possible [2], where > allocation creates a new pi name, and its uses are modeled by pi calculus > communication > > * Perfect Lazy evaluation (in the sense that the wrapper and associated > wrapped type overhead is coerced away after the first evaluation) is > possible in the pi calculus and closely linked the gc model. I intend > to make strict evaluation the default, If you want lazy (for MonadFix > or infinite lists or whatever), you must request it. The ideas sound very interesting, but could you elaborate on the "strict by default" aspect? Who's the "you" who'd have to request lazy evaluation? Is this something internal to the compiler with strictness analysis generating the "requests" internally, or would all existing application and library code that expects lazy evaluation need to be updated with explicit laziness annotations? -- Viktor. From james.faure at epitech.eu Thu May 9 18:11:08 2019 From: james.faure at epitech.eu (james faure) Date: Thu, 9 May 2019 18:11:08 +0000 Subject: [Haskell-cafe] LFVM-STG Compilation In-Reply-To: <20190509174026.GU67454@straasha.imrryr.org> References: , <20190509174026.GU67454@straasha.imrryr.org> Message-ID: Haskell has the '~' and '!' that can be used to specify strictness of constructor parameters, If nothing is given lfvm will assume '!'. It's worth noting that it's not always easy to tell when laziness can pay off, the classic example of 'take 3 . sort' being something that benefits from lazy evaluation. Perhaps cases like these can be resolved by marking 'take' as preferring lazy lists. So yes, This strict by default approach probably means some library code will need to be updated to avoid unnecessarily forcing huge lists to be evaluated, although I don't think the effects will be that massive, for lists I can't think of many functions besides 'take' and 'head' that don't need the whole list. Besides the vast majority of the time I would assume one uses all the data one creates. In the above example, you're relying on sort to operate in a certain way - if it uses a bubble sort for example, then that's unfortunate. ________________________________ From: Haskell-Cafe on behalf of Viktor Dukhovni Sent: Thursday, May 9, 2019 7:40 PM To: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] LFVM-STG Compilation On Thu, May 09, 2019 at 12:54:01PM +0000, james faure wrote: > Pi calculus [1] (process calculus) In the STG > > * Multithreading occurs for arguments of functions with >1 arity > > * Perfect garbage collection is quite probably possible [2], where > allocation creates a new pi name, and its uses are modeled by pi calculus > communication > > * Perfect Lazy evaluation (in the sense that the wrapper and associated > wrapped type overhead is coerced away after the first evaluation) is > possible in the pi calculus and closely linked the gc model. I intend > to make strict evaluation the default, If you want lazy (for MonadFix > or infinite lists or whatever), you must request it. The ideas sound very interesting, but could you elaborate on the "strict by default" aspect? Who's the "you" who'd have to request lazy evaluation? Is this something internal to the compiler with strictness analysis generating the "requests" internally, or would all existing application and library code that expects lazy evaluation need to be updated with explicit laziness annotations? -- Viktor. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zocca.marco at gmail.com Thu May 9 20:20:21 2019 From: zocca.marco at gmail.com (Marco Zocca) Date: Thu, 9 May 2019 22:20:21 +0200 Subject: [Haskell-cafe] FHPNC'19 Deadline Extension and 2nd Call for Papers Message-ID: We are happy to extend the submission deadline to the 2019 ACM SIGPLAN Functional High Performance and Numerical Computing Workshop until Saturday, May 25, 2019, 12 PM AoE ("anywhere on Earth", i.e. UTC-6). Marco Zocca and Dominic Steinitz FHPNC'19 Organizing Committee ================================= 2nd Call for Papers (Extended Abstracts and Full Papers) ACM SIGPLAN Workshop on Functional High-Performance and Numerical Computing (FHPNC), Berlin, August 18, 2019 Satellite event of the 24th ACM SIGPLAN International Conference on Functional Programming (ICFP 2019) 18 - 23 August, 2019 Homepage : https://icfp19.sigplan.org/home/FHPNC-2019#Call-for-Papers The ACM SIGPLAN International Workshop on Functional High-Performance and Numerical Computing aims to bring together researchers and practitioners exploring or employing the use of functional or declarative programming languages or techniques in scientific computing, and specifically in the domains of high-performance computing and numerical programming. The purpose of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative techniques can help make high-performance, distributed/parallel, or numerically-intensive code dealing with computationally challenging problems easier to write, read, maintain, or portable to new hardware architectures. Areas of interest include, but are not limited to: * relevant compiler technologies * runtime systems (including fault tolerance mechanisms and those supporting distributed or parallel computation) * domain-specific languages (embedded or standalone) * type systems * formal methods * software libraries (e.g. for exact or interval arithmetic). ## Submission details Submissions should fall into one of two categories: * Regular research papers (up to 12 pages) * Extended abstracts (1 - 2 pages) The bibliography will not be counted against the page limits for either category. Regular research papers are expected to present novel and interesting research results, and will be included in the formal proceedings. Extended abstracts should report work in progress that the authors would like to present at the workshop; they will be evaluated primarily for relevance and interest. Extended abstracts will be distributed to workshop attendees but will not be published in the formal proceedings. We welcome submissions from PC members (with the exception of the PC Chair), but these submissions will be held to a higher standard. Submission is handled through the HotCRP site. All submissions should be in portable document format (PDF) and formatted using the ACM SIGPLAN style guidelines. Submissions written with LaTeX are required to use the ‘acmart’ format and the two-column ‘sigplan’ subformat (not to be confused with the one-column ‘acmlarge’ subformat!). Extended Abstracts must be submitted with the label ‘Extended abstract’ clearly in the title. ## Publication The proceedings of FHPNC 2019 will be published in the ACM Digital Library. ## Related links * Author Information and LaTeX templates : http://www.sigplan.org/Resources/Author/ * Attendee Code of Conduct: http://www.sigplan.org/Resources/Policies/CodeOfConduct/ From tanuki at gmail.com Thu May 9 21:22:09 2019 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Thu, 9 May 2019 14:22:09 -0700 Subject: [Haskell-cafe] LFVM-STG Compilation In-Reply-To: References: <20190509174026.GU67454@straasha.imrryr.org> Message-ID: Do not underestimate the repercussions of strict-by-default. I have quite a bit of production code which would bottom out (or at best *massively* over-allocate) without pervasive laziness. On Thu, May 9, 2019, 11:11 AM james faure wrote: > Haskell has the '~' and '!' that can be used to specify strictness of > constructor parameters, If nothing is given lfvm will assume '!'. It's > worth noting that it's not always easy to tell when laziness can pay off, > the classic example of 'take 3 . sort' being something that benefits from > lazy evaluation. Perhaps cases like these can be resolved by marking 'take' > as preferring lazy lists. > > So yes, This strict by default approach probably means some library code > will need to be updated to avoid unnecessarily forcing huge lists to be > evaluated, although I don't think the effects will be that massive, for > lists I can't think of many functions besides 'take' and 'head' that don't > need the whole list. Besides the vast majority of the time I would assume > one uses all the data one creates. In the above example, you're relying on > sort to operate in a certain way - if it uses a bubble sort for example, > then that's unfortunate. > ------------------------------ > *From:* Haskell-Cafe on behalf of > Viktor Dukhovni > *Sent:* Thursday, May 9, 2019 7:40 PM > *To:* haskell-cafe at haskell.org > *Subject:* Re: [Haskell-cafe] LFVM-STG Compilation > > On Thu, May 09, 2019 at 12:54:01PM +0000, james faure wrote: > > > Pi calculus [1] (process calculus) In the STG > > > > * Multithreading occurs for arguments of functions with >1 arity > > > > * Perfect garbage collection is quite probably possible [2], where > > allocation creates a new pi name, and its uses are modeled by pi > calculus > > communication > > > > * Perfect Lazy evaluation (in the sense that the wrapper and > associated > > wrapped type overhead is coerced away after the first evaluation) > is > > possible in the pi calculus and closely linked the gc model. I > intend > > to make strict evaluation the default, If you want lazy (for > MonadFix > > or infinite lists or whatever), you must request it. > > The ideas sound very interesting, but could you elaborate on the > "strict by default" aspect? Who's the "you" who'd have to request > lazy evaluation? Is this something internal to the compiler with > strictness analysis generating the "requests" internally, or would > all existing application and library code that expects lazy evaluation > need to be updated with explicit laziness annotations? > > -- > Viktor. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhmerchant at gmail.com Thu May 9 21:51:38 2019 From: bhmerchant at gmail.com (Brian Merchant) Date: Thu, 9 May 2019 14:51:38 -0700 Subject: [Haskell-cafe] Need help understanding Ralf Hinze's Lifting Lemma, and its connection to the Transfer Principle Message-ID: Hi all, I am a student in mathematics exploring alternative ways in which the transfer principle ( https://en.wikipedia.org/wiki/Transfer_principle ) can be proved. I've found a paper by Ralf Hinze which I think is relevant: https://www.cs.ox.ac.uk/ralf.hinze/Lifting.pdf. However, I'd benefit from being able to talk to someone who understands the notation starting section 3 and onwards, as I am very much a Haskell newbie (everything I have learned, has been in the last 4 days, as I try to decipher this paper). Would anyone be willing to have a conversation with me regarding this? Kind regards, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu May 9 22:04:24 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 9 May 2019 18:04:24 -0400 Subject: [Haskell-cafe] LFVM-STG Compilation In-Reply-To: References: <20190509174026.GU67454@straasha.imrryr.org> Message-ID: The same is true of the Prelude. You might want to look at what's happened with -XStrict and even -XStrictData. Both end up meaning you replace or rewrite a bunch of library functions, because lots of things rely on laziness either for memory usage or to avoid bottoms. In short, if you are still talking about Haskell, default-strict isn't an option. A strict Haskell-*like* language is an option, but it won't be Haskell; its idioms will be different and library compatibility will be dubious at best. On Thu, May 9, 2019 at 5:22 PM Theodore Lief Gannon wrote: > Do not underestimate the repercussions of strict-by-default. I have quite > a bit of production code which would bottom out (or at best *massively* > over-allocate) without pervasive laziness. > > On Thu, May 9, 2019, 11:11 AM james faure wrote: > >> Haskell has the '~' and '!' that can be used to specify strictness of >> constructor parameters, If nothing is given lfvm will assume '!'. It's >> worth noting that it's not always easy to tell when laziness can pay off, >> the classic example of 'take 3 . sort' being something that benefits from >> lazy evaluation. Perhaps cases like these can be resolved by marking 'take' >> as preferring lazy lists. >> >> So yes, This strict by default approach probably means some library code >> will need to be updated to avoid unnecessarily forcing huge lists to be >> evaluated, although I don't think the effects will be that massive, for >> lists I can't think of many functions besides 'take' and 'head' that don't >> need the whole list. Besides the vast majority of the time I would assume >> one uses all the data one creates. In the above example, you're relying on >> sort to operate in a certain way - if it uses a bubble sort for example, >> then that's unfortunate. >> ------------------------------ >> *From:* Haskell-Cafe on behalf of >> Viktor Dukhovni >> *Sent:* Thursday, May 9, 2019 7:40 PM >> *To:* haskell-cafe at haskell.org >> *Subject:* Re: [Haskell-cafe] LFVM-STG Compilation >> >> On Thu, May 09, 2019 at 12:54:01PM +0000, james faure wrote: >> >> > Pi calculus [1] (process calculus) In the STG >> > >> > * Multithreading occurs for arguments of functions with >1 arity >> > >> > * Perfect garbage collection is quite probably possible [2], where >> > allocation creates a new pi name, and its uses are modeled by pi >> calculus >> > communication >> > >> > * Perfect Lazy evaluation (in the sense that the wrapper and >> associated >> > wrapped type overhead is coerced away after the first evaluation) >> is >> > possible in the pi calculus and closely linked the gc model. I >> intend >> > to make strict evaluation the default, If you want lazy (for >> MonadFix >> > or infinite lists or whatever), you must request it. >> >> The ideas sound very interesting, but could you elaborate on the >> "strict by default" aspect? Who's the "you" who'd have to request >> lazy evaluation? Is this something internal to the compiler with >> strictness analysis generating the "requests" internally, or would >> all existing application and library code that expects lazy evaluation >> need to be updated with explicit laziness annotations? >> >> -- >> Viktor. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Fri May 10 02:00:45 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Fri, 10 May 2019 10:00:45 +0800 Subject: [Haskell-cafe] How to optimize a directory scanning? Message-ID: Hi, I have asked this in Stackoverflow without getting an answer. Wondering if people here could have some thoughts. I have a function reading the content of /proc every second. Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same logic in C or Rust just takes like 1% or 2%. Wondering if this can be improved. /proc is virtual filesystem, so this is not related to HDD performance. And I noticed this difference because my CPU is too old (Core Gen2). On modern CPU, as tested by others, the difference is barely noticeable. import Control.Exception import Control.Concurrent import Control.Monad import Data.Char import Data.Maybe import System.Directory import System.FilePath import System.Posix.Files import System.Posix.Signals import System.Posix.Types import System.Posix.User import System.IO.Strict as Strict watch u limit0s limit0h = do listDirectory "/proc/" >>= mapM_ (\fp -> do isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) threadDelay 1000000 watch u limit0s limit0h where wrap2Maybe :: IO a -> IO (Maybe a) wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> return Nothing) isMyPid :: FilePath -> UserID -> IO Bool isMyPid fp me = do let areDigit = fp >= "0" && fp <= "9" isDir <- doesDirectoryExist $ "/proc/" fp owner <- fileOwner <$> getFileStatus ("/proc" fp) return $ areDigit && isDir && (owner == me) -- 竹密岂妨流水过 山高哪阻野云飞 From david.feuer at gmail.com Fri May 10 02:11:19 2019 From: david.feuer at gmail.com (David Feuer) Date: Thu, 9 May 2019 22:11:19 -0400 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: Message-ID: Pure speculation: are you paying for a lot of conversions between FilePath (string) and C strings? On Thu, May 9, 2019, 10:02 PM Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Hi, > I have asked this in Stackoverflow without getting an answer. > Wondering if people here could have some thoughts. > > I have a function reading the content of /proc every second. > Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same > logic in C or Rust just takes like 1% or 2%. Wondering if this can be > improved. /proc is virtual filesystem, so this is not related to HDD > performance. And I noticed this difference because my CPU is too old > (Core Gen2). On modern CPU, as tested by others, the difference is > barely noticeable. > > import Control.Exception > import Control.Concurrent > import Control.Monad > import Data.Char > import Data.Maybe > import System.Directory > import System.FilePath > import System.Posix.Files > import System.Posix.Signals > import System.Posix.Types > import System.Posix.User > import System.IO.Strict as Strict > > watch u limit0s limit0h = do > listDirectory "/proc/" >>= mapM_ (\fp -> do > isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) > wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) > threadDelay 1000000 > watch u limit0s limit0h > where > wrap2Maybe :: IO a -> IO (Maybe a) > wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> > return Nothing) > isMyPid :: FilePath -> UserID -> IO Bool > isMyPid fp me = do > let areDigit = fp >= "0" && fp <= "9" > isDir <- doesDirectoryExist $ "/proc/" fp > owner <- fileOwner <$> getFileStatus ("/proc" fp) > return $ areDigit && isDir && (owner == me) > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa.mchale at iohk.io Fri May 10 02:12:59 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Thu, 9 May 2019 21:12:59 -0500 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: Message-ID: Would you happen to have the Rust/C code available? One option is to simply using the C code and bind to it. The one thing that stands out to me in your code is that you call doesDirectoryExist as well as getFileStatus when you could determine whether it exists with doesPathExist and then determine whether it's a directory by checking the result of getFileStatus Cheers, Vanessa McHale On 5/9/19 9:00 PM, Magicloud Magiclouds wrote: > Hi, > I have asked this in Stackoverflow without getting an answer. > Wondering if people here could have some thoughts. > > I have a function reading the content of /proc every second. > Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same > logic in C or Rust just takes like 1% or 2%. Wondering if this can be > improved. /proc is virtual filesystem, so this is not related to HDD > performance. And I noticed this difference because my CPU is too old > (Core Gen2). On modern CPU, as tested by others, the difference is > barely noticeable. > > import Control.Exception > import Control.Concurrent > import Control.Monad > import Data.Char > import Data.Maybe > import System.Directory > import System.FilePath > import System.Posix.Files > import System.Posix.Signals > import System.Posix.Types > import System.Posix.User > import System.IO.Strict as Strict > > watch u limit0s limit0h = do > listDirectory "/proc/" >>= mapM_ (\fp -> do > isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) > wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) > threadDelay 1000000 > watch u limit0s limit0h > where > wrap2Maybe :: IO a -> IO (Maybe a) > wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> > return Nothing) > isMyPid :: FilePath -> UserID -> IO Bool > isMyPid fp me = do > let areDigit = fp >= "0" && fp <= "9" > isDir <- doesDirectoryExist $ "/proc/" fp > owner <- fileOwner <$> getFileStatus ("/proc" fp) > return $ areDigit && isDir && (owner == me) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From magicloud.magiclouds at gmail.com Fri May 10 02:13:54 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Fri, 10 May 2019 10:13:54 +0800 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: Message-ID: I could not tell, since those are some kind of "standard" functions of Haskell, right? On Fri, May 10, 2019 at 10:11 AM David Feuer wrote: > > Pure speculation: are you paying for a lot of conversions between FilePath (string) and C strings? > > On Thu, May 9, 2019, 10:02 PM Magicloud Magiclouds wrote: >> >> Hi, >> I have asked this in Stackoverflow without getting an answer. >> Wondering if people here could have some thoughts. >> >> I have a function reading the content of /proc every second. >> Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same >> logic in C or Rust just takes like 1% or 2%. Wondering if this can be >> improved. /proc is virtual filesystem, so this is not related to HDD >> performance. And I noticed this difference because my CPU is too old >> (Core Gen2). On modern CPU, as tested by others, the difference is >> barely noticeable. >> >> import Control.Exception >> import Control.Concurrent >> import Control.Monad >> import Data.Char >> import Data.Maybe >> import System.Directory >> import System.FilePath >> import System.Posix.Files >> import System.Posix.Signals >> import System.Posix.Types >> import System.Posix.User >> import System.IO.Strict as Strict >> >> watch u limit0s limit0h = do >> listDirectory "/proc/" >>= mapM_ (\fp -> do >> isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) >> wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) >> threadDelay 1000000 >> watch u limit0s limit0h >> where >> wrap2Maybe :: IO a -> IO (Maybe a) >> wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> >> return Nothing) >> isMyPid :: FilePath -> UserID -> IO Bool >> isMyPid fp me = do >> let areDigit = fp >= "0" && fp <= "9" >> isDir <- doesDirectoryExist $ "/proc/" fp >> owner <- fileOwner <$> getFileStatus ("/proc" fp) >> return $ areDigit && isDir && (owner == me) >> >> >> -- >> 竹密岂妨流水过 >> 山高哪阻野云飞 >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From allbery.b at gmail.com Fri May 10 02:17:43 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 9 May 2019 22:17:43 -0400 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: Message-ID: ...what? Also, in C you'd stat() and check for -1 (not found_ or inspect the result to see if it's what you want. But in Haskell this throws an exception instead of producing a sane Either. so you either make multiple syscalls or you have to catch an exception. So no matter what this ends up being higher overhead than C or Rust. On Thu, May 9, 2019 at 10:15 PM Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > I could not tell, since those are some kind of "standard" functions of > Haskell, right? > > On Fri, May 10, 2019 at 10:11 AM David Feuer > wrote: > > > > Pure speculation: are you paying for a lot of conversions between > FilePath (string) and C strings? > > > > On Thu, May 9, 2019, 10:02 PM Magicloud Magiclouds < > magicloud.magiclouds at gmail.com> wrote: > >> > >> Hi, > >> I have asked this in Stackoverflow without getting an answer. > >> Wondering if people here could have some thoughts. > >> > >> I have a function reading the content of /proc every second. > >> Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same > >> logic in C or Rust just takes like 1% or 2%. Wondering if this can be > >> improved. /proc is virtual filesystem, so this is not related to HDD > >> performance. And I noticed this difference because my CPU is too old > >> (Core Gen2). On modern CPU, as tested by others, the difference is > >> barely noticeable. > >> > >> import Control.Exception > >> import Control.Concurrent > >> import Control.Monad > >> import Data.Char > >> import Data.Maybe > >> import System.Directory > >> import System.FilePath > >> import System.Posix.Files > >> import System.Posix.Signals > >> import System.Posix.Types > >> import System.Posix.User > >> import System.IO.Strict as Strict > >> > >> watch u limit0s limit0h = do > >> listDirectory "/proc/" >>= mapM_ (\fp -> do > >> isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) > >> wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) > >> threadDelay 1000000 > >> watch u limit0s limit0h > >> where > >> wrap2Maybe :: IO a -> IO (Maybe a) > >> wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> > >> return Nothing) > >> isMyPid :: FilePath -> UserID -> IO Bool > >> isMyPid fp me = do > >> let areDigit = fp >= "0" && fp <= "9" > >> isDir <- doesDirectoryExist $ "/proc/" fp > >> owner <- fileOwner <$> getFileStatus ("/proc" fp) > >> return $ areDigit && isDir && (owner == me) > >> > >> > >> -- > >> 竹密岂妨流水过 > >> 山高哪阻野云飞 > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> To (un)subscribe, modify options or view archives go to: > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> Only members subscribed via the mailman list are allowed to post. > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Fri May 10 02:17:27 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Fri, 10 May 2019 10:17:27 +0800 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: Message-ID: Yes, I do. But binding might not be the top priority since I'd like to leave logic in Haskell. Tried the dir checking, could not see major differences. On Fri, May 10, 2019 at 10:13 AM Vanessa McHale wrote: > > Would you happen to have the Rust/C code available? > > One option is to simply using the C code and bind to it. > > The one thing that stands out to me in your code is that you call > > doesDirectoryExist > > as well as > > getFileStatus > > when you could determine whether it exists with > > doesPathExist > > and then determine whether it's a directory by checking the result of getFileStatus > > Cheers, > Vanessa McHale > > On 5/9/19 9:00 PM, Magicloud Magiclouds wrote: > > Hi, > I have asked this in Stackoverflow without getting an answer. > Wondering if people here could have some thoughts. > > I have a function reading the content of /proc every second. > Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same > logic in C or Rust just takes like 1% or 2%. Wondering if this can be > improved. /proc is virtual filesystem, so this is not related to HDD > performance. And I noticed this difference because my CPU is too old > (Core Gen2). On modern CPU, as tested by others, the difference is > barely noticeable. > > import Control.Exception > import Control.Concurrent > import Control.Monad > import Data.Char > import Data.Maybe > import System.Directory > import System.FilePath > import System.Posix.Files > import System.Posix.Signals > import System.Posix.Types > import System.Posix.User > import System.IO.Strict as Strict > > watch u limit0s limit0h = do > listDirectory "/proc/" >>= mapM_ (\fp -> do > isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) > wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) > threadDelay 1000000 > watch u limit0s limit0h > where > wrap2Maybe :: IO a -> IO (Maybe a) > wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> > return Nothing) > isMyPid :: FilePath -> UserID -> IO Bool > isMyPid fp me = do > let areDigit = fp >= "0" && fp <= "9" > isDir <- doesDirectoryExist $ "/proc/" fp > owner <- fileOwner <$> getFileStatus ("/proc" fp) > return $ areDigit && isDir && (owner == me) > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From magicloud.magiclouds at gmail.com Fri May 10 02:24:46 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Fri, 10 May 2019 10:24:46 +0800 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: Message-ID: Make sense. I can see those "tricks" of C. But just, since this code is not some complex computing, really wishing it could be speeded up. For example, Rust gives Either on IO errors. On Fri, May 10, 2019 at 10:17 AM Brandon Allbery wrote: > > ...what? > > Also, in C you'd stat() and check for -1 (not found_ or inspect the result to see if it's what you want. But in Haskell this throws an exception instead of producing a sane Either. so you either make multiple syscalls or you have to catch an exception. So no matter what this ends up being higher overhead than C or Rust. > > On Thu, May 9, 2019 at 10:15 PM Magicloud Magiclouds wrote: >> >> I could not tell, since those are some kind of "standard" functions of >> Haskell, right? >> >> On Fri, May 10, 2019 at 10:11 AM David Feuer wrote: >> > >> > Pure speculation: are you paying for a lot of conversions between FilePath (string) and C strings? >> > >> > On Thu, May 9, 2019, 10:02 PM Magicloud Magiclouds wrote: >> >> >> >> Hi, >> >> I have asked this in Stackoverflow without getting an answer. >> >> Wondering if people here could have some thoughts. >> >> >> >> I have a function reading the content of /proc every second. >> >> Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same >> >> logic in C or Rust just takes like 1% or 2%. Wondering if this can be >> >> improved. /proc is virtual filesystem, so this is not related to HDD >> >> performance. And I noticed this difference because my CPU is too old >> >> (Core Gen2). On modern CPU, as tested by others, the difference is >> >> barely noticeable. >> >> >> >> import Control.Exception >> >> import Control.Concurrent >> >> import Control.Monad >> >> import Data.Char >> >> import Data.Maybe >> >> import System.Directory >> >> import System.FilePath >> >> import System.Posix.Files >> >> import System.Posix.Signals >> >> import System.Posix.Types >> >> import System.Posix.User >> >> import System.IO.Strict as Strict >> >> >> >> watch u limit0s limit0h = do >> >> listDirectory "/proc/" >>= mapM_ (\fp -> do >> >> isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) >> >> wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) >> >> threadDelay 1000000 >> >> watch u limit0s limit0h >> >> where >> >> wrap2Maybe :: IO a -> IO (Maybe a) >> >> wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> >> >> return Nothing) >> >> isMyPid :: FilePath -> UserID -> IO Bool >> >> isMyPid fp me = do >> >> let areDigit = fp >= "0" && fp <= "9" >> >> isDir <- doesDirectoryExist $ "/proc/" fp >> >> owner <- fileOwner <$> getFileStatus ("/proc" fp) >> >> return $ areDigit && isDir && (owner == me) >> >> >> >> >> >> -- >> >> 竹密岂妨流水过 >> >> 山高哪阻野云飞 >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> To (un)subscribe, modify options or view archives go to: >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> Only members subscribed via the mailman list are allowed to post. >> >> >> >> -- >> 竹密岂妨流水过 >> 山高哪阻野云飞 >> >> And for G+, please use magiclouds#gmail.com. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From ietf-dane at dukhovni.org Fri May 10 02:56:56 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 May 2019 22:56:56 -0400 Subject: [Haskell-cafe] LFVM-STG Compilation In-Reply-To: References: <20190509174026.GU67454@straasha.imrryr.org> Message-ID: <8A2991FD-0F79-44E1-BB76-EE7E02F1FCE7@dukhovni.org> > On May 9, 2019, at 6:04 PM, Brandon Allbery wrote: > > In short, if you are still talking about Haskell, default-strict isn't an option. A strict Haskell-*like* language is an option, but it won't be Haskell; its idioms will be different and library compatibility will be dubious at best. That's my take too. Lazy by default pervades the language, and strict by default simply is not Haskell. There are some modules where I can get away with and may benefit from "{-# LANGUAGE Strict #-}", but the default must remain lazy. Code I write implicitly depends on default lazy behaviour, and rewriting it all is not an option. At that point I'd be using Rust or some other language... -- Viktor. From byorgey at gmail.com Fri May 10 04:09:18 2019 From: byorgey at gmail.com (Brent Yorgey) Date: Thu, 9 May 2019 23:09:18 -0500 Subject: [Haskell-cafe] Need help understanding Ralf Hinze's Lifting Lemma, and its connection to the Transfer Principle In-Reply-To: References: Message-ID: Hi Brian, this sounds like fun. Let's talk off-list and see if we can set something up for next week (unless someone else already replied). -Brent On Thu, May 9, 2019, 4:52 PM Brian Merchant wrote: > Hi all, > > I am a student in mathematics exploring alternative ways in which the > transfer principle ( https://en.wikipedia.org/wiki/Transfer_principle ) > can be proved. > > I've found a paper by Ralf Hinze which I think is relevant: > https://www.cs.ox.ac.uk/ralf.hinze/Lifting.pdf. However, I'd benefit from > being able to talk to someone who understands the notation starting section > 3 and onwards, as I am very much a Haskell newbie (everything I have > learned, has been in the last 4 days, as I try to decipher this paper). > > Would anyone be willing to have a conversation with me regarding this? > > Kind regards, > Brian > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Fri May 10 07:45:17 2019 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 10 May 2019 09:45:17 +0200 Subject: [Haskell-cafe] LFVM-STG Compilation In-Reply-To: References: <20190509174026.GU67454@straasha.imrryr.org> Message-ID: Am Fr., 10. Mai 2019 um 00:05 Uhr schrieb Brandon Allbery < allbery.b at gmail.com>: > [...] In short, if you are still talking about Haskell, default-strict > isn't an option. A strict Haskell-*like* language is an option, but it > won't be Haskell; its idioms will be different and library compatibility > will be dubious at best. > +1. I think one (quite old) point has been missed so far in this discussion: "Strict evaluation is fundamentally flawed for function reuse.", see http://augustss.blogspot.com/2011/05/. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iustin at k1024.org Fri May 10 07:46:46 2019 From: iustin at k1024.org (Iustin Pop) Date: Fri, 10 May 2019 09:46:46 +0200 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: Message-ID: <20190510074646.GC30971@teal.hq.k1024.org> On 2019-05-10 10:00:45, Magicloud Magiclouds wrote: > Hi, > I have asked this in Stackoverflow without getting an answer. > Wondering if people here could have some thoughts. > > I have a function reading the content of /proc every second. > Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same > logic in C or Rust just takes like 1% or 2%. Wondering if this can be > improved. /proc is virtual filesystem, so this is not related to HDD > performance. And I noticed this difference because my CPU is too old > (Core Gen2). On modern CPU, as tested by others, the difference is > barely noticeable. > > watch u limit0s limit0h = do > listDirectory "/proc/" >>= mapM_ (\fp -> do > isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) > wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) > threadDelay 1000000 > watch u limit0s limit0h > where > wrap2Maybe :: IO a -> IO (Maybe a) > wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> > return Nothing) > isMyPid :: FilePath -> UserID -> IO Bool > isMyPid fp me = do > let areDigit = fp >= "0" && fp <= "9" > isDir <- doesDirectoryExist $ "/proc/" fp > owner <- fileOwner <$> getFileStatus ("/proc" fp) > return $ areDigit && isDir && (owner == me) Interesting, I can see a few potential issues. But first, have you measure how many syscalls does this do in Haskell vs. C vs Rust? That would allow you to separate the problem between internal Haskell problems (e.g. String) vs. different algorithm in Haskell. For exacmple, one issue that could lead to unneded syscalls is your "isMyPid" function. AFAIK there's no caching done by getFileStatus, so you're stat'ing (and making a syscall) each path twice, once to get file type (is it directory) information, and then a second time to get owner information. You also build `"/proc/" <> fp` twice (and thus evaluate it twice). But without understanding "how" Haskell it slower, it's not clear where the problem lies (in syscalls or in GC or …). regards, iustin From magicloud.magiclouds at gmail.com Fri May 10 07:49:27 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Fri, 10 May 2019 15:49:27 +0800 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: <20190510074646.GC30971@teal.hq.k1024.org> References: <20190510074646.GC30971@teal.hq.k1024.org> Message-ID: Good point. Let me see what strace can tell me. On Fri, May 10, 2019 at 3:46 PM Iustin Pop wrote: > > On 2019-05-10 10:00:45, Magicloud Magiclouds wrote: > > Hi, > > I have asked this in Stackoverflow without getting an answer. > > Wondering if people here could have some thoughts. > > > > I have a function reading the content of /proc every second. > > Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same > > logic in C or Rust just takes like 1% or 2%. Wondering if this can be > > improved. /proc is virtual filesystem, so this is not related to HDD > > performance. And I noticed this difference because my CPU is too old > > (Core Gen2). On modern CPU, as tested by others, the difference is > > barely noticeable. > > > > watch u limit0s limit0h = do > > listDirectory "/proc/" >>= mapM_ (\fp -> do > > isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) > > wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) > > threadDelay 1000000 > > watch u limit0s limit0h > > where > > wrap2Maybe :: IO a -> IO (Maybe a) > > wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> > > return Nothing) > > isMyPid :: FilePath -> UserID -> IO Bool > > isMyPid fp me = do > > let areDigit = fp >= "0" && fp <= "9" > > isDir <- doesDirectoryExist $ "/proc/" fp > > owner <- fileOwner <$> getFileStatus ("/proc" fp) > > return $ areDigit && isDir && (owner == me) > > Interesting, I can see a few potential issues. But first, have you > measure how many syscalls does this do in Haskell vs. C vs Rust? That > would allow you to separate the problem between internal Haskell > problems (e.g. String) vs. different algorithm in Haskell. > > For exacmple, one issue that could lead to unneded syscalls is your > "isMyPid" function. AFAIK there's no caching done by getFileStatus, so > you're stat'ing (and making a syscall) each path twice, once to get file > type (is it directory) information, and then a second time to get owner > information. > > You also build `"/proc/" <> fp` twice (and thus evaluate it twice). > > But without understanding "how" Haskell it slower, it's not clear where > the problem lies (in syscalls or in GC or …). > > regards, > iustin -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From magicloud.magiclouds at gmail.com Fri May 10 15:07:50 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Fri, 10 May 2019 23:07:50 +0800 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: <20190510074646.GC30971@teal.hq.k1024.org> Message-ID: So this is what I got. Seems like both calls two stat(stat/newfstatat) for dir checking and uid checking. But when open file for reading, there is an ioctl call (maybe from System.IO.Strict) which seems failed, for Haskell. I want to test the case without System.IO.Strict. But have no idea how to get exception catching works with lazy readFIle. For Haskell implenmentation, ``` stat("/proc/230", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 stat("/proc/230", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 openat(AT_FDCWD, "/proc/230/stat", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 23 fstat(23, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 ioctl(23, TCGETS, 0x7ffe88c18090) = -1 ENOTTY (Inappropriate ioctl for device) read(23, "230 (scsi_eh_5) S 2 0 0 0 -1 212"..., 8192) = 155 read(23, "", 8192) = 0 close(23) ``` For Rust implenmentation, ``` newfstatat(3, "1121", {st_mode=S_IFDIR|0555, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0 stat("/proc/1121", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 open("/proc/1121/stat", O_RDONLY|O_CLOEXEC) = 4 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 read(4, "1121 (ibus-engine-sim) S 1077 10", 32) = 32 read(4, "77 1077 0 -1 4194304 425 0 1 0 5", 32) = 32 read(4, "866 1689 0 0 20 0 3 0 3490 16454"..., 64) = 64 read(4, "4885264596992 94885264603013 140"..., 128) = 128 read(4, "0724521155542 140724521155575 14"..., 256) = 64 read(4, "", 192) = 0 close(4) ``` On Fri, May 10, 2019 at 3:49 PM Magicloud Magiclouds wrote: > > Good point. Let me see what strace can tell me. > > On Fri, May 10, 2019 at 3:46 PM Iustin Pop wrote: > > > > On 2019-05-10 10:00:45, Magicloud Magiclouds wrote: > > > Hi, > > > I have asked this in Stackoverflow without getting an answer. > > > Wondering if people here could have some thoughts. > > > > > > I have a function reading the content of /proc every second. > > > Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same > > > logic in C or Rust just takes like 1% or 2%. Wondering if this can be > > > improved. /proc is virtual filesystem, so this is not related to HDD > > > performance. And I noticed this difference because my CPU is too old > > > (Core Gen2). On modern CPU, as tested by others, the difference is > > > barely noticeable. > > > > > > watch u limit0s limit0h = do > > > listDirectory "/proc/" >>= mapM_ (\fp -> do > > > isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) > > > wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) > > > threadDelay 1000000 > > > watch u limit0s limit0h > > > where > > > wrap2Maybe :: IO a -> IO (Maybe a) > > > wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> > > > return Nothing) > > > isMyPid :: FilePath -> UserID -> IO Bool > > > isMyPid fp me = do > > > let areDigit = fp >= "0" && fp <= "9" > > > isDir <- doesDirectoryExist $ "/proc/" fp > > > owner <- fileOwner <$> getFileStatus ("/proc" fp) > > > return $ areDigit && isDir && (owner == me) > > > > Interesting, I can see a few potential issues. But first, have you > > measure how many syscalls does this do in Haskell vs. C vs Rust? That > > would allow you to separate the problem between internal Haskell > > problems (e.g. String) vs. different algorithm in Haskell. > > > > For exacmple, one issue that could lead to unneded syscalls is your > > "isMyPid" function. AFAIK there's no caching done by getFileStatus, so > > you're stat'ing (and making a syscall) each path twice, once to get file > > type (is it directory) information, and then a second time to get owner > > information. > > > > You also build `"/proc/" <> fp` twice (and thus evaluate it twice). > > > > But without understanding "how" Haskell it slower, it's not clear where > > the problem lies (in syscalls or in GC or …). > > > > regards, > > iustin > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From allbery.b at gmail.com Fri May 10 15:35:34 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 10 May 2019 11:35:34 -0400 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: <20190510074646.GC30971@teal.hq.k1024.org> Message-ID: The ioctl is standard, including in C unless you are using open() directly: it checks to see if the opened file is a terminal, to determine whether to set block or line buffering. On Fri, May 10, 2019 at 11:09 AM Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > So this is what I got. Seems like both calls two stat(stat/newfstatat) > for dir checking and uid checking. But when open file for reading, > there is an ioctl call (maybe from System.IO.Strict) which seems > failed, for Haskell. I want to test the case without System.IO.Strict. > But have no idea how to get exception catching works with lazy > readFIle. > > For Haskell implenmentation, > ``` > stat("/proc/230", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 > stat("/proc/230", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 > openat(AT_FDCWD, "/proc/230/stat", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 23 > fstat(23, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 > ioctl(23, TCGETS, 0x7ffe88c18090) = -1 ENOTTY (Inappropriate > ioctl for device) > read(23, "230 (scsi_eh_5) S 2 0 0 0 -1 212"..., 8192) = 155 > read(23, "", 8192) = 0 > close(23) > ``` > For Rust implenmentation, > ``` > newfstatat(3, "1121", {st_mode=S_IFDIR|0555, st_size=0, ...}, > AT_SYMLINK_NOFOLLOW) = 0 > stat("/proc/1121", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 > open("/proc/1121/stat", O_RDONLY|O_CLOEXEC) = 4 > fcntl(4, F_SETFD, FD_CLOEXEC) = 0 > fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 > read(4, "1121 (ibus-engine-sim) S 1077 10", 32) = 32 > read(4, "77 1077 0 -1 4194304 425 0 1 0 5", 32) = 32 > read(4, "866 1689 0 0 20 0 3 0 3490 16454"..., 64) = 64 > read(4, "4885264596992 94885264603013 140"..., 128) = 128 > read(4, "0724521155542 140724521155575 14"..., 256) = 64 > read(4, "", 192) = 0 > close(4) > ``` > > On Fri, May 10, 2019 at 3:49 PM Magicloud Magiclouds > wrote: > > > > Good point. Let me see what strace can tell me. > > > > On Fri, May 10, 2019 at 3:46 PM Iustin Pop wrote: > > > > > > On 2019-05-10 10:00:45, Magicloud Magiclouds wrote: > > > > Hi, > > > > I have asked this in Stackoverflow without getting an answer. > > > > Wondering if people here could have some thoughts. > > > > > > > > I have a function reading the content of /proc every second. > > > > Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same > > > > logic in C or Rust just takes like 1% or 2%. Wondering if this can be > > > > improved. /proc is virtual filesystem, so this is not related to HDD > > > > performance. And I noticed this difference because my CPU is too old > > > > (Core Gen2). On modern CPU, as tested by others, the difference is > > > > barely noticeable. > > > > > > > > watch u limit0s limit0h = do > > > > listDirectory "/proc/" >>= mapM_ (\fp -> do > > > > isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) > > > > wrap2Maybe (Strict.readFile ("/proc/" fp "stat"))) > > > > threadDelay 1000000 > > > > watch u limit0s limit0h > > > > where > > > > wrap2Maybe :: IO a -> IO (Maybe a) > > > > wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> > > > > return Nothing) > > > > isMyPid :: FilePath -> UserID -> IO Bool > > > > isMyPid fp me = do > > > > let areDigit = fp >= "0" && fp <= "9" > > > > isDir <- doesDirectoryExist $ "/proc/" fp > > > > owner <- fileOwner <$> getFileStatus ("/proc" fp) > > > > return $ areDigit && isDir && (owner == me) > > > > > > Interesting, I can see a few potential issues. But first, have you > > > measure how many syscalls does this do in Haskell vs. C vs Rust? That > > > would allow you to separate the problem between internal Haskell > > > problems (e.g. String) vs. different algorithm in Haskell. > > > > > > For exacmple, one issue that could lead to unneded syscalls is your > > > "isMyPid" function. AFAIK there's no caching done by getFileStatus, so > > > you're stat'ing (and making a syscall) each path twice, once to get > file > > > type (is it directory) information, and then a second time to get owner > > > information. > > > > > > You also build `"/proc/" <> fp` twice (and thus evaluate it twice). > > > > > > But without understanding "how" Haskell it slower, it's not clear where > > > the problem lies (in syscalls or in GC or …). > > > > > > regards, > > > iustin > > > > > > > > -- > > 竹密岂妨流水过 > > 山高哪阻野云飞 > > > > And for G+, please use magiclouds#gmail.com. > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil_mayhew at users.sourceforge.net Fri May 10 17:12:47 2019 From: neil_mayhew at users.sourceforge.net (Neil Mayhew) Date: Fri, 10 May 2019 11:12:47 -0600 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: <20190510074646.GC30971@teal.hq.k1024.org> Message-ID: <256855e1-82e6-f742-79a4-1019eac793e3@users.sourceforge.net> It would be possible to avoid that TCGETS ioctl since the immediately preceding fstat shows that the file is a regular file and not a device. However, I'm not sure how easy it would be for the library to make that optimization. The Haskell implementation actually makes less syscalls than the Rust one, because Rust reads the file in very small chunks (32,32,64,128,64) whereas Haskell reads one big chunk (8192) which is sufficient to contain the entire file. I think it's unlikely that the extra ioctl outweighs the multiple extra reads. However, if you use the -r option with strace to include timestamps in the output, you'll be able to see just how long each syscall is taking. On my system, they all take about the same amount of time. It would also be worth using time on the program, to see how much of the CPU time is in user space vs kernel. On 2019-05-10 9:35 AM, Brandon Allbery wrote: > The ioctl is standard, including in C unless you are using open() > directly: it checks to see if the opened file is a terminal, to > determine whether to set block or line buffering. > > On Fri, May 10, 2019 at 11:09 AM Magicloud Magiclouds > > wrote: > > So this is what I got. Seems like both calls two stat(stat/newfstatat) > for dir checking and uid checking. But when open file for reading, > there is an ioctl call (maybe from System.IO.Strict) which seems > failed, for Haskell. I want to test the case without System.IO.Strict. > But have no idea how to get exception catching works with lazy > readFIle. > > For Haskell implenmentation, > ``` > stat("/proc/230", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 > stat("/proc/230", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 > openat(AT_FDCWD, "/proc/230/stat", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 23 > fstat(23, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 > ioctl(23, TCGETS, 0x7ffe88c18090)       = -1 ENOTTY (Inappropriate > ioctl for device) > read(23, "230 (scsi_eh_5) S 2 0 0 0 -1 212"..., 8192) = 155 > read(23, "", 8192)                      = 0 > close(23) > ``` > For Rust implenmentation, > ``` > newfstatat(3, "1121", {st_mode=S_IFDIR|0555, st_size=0, ...}, > AT_SYMLINK_NOFOLLOW) = 0 > stat("/proc/1121", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 > open("/proc/1121/stat", O_RDONLY|O_CLOEXEC) = 4 > fcntl(4, F_SETFD, FD_CLOEXEC)           = 0 > fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 > read(4, "1121 (ibus-engine-sim) S 1077 10", 32) = 32 > read(4, "77 1077 0 -1 4194304 425 0 1 0 5", 32) = 32 > read(4, "866 1689 0 0 20 0 3 0 3490 16454"..., 64) = 64 > read(4, "4885264596992 94885264603013 140"..., 128) = 128 > read(4, "0724521155542 140724521155575 14"..., 256) = 64 > read(4, "", 192)                        = 0 > close(4) > ``` > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Fri May 10 18:29:03 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 10 May 2019 14:29:03 -0400 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: Message-ID: Why is the process id re-computed every second? Do you expected it to change during the process lifetime? > isMyPid fp me = do > let areDigit = fp >= "0" && fp <= "9" > isDir <- doesDirectoryExist $ "/proc/" fp > owner <- fileOwner <$> getFileStatus ("/proc" fp) > return $ areDigit && isDir && (owner == me) And the code should skip looking for sub-directories of non-numeric directory entries, avoiding unnecessary stat(2) calls. import System.Posix.Directory as D import Control.Monad perEntry_ :: FilePath -> (FilePath -> IO ()) -> IO () perEntry_ dirPath entryAction = bracket (D.openDirStream) (D.closeDirStream) (D.readDirStream >=> entryAction) Or with Conduits: import Data.Conduit as C import Data.Conduit.Combinators as C C.runConduitRes $ C.sourceDirectory dirPath .| (C.awaitForever >>= entryAction) But now you have more choices about when and what to return from the loop, whether the scan the whole directory, ... Note that the conduit version prepends the directory name to the entry names. I would not have done that, but you can just copy the handful of lines of source and stream the bare entry names: http://hackage.haskell.org/package/conduit-1.3.1.1/docs/src/Data.Conduit.Combinators.html#sourceDirectory -- Viktor. From mail at nh2.me Sat May 11 01:52:38 2019 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Sat, 11 May 2019 03:52:38 +0200 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: Message-ID: <71065c8f-cbc1-93c4-d897-bd6921593105@nh2.me> Hi, we made the `posix-paths` package for fast directory traversals: https://hackage.haskell.org/package/posix-paths You can find benchmarks in https://github.com/JohnLato/posix-paths#benchmarks Some more tips (some of them you're already following as per other threads): * Use `time` to if time is spent on kernel CPU, userspace CPU, or waiting * Use `strace -fy` with `-ttt` and `-T` to see timings, and `-c` and `-wc` summary statistics From kc1956 at gmail.com Sat May 11 22:23:54 2019 From: kc1956 at gmail.com (KC) Date: Sat, 11 May 2019 15:23:54 -0700 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: <71065c8f-cbc1-93c4-d897-bd6921593105@nh2.me> References: <71065c8f-cbc1-93c4-d897-bd6921593105@nh2.me> Message-ID: Thank you for making the `posix-paths` package for fast directory traversals: Are directories stored in consecutive disk blocks? On Fri, May 10, 2019 at 6:53 PM Niklas Hambüchen wrote: > Hi, > > we made the `posix-paths` package for fast directory traversals: > > https://hackage.haskell.org/package/posix-paths > > You can find benchmarks in > > https://github.com/JohnLato/posix-paths#benchmarks > > Some more tips (some of them you're already following as per other > threads): > > * Use `time` to if time is spent on kernel CPU, userspace CPU, or waiting > * Use `strace -fy` with `-ttt` and `-T` to see timings, and `-c` and `-wc` > summary statistics > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat May 11 22:27:13 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 11 May 2019 18:27:13 -0400 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: <71065c8f-cbc1-93c4-d897-bd6921593105@nh2.me> Message-ID: Depends on the host filesystem. Traditionally, the first 10 blocks are direct and often (but not always, if the fs is fragmented) consecutive; the remainder are indirect by 1-3 levels (not that you ever want a directory to be double indirect much less triple!), and often are not consecutive simply because by the time you get to that point you're working with a filesystem with a lot of files on it and a fair amount of fragmentation. On Sat, May 11, 2019 at 6:24 PM KC wrote: > Thank you for making the `posix-paths` package for fast directory > traversals: > > Are directories stored in consecutive disk blocks? > > On Fri, May 10, 2019 at 6:53 PM Niklas Hambüchen wrote: > >> Hi, >> >> we made the `posix-paths` package for fast directory traversals: >> >> https://hackage.haskell.org/package/posix-paths >> >> You can find benchmarks in >> >> https://github.com/JohnLato/posix-paths#benchmarks >> >> Some more tips (some of them you're already following as per other >> threads): >> >> * Use `time` to if time is spent on kernel CPU, userspace CPU, or waiting >> * Use `strace -fy` with `-ttt` and `-T` to see timings, and `-c` and >> `-wc` summary statistics >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > > -- > > Sent from an expensive device which will be obsolete in a few months! :D > Casey > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sun May 12 06:03:01 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 12 May 2019 02:03:01 -0400 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: <71065c8f-cbc1-93c4-d897-bd6921593105@nh2.me> References: <71065c8f-cbc1-93c4-d897-bd6921593105@nh2.me> Message-ID: <20190512060301.GV67454@straasha.imrryr.org> On Sat, May 11, 2019 at 03:52:38AM +0200, Niklas Hambüchen wrote: > we made the `posix-paths` package for fast directory traversals: > > https://hackage.haskell.org/package/posix-paths > > You can find benchmarks in > > https://github.com/JohnLato/posix-paths#benchmarks It should perhaps be noted that a large fraction of the additional overhead encountered by the String FilePath traversals in the that benchmark occur in the output code that prints all the paths to stdout. The corresponding ByteString listing is noticeably faster. If one rather just stats and counts all the files, the performance difference is somewhat more modest, (IIRC around a factor of ~2 rather than ~5 or 6) At the directory traversal of course needs to use 'getSymbolicLinkStatus' rather than 'getFileStatus', since recursive directory traversals should almost never follow symlinks. -- Viktor. From jo at durchholz.org Sun May 12 06:27:01 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 12 May 2019 08:27:01 +0200 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: References: <71065c8f-cbc1-93c4-d897-bd6921593105@nh2.me> Message-ID: <3e9883f8-b96c-8ad3-b06a-cf2733e1a045@durchholz.org> Am 12.05.19 um 00:23 schrieb KC: > Are directories stored in consecutive disk blocks? That's something that you have to rely on the file system to organize for you. Brandon's answer is the traditional one for Unix filesystems, up to and including ext3fs. Modern filesystems try to do better (and often do), since scanning large directories has turned out to be so important. If you do performance testing, both bad and good filesystem performance may be accidental; if you want to know not just the typical behaviour but also the pathological cases, you'll either have to wait for user reports to come in or talk to real filesystem experts (and even their answers will mostly be on an "it depends" basis). Note that fragmentation is irrelevant for SSDs. The OP is at the "what system calls are being done" stage; optimization questions about fragmentation aren't going to be relevant to him I think. TL;DR: Don't worry about fragmentation, unless you are willing to spend a really high amount of time on detail optimization. Regards, Jo From magicloud.magiclouds at gmail.com Sun May 12 07:25:53 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sun, 12 May 2019 15:25:53 +0800 Subject: [Haskell-cafe] How to optimize a directory scanning? In-Reply-To: <3e9883f8-b96c-8ad3-b06a-cf2733e1a045@durchholz.org> References: <71065c8f-cbc1-93c4-d897-bd6921593105@nh2.me> <3e9883f8-b96c-8ad3-b06a-cf2733e1a045@durchholz.org> Message-ID: Thanks for all replies. I did not track forks with strace since "I do not have such code" although stack has threaded and rtsopts set. But now `strace -f` clearly shows that there are qutie a lot of forking for my code. Removing those options got me a 3% CPU usage reducing. And as Neil said, ioctl or other syscalls in the whole reading process, Haskell is more optimized than Rust. I am trying posix-paths now. @Viktor, Sorry, that was a part missing in sample code. isMyPid should be called before reading the stat file. @Brandon, @Joachim, @KC, At least for me, how data is stored on disk is not related. /proc is a virtual filesystem which just a kernel data structures exposed via IO operations. On Sun, May 12, 2019 at 2:27 PM Joachim Durchholz wrote: > > Am 12.05.19 um 00:23 schrieb KC: > > Are directories stored in consecutive disk blocks? > > That's something that you have to rely on the file system to organize > for you. > Brandon's answer is the traditional one for Unix filesystems, up to and > including ext3fs. Modern filesystems try to do better (and often do), > since scanning large directories has turned out to be so important. > If you do performance testing, both bad and good filesystem performance > may be accidental; if you want to know not just the typical behaviour > but also the pathological cases, you'll either have to wait for user > reports to come in or talk to real filesystem experts (and even their > answers will mostly be on an "it depends" basis). > Note that fragmentation is irrelevant for SSDs. > > The OP is at the "what system calls are being done" stage; optimization > questions about fragmentation aren't going to be relevant to him I think. > > TL;DR: Don't worry about fragmentation, unless you are willing to spend > a really high amount of time on detail optimization. > > Regards, > Jo > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. From mail at nh2.me Sun May 12 23:21:53 2019 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Mon, 13 May 2019 01:21:53 +0200 Subject: [Haskell-cafe] Cabal revision online form silently converts file to Windows line endings, breaking patches Message-ID: <3a029520-2f37-542d-8cf3-1d131442a4e3@nh2.me> I noticed that if you use Hackage's online Cabal file editor, it changes all your \n line endings to \r\n. This breaks all patches written against upstream .cabal files. For example, if I write a patch against `cachix-0.2.0` git repo's .cabal file, I can no longer apply it to whatever revisions of it Hackage has, even if there's no real conflict. Here's a reproduction (I changed only 1 line in the editor, and it shows the whole file as changed): diff -u <(curl https://hackage.haskell.org/package/AesonBson-0.2.0/revision/0.cabal) <(curl https://hackage.haskell.org/package/AesonBson-0.2.0/revision/1.cabal) I found this especially problematic for nixpkgs, where patching packages is a common practice. From danburton.email at gmail.com Mon May 13 14:29:50 2019 From: danburton.email at gmail.com (Dan Burton) Date: Mon, 13 May 2019 10:29:50 -0400 Subject: [Haskell-cafe] Cabal revision online form silently converts file to Windows line endings, breaking patches In-Reply-To: <3a029520-2f37-542d-8cf3-1d131442a4e3@nh2.me> References: <3a029520-2f37-542d-8cf3-1d131442a4e3@nh2.me> Message-ID: Two thoughts: 1. this is annoying and I wish it didn't do this 2. one workaround would be to always fetch v0 of the patch, and maintain/generate custom versions of the patches equivalent to each revision as needed. -- Dan Burton On Sun, May 12, 2019 at 7:22 PM Niklas Hambüchen wrote: > I noticed that if you use Hackage's online Cabal file editor, it changes > all your \n line endings to \r\n. > > This breaks all patches written against upstream .cabal files. > > For example, if I write a patch against `cachix-0.2.0` git repo's .cabal > file, I can no longer apply it to whatever revisions of it Hackage has, > even if there's no real conflict. > > Here's a reproduction (I changed only 1 line in the editor, and it shows > the whole file as changed): > > diff -u <(curl > https://hackage.haskell.org/package/AesonBson-0.2.0/revision/0.cabal) > <(curl > https://hackage.haskell.org/package/AesonBson-0.2.0/revision/1.cabal) > > I found this especially problematic for nixpkgs, where patching packages > is a common practice. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Mon May 13 16:21:31 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 13 May 2019 18:21:31 +0200 Subject: [Haskell-cafe] Cabal revision online form silently converts file to Windows line endings, breaking patches In-Reply-To: References: <3a029520-2f37-542d-8cf3-1d131442a4e3@nh2.me> Message-ID: Actually this is much, much worse than annoying: All attempts to checksum or diff files modified in this way will have to take line-end differences into account, which will be a neverending source of bugs, and as every unexpected behaviour may make people miss a security issue, it's also a source of exploits (likely to become more interesting as Haskell gets into high-value niches). Just my 2 cents from the sideline :-) Am 13.05.19 um 16:29 schrieb Dan Burton: > Two thoughts: > 1. this is annoying and I wish it didn't do this > 2. one workaround would be to always fetch v0 of the patch, and > maintain/generate custom versions of the patches equivalent to each > revision as needed. > > -- Dan Burton > > > On Sun, May 12, 2019 at 7:22 PM Niklas Hambüchen > wrote: > > I noticed that if you use Hackage's online Cabal file editor, it > changes all your \n line endings to \r\n. > > This breaks all patches written against upstream .cabal files. > > For example, if I write a patch against `cachix-0.2.0` git repo's > .cabal file, I can no longer apply it to whatever revisions of it > Hackage has, even if there's no real conflict. > > Here's a reproduction (I changed only 1 line in the editor, and it > shows the whole file as changed): > >     diff -u <(curl > https://hackage.haskell.org/package/AesonBson-0.2.0/revision/0.cabal) <(curl > https://hackage.haskell.org/package/AesonBson-0.2.0/revision/1.cabal) > > I found this especially problematic for nixpkgs, where patching > packages is a common practice. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > From theflossinformation at yandex.com Tue May 14 03:12:47 2019 From: theflossinformation at yandex.com (The FLOSS Information) Date: Tue, 14 May 2019 06:12:47 +0300 Subject: [Haskell-cafe] Scrap your boilerplate Message-ID: <8007491557803567@iva8-d09e540be28d.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Tue May 14 05:52:20 2019 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 14 May 2019 13:52:20 +0800 Subject: [Haskell-cafe] Scrap your boilerplate In-Reply-To: <8007491557803567@iva8-d09e540be28d.qloud-c.yandex.net> References: <8007491557803567@iva8-d09e540be28d.qloud-c.yandex.net> Message-ID: On Tue, 14 May 2019 at 11:13, The FLOSS Information < theflossinformation at yandex.com> wrote: > Scrap your boilerplate > > Can you write the synonyms of the words in this sentence? I think that > such a method is necessary to avoid meaning confusion. > Get rid of repetitive code? Is that what you were after? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From boris at d12frosted.io Tue May 14 06:19:20 2019 From: boris at d12frosted.io (Boris) Date: Tue, 14 May 2019 06:19:20 +0000 Subject: [Haskell-cafe] Cabal revision online form silently converts file to Windows line endings, breaking patches In-Reply-To: References: <3a029520-2f37-542d-8cf3-1d131442a4e3@nh2.me> Message-ID: Hi everyone, Not to contribute to the solution of the problem itself, but to help with mitigation of annoying symptoms. The diff program has an option to --ignore-trailing-space (-Z for short) that will totally ignore changes of `\n` to `\n\r` and vice versa. And so you will see only 'actual' changes. Another generally useful option is --ignore-space-change (-b for short) that will ignore indentation changes. Another option that you may use is --ignore-all-space. The good thing, git diff also understand these options. Having less clutter when viewing diff is nice, but sometimes it prevents clean merges/rebases. For such cases you can pass a strategy to the merge command. For example, git merge -Xignore-trailing-space pr/xyz git merge -Xignore-all-space pr/xyz This allows you to merge a branch without the need to fight the line ending changes. Note that in some cases it doesn't work as good as you would expect it to work, but from my experience these options help a lot. P. S. more information can be found in man diff, man git-diff and man git-merge. Cheers, boris at d12frosted.io ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, May 13, 2019 7:21 PM, Joachim Durchholz wrote: > Actually this is much, much worse than annoying: All attempts to > checksum or diff files modified in this way will have to take line-end > differences into account, which will be a neverending source of bugs, > and as every unexpected behaviour may make people miss a security issue, > it's also a source of exploits (likely to become more interesting as > Haskell gets into high-value niches). > > Just my 2 cents from the sideline :-) > > Am 13.05.19 um 16:29 schrieb Dan Burton: > > > Two thoughts: > > > > 1. this is annoying and I wish it didn't do this > > 2. one workaround would be to always fetch v0 of the patch, and > > maintain/generate custom versions of the patches equivalent to each > > revision as needed. > > > > > > -- Dan Burton > > On Sun, May 12, 2019 at 7:22 PM Niklas Hambüchen > mailto:mail at nh2.me> wrote: > > > > I noticed that if you use Hackage's online Cabal file editor, it > > changes all your \\n line endings to \\r\\n. > > > > This breaks all patches written against upstream .cabal files. > > > > For example, if I write a patch against `cachix-0.2.0` git repo's > > .cabal file, I can no longer apply it to whatever revisions of it > > Hackage has, even if there's no real conflict. > > > > Here's a reproduction (I changed only 1 line in the editor, and it > > shows the whole file as changed): > > > >     diff -u <(curl > > https://hackage.haskell.org/package/AesonBson-0.2.0/revision/0.cabal) <(curl > > https://hackage.haskell.org/package/AesonBson-0.2.0/revision/1.cabal) > > > > I found this especially problematic for nixpkgs, where patching > > packages is a common practice. > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jo at durchholz.org Tue May 14 06:52:35 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 14 May 2019 08:52:35 +0200 Subject: [Haskell-cafe] Cabal revision online form silently converts file to Windows line endings, breaking patches In-Reply-To: References: <3a029520-2f37-542d-8cf3-1d131442a4e3@nh2.me> Message-ID: The options for ignoring spaces are a technical solution, but they do not solve the social problem: That everybody dealing with the diffs needs to remember to apply them. They aren't a full solution either. --ignore-trailing-space will also suppress trailing blanks. This is exactly the kind of 99% solution that makes systems less stable: have a dozen or so 99%-reliable points in the system, and the overall system will fail constantly, every time for a different reason. The options are still valuable as a stopgap solution, of course! Am 14.05.19 um 08:19 schrieb Boris: > Hi everyone, > > Not to contribute to the solution of the problem itself, but to help with mitigation of annoying symptoms. > > The diff program has an option to --ignore-trailing-space (-Z for short) that will totally ignore changes of `\n` to `\n\r` and vice versa. And so you will see only 'actual' changes. > > Another generally useful option is --ignore-space-change (-b for short) that will ignore indentation changes. Another option that you may use is --ignore-all-space. > > The good thing, git diff also understand these options. > > Having less clutter when viewing diff is nice, but sometimes it prevents clean merges/rebases. For such cases you can pass a strategy to the merge command. For example, > > git merge -Xignore-trailing-space pr/xyz > git merge -Xignore-all-space pr/xyz > > This allows you to merge a branch without the need to fight the line ending changes. Note that in some cases it doesn't work as good as you would expect it to work, but from my experience these options help a lot. > > P. S. more information can be found in man diff, man git-diff and man git-merge. > > Cheers, > boris at d12frosted.io > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, May 13, 2019 7:21 PM, Joachim Durchholz wrote: > >> Actually this is much, much worse than annoying: All attempts to >> checksum or diff files modified in this way will have to take line-end >> differences into account, which will be a neverending source of bugs, >> and as every unexpected behaviour may make people miss a security issue, >> it's also a source of exploits (likely to become more interesting as >> Haskell gets into high-value niches). >> >> Just my 2 cents from the sideline :-) >> >> Am 13.05.19 um 16:29 schrieb Dan Burton: >> >>> Two thoughts: >>> >>> 1. this is annoying and I wish it didn't do this >>> 2. one workaround would be to always fetch v0 of the patch, and >>> maintain/generate custom versions of the patches equivalent to each >>> revision as needed. >>> >>> >>> -- Dan Burton >>> On Sun, May 12, 2019 at 7:22 PM Niklas Hambüchen >> mailto:mail at nh2.me> wrote: >>> >>> I noticed that if you use Hackage's online Cabal file editor, it >>> changes all your \\n line endings to \\r\\n. >>> >>> This breaks all patches written against upstream .cabal files. >>> >>> For example, if I write a patch against `cachix-0.2.0` git repo's >>> .cabal file, I can no longer apply it to whatever revisions of it >>> Hackage has, even if there's no real conflict. >>> >>> Here's a reproduction (I changed only 1 line in the editor, and it >>> shows the whole file as changed): >>> >>>     diff -u <(curl >>> https://hackage.haskell.org/package/AesonBson-0.2.0/revision/0.cabal) <(curl >>> https://hackage.haskell.org/package/AesonBson-0.2.0/revision/1.cabal) >>> >>> I found this especially problematic for nixpkgs, where patching >>> packages is a common practice. >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >>> >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > From pierre.van.de.laar at philips.com Tue May 14 07:05:22 2019 From: pierre.van.de.laar at philips.com (Pierre_van_der_Laar (Functional Account)) Date: Tue, 14 May 2019 07:05:22 +0000 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) Message-ID: Dear Gershom / GHC development team, The provided windows version of GHC contains lib-gmp. Hence, this version enforces a LGPL license on my code (see e.g. https://gitlab.haskell.org/ghc/ghc/wikis/replacing-gmp-notes for more info) . Unfortunately, this license is unacceptable for me. For me this raises the question: What is the strategy of GHC with respect to licensing? In particularly, * Why considers GHC a LGPL license for all the code developed by their users acceptable? * Is GHC considering to allow their user to standardly develop their code under a license of their own choice? * Are there plans to offer the GHC users an opportunity to choose the license in the near future? e.g. by distributing GHC binary distributions with integer-gmp and integer-simple. Thanks in advance for your answers, Pierre van de Laar --------------------------------------------------------------------- Date: Wed, 8 May 2019 16:28:21 -0400 From: Gershom B To: haskell-cafe , haskell at haskell.org Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 Message-ID: Content-Type: text/plain; charset="UTF-8" On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.6.5 Now available at https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.haskell.org%2Fplatform%2F&data=02%7C01%7C%7Cd954a15a52dd434d55b208d6d47d261e%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C636930031310033410&sdata=HQ%2Fzhjj0Ov2AXsSy6Smnx2vrQJlZDAnttGV5%2FQjZkO8%3D&reserved=0 This includes GHC 8.6.5, cabal-install 2.4.1.0, and stack 1.9.3. It is an incremental release over 8.6.3 intended mainly to make available bugfixes for windows in subsequent revisions in the 8.6 series and otherwise leave everything the same. These windows fixes are important, and it is recommended all windows users upgrade to 8.6.5 whether through the platform installer or some other mechanism. For detail on these changes and fixes see https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.haskell.org%2Fghc%2Fblog%2F20190305-ghc-8.6.4-released.html&data=02%7C01%7C%7Cd954a15a52dd434d55b208d6d47d261e%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C636930031310033410&sdata=IxRhbFNkYVk7Pam6WWTPuaUQNyzYNh2OtYNlRZp6hs8%3D&reserved=0 https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.haskell.org%2Fghc%2Fblog%2F20190423-ghc-8.6.5-released.html&data=02%7C01%7C%7Cd954a15a52dd434d55b208d6d47d261e%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C636930031310033410&sdata=21Nat%2FDG1u7cb9I9%2BiC%2BUUtQZj3SKgDU6qzVIdb7JGw%3D&reserved=0 As with the 8.6.3 release, we are only providing core builds. Further, in 8.6.3 we moved from generic linux installers to recommending users install ghc through ghcup. As discussed in the last announcement, we have now moved to recommending os x users also use ghcup rather than a dedicated binary installer. For more details, please see the 8.6.3 announcement at https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fhaskell-cafe%2F2018-December%2F130371.html&data=02%7C01%7C%7Cd954a15a52dd434d55b208d6d47d261e%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C636930031310033410&sdata=UfTClxGp5Ht0dzpjV85pQUHO7hO8cZc5BEPJj1ImNuA%3D&reserved=0 Happy Haskell Hacking all, Gershom ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From simons at nospf.cryp.to Tue May 14 11:05:00 2019 From: simons at nospf.cryp.to (Peter Simons) Date: Tue, 14 May 2019 13:05:00 +0200 Subject: [Haskell-cafe] Cabal revision online form silently converts file to Windows line endings, breaking patches References: <3a029520-2f37-542d-8cf3-1d131442a4e3@nh2.me> Message-ID: <87sgthwb37.fsf@write-only.cryp.to> Hi guys, > The diff program has an option to --ignore-trailing-space > (-Z for short) that will totally ignore changes of `\n` > to `\n\r` and vice versa. And so you will see only > 'actual' changes. more importantly, patch(1) has an option --ignore-whitespace that helps applying patches to a revised Cabal file which suddenly comes along with CRLF line endings. Using that flag with diff(1) when creating the patch is a good idea, but it won't make the patch resistant against failures when it's applied to a modified Cabal file. > Another generally useful option is --ignore-space-change > (-b for short) that will ignore indentation changes. > Another option that you may use is --ignore-all-space. This option is actually somewhat dangerous when applied in cases where the underlying source relies on layout to convey structure, because changes in indention will be lost with that flag enabled. Generally speaking, Hackage's policy of adding CRLFs to edited files seems like a bad idea. The least intrusive choice would be to follow whatever line-ending convention the original Cabal file has and to adhere to that. Anyway, I'll throw in a historical footnote for good measure: [1] Best regards, Peter [1] https://github.com/commercialhaskell/all-cabal-files/issues/11 From jo at durchholz.org Tue May 14 14:32:34 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 14 May 2019 16:32:34 +0200 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) In-Reply-To: References: Message-ID: <373a7355-9281-6c3e-6b17-9c83ca38ae41@durchholz.org> Am 14.05.19 um 09:05 schrieb Pierre_van_der_Laar (Functional Account) via Haskell-Cafe: > Dear Gershom / GHC development team, > > The provided windows version of GHC contains lib-gmp. > Hence, this version enforces a LGPL license on my code > (see e.g. https://gitlab.haskell.org/ghc/ghc/wikis/replacing-gmp-notes for more info) . > Unfortunately, this license is unacceptable for me. What is making the LGPL inacceptable for you? The usual understanding of the LGPL enforces the LGPL license only on the lib-gmp code itself and any modifications you make to it, not on any other parts of the code. Regards, Jo From allbery.b at gmail.com Tue May 14 14:51:32 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 14 May 2019 10:51:32 -0400 Subject: [Haskell-cafe] Cabal revision online form silently converts file to Windows line endings, breaking patches In-Reply-To: <87sgthwb37.fsf@write-only.cryp.to> References: <3a029520-2f37-542d-8cf3-1d131442a4e3@nh2.me> <87sgthwb37.fsf@write-only.cryp.to> Message-ID: The main problem being that if they're using basic web upload for the file, it's using network CRLF. On Tue, May 14, 2019 at 7:05 AM Peter Simons wrote: > Hi guys, > > > The diff program has an option to --ignore-trailing-space > > (-Z for short) that will totally ignore changes of `\n` > > to `\n\r` and vice versa. And so you will see only > > 'actual' changes. > > more importantly, patch(1) has an option --ignore-whitespace > that helps applying patches to a revised Cabal file which > suddenly comes along with CRLF line endings. Using that flag > with diff(1) when creating the patch is a good idea, but it > won't make the patch resistant against failures when it's > applied to a modified Cabal file. > > > Another generally useful option is --ignore-space-change > > (-b for short) that will ignore indentation changes. > > Another option that you may use is --ignore-all-space. > > This option is actually somewhat dangerous when applied in > cases where the underlying source relies on layout to convey > structure, because changes in indention will be lost with > that flag enabled. > > Generally speaking, Hackage's policy of adding CRLFs to > edited files seems like a bad idea. The least intrusive > choice would be to follow whatever line-ending convention > the original Cabal file has and to adhere to that. > > Anyway, I'll throw in a historical footnote for good > measure: [1] > > Best regards, > Peter > > > [1] https://github.com/commercialhaskell/all-cabal-files/issues/11 > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Tue May 14 15:21:09 2019 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 14 May 2019 17:21:09 +0200 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) In-Reply-To: <373a7355-9281-6c3e-6b17-9c83ca38ae41@durchholz.org> References: <373a7355-9281-6c3e-6b17-9c83ca38ae41@durchholz.org> Message-ID: <20190514152109.GA28951@octa> Hi Joachim, On Tue, May 14, 2019 at 04:32:34PM +0200, Joachim Durchholz wrote: > The usual understanding of the LGPL enforces the LGPL license only on the > lib-gmp code itself and any modifications you make to it, not on any other > parts of the code. if you follow the LGPL strictly - which I think almost nobody does - you also have to provide a development kit for you application, that users can relink your application with newer versions of the lib-gmp. Greetings, Daniel From monnier at iro.umontreal.ca Tue May 14 15:23:30 2019 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Tue, 14 May 2019 11:23:30 -0400 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) References: Message-ID: > The provided windows version of GHC contains lib-gmp. > Hence, this version enforces a LGPL license on my code I think you're confusing the GPL and the LGPL here. Otherwise, please clarify what you mean by "enforces a LGPL license on my code". Stefan From daniel.trstenjak at gmail.com Tue May 14 15:31:43 2019 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 14 May 2019 17:31:43 +0200 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) In-Reply-To: <20190514152109.GA28951@octa> References: <373a7355-9281-6c3e-6b17-9c83ca38ae41@durchholz.org> <20190514152109.GA28951@octa> Message-ID: <20190514153143.GA29249@octa> On Tue, May 14, 2019 at 05:21:09PM +0200, Daniel Trstenjak wrote: > if you follow the LGPL strictly - which I think almost nobody does - you > also have to provide a development kit for you application, that users > can relink your application with newer versions of the lib-gmp. I should have added, that you should be fine - no need for a development kit - as long as you don't statically link the lib-gmp. Greetings, Daniel From cdsmith at gmail.com Tue May 14 16:07:30 2019 From: cdsmith at gmail.com (Chris Smith) Date: Tue, 14 May 2019 12:07:30 -0400 Subject: [Haskell-cafe] You're invited to the New York Haskell CoHack Message-ID: Fellow Haskellers, In cooperation with the New York Haskell User Group, I'm now organizing a monthly co-hacking event for Haskell programmers in New York. We are meeting on June 1st, and the first Saturday of each month after that. (However, to avoid the U.S. holiday weekend, we're meeting on June 29 instead of July 6.) More details and RSVP form at https://www.meetup.com/NY-Haskell/events/261245898/ This is an informal event where you can meet and collaborate with the rest of the Haskell community in New York. I am taking the format from the Atlanta Haskathon , where it's worked really well. We'll have time for lightning talks, and then open hacking time. To stay focused on project work, we will ask everyone to state a goal for the day, and check in on progress when we're wrapping up. Your choice of goal, though, is entirely up to you. You can use the time to collaborate on a project, get help learning Haskell or advice on using libraries or tools, help others, or just work by yourself. There will be refreshments provided courtesy of the Microsoft Reactor space. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz at gmail.com Tue May 14 17:05:59 2019 From: raoknz at gmail.com (Richard O'Keefe) Date: Wed, 15 May 2019 05:05:59 +1200 Subject: [Haskell-cafe] Scrap your boilerplate In-Reply-To: References: <8007491557803567@iva8-d09e540be28d.qloud-c.yandex.net> Message-ID: I'm more confused by "get rid of repetitive code" than by "scrap your boilerplate". On Tue, 14 May 2019 at 17:53, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > On Tue, 14 May 2019 at 11:13, The FLOSS Information < > theflossinformation at yandex.com> wrote: > >> Scrap your boilerplate >> >> Can you write the synonyms of the words in this sentence? I think that >> such a method is necessary to avoid meaning confusion. >> > > Get rid of repetitive code? > > Is that what you were after? > > >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Tue May 14 18:42:09 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 14 May 2019 20:42:09 +0200 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) In-Reply-To: <20190514152109.GA28951@octa> References: <373a7355-9281-6c3e-6b17-9c83ca38ae41@durchholz.org> <20190514152109.GA28951@octa> Message-ID: Am 14.05.19 um 17:21 schrieb Daniel Trstenjak: > Hi Joachim, > > On Tue, May 14, 2019 at 04:32:34PM +0200, Joachim Durchholz wrote: >> The usual understanding of the LGPL enforces the LGPL license only on the >> lib-gmp code itself and any modifications you make to it, not on any other >> parts of the code. > > if you follow the LGPL strictly - which I think almost nobody does - you > also have to provide a development kit for you application, that users > can relink your application with newer versions of the lib-gmp. Mmm... sort-of. You have to make sure that people can take lib-gmp, change it, and relink your application with it. A reference to a standard build environment should be enough to fulfil that requirement, though it can become a bit more difficult if you have packaging steps after linking. From allbery.b at gmail.com Tue May 14 18:46:29 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 14 May 2019 14:46:29 -0400 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) In-Reply-To: References: <373a7355-9281-6c3e-6b17-9c83ca38ae41@durchholz.org> <20190514152109.GA28951@octa> Message-ID: Most of the builds use a system or packaged libgmp of some variety, so it's not even bundled with ghc. (This includes Windows builds, using the package from msys2.) On Tue, May 14, 2019 at 2:42 PM Joachim Durchholz wrote: > Am 14.05.19 um 17:21 schrieb Daniel Trstenjak: > > Hi Joachim, > > > > On Tue, May 14, 2019 at 04:32:34PM +0200, Joachim Durchholz wrote: > >> The usual understanding of the LGPL enforces the LGPL license only on > the > >> lib-gmp code itself and any modifications you make to it, not on any > other > >> parts of the code. > > > > if you follow the LGPL strictly - which I think almost nobody does - you > > also have to provide a development kit for you application, that users > > can relink your application with newer versions of the lib-gmp. > > Mmm... sort-of. You have to make sure that people can take lib-gmp, > change it, and relink your application with it. > A reference to a standard build environment should be enough to fulfil > that requirement, though it can become a bit more difficult if you have > packaging steps after linking. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Tue May 14 19:14:43 2019 From: lonetiger at gmail.com (Phyx) Date: Tue, 14 May 2019 20:14:43 +0100 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) In-Reply-To: References: <373a7355-9281-6c3e-6b17-9c83ca38ae41@durchholz.org> <20190514152109.GA28951@octa> Message-ID: > Most of the builds use a system or packaged libgmp of some variety, so it's not even bundled with ghc. (This includes Windows builds, using the package from msys2.) Windows uses a statistically linked gmp built from source during the ghc bootstrap. It does not use libgmp from msys2. The difficulty here is that Haskell programs should work regardless of if you're running in msys2 or not. Compared to other languages that are dynamically linked ghc has no "runtime libraries". You'd have to ship libgmp with every application you make. On Tue, May 14, 2019, 19:47 Brandon Allbery wrote: > Most of the builds use a system or packaged libgmp of some variety, so > it's not even bundled with ghc. (This includes Windows builds, using the > package from msys2.) > > On Tue, May 14, 2019 at 2:42 PM Joachim Durchholz > wrote: > >> Am 14.05.19 um 17:21 schrieb Daniel Trstenjak: >> > Hi Joachim, >> > >> > On Tue, May 14, 2019 at 04:32:34PM +0200, Joachim Durchholz wrote: >> >> The usual understanding of the LGPL enforces the LGPL license only on >> the >> >> lib-gmp code itself and any modifications you make to it, not on any >> other >> >> parts of the code. >> > >> > if you follow the LGPL strictly - which I think almost nobody does - you >> > also have to provide a development kit for you application, that users >> > can relink your application with newer versions of the lib-gmp. >> >> Mmm... sort-of. You have to make sure that people can take lib-gmp, >> change it, and relink your application with it. >> A reference to a standard build environment should be enough to fulfil >> that requirement, though it can become a bit more difficult if you have >> packaging steps after linking. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From theflossinformation at yandex.com Wed May 15 01:46:49 2019 From: theflossinformation at yandex.com (The FLOSS Information) Date: Wed, 15 May 2019 04:46:49 +0300 Subject: [Haskell-cafe] Scrap your boilerplate In-Reply-To: References: <8007491557803567@iva8-d09e540be28d.qloud-c.yandex.net> Message-ID: <36916171557884809@iva3-9f0a2b3ff63a.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From jo at durchholz.org Wed May 15 04:57:46 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 15 May 2019 06:57:46 +0200 Subject: [Haskell-cafe] Scrap your boilerplate In-Reply-To: <36916171557884809@iva3-9f0a2b3ff63a.qloud-c.yandex.net> References: <8007491557803567@iva8-d09e540be28d.qloud-c.yandex.net> <36916171557884809@iva3-9f0a2b3ff63a.qloud-c.yandex.net> Message-ID: <0dc7c9ac-7c48-9c4b-ef7e-12d44d157bb8@durchholz.org> Every language has its idioms where a word-by-word translation would be misleading. Even communities have this, and programming is no exception. "Boilerplate" is a term from the programming community, and you simply have to learn its meaning in programming - just as the meanings of "the program knows", "bus", "keyboard", "tree", etc. etc. pp. Am 15.05.19 um 03:46 schrieb The FLOSS Information: > I think the proposed term is less confusing because the other term has > more than one meaning in our language and it's a little hard to decide > which one is right. > 14.05.2019, 20:06, "Richard O'Keefe" : > > I'm more confused by "get rid of repetitive code" than by "scrap > your boilerplate". > On Tue, 14 May 2019 at 17:53, Ivan Lazar Miljenovic > > wrote: > > On Tue, 14 May 2019 at 11:13, The FLOSS Information > > wrote: > > Scrap your boilerplate > Can you write the synonyms of the words in this sentence? I > think that such a method is necessary to avoid meaning > confusion. > > Get rid of repetitive code? > Is that what you were after? From winterland1989 at gmail.com Wed May 15 11:24:23 2019 From: winterland1989 at gmail.com (Dong Han) Date: Wed, 15 May 2019 19:24:23 +0800 Subject: [Haskell-cafe] [ANN] stdio-0.2.0.0 Message-ID: Dear Haskellers, Today I'm very happy to announce a new beta version of stdio is released on hackage , there're some large additions in this version: - Add UDP module. - Add JSON module. - Add ToText class to Std.Data.TextBuilder module. The largest addition is a new JSON module, features full RFC 8259 compliance and 2~3x faster performance . Try to bring big improvements over a very mature library like aeson is not an easy task, parts of the improvements come from faster Parser and Builder infrastructures in stdio. But we also made a few other improvements: - To improve building lookup table during JSON parsing(and many other formats as well), An ordered map module based on sorted vectors and binary-search is also added, there're actually four modules providing similar functions to containers: - Std.Data.Vector.FlatMap - Std.Data.Vector.FlatIntMap - Std.Data.Vector.FlatSet - Std.Data.Vector.FlatIntSet These data structures have different time and memory characteristics from tree-based ones, and suits some situations better, e.g. intermediate lookup table. - To improve JSON string parsing, we made an UTF-8 validation state machine with JSON unescaping logic built-in written in C, combine with the ability to scan a whole chunk of input(provided by our new Parser, namely scanChunks), we now have faster JSON string parsing performance than some native code(JSON.parse from nodejs). - Numeric parsing is also improved, e.g. we changed Integer decoding loop to use machine words if range permits, then covert the result to Integer rather than use Integer all the time. There're also lots of improvements and simplifications contribute to faster performance. Overall this is good proof that our new Parser and Builder infrastructures work well. Besides the JSON module, another important addition is the ToText class in Std.Data.TextBuilder, which is also derivable via generics. The format is chosen to follow Show class as much as possible, this is a very handy class when you need to quickly turn something into a builder or text. A UDP module is added quite easily since the IO manager part is in place. Due to the message based nature, the API is quite different from TCP, design suggestions are welcomed! Happy hacking! ~Cheers Han Dong -------------- next part -------------- An HTML attachment was scrubbed... URL: From yallop at gmail.com Wed May 15 13:14:58 2019 From: yallop at gmail.com (Jeremy Yallop) Date: Wed, 15 May 2019 14:14:58 +0100 Subject: [Haskell-cafe] Metaprogramming Summer School (August 2019): call for applications Message-ID: ==================================================================== Second International Summer School on Metaprogramming Schloss Dagstuhl, Leibniz Center for Informatics, Germany 11th-16th August 2019 (the week before ICFP'19) https://www.cl.cam.ac.uk/events/metaprog/2019/ ==================================================================== Metaprogramming is an approach to constructing programs by treating program fragments (such as expressions or types) as values that the program can manipulate. Metaprogramming comes in various forms --- for example, * in dependently-typed programming terms appear within types, supporting the construction of precise specifications of functions and data. * in multi-stage programming expressions are program values, making it possible to write safe program generation programs that can significantly improve performance. * in languages with macros programs execute partly during compilation and partly at run-time, eliminating the sharp distinction between built-in and user-defined constructs. * embedded domain-specific languages reuse host language features such as syntax and type-checking for convenient definition of little languages suited to a particular endeavour. Metaprogramming has many applications, including genericity, proof automation, language extensibility and user-defined optimization. The goal of the summer school is to explore the state-of-the art in metaprogramming and its applications, covering both theory and practice. -------------------------------------------------------------------- Lecturers and courses Oleg Kiselyov (Tohoku University) From the tagless-final cookbook: simple hardware description language and optimization-by-evaluation Matthew Flatt (University of Utah) Building Languages with Racket Conor McBride (University of Strathclyde) TBD Jonathan Protzenko (Microsoft Research Redmond) Meta-F*: efficient meta-programming of the F* compiler at every stage -------------------------------------------------------------------- Prerequisites The school is aimed at graduate students in programming languages and related areas, but is open to researchers, practitioners and strong masters students with the support of a supervisor. Some experience of typed functional programming in Haskell, OCaml, Scala, or a similar language will be assumed. -------------------------------------------------------------------- Costs Thanks to the Schloss Dagstuhl subsidies, accommodation costs are as follows, and the dates are immediately before ICFP'19 (also in Germany): Single-occupancy accommodation: €420 Double-occupancy accommodation: €330 Accommodation costs include full board (in a single- or double-occupancy room, including meals during stay) from Sunday 11 August (evening) to Friday 16 August (afternoon). -------------------------------------------------------------------- Application procedure You will need to complete the online registration form at: https://www.cl.cam.ac.uk/events/metaprog/2019/application.html and ensure your referees send your references to: metaprog-2019 at cl.cam.ac.uk by the application deadline. TIMETABLE * 30 June: Application and reference letters deadline. * 10 July: Notification of acceptance. * 11 August: Summer school. -------------------------------------------------------------------- Further information For any questions relating to the school, please contact the organisers (Jeremy Yallop, Ohad Kammar, Yukiyoshi Kameyama) at metaprog-2019 at cl.cam.ac.uk From nathan.bloomfield at automattic.com Wed May 15 15:14:13 2019 From: nathan.bloomfield at automattic.com (Nathan Bloomfield) Date: Wed, 15 May 2019 10:14:13 -0500 Subject: [Haskell-cafe] Speeding up compilation of a happy generated parser Message-ID: Hello all! I'm using Alex/Happy to generate a parser for PHP. This is my first go at using a parser generator instead of parser combinators and it's been going pretty smoothly so far, but I've hit a snag. Compiling the happy-generated parser is excruciatingly slow -- 20+ minutes with -O0 -- which messes up the typically very fast feedback loop haskell+ghci allows. Running the code is great; my quickcheck test suite is very fast. But compiling and loading into ghci are so slow that iterating on the project further is not practical until I can figure out how to speed it up. Are there any folklore techniques for dealing with this problem, or any resources about how to profile/debug slow compilation? I'm on macos using Stack with lts-13.21, which includes happy-1.19.10. I tried the ideas in this known issue: https://github.com/simonmar/happy/issues/109. I also tried downgrading to lts-6.35 (the most recent with GHC 7.*), all with similar results. I imagine some of this slowdown is inevitable because of the grammar's size; it has ~275 nonterminals and the generated `Parser.hs` module is 3.8MB. Usually for a problem like this I'd break the module up into smaller pieces that won't change as often, but in this case it's an opaque monolith generated by happy. I also see that the generated code doesn't have type signatures on all top level functions. Here's the relevant output from GHC with -v2 enabled: ``` *** Parser [PHP.Parse.Parser]: !!! Parser [PHP.Parse.Parser]: finished in 1980.24 milliseconds, allocated 3155.733 megabytes *** Renamer/typechecker [PHP.Parse.Parser]: !!! Renamer/typechecker [PHP.Parse.Parser]: finished in 243923.86 milliseconds, allocated 178189.005 megabytes *** Desugar [PHP.Parse.Parser]: Result size of Desugar (before optimization) = {terms: 1,346,664, types: 672,082,252, coercions: 789, joins: 0/9,651} Result size of Desugar (after optimization) = {terms: 834,353, types: 285,053,589, coercions: 246,053, joins: 235/735} !!! Desugar [PHP.Parse.Parser]: finished in 103983.68 milliseconds, allocated 17597.213 megabytes *** Simplifier [PHP.Parse.Parser]: Result size of Simplifier iteration=1 = {terms: 1,059,012, types: 69,942,882, coercions: 1,934,739, joins: 235/1,935} Result size of Simplifier iteration=2 = {terms: 815,760, types: 64,805,160, coercions: 1,368,873, joins: 233/1,929} Result size of Simplifier = {terms: 776,400, types: 64,474,214, coercions: 1,297,320, joins: 233/1,929} !!! Simplifier [PHP.Parse.Parser]: finished in 197842.50 milliseconds, allocated 116983.797 megabytes *** CoreTidy [PHP.Parse.Parser]: Result size of Tidy Core = {terms: 776,400, types: 64,474,214, coercions: 1,297,320, joins: 233/1,929} !!! CoreTidy [PHP.Parse.Parser]: finished in 97776.92 milliseconds, allocated 11254.968 megabytes *** CorePrep [PHP.Parse.Parser]: Result size of CorePrep = {terms: 795,714, types: 66,237,082, coercions: 1,297,320, joins: 233/4,234} !!! CorePrep [PHP.Parse.Parser]: finished in 7911.78 milliseconds, allocated 2564.067 megabytes *** Stg2Stg: *** CodeGen [PHP.Parse.Parser]: !!! CodeGen [PHP.Parse.Parser]: finished in 7048.73 milliseconds, allocated 6407.563 megabytes *** Assembler: *** CorePrep [PHP.Parse.Parser]: Result size of CorePrep = {terms: 795,714, types: 66,237,082, coercions: 1,297,320, joins: 233/4,234} !!! CorePrep [PHP.Parse.Parser]: finished in 3069.67 milliseconds, allocated 2564.018 megabytes *** Stg2Stg: *** CodeGen [PHP.Parse.Parser]: !!! CodeGen [PHP.Parse.Parser]: finished in 5970.62 milliseconds, allocated 6634.422 megabytes *** Assembler: *** Deleting temp files: Warning: deleting non-existent /var/folders/td/sxyy9wl919740vddr49g8nth0000gn/T/ghc1272_0/ghc_70.s Warning: deleting non-existent /var/folders/td/sxyy9wl919740vddr49g8nth0000gn/T/ghc1272_0/ghc_72.c Warning: deleting non-existent /var/folders/td/sxyy9wl919740vddr49g8nth0000gn/T/ghc1272_0/ghc_74.c ``` -- Nathan Bloomfield Systems Analyst, Team Neutron Automattic, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From permeakra at gmail.com Thu May 16 07:02:28 2019 From: permeakra at gmail.com (Evgeny Permyakov) Date: Thu, 16 May 2019 10:02:28 +0300 Subject: [Haskell-cafe] Dispatching user code at runtime, injecting appropriate typeclass instances into user code scope Message-ID: Let's suppose that at runtime I create a hardware context and test it for a set of supported operation and want to adapt the way I work with it based on the set of operations available. (RL example: OpenGL extension discovery and use) Naturally, I can create a function that checks hardware and then, based on the result, returns different dictionaries of functions over the context, maybe as closures. This is verbose and crude, even if it shall work. However, I want to work with the context using a typeclass interface. It isn't hard when number of options is low. I suppose, we can use something like typeclass Context a where > { dispatch :: MonadIO m => forall k . Context a -> (forall a . Testable1 > a -> a -> m k) -> (forall a. Testable2 a -> a -> m k ) -> a -> m k } > Here, Context typeclass defines a function that selects appropriate handler from the set of user-provided functions and each instance takes the function it likes. Fine. The problems are twofold: - This is not extensible, the set of possible cases is defined on the definition of Context typeclass - This approach is hardly appropriate if we have a lot of cases, For example, if context may support ten optional operation sets in addtion to basic one, the number of possible cases *dispatch* needs to support A more modular approach is needed, something like (pseudocode) dispatch :: typeclassSet Defined, -- collection of defined typeclasses typeClass Tested, -- what we test for Dispatchable a, Defined a -- what we test =>forall b. (forall a . Defined a => a -> b) -- 'fallback' function -> (forall a . Defined a, Tested a => a -> b) -- this is called if A supports Tested interface. -> b This way one can gradually inject typeclass instances into scope. But how I can do it? PS. Naturally, I don't want to expose internals of the type I dispatch over, it is an abstract type. -------------- next part -------------- An HTML attachment was scrubbed... URL: From permeakra at gmail.com Thu May 16 07:52:17 2019 From: permeakra at gmail.com (Evgeny Permyakov) Date: Thu, 16 May 2019 10:52:17 +0300 Subject: [Haskell-cafe] Dispatching user code at runtime, injecting appropriate typeclass instances into user code scope In-Reply-To: References: Message-ID: Hi. reflection is about selecting a type instance of a typeclass that is known to exist over type. Completely different thing. Monads ... I guess, using monadic context in some way is an option, but not exactly what I have in mind. Still, worth looking into. On Thu, 16 May 2019 at 10:20, Georgi Lyubenov wrote: > Hi, > > It seems like the "extensible" parts you want is something similar to most > extensible effects stuff. Perhaps check out the "Member stuff" from the > "Freer Monads, More Extensible Effects" paper and some EE libraries > (freer-simple, fused-effects, polysemy)? Also, if you want runtime > typeclasses reflection can > help. > > ======= > Georgi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Fri May 17 03:12:43 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Fri, 17 May 2019 11:12:43 +0800 Subject: [Haskell-cafe] How to express a logic matrix clearly? Message-ID: Hi, I have trouble describing this clearly. Let me show code directly. data Rule1 = A1 | A2 | A3 data Rule2 = B1 | B2 | B3 foo a b = if a == A1 then if b == B1 then fun1 else if b == B2 then fun2 else if b == B3 then fun3 else fun4 ... Basically, Rule1 and Rule2 compose a matrix, for each case of Rule1 and Rule2, I need to do different things. Above is already long and not quite clear, and it is far from complete. So my question is, is there a way/lib that I can make this clear to read/understand? From nathan.bloomfield at automattic.com Fri May 17 03:21:14 2019 From: nathan.bloomfield at automattic.com (Nathan Bloomfield) Date: Thu, 16 May 2019 22:21:14 -0500 Subject: [Haskell-cafe] How to express a logic matrix clearly? In-Reply-To: References: Message-ID: This is a good opportunity to use case syntax. You can also case on tuples, like this: ``` foo a b = case (a,b) of (A1,B1) -> fun1 (A1,B2) -> fun2 (A1,B3) -> fun3 (A1,_) -> fun4 <- this is probably not necessary anymore, unless you expect Rule2 to get more constructors. (A2,B1) -> fun5 ... ``` On Thu, May 16, 2019 at 10:14 PM Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Hi, > I have trouble describing this clearly. Let me show code directly. > > data Rule1 = A1 | A2 | A3 > data Rule2 = B1 | B2 | B3 > > foo a b = > if a == A1 > then if b == B1 > then fun1 > else if b == B2 > then fun2 > else if b == B3 > then fun3 > else fun4 > ... > > Basically, Rule1 and Rule2 compose a matrix, for each case of Rule1 > and Rule2, I need to do different things. Above is already long and > not quite clear, and it is far from complete. > > So my question is, is there a way/lib that I can make this clear to > read/understand? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Nathan Bloomfield Code Wrangler, Team Absinthe Automattic, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa.mchale at iohk.io Fri May 17 03:24:59 2019 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Thu, 16 May 2019 22:24:59 -0500 Subject: [Haskell-cafe] How to express a logic matrix clearly? In-Reply-To: References: Message-ID: <1175676e-ac6f-9a73-e2fa-17c612059884@iohk.io> For one, you should pattern match rather than using nested ifs, viz. foo A1 B1 = fun1 Using a case statement on tuples is not necessary. On 5/17/19 3:12 AM, Magicloud Magiclouds wrote: > Hi, > I have trouble describing this clearly. Let me show code directly. > > data Rule1 = A1 | A2 | A3 > data Rule2 = B1 | B2 | B3 > > foo a b = > if a == A1 > then if b == B1 > then fun1 > else if b == B2 > then fun2 > else if b == B3 > then fun3 > else fun4 > ... > > Basically, Rule1 and Rule2 compose a matrix, for each case of Rule1 > and Rule2, I need to do different things. Above is already long and > not quite clear, and it is far from complete. > > So my question is, is there a way/lib that I can make this clear to > read/understand? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From magicloud.magiclouds at gmail.com Fri May 17 03:24:51 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Fri, 17 May 2019 11:24:51 +0800 Subject: [Haskell-cafe] How to express a logic matrix clearly? In-Reply-To: References: Message-ID: Yes, that is a good way. I was thinking something like a "table". Well, just realize that if it was a more dimension, it is hard to express in 2-D text anyway.... On Fri, May 17, 2019 at 11:21 AM Nathan Bloomfield wrote: > > This is a good opportunity to use case syntax. You can also case on tuples, like this: > > ``` > foo a b = case (a,b) of > (A1,B1) -> fun1 > (A1,B2) -> fun2 > (A1,B3) -> fun3 > (A1,_) -> fun4 <- this is probably not necessary anymore, unless you expect Rule2 to get more constructors. > (A2,B1) -> fun5 > ... > ``` > > On Thu, May 16, 2019 at 10:14 PM Magicloud Magiclouds wrote: >> >> Hi, >> I have trouble describing this clearly. Let me show code directly. >> >> data Rule1 = A1 | A2 | A3 >> data Rule2 = B1 | B2 | B3 >> >> foo a b = >> if a == A1 >> then if b == B1 >> then fun1 >> else if b == B2 >> then fun2 >> else if b == B3 >> then fun3 >> else fun4 >> ... >> >> Basically, Rule1 and Rule2 compose a matrix, for each case of Rule1 >> and Rule2, I need to do different things. Above is already long and >> not quite clear, and it is far from complete. >> >> So my question is, is there a way/lib that I can make this clear to >> read/understand? >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Nathan Bloomfield > Code Wrangler, Team Absinthe > Automattic, Inc. From magicloud.magiclouds at gmail.com Fri May 17 03:26:45 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Fri, 17 May 2019 11:26:45 +0800 Subject: [Haskell-cafe] How to express a logic matrix clearly? In-Reply-To: <1175676e-ac6f-9a73-e2fa-17c612059884@iohk.io> References: <1175676e-ac6f-9a73-e2fa-17c612059884@iohk.io> Message-ID: This works, but may not suitable as case. Sometimes it may be hard to name the function just for branching. On Fri, May 17, 2019 at 11:25 AM Vanessa McHale wrote: > > For one, you should pattern match rather than using nested ifs, viz. > > foo A1 B1 = fun1 > > Using a case statement on tuples is not necessary. > > On 5/17/19 3:12 AM, Magicloud Magiclouds wrote: > > Hi, > > I have trouble describing this clearly. Let me show code directly. > > > > data Rule1 = A1 | A2 | A3 > > data Rule2 = B1 | B2 | B3 > > > > foo a b = > > if a == A1 > > then if b == B1 > > then fun1 > > else if b == B2 > > then fun2 > > else if b == B3 > > then fun3 > > else fun4 > > ... > > > > Basically, Rule1 and Rule2 compose a matrix, for each case of Rule1 > > and Rule2, I need to do different things. Above is already long and > > not quite clear, and it is far from complete. > > > > So my question is, is there a way/lib that I can make this clear to > > read/understand? > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Fri May 17 09:37:20 2019 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 17 May 2019 10:37:20 +0100 Subject: [Haskell-cafe] How to express a logic matrix clearly? In-Reply-To: References: Message-ID: <20190517093720.u5sbatzp7s6ilawt@weber> On Thu, May 16, 2019 at 10:21:14PM -0500, Nathan Bloomfield wrote: > This is a good opportunity to use case syntax. You can also case on tuples, > like this: > > ``` > foo a b = case (a,b) of > (A1,B1) -> fun1 > (A1,B2) -> fun2 > (A1,B3) -> fun3 > (A1,_) -> fun4 <- this is probably not necessary anymore, unless you > expect Rule2 to get more constructors. > (A2,B1) -> fun5 > ... > ``` In fact, and this is veering somewhat off-topic, but I would strongly recommend *not* making a default match `(A1,_)` because then you will get an explicit warning if indeed `Rule2` gets more constructors. From jvilar at uji.es Fri May 17 09:48:33 2019 From: jvilar at uji.es (Juan Miguel Vilar) Date: Fri, 17 May 2019 11:48:33 +0200 Subject: [Haskell-cafe] Identity operator for types Message-ID: <9ea98a37-21b1-cbfa-4964-a9a4a38e0412@uji.es> Hi, Café: I am not sure how to make the question, but the idea is to have a type operator that returns the same type. Let me show what I need. I have some type like this: data Example f t = Example (f t) So if I want a type variable that contains a list of integers, I can use Example [] Int and then treat the content like a list: f :: Example [] Int -> Int f (Example l) = length l Now, the problem is what can I do to have a type that contains a single Int? Is there a sort of id for types so that I can write f :: Example ?? Int -> Int f (Example i) = 2 * i ? Thanks in advance Juan Miguel Vilar -- Juan Miguel Vilar Torres Profesor titular de universidad Departamento de Lenguajes y Sistemas Informáticos Escuela Superior de Tecnología y Ciencias Experimentales Universitat Jaume I Av. de Vicent Sos Baynat s/n 12071 Castelló de la Plana (Spain) Tel: +34 964 72 8365 Fax: +34 964 72 8435 jvilar at uji.es From alex at kazik.de Fri May 17 09:56:17 2019 From: alex at kazik.de (ALeX Kazik) Date: Fri, 17 May 2019 11:56:17 +0200 Subject: [Haskell-cafe] Identity operator for types In-Reply-To: <9ea98a37-21b1-cbfa-4964-a9a4a38e0412@uji.es> References: <9ea98a37-21b1-cbfa-4964-a9a4a38e0412@uji.es> Message-ID: Hi Juan, > Now, the problem is what can I do to have a type that contains a > single Int? Is there a sort of id for types so that I can write Identity is the solution f :: Example Identity Int -> Int f (Example i) = 2 * runIdentity i Alex. From jvilar at uji.es Fri May 17 10:33:08 2019 From: jvilar at uji.es (Juan Miguel Vilar) Date: Fri, 17 May 2019 12:33:08 +0200 Subject: [Haskell-cafe] Identity operator for types In-Reply-To: References: <9ea98a37-21b1-cbfa-4964-a9a4a38e0412@uji.es> Message-ID: <908d7d63-6b63-6671-06f2-f20d735c8fc7@uji.es> El 17/5/19 a las 11:56, ALeX Kazik escribió: > Hi Juan, > >> Now, the problem is what can I do to have a type that contains a >> single Int? Is there a sort of id for types so that I can write > > Identity is the solution > > f :: Example Identity Int -> Int > f (Example i) = 2 * runIdentity i > > Alex. > Thank you Alex, but this forces the use of runIdentity. I am aware that Identity Int and Int are isomorphic, but my problem is more aesthetic, I would like that the f t was t. I want to use it in a library and I don't want the users to be aware of details that should be irrelevant. Sometimes they will use lists, sometimes simple times, and would like that to be as transparent as possible. Juan Miguel -- Juan Miguel Vilar Torres Profesor titular de universidad Departamento de Lenguajes y Sistemas Informáticos Escuela Superior de Tecnología y Ciencias Experimentales Universitat Jaume I Av. de Vicent Sos Baynat s/n 12071 Castelló de la Plana (Spain) Tel: +34 964 72 8365 Fax: +34 964 72 8435 jvilar at uji.es From ben.franksen at online.de Fri May 17 10:45:18 2019 From: ben.franksen at online.de (Benjamin Franksen) Date: Fri, 17 May 2019 12:45:18 +0200 Subject: [Haskell-cafe] Identity operator for types In-Reply-To: <908d7d63-6b63-6671-06f2-f20d735c8fc7@uji.es> References: <9ea98a37-21b1-cbfa-4964-a9a4a38e0412@uji.es> <908d7d63-6b63-6671-06f2-f20d735c8fc7@uji.es> Message-ID: Am 17.05.19 um 12:33 schrieb Juan Miguel Vilar: > El 17/5/19 a las 11:56, ALeX Kazik escribió: >>> Now, the problem is what can I do to have a type that contains a >>> single Int? Is there a sort of id for types so that I can write >> >> Identity is the solution >> >> f :: Example Identity Int -> Int >> f (Example i) = 2 * runIdentity i >> > Thank you Alex, but this forces the use of runIdentity. I am aware that > Identity Int and Int are isomorphic, but my problem is more aesthetic, I > would like that the f t was t. I want to use it in a library and I don't > want the users to be aware of details that should be irrelevant. > Sometimes they will use lists, sometimes simple times, and would like > that to be as transparent as possible. https://reasonablypolymorphic.com/blog/higher-kinded-data/ shows how to do that using closed type families. Cheers Ben From jack at jackkelly.name Fri May 17 11:01:57 2019 From: jack at jackkelly.name (Jack Kelly) Date: Fri, 17 May 2019 21:01:57 +1000 Subject: [Haskell-cafe] Identity operator for types In-Reply-To: <908d7d63-6b63-6671-06f2-f20d735c8fc7@uji.es> (Juan Miguel Vilar's message of "Fri, 17 May 2019 12:33:08 +0200") References: <9ea98a37-21b1-cbfa-4964-a9a4a38e0412@uji.es> <908d7d63-6b63-6671-06f2-f20d735c8fc7@uji.es> Message-ID: <87v9y9ibtm.fsf@jackkelly.name> Juan Miguel Vilar writes: > El 17/5/19 a las 11:56, ALeX Kazik escribió: >>> Now, the problem is what can I do to have a type that contains a >>> single Int? Is there a sort of id for types so that I can write >> >> Identity is the solution >> > Thank you Alex, but this forces the use of runIdentity. [...] > Sometimes they will use lists, sometimes simple times, and would like > that to be as transparent as possible. I do not like the sibling thread's suggestion of using closed type families, because I think the regulatity of always having the `f t` present is a nicer aesthetic. Using a type family to unwrap the `Identity` makes it noisier to write functions that consume your structure and are polymorphic in `f`. You can alleviate some of the syntactic noise of `runIdentity` with careful choices of type aliases or other helper functions. The type aliases (and `runFoo` functions) for monad transformers are good examples, and the `(==>)` function in dependent-sum[1] is a good additional example of the latter. To save you the click, DSum in dependent-sum is defined like this: data DSum tag f where !(tag a) :=> f a The (==>) helper is defined like this: (==>) :: Applicative f => tag a -> a -> DSum tag f tag ==> a = tag :=> f a So when f ~ Identity (or any other Applicative), the machinery becomes that much easier to use. -- Jack [1]: https://hackage.haskell.org/package/dependent-sum-0.5/docs/Data-Dependent-Sum.html From jvilar at uji.es Fri May 17 14:55:28 2019 From: jvilar at uji.es (Juan Miguel Vilar) Date: Fri, 17 May 2019 16:55:28 +0200 Subject: [Haskell-cafe] Identity operator for types In-Reply-To: <87v9y9ibtm.fsf@jackkelly.name> References: <9ea98a37-21b1-cbfa-4964-a9a4a38e0412@uji.es> <908d7d63-6b63-6671-06f2-f20d735c8fc7@uji.es> <87v9y9ibtm.fsf@jackkelly.name> Message-ID: <7b9ccdf9-5713-eb95-f460-931cb91ef680@uji.es> El 17/5/19 a las 13:01, Jack Kelly escribió: > Juan Miguel Vilar writes: > >> El 17/5/19 a las 11:56, ALeX Kazik escribió: >>>> Now, the problem is what can I do to have a type that contains a >>>> single Int? Is there a sort of id for types so that I can write >>> >>> Identity is the solution >>> >> Thank you Alex, but this forces the use of runIdentity. [...] >> Sometimes they will use lists, sometimes simple times, and would like >> that to be as transparent as possible. > > I do not like the sibling thread's suggestion of using closed type > families, because I think the regulatity of always having the `f t` > present is a nicer aesthetic. Using a type family to unwrap the > `Identity` makes it noisier to write functions that consume your > structure and are polymorphic in `f`. > > You can alleviate some of the syntactic noise of `runIdentity` with > careful choices of type aliases or other helper functions. The type > aliases (and `runFoo` functions) for monad transformers are good > examples, and the `(==>)` function in dependent-sum[1] is a good > additional example of the latter. To save you the click, DSum in > dependent-sum is defined like this: > > data DSum tag f where > !(tag a) :=> f a > > The (==>) helper is defined like this: > > (==>) :: Applicative f => tag a -> a -> DSum tag f > tag ==> a = tag :=> f a > > So when f ~ Identity (or any other Applicative), the machinery becomes > that much easier to use. > > -- Jack > > [1]: https://hackage.haskell.org/package/dependent-sum-0.5/docs/Data-Dependent-Sum.html > Thank you, Jack: I can't see the sibling thread you mentioned. On the other hand, as I said it is sort of an aesthetic question, so I think I can live with Identity. Juan Miguel -- Juan Miguel Vilar Torres Profesor titular de universidad Departamento de Lenguajes y Sistemas Informáticos Escuela Superior de Tecnología y Ciencias Experimentales Universitat Jaume I Av. de Vicent Sos Baynat s/n 12071 Castelló de la Plana (Spain) Tel: +34 964 72 8365 Fax: +34 964 72 8435 jvilar at uji.es From jack at jackkelly.name Fri May 17 23:52:27 2019 From: jack at jackkelly.name (Jack Kelly) Date: Sat, 18 May 2019 09:52:27 +1000 Subject: [Haskell-cafe] Identity operator for types In-Reply-To: <7b9ccdf9-5713-eb95-f460-931cb91ef680@uji.es> (Juan Miguel Vilar's message of "Fri, 17 May 2019 16:55:28 +0200") References: <9ea98a37-21b1-cbfa-4964-a9a4a38e0412@uji.es> <908d7d63-6b63-6671-06f2-f20d735c8fc7@uji.es> <87v9y9ibtm.fsf@jackkelly.name> <7b9ccdf9-5713-eb95-f460-931cb91ef680@uji.es> Message-ID: <87bm00iqpw.fsf@jackkelly.name> Juan Miguel Vilar writes: > El 17/5/19 a las 13:01, Jack Kelly escribió: > >> I do not like the sibling thread's suggestion of using closed type >> families... > > I can't see the sibling thread you mentioned. On the other hand, as I > said it is sort of an aesthetic question, so I think I can live with > Identity. Oh. In that case, here is the blog post they discussed, with the approach that I personally dislike: https://reasonablypolymorphic.com/blog/higher-kinded-data/ The key part is the HKD type family: {-# LANGUAGE TypeFamilies #-} -- "Higher-Kinded Data" type family HKD f a where HKD Identity a = a HKD f a = f a data Person' f = Person { pName :: HKD f String , pAge :: HKD f Int } deriving (Generic) HTH, -- Jack From magicloud.magiclouds at gmail.com Sat May 18 04:33:00 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sat, 18 May 2019 12:33:00 +0800 Subject: [Haskell-cafe] How to dynamic plan in Haskell? Message-ID: Hi, I solved the question. But I could not figure out a FP style solution. Question: 1 - 9, nine numbers. Show all the possible combinations that sum up to 10. Different orders are counted as the same. For example, [1, 4, 5]. From fa-ml at ariis.it Sat May 18 05:48:18 2019 From: fa-ml at ariis.it (Francesco Ariis) Date: Sat, 18 May 2019 07:48:18 +0200 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: Message-ID: <20190518054818.u2n3fykk7ekiexww@x60s.casa> Hello, On Sat, May 18, 2019 at 12:33:00PM +0800, Magicloud Magiclouds wrote: > I solved the question. But I could not figure out a FP style solution. > > Question: > > 1 - 9, nine numbers. Show all the possible combinations that sum up to > 10. Different orders are counted as the same. A possible solution takes advantage of powersets with the [] Monad. λ> :m +Control.Monad λ> f cs = filterM (\x -> [True, False]) cs λ> filter ((==10) . sum) (f [1..10]) From magicloud.magiclouds at gmail.com Sat May 18 06:00:49 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sat, 18 May 2019 14:00:49 +0800 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: <20190518054818.u2n3fykk7ekiexww@x60s.casa> References: <20190518054818.u2n3fykk7ekiexww@x60s.casa> Message-ID: I see. Did not got the filterM part in mind. Thanks. On Sat, May 18, 2019 at 1:48 PM Francesco Ariis wrote: > > Hello, > > On Sat, May 18, 2019 at 12:33:00PM +0800, Magicloud Magiclouds wrote: > > I solved the question. But I could not figure out a FP style solution. > > > > Question: > > > > 1 - 9, nine numbers. Show all the possible combinations that sum up to > > 10. Different orders are counted as the same. > > A possible solution takes advantage of powersets with the [] Monad. > > λ> :m +Control.Monad > λ> f cs = filterM (\x -> [True, False]) cs > λ> filter ((==10) . sum) (f [1..10]) > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From kane at kane.cx Sat May 18 06:12:50 2019 From: kane at kane.cx (David Kraeutmann) Date: Sat, 18 May 2019 02:12:50 -0400 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: <20190518054818.u2n3fykk7ekiexww@x60s.casa> Message-ID: This is also an interesting solution: sums :: [[Integer]] sums = do   x <- [1..9]   go x [x] (10 - x)   where     go x xs r       | r > 0       = do         x <- [1..min x r]         go x (x:xs) (r - x)       | otherwise = return xs On 05/18/2019 02:00 AM, Magicloud Magiclouds wrote: > I see. Did not got the filterM part in mind. Thanks. > > On Sat, May 18, 2019 at 1:48 PM Francesco Ariis wrote: >> Hello, >> >> On Sat, May 18, 2019 at 12:33:00PM +0800, Magicloud Magiclouds wrote: >>> I solved the question. But I could not figure out a FP style solution. >>> >>> Question: >>> >>> 1 - 9, nine numbers. Show all the possible combinations that sum up to >>> 10. Different orders are counted as the same. >> A possible solution takes advantage of powersets with the [] Monad. >> >> λ> :m +Control.Monad >> λ> f cs = filterM (\x -> [True, False]) cs >> λ> filter ((==10) . sum) (f [1..10]) >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From thomas.dubuisson at gmail.com Sat May 18 07:03:22 2019 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat, 18 May 2019 00:03:22 -0700 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: Message-ID: As an aside: I feel certain I saw a beautiful solution presented as lecture notes and referencing a game show (around 2007). Maybe it was in Hudak's book? Perhaps I missed something, but the answer's I've seen posted thus far are not dynamic programming. Certainly in the powerset case you'll experience exponential costs. Benchmarks are good - try to solve with numbers [1..64] in low numbers of seconds. An explicit 98-ish solution is to have a generator that will refer to the prior indexes in the list when computing the current index. First the boiler plate: ``` {-# LANGUAGE OverloadedLists #-} module Main where import qualified Data.Set as Set import Control.Monad (guard) type Solution = Set.Set Int -- A list of all sets of numbers, no duplicates and ignoring order, -- that sum to the value @index + 1 at . answer :: [[Solution]] answer = fmap op [1..10] where ``` Now for the interesting part. The recursive definition of a solution for value `target` is `[target]` and the solutions for `x` added with the solution for `target - x` where `x <- [0..target/2]. Some care must be taken because solutions will overlap. With that in mind: ``` -- Generate the entry for value @target@ (list index @target - 1@) op :: Int -> [Solution] op target = ([target] :: Solution) -- The target itself is an answer : snub -- Ignore duplicate results -- Better idea: don't generate dups if you can... (do let half = target `div` 2 halfRDown = (target-1) `div` 2 (ls,hs) <- zip (slice 0 half answer) -- Pair 0 .. t/2 -- with t-1, t-2 .. t/2+1 (reverse $ slice half halfRDown answer) l <- ls -- For each solution to the lower number h <- hs -- and the matching solution to the larger number guard (Set.intersection l h == []) -- No repeat values! (?) pure (l <> h) -- target = l + h ) -- | List slice from a base and of given length slice :: Int -> Int -> [a] -> [a] slice base len = take len . drop base -- | Efficient combined sort and nub snub :: (Eq a, Ord a) => [a] -> [a] snub = Set.toList . Set.fromList main :: IO () main = print answers ``` -Thomas On Fri, May 17, 2019 at 9:35 PM Magicloud Magiclouds wrote: > > Hi, > > I solved the question. But I could not figure out a FP style solution. > > Question: > > 1 - 9, nine numbers. Show all the possible combinations that sum up to > 10. Different orders are counted as the same. > > For example, [1, 4, 5]. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From magicloud.magiclouds at gmail.com Sat May 18 09:48:36 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sat, 18 May 2019 17:48:36 +0800 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: <20190518054818.u2n3fykk7ekiexww@x60s.casa> Message-ID: Ah, I did not make it clear. Once for each number. On Sat, May 18, 2019 at 2:11 PM David Kraeutmann wrote: > > This is also an interesting solution: > > sums :: [[Integer]] > sums = do > x <- [1..9] > go x [x] (10 - x) > > where > go x xs r > | r > 0 > = do > x <- [1..min x r] > go x (x:xs) (r - x) > > | otherwise = return xs > > > On 05/18/2019 02:00 AM, Magicloud Magiclouds wrote: > > I see. Did not got the filterM part in mind. Thanks. > > > > On Sat, May 18, 2019 at 1:48 PM Francesco Ariis wrote: > >> Hello, > >> > >> On Sat, May 18, 2019 at 12:33:00PM +0800, Magicloud Magiclouds wrote: > >>> I solved the question. But I could not figure out a FP style solution. > >>> > >>> Question: > >>> > >>> 1 - 9, nine numbers. Show all the possible combinations that sum up to > >>> 10. Different orders are counted as the same. > >> A possible solution takes advantage of powersets with the [] Monad. > >> > >> λ> :m +Control.Monad > >> λ> f cs = filterM (\x -> [True, False]) cs > >> λ> filter ((==10) . sum) (f [1..10]) > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> To (un)subscribe, modify options or view archives go to: > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From magicloud.magiclouds at gmail.com Sat May 18 09:54:21 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sat, 18 May 2019 17:54:21 +0800 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: Message-ID: Thanks. Just to make it clear, the code is for generating candidates, not the answer, right? From first glance, the code shows a lot solutions that do not sum to 10. Have not check if it contains all answers. On Sat, May 18, 2019 at 3:03 PM Thomas DuBuisson wrote: > > As an aside: I feel certain I saw a beautiful solution presented as > lecture notes and referencing a game show (around 2007). Maybe it was > in Hudak's book? > > > Perhaps I missed something, but the answer's I've seen posted thus far > are not dynamic programming. Certainly in the powerset case you'll > experience exponential costs. Benchmarks are good - try to solve with > numbers [1..64] in low numbers of seconds. > > An explicit 98-ish solution is to have a generator that will refer to > the prior indexes in the list when computing the current index. > > > First the boiler plate: > > ``` > {-# LANGUAGE OverloadedLists #-} > module Main where > > import qualified Data.Set as Set > import Control.Monad (guard) > > type Solution = Set.Set Int > > -- A list of all sets of numbers, no duplicates and ignoring order, > -- that sum to the value @index + 1 at . > answer :: [[Solution]] > answer = fmap op [1..10] > where > ``` > > Now for the interesting part. The recursive definition of a solution > for value `target` is `[target]` and the solutions for `x` added with > the solution for `target - x` where `x <- [0..target/2]. Some care > must be taken because solutions will overlap. > > With that in mind: > > ``` > -- Generate the entry for value @target@ (list index @target - 1@) > op :: Int -> [Solution] > op target = > ([target] :: Solution) -- The target itself is an answer > : snub -- Ignore duplicate results > -- Better idea: don't > generate dups if you can... > (do let half = target `div` 2 > halfRDown = (target-1) `div` 2 > (ls,hs) <- zip (slice 0 half answer) -- Pair 0 .. t/2 > -- with t-1, t-2 .. t/2+1 > (reverse $ slice half halfRDown answer) > l <- ls -- For each solution to the lower number > h <- hs -- and the matching solution to the larger number > guard (Set.intersection l h == []) -- No repeat values! (?) > pure (l <> h) -- target = l + h > ) > > -- | List slice from a base and of given length > slice :: Int -> Int -> [a] -> [a] > slice base len = take len . drop base > > -- | Efficient combined sort and nub > snub :: (Eq a, Ord a) => [a] -> [a] > snub = Set.toList . Set.fromList > > main :: IO () > main = print answers > ``` > > -Thomas > > > On Fri, May 17, 2019 at 9:35 PM Magicloud Magiclouds > wrote: > > > > Hi, > > > > I solved the question. But I could not figure out a FP style solution. > > > > Question: > > > > 1 - 9, nine numbers. Show all the possible combinations that sum up to > > 10. Different orders are counted as the same. > > > > For example, [1, 4, 5]. > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. From naur at post11.tele.dk Sat May 18 12:25:15 2019 From: naur at post11.tele.dk (Thorkil Naur) Date: Sat, 18 May 2019 14:25:15 +0200 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: Message-ID: <20190518122515.GA590@Annette-Pc2> Hello, On Sat, May 18, 2019 at 12:33:00PM +0800, Magicloud Magiclouds wrote: > ... > 1 - 9, nine numbers. Show all the possible combinations that sum up to > 10. Different orders are counted as the same. > > For example, [1, 4, 5]. With sumIs n [] = if n == 0 then [[]] else [] sumIs n (x:xs) = (if n < x then [] else map (x:) $ sumIs (n-x) xs ) ++ sumIs n xs we can do: Prelude Main> sumIs 10 [1..9] [[1,2,3,4],[1,2,7],[1,3,6],[1,4,5],[1,9],[2,3,5],[2,8],[3,7],[4,6]] > ... Best Thorkil From magicloud.magiclouds at gmail.com Sat May 18 14:13:21 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sat, 18 May 2019 22:13:21 +0800 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: <20190518122515.GA590@Annette-Pc2> References: <20190518122515.GA590@Annette-Pc2> Message-ID: Thanks. This is kind like my original (did not get through) thought. On Sat, May 18, 2019 at 8:25 PM Thorkil Naur wrote: > > Hello, > > On Sat, May 18, 2019 at 12:33:00PM +0800, Magicloud Magiclouds wrote: > > ... > > 1 - 9, nine numbers. Show all the possible combinations that sum up to > > 10. Different orders are counted as the same. > > > > For example, [1, 4, 5]. > > With > > sumIs n [] = if n == 0 then [[]] else [] > sumIs n (x:xs) > = (if n < x then > [] > else > map (x:) $ sumIs (n-x) xs > ) > ++ sumIs n xs > > we can do: > > Prelude Main> sumIs 10 [1..9] > [[1,2,3,4],[1,2,7],[1,3,6],[1,4,5],[1,9],[2,3,5],[2,8],[3,7],[4,6]] > > > ... > > Best > Thorkil From will.yager at gmail.com Sat May 18 14:18:28 2019 From: will.yager at gmail.com (William Yager) Date: Sat, 18 May 2019 22:18:28 +0800 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: <20190518122515.GA590@Annette-Pc2> Message-ID: Here are two mechanical strategies for implementing DP in haskell: module Main where import Data.Map.Strict as Map import Data.Vector as Vec -- The recursive step rec :: (Int -> [[Int]]) -> Int -> [[Int]] rec rec n = do this <- [1..n] other <- rec (n - this) return $ (this : other) -- Non-dynamic sumsTo1 :: Int -> [[Int]] sumsTo1 0 = [[]] sumsTo1 n = rec sumsTo1 n -- Dynamic (corecursive) sumsTo2 :: Int -> [[Int]] sumsTo2 n = lookup Map.! n where lookup = go 1 (Map.singleton 0 [[]]) go m acc | m > n = acc | otherwise = go (m + 1) (Map.insert m (rec (acc Map.!) m) acc) -- Dynamic (lazy) sumsTo3 :: Int -> [[Int]] sumsTo3 n = lookup Vec.! n where lookup = generate (n + 1) $ \m -> if m == 0 then [[]] else rec (lookup Vec.!) m main = do let a = sumsTo1 10 b = sumsTo2 10 c = sumsTo3 10 print (a == b && b == c) print a In case the formatting is messed up, see https://gist.github.com/wyager/7daebb351d802bbb2a624b71c0f343d3 On Sat, May 18, 2019 at 10:15 PM Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Thanks. This is kind like my original (did not get through) thought. > > On Sat, May 18, 2019 at 8:25 PM Thorkil Naur wrote: > > > > Hello, > > > > On Sat, May 18, 2019 at 12:33:00PM +0800, Magicloud Magiclouds wrote: > > > ... > > > 1 - 9, nine numbers. Show all the possible combinations that sum up to > > > 10. Different orders are counted as the same. > > > > > > For example, [1, 4, 5]. > > > > With > > > > sumIs n [] = if n == 0 then [[]] else [] > > sumIs n (x:xs) > > = (if n < x then > > [] > > else > > map (x:) $ sumIs (n-x) xs > > ) > > ++ sumIs n xs > > > > we can do: > > > > Prelude Main> sumIs 10 [1..9] > > [[1,2,3,4],[1,2,7],[1,3,6],[1,4,5],[1,9],[2,3,5],[2,8],[3,7],[4,6]] > > > > > ... > > > > Best > > Thorkil > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.dubuisson at gmail.com Sat May 18 15:34:26 2019 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat, 18 May 2019 08:34:26 -0700 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: Message-ID: On Sat, May 18, 2019 at 2:56 AM Magicloud Magiclouds wrote: > > Thanks. Just to make it clear, the code is for generating candidates, > not the answer, right? From first glance, the code shows a lot > solutions that do not sum to 10. Have not check if it contains all > answers. They were the right answers for each index. N.B. the comment -- A list of all sets of numbers, no duplicates and ignoring order, -- that sum to the value @index + 1 at . I'm glad to hear you only want the answer for 10 and the DP aspect isn't supposed to re-use sum sets for values 1..9 to construct sums for 10 (which is what I did, it was ugly and slow). In that case you can use Ariis's awesome solution with very minor modification: ``` import Data.List main = print answer type Solution = [Integer] answer = sums 10 sums :: Integer -> [Solution] sums n = do x <- [1..n] -- Pick a largest number in the same go x [x] (n - x) -- recursively pass the smallest value, the current solution, and remainder where go x xs r | r > 0 && x == 1 = fail "" -- If there is a remainder and we've already used 1 this isn't a soluton | r > 0 = do x <- [1..min (x-1) r] -- The next value must be between 1 and the min of remainder and one-less than the last pick go x (x:xs) (r - x) | otherwise = return xs ``` -Thomas > > On Sat, May 18, 2019 at 3:03 PM Thomas DuBuisson > wrote: > > > > As an aside: I feel certain I saw a beautiful solution presented as > > lecture notes and referencing a game show (around 2007). Maybe it was > > in Hudak's book? > > > > > > Perhaps I missed something, but the answer's I've seen posted thus far > > are not dynamic programming. Certainly in the powerset case you'll > > experience exponential costs. Benchmarks are good - try to solve with > > numbers [1..64] in low numbers of seconds. > > > > An explicit 98-ish solution is to have a generator that will refer to > > the prior indexes in the list when computing the current index. > > > > > > First the boiler plate: > > > > ``` > > {-# LANGUAGE OverloadedLists #-} > > module Main where > > > > import qualified Data.Set as Set > > import Control.Monad (guard) > > > > type Solution = Set.Set Int > > > > -- A list of all sets of numbers, no duplicates and ignoring order, > > -- that sum to the value @index + 1 at . > > answer :: [[Solution]] > > answer = fmap op [1..10] > > where > > ``` > > > > Now for the interesting part. The recursive definition of a solution > > for value `target` is `[target]` and the solutions for `x` added with > > the solution for `target - x` where `x <- [0..target/2]. Some care > > must be taken because solutions will overlap. > > > > With that in mind: > > > > ``` > > -- Generate the entry for value @target@ (list index @target - 1@) > > op :: Int -> [Solution] > > op target = > > ([target] :: Solution) -- The target itself is an answer > > : snub -- Ignore duplicate results > > -- Better idea: don't > > generate dups if you can... > > (do let half = target `div` 2 > > halfRDown = (target-1) `div` 2 > > (ls,hs) <- zip (slice 0 half answer) -- Pair 0 .. t/2 > > -- with t-1, t-2 .. t/2+1 > > (reverse $ slice half halfRDown answer) > > l <- ls -- For each solution to the lower number > > h <- hs -- and the matching solution to the larger number > > guard (Set.intersection l h == []) -- No repeat values! (?) > > pure (l <> h) -- target = l + h > > ) > > > > -- | List slice from a base and of given length > > slice :: Int -> Int -> [a] -> [a] > > slice base len = take len . drop base > > > > -- | Efficient combined sort and nub > > snub :: (Eq a, Ord a) => [a] -> [a] > > snub = Set.toList . Set.fromList > > > > main :: IO () > > main = print answers > > ``` > > > > -Thomas > > > > > > On Fri, May 17, 2019 at 9:35 PM Magicloud Magiclouds > > wrote: > > > > > > Hi, > > > > > > I solved the question. But I could not figure out a FP style solution. > > > > > > Question: > > > > > > 1 - 9, nine numbers. Show all the possible combinations that sum up to > > > 10. Different orders are counted as the same. > > > > > > For example, [1, 4, 5]. > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > To (un)subscribe, modify options or view archives go to: > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > Only members subscribed via the mailman list are allowed to post. From thomas.dubuisson at gmail.com Sat May 18 15:37:36 2019 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat, 18 May 2019 08:37:36 -0700 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: Message-ID: That prior mail built on code from Kraeutmann, sorry for the mis-attribution. On Sat, May 18, 2019 at 8:34 AM Thomas DuBuisson wrote: > > On Sat, May 18, 2019 at 2:56 AM Magicloud Magiclouds > wrote: > > > > Thanks. Just to make it clear, the code is for generating candidates, > > not the answer, right? From first glance, the code shows a lot > > solutions that do not sum to 10. Have not check if it contains all > > answers. > > They were the right answers for each index. N.B. the comment > -- A list of all sets of numbers, no duplicates and ignoring order, > -- that sum to the value @index + 1 at . > > I'm glad to hear you only want the answer for 10 and the DP aspect > isn't supposed to re-use sum sets for values 1..9 to construct sums > for 10 (which is what I did, it was ugly and slow). In that case you > can use Ariis's awesome solution with very minor modification: > > ``` > import Data.List > > main = print answer > > type Solution = [Integer] > > answer = sums 10 > > sums :: Integer -> [Solution] > sums n = do > x <- [1..n] -- Pick a largest number in the same > go x [x] (n - x) -- recursively pass the smallest value, the > current solution, and remainder > where > go x xs r > | r > 0 && x == 1 = fail "" -- If there is a > remainder and we've already used 1 this isn't a soluton > | r > 0 = do x <- [1..min (x-1) r] -- The next value must be > between 1 and the min of remainder and one-less than the last pick > go x (x:xs) (r - x) > | otherwise = return xs > ``` > > -Thomas > > > > > On Sat, May 18, 2019 at 3:03 PM Thomas DuBuisson > > wrote: > > > > > > As an aside: I feel certain I saw a beautiful solution presented as > > > lecture notes and referencing a game show (around 2007). Maybe it was > > > in Hudak's book? > > > > > > > > > Perhaps I missed something, but the answer's I've seen posted thus far > > > are not dynamic programming. Certainly in the powerset case you'll > > > experience exponential costs. Benchmarks are good - try to solve with > > > numbers [1..64] in low numbers of seconds. > > > > > > An explicit 98-ish solution is to have a generator that will refer to > > > the prior indexes in the list when computing the current index. > > > > > > > > > First the boiler plate: > > > > > > ``` > > > {-# LANGUAGE OverloadedLists #-} > > > module Main where > > > > > > import qualified Data.Set as Set > > > import Control.Monad (guard) > > > > > > type Solution = Set.Set Int > > > > > > -- A list of all sets of numbers, no duplicates and ignoring order, > > > -- that sum to the value @index + 1 at . > > > answer :: [[Solution]] > > > answer = fmap op [1..10] > > > where > > > ``` > > > > > > Now for the interesting part. The recursive definition of a solution > > > for value `target` is `[target]` and the solutions for `x` added with > > > the solution for `target - x` where `x <- [0..target/2]. Some care > > > must be taken because solutions will overlap. > > > > > > With that in mind: > > > > > > ``` > > > -- Generate the entry for value @target@ (list index @target - 1@) > > > op :: Int -> [Solution] > > > op target = > > > ([target] :: Solution) -- The target itself is an answer > > > : snub -- Ignore duplicate results > > > -- Better idea: don't > > > generate dups if you can... > > > (do let half = target `div` 2 > > > halfRDown = (target-1) `div` 2 > > > (ls,hs) <- zip (slice 0 half answer) -- Pair 0 .. t/2 > > > -- with t-1, t-2 .. t/2+1 > > > (reverse $ slice half halfRDown answer) > > > l <- ls -- For each solution to the lower number > > > h <- hs -- and the matching solution to the larger number > > > guard (Set.intersection l h == []) -- No repeat values! (?) > > > pure (l <> h) -- target = l + h > > > ) > > > > > > -- | List slice from a base and of given length > > > slice :: Int -> Int -> [a] -> [a] > > > slice base len = take len . drop base > > > > > > -- | Efficient combined sort and nub > > > snub :: (Eq a, Ord a) => [a] -> [a] > > > snub = Set.toList . Set.fromList > > > > > > main :: IO () > > > main = print answers > > > ``` > > > > > > -Thomas > > > > > > > > > On Fri, May 17, 2019 at 9:35 PM Magicloud Magiclouds > > > wrote: > > > > > > > > Hi, > > > > > > > > I solved the question. But I could not figure out a FP style solution. > > > > > > > > Question: > > > > > > > > 1 - 9, nine numbers. Show all the possible combinations that sum up to > > > > 10. Different orders are counted as the same. > > > > > > > > For example, [1, 4, 5]. > > > > _______________________________________________ > > > > Haskell-Cafe mailing list > > > > To (un)subscribe, modify options or view archives go to: > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > Only members subscribed via the mailman list are allowed to post. From magicloud.magiclouds at gmail.com Sat May 18 15:47:16 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sat, 18 May 2019 23:47:16 +0800 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: Message-ID: Ah, I see. Sorry did not make myself clear. On Sat, May 18, 2019 at 11:34 PM Thomas DuBuisson wrote: > > On Sat, May 18, 2019 at 2:56 AM Magicloud Magiclouds > wrote: > > > > Thanks. Just to make it clear, the code is for generating candidates, > > not the answer, right? From first glance, the code shows a lot > > solutions that do not sum to 10. Have not check if it contains all > > answers. > > They were the right answers for each index. N.B. the comment > -- A list of all sets of numbers, no duplicates and ignoring order, > -- that sum to the value @index + 1 at . > > I'm glad to hear you only want the answer for 10 and the DP aspect > isn't supposed to re-use sum sets for values 1..9 to construct sums > for 10 (which is what I did, it was ugly and slow). In that case you > can use Ariis's awesome solution with very minor modification: > > ``` > import Data.List > > main = print answer > > type Solution = [Integer] > > answer = sums 10 > > sums :: Integer -> [Solution] > sums n = do > x <- [1..n] -- Pick a largest number in the same > go x [x] (n - x) -- recursively pass the smallest value, the > current solution, and remainder > where > go x xs r > | r > 0 && x == 1 = fail "" -- If there is a > remainder and we've already used 1 this isn't a soluton > | r > 0 = do x <- [1..min (x-1) r] -- The next value must be > between 1 and the min of remainder and one-less than the last pick > go x (x:xs) (r - x) > | otherwise = return xs > ``` > > -Thomas > > > > > On Sat, May 18, 2019 at 3:03 PM Thomas DuBuisson > > wrote: > > > > > > As an aside: I feel certain I saw a beautiful solution presented as > > > lecture notes and referencing a game show (around 2007). Maybe it was > > > in Hudak's book? > > > > > > > > > Perhaps I missed something, but the answer's I've seen posted thus far > > > are not dynamic programming. Certainly in the powerset case you'll > > > experience exponential costs. Benchmarks are good - try to solve with > > > numbers [1..64] in low numbers of seconds. > > > > > > An explicit 98-ish solution is to have a generator that will refer to > > > the prior indexes in the list when computing the current index. > > > > > > > > > First the boiler plate: > > > > > > ``` > > > {-# LANGUAGE OverloadedLists #-} > > > module Main where > > > > > > import qualified Data.Set as Set > > > import Control.Monad (guard) > > > > > > type Solution = Set.Set Int > > > > > > -- A list of all sets of numbers, no duplicates and ignoring order, > > > -- that sum to the value @index + 1 at . > > > answer :: [[Solution]] > > > answer = fmap op [1..10] > > > where > > > ``` > > > > > > Now for the interesting part. The recursive definition of a solution > > > for value `target` is `[target]` and the solutions for `x` added with > > > the solution for `target - x` where `x <- [0..target/2]. Some care > > > must be taken because solutions will overlap. > > > > > > With that in mind: > > > > > > ``` > > > -- Generate the entry for value @target@ (list index @target - 1@) > > > op :: Int -> [Solution] > > > op target = > > > ([target] :: Solution) -- The target itself is an answer > > > : snub -- Ignore duplicate results > > > -- Better idea: don't > > > generate dups if you can... > > > (do let half = target `div` 2 > > > halfRDown = (target-1) `div` 2 > > > (ls,hs) <- zip (slice 0 half answer) -- Pair 0 .. t/2 > > > -- with t-1, t-2 .. t/2+1 > > > (reverse $ slice half halfRDown answer) > > > l <- ls -- For each solution to the lower number > > > h <- hs -- and the matching solution to the larger number > > > guard (Set.intersection l h == []) -- No repeat values! (?) > > > pure (l <> h) -- target = l + h > > > ) > > > > > > -- | List slice from a base and of given length > > > slice :: Int -> Int -> [a] -> [a] > > > slice base len = take len . drop base > > > > > > -- | Efficient combined sort and nub > > > snub :: (Eq a, Ord a) => [a] -> [a] > > > snub = Set.toList . Set.fromList > > > > > > main :: IO () > > > main = print answers > > > ``` > > > > > > -Thomas > > > > > > > > > On Fri, May 17, 2019 at 9:35 PM Magicloud Magiclouds > > > wrote: > > > > > > > > Hi, > > > > > > > > I solved the question. But I could not figure out a FP style solution. > > > > > > > > Question: > > > > > > > > 1 - 9, nine numbers. Show all the possible combinations that sum up to > > > > 10. Different orders are counted as the same. > > > > > > > > For example, [1, 4, 5]. > > > > _______________________________________________ > > > > Haskell-Cafe mailing list > > > > To (un)subscribe, modify options or view archives go to: > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > Only members subscribed via the mailman list are allowed to post. From magicloud.magiclouds at gmail.com Sat May 18 15:48:10 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sat, 18 May 2019 23:48:10 +0800 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: <20190518122515.GA590@Annette-Pc2> Message-ID: Cool. Thanks. On Sat, May 18, 2019 at 10:18 PM William Yager wrote: > > Here are two mechanical strategies for implementing DP in haskell: > > module Main where > import Data.Map.Strict as Map > import Data.Vector as Vec > > > -- The recursive step > > rec :: (Int -> [[Int]]) -> Int -> [[Int]] > rec rec n = do > this <- [1..n] > other <- rec (n - this) > return $ (this : other) > > -- Non-dynamic > > sumsTo1 :: Int -> [[Int]] > sumsTo1 0 = [[]] > sumsTo1 n = rec sumsTo1 n > > -- Dynamic (corecursive) > > sumsTo2 :: Int -> [[Int]] > sumsTo2 n = lookup Map.! n > where > lookup = go 1 (Map.singleton 0 [[]]) > go m acc | m > n = acc > | otherwise = go (m + 1) (Map.insert m (rec (acc Map.!) m) acc) > > -- Dynamic (lazy) > > sumsTo3 :: Int -> [[Int]] > sumsTo3 n = lookup Vec.! n > where > lookup = generate (n + 1) $ \m -> > if m == 0 > then [[]] > else rec (lookup Vec.!) m > > main = do > let a = sumsTo1 10 > b = sumsTo2 10 > c = sumsTo3 10 > print (a == b && b == c) > print a > > In case the formatting is messed up, see > https://gist.github.com/wyager/7daebb351d802bbb2a624b71c0f343d3 > > On Sat, May 18, 2019 at 10:15 PM Magicloud Magiclouds wrote: >> >> Thanks. This is kind like my original (did not get through) thought. >> >> On Sat, May 18, 2019 at 8:25 PM Thorkil Naur wrote: >> > >> > Hello, >> > >> > On Sat, May 18, 2019 at 12:33:00PM +0800, Magicloud Magiclouds wrote: >> > > ... >> > > 1 - 9, nine numbers. Show all the possible combinations that sum up to >> > > 10. Different orders are counted as the same. >> > > >> > > For example, [1, 4, 5]. >> > >> > With >> > >> > sumIs n [] = if n == 0 then [[]] else [] >> > sumIs n (x:xs) >> > = (if n < x then >> > [] >> > else >> > map (x:) $ sumIs (n-x) xs >> > ) >> > ++ sumIs n xs >> > >> > we can do: >> > >> > Prelude Main> sumIs 10 [1..9] >> > [[1,2,3,4],[1,2,7],[1,3,6],[1,4,5],[1,9],[2,3,5],[2,8],[3,7],[4,6]] >> > >> > > ... >> > >> > Best >> > Thorkil >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. From will.yager at gmail.com Sun May 19 06:31:57 2019 From: will.yager at gmail.com (William Yager) Date: Sun, 19 May 2019 14:31:57 +0800 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: <20190518122515.GA590@Annette-Pc2> Message-ID: I realized that there is a simplification which makes the transformation more obvious. I should have put the base case inside the recursive step, rather than special-casing it: module Main where import Data.Map.Strict as Map import Data.Vector as Vec -- The recursive step rec :: (Int -> [[Int]]) -> Int -> [[Int]] rec rec 0 = [[]] rec rec n = do this <- [1..n] other <- rec (n - this) return $ (this : other) -- Non-dynamic sumsTo1 :: Int -> [[Int]] sumsTo1 = rec sumsTo1 -- Dynamic (corecursive) sumsTo2 :: Int -> [[Int]] sumsTo2 n = lookup Map.! n where lookup = go 0 Map.empty go m acc | m > n = acc | otherwise = go (m + 1) (Map.insert m (rec (acc Map.!) m) acc) -- Dynamic (lazy) sumsTo3 :: Int -> [[Int]] sumsTo3 n = lookup Vec.! n where lookup = generate (n + 1) $ rec (lookup Vec.!) main = do let a = sumsTo1 10 b = sumsTo2 10 c = sumsTo3 10 print (a == b && b == c) print a Also, to expand on this: * Corecursive DP is good in cases where you can figure out which order to generate things in, especially if you can drop no-longer-relevant data as you go * Lazy DP (using Vector) is good and fast in the case where the data is dense in the (n-dimensional) integers. Also very elegant! * If your DP dependency graph doesn't have any nice properties (not trivially dense in the integers, not easily predictable dependencies), you can implement your algorithm using e.g. a State monad over a map of cached values. However, I think this requires the recursive step to be written in terms of a monad rather than a non-monadic function (so that you can interrupt the control flow of the recursive step). On Sat, May 18, 2019 at 11:49 PM Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Cool. Thanks. > > On Sat, May 18, 2019 at 10:18 PM William Yager > wrote: > > > > Here are two mechanical strategies for implementing DP in haskell: > > > > module Main where > > import Data.Map.Strict as Map > > import Data.Vector as Vec > > > > > > -- The recursive step > > > > rec :: (Int -> [[Int]]) -> Int -> [[Int]] > > rec rec n = do > > this <- [1..n] > > other <- rec (n - this) > > return $ (this : other) > > > > -- Non-dynamic > > > > sumsTo1 :: Int -> [[Int]] > > sumsTo1 0 = [[]] > > sumsTo1 n = rec sumsTo1 n > > > > -- Dynamic (corecursive) > > > > sumsTo2 :: Int -> [[Int]] > > sumsTo2 n = lookup Map.! n > > where > > lookup = go 1 (Map.singleton 0 [[]]) > > go m acc | m > n = acc > > | otherwise = go (m + 1) (Map.insert m (rec (acc Map.!) m) > acc) > > > > -- Dynamic (lazy) > > > > sumsTo3 :: Int -> [[Int]] > > sumsTo3 n = lookup Vec.! n > > where > > lookup = generate (n + 1) $ \m -> > > if m == 0 > > then [[]] > > else rec (lookup Vec.!) m > > > > main = do > > let a = sumsTo1 10 > > b = sumsTo2 10 > > c = sumsTo3 10 > > print (a == b && b == c) > > print a > > > > In case the formatting is messed up, see > > https://gist.github.com/wyager/7daebb351d802bbb2a624b71c0f343d3 > > > > On Sat, May 18, 2019 at 10:15 PM Magicloud Magiclouds < > magicloud.magiclouds at gmail.com> wrote: > >> > >> Thanks. This is kind like my original (did not get through) thought. > >> > >> On Sat, May 18, 2019 at 8:25 PM Thorkil Naur > wrote: > >> > > >> > Hello, > >> > > >> > On Sat, May 18, 2019 at 12:33:00PM +0800, Magicloud Magiclouds wrote: > >> > > ... > >> > > 1 - 9, nine numbers. Show all the possible combinations that sum up > to > >> > > 10. Different orders are counted as the same. > >> > > > >> > > For example, [1, 4, 5]. > >> > > >> > With > >> > > >> > sumIs n [] = if n == 0 then [[]] else [] > >> > sumIs n (x:xs) > >> > = (if n < x then > >> > [] > >> > else > >> > map (x:) $ sumIs (n-x) xs > >> > ) > >> > ++ sumIs n xs > >> > > >> > we can do: > >> > > >> > Prelude Main> sumIs 10 [1..9] > >> > [[1,2,3,4],[1,2,7],[1,3,6],[1,4,5],[1,9],[2,3,5],[2,8],[3,7],[4,6]] > >> > > >> > > ... > >> > > >> > Best > >> > Thorkil > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> To (un)subscribe, modify options or view archives go to: > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sun May 19 10:25:26 2019 From: fa-ml at ariis.it (Francesco Ariis) Date: Sun, 19 May 2019 12:25:26 +0200 Subject: [Haskell-cafe] Mocking out external services Message-ID: <20190519102526.wtme7bx4dsrl3kek@x60s.casa> (literate Haskell follows) Hello -cafe, I recently read "Three Layer Haskell Cake" [1] and decided to give it a go. I am stuck on a simple problem and feel like I am missing something easy. One of the first examples is a mocking of an `IO UTCTime` function. > > {-# Language FlexibleInstances #-} > > data UTCTime = UTCTime Int > > class MonadTime m where > getCurrentTime :: m UTCTime > > instance MonadTime ((->) UTCTime) where > getCurrentTime = id > > -- instance IO omitted > Everything is clear. I decided to write another function, mocking a stream-of-Char input. > > class MonadKeys m where > getKeys :: m [Char] > > instance MonadKeys ((->) [Char]) where > getKeys = id > > -- instance IO omitted > Again, fine. But now, if I want to write a function which combines the two external services, like: > > someFun :: (MonadTime m, MonadKeys m) => m () > someFun = undefined > there is no non-IO instance satisfying the two constraints. I could of course write a type > > data Env = Env UTCTime [Char] > and make it instance of MonadTime and MonadKeys, but then I am passing non-relevant arguments to a mocked function like getCurrentTime, which would only need UTCTime. What am I doing incorrectly? -F [1] https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html From magicloud.magiclouds at gmail.com Sun May 19 13:32:57 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sun, 19 May 2019 21:32:57 +0800 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: <20190518122515.GA590@Annette-Pc2> Message-ID: Awesome, thanks for the explanation. On Sun, May 19, 2019 at 2:32 PM William Yager wrote: > > I realized that there is a simplification which makes the transformation more obvious. I should have put the base case inside the recursive step, rather than special-casing it: > > module Main where > import Data.Map.Strict as Map > import Data.Vector as Vec > > > -- The recursive step > > rec :: (Int -> [[Int]]) -> Int -> [[Int]] > rec rec 0 = [[]] > rec rec n = do > this <- [1..n] > other <- rec (n - this) > return $ (this : other) > > -- Non-dynamic > > sumsTo1 :: Int -> [[Int]] > sumsTo1 = rec sumsTo1 > > -- Dynamic (corecursive) > > sumsTo2 :: Int -> [[Int]] > sumsTo2 n = lookup Map.! n > where > lookup = go 0 Map.empty > go m acc | m > n = acc > | otherwise = go (m + 1) (Map.insert m (rec (acc Map.!) m) acc) > > -- Dynamic (lazy) > > sumsTo3 :: Int -> [[Int]] > sumsTo3 n = lookup Vec.! n > where > lookup = generate (n + 1) $ rec (lookup Vec.!) > > main = do > let a = sumsTo1 10 > b = sumsTo2 10 > c = sumsTo3 10 > print (a == b && b == c) > print a > > Also, to expand on this: > > * Corecursive DP is good in cases where you can figure out which order to generate things in, especially if you can drop no-longer-relevant data as you go > * Lazy DP (using Vector) is good and fast in the case where the data is dense in the (n-dimensional) integers. Also very elegant! > * If your DP dependency graph doesn't have any nice properties (not trivially dense in the integers, not easily predictable dependencies), you can implement your algorithm using e.g. a State monad over a map of cached values. However, I think this requires the recursive step to be written in terms of a monad rather than a non-monadic function (so that you can interrupt the control flow of the recursive step). > > > On Sat, May 18, 2019 at 11:49 PM Magicloud Magiclouds wrote: >> >> Cool. Thanks. >> >> On Sat, May 18, 2019 at 10:18 PM William Yager wrote: >> > >> > Here are two mechanical strategies for implementing DP in haskell: >> > >> > module Main where >> > import Data.Map.Strict as Map >> > import Data.Vector as Vec >> > >> > >> > -- The recursive step >> > >> > rec :: (Int -> [[Int]]) -> Int -> [[Int]] >> > rec rec n = do >> > this <- [1..n] >> > other <- rec (n - this) >> > return $ (this : other) >> > >> > -- Non-dynamic >> > >> > sumsTo1 :: Int -> [[Int]] >> > sumsTo1 0 = [[]] >> > sumsTo1 n = rec sumsTo1 n >> > >> > -- Dynamic (corecursive) >> > >> > sumsTo2 :: Int -> [[Int]] >> > sumsTo2 n = lookup Map.! n >> > where >> > lookup = go 1 (Map.singleton 0 [[]]) >> > go m acc | m > n = acc >> > | otherwise = go (m + 1) (Map.insert m (rec (acc Map.!) m) acc) >> > >> > -- Dynamic (lazy) >> > >> > sumsTo3 :: Int -> [[Int]] >> > sumsTo3 n = lookup Vec.! n >> > where >> > lookup = generate (n + 1) $ \m -> >> > if m == 0 >> > then [[]] >> > else rec (lookup Vec.!) m >> > >> > main = do >> > let a = sumsTo1 10 >> > b = sumsTo2 10 >> > c = sumsTo3 10 >> > print (a == b && b == c) >> > print a >> > >> > In case the formatting is messed up, see >> > https://gist.github.com/wyager/7daebb351d802bbb2a624b71c0f343d3 >> > >> > On Sat, May 18, 2019 at 10:15 PM Magicloud Magiclouds wrote: >> >> >> >> Thanks. This is kind like my original (did not get through) thought. >> >> >> >> On Sat, May 18, 2019 at 8:25 PM Thorkil Naur wrote: >> >> > >> >> > Hello, >> >> > >> >> > On Sat, May 18, 2019 at 12:33:00PM +0800, Magicloud Magiclouds wrote: >> >> > > ... >> >> > > 1 - 9, nine numbers. Show all the possible combinations that sum up to >> >> > > 10. Different orders are counted as the same. >> >> > > >> >> > > For example, [1, 4, 5]. >> >> > >> >> > With >> >> > >> >> > sumIs n [] = if n == 0 then [[]] else [] >> >> > sumIs n (x:xs) >> >> > = (if n < x then >> >> > [] >> >> > else >> >> > map (x:) $ sumIs (n-x) xs >> >> > ) >> >> > ++ sumIs n xs >> >> > >> >> > we can do: >> >> > >> >> > Prelude Main> sumIs 10 [1..9] >> >> > [[1,2,3,4],[1,2,7],[1,3,6],[1,4,5],[1,9],[2,3,5],[2,8],[3,7],[4,6]] >> >> > >> >> > > ... >> >> > >> >> > Best >> >> > Thorkil >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> To (un)subscribe, modify options or view archives go to: >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> Only members subscribed via the mailman list are allowed to post. From parsonsmatt at gmail.com Sun May 19 15:17:50 2019 From: parsonsmatt at gmail.com (Matt) Date: Sun, 19 May 2019 09:17:50 -0600 Subject: [Haskell-cafe] Mocking out external services In-Reply-To: <20190519102526.wtme7bx4dsrl3kek@x60s.casa> References: <20190519102526.wtme7bx4dsrl3kek@x60s.casa> Message-ID: Hi Francesco, You won't have a concrete type for every combination of constraints. For the most part, your programs will all end up in IO (or some transformer over IO) anyway. I usually have a "test" transformer and a "production" transformer (both of which are usually ReaderT Env IO), and instances defined for each. It's OK to pass an overly large record to a function. A common style is to write a huge `data Env = Env { ... }` with dozens of fields, and use classes to only access the things you need. This allows you to pass smaller Envs in, but it doesn't require that you write dozens of types preemptively. I would suggest that `MonadTime` and `MonadKeys` are not great choice for a Layer 2 - it would be really difficult to write a mock for MonadKeys that was in any way meaningful. I'd suggest restricting these classes to be tightly coupled to your domain problem. Instead of getting random keys, try a sum-type with all the possible things you'd prompt the user for, and a type for possible user responses. This is much easier to mock meaningfully. Matt Parsons On Sun, May 19, 2019 at 4:25 AM Francesco Ariis wrote: > (literate Haskell follows) > > Hello -cafe, > I recently read "Three Layer Haskell Cake" [1] and decided to give > it a go. I am stuck on a simple problem and feel like I am missing > something easy. > One of the first examples is a mocking of an `IO UTCTime` function. > > > > > {-# Language FlexibleInstances #-} > > > > data UTCTime = UTCTime Int > > > > class MonadTime m where > > getCurrentTime :: m UTCTime > > > > instance MonadTime ((->) UTCTime) where > > getCurrentTime = id > > > > -- instance IO omitted > > > > Everything is clear. I decided to write another function, mocking > a stream-of-Char input. > > > > > class MonadKeys m where > > getKeys :: m [Char] > > > > instance MonadKeys ((->) [Char]) where > > getKeys = id > > > > -- instance IO omitted > > > > Again, fine. But now, if I want to write a function which combines the > two external services, like: > > > > > someFun :: (MonadTime m, MonadKeys m) => m () > > someFun = undefined > > > > there is no non-IO instance satisfying the two constraints. I could of > course write a type > > > > > data Env = Env UTCTime [Char] > > > > and make it instance of MonadTime and MonadKeys, but then I am passing > non-relevant arguments to a mocked function like getCurrentTime, which > would only need UTCTime. > > What am I doing incorrectly? > -F > > > [1] https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sun May 19 17:08:01 2019 From: fa-ml at ariis.it (Francesco Ariis) Date: Sun, 19 May 2019 19:08:01 +0200 Subject: [Haskell-cafe] Mocking out external services In-Reply-To: References: <20190519102526.wtme7bx4dsrl3kek@x60s.casa> Message-ID: <20190519170801.w2ytqk3a2k4ayx7m@x60s.casa> Hello Matt, On Sun, May 19, 2019 at 09:17:50AM -0600, Matt wrote: > I would suggest that `MonadTime` and `MonadKeys` are not great choice for a > Layer 2 - it would be really difficult to write a mock for MonadKeys that > was in any way meaningful. I'd suggest restricting these classes to be > tightly coupled to your domain problem. Instead of getting random keys, try > a sum-type with all the possible things you'd prompt the user for, and a > type for possible user responses. This is much easier to mock meaningfully. excellent explanation and excellent suggestions, many thanks -F From ichistmeinname at web.de Sun May 19 19:38:04 2019 From: ichistmeinname at web.de (Sandra Dylus) Date: Sun, 19 May 2019 21:38:04 +0200 Subject: [Haskell-cafe] First Call for Student Volunteers at ICFP'19 in Berlin, Germany In-Reply-To: <1AA93BC8-AA03-4539-8566-FC1CCE7FEA43@me.com> References: <1AA93BC8-AA03-4539-8566-FC1CCE7FEA43@me.com> Message-ID: <30F85490-2BFB-4C21-8DDF-BDBC1932BBDD@web.de> Hi, I’d appreciate it if you share this information with students or classmates: help us to make the experience great for everybody attending the conference, in exchange for access to all open sessions. Cheers Sandra ICFP'19 -- FIRST CALL FOR STUDENT VOLUNTEERS ============================================ ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. In order to smoothly run the conference, associated workshops, and tutorials, we need student volunteers to help out on the practical aspect of the organization. All the events associated with ICFP'19 will take place from Sun 18 - Fr 23 August 2019 in Berlin, Germany. The student volunteer program is a chance for students from around the world to participate in the conferences whilst assisting us in preparing and running the events. In return, volunteers are granted free registration to the conferences, tutorials, workshops, and panel, and a ticket for the banquet. As an ICFP 2019 Student Volunteer, you will interact closely with researchers, academics and practitioners from various disciplines and meet other students from around the world. Job assignments for student volunteers include but are not restricted to: assisting with technical sessions, workshops, tutorials and panels, checking badges at doors, operating the information desk, providing information about the conference to attendees, helping with traffic flow, assisting with accessibility accommodations, and general assistance to keep the conferences running smoothly. Please note that Student Volunteers are responsible for their own travel and accommodation arrangements. However, Student Volunteers are compensated for the following things. * A complimentary conference registration, offering access to all open sessions (i.e., parallel paper presentations, demonstrations, and workshops) and conference proceedings. * Free lunches and refreshments during breaks. * Student volunteer garments. * Free admission to all social events. Furthermore, Student Volunteers can apply for extra funding from SIGPLAN PAC funding when eligible. Important Links ============= To be considered as a Student Volunteer for ICFP, please fill in the following application form. https://docs.google.com/forms/d/e/1FAIpQLSe6oK0Jr8P-vSKwYBQU8OTGS593LC-atOCkK9Mc8qutiN1bjg/viewform The permanent link to this form can be found on the official conference website. https://icfp19.sigplan.org/track/icfp-2019-Student-Volunteering Important Dates ============= There are two rounds of calls with the following deadlines. * deadline for first round: June 2nd, 2019 AoE (notification: June 7th) * deadline for second round: July 7th, 2019 AoE (notification: July 14th) Positive notifications given in the first round are firm and the second round is only for spots not filled by the first round. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis at luispedro.org Mon May 20 02:49:53 2019 From: luis at luispedro.org (Luis Pedro Coelho) Date: Mon, 20 May 2019 10:49:53 +0800 Subject: [Haskell-cafe] zstd package. Proposal to take over maintenance Message-ID: <456d128e-8c36-4d92-993e-a5172ac15e2d@www.fastmail.com> Hi everyone, The zstd package contains important bugs (it produces malformed output in some cases) and seems unmaintained. I would like to take over maintenance of it. I have actually forked the package and fixed the bugs, releasing it as hs-zstd: https://github.com/luispedro/hs-zstd http://hackage.haskell.org/package/hs-zstd I was advised to consider taking over maintenance of zstd as an earlier attempt to contact the maintainers of zstd was not answered. I would still prefer not to have this responsibility, but I would also like to use zstd in my work. * The zstd issues are not obvious because 99% of the time it works well, so we actually used it in a release of ngless, but after 3 days in the wild, we had to release a "bugfix". This is because most code paths work well, but there is one which produces a broken file. http://ngless.embl.de/whatsnew.html#version-0-11 Thanks, Luis Luis Pedro Coelho | Fudan University | http://luispedro.org https://orcid.org/0000-0002-9280-7885 From trebla at vex.net Mon May 20 18:23:14 2019 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon, 20 May 2019 14:23:14 -0400 Subject: [Haskell-cafe] How to dynamic plan in Haskell? In-Reply-To: References: Message-ID: <66d6a33b-26fb-93fb-b551-7dd77c83ca05@vex.net> On 2019-05-18 3:03 a.m., Thomas DuBuisson wrote: > As an aside: I feel certain I saw a beautiful solution presented as > lecture notes and referencing a game show (around 2007). Maybe it was > in Hudak's book? Perhaps Hutton's book, chapter 9 "the countdown problem". (The game show is Countdown.) "Given a sequence of numbers and a target number, attempt to construct an expression whose value is the target, by combining one or more numbers from the sequence using addition, subtraction, multiplication, division and parentheses." From icfp.publicity at googlemail.com Mon May 20 21:25:15 2019 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Mon, 20 May 2019 17:25:15 -0400 Subject: [Haskell-cafe] Second Call for Tutorial Proposals: ICFP 2019 Message-ID: <5ce31b3bc5c0f_3be82b1fe4fb05d46362d@homer.mail> *EXTENDED DEADLINE* - CALL FOR TUTORIAL PROPOSALS ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming August 18 - 23, 2019 Berlin, Germany https://icfp19.sigplan.org/ The 24th ACM SIGPLAN International Conference on Functional Programming will be held in Berlin, Germany on August 18-23, 2019. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". Tutorials may occur after ICFP co-located with the associated workshops, from August 22 till August 23. ---------------------------------------------------------------------- Submission details Deadline for submission: June 3rd, 2019 Notification of acceptance: June 10th, 2019 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2018 workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019 at googlegroups.com by June 3rd, 2019. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by June 10th, 2019. The proposal form is available at: http://www.icfpconference.org/icfp2019-files/icfp19-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2019 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Christophe Scholliers (University of Ghent) General Chair: Derek Dreyer (MPI-SWS) Program Chair: François Pottier ( Inria, France) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019 at googlegroups.com From pierre.van.de.laar at philips.com Tue May 21 09:54:11 2019 From: pierre.van.de.laar at philips.com (Pierre_van_der_Laar (Functional Account)) Date: Tue, 21 May 2019 09:54:11 +0000 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) - clarification Message-ID: Dear All, The license issue can be summarized as follows: Whenever a program is compiled with GHC and is distributed on another platform than OS X, anybody can claim that the source code of that program must be provided due to the LGPL license, since integer-gmp, the ghc code, and that program's code are statically linked! Not convinced? Read e.g. https://gitlab.haskell.org/ghc/ghc/wikis/replacing-gmp-notes that discussed both the LGPL license and the usage of static libraries by GHC. For convenience, I have include the most relevant parts: ``` GMP is licensed under the GNU Lesser General Public License (LGPL), a kind of "copyleft" license. According to the terms of the LGPL, paragraph 5, you may distribute a program that is designed to be compiled and dynamically linked with the library under the terms of your choice (i.e., commercially) but if your program incorporates portions of the library, if it is linked statically, then your program is a "derivative"--a "work based on the library"--and according to paragraph 2, section c, you "must cause the whole of the work to be licensed" under the terms of the LGPL (including for free). The LGPL licensing for GMP is a problem for the overall licensing of binary programs compiled with GHC because most distributions (and builds) of GHC use static libraries. (Dynamic libraries are currently distributed only for OS X.) The LGPL licensing situation may be worse: even though The Glasgow Haskell Compiler License is essentially a "free software" license (BSD3), according to paragraph 2 of the LGPL, GHC must be distributed under the terms of the LGPL! ``` So the problem is real and seems to be underestimated by the Haskell user community based on the many (partly) incorrect responses on this mailing list. I still would like to know what GHC's strategy is to tackle this problem! Greetings, Pierre ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From fa-ml at ariis.it Tue May 21 10:32:05 2019 From: fa-ml at ariis.it (Francesco Ariis) Date: Tue, 21 May 2019 12:32:05 +0200 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) In-Reply-To: Message-ID: <20190521103205.l2stx54g6r4ogl4k@x60s.casa> Hello Pierre, On Tue, May 21, 2019 at 09:54:11AM +0000, Pierre_van_der_Laar (Functional Account) via Haskell-Cafe wrote: > So the problem is real and seems to be underestimated by the Haskell > user community based on the many (partly) incorrect responses on this > mailing list. > I still would like to know what GHC's strategy is to tackle this problem! Could you please answer Stefan Monnier's question? On Tue, May 14, 2019 at 11:23:30AM -0400, Stefan Monnier wrote: > I think you're confusing the GPL and the LGPL here. > Otherwise, please clarify what you mean by "enforces a LGPL license on > my code". The authentic interpretation [1] by the FSF itself seems pretty clear: "If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application." [1] http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic From mail at nh2.me Tue May 21 12:35:46 2019 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Tue, 21 May 2019 14:35:46 +0200 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) In-Reply-To: References: Message-ID: <1f40d7d8-9f84-0168-41db-e7827e7bd373@nh2.me> Hello Pierre, On 21/05/2019 11:54 AM, Pierre_van_der_Laar (Functional Account) via Haskell-Cafe wrote: > Whenever a program is compiled with GHC and is distributed on another platform than OS X, > anybody can claim that the source code of that program must be provided due to the LGPL license, > since integer-gmp, the ghc code, and that program's code are statically linked! Some facts on Linux: libgmp code is *not* typically statically linked into executables created with GHC. Consider this hello-world program built with `ghc --make`: % ldd Hello linux-vdso.so.1 => (0x00007ffe1d1ad000) ... libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f710fe3e000) As you can see, this program is dynamically linked against my system libgmp.so. As an end user of this program I can compile my own libgmp and make the program use that instead. Only if you pass flags to GHC to indicate that you want libgmp linked statically will it do so. In that static-linking case, you need to ensure that your program, when distributed, satisfies the requirements that gmp's LGPL has on being linked statically. For the cases where you do not want to use libgmp at all, you can use * integer-simple * integer-openssl (upcoming, see https://github.com/ch1bo/integer-openssl/issues/3) Hope this helps, Niklas From P.Achten at cs.ru.nl Tue May 21 15:14:52 2019 From: P.Achten at cs.ru.nl (Peter Achten) Date: Tue, 21 May 2019 17:14:52 +0200 Subject: [Haskell-cafe] [TFP'19 and TFPIE'19] call for participation Message-ID:                         ---------------------------------                     C A L L  F O R  P A R T I C I P A T I O N                         ---------------------------------                             ====== TFP 2019 ======                 20th Symposium on Trends in Functional Programming                                  12-14 June, 2019                                 Vancouver, BC, CA                         https://www.tfp2019.org/index.html                            ====== TFPIE 2019 ======    8th International Workshop on Trends in Functional Programming in Education                                  11 June, 2019                                Vancouver, BC, CA http://www.staff.science.uu.nl/~hage0101/tfpie2019/index.html The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below at scope). Please be aware that TFP uses two distinct rounds of submissions (see below at submission details). TFP 2019 will be the main event of a pair of functional programming events. TFP 2019 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 11. == Invited Speakers == TFP 2019 is pleased to announce keynote talks by the following two invited speakers: Nikhil Swamy, Microsoft Research: Structuring the Verification of Imperative Programs with                                   Functional Programming Frank Wood, University of British Columbia: Probabilistic Programming TFPIE 2019 is pleased to have the following invited speaker: Gregor Kiczales: Functional Programming at the Core of a High Throughput Software                  Engineering Curriculum == Scope == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories:     Research Articles:         Leading-edge, previously unpublished research work     Position Articles:         On what new trends should or should not be     Project Articles:         Descriptions of recently started new projects     Evaluation Articles:         What lessons can be drawn from a finished project     Overview Articles:         Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to:     Functional programming and multicore/manycore computing     Functional programming in the cloud     High performance functional computing     Extra-functional (behavioural) properties of functional programs     Dependently typed functional programming     Validation and verification of functional programs     Debugging and profiling for functional languages     Functional programming in different application areas:     security, mobility, telecommunications applications, embedded     systems, global computing, grids, etc.     Interoperability with imperative programming languages     Novel memory management techniques     Program analysis and transformation techniques     Empirical performance studies     Abstract/virtual machines and compilers for functional languages     (Embedded) domain specific languages     New implementation strategies     Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2019 program chairs, William J. Bowman and Ron Garcia. == Best Paper Awards == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == Instructions to Author == Papers must be submitted at:     https://easychair.org/conferences/?conf=tfp2019 Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. == Pre-symposium formal review == Papers to be formally reviewed before the symposium should be submitted before an early deadline and receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected in this process may still be accepted for presentation at the symposium, but will not be considered for the post-symposium formal review. == Post-symposium formal review == Papers submitted for post-symposium review (draft papers) will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback received at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. == Paper categories == There are two types of submission, each of which can be submitted either for pre-symposium or post-symposium review:     Extended abstracts. Extended abstracts are 4 to 10 pages in length.     Full papers.        Full papers are up to 20 pages in length. Each submission also belongs to a category:     research     position     project     evaluation     overview paper Each submission should clearly indicate to which category it belongs. Additionally, a draft paper submission—of either type (extended abstract or full paper) and any category—can be considered a student paper. A student paper is one for which primary authors are research students and the majority of the work described was carried out by the students. The submission should indicate that it is a student paper. Student papers will receive additional feedback from the PC shortly after the symposium has taken place and before the post-symposium submission deadline. Feedback is only provided for accepted student papers, i.e., papers submitted for presentation and post-symposium formal review that are accepted for presentation. If a student paper is rejected for presentation, then it receives no further feedback and cannot be submitted for post-symposium review. == Format == Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site (http://www.springer.com/lncs). == Program Committee == Program Co-chairs William J. Bowman          University of British Columbia Ronald Garcia              University of British Columbia Matteo Cimini              University of Massachusetts Lowell Ryan Culpepper             Czech Technical Institute Joshua Dunfield            Queen's University Sam Lindley                University of Edinburgh Assia Mahboubi             INRIA Nantes Christine Rizkallah        University of New South Wales Satnam Singh               Google AI Marco T. Morazán           Seton Hall University John Hughes                Chalmers University and Quviq Nicolas Wu                 University of Bristol Tom Schrijvers             KU Leuven Scott Smith                Johns Hopkins University Stephanie Balzer           Carnegie Mellon University Viktória Zsók              Eötvös Loránd University From aeroboy94 at gmail.com Tue May 21 16:53:59 2019 From: aeroboy94 at gmail.com (Arian van Putten) Date: Tue, 21 May 2019 18:53:59 +0200 Subject: [Haskell-cafe] Announce: Haskell Platform 8.6.5 (Gershom B) - clarification In-Reply-To: References: Message-ID: For some reason your mail seems to miss the rest of the thread so I have no idea what had been said before do maybe I am repeating something that was already said. GHC doesn't produce statically linked binaries by default. So they are dynamically linked against libgmp, libc and libz, not statically. The issue you linked is about the fact that it would be best to replace libgmp such that we can _allow_ static linking without licensing issues. It does not say we currently statically link. (You can reaffirm this by running ld on a GHC produced binary) On Tue, May 21, 2019, 11:54 Pierre_van_der_Laar (Functional Account) via Haskell-Cafe wrote: > Dear All, > > The license issue can be summarized as follows: > > Whenever a program is compiled with GHC and is distributed on another > platform than OS X, > anybody can claim that the source code of that program must be provided > due to the LGPL license, > since integer-gmp, the ghc code, and that program's code are statically > linked! > > Not convinced? Read e.g. > https://gitlab.haskell.org/ghc/ghc/wikis/replacing-gmp-notes that > discussed both the LGPL license and the usage of static libraries by GHC. > For convenience, I have include the most relevant parts: > > ``` > GMP is licensed under the GNU Lesser General Public License (LGPL), a kind > of "copyleft" license. According to the terms of the LGPL, paragraph 5, you > may distribute a program that is designed to be compiled and dynamically > linked with the library under the terms of your choice (i.e., commercially) > but if your program incorporates portions of the library, if it is linked > statically, then your program is a "derivative"--a "work based on the > library"--and according to paragraph 2, section c, you "must cause the > whole of the work to be licensed" under the terms of the LGPL (including > for free). > > The LGPL licensing for GMP is a problem for the overall licensing of > binary programs compiled with GHC because most distributions (and builds) > of GHC use static libraries. (Dynamic libraries are currently distributed > only for OS X.) The LGPL licensing situation may be worse: even though The > Glasgow Haskell Compiler License is essentially a "free software" license > (BSD3), according to paragraph 2 of the LGPL, GHC must be distributed under > the terms of the LGPL! > ``` > > So the problem is real and seems to be underestimated by the Haskell user > community based on the many (partly) incorrect responses on this mailing > list. > I still would like to know what GHC's strategy is to tackle this problem! > > Greetings, > Pierre > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby > notified that any use, forwarding, dissemination, or reproduction of this > message is strictly prohibited and may be unlawful. If you are not the > intended recipient, please contact the sender by return e-mail and destroy > all copies of the original message. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylwia.brodacka at luna-lang.org Thu May 23 11:40:45 2019 From: sylwia.brodacka at luna-lang.org (Sylwia Brodacka) Date: Thu, 23 May 2019 13:40:45 +0200 Subject: [Haskell-cafe] job opportunity at Luna Message-ID: Luna (http://luna-lang.org) is an award-winning data-science platform and a general-purpose functional programming language, selected by NASA and Singularity University as 1 of the 20 most impressive technologies worldwide. It spans the entire stack, from high-level visualisation and communication, to the nitty-gritty of running backend services in a single language. With inbuilt capabilities for visualisation and a dual-syntax architecture, the possibilities are limitless. We are looking for talented and extraordinary people with strong technical skills and a passion for functional programming. Since majority of Luna codebase is written in Haskell we have available positions for senior Haskell developers for a variety of roles, including Compiler Engineer, DevOps Engineer, GUI Architect, and Cloud Software Engineer. If you want to learn more about possibilities please check out detailed job description: https://stackoverflow.com/jobs/264670/senior-haskell-developer-luna Cheers, Sylwia -------------- next part -------------- An HTML attachment was scrubbed... URL: From leah at vuxu.org Fri May 24 14:01:42 2019 From: leah at vuxu.org (Leah Neukirchen) Date: Fri, 24 May 2019 16:01:42 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2019-05-27 @ 19:30 Message-ID: <87blzsrlx5.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 27 at Augustiner-Gaststätte Rumpler 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-may-2019/ Everybody is welcome! cu, -- Leah Neukirchen http://leahneukirchen.org/ From matthewtpickering at gmail.com Sat May 25 11:00:43 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 25 May 2019 12:00:43 +0100 Subject: [Haskell-cafe] haskell-src-exts - no more releases Message-ID: Hi all, I have decided that I am not going to do any more releases of `haskell-src-exts`. (https://github.com/haskell-suite/haskell-src-exts) If anyone wants to become the maintainer then I will gladly transfer rights to the repo. I advise anyone who wants to parse Haskell programs to use the GHC API, specifically you can use `ghc-lib-parser`. https://hackage.haskell.org/package/ghc-lib-parser Cheers, Matt From brucker at spamfence.net Sat May 25 22:57:31 2019 From: brucker at spamfence.net (Achim D. Brucker) Date: Sat, 25 May 2019 23:57:31 +0100 Subject: [Haskell-cafe] Call For Papers: Workshop in OCL and Textual Modeling (OCL 2019) Message-ID: <20190525225731.3ns2wiymrfg4koys@ananogawa.home.brucker.ch> CALL FOR PAPERS 19th International Workshop on OCL and Textual Modeling Co-located with MODELS 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and System, September 15-20, 2019, Munich, Germany http://oclworkshop.github.io The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages (e.g., OCL, textual MOF, Epsilon, or Alloy) can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. ## Topics of interest Topics of interest include (but are not limited to): - Mappings between textual modeling languages and other languages/formalisms - Mathematical models and/or formal semantics for textual modeling languages - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for: - validation, verification, and testing, - model transformation and code generation, - meta-modeling and DSLs, and - query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Model-driven security using textual modeling languages - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports: - usage of textual modeling languages and tools in complex domains, - usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks We particularly encourage submissions describing applications and case studies of textual modeling as well as test suites and benchmark collections for evaluating textual modeling tools. ## Submissions Four types of submissions will be considered: * Presentation only submission (not included in the workshop proceedings), e.g., for already published work. Authors should submit a short (1 page) abstract of their presentation. * Short papers (between 5 and 7 pages) describing new ideas or position papers. * Tool papers (between 5 and 7 pages) describing tools supporting textual modeling tools * Full papers (between 10 and 14 pages). All submissions should follow the LNCS format guidelines and should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2019). Accepted papers will be published online in [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: 14 Jul 2019 - Notification: 25 Aug 2019 - Pre-Workshop CRC: 9 Sep 2019 - Post-Workshop CRC: 5 Oct 2019 -- Dr. Achim D. Brucker | Chair of Cybersecurity | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking From manny at fpcomplete.com Sun May 26 01:32:13 2019 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Sat, 25 May 2019 18:32:13 -0700 Subject: [Haskell-cafe] ANN: stack-2.1 release candidate Message-ID: Announcing the first release candidate of Stack 2.1! You can download bindists for Linux, macOS, and Windows from https://github.com/commercialhaskell/stack/releases/tag/v2.1.0.1. ### Changes since v1.9.3 Major changes: * Switch over to pantry for managing packages. This is a major change to Stack's internals, and affects user-visible behavior in a few places. Some highlights: * Drop support for multiple package indices and legacy `00-index.tar` style indices. See [#4137](https://github.com/commercialhaskell/stack/issues/4137). * Support for archives and repos in the `packages` section has been removed. Instead, you must use `extra-deps` for such dependencies. `packages` now only supports local filepaths. * Add support for Git repositories containing (recursive) submodules. * Addition of new configuration options for specifying a "pantry tree" key, which provides more reproducibility around builds, and (in the future) will be used for more efficient package content downloads. You can also specify package name and version for more efficient config parsing. * __NOTE__ The new `stack freeze` command provides support for automatically generating this additional information. * Package contents and metadata are stored in an SQLite database in place of files on the filesystem. The `pantry` library can be used for interacting with these contents. * Internally, Stack has changed many datatypes, including moving to Cabal's definition of many data types. As a result of such changes, existing cache files will in general be invalidated, resulting in Stack needing to rebuild many previously cached builds in the new version. Sorry :(. * A new command, `stack freeze` has been added which outputs project and snapshot definitions with dependencies pinned to their exact versions. * The `ignore-revision-mismatch` setting is no longer needed, and has been removed. * Overriding GHC boot packages results in any other GHC boot packages depending on it being no longer available as a dependency, such packages need to be added explicitly when needed. See [#4510] (https://github.com/commercialhaskell/stack/issues/4510). * Cabal solver integration was not updated to support newer `cabal-install` versions so `stack solver` command was removed as well as a related option `--solver` from `stack new` and `stack init`. * Upgrade to Cabal 2.4 * Note that, in this process, the behavior of file globbing has been modified to match that of Cabal. In particular, this means that for Cabal spec versions less than 2.4, `*.txt` will match `foo.txt`, but not `foo.2.txt`. * Remove the `stack image` command. With the advent of Docker multistage builds, this functionality is no longer useful. For an example, please see [Building Haskell Apps with Docker]( https://www.fpcomplete.com/blog/2017/12/building-haskell-apps-with-docker). * Support building GHC from source (experimental) * Stack now supports building and installing GHC from source. The built GHC is uniquely identified by a commit id and an Hadrian "flavour" (Hadrian is the newer GHC build system), hence `compiler` can be set to use a GHC built from source with `ghc-git-COMMIT-FLAVOUR` * `stack.yaml` now supports a `configure-options`, which are passed directly to the `configure` step in the Cabal build process. See [#1438](https://github.com/commercialhaskell/stack/issues/1438) * Remove support for building GHCJS itself. Future releases of Stack may remove GHCJS support entirely. * Support for lock files for pinning exact project dependency versions Behavior changes: * `stack.yaml` now supports `snapshot`: a synonym for `resolver`. See [#4256](https://github.com/commercialhaskell/stack/issues/4256) * `stack script` now passes `-i -idir` in to the `ghc` invocation. This makes it so that the script can import local modules, and fixes an issue where `.hs` files in the current directory could affect interpretation of the script. See [#4538](https://github.com/commercialhaskell/stack/pull/4538) * When using `stack script`, custom snapshot files will be resolved relative to the directory containing the script. * Remove the deprecated `--upgrade-cabal` flag to `stack setup`. * Support the `drop-packages` field in `stack.yaml` * Remove the GPG signing code during uploads. The GPG signatures have never been used yet, and there are no plans to implement signature verification. * Remove the `--plain` option for the `exec` family of commands * Always use the `--exact-configuration` Cabal configuration option when building (should mostly be a non-user-visible enhancement). * No longer supports Cabal versions older than `1.19.2`. This means projects using snapshots earlier than `lts-3.0` or `nightly-2015-05-05` will no longer build. * Remove the `stack docker cleanup` command. Docker itself now has [`docker image prune`]( https://docs.docker.com/engine/reference/commandline/image_prune/) and [`docker container prune`]( https://docs.docker.com/engine/reference/commandline/container_prune/), which you can use instead. * Interleaved output is now turned on by default, see [#4702](https://github.com/commercialhaskell/stack/issues/4702). In addition, the `packagename> ` prefix is no longer included in interelaved mode when only building a single target. * The `-fhide-source-paths` GHC option is now enabled by default and can be disabled via the `hide-source-paths` configuration option in `stack.yaml`. See [#3784]( https://github.com/commercialhaskell/stack/issues/3784) * Stack will reconfigure a package if you modify your `PATH` environment variable. See [#3138](https://github.com/commercialhaskell/stack/issues/3138). * For GHC 8.4 and later, disable the "shadowed dependencies" workaround. This means that Stack will no longer have to force reconfigures as often. See [#3554](https://github.com/commercialhaskell/stack/issues/3554). * When building a package, Stack takes a lock on the dist directory in use to avoid multiple runs of Stack from trampling each others' files. See [#2730](https://github.com/commercialhaskell/stack/issues/2730). * Stack will check occassionally if there is a new version available and prompt the user to upgrade. This will not incur any additional network traffic, as it will piggy-back on the existing Hackage index updates. You can set `recommend-stack-upgrade: false` to bypass this. See [#1681](https://github.com/commercialhaskell/stack/issues/1681). * `stack list-dependencies` has been removed in favour of `stack ls dependencies`. * The new default for `--docker-auto-pull` is enabled. See [#3332](https://github.com/commercialhaskell/stack/issues/3332). Other enhancements: * Support MX Linux in get-stack.sh. Fixes [#4769](https://github.com/commercialhaskell/stack/issues/4769). * Defer loading up of files for local packages. This allows us to get plan construction errors much faster, and avoid some unnecessary work when only building a subset of packages. This is especially useful for the curator use case. * Existing global option `--color=WHEN` is now also available as a non-project-specific yaml configuration parameter `color:`. * Adopt the standard proposed at http://no-color.org/, that color should not be added by default if the `NO_COLOR` environment variable is present. * New command `stack ls stack-colors` lists the styles and the associated 'ANSI' control character sequences that stack uses to color some of its output. See `stack ls stack-colors --help` for more information. * New global option `--stack-colors=STYLES`, also available as a non-project-specific yaml configuration parameter, allows a stack user to redefine the default styles that stack uses to color some of its output. See `stack --help` for more information. * British English spelling of 'color' (colour) accepted as an alias for `--color`, `--stack-colors`, `stack ls stack-colors` at the command line and for `color:` and `stack-colors:` in yaml configuration files. * New build option `--ddump-dir`. (See [#4225]( https://github.com/commercialhaskell/stack/issues/4225)) * Stack parses and respects the `preferred-versions` information from Hackage for choosing latest version of a package in some cases, e.g. `stack unpack packagename`. * The components output in the `The main module to load is ambiguous` message now include package names so they can be more easily copy-pasted. * Git repos are shared across multiple projects. See [#3551](https://github.com/commercialhaskell/stack/issues/3551) * Use en_US.UTF-8 locale by default in pure Nix mode so programs won't crash because of Unicode in their output [#4095](https://github.com/commercialhaskell/stack/issues/4095) * Add `--tree` to `ls dependencies` to list dependencies as tree. [#4101](https://github.com/commercialhaskell/stack/issues/4101) * Add `--pedantic` to `ghci` to run with `-Wall` and `-Werror` [#4463](https://github.com/commercialhaskell/stack/issues/4463) * Add `--cabal-files` flag to `stack ide targets` command. * Add `--stdout` flag to all `stack ide` subcommands. * Use batches when unregistering packages with `ghc-pkg`. (See [#2662](https://github.com/commercialhaskell/stack/issues/2662)) * `get-stack` script now works on Windows CI machines of Appveyor, Travis and Azure Pipelines. See [#4535](https://github.com/commercialhaskell/stack/issues/4535)/ * Show snapshot being used when `stack ghci` is invoked outside of a project directory. See [#3651](https://github.com/commercialhaskell/stack/issues/3651) * The script interpreter now accepts a `--extra-dep` flag for adding packages not present in the snapshot. Currently, this only works with packages from Hackage, not Git repos or archives. * When using the script interpreter with `--optimize` or `--compile`, Stack will perform an optimization of checking whether a newer executable exists, making reruns significantly faster. There's a downside to this, however: if you have a multifile script, and change one of the dependency modules, Stack will not automatically detect and recompile. * `stack clean` will delete the entire `.stack-work/dist` directory, not just the relevant subdirectory for the current GHC version. See [#4480](https://github.com/commercialhaskell/stack/issues/4480). * Add `stack purge` as a shortcut for `stack clean --full`. See [#3863](https://github.com/commercialhaskell/stack/issues/3863). * Both `stack dot` and `stack ls dependencies` accept a `--global-hints` flag to bypass the need for an installed GHC. See [#4390](https://github.com/commercialhaskell/stack/issues/4390). * Add the `stack config env` command for getting shell script environment variables. See [#620]( https://github.com/commercialhaskell/stack/issues/620). * Less verbose output from `stack setup` on Windows. See [#1212](https://github.com/commercialhaskell/stack/issues/1212). * Add an optional `ignore-expiry` flag to the `hackage-security` section of the `~/.stack/config.yaml`. It allows to disable timestamp expiration verification just like `cabal --ignore-expiry` does. The flag is not enabled by default so that the default functionality is not changed. * Include default values for most command line flags in the `--help` output. See [#893](https://github.com/commercialhaskell/stack/issues/893). * Set the `GHC_ENVIRONMENT` environment variable to specify dependency packages explicitly when running test. This is done to prevent ambiguous module name errors in `doctest` tests. * Document the way stack interacts with the Cabal library. * `get-stack` script now works on Windows CI machines of Appveyor, Travis and Azure Pipelines. See [#4535](https://github.com/commercialhaskell/stack/issues/4535) * Warn when a Docker image does not include a `PATH` environment variable. See [#2472](https://github.com/commercialhaskell/stack/issues/2742) * When using `system-ghc: true`, Stack will now find the appropriate GHC installation based on the version suffix, allowing you to more easily switch between various system-installed GHCs. See [#2433](https://github.com/commercialhaskell/stack/issues/2433). * `stack init` will now support create a `stack.yaml` file without any local packages. See [#2465]( https://github.com/commercialhaskell/stack/issues/2465) * Store caches in SQLite database instead of files. * No longer use "global" Docker image database (`docker.db`). * User config files are respected for the script command. See [#3705](https://github.com/commercialhaskell/stack/issues/3705), [#3887](https://github.com/commercialhaskell/stack/issues/3887). * Set the `GHC_ENVIRONMENT` environment variable to `-` to tell GHC to ignore any such files when GHC is new enough (>= 8.4.4), otherwise simply unset the variable. This allows Stack to have control of package databases when running commands like `stack exec ghci`, even in the presence of implicit environment files created by `cabal new-build`. See [#4706](https://github.com/commercialhaskell/stack/issues/4706). * Use a database cache table to speed up discovery of installed GHCs * You can specify multiple `--test-arguments` options. See [#2226](https://github.com/commercialhaskell/stack/issues/2226) * Windows terminal width detection is now done. See [#3588](https://github.com/commercialhaskell/stack/issues/3588) * On Windows, informs users if the 'programs' path contains a space character and further warns users if that path does not have an alternative short ('8 dot 3') name, referencing the `local-programs-path` configuration option. See [#4726](https://github.com/commercialhaskell/stack/issues/4726) Bug fixes: * Ignore duplicate files for a single module when a Haskell module was generated from a preprocessor file. See [#4076](https://github.com/commercialhaskell/stack/issues/4076). * Only track down components in current directory if there are no hs-source-dirs found. This eliminates a number of false-positive warnings, similar to [#4076](https://github.com/commercialhaskell/stack/issues/4076). * Handle a change in GHC's hi-dump format around `addDependentFile`, which now includes a hash. See [yesodweb/yesod#1551](https://github.com/yesodweb/yesod/issues/1551) * Fix `subdirs` for git repos in `extra-deps` to match whole directory names. Also fixes for `subdirs: .`. See [#4292](https://github.com/commercialhaskell/stack/issues/4292) * Fix for git packages to update submodules to the correct state. See [#4314](https://github.com/commercialhaskell/stack/pull/4314) * Add `--cabal-files` flag to `stack ide targets` command. * Don't download ghc when using `stack clean`. * Support loading in GHCi definitions from symlinked C files. Without this patch, Stack will try to find object files in the directory pointed to by symlinks, while GCC will produce the object files in the original directory. See [#4402](https://github.com/commercialhaskell/stack/pull/4402) * Fix handling of GitHub and URL templates on Windows. See [commercialhaskell/stack#4394]( https://github.com/commercialhaskell/stack/issues/4394) * Fix `--file-watch` not responding to file modifications when running inside docker on Mac. See [#4506](https://github.com/commercialhaskell/stack/issues/4506) * Using `--ghc-options` with `stack script --compile` now works. * Ensure the detailed-0.9 type tests work. See [#4453](https://github.com/commercialhaskell/stack/issues/4453). * Extra include and lib dirs are now order-dependent. See [#4527](https://github.com/commercialhaskell/stack/issues/4527). * Apply GHC options when building a `Setup.hs` file. See [#4526](https://github.com/commercialhaskell/stack/issues/4526). * Stack handles ABI changes in FreeBSD 12 by differentiating that version from previous. * Help text for the `templates` subcommand now reflects behaviour in stack 1.9 — that it downloads and shows a help file, rather than listing available templates. * Fix detection of aarch64 platform (this broke when we upgraded to a newer Cabal version). * Docker: fix detecting and pulling missing images with `--docker-auto-pull`, see [#4598](https://github.com/commercialhaskell/stack/issues/4598) * Hackage credentials are not world-readable. See [#2159](https://github.com/commercialhaskell/stack/issues/2159). * Warnings are dumped from logs even when color is enabled. See [#2997](https://github.com/commercialhaskell/stack/issues/2997) * `stack init` will now work for cabal files with sublibraries. See [#4408](https://github.com/commercialhaskell/stack/issues/4408) * When the Cabal spec version is newer than the global Cabal version, build against the snapshot's Cabal library. See [#4488](https://github.com/commercialhaskell/stack/issues/4488) * Docker: fix detection of expected subprocess failures. This fixes downloading a compatible `stack` executable when the host `stack` is not compatible with the Docker image (on Linux), and doesn't show an unnecessary extra error when the in-container re-exec'ed `stack` exits with failure. * The `stack ghci` command's `--ghc-options` flag now parses multiple options. See [#3315](https://github.com/commercialhaskell/stack/issues/3315). -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Sun May 26 04:45:15 2019 From: danburton.email at gmail.com (Dan Burton) Date: Sun, 26 May 2019 00:45:15 -0400 Subject: [Haskell-cafe] haskell-src-exts - no more releases In-Reply-To: References: Message-ID: I would like to maintain haskell-src-exts. I took over maintenance of haskell-src-meta a few months ago, which is downstream of haskell-src-exts. I don't have any grand plans or intentions to keep either of these super up to date, but I am willing to at least try to keep them on life support: preserving current functionality on new versions of GHC, implementing simple feature requests, and accepting sensible PRs. -- Dan Burton On Sat, May 25, 2019 at 7:01 AM Matthew Pickering < matthewtpickering at gmail.com> wrote: > Hi all, > > I have decided that I am not going to do any more releases of > `haskell-src-exts`. > (https://github.com/haskell-suite/haskell-src-exts) > > If anyone wants to become the maintainer then I will gladly transfer > rights to the repo. > > I advise anyone who wants to parse Haskell programs to use the GHC > API, specifically you can use `ghc-lib-parser`. > https://hackage.haskell.org/package/ghc-lib-parser > > Cheers, > > Matt > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Sun May 26 06:58:15 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sun, 26 May 2019 14:58:15 +0800 Subject: [Haskell-cafe] Is there already a lib to work with filepath glob? Message-ID: Hi, Say for logic of Bash code `for f in /somePath/*/*; do ... done`, with filepath, directory packages, I have to do something like `listDirectoryContent "somePath" >>= mapM_ (\fp -> listDirectoryContent fp >>= action)`. It is not as expressive as the script. Especially when I'd like to use conduit to stream the folder. So is there already something I can use to make the logic expressive? PS: I know there are some libs to match a filepath against a glob string. But that is not what I want. From magicloud.magiclouds at gmail.com Sun May 26 07:08:11 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Sun, 26 May 2019 15:08:11 +0800 Subject: [Haskell-cafe] Is there already a lib to work with filepath glob? In-Reply-To: References: Message-ID: Ah, `conduit-find`. Seems appropriate. Thread terminated. On Sun, May 26, 2019 at 2:58 PM Magicloud Magiclouds wrote: > > Hi, > > Say for logic of Bash code `for f in /somePath/*/*; do ... done`, with > filepath, directory packages, I have to do something like > `listDirectoryContent "somePath" >>= mapM_ (\fp -> > listDirectoryContent fp >>= action)`. It is not as expressive as the > script. Especially when I'd like to use conduit to stream the folder. > > So is there already something I can use to make the logic expressive? > > PS: I know there are some libs to match a filepath against a glob > string. But that is not what I want. From michelhaber1994 at gmail.com Sun May 26 17:44:26 2019 From: michelhaber1994 at gmail.com (Michel Haber) Date: Sun, 26 May 2019 19:44:26 +0200 Subject: [Haskell-cafe] A "less" complex median Message-ID: Hello Cafe, I wanted to try and write a median filter with good complexity and performance. This is just an exercise, so there is no use looking for better performance algorithms (median of medians). Below is the code I came up with: import Control.Monad.State import System.Random type MyState s = State (Int, Int, [(Int, s)]) -- Inserts a value in its sorted place, -- Removes all expired values encountered, -- Returns the median value of the list. insertSorted :: (Ord a) => a -> MyState a a insertSorted v = do (size, index, list) <- get let flt = valid size index -- Filter: If too old remove value cmp (_,x) = v < x -- Compare: If v spot reached, add v ret = min index size `div` 2 -- The return value's index let (newList, med) = goThrough flt cmp ret (index, v) list put (size, index + 1, newList) return . snd $ med -- Internal implementation goThrough :: (a -> Bool) -> (a -> Bool) -> Int -> a -> [a] -> ([a], a) goThrough _ _ _ v [] = ([v], v) goThrough flt cmp idx v ls@(x:xs) | flt x && cmp x = if idx == 0 then (v:ls, v) else (v:ls, getTo idx (v:ls)) | flt x = let (ys, y) = goThrough flt cmp (max 0 (idx-1)) v xs in if idx == 0 then (x:ys, x) else (x:ys, y) | otherwise = goThrough flt cmp idx v xs -- Continues going through the list until we get to the element we want, or we -- run out of elements, in which case we take the last one getTo :: Int -> [a] -> a getTo _ [] = error "No value to return!" getTo _ [x] = x getTo 0 (x:_) = x getTo i (_:xs) = getTo (i-1) xs -- A value is valid if it still has a place in the list (hasn't expired) valid :: Int -> Int -> (Int, a) -> Bool valid size index (i,_) = index - i < size -- Clean up all the old values in the list. This is costly, and should be -- performed sparingly clean :: MyState Double () clean = do (size, index, list) <- get put (size, index, filter (valid size index) list) -- Insert n values with insertSorted insertList :: [Double] -> MyState Double [Double] insertList ls = sequence $ insertSorted <$> ls -- Example main :: IO () main = do values <- sequence $ replicate 10000 $ randomRIO (1,100::Double) print $ runState (insertList values <* clean) (10, 0, []) return () The code works, at least in the simple cases I've tried. It seems, however, way too complex and not very composable. So I was wondering if anyone could tell me where I went wrong, and how I can make the code simpler and smaller. Of course, it is completely possible to divide my insertion function, but the goal is to do all of the steps in one iteration over the list. This allows me to later compare what I have with divided functions to discover if the compiler would optimize them into one traversal. But even with its current logic, I believe the code can be better written. I just don't know how :p So I really appreciate any advice on how to make it better (or fix a bug I missed, or maybe even the logic of the whole algorithm). Cheers, Michel :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Mon May 27 05:07:37 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Mon, 27 May 2019 13:07:37 +0800 Subject: [Haskell-cafe] How to make boolean logic with IO Monad more expressive? Message-ID: Hi, I think `a || b && c` is more clear than ``` if a then True else if b then if c then True else False else False ``` And some languages, `pureComputing || (ioOperation && pure2)` involves IO only when pureComputing is False. So in Haskell, is it possible to get both benefits? ``` status <- ioOperation -- IO-ed anyway return $ pureComputing || (status && pure2) ``` ``` if pureComputing then return True else do status <- ioOperation if status then return pure2 else return False -- Looks ugly ``` From 78emil at gmail.com Mon May 27 07:35:04 2019 From: 78emil at gmail.com (Emil Axelsson) Date: Mon, 27 May 2019 09:35:04 +0200 Subject: [Haskell-cafe] How to make boolean logic with IO Monad more expressive? In-Reply-To: References: Message-ID: <4ae456d6-7cf2-5b41-714e-6bfa55461008@gmail.com> Not with the standard `||` and `&&` operations. You'd have to define new versions with a `Monad` constraint. The `monad-loops` package is pretty nice for short-circuiting stuff. See, for example, `andM` and `orM`. But it doesn't provide any binary operators. https://hackage.haskell.org/package/monad-loops / Emil Den 2019-05-27 kl. 07:07, skrev Magicloud Magiclouds: > Hi, > > I think `a || b && c` is more clear than > ``` > if a > then True > else if b > then if c > then True > else False > else False > ``` > > And some languages, `pureComputing || (ioOperation && pure2)` involves > IO only when pureComputing is False. > > So in Haskell, is it possible to get both benefits? > ``` > status <- ioOperation -- IO-ed anyway > return $ pureComputing || (status && pure2) > ``` > ``` > if pureComputing > then return True > else do > status <- ioOperation > if status > then return pure2 > else return False > -- Looks ugly > ``` > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From publicityifl at gmail.com Mon May 27 09:02:02 2019 From: publicityifl at gmail.com (Jurriaan Hage) Date: Mon, 27 May 2019 02:02:02 -0700 Subject: [Haskell-cafe] Call for papers for IFL 2019 (Implementation and Application of Functional Languages) Message-ID: Hello, Please, find below the call for papers for IFL 2019. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- ================================================================================ IFL 2019 31st Symposium on Implementation and Application of Functional Languages National University of Singapore September 25th-27th, 2019 http://2019.iflconference.org ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2019 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Keynote Speaker * Olivier Danvy, Yale-NUS College ### Submissions and peer-review Differently from previous editions of IFL, IFL 2019 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2019. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication ### Important dates Submission of regular papers: May 31, 2019 Submission of draft papers: July 15, 2019 Regular and draft papers notification: August 1, 2019 Deadline for early registration: August 15, 2019 Submission of pre-proceedings version: September 15, 2019 IFL Symposium: September 25-27, 2019 Submission of papers for post-proceedings: November 30, 2019 Notification of acceptance: January 31, 2020 Camera-ready version: February 29, 2020 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2019 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organization and Program committee Chairs: Jurrien Stutterheim (Standard Chartered Bank Singapore), Wei Ngan Chin (National University of Singapore) Program Committee: - Olaf Chitil, University of Kent - Clemens Grelck, University of Amsterdam - Daisuke Kimura, Toho University - Pieter Koopman, Radboud University - Tamas Kozsik, Eotvos Lorand University - Roman Leschinskiy, Facebook - Ben Lippmeier, The University of New South Wales - Marco T. Morazan, Seton Hall University - Sven-Bodo Scholz, Heriot-Watt University - Tom Schrijvers, Katholieke Universiteit Leuven - Alejandro Serrano, Utrecht University - Tony Sloane, Macquarie University - Simon Thompson, University of Kent - Marcos Viera, Universidad de la Republica - Wei Ngan Chin, NUS - Jurrien Stutterheim, Standard Chartered Bank ### Venue The 31st IFL is organized by the National University of Singapore. Singapore is located in the heart of South-East Asia, and the city itself is extremely well connected by trains and taxis. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2019 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Mon May 27 09:00:52 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Mon, 27 May 2019 17:00:52 +0800 Subject: [Haskell-cafe] How to make boolean logic with IO Monad more expressive? In-Reply-To: <4ae456d6-7cf2-5b41-714e-6bfa55461008@gmail.com> References: <4ae456d6-7cf2-5b41-714e-6bfa55461008@gmail.com> Message-ID: Good call. I see `orM` is actually a wrapper of the "ugly" nested-if. So operators can be another wrapper away. Thanks. On Mon, May 27, 2019 at 3:35 PM Emil Axelsson <78emil at gmail.com> wrote: > > Not with the standard `||` and `&&` operations. You'd have to define new > versions with a `Monad` constraint. > > The `monad-loops` package is pretty nice for short-circuiting stuff. > See, for example, `andM` and `orM`. But it doesn't provide any binary > operators. > > https://hackage.haskell.org/package/monad-loops > > / Emil > > Den 2019-05-27 kl. 07:07, skrev Magicloud Magiclouds: > > Hi, > > > > I think `a || b && c` is more clear than > > ``` > > if a > > then True > > else if b > > then if c > > then True > > else False > > else False > > ``` > > > > And some languages, `pureComputing || (ioOperation && pure2)` involves > > IO only when pureComputing is False. > > > > So in Haskell, is it possible to get both benefits? > > ``` > > status <- ioOperation -- IO-ed anyway > > return $ pureComputing || (status && pure2) > > ``` > > ``` > > if pureComputing > > then return True > > else do > > status <- ioOperation > > if status > > then return pure2 > > else return False > > -- Looks ugly > > ``` > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. From ietf-dane at dukhovni.org Mon May 27 09:10:12 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 27 May 2019 05:10:12 -0400 Subject: [Haskell-cafe] How to make boolean logic with IO Monad more expressive? In-Reply-To: References: Message-ID: > On May 27, 2019, at 1:07 AM, Magicloud Magiclouds wrote: > > ``` > status <- ioOperation -- IO-ed anyway > return $ pureComputing || (status && pure2) > ``` With two helpers: (<&&>) :: IO Bool -> IO Bool -> IO Bool (<&&>) ma mb = ma >>= (\a -> if not a then return False else mb) (<||>) :: IO Bool -> IO Bool -> IO Bool (<||>) ma mb = ma >>= (\a -> if a then return True else mb) you'd write: pure preComputing <||> (ioOperation <&&> pure pure2) You could even define suitable fixity to make <&&> have higher precedence than <||> and not need any parentheses. -- Viktor. From magicloud.magiclouds at gmail.com Mon May 27 09:14:05 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Mon, 27 May 2019 17:14:05 +0800 Subject: [Haskell-cafe] How to make boolean logic with IO Monad more expressive? In-Reply-To: References: Message-ID: Cool. Thanks. On Mon, May 27, 2019 at 5:10 PM Viktor Dukhovni wrote: > > > > > On May 27, 2019, at 1:07 AM, Magicloud Magiclouds wrote: > > > > ``` > > status <- ioOperation -- IO-ed anyway > > return $ pureComputing || (status && pure2) > > ``` > > With two helpers: > > (<&&>) :: IO Bool -> IO Bool -> IO Bool > (<&&>) ma mb = ma >>= (\a -> if not a then return False else mb) > > (<||>) :: IO Bool -> IO Bool -> IO Bool > (<||>) ma mb = ma >>= (\a -> if a then return True else mb) > > you'd write: > > pure preComputing <||> (ioOperation <&&> pure pure2) > > You could even define suitable fixity to make <&&> have higher > precedence than <||> and not need any parentheses. > > -- > Viktor. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jack at jackkelly.name Mon May 27 09:37:37 2019 From: jack at jackkelly.name (Jack Kelly) Date: Mon, 27 May 2019 19:37:37 +1000 Subject: [Haskell-cafe] How to make boolean logic with IO Monad more expressive? In-Reply-To: (Viktor Dukhovni's message of "Mon, 27 May 2019 05:10:12 -0400") References: Message-ID: <87o93ojl0e.fsf@jackkelly.name> Viktor Dukhovni writes: >> On May 27, 2019, at 1:07 AM, Magicloud Magiclouds wrote: >> >> ``` >> status <- ioOperation -- IO-ed anyway >> return $ pureComputing || (status && pure2) >> ``` > > With two helpers: > > (<&&>) :: IO Bool -> IO Bool -> IO Bool > (<&&>) ma mb = ma >>= (\a -> if not a then return False else mb) > > (<||>) :: IO Bool -> IO Bool -> IO Bool > (<||>) ma mb = ma >>= (\a -> if a then return True else mb) These generalise to any Applicative, I think: import Control.Applicative (liftA2) (<&&>) = liftA2 (&&) (<||>) = liftA2 (||) -- Jack From magicloud.magiclouds at gmail.com Mon May 27 09:41:05 2019 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Mon, 27 May 2019 17:41:05 +0800 Subject: [Haskell-cafe] How to make boolean logic with IO Monad more expressive? In-Reply-To: <87o93ojl0e.fsf@jackkelly.name> References: <87o93ojl0e.fsf@jackkelly.name> Message-ID: With side effect, they are not the same. Viktor's nested-if does not trigger unnecessary IO action, while liftA2 does. On Mon, May 27, 2019 at 5:38 PM Jack Kelly wrote: > > Viktor Dukhovni writes: > > >> On May 27, 2019, at 1:07 AM, Magicloud Magiclouds wrote: > >> > >> ``` > >> status <- ioOperation -- IO-ed anyway > >> return $ pureComputing || (status && pure2) > >> ``` > > > > With two helpers: > > > > (<&&>) :: IO Bool -> IO Bool -> IO Bool > > (<&&>) ma mb = ma >>= (\a -> if not a then return False else mb) > > > > (<||>) :: IO Bool -> IO Bool -> IO Bool > > (<||>) ma mb = ma >>= (\a -> if a then return True else mb) > > These generalise to any Applicative, I think: > > import Control.Applicative (liftA2) > > (<&&>) = liftA2 (&&) > (<||>) = liftA2 (||) > > -- Jack > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ietf-dane at dukhovni.org Mon May 27 09:46:11 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 27 May 2019 05:46:11 -0400 Subject: [Haskell-cafe] How to make boolean logic with IO Monad more expressive? In-Reply-To: <87o93ojl0e.fsf@jackkelly.name> References: <87o93ojl0e.fsf@jackkelly.name> Message-ID: <20190527094611.GL67454@straasha.imrryr.org> On Mon, May 27, 2019 at 07:37:37PM +1000, Jack Kelly wrote: > Viktor Dukhovni writes: > > >> On May 27, 2019, at 1:07 AM, Magicloud Magiclouds wrote: > >> > >> ``` > >> status <- ioOperation -- IO-ed anyway > >> return $ pureComputing || (status && pure2) > >> ``` > > > > With two helpers: > > > > (<&&>) :: IO Bool -> IO Bool -> IO Bool > > (<&&>) ma mb = ma >>= (\a -> if not a then return False else mb) > > > > (<||>) :: IO Bool -> IO Bool -> IO Bool > > (<||>) ma mb = ma >>= (\a -> if a then return True else mb) > > These generalise to any Applicative, I think: > > import Control.Applicative (liftA2) > > (<&&>) = liftA2 (&&) > (<||>) = liftA2 (||) As written, the above Applicative version won't short-circuit (is strict in both arguments) in the IO Monad. For example, the below will still read stdin: pure False <&&> (getLine >>= return . read) The generalized Monadic version will short-circuit. (<&&>) :: Monad m => m Bool -> m Bool -> m Bool (<&&>) ma mb = ma >>= (\a -> if not a then return False else mb) (<||>) :: Monad m => m Bool -> m Bool -> m Bool (<||>) ma mb = ma >>= (\a -> if a then return True else mb) -- Viktor. From jack at jackkelly.name Mon May 27 09:47:00 2019 From: jack at jackkelly.name (Jack Kelly) Date: Mon, 27 May 2019 19:47:00 +1000 Subject: [Haskell-cafe] How to make boolean logic with IO Monad more expressive? In-Reply-To: (Magicloud Magiclouds's message of "Mon, 27 May 2019 17:41:05 +0800") References: <87o93ojl0e.fsf@jackkelly.name> Message-ID: <87k1ecjkkr.fsf@jackkelly.name> Magicloud Magiclouds writes: > With side effect, they are not the same. > Viktor's nested-if does not trigger unnecessary IO action, while liftA2 does. Ah, of course. Still, there's no need to restrict their type to IO; any Monad should be fine. -- Jack > On Mon, May 27, 2019 at 5:38 PM Jack Kelly wrote: >> >> Viktor Dukhovni writes: >> >> >> On May 27, 2019, at 1:07 AM, Magicloud Magiclouds wrote: >> >> >> >> ``` >> >> status <- ioOperation -- IO-ed anyway >> >> return $ pureComputing || (status && pure2) >> >> ``` >> > >> > With two helpers: >> > >> > (<&&>) :: IO Bool -> IO Bool -> IO Bool >> > (<&&>) ma mb = ma >>= (\a -> if not a then return False else mb) >> > >> > (<||>) :: IO Bool -> IO Bool -> IO Bool >> > (<||>) ma mb = ma >>= (\a -> if a then return True else mb) >> >> These generalise to any Applicative, I think: >> >> import Control.Applicative (liftA2) >> >> (<&&>) = liftA2 (&&) >> (<||>) = liftA2 (||) From ietf-dane at dukhovni.org Mon May 27 17:29:50 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 27 May 2019 13:29:50 -0400 Subject: [Haskell-cafe] How to make boolean logic with IO Monad more expressive? In-Reply-To: <20190527094611.GL67454@straasha.imrryr.org> References: <87o93ojl0e.fsf@jackkelly.name> <20190527094611.GL67454@straasha.imrryr.org> Message-ID: <20190527172950.GM67454@straasha.imrryr.org> On Mon, May 27, 2019 at 05:46:11AM -0400, Viktor Dukhovni wrote: > The generalized Monadic version will short-circuit. > > (<&&>) :: Monad m => m Bool -> m Bool -> m Bool > (<&&>) ma mb = ma >>= (\a -> if not a then return False else mb) > > (<||>) :: Monad m => m Bool -> m Bool -> m Bool > (<||>) ma mb = ma >>= (\a -> if a then return True else mb) I should mention that a compatible even better generalized interface is available via Control.Selective: (<||>): http://hackage.haskell.org/package/selective-0.2/docs/Control-Selective.html#v:-60--124--124--62- (<&&>): http://hackage.haskell.org/package/selective-0.2/docs/Control-Selective.html#v:-60--38--38--62- -- Viktor. From borgauf at gmail.com Mon May 27 19:37:39 2019 From: borgauf at gmail.com (Lawrence Bottorff) Date: Mon, 27 May 2019 14:37:39 -0500 Subject: [Haskell-cafe] Emacs org-mode code block problems Message-ID: I've got this in an Emacs org-mode code block: #+begin_src haskell :results output doubleSmallNumber4 x = if x > 0 then x else x * 2 #+end_src but when I try to run it (with C-c C-c) I get ... Prelude> doubleSmallNumber4 x = if x > 0 then x else x * 2 "org-babel-haskell-eoe" :19:23: error: parse error (possibly incorrect indentation or mismatched brackets) Prelude> :20:11: error: parse error (possibly incorrect indentation or mismatched brackets) Prelude> :21:5-8: error: parse error on input ‘then’ Prelude> :22:5-8: error: parse error on input ‘else’ Prelude> "org-babel-haskell-eoe" ... I can run #+begin_src haskell tripleMe x = x + x + x #+end_src just fine though -- which means I've done something right with my Emacs init. The REPL started is 8.6.3 stack-ghci. I've formatted with the org-mode C-c ' -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandeep at sras.me Tue May 28 04:16:22 2019 From: sandeep at sras.me (sras) Date: Tue, 28 May 2019 09:46:22 +0530 Subject: [Haskell-cafe] ANN: Elminator (Haskell to Elm code generator for Elm 0.19/0.18) Message-ID: <939a1d97-f17f-edaf-90ea-740125627432@sras.me> Happy to announce 'Elminator', a package for generating Elm source for type definitions and Json encoders/decoders from Haskell data type definitions. https://hackage.haskell.org/package/elminator, This package tries to address some issues with popular/existing packages in the same space. Some distinguishing features are.. 1. Supports generation of polymorphic types (as well as concrete ones) in Elm from possibly polymorphic Haskell types, including types with phantom type variables. 2. Supports generation of code for recursive types (direct/indirect) as long as the type is not polymorphic. 3. Generates code that does not depend on external Elm libraries. 4. Does not have limits on the number of fields that the constructors of your types can have. 5. Supports JSON encoding options exported by the Aeson library comprehensively. 6. Supports generation of code that depend on user defined types and encoders/decoders in Elm. Right now this package is tested by using a Haskell/Elm test app that round trips a bunch of data structures between an Elm front end and a Haskell back end, so as of now, there there aren't any automated tests included with this repo. Any feedback is welcome! Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at gmail.com Tue May 28 14:54:26 2019 From: monkleyon at gmail.com (MarLinn) Date: Tue, 28 May 2019 16:54:26 +0200 Subject: [Haskell-cafe] A "less" complex median In-Reply-To: References: Message-ID: <4250801b-c690-11c5-f269-dd16fe8b650c@gmail.com> > The code works, at least in the simple cases I've tried. > It seems, however, way too complex and not very composable. > So I was wondering if anyone could tell me where I went wrong, and how > I can make the code simpler and smaller. > > Of course, it is completely possible to divide my insertion function, > but the goal is to do all of the steps in one iteration over the list. > This allows me to later compare what I have with divided functions to > discover if the compiler would optimize them into one traversal. > > But even with its current logic, I believe the code can be better > written. I just don't know how :p > > So I really appreciate any advice on how to make it better (or fix a > bug I missed, or maybe even the logic of the whole algorithm). > Hi Michael, first of all, let's see what makes your code look so complex. Part of that is not inherent complexity, it's a lack of documentation. And by that I don't mean a lack of comments, but rather that the code is not self-documenting. Names are too abstract and/or too short. For example the name "getTo" means almost nothing on its own. You could also use records and types for this kind of documentation. The function-arguments of "goThrough", "flt" and "cmp", may be extension points in the future (see below), but right now they make the code more complex than necessary as well. Then there's monadic syntax for what is essentially pure computation and a few other bits and bobs. All this is not bad for some quick and dirty experiment, but changing that is a great first step for a clean-up. So here's one proposal how you could clean up the core part of the code. Everything is (almost) just renamed and reordered parts of the original, with obvious environmental stuff left out as an exercise to the reader. I also use -XUnicodeSyntax, but that's just my personal preference.     data MedianFilter a = MF         { kernelSize    ∷ !KernelSize         , srcPosition   ∷ !Position         , currentKernel ∷ ![(Position, a)]         }       deriving ( Show )     stepMedianFilterS ∷ Ord a ⇒ a → State (MedianFilter a) a     stepMedianFilterS = state . stepMedianFilter     stepMedianFilter ∷ Ord v ⇒ v → MedianFilter v → (Median v,MedianFilter v)     stepMedianFilter _   MF{..} | kernelSize < 1 || srcPosition < 0                                 = error "stepMedianFilter: bad argument"     stepMedianFilter v s at MF{..} = (median , s{ srcPosition = srcPosition + 1, currentKernel = newKernel } )       where         (newKernel, median) = updateKernelAndGetMedian medianIdx currentKernel         -- medianIdx = kernelSize `div` 2, unless we're at the start of the stream         medianIdx           = min srcPosition kernelSize `div` 2         isTooOld x          = not $ validAt kernelSize srcPosition x         v'                  = (srcPosition, v)              -- kernel is empty: create new kernel         updateKernelAndGetMedian _                 []    = ([v'], v)              -- clean up old values         updateKernelAndGetMedian stepsToMedian   (x:xs)  | isTooOld x = updateKernelAndGetMedian stepsToMedian xs         updateKernelAndGetMedian stepsToMedian k@(x:xs)  = case (v < snd x, stepsToMedian) of              -- the new value is also the median             (True,0) → (v':k , v)              -- the value belongs here, but the median has not been found yet             (True,_) → (v':k , snd $ nthOrLast (stepsToMedian-1) k)              -- the median is here, but the value must still be inserted             (_   ,0) → (x :ys, snd x)              -- neither median nor position have been found yet             (_   ,_) → (x :ys, y)           where             (ys, y) = updateKernelAndGetMedian (stepsToMedian-1) xs Of course this does little in the way of making the code more composable or simpler from a purely logical perspective. Nesting the functions does help in reducing the number of arguments that have to be passed around though. And without getting here I would not have been able to think about the code in any meaningful way as well. Now let's look at a few other properties of the code: There are few avenues that lead to dead ends, I believe. * Can the core function "goThrough" (my "updateKernelAndGetMedian") be replaced by a primitive like a fold, a scan, or similar? I don't think so. * Can the kernel be represented with a set, a priority queue, or any other type of tree? Yes, but the cleanup of old values would be even harder. Not worth the effort, unless you plan on using huge kernels. Bugs: I think I found one. The "goThrough"/"updateKernelAndGetMedian"-function does three things at once: inserting the new value into the sorted list, cleaning up old values, and searching for the current median. But if the place to insert is found before the median is found, you drop the cleaning. Which means if there is an old, invalid value between the position of the new value and the true median, you should not be computing the right median. (Unless it's directly behind the position of the new value.) One example is the sequence [3,6,5,4,2,1]. With a kernel size of 5, your algorithm computes a median of 3 for the 6th position (the 1), where it seems you would want a 4. On to composability. I agree that there's tension between efficiency and extendability, mostly inside "goThrough"/"updateKernelAndGetMedian" In particular, I can think of three important ways you might want to reuse parts of this algorithm. 1. You might want to have a generic "iterate over a stream with a kernel-based function"-function. This way you could implement things like a Gaussian blur or edge detection. To get there you would have to replace your "cmp" and "idx==0" (my "v < snd x" and "stepsToMedian") with more complex functions and to replace "getTo" (my "nthOrLast") with another recursive call or similar. (This part is probably also the way to correct the bug mentioned above.) So your "flt" and "cmp" where not a bad idea, but not quite there either. 2. You might want to handle start and end of the stream in more different ways. You could "extend" the first/last value, mirror or extrapolate the bordering values, fill with a constant, append secondary streams, ignore border values, … Right now both ends are handled differently. Also, both parts are hard coded into "goThrough"/"updateKernelAndGetMedian" (and "ret"/"medianIdx"). Again, making it more complex. So pulling this handling out might also make the code simpler. The best way I can see to solve this is to detect start and end outside this function and direct all three to different, exchangeable functions – which, in turn, will probably interact with a simplified version of "goThrough"/"updateKernelAndGetMedian" again. You could also assume that some other function prepends/appends meaningful extensions to both ends and also cleans up the ends afterwards. The same way you cut the end right now, but expect some outside user to clean up the start. But then you should default to squashing the kernel at both ends. 3. You might want to create a pipeline of different filters for every point of the stream. This gets easier if you separate the state from its monad like I did, because now you can compose states before putting them inside that monad. It also helps write nicer-looking functions – at least in my opinion. Lastly, most of these extensibility problems should have been solved in OpenCV, so you could search for inspiration there. Just a few idea. Hope they help! Cheers, MarLinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelhaber1994 at gmail.com Tue May 28 16:54:17 2019 From: michelhaber1994 at gmail.com (Michel Haber) Date: Tue, 28 May 2019 18:54:17 +0200 Subject: [Haskell-cafe] A "less" complex median In-Reply-To: <4250801b-c690-11c5-f269-dd16fe8b650c@gmail.com> References: <4250801b-c690-11c5-f269-dd16fe8b650c@gmail.com> Message-ID: Hello MarLinn, Thanks for the thorough analysis! Indeed the code is more readable in your refactoring! And yes the bug you found needs addressing. I'll get on that :p I will look into your suggestions as well as the OpenCV solutions to my problem. Thanks again, this was very helpful :) Cheers, Michel On Tue, May 28, 2019 at 4:55 PM MarLinn wrote: > > The code works, at least in the simple cases I've tried. > It seems, however, way too complex and not very composable. > So I was wondering if anyone could tell me where I went wrong, and how I > can make the code simpler and smaller. > > Of course, it is completely possible to divide my insertion function, but > the goal is to do all of the steps in one iteration over the list. This > allows me to later compare what I have with divided functions to discover > if the compiler would optimize them into one traversal. > > But even with its current logic, I believe the code can be better written. > I just don't know how :p > > So I really appreciate any advice on how to make it better (or fix a bug I > missed, or maybe even the logic of the whole algorithm). > > Hi Michael, > > first of all, let's see what makes your code look so complex. Part of that > is not inherent complexity, it's a lack of documentation. And by that I > don't mean a lack of comments, but rather that the code is not > self-documenting. Names are too abstract and/or too short. For example the > name "getTo" means almost nothing on its own. You could also use records > and types for this kind of documentation. The function-arguments of " > goThrough", "flt" and "cmp", may be extension points in the future (see > below), but right now they make the code more complex than necessary as > well. Then there's monadic syntax for what is essentially pure computation > and a few other bits and bobs. > > All this is not bad for some quick and dirty experiment, but changing that > is a great first step for a clean-up. > > So here's one proposal how you could clean up the core part of the code. > Everything is (almost) just renamed and reordered parts of the original, > with obvious environmental stuff left out as an exercise to the reader. I > also use -XUnicodeSyntax, but that's just my personal preference. > data MedianFilter a = MF > { kernelSize ∷ !KernelSize > , srcPosition ∷ !Position > , currentKernel ∷ ![(Position, a)] > } > deriving ( Show ) > > stepMedianFilterS ∷ Ord a ⇒ a → State (MedianFilter a) a > stepMedianFilterS = state . stepMedianFilter > > stepMedianFilter ∷ Ord v ⇒ v → MedianFilter v → (Median v,MedianFilter > v) > stepMedianFilter _ MF{..} | kernelSize < 1 || srcPosition < 0 > = error "stepMedianFilter: bad argument" > stepMedianFilter v s at MF{..} = (median , s{ srcPosition = srcPosition > + 1, currentKernel = newKernel } ) > where > (newKernel, median) = updateKernelAndGetMedian medianIdx > currentKernel > > -- medianIdx = kernelSize `div` 2, unless we're at the start of > the stream > medianIdx = min srcPosition kernelSize `div` 2 > isTooOld x = not $ validAt kernelSize srcPosition x > v' = (srcPosition, v) > > -- kernel is empty: create new kernel > updateKernelAndGetMedian _ [] = ([v'], v) > -- clean up old values > updateKernelAndGetMedian stepsToMedian (x:xs) | isTooOld x = > updateKernelAndGetMedian stepsToMedian xs > updateKernelAndGetMedian stepsToMedian k@(x:xs) = case (v < snd > x, stepsToMedian) of > -- the new value is also the median > (True,0) → (v':k , v) > -- the value belongs here, but the median has not been found > yet > (True,_) → (v':k , snd $ nthOrLast (stepsToMedian-1) k) > -- the median is here, but the value must still be inserted > (_ ,0) → (x :ys, snd x) > -- neither median nor position have been found yet > (_ ,_) → (x :ys, y) > where > (ys, y) = updateKernelAndGetMedian (stepsToMedian-1) xs > > Of course this does little in the way of making the code more composable > or simpler from a purely logical perspective. Nesting the functions does > help in reducing the number of arguments that have to be passed around > though. And without getting here I would not have been able to think about > the code in any meaningful way as well. > > Now let's look at a few other properties of the code: > > There are few avenues that lead to dead ends, I believe. > > - Can the core function "goThrough" (my "updateKernelAndGetMedian") be > replaced by a primitive like a fold, a scan, or similar? I don't think so. > - Can the kernel be represented with a set, a priority queue, or any > other type of tree? Yes, but the cleanup of old values would be even > harder. Not worth the effort, unless you plan on using huge kernels. > > Bugs: I think I found one. The "goThrough"/"updateKernelAndGetMedian"-function > does three things at once: inserting the new value into the sorted list, > cleaning up old values, and searching for the current median. But if the > place to insert is found before the median is found, you drop the cleaning. > Which means if there is an old, invalid value between the position of the > new value and the true median, you should not be computing the right > median. (Unless it's directly behind the position of the new value.) One > example is the sequence [3,6,5,4,2,1]. With a kernel size of 5, your > algorithm computes a median of 3 for the 6th position (the 1), where it > seems you would want a 4. > > On to composability. I agree that there's tension between efficiency and > extendability, mostly inside "goThrough"/"updateKernelAndGetMedian" In > particular, I can think of three important ways you might want to reuse > parts of this algorithm. > > 1. > > You might want to have a generic "iterate over a stream with a > kernel-based function"-function. This way you could implement things like a > Gaussian blur or edge detection. To get there you would have to replace > your "cmp" and "idx==0" (my "v < snd x" and "stepsToMedian") with more > complex functions and to replace "getTo" (my "nthOrLast") with another > recursive call or similar. (This part is probably also the way to correct > the bug mentioned above.) So your "flt" and "cmp" where not a bad > idea, but not quite there either. > 2. > > You might want to handle start and end of the stream in more different > ways. You could "extend" the first/last value, mirror or extrapolate the > bordering values, fill with a constant, append secondary streams, ignore > border values, … Right now both ends are handled differently. Also, both > parts are hard coded into "goThrough"/"updateKernelAndGetMedian" (and " > ret"/"medianIdx"). Again, making it more complex. So pulling this > handling out might also make the code simpler. The best way I can see to > solve this is to detect start and end outside this function and direct all > three to different, exchangeable functions – which, in turn, will probably > interact with a simplified version of "goThrough"/" > updateKernelAndGetMedian" again. You could also assume that some other > function prepends/appends meaningful extensions to both ends and also > cleans up the ends afterwards. The same way you cut the end right now, but > expect some outside user to clean up the start. But then you should default > to squashing the kernel at both ends. > 3. > > You might want to create a pipeline of different filters for every > point of the stream. This gets easier if you separate the state from its > monad like I did, because now you can compose states before putting them > inside that monad. It also helps write nicer-looking functions – at least > in my opinion. > > Lastly, most of these extensibility problems should have been solved in > OpenCV, so you could search for inspiration there. > > Just a few idea. Hope they help! > > Cheers, > MarLinn > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed May 29 12:49:11 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 29 May 2019 14:49:11 +0200 Subject: [Haskell-cafe] Fwd: Two weeks left for Haskell Exchange talk proposals In-Reply-To: References: Message-ID: Dear all, Only two weeks remain before the end of the Haskell eXchange call-for-paper (11th of june). Send your proposals! This year's keynote speaker will be Elise Huard, Gabriele Keller, Simon Peyton Jones, and Philip Wadler. Find the full CFP and submit your proposal here: https://docs.google.com/forms/d/e/1FAIpQLSeJgeTqAdYLBlRcO9PDzI3yrR22CqzhInHpelnqWzOrs5Wg9A/viewform -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlatko.basic at gmail.com Wed May 29 12:49:56 2019 From: vlatko.basic at gmail.com (Vlatko Basic) Date: Wed, 29 May 2019 14:49:56 +0200 Subject: [Haskell-cafe] "-with-rtsopts=-T" solved the memory leak Message-ID: <6c2ce62b-6b25-93ad-0f8e-df4cae340f56@gmail.com> Hello, I accidentally solved a memory leak just by enabling "with-rtsopts=-T". I knew where the issues was, in one servant client web call. It was showing even when the call result (a Bool) wasn't used. While the leak was "active", I had: ghc-options:   -threaded   -rtsopts   -with-rtsopts=-N And now that it doesn't show anymore, I have: ghc-options:   -threaded   -rtsopts   -with-rtsopts=-N   -with-rtsopts=-T I can reproduce the leak just by commenting out "-with-rtsopts=-T" and force rebuilding. Can anyone explain what is happening? Best regards, vlatkoB -------------- next part -------------- An HTML attachment was scrubbed... URL: