[00:09:50] Yes, I think it’s only in Try this function and Try this implementation that it’s a problem. (In https://www.wikifunctions.org/wiki/Special:RunFunction one can wrap the call oneself.) (re @Toby: I missed when you showed this issue at first. Interesting. I can see why it might make sense to wrap it in something like "evalu...) [00:27:36] Z20107 Is this attempt futile? Do errors propagate through a separate output stream, or can we scrutinize them with functions? [00:29:07] I'd imagine they ignore everything and just output the error when it is thrown (re @Toby: Z20107 Is this attempt futile? Do errors propagate through a separate output stream, or can we scrutinize them with functions?) [00:29:16] Maybe they don't [00:32:14] Does anyone know if what I pick here matters? : https://tools-static.wmflabs.org/bridgebot/e1bc4a0b/file_66565.jpg [00:32:26] I guess I'll just go with the first one [00:40:30] if it didn't matter they wouldn't be asking :p (re @Feeglgeef: Does anyone know if what I pick here matters?) [00:40:55] every database server has its own set of commands and quirks [00:40:56] which one do you have installed? [00:41:16] I think SQLite? [02:45:41] I have to agree with lydia. people started posting milestone numbers in the news on wikidata's main page and it soon became the only thing people add there. new features? not newsworthy. upcoming events? not newsworthy. a tool's own database reached an id that's all twos? quick, put it on the main page!! (re @vrandecic: I'll consider it 🙂 Lydia always scolds me when I [02:45:41] celebrate numbers 🙂) [02:57:34] if you want to point it out to people, I think it would be better to briefly mention it as context for something else, rather than just celebrating the number. a post that's something like "we recently reached 10,000 functions so I thought it would be a good point to analyse what we have so far" and goes on to look at various aspects we actually care about (e.g. do [02:57:34] they all have [02:57:35] tests, do all the tests pass, are they doing useful things) would be a lot better than just "yay we reached 10,000 functions" [02:58:12] 10,000 objects* (re @Nikki: if you want to point it out to people, I think it would be better to briefly mention it as context for something else, rather th...) [02:58:17] But yeah [02:58:40] All of them are labeled I guess [04:50:34] Re: _MR 249: Ingest more statements when fetching lexemes, etc._ (planned for deployment soon) - I'm curious to know if the "Identifier" statements have much value in Wikifunctions use cases. These are statements, in a lexeme, indicating which entries in external dictionaries are equivalent to the lexeme. For example there are about 12 of these listed for L3435. Asking [04:50:34] because [04:50:35] there are so many of them... if they will never be used in Wikifunctions, we could omit them, by default, from the fetched lexeme to avoid needless bandwidth and processing time. (re @cvictorovich: Need it very very much) [04:51:07] P5186 is needed! (re @David: Re: MR 249: Ingest more statements when fetching lexemes, etc. (planned for deployment soon) - I'm curious to know if the "Ident...) [04:51:30] Unsure about others [04:51:49] I don't see a use case, if there is one it's probably small and not worth it (re @David: Re: MR 249: Ingest more statements when fetching lexemes, etc. (planned for deployment soon) - I'm curious to know if the "Ident...) [04:53:15] ^^ (re @cvictorovich: P5186 is needed!) [04:53:37] For verbs they’re very very important (re @Feeglgeef: ^^) [04:53:43] Right. That sort of statement is not one of these Identifier statements, and would definitely be included. (re @cvictorovich: P5186 is needed!) [04:54:12] Yeah, basically mandatory (re @cvictorovich: For verbs they’re very very important) [04:54:15] You might not speak French: as if you understand a little French, you would know how important this property is [07:48:52] Never say never 😉 [07:48:53] I could imagine some use for identifiers. [07:48:54] Like if we need to choose between two lexemes, we could choose the one with the more identifiers (as it's probably the more common lexeme) (re @David: Re: MR 249: Ingest more statements when fetching lexemes, etc. (planned for deployment soon) - I'm curious to know if the "Ident...) [09:19:13] Not sure. I can see a case for returning (or not returning) specified portions of a lexeme, by default, yes. But “by default” implies to me that there is still some way to have the excluded portions returned. That means more development work and it would not bother me if, for some time, the Identifiers became unavailable. In practice, though, I think separate built-ins to [09:19:13] ret [09:19:14] rieve a lexeme with or without (all) its Forms would have a more positive impact. I think that would also imply a “fetch forms of Wikidata lexeme” built-in. (re @David: Re: MR 249: Ingest more statements when fetching lexemes, etc. (planned for deployment soon) - I'm curious to know if the "Ident...) [14:19:16] Yeah, but I think we should only do this when we have code implementations able to call other functions, so that Python and JS can use these. (re @Al: Not sure. I can see a case for returning (or not returning) specified portions of a lexeme, by default, yes. But “by default” im...) [15:28:08] In theory, we can re-build the complete Wikidata lexeme with a composition and have code implementations and compositions operate over the re-constructed Wikidata lexeme object 😏🤷‍♂️ (re @Feeglgeef: Yeah, but I think we should only do this when we have code implementations able to call other functions, so that Python and JS c...) [21:34:20] Wouldn't that be slower than just a call to get the full lexeme? I'm saying we have separate functions to get certain parts of a Lexeme if a function only needs one of them. [22:05:29] In general, yes (ignoring any cached results). But if a code function needs any combination of parts (including all the parts) it can operate over the result of a composition of built-ins that fetch all and only the required parts (in theory). If we generally require less than the whole thing, the average result might be quicker. (re @Feeglgeef: Wouldn't that be slower [22:05:29] than just [22:05:30] a call to get the full lexeme? I'm saying we have separate functions to get certain parts of a...) [22:06:07] If we could optimize to only one call to Wikidata, yes. (re @Al: In general, yes (ignoring any cached results). But if a code function needs any combination of parts (including all the parts) i...) [22:06:54] Or a small number of quick calls. (re @Feeglgeef: If we could optimize to only one call to Wikidata, yes.) [22:07:02] Yeah [22:12:05] @vrandecic or Z20118 (re @Feeglgeef: @vrandecic it is a little early but I suggest that for the Volunteer's Corner, we try to come up with a function that can connec...) [22:12:58] It's difficult but reasonably doable [22:17:09] Our fraction words (for the denominator) are mostly the same as our ordinals Z14525 (re @Feeglgeef: It's complex but reasonably doable) [22:19:45] We would have to cover edge cases (with something like Z19601) and add s, but that function handles a lot of the heavy lifting (re @Al: Our fraction words (for the denominator) are mostly the same as our ordinals Z14525) [22:27:09] I've created one test as rough guidance but I will leave everything else up for discussion during the corner [23:07:14] This is my first choice, unless someone thinks of a better idea (re @wikilinksbot: Z20118 – English Rational Number)