<adam12>
leah2: I don't see why you couldn't have it again if you wanted it (tho I wouldn't be the one making the decision on that; maybe havenwood or jhass[m]).
<leah2>
oh, i'm not so active anymore, and i dont think we need it
<adam12>
I wonder how ubiquitous the history support in readline is.
<leah2>
i never use interactive mode, but sounds reasonable
<leah2>
my shell already has history :p
<adam12>
I like using it to explore. Maybe digging around in Sequel#Dataset or something.
analogsalad has quit [Quit: bye]
aximik[m] has quit [Quit: You have been kicked for being idle]
fef has joined #ruby
* mooff
slaps the +c inventor around a bit with a large trout
a7tism has joined #ruby
sgnh has quit [Ping timeout: 250 seconds]
sgnh has joined #ruby
ule_ is now known as ule
ule has quit [Changing host]
ule has joined #ruby
sgnh has quit [Ping timeout: 256 seconds]
sgnh has joined #ruby
sgnh has quit [Ping timeout: 256 seconds]
bluedust has quit [Remote host closed the connection]
sgnh has joined #ruby
<ox1eef>
i think that's the first time i saw syntax highlighted code on IRC.
Bounga has quit [Ping timeout: 250 seconds]
mahlon has joined #ruby
antos has joined #ruby
antos has quit [Quit: Leaving]
<Sheilong>
arithmetic expressions in Ruby are always evaluated from the left to the right? For instance the expression "1/2 * 1 * 2 * 3 * 4 * 5" evals to 0 because 1/2 is 0; but "5 * 4 * 3 * 2 * 1 * 1/2" evals to 60. Why does it happen? Since * has the same precedence order of * then 1/2 on the right could be evaluated to 0 also.
<wnd>
"1/2" isn't a single component
<wnd>
think (5 * 4 * 3 * 2 * 1) / 2
<adam12>
Would probably need `1/2r`?
<Sheilong>
I just wanted to understand that behavior.
<adam12>
Sheilong: Oh.
<adam12>
Integer / Integer = Integer. You'd need either 1.fdiv(2) or 1 / 2.0
<adam12>
Integer / Integer = Integer. You'd need either 1.fdiv(2) or 1 / 2.0
<Sheilong>
I am a novice in the language, so somethings are not so obvious to me.
<Sheilong>
adam12: Yeah. I meant to to integer division. I just was trying to understand the behavior when you multiply that from right or from the left
<nakilon>
* and / are of the same precedence in any language
BSaboia has quit [Ping timeout: 240 seconds]
<nakilon>
and yeah, usually left to right
<Sheilong>
The language implementation always guarantee that behavior?
ouestbillie has joined #ruby
BSaboia has joined #ruby
<adam12>
500 new gems on gemdocs.org in 2 days... doesn't seem absurd but I'm surprised by the amount.
<leah2>
i thought ruby was dead :p
<leah2>
are they legit updates?
<mooff>
^ does rubygems.org monitor for potential typosquat attacks?
BSaboia has quit [Ping timeout: 250 seconds]
<adam12>
leah2: Looks like it, tho seems a lot are similar packages. dependabot-* and pulp_* and tencentcloud-sdk-* probably make up a hundred or so.
<leah2>
mhm
<adam12>
It's now about ~ 9 GB uncompressed. For 1980 gems, but not including multiple versions which I dont log yet.
<adam12>
I know there are a lot of fans of YARD, but with a better rdoc theme, I wonder if we could do something where docs don't have a mean size of 4MB
<leah2>
put on zfs, enable compression :p
<adam12>
I'm already kinda doing that, but with btrfs.
<leah2>
same, just ensure you have backups /s
<adam12>
So that 9GB is about 1.9GB right now, compressed.
<adam12>
Haha
<leah2>
:)
<adam12>
Yeah, I wouldn't use btrfs if there was more than a single device in this. But I'm actually cheating and using a loopback from a flat file.
<adam12>
Since these are re-generatable docs, I don't care if something goes south.
<leah2>
fair
sgnh has quit [Quit: WeeChat 3.4]
<ox1eef>
i like YARD mostly for the tags.
<ox1eef>
if rdoc added support for those, i might try it again
<ox1eef>
ah, wait.. markdown > rdoc as well.
BSaboia has joined #ruby
<mooff>
should i use Ruby 3 features, or keep the library compatible?
<mooff>
it'd be an easier choice if e.g. mruby, artichoke supported them!
<leah2>
do you really need the features?
<nakilon>
^ this
<leah2>
apparently not because the library exist already :^)
<mooff>
'need' is such a strong word :)
<ox1eef>
you could write ruby in such a way that it'd still work on 1.8.6/7 but you miss out on the language features that make, imho, Ruby better - for the most part. So, as of late, I don't care about anything <2.7
<ox1eef>
On my most recent project, I went straight to Ruby 3.1.
hanzo has quit [Quit: Connection closed for inactivity]
BSaboia has quit [Ping timeout: 256 seconds]
yossarian has quit [Ping timeout: 256 seconds]
BSaboia has joined #ruby
yossarian has joined #ruby
yossarian has quit [Changing host]
yossarian has joined #ruby
<mooff>
i feel that pull too, ox1eef. when 1.9 came out i switched to it immediately. we only cared about MRI at that point, though JRuby etc supported 1.9 stuff fast
<mooff>
now it feels like 2.6/2.7 is the new sort of "ISO" Ruby. explicitly targeted by many implementations with no real urge to 3.0 ify
<mooff>
the 3.x features i want are endless methods and the new "foo(x:, y:)" calling sugar :)
<ox1eef>
i was more excited for 1.9 than any other major bump I remember. If it is a gem, increasing the audience with support across versions would benefit your gem, but if it is your own web app or whatever, i don't see why not 3.1
<mooff>
it's not a gem yet, but when the design stabilises i hope to release it
<ox1eef>
is it a library or what
<mooff>
it's for making modular IRC bots and aims to be simpler than Cinch
<ox1eef>
for libs id recommend supporting at least 2.7 because companies usually cant move as fast as we do
<adam12>
mooff: There's also ruby-next and backports, if you're interested.
<mooff>
i'd been a bit out of the loop leading up to 3.0, and that always struck me as weird. the 'opts' convention was quite nice
<adam12>
It had strange edge cases tho (but what I can't remember currently - there are talks on them). So I enjoyed it too, but the edge cases would get people.
<mooff>
i guess there must have been reasons that backwards incompatibility was preferred. but it's still a little :[
<mooff>
ah yes, cool, adam12
<mooff>
ruby-next does some pretty funky stuff, doesn't it?
<ox1eef>
**opts always feels like an anti-pattern to me, that should just be a hash.
<adam12>
When they introduced kw args in v2, it was a known limitation of how they did it. I guess over time, they decided the breaking change was worth fixing the edge cases.
<adam12>
mooff: Refinements to the extreme :P
<mooff>
ox1eef: if there are optimizations on the table for the foo(bar:, baz:) syntax.. say if the call site and the declaration use kwargs.. couldn't we have that w/o breaking compatibility?
easbarba has quit [Ping timeout: 268 seconds]
<mooff>
adam12: don't tempt me.. refinements were slow, new and scary before, but now that they're well supported i could really go out to lunch using them :P
<mooff>
'off the rails'
<ox1eef>
i don't think there should be **args at all. a hash serves that purpose 100%, right? so why complicate the syntax for this feature.
<mooff>
i don't mind the syntax per-se. it was already supported for calls before, right?
<ox1eef>
afaik it is as old as kw args itself. to me it's just confusing.
<adam12>
mooff: Downside is them not working in an IRB repl, but .. maybe the tradeoffs are worth it :)
<mooff>
ox1eef: i got bit a little not realising we must pass **kwargs too now, *args alone won't suffice.. :(
<mooff>
same with capturing args in a method signature for passing on
<mooff>
adam12: well, ruby-next is surely impressive, but using it with my lib can be left as an exercise for the reader :P
<ox1eef>
i use kw args sparingly, usually like def foo(bar, option: )
<mooff>
did they make it illegal to keep using opts={}?
<mooff>
don't want to get in trouble with the Ruby police :)
<ox1eef>
they're cool but easy to misuse, can end up overly verbose if you use them too much.
<ox1eef>
no, opts={} should still work?
<mooff>
(yeah i'm kidding but it feels wrong to use :))
<ox1eef>
:/
<ox1eef>
why?
<ox1eef>
that's syntax that has been here since the early days
<mooff>
haven't seen opts={} used in new code. though i haven't read a lot of new code..
fef has quit [Ping timeout: 276 seconds]
<mooff>
tend to prefer embracing language changes rather than clinging on
<mooff>
as a side comment, i wish keyword_init: true was the default for Struct's
<ox1eef>
well, you coud replace it with: **opts, it is not exactly the same in terms of syntax but more or less it is a new (and more ugly, imho) way of allowing for optional options
<mooff>
with positional initialization still supported
<ox1eef>
if it's the last arg, yes, from what i understood
<mooff>
ox1eef, well, exactly! :)
<havenwood>
ox1eef: it's on its way to being default
<havenwood>
Matz gave the go ahead, if I recall, but wanted a deprecation warning first.
<havenwood>
oh, it was mooff who said they wished it was default
<mooff>
ooh <3
<mooff>
cool
<ox1eef>
what will be default?
<mooff>
keyword_init for Structs
<ox1eef>
interesting
<mooff>
i hope it is backwards compatible by default
<adam12>
I've already said this but I wish Struct didn't default come with Array and Hash accessors. It breaks Array(struct) which is annoying.
<mooff>
eek. special case it in Array()! :)
<mooff>
refine Object!
<gr33n7007h>
adam12: how does it break?
<havenwood>
I am OK with 3.1 to warn, 3.2 to change. ~Matz
<havenwood>
So keyword_init should be default in 3.2 this Christmas.
<ruby[bot]>
havenwood: I'm terribly sorry, I could not evaluate your code because of an error: JSON::ParserError:A JSON text must at least contain two octets!
<havenwood>
) end; Struct(aim: true, lies: false)
<havenwood>
#=> #<struct aim=true, lies=false>
<mooff>
a pain point for Structs.. is their behavior under code reload
constxd_ has quit [Ping timeout: 256 seconds]
<mooff>
i've started sketching with them then rewritten classes 'long form' twice now for this IRC lib
<mooff>
you either do e.g. User = Struct.new(..); class User, or a similar sleight of hand, but they have downsides
<mooff>
>> true
<ruby[bot]>
mooff: I'm terribly sorry, I could not evaluate your code because of an error: JSON::ParserError:A JSON text must at least contain two octets!
<mooff>
>> {}
<ruby[bot]>
mooff: I'm terribly sorry, I could not evaluate your code because of an error: JSON::ParserError:A JSON text must at least contain two octets!
<havenwood>
mooff: when you say under reload, you mean redefining the constant or something else?
<havenwood>
Like? Point = Struct.new(:x, :y, keyword_init: true) unless defined?(Point)
handsomeGOODm has joined #ruby
<mooff>
havenwood: i'm not worried about redefining the constant, but that we've changed what it refers to
jimeh has quit [Quit: Bridge terminating on SIGTERM]
<mooff>
it's pretty niche, but in the case of this eval bot, say if i add a method to User at runtime, on reload, it will be gone
jimeh has joined #ruby
* mooff
wishes Set implemented pop, shift, unshift
<havenwood>
If the API won't tell you the page count up front, you have to jump through frustrating hoops to make most pagination gems work.
<nakilon>
mindblowing.jpg
<nakilon>
initially I hopes when it's the last page the cursor will be nil, but it fact it's equal to total items count and so it was stuck in the end lol
<nakilon>
*hoped
<havenwood>
hah, yeah, I'm accustomed to `nil` when there's no cursor too
<havenwood>
nakilon: That was actually the sane part of the code. You should see the "ReverseEnumeratorProxy" to share it between Threads, since Enumerator is Fiber backed and can't be resumed across Threads. >.>
<havenwood>
nakilon: ^ then the memoized enumerator doesn't actually make API calls for pages it has seen
<havenwood>
nakilon: I got API cursor-based pagination working in Rails with that ^ and Pagy
<havenwood>
It was a yak shave, and too insane for prod, but good to know we *can*.
<havenwood>
I mean, it works. Fine for prod, but not fine to suggest others to use in prod. :P
<nakilon>
do you mean it does not do API calls when you drop the pages in that snippet?
<havenwood>
nakilon: Yeah, like if you `paginate(page: 2, per_page: 10)` and any of those 10 were already fetched, it won't re-hit the API — it'll start from where it left off.
<nakilon>
like... flat_map create something droppable but does not initialize items unless you ask to?
<nakilon>
ah
<havenwood>
I look forward to Enumerators being sharable between Threads.
<havenwood>
(Assuming they ever will be.)
<havenwood>
The current Fiber-backed implementation is a bit leaky.
<nakilon>
oh crap: HTTP error #403 {"status":11400,"error":"userBlocked","message":"This account has been blocked due to account abnormality detected forever. To unblock please contact us at customer@