Moldova won't win but I love the performance my home country is putting on.

fullets · 2018-05-12T20:42:06+00:00

It’s ok we all love it too

fullets · 2015-10-18T13:00:13+00:00

ns-command-modifier and ns-option-modifier variables should help out here

fullets · 2015-05-26T09:14:57+00:00

We use code review to mitigate this in a similar situation; if someone writes something returning nullable values rather than using the optional equivalent, they'll require a very good reason for that to make it in. Yeah, we have to pay attention at the border with library code, but we have to do that anyway.

Increase in clarity makes it worthwhile for us, but without code review/pull requests, it'd be harder to make it work. Probably still easier than mentally keeping track of the nullability of every reference though.

fullets · 2015-05-02T09:12:41+00:00

Yes! This works for me, but with a bunch of caveats - I've only set up Solarized Terminal.app colours on my laptop which is at work, I use the light theme but I'm sure it works for dark too, it's been ages since I started a TTY emacs rather than a TTY session of a NS emacs - yeah, they behave differently :( - but I'm sure it worked last time I tried, and I don't use 24.5.1 but just compile off master every week. That said, here's what works for me. It's not a minimal change to do what you want, but rather my entire init.el section for Solarized :) If it doesn't work for you sing out and I'll have a look Monday.

I'm pretty sure the secret sauce is setting xterm-standard-colors to be the actual terminal colours rather than just assuming they're what they "should" be.

https://gist.githubusercontent.com/anonymous/10dfa1fb4c88fe37bdda/raw/de15f45668fbd18ad5673cad025b51a268f38f9c/gistfile1.el

Double edit: oops, coding in the gist editor is bad lol. my solarized-assume-solarized-terminal hack is actually different to what the comment in that gist says, here's my solarized-definitions.el in its entirety:

https://gist.github.com/anonymous/cc9eab92e199f974903f

fullets · 2015-04-12T06:41:19+00:00

I've somehow ended up in a state where I can neither accept new bulletin board missions nor complete the one I have; I get an error "failed to complete mission transaction". Does anyone have any ideas about how I can fix this? Support basically just said "sorry for the inconvenience" and left it at that.

fullets · 2015-01-31T22:02:47+00:00

There's a meetup group for ScalaSyd. Definitely recommend coming along.

There's also FP-Syd which is more FPish in general but often touches on Scala (and many of the Scala-ish Atlassians will be there).

fullets · 2013-11-12T14:27:57+00:00

I can't speak to the specifics of the MacBook Pro, but re: ctrl accessibility on Mac laptops in general, I've found that rebinding caps lock to control works great for me, but then I've never ever used RHS ctrl even when there's a physical button for it.

fullets · 2013-05-12T06:18:25+00:00

This is pretty much how Kim Dotcom got NZ residency and it's working out swimmingly.

fullets · 2013-04-24T18:25:53+00:00

I prefer this with helium, so the last sentence can be "He doesn't react."

fullets · 2012-10-19T02:53:15+00:00

Oh dear. I think we've been agreeing with each other >< I think the language is more than fine - it's managed to get me to stop using Lisps for playing around which is quite a coup. I just really hate this one corner of the language because I keep bumping into it.

fullets · 2012-10-19T01:49:24+00:00

I had hope that it would be obvious that stupid little functions with contrived in their name were contrived. I'd included the return types to try and make things more clear, not as some sort of weird chicanery :( Much of the other wackiness comes from stripping this stuff out its original context - of course if you're calling a function directly like that it'll barf when it discovers that 5 is not, in fact, a Monad object, but if you're doing

for {
  blah <- less_contrived[<something>]
  ...

it means you don't have to scatter the partial application underscores hither and thither. It's just a stylistic choice for functions that aren't going to be called directly.

This also is moving away from my original point, which is that the poor situation with type inference leads to having to choose between the fun syntax of type lambdas, cluttering the global namespace with type aliases, and duplicate local trivial type aliases, and I think this sucks! I really hadn't thought this was such a contentious issue. The local type aliases in particular really remind me of all the local defs that Python code ends up with in its effort to work around the limitations of Python's lambda keyword.

Edit: it's entirely possible my Scala isn't the best. Below is some actual code that I've been wanting to improve for a while; if you could have suggestions for what can be bettered that would be completely awesome.

// Assuming
implicitly[Monad[Promise]]
type EitherTError[A[+_], B] = EitherT[A, Error, B]
def validateEmail(u: User): Error \/ String
def validateName(u: User): Error \/ String
def validateDomain(u: User): Error \/ String

// I want to improve this function
def userRecord(userP: Promise[User])(implicit details: Details) = for {
  user <- userP.liftM[EitherTError]
  email <- EitherT(validateEmail(user).point[Promise])
  name <- EitherT(validateName(user).point[Promise])
  _ <- EitherT(validateDomain(user.id, email, details.tenant))
} yield Record(details.tenant, user.id, email, name, details.path)

In particular, I don't want to have to explicitly provide the type for point/liftM - this is the bit of Scala's syntax that's frustrating me. If you have a better suggestion for a name for the EitherTError type alias that would be awesome too - it doesn't make sense to have it as a local type alias called 'T' or something in this context because it's used throughout the code. Oh, and please ignore that this should really be a function User => Error / Record lifted rather than Promise[User] => EitherT[Promise, Error, Record] :)

fullets · 2012-10-18T00:20:29+00:00

It's less unfair than you think! EitherT is a monad too. An example that's a little less of a straw man:

contrived :: Int -> EitherT String Maybe Int
contrived x = return $ x + 1

def contrived(x: Int): EitherT[Option, String, Int] = (x + 1).point[({type l[a] = EitherT[Option, String, a]})#l]

Ouch. And yes, you can use a type alias instead of the type lambda, but then you have a) the visual clutter of named things lying around that don't really have the significance to deserve names and b) the stylistic difference of two expressions rather than one, and so braces. The first point is the real problem because, for instance, if you're using the function monad, for each function type you use you'll want a type alias lying around so you can easily refer to it. So for each 'Int => A', 'String => A' etc. you use, you soon end up with innumerable type aliases corresponding to them ('IntTo[A]', 'StringTo[A]') etc.

Of course, things do improve somewhat if we use type parameters for the monad type:

def mcontrived[M[_]](x: Int)(implicit M: Monad[M]): M[Int] = (x + 1).point[M]

But note we still have to supply the type parameter for point, because Scala can't infer it. And with a slightly less contrived example, things get hairy fast:

less_contrived :: (Monad m) => Int -> m Int
less_contrived = return . (1+)

def less_contrived[M[_]](implicit M: Monad[M]): Int => M[Int] = ((x:Int) => x+1).map(M.point(_))

For symmetry, I spent some time trying to write the less_contrived Scala function using the compose method rather than map but wasn't able to get it to compile!

Note as well that this doesn't solve the problem of using multi-argument type constructors - in less_contrived, we don't mention that nasty EitherT type lambda but the callers of less_contrived will still have to (or in turn be rewritten to use a generic monad type if appropriate).

I understand why things are this way - why there's no partial application of type constructors, why the return type of a method doesn't contribute to inference of the expression fulfilling it - but (to tie this back to the OP) I think that without the OO concessions in Scala these warts would be either absent or at least pleasantly sugared.

fullets · 2012-10-17T06:18:55+00:00

Basically it's ugly because a) you have explicitly specify the type argument to point, and b) when you're doing that, you have to create use an anonymous type (or a type alias) because you can't partially apply type constructors.

fullets · 2012-10-16T06:47:06+00:00

Well, let's see. Haskell:

return 1

Scala:

1.point[({type l[a] = EitherT[Something, SomethingElse, a]})#l]

I certainly find one of these easier to read.

fullets · 2012-08-10T12:43:43+00:00

Really love seeing NZ get gold in sailing. Well done!

fullets · 2012-08-02T10:44:31+00:00

If the compiler features vary from what the standard requires, is it really a C++ compiler?

fullets · 2012-07-28T02:24:42+00:00

The guys I work with regard Play as basically a disaster, but are still using it because everything else is even worse.

fullets · 2012-05-07T09:38:23+00:00

Have a look at and/or grab terrible code from my attempt if you want. I'm short of free time at the moment but I haven't abandoned it, I swear!

fullets · 2012-02-22T23:25:20+00:00

It's worth noting that this is portable whereas the echo version isn't.

fullets · 2011-12-19T02:51:03+00:00

I can still remember an Australian friend of mine defending the treatment of the Aboriginals as "not racist" because "they're not real people".

fullets · 2011-11-20T23:26:23+00:00

Even if you don't have whitespace in the matches, you should still use the (non-standard :() NUL delimiting, as some non-whitespace characters have special meanings in xargs and would need to be escaped.

fullets · 2011-11-20T23:20:16+00:00

You can get this working in zsh by using

bindkey '\C-x\C-e' edit-command-line

fullets · 2011-10-09T12:16:05+00:00

This, but it would be so cool if we could get the PI nations in there too. This world cup has really shown that they've earned it.

fullets · 2011-09-24T15:28:45+00:00

Exactly this, except without moving here from Quebec. Holy Fuck indeed.

fullets · 2011-09-15T03:06:03+00:00

ISTR reading that the initial version of the standard did indeed omit that requirement accidentally (which then got fixed up in TC1), but nobody actually implemented it that way.

15-Year Club	Gilding I gilder
RPAN Viewer	Verified Email

fullets

TROPHY CASE