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 :)

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!

At least the code now has one external reader!

;)

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!

Theodor Thornhill referenced this ticket in commit a11b92d.

Theodor Thornhill referenced this ticket in commit a11b92d.

Theodor Thornhill referenced this ticket in commit d257076.

Yeah! I've seen that as well!

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.

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?