Steps to propose a new primop in GHC

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Steps to propose a new primop in GHC

Mitsutoshi Aoe
Hi devs,

I'm thinking to add a primop in GHC but not sure how I should proceed. The primop I have in mind is something like:

  traceEventBinary# :: Addr# -> Int# -> State# s -> State# s

This function is similar to the existing traceEvent# but it takes a chunk of bytes rather than a null-terminated string. It is useful to trace custom user events (e.g. network packet arrival timestamps in an network application) in eventlogs. At library level, it is supposed to be used like the tracing functions in Debug.Trace but with ByteString argument:

  traceEventBinary :: ByteString -> a -> a
  traceEventBinaryIO :: ByteString -> IO ()

Note that this can't live in base because of the dependency on bytestring.

So how should I proceed from here? Am I supposed to submit a GHC proposal or should I ask on the libraries list? This is not a prominently visible change in GHC. It rather affects only ghc-prim and no effects in base.

Thanks,
Mitsutoshi



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Steps to propose a new primop in GHC

Mitsutoshi Aoe
I forgot to mention that I have prototype implementation:


Some details still need to be sorted out though.

Regards,
Mitsutoshi

2018年5月28日(月) 16:23 Mitsutoshi Aoe <[hidden email]>:
Hi devs,

I'm thinking to add a primop in GHC but not sure how I should proceed. The primop I have in mind is something like:

  traceEventBinary# :: Addr# -> Int# -> State# s -> State# s

This function is similar to the existing traceEvent# but it takes a chunk of bytes rather than a null-terminated string. It is useful to trace custom user events (e.g. network packet arrival timestamps in an network application) in eventlogs. At library level, it is supposed to be used like the tracing functions in Debug.Trace but with ByteString argument:

  traceEventBinary :: ByteString -> a -> a
  traceEventBinaryIO :: ByteString -> IO ()

Note that this can't live in base because of the dependency on bytestring.

So how should I proceed from here? Am I supposed to submit a GHC proposal or should I ask on the libraries list? This is not a prominently visible change in GHC. It rather affects only ghc-prim and no effects in base.

Thanks,
Mitsutoshi



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Steps to propose a new primop in GHC

Ben Gamari-2
In reply to this post by Mitsutoshi Aoe
Mitsutoshi Aoe <[hidden email]> writes:

> Hi devs,
>
> I'm thinking to add a primop in GHC but not sure how I should proceed. The
> primop I have in mind is something like:
>
>   traceEventBinary# :: Addr# -> Int# -> State# s -> State# s
>
> This function is similar to the existing traceEvent# but it takes a chunk
> of bytes rather than a null-terminated string. It is useful to trace custom
> user events (e.g. network packet arrival timestamps in an network
> application) in eventlogs. At library level, it is supposed to be used like
> the tracing functions in Debug.Trace but with ByteString argument:
>
>   traceEventBinary :: ByteString -> a -> a
>   traceEventBinaryIO :: ByteString -> IO ()
>
> Note that this can't live in base because of the dependency on bytestring.
>
> So how should I proceed from here? Am I supposed to submit a GHC proposal
> or should I ask on the libraries list? This is not a prominently visible
> change in GHC. It rather affects only ghc-prim and no effects in base.
>
Hmm, that is a good question. I have also needed something like your
traceEventBinary# in the past and I think adding the primop is rather
non-controversial.

As far as adding a wrapper in `base`, I think we can just go ahead and
do it. `Debug.Trace` module isn't defined by the Haskell Report so I
don't think there's a need to involve the CLC here.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Steps to propose a new primop in GHC

Mitsutoshi Aoe
Hi Ben,

Thanks for your reply. I take that at least for the GHC part I can submit the diff to phab and ask for review. I’ll do it.

> As far as adding a wrapper in `base`, I think we can just go ahead and
do it.

Note that the wrapper cannot live in base doe to the dependency on bytestring. I’m thinking to put it in my ghc-trace-events for now.

Regards,
Mitsutoshi

2018年5月30日 5:33 +0900、Ben Gamari <[hidden email]>のメール:
Mitsutoshi Aoe <[hidden email]> writes:

Hi devs,

I'm thinking to add a primop in GHC but not sure how I should proceed. The
primop I have in mind is something like:

traceEventBinary# :: Addr# -> Int# -> State# s -> State# s

This function is similar to the existing traceEvent# but it takes a chunk
of bytes rather than a null-terminated string. It is useful to trace custom
user events (e.g. network packet arrival timestamps in an network
application) in eventlogs. At library level, it is supposed to be used like
the tracing functions in Debug.Trace but with ByteString argument:

traceEventBinary :: ByteString -> a -> a
traceEventBinaryIO :: ByteString -> IO ()

Note that this can't live in base because of the dependency on bytestring.

So how should I proceed from here? Am I supposed to submit a GHC proposal
or should I ask on the libraries list? This is not a prominently visible
change in GHC. It rather affects only ghc-prim and no effects in base.

Hmm, that is a good question. I have also needed something like your
traceEventBinary# in the past and I think adding the primop is rather
non-controversial.

As far as adding a wrapper in `base`, I think we can just go ahead and
do it. `Debug.Trace` module isn't defined by the Haskell Report so I
don't think there's a need to involve the CLC here.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Steps to propose a new primop in GHC

Ben Gamari-2
Mitsutoshi Aoe <[hidden email]> writes:

> Hi Ben,
>
> Thanks for your reply. I take that at least for the GHC part I can
> submit the diff to phab and ask for review. I’ll do it.
>
Absolutely. I'm looking forward to seeing it.

>> As far as adding a wrapper in `base`, I think we can just go ahead and
> do it.
>
> Note that the wrapper cannot live in base doe to the dependency on
> bytestring. I’m thinking to put it in my ghc-trace-events for now.
>
Yes, of course. Silly me.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (493 bytes) Download Attachment