<triallax>
if i feel like it later maybe i can set up a bridge to matrix or something
<sharkdp>
We recently got two larger (corporate) sponsorships for my 'bat' and 'fd' projects. They are far more popular in terms of page views compared to Numbat, which is why some companies are interested in placing their sponsorship logos in the READMEs. We have discussed the pros and cons of this and some ideological concerns, but eventually decided to go for the money :-).
<sharkdp>
I'm mentioning this here because we decided to split that money evenly between the maintainers of those projects — but to also set aside a part of the money to support maintainers and contributors on my other projects, like Numbat.
<sharkdp>
I'm not yet sure *how* I will do that. And I don't really want to distribute it by "amount of work done on a project", because I want contributors to be motivated by other factors (and I know that all of you are!).
<sharkdp>
But I guess I'm saying that *if* some of you are interested in setting up GitHub sponsors, I'd definitely be interested in giving back some money for your awesome work on Numbat.
<sharkdp>
(Do not expect *huge* amounts of money)
<sharkdp>
Feel free to ask questions here or to me personally, if you are interested. And let me know if one of you sets up GitHub sponsors.
<achin>
congrats on the bat and fd sponsorships! they are both daily tools for me, as i'm sure they are for many others. it's well-deserved to get some money from companies relying on them
<achin>
if you don't mind me asking, do you have a day job? i'm wondering how you have time for all these great tools :)
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
<triallax>
congrats, that's great news!
<triallax>
i know you said that you want to distribute it based on how much work somebody does, but i don't think that what i do even comes close to crossing the threshold for accepting numbat-related donations
<triallax>
don't want to*
<triallax>
maybe you disagree, but the fact that i'm a numbat maintainer is more of a historical happenstance than anything else because i used to maintain insect as well
<triallax>
which is fine, i don't mind it at all, but it's something i have to keep in mind when i consider numbat donations
<triallax>
that being said, maybe i should set up github sponsors regardless
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
<sharkdp>
achin: yes, I have a normal day job (currently only 35h/week)
<sharkdp>
some of those projects are years old :-)
<achin>
still, it's pretty impressive
<sharkdp>
achin: I know it was mostly slowed down because of me, but I would really like to get a first version of DateTime handling merged. What are the big open questions? I see at least two points:
<sharkdp>
1) How we deal with the "hardcoded" time dimension and the hardcoded unit of seconds.
<sharkdp>
2) Whether or not we can use "Time" as the type/dimension for durations.
<sharkdp>
Concerning point 2, I think I am now more confident to go with your current approach, after I saw that Frink basically does the same
<achin>
for #1, i agree we want this, but i would be comfortable delaying that to a subsequent merge request. we brainstormed about some ideas like a new "time" annotation, but i don't think we fully settled on the approach we should use
<achin>
for #2, i've also come to the same conclusion, mostly based on my own personal usage (but also based on the research done with other comparable tools)
<sharkdp>
concerning #1: ok, I just noticed that we can use 'numbat --no-prelude'. we just don't have datetimes unless we include core::datetime, which would then pull in SI units. But that's an OK solution
<achin>
if someone has a usecase where they are defining a custom prelude with different a time/second, i would be very interested in learning more about their use case :)
<triallax>
parallel universe denizens! :P
<sharkdp>
I know, it's more of an ideological thing I guess. But somehow I really like the decoupling of the core language and the prelude. We had something very tightly coupled in the previous Insect project, and I like the new approach much more.
<achin>
fully agreed
<sharkdp>
But I see that we do need some sort of coupling between DateTime, some Time dimension, and a unit of time (or more specifically, a "second" unit).
<sharkdp>
I would probably go with the decorator solution. Something like @register_time_dimension and @register_time_unit. Or a generic @register decorator with some sort of argument.
<achin>
this isn't quite the right terminology, but i'm reminded of the #[lang = ""] syntax from rust, for defining "language items"
<achin>
a way of saying "this thing that i'm defining is special for the language"
<sharkdp>
wait, I need to check what #[lang …] does :-)
<sharkdp>
we're free to come up with a new syntax here. but I guess the decorator pattern fits quite well. Regarding the name, I'm open for suggestions.
<sharkdp>
Maybe we could use a more generic @lang(…) or similar for other things as well. Like if we introduce @…@ syntax for entering datetimes, maybe that should call a user-definable String->DateTime function? Which is registered with the language to be *the* datetime parsing function?
<sharkdp>
(which would allow users to customize how datetimes are parsed)
<achin>
yeah, having customized datetime parsing is a must, i think. eventually i think parse_datetime will be extended to take an optional 2nd argument (do we support varidict functions?) with a formatting string. but if you have your favoriate datetime format, it will be tedious to have to specify your custom formatting string every time
<sharkdp>
we have variadic functions, but only for foreign functions.
<triallax>
native variadic functions need list/array data types, right?
<achin>
ah, good, because parse_datetime is a foreign function
<sharkdp>
triallax: yes, probably
<achin>
this is a really "adventurous" suggestion, but i'll put it out there anyway: if we introduce a @...@ syntax for constructing datetimes, could we imagine making that generic, allowing custom syntax for constructing arbitrary objects? this thought entered my head when i was trying to write some functions to help with dice math, and i wanted a way to represent dice configurations like "2d6" (to
<achin>
represent 2 rolls of a 6-sided dice)
<triallax>
why don't we just have composite data types
<triallax>
or structs or records or whatever we want to call them
<achin>
it's tempting to shove all sorts of crazy things into numbat. i'm not sure what guiding principle we should have here
<triallax>
yeah
<sharkdp>
My guiding principle would be: let's try to make the language more powerful. Then we can implement all of this in Numbat itself (as modules/libaries). Yes, we are far from that goal :-)
<sharkdp>
Special syntax is something you usually cannot implement in a library... unless you have macros, metaprogramming, overloadable operators, …
<achin>
yeah
<sharkdp>
Maybe we should indeed have something more generic instead of "just" a special datetime-entering-syntax. Something similar to user-defined literals in C++. Or prefixed strings like d"2024-02-07" and dice"2d6"
<sharkdp>
I like it. But let's focus on merging #287 first
<sharkdp>
I will give it a more thorough review tomorrow
<achin>
tonight i'll go through some of the comments you made and push a commit
<sharkdp>
https://i.imgur.com/LRiBUhe.png I know why it's happening (DST), but this is a bit confusing. I am in the "Europe/Berlin" time zone.
<sharkdp>
(it doesn't happen for a date in winter)
<triallax>
smells like dst to me
<sharkdp>
yes (see above)
<triallax>
ah yeah, missed that
<triallax>
shouldn't local be the current timezone
<triallax>
and not just the current offset
<sharkdp>
What's confusing is that I am doing this calculation in winter... when "local" is "Europe/Berlin (winter)"
<sharkdp>
presumably
<sharkdp>
If I would do that same calculation in summer, I would probably get +0200 for "local" as well
<triallax>
that's how it should be i'd say
<sharkdp>
yes, probably
<triallax>
or what i mean is, "local" should consider dst and that stuff
sharkdp has quit [Remote host closed the connection]