00:35 sftp left 00:51 sftp joined, sftp left, sftp joined 02:18 guifa joined 02:22 hulk joined
guifa finally got permission to implement Calendrical Calculations in Raku! 02:22
02:23 kylese left
guifa means I can finally attempt to extend Date to accept a range of different calendars 02:23
it's going to be a bit tricker than with DateTime::Timezones though. There's a lot of entangling going on between Date / Dateish / DateTime that's not going to be easy to just tack on 03:08
03:15 hulk left, kylese joined 05:06 Sgeo left 06:17 sivoais left 06:31 sivoais joined
japhb guifa: Permission from whom? $day-job? Are you going to get paid for Raku work? :-) 08:11
guifa japhb there's a fairly definitive work on calendars called Calendrical Calculations. While in the US generally formulae are not considered copyrightable, I'd rather not take the risk 08:18
Authors granted permission with request to use the Apache license 08:19
08:25 belluzj joined 09:11 erooke left 09:26 erooke joined 09:32 cleo left 09:48 belluzj left 09:52 belluzj joined
lizmat guifa: I assume you're aware of the work of Jean Forget ? raku.land/zef:jforget 10:24
10:56 belluzj left
guifa lizmat: I am 11:04
It looks like in that one, the sourcing for each calendar is a bit different potentially -- in this case, I'll be building all of them off of a single common set of algorithms from the definitive work on the topic for consistency / maintenance 11:08
lizmat I was just thinking whether it would make sense to involve him in this project, he clearly knows a bit about the subject :-) 11:09
guifa true true 11:11
the algos themselves aren't too complicated
the tricky bit is the other half: modifying Date itself like I did with DateTime for the timezones so everything just magically works 11:12
lizmat and doesn't affect the performance of core Date too much, I hope? 11:13
:-)
guifa heh that's definitely up there in my thoughts 11:14
I don't think performance should be significantly impacted. Ultimately, all the algos are based off of the julian date (days since an epoch), which is functionally no different than working from unix time (which is just seconds since epoch) 11:16
at worst there should be a handful more math calculations, but for most calendars, it's a straight forward set of math, no loops or anything like that 11:17
the biggest effect on the perf will be just the performance impact of calling a method with wrap
11:28 erooke left 11:45 erooke joined
disbot <antononcube> @guifa Just generate the Raku code using LLMs. Then they (whoever they are) cannot claim copyright. 12:21
lizmat doesn't that imply that using stolen goods is ok as long as the dealer of stolen goods is rich enough ? 12:25
disbot <antononcube> Yes. LLM providers are obviously committing a large scale theft. But, well, they all "big tech" and US government and Wall Street are behind them. So, it is ok. 12:28
<antononcube> But, on a more practical, if you generate code and formulas just by using LLM prompts and / or AI-agent workflows, you are just leveraging the accumulated humanity knowledge. Using publicly available tools. 12:31
<antononcube> * practical note 12:32
lizmat practical, yes: also makes copyright meaningless, as you only have to claim you produced it using LLMs 12:38
disbot <antononcube> Yeah, more or less. 12:43
<antononcube> Hence everything would become "open source".
lizmat I guess some creative people would like to have a word 12:44
disbot <antononcube> Yeah. And their word is going to be summarized and answered by LLMs. 12:45
lizmat that's a bleak vision of the future 12:46
disbot <antononcube> There is a certain GitHub repository (or, maybe, five at this point) that give AI-agent workflows to "reverse engineer everything". From bytecode you can produces source code. (Of any language.) This already means that a fair amount of software is learnable and digestible by LLMs / AIs.
<antononcube> I plan to write about my recent advancements with Raku numerical packages: numerical integration, optimization, and quantile regression. Basically, I wanted to do the numerical integration design and implementation by myself. (Except for a few integration rules.) For the optimization and quantile regression I basically used Waterfall + AI-agents with lots of do-it-by-hand experiments in order to convince myself that the 12:51
packages provide something useful.
Voldenet Heh, it's okay if dealer of stolen goods is rich enough, because they're doing this for the love of the game, not money :> 13:00
disbot <antononcube> BTW, there is a project called Woxi that did/does to Wolfram Language what Rakupp is doing to Raku.
<antononcube> @Voldenet I am not sure it is that simple. For many of these LLM-tech-bros in USA and USA government working on AI is existentially important. 13:02
<antononcube> A week ago I read some estimate that 50% of the USA stocks are in AI companies. 13:03
lizmat
.oO( too big to fail )
 13:04
disbot <antononcube> And Elon Musk and some politician had a live talk about tightening our belts and getting more energy and data centers around. 13:05
<antononcube> @lizmat This might be the good news. If those companies fall they will some sort of an AI-winter or AI-autumn. 13:06
<aruniecrisps> I’m almost positive that the AI bubble will burst within the next several months or within the next year
<antononcube> *there will be...
<aruniecrisps> Anthropic openly just said that they may not turn a profit for shareholders in their S1, which say what you will about Wall Street, that’s a step too far even for them I think 13:08
Voldenet AI works and if you ask whether it's probably cheaper than human, then yes (even if you consider huge datacenter costs)… 13:09
however, it simply may not be as profitable as some people think 13:10
disbot <aruniecrisps> I mean, i guess it depends on your definition of ‘works’. I use LLMs daily, and even then it’s produced code that I wouldn’t write, like needless for loops for search when we could just search the most recent element returned by an API 13:12
<aruniecrisps> My experience is that it produces code that is good enough to create a demo for SaaS apps to leadership 13:13
lizmat reminds me of a time when a competitor was stealing a good client from my company: the site looked great, just died if it had more than 1 request / second 13:15
and it was already doing 50/second at that time 13:16
Voldenet Heh, if you expect LLMs to write working products from scratch, you'd be surprised :P 13:20
but it's good at writing code
lizmat
.oO( and lots of it )
 13:21
Voldenet A lots it is, I really have to curb its enthusiasm
but apart from that, you can ask for refactors you wouldn't dare doing before, because it's so much effort
disbot <antononcube> Yeah. This my next "big project" -- to refactor "JavaScripdt::D3" using LLMs. 13:22
Voldenet I think the braindead refactors are the most difficult kind for humans, great for AI 13:23
because it is moderately vigilant
so I think thanks to AI my codebases will look better…
disbot <antononcube> That package, "JavaScripdt::D3" has lots of JavaScript snippets that are spliced together by Raku subs. It is probably wrong in many places (because of my understanding of JavaScript and D3) but it is also cumbersome to extend, at this point. Refactoring it with an AI-agent seems very promissing. 13:25
<antononcube> I have a few package names questions. Recently, I published the package "COIN-OR" that interfaces Raku to the optimization / operations research library COIN-OR. I did not name it "COIN-OR::Client" because I think/thought that COIN-OR is known well enough. 13:28
<antononcube> Do you think "COIN-OR::Client" would have been a better name? 13:29
<antononcube> I plan to make some other interface packages soon for Gurobi and Woxi. For those, I am 80% sure I will use the "::Client" suffix. 13:30
13:45 belluzj joined
Voldenet wouldn't ::Client suggest it's http thing? 14:04
or at least tcp
disbot <antononcube> Yeah, I guess. 14:10
<antononcube> I am not sure what is the convention in the Raku community about these kind of packages.
<antononcube> I see Brian Duggan uses just the name of the corresponding software component, like, "Duckie". 14:12
<antononcube> ... or "GEOS". 14:13
<antononcube> @Voldenet To your point "H2O::Client" does use the web API by H20. 14:15
[Coke] I assume not GEOS the operating system from 1986? 14:18
(ah, high school)
Voldenet geos is probably this libgeos.org/ 14:38
15:59 belluzj left, swaggboi left 16:07 stanrifkin joined 16:17 swaggboi joined 16:19 stanrifkin left 16:37 scott2 left 16:39 scott2 joined 16:46 lizmat left 16:47 lizmat joined 17:35 stanrifkin joined 18:26 stanrifkin left 18:57 stanrifkin joined 19:02 human-blip left 19:04 human-blip joined 19:11 swaggboi left 19:24 swaggboi joined 19:34 stanrifkin left
guifa antononcube: I definitely use a range of AI systems at work, but mainly for things that I already fully understand and could supervise on. Basically treat it like a pack of interns 21:02
but also I'm creating random resources like worksheets for students 21:03
for this, beyond the copyright question, I want to handroll it to personally get a better understandig of how it all works 21:05
21:08 atcroft left 22:33 Sgeo joined 22:46 atcroft joined 23:06 atcroft left 23:31 atcroft joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!