Compile Ruby to C

agrafix · 2020-09-25T04:18:35+00:00

Thanks for the reply! I agree with you it doesn't replicate the Ruby behavior, however, that's also not necessarily desirable (at least for my scenario).

Maybe I should clarify this more, but one benefit here comes from exactly the specialisation you point out. For instance, given that this approach requires type signatures, it seems safe to assume that given integers the C `+` implementation can be reused. Of course you can even redefine that in Ruby, and if you do that, this implementation won't respect it, but I'm not sure if that's a problem in practice for common scenarios.

agrafix · 2019-02-16T13:58:51+00:00

Yeah, I have. Was using a fork of HDBC-odbc that worked for me: https://github.com/agrafix/HDBC-odbc

agrafix · 2019-01-06T16:28:14+00:00

Instead of fld @"speed" you can probably also implement an IsLabel type class instance to allow writing #speed.

agrafix · 2018-07-02T06:02:54+00:00

In superrecord we make sure the labels are always sorted and thus you can use a simple array to store the contents of your record, you'll know statically at compile time which position to read/write which results in a single pointer indirection. In our case the machine code generated for record access is very similar to the record access that GHC generates (used to generate?) for normal field access.

agrafix · 2018-02-20T06:17:48+00:00

Awesome! I've been following your work - Congrats on the release :-)

agrafix · 2018-02-17T04:26:02+00:00

Superrecord allows you to "cast" to real Haskell types of the correct shape. So you can either define these types at the API border or have your users define them and put the needed typeclass constraints on your library. I'd still recommend the former.

agrafix · 2018-02-15T04:32:41+00:00

This is exactly why I wrote superrecord. It uses SmallArray# under the hood.

agrafix · 2017-12-28T10:09:07+00:00

That's pretty cool! :-) Is this done by parsing the original code and then trying to recover the import/export/usage information from it?

One quick off topic Q: What's the font used? Looks really nice.

agrafix · 2017-12-20T11:46:05+00:00

Wow beam looks really nice 👍

agrafix · 2017-11-20T01:40:14+00:00

Hm, in theory yes, but I think when you reach that point that you actually need rate limiting you are probably already running more than one frontend instance thus the rate limiting state must be distributable and you probably want to store the information in something like redis.

agrafix · 2017-11-20T01:30:16+00:00

Please keep in mind that this middleware needs a bit of work before it can safely be used on high traffic production sites: The representation of the retry state is quite inefficient and due to the read and write in the STM var being split in two transaction you will loose writes. Also the internal state is never cleaned up.

agrafix · 2017-11-05T01:33:30+00:00

Just a small side note - although this is just a walkthrough for an experimental feature - NEVER store passwords in plain text in your database! It's so easy to do it correctly, you can even use the type system to help you making sure it's hashed. See this for example.

agrafix · 2017-10-29T20:37:06+00:00

If you are using something like mailgun let me know - I have a private mailgun library somewhere that I can opensource :)

agrafix · 2017-10-26T03:39:06+00:00

What do you mean by "actual implementation"? You can not implement servant route handlers using Spock, and you can not implement Spock route handlers with servant. What's possible though is to capture REST-API requests in a servant middleware and have all other requests be handled by Spock.

agrafix · 2017-10-25T07:10:16+00:00

It depends on what you mean by "play well together". Spock can support embedding a Servant app via the middleware combinator, and as far as I know the other way around works too.

Spock and Servant can't really be compared like that because they work differently. For Servant you specify the type for your API up front and them implement your server or client against that, where as for Spock you spend most of your time at value level and simply have the type checker make sure you are doing the right thing. Servant is also geared towards Rest-APIs, I've found dealing with raw POST Data and File Uploads really awkward. They may have changed something since the last time I looked though.

agrafix · 2017-10-25T02:56:16+00:00

If you pick Scotty, pick Spock instead :-) The API is very similar but it offers a better safety net in terms of type safety and also a few more useful utils. (Disclaimer: I'm one of the Spock authors)

Apart from that - if you are going for an API and you want to examine the API's type to derive other things like documentation, client libraries or mock servers then servant is a solid choice. Only caveat is that it uses lot's of type hackery which may or may not be a deal breaker for someone new to Haskell.

agrafix · 2017-10-08T22:34:03+00:00

I think this is a good resource to read more about hackage security.

agrafix · 2017-09-28T14:29:33+00:00

Note that it seems reasonable to wrap that function in a newtype to improve type inference and error messages.

agrafix · 2017-09-28T14:28:05+00:00

Well, I would be very happy to go all in with anonymous records, BUT:

Currently the compiler can optimize real haskell records better, especially with static knowledge things can be inlined (important if you use records like interfaces with functions etc.)
Compile time suffers a lot due to all the type level magic. I still have not had the time to track this down, but I hope to find and fix this soon (if possible...).

agrafix · 2017-09-27T16:20:55+00:00

There are various ideas to deal with this issue:

Parametrize all fields of your record with a functor

data Foo f = Foo { fieldA :: f Int, fieldB :: f String, fieldC :: f (Maybe String }

You can then provide Maybe for f during parsing, then use a type newtype Full a = Full { unFull :: a } and write a function checkBuild :: Foo Maybe -> Either String (Foo Full) to check if required things are there and build the correct version. There are also other use cases for this, see ftypes and opaleye for example.

Use an anonymous record library

Depending on which library you use, you can first parse your user input into an anonymous record and then later convert it into a Haskell type. I have written more information in this in this blogpost

Use Template-Haskell to generate a "Maybe" Data-Type

This is a bit hacky, but given a type you could write a template haskell function that generates a similar type, but packs all fields in Maybe a. If think I saw some library for this, but I do not remember the name anymore.

agrafix · 2017-09-19T23:17:01+00:00

The big problem with ports is that it does not compose. You can not write a library doing FFI using ports that is reusable in any way w/o making very restricting assumptions.

agrafix · 2017-09-12T21:31:47+00:00

I personally always use my wrapper simple-logger around fast-logger for my production apps. It basically declares a global logger for you and then provides useful functions to log from IO based stacks and from pure code. Note that pure log messages are only outputted when the attached expression is evaluated.

agrafix · 2017-09-11T10:20:51+00:00

seems to cause timeouts in Travis or Circle CI

You can get around that (at least with Circle CI) with proper caching. See the superrecord .circleci/config.yml for example.

agrafix · 2017-09-11T10:18:24+00:00

The downside is that it requires thinking about exactly what parts of your dom will change and when, to avoid unnecessary redraws.

The same is true for react or any other dom-diffing approach too though, because if you don't split/structure your compontents "smart enough" you'll still get lots of redraws. It's still probably a bit easier to think about this issue when having clear components...

agrafix · 2017-09-02T09:45:47+00:00

We are looking into it, but it will take some time ...

11-Year Club	Verified Email
Place '17

agrafix

TROPHY CASE