~theo

Bergen, Norway

https://thornhill.no

Trackers

~theo/edap

Last active 3 months ago

~theo/gql

Last active 6 months ago

~theo/tree-sitter

Last active 7 months ago

~theo/Satchel

Last active 11 months ago

#34 Examples nolonger work 6 months ago

Comment by ~theo on ~theo/gql

Yeah! I think doing the same as parenscript makes sense - I think using NULL is a good idea. I'll consider this moving forward - thanks!

As for the examples, I'll get to it eventually, as time permits :)

#34 Examples nolonger work 6 months ago

on ~theo/gql

One idea you could try is using the same conversion that parenscript does

  • T
  • F
  • FALSE
  • NIL
  • UNDEFINED

T and FALSE (or F) are converted to their JavaScript boolean equivalents true and false.

NIL is converted to the JavaScript keyword null.

UNDEFINED is converted to the JavaScript global variable undefined.

https://parenscript.common-lisp.dev/reference.html#ssection-booleans

Only concern here would be the use of NIL since you would then have to consider the overlap of NIL and (). If you represent JS arrays as CL arrays this wouldn't be an issue.

Anyways just a thought that may interest you.

"~theo" outgoing@sr.ht writes:

[[PGP Signed Part:Undecided]] On 9 Jul 2022 08:33, ~gavinok outgoing@sr.ht wrote: Current example files are out of date. I have yet to learn the new api but at the moment at least example1.lisp is using the wrong api. For example

(defparameter *fields*
  (list
   (field :name "name"
               :type *string*
               :resolver (constantly "Theodor Thornhill"))
   (field :name "age"
               :type *int*
               :resolver (constantly 31))))

should be

(defparameter *fields*
  (list
   (field :name "name"
               :gql-type *string*
               :resolver (constantly "Theodor Thornhill"))
   (field :name "age"
               :gql-type *int*
               :resolver (constantly 31))))

You are absolutely correct that they are out of date, unfortunately. I'll see if I can update them this evening or so. I will also make a real list of actionable task for me and/others to work on so that it will be actually useful.

I'm struggling a bit on the coersion between nil/false/null/true problem in lisp vs js, but we'll get there :)

Also I finally have some summer holidays, so there's that :)

Thanks for your interest!

#34 Examples nolonger work 6 months ago

Comment by ~theo on ~theo/gql

At least the code now has one external reader!

;)

#34 Examples nolonger work 6 months ago

Comment by ~theo on ~theo/gql

On 9 Jul 2022 08:33, ~gavinok outgoing@sr.ht wrote: Current example files are out of date. I have yet to learn the new api but at the moment at least example1.lisp is using the wrong api. For example

(defparameter *fields*
  (list
   (field :name "name"
               :type *string*
               :resolver (constantly "Theodor Thornhill"))
   (field :name "age"
               :type *int*
               :resolver (constantly 31))))

should be

(defparameter *fields*
  (list
   (field :name "name"
               :gql-type *string*
               :resolver (constantly "Theodor Thornhill"))
   (field :name "age"
               :gql-type *int*
               :resolver (constantly 31))))

You are absolutely correct that they are out of date, unfortunately. I'll see if I can update them this evening or so. I will also make a real list of actionable task for me and/others to work on so that it will be actually useful.

I'm struggling a bit on the coersion between nil/false/null/true problem in lisp vs js, but we'll get there :)

Also I finally have some summer holidays, so there's that :)

Thanks for your interest!

#25 Make sure we check the validation errors 1 year, 26 days ago

Comment by ~theo on ~theo/gql

Theodor Thornhill referenced this ticket in commit a11b92d.

#13 Make validation tests actually check validation errors 1 year, 26 days ago

Comment by ~theo on ~theo/gql

Theodor Thornhill referenced this ticket in commit a11b92d.

#29 Resolve abstract type 1 year, 26 days ago

Comment by ~theo on ~theo/gql

Theodor Thornhill referenced this ticket in commit d257076.

#1 Migration to sourcehut 1 year, 1 month ago

Comment by ~theo on ~emacs/emacs

Yeah! I've seen that as well!

#1 Migration to sourcehut 1 year, 1 month ago

Comment by ~theo on ~emacs/emacs

On 22 December 2021 21:41:08 CET, ~larsi outgoing@sr.ht wrote:

The mail is from the sr.ht server:

Received: from mail-b.sr.ht ([173.195.146.151]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from outgoing@sr.ht) id 1n08MH-0003SA-0e for larsi@gnus.org; Wed, 22 Dec 2021 21:37:11 +0100

So you've sent the mail to sr.ht, and it has apparently mangled it before sending it on to me?

Apparently. In notmuch, I press R, then type, then C-c C-c. (this one is sent from K9 on android)

What specifically is mangled, so that I know we are talking about the same things? Also would help me pass it on to the devs.

#1 Migration to sourcehut 1 year, 1 month ago

Comment by ~theo on ~emacs/emacs

Wasn't the message I was looking at in the URL sent from/via Sourcehut? The Received header seems to say so?

Your messages on emacs-devel look fine, but they haven't been via Sourcehut.

No, The only messages I've sent from the web forms are the ones from the ~emacs user. Strange. But to me it looks mostly like a line-wrapping thing? Or is it something else you are thinking of?