gkossakowski

Warsaw AI Breakfast Reel: llm & helicone.ai

llm by Simon Willison

Intro to llm

llm "Hello"

gkossakowski

❯ llm --cid 01h8f03gxe1bept7sz4yww2t8t -t qa-steps-to-json ""
Traceback (most recent call last):
  File "/opt/homebrew/bin/llm", line 8, in <module>
    sys.exit(cli())
             ^^^^^
  File "/opt/homebrew/Cellar/llm/0.8/libexec/lib/python3.11/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/llm/0.8/libexec/lib/python3.11/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)

gkossakowski

class A1 {
    String f1(String x) { return x; }
    String f2(String x) { return x; }
    .
    .
    String f100(String x) { return x; }
}

gkossakowski

val resolvedParents = new util.ArrayList[Type]()
var remainingParents = tmpl.parents
while (remainingParents.nonEmpty) {
  val parent = remainingParents.head
  val resolved = resolveTypeTree(parent, lookupScope)
  // this is awkard and highly repetitive pattern
  resolved match {
    case CompletedType(tpe) => resolvedParents.add(tpe)
    case _: IncompleteDependency | NotFound => return resolved
  }

gkossakowski

sealed trait Result[T]
case class CompletedResult[T](value: T) extends Result[T]
case class IncompleteDependency(dep: Symbol) extends Result[T]

// completer is:
() => Result[T]

gkossakowski

// Ensure constructor is completed so that any parameter accessors
// which have type trees deriving from its parameters can be
// completed in turn. Note that parent types access such parameter
// accessors, that's why the constructor needs to be completed before
// the parent types are elaborated.
index(constr)

annotate(constr :: params)
symbolOfTree(constr).ensureCompleted()

gkossakowski

| Tydzień | Dystans km | Przyrost % | Przyrost 7% = km |
|---------|------------|------------|------------------|
|       1 |         30 | 7%         |              2,1 |
|       2 |       32,1 | 7%         |             2,24 |
|       5 |      36,75 | 7%         |             2,57 |
|      10 |         59 | 7%         |             4,13 |
|      15 |      82,77 | 7%         |             5,79 |
|      20 |        116 | 7%         |             8,12 |
|------------------------------------------------------|
|      25 |     162,82 | 7%         |            11,39 |

gkossakowski

Scala's "type T in class C as seen from a prefix type S" with examples

Introduction

Recently, I found myself in need to precisely understand Scala's core typechecking rules. I was particulary interested in understanding rules responsible for typechecking signatures of members defined in classes (and all types derived from them). Scala Language Specification (SLS) contains definition of the rules but lacks any examples. The definition of the rules uses mutual recursion and nested switch-like constructs that make it hard to follow. I've written down examples together with explanation how specific set of rules (grouped thematically) is applied. These notes helped me gain confidence that I fully understand Scala's core typechecking algorithm.

As Seen From

Let's quote the Scala spec for As Seen From (ASF) rules numbered for an easier reference:

gkossakowski

### Keybase proof

I hereby claim:

  * I am gkossakowski on github.
  * I am grek (https://keybase.io/grek) on keybase.
  * I have a public key whose fingerprint is F784 54E6 6DA3 D66C 89D2  C01E 287A 9033 977D BF9C

To claim this, I am signing this object:

gkossakowski

function fetchTweets(username, callback) {
  jQuery.ajax({
    url: "http://api.twitter.com/1/
    statuses/user_timeline.json/",
    type: "GET",
    dataType: "jsonp",
    data: {
      screen_name : username,
      include_rts : true,
      count : 5,