@AlanMunn They do, because they all stopped over in the north of Scotland to pick up some burds. :p

@barbarabeeton I don't think I've ever even seen a teal. :p

quack

baa!

ooh

@PauloCereda Hi duck person! :D

@Plergux how are you?

@PauloCereda Very good. Went to see an old friend last night and we chatted for four hours. Which is maybe not strange cause we'd not seen each other almost ten years! It was very nice :D

@Plergux ooh

@StefanKottwitz oh no, it's a comic strip named "Foxes in love"

Hi all!

@yo' hi Tom!

@PauloCereda how do you do?

@yo' okay-ish I guess... and you?

@PauloCereda I'm fine. I had a NID (No internet day) yesterday, and it felt so great!

@yo' ooh

@DavidCarlisle quack <3

@PauloCereda breakfast

@DavidCarlisle oh no

@DavidCarlisle brunch?

@UlrikeFischer probably lunch by the time it's done

oh no

@Plergux A couple of sheep on their Sunday stroll

@samcarter_preparing_for_xmas oooooh!

@JosephWright do you think a function turning a property list into a key=value list would be interesting?

@Plergux ooh

@Skillmon Sure

@JosephWright just because the l3prop module has \prop_set_from_keyval:Nn, but not \prop_to_keyval:N (which could be implemented expandably, returning in \unexpanded).

@JosephWright Potential use case: Manage stuff as a property list which should then be parsed as a keyval list by another keyval solution (e.g., managing a TikZ style with expl3, but then passing it on to \pgfkeys).

@JosephWright also, currently \prop_set_from_keyval:Nn can't be used to parse user input after \begin{document} (if comma or equals sign are active). I didn't benchmark this, but instead of implementing \__prop_from_keyval_loop:w one could just use \keyval_parse:NNn to populate the property variable. (I think this might imply a slight performance hit, whether the increased robustness is worth it I'm not sure, after all property lists are meant to store programmatic information)

@Skillmon it is only a small wrapper around \prop_map_function:NN, but it could be useful. The main question is if it should be \prop_to_keyval:N, or \keys_set_from_prop: ;-)

@UlrikeFischer the former to allow other key=value interfaces to be used, imho. I already have an implementation, which takes 39 lines (actually 17, but currently I use two separate implementations if \expanded is available or not, doubling the effective lines of code, plus 5 lines for the conditional)

@UlrikeFischer my implementation expands after two steps of expansion and returns the result inside of \unexpanded.

@UlrikeFischer the most important thing to note is, that my implementation reverses the prop, since they are documented as unordered this seems ok, but it should be noted, as there might be use cases in which the order of keys matters (looking at the image manipulations of graphicx for example).

I could change that behaviour to not reverse the output fairly easily, I think, the result would be a bit slower.

@Skillmon well the keys-module could declare a "key-val" variable type, a tl-var or a direct output which contains the key-val-list and then the keys function could fill this and other implementations could use it too. So it is more the question in which module it belongs more.

@UlrikeFischer imho, it should belong to either prop or keyval, not to keys.

@Skillmon properties are unordered, I don't think that it would be good to implement functions which rely on them being not really unordered.

@UlrikeFischer I know, hence I said "since they are documented as unordered this seems ok" :)

BibLaTeX question: How can I avoid shortening the author list in the reference list, but do shorten it in author-year style citations?

Never mind, maxbibnames

I do have another, somewhat weird question: Is it possible to modify the formatting of just one reference out of many? I would effectively like to have minbibnames=2 just for one reference, but keep minbibnames=1 for the rest.

My \prop_to_keyval:N function:

\cs_if_exist:NTF \tex_expanded:D
  {
    \cs_new:Npn \prop_to_keyval_list:N #1
      {
        \__kernel_exp_not:w
          \prop_if_empty:NTF #1
            { {} }
            {
              \if_false: { \fi:
                \exp_after:wN \__prop_to_keyval_list_aux:w
                \tex_expanded:D
                  { \prop_map_function:NN #1 \__prop_to_keyval_list_aux:nn }
              }
            }
      }
    \cs_new:Npn \__prop_to_keyval_list_aux:w ,
      { \exp_after:wN { \if_false: } \fi: }

@Szabolcs Using biblatex with authoryear style?

@Skillmon I see you added braces ;-)

@AlanMunn ext-authoryear

@UlrikeFischer added braces? You mean around the value? Yes, that's quite important. The thing which might need explanation is the space before the opening brace of the values :)

@Szabolcs maybe it is a good idea to ask this as a question on the main site. It seems like something future visitors might be interested in as well!

@Skillmon I thought it might be considered a ridiculous request to want to format just a single reference differently from the rest (there is a very good use case though...)

@Szabolcs if you have a good use-case just include it as a short note in the question, I'm sure the community will understand and not mock you for wanting it in the first place :)

@Skillmon @Szabolcs Already asked:

@Szabolcs there are quite a number of question about how to format single reference differently (mostly to show a specific author)

Yes, useful for job applications and such ...

@AlanMunn well, I didn't search for it, and never needed this myself, but thanks for pointing out :)

@Szabolcs The general idea is to use \AtNextCite and temporarily change the maxnames counter. (See the second answer, not the accepted answer, and not mine).

That is the one I am looking at.

Thanks for the reference!

I should have searched more carefully.

@DavidCarlisle developers.slashdot.org/story/20/11/14/235253/…

@Szabolcs It's much easier to search for an answer than a question, which is why it was easy for me to find. I knew the answer, and just searched for AtNextCite. :)

@PauloCereda Apple is unlikely to contribute ... Recently they seem to be saying, "Do it the Apple way or go away!" Think making CUDA impossible to use (no NVIDIA drivers on newer macOS), abandoning OpenGL and OpenCL ...

Big companies like Adobe may be able to afford to support Apple-only technologies like Metal. Open source projects (most of the scientific stuff) simply can't.

@Szabolcs Wow this will make all of the Mac using R community very pissed.

Not just R, but most numerically focused stuff.

@Szabolcs bye LAPACK

@Skillmon That is actually not a problem. Apple ships a BLAS and LAPACK implementation as standard with macOS (see vecLib). Actually, most performant BLAS and LAPACK implementations are not written in Fortran. Only the NetLib implementation is (but that one is slow, it's just a fallback when there's nothing better)

At least that's my understanding.

@Szabolcs Yes, although I think the R community is broader, and therefore likely has more people who might be affected. It's certainly true in my corner of the world.

@Szabolcs :(

@Szabolcs afaik, LAPACK is a FORTRAN lib, and things like clapack are C ports of LAPACK, but it's been a while, so I'm not sure here.

@AlanMunn well, the Python community isn't small either, and things like SciPy are widely used.

It's better to think of LAPACK as a semi-standardized API than a library (the Fortran library is the NetLib one). It is a Fortran API, but it's callable from C. Basically no one uses NetLib lapack

This is a list of many (but not all) implementations of BLAS: cmake.org/cmake/help/latest/module/FindBLAS.html

Most implement the LAPACK API as well: cmake.org/cmake/help/latest/module/FindLAPACK.html

OpenBLAS is a very common open-source implementation of both the BLAS and LAPACK APIs. MKL provides another (commercial one) and may other things. Apple's vecLib yet another one. As far as I know, none of these are written in Fortran.

But maybe I am getting details wrong. I also learned this only this summer.

@Szabolcs then it's arguably newer/fresher for you :)

Newer, but not quite complete, just cobbled together from various sources on the web while working on igraph (which needs BLAS/LAPACK)

Well my Mac is probably on the verge of a Linux install, as it's now 4 version behind.

I stopped at High Sierra.

Any my old Macbook still holds a Lion install.

Well, had a Lion, now it's running Fedora. :)

@Szabolcs of course the best lapack documentation is my day job:-) nag.com/numeric/nl/nagdoc_27.1/flhtml/f07/f07conts.html

@DavidCarlisle write(*,*) "quack"

@PauloCereda write(6,99997) "dinner"

@DavidCarlisle oh no

/quacks in FORTRAN

@DavidCarlisle FORMAT label 99997 not defined

\dies of nerd :p