Re: Including remote-iserv upstream?

[Shea Levy]

No, as it currently exists it has to create a ProcessHandle, and I have
to layer some stuff on top of the iserv protocol anyway, so it wouldn't
really help much. I just use -pgmi to point to the client executable.

~Shea

Alan & Kim Zimmerman  writes:

> As a matter of interest, are you making use of `createIservProcessHook`
> which allows you to set the FDs to be used when communicating with the
> iserve process?
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Including remote-iserv upstream?

[Alan & Kim Zimmerman]

As a matter of interest, are you making use of `createIservProcessHook`
which allows you to set the FDs to be used when communicating with the
iserve process?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Including remote-iserv upstream?

[Shea Levy]

Hi Simon, devs,

As part of my work to get TH working when cross-compiling to iOS, I've
developed remote-iserv [1] (not yet on hackage), a set of libraries for
letting GHC communicate with an external interpreter that may be on
another machine. So far, there are only three additions of note on top
of what the ghci library offers:

1. The remote-iserv protocol has facilities for the host sending
   archives and object files the target doesn't have (dynlibs not yet
   implemented but there's no reason they can't be). This works by
   having the server send back a Bool after a loadObj or loadArchive
   indicating whether it needs the object sent, and then just reading it
   off the Pipe.
2. The remote-iserv lib abstracts over how the Pipe it communicates over
   is obtained. One could imagine e.g. an ssh-based implementation that
   just uses stdin and stdout* for the communication, the implementation
   I've actually tested on is a TCP server advertised over bonjour.
3. There is a protocol version included to address forwards
   compatibility concerns.

As the library currently stands, it works for my use case. However,
there would be a number of benefits if it were included with ghc (and
used for local iserv as well):

1. Reduced code duplication (the server side copies iserv/src/Main.hs
   pretty heavily)
2. Reduced overhead keeping up to date with iserv protocol changes
3. No need for an extra client-side process, GHC can just open the Pipe
   itself
4. Proper library distribution in the cross-compiling case. The client
   needs to be linked with the ghci lib built by the stage0 compiler, as
   it runs on the build machine, while the server needs to be linked
   with the ghci lib built by the stage1 compiler. With a distribution
   created by 'make install', we only get the ghci lib for the
   target. Currently, I'm working around this by just using the ghci lib
   of the bootstrap compiler, which in my case is built from the same
   source checkout, but of course this isn't correct. If these libs were
   upstream, we'd only need one version of the client lib exposed and
   one version of the server lib exposed and could have them be for the
   build machine and the target, respectively
5. Better haskell hackers than I invested in the code ;)

Thoughts on this? Would this be welcome upstream in some form?

Thanks,
Shea

* Note that, in the general case, having the server process's stdio be
  the same as the compiler's (as we have in the local-iserv case) is not
  possible. Future work includes adding something to the protocol to
  allow forwarding stdio over the protocol pipe, to make GHCi usable
  without watching the *server*'s console.

[1]: https://github.com/obsidiansystems/remote-iserv


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Exhaustiveness checking for pattern synonyms

[Benno Fünfstück]

An idea: could we perhaps use the same syntax as for MINIMAL pragmas also
for COMPLETE pragmas, since those two feel very similar to me? So instead
of multiple pragmas, let's have {-# COMPLETE (Pat1, Pat2) | (Pat3, Pat4)
#}, just like with {-# MINIMAL #-} ?

Regards,
Benno

Simon Peyton Jones via ghc-devs  schrieb am Fr., 13.
Jan. 2017 um 16:50 Uhr:

> Thanks.
>
> |  > * What if there are multiple COMPLETE pragmas e.g.
> |  >   {-# COMPLETE A, B, C #-}
> |  >   {-# COMPLETE A, X, Y, Z #-}
> |  >   Is that ok?  I guess it should be!
> |  >
> |  >   Will the pattern-match exhaustiveness check then succeed
> |  >   if a function uses either set?
> |  >
> |  >   What happens if you use a mixture of constructors in a match
> |  >   (e.g. A, X, C, Z)?  Presumably all bets are off?
> |
> |  Yes this is fine. In the case you ask about then as neither COMPLETE
> pragma
> |  will match then the "best" one as described in the error messages
> section
> |  will be chosen.
>
> The wiki spec doesn't say this (presumably under "semantics").  Could it?
>
> |  > * Note that COMPLETE pragmas could be a new source of orphan modules
> |  >  module M where
> |  >import N( pattern P, pattern Q )
> |  >{-# COMPLETE P, Q #-}
> |  >   where neither P nor Q is defined in M.  Then every module that is
> |  >   transitively "above" M would need to read M.hi just in case its
> |  >   COMPLETE pragmas was relevant.
>
> Can you say this in the spec?
>
> |  >
> |  > * Point out in the spec that COMPLETE pragmas are entirely unchecked.
> |  >   It's up to the programmer to get it right.
>
> Can you say this in the spec?  Ah -- it's in "Discussion"... put it under
> "Semantics".
>
> |  >
> |  > * Typing.  What does it mean for the types to "agree" with each other.
> |  >   E.g  A :: a -> [(a, Int)]
> |  >B :: b -> [(Int, b)]
> |  >   Is this ok?  Please say explicitly with examples.
> |
> |  This would be ok as the type constructor of both result types is [].
>
> Can you say this in the spec?
>
> |
> |  > * I didn't really didn't understand the "Error messages" section.
> |  >
> |  >
> |
> |  I can't really help unless I know what you don't understand.
>
> "The pattern match checker checks each set of patterns individually"
>
> Given a program, what are the "sets of patterns", precisely?
>
> |  The idea is simply that all the different sets of patterns are tried and
> |  that the results are prioritised by
> |
> |  1. Fewest uncovered clauses
> |  2. Fewest redundant clauses
> |  3. Fewest inaccessible clauses
> |  4. Whether the match comes from a COMPLETE pragma or the build in set of
> |  data constructors for a type constructor.
>
> Some examples would be a big help.
>
> Simon
>
> |
> |
> |
> |  > Simon
> |  >
> |  > |  -Original Message-
> |  > |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  > | Matthew  Pickering
> |  > |  Sent: 22 November 2016 10:43
> |  > |  To: GHC developers 
> |  > |  Subject: Exhaustiveness checking for pattern synonyms
> |  > |
> |  > |  Hello devs,
> |  > |
> |  > |  I have implemented exhaustiveness checking for pattern synonyms.
> |  > | The idea is  very simple, you specify a set of pattern synonyms (or
> |  > | data
> |  > |  constructors) which are regarded as a complete match.
> |  > |  The pattern match checker then uses this information in order to
> |  > | check  whether a function covers all possibilities.
> |  > |
> |  > |  Specification:
> |  > |
> |  > |  https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs
> |  > |
> |  > |  https://phabricator.haskell.org/D2669
> |  > |  https://phabricator.haskell.org/D2725
> |  > |
> |  > |  https://ghc.haskell.org/trac/ghc/ticket/8779
> |  > |
> |  > |  Matt
> |  > |  ___
> |  > |  ghc-devs mailing list
> |  > |  ghc-devs@haskell.org
> |  > |
> |  > |
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail
> |  > | .haskell
> |  > |  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  > |
> |  > | devs=02%7C01%7Csimonpj%40microsoft.com
> %7C155eb2786cb040d8052908
> |  > | d412c453
> |  > | b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154081815249356
> |  > | data=MkQ
> |  > |  FpwJWaTU%2BdEQSYEBjXLt80BrXLkBp9V8twdKB6BI%3D=0
> |
> |  I updated the wiki page quite a bit. Thanks Simon for the comments.
> |
> |  Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs