Ag <agzam.ibragimov@gmail.com> writes:

> Why have you closed it so quickly? I thought it would be open for a few
> more days.

I'm not sure what you mean; the survey was open for nearly a month.

-Phil

Claude Marinier <claudem223@gmail.com> writes:

> The match function uses this pattern
>
>     "(.*)\027%[7m(.*)\027%[0m(.*)"
>
> The "%" matches a digit, right? Is this correct?

No, in Lua patterns the % character indicates an escape code, so it's
just matching against a literal [ rather than using [] to denote
character set.

-Phi

Phil Hagelberg <phil@hagelb.org> writes:

> I've just recently opened the 2024 community survey. If you're a Fennel
> user, please take a few minutes to fill this out. It shouldn't take long!
>
> https://fennel-lang.org/survey

Hey friends! The survey closed a few days ago, and I finally got a
chance to finish summarizing the results. They are posted here:

  https://fennel-lang.org/survey/2024

Thanks!

Michel Lind <michel@michel-slm.name> writes:

> Thanks! Yeah, the breaking changes happened between 1.5.0 and 1.5.1 -
> prior to that the code accidentally worked in our build system as the
> Git remote was predefined, and the one git operation was to determine
> the branch -- that will fail, return nil, and nil is not 'main' so
> everything else got skipped.

Oh, that's funny; I ran into a really similar situation just over the
weekend trying to package it for Debian, except the problem was not
finding the branch; the builder system didn't have git at all. I assumed
yours was the same.

~michel-slm <michel-slm@git.sr.ht> writes:

> This means either Git is not installed, or the test is being run from a
> published tarball and not a Git checkout.
>
> In either case, that means we don't want to report the build result
> (many Linux distributions also build with network access disabled, so
> reporting will fail anyway) - and we should exit with status code 0, as
> this is not actually an error.

Good catch; thanks! I think until recently no one had ever tried to run
the test suite on a computer that didn't have git installed. But of
course this is the better move.

Greetings Fennel users.

I'm happy to announce that Fennel 1.5.1 is out. It's mostly a bug fix
but we did sneak one new feature in there; we now have literal syntax
for infinity (.inf) and NaN (.nan).

* `,doc`/`fennel.doc`: Don't mutate `:fnl/arglist` directly when showing callable form
* `(set (. tgt k1 ...) v)` now works on known globals and `$, $1 ... $9` in hashfns
* Macro quote expansion no longer breaks when `sym`, `list` or `sequence` is shadowed
* Bring `fennel.traceback` behavior closer to Lua's `traceback` by
  not modifying non-string and non-`nil` values.
* Avoid losing precision when compiling large numbers on LuaJIT.
* Add syntax for representing infinity and NaN values.

Andrey Listopadov <andreyorst@gmail.com> writes:

> Just wanted to announce a new release of my library for testing Fennel
> code: v0.1.50!  It's a pretty big update - I've changed a lot of things,
> and further enhanced the ability to configure custom reporters.

Congratulations on the release.

It's great to see you back again. =)

-Phil

Andrey Listopadov <andreyorst@gmail.com> writes:

> I'm not sure why it's failing. I've tested locally with 5.1, 5.3, 5.4
> and luajit, and it seems to build for me.  The error message is weird
> tho:
>
>> FENNEL_PATH=src/?.fnl lua5.1 bootstrap/aot.lua src/fennel.fnl --require-as-include >> fennel.lua
>> Compile error in 'negative-nan' src/fennel/parser.fnl:62: unable to bind number nan

I figured this out and it's very weird.

    $ lua5.1 -e "print(tonumber('nan'))"
    nan
    $ lua5.2 -e "print(tonumber('nan'))"

We had an interesting discussion today on the Fennel meetup call. Some
people were surprised that we could have `&inf` as the notation for
infinity because the current precedent for ampersand is to use it for
directives like `&as`, `&into`, or `&until`, and this uses a similar
notation but a very different meaning.

The original intent of marking `&` as reserved was just to have a
character that's guaranteed not to ever be a valid identifier in scope,
but the perception or common understanding of it is that it's for
directives.

So we started talking about alternatives which might be clearer. One
that was suggested was `.inf` because the dot suggests a numeric
meaning. Another suggestion was `&:inf` which looks different enough

andreyorst@gmail.com writes:

> &inf and -&inf were added to represent positive and negative infinity.
> &nan and -&nan were added to represent positive and negative NaN (not
> a number) value. For some reason, in PUC Lua 0/0 gives -nan so in
> order to generate positive NaN portably across most Lua
> implementations, math.acos(2) is used. If there's a way to do it
> without depending on math table, it should be used instead, as math,
> theoretically, may be absent in some implementations. Theoretically,
> n%0 is always NaN, but it's an error in PUC Lua specifically.

This looks good! It's very weird that 0/0 is considered negative in Lua,
and boy there are a lot of quirks to work around from one supported
version to another, but I think this does a good job.
[message trimmed]