00:38 deoac joined 00:42 jargan is now known as jast 00:51 sourceable6__ left, sourceable6 joined 01:19 kst joined 02:27 hulk joined 02:28 kylese left 03:13 patrickb left, patrickb joined 03:15 hulk left, kylese joined 04:33 hvxgr left, hvxgr joined 05:10 ugexe left, ugexe joined 05:12 peder left 05:14 peder joined 05:17 Aedil joined 05:39 sibl joined 06:32 jedesa joined, jedesa left 07:32 cryosis left 07:50 Aedil left 07:53 Sgeo left 10:14 linkable6 left 10:15 linkable6 joined 10:42 unicodable6 left, unicodable6 joined 11:04 [Coke] left, [Coke] joined 11:47 inspork left 11:48 inspork_ joined, inspork_ is now known as inspork
lizmat . 12:12
12:23 Guest61 joined 12:24 Guest61 left 12:30 cryosis joined 12:35 jcallen left 12:36 jcallen joined 13:56 sibl left
lizmat weekly: dev.to/lizmat/raku-resolutions-3-3j6m 14:25
notable6 lizmat, Noted! (weekly)
14:31 elcaro left, elcaro joined 14:50 ShimmerFairy left, ShimmerFairy joined 14:51 hulk joined 14:53 kylese left 15:30 xinming left 15:32 xinming joined, Aedil joined
[Coke] oh, that was yesterday?! oops. :( 15:46
I do not have a great track record here.
16:15 [Coke] left 16:45 Sgeo joined 17:34 lucs left
SmokeMachine Instead of :no-backtrace, would it make more sense to be :!backtrace? 17:48
17:52 wayland joined, wayland76 left
ugexe that stuck out to me as well, but ultimately i don't like the parameter idea since it also doesn't do anything if you pass an exception object 17:53
lizmat well, the problem solving issue was about: die "foo" 17:55
I mean, could make it with an exception as well, but that would be outside of the scope of the issue 17:56
ugexe yeah i understand that. however that doesn't mean any solution shouldn't consider things hollistically
lizmat the :!backtrace I can work with :-)
ugexe i was ok with the parameter on first glance, but now im not. i think the new exception object, while not ideal either, would be a more consistent / comprehendable api 17:57
by not ok with it i mean its not something i would suggest or implement. not that i would reject the PR 17:58
more generally though i'm trying to think as a library author, and if i should be on control of when consumers of my library get a backtrace 18:01
so in some sense i feel like the ultimate end consumer of the library should be determining when backtraces get printed 18:03
lizmat so, what I was going for was a CATCHable alternative to: note "foo"; exit 1
ugexe right but then a consumer has to know they need to catch those types of exceptions if they want backtraces for those pieces of code 18:08
18:09 [Coke] joined
ugexe as an end user writing scripts i can understanding wanting `die` to not include stack traces sometimes (probably most of the time). as a library consumer i don't want the library author to control when i can get backtraces without explicitly asking for them (and thus knowing i need to in the first place). these two use cases are in conflict 18:10
lizmat hmmm... changing :$no-backtrace to :$backtrace appears to trigger some infiniloop :-( 18:34
18:39 lucs joined
ugexe presumably you have some clash with the backtrace method 18:39
m: say X::AdHoc.new.backtrace
camelia Nil 18:40
18:41 lucs left
ugexe the pre-existence of the backtrace method also suggests these parameter names arent good 18:42
the backtrace still exist
so having a flag on x::adhoc to not have a backtrace really means to not "print" a backtrace 18:43
this is confusing
i guess in that PR it does actually remove the backtrace. i don't think that is the correct thing to do 18:48
the backtrace should always be on the exception object. the use case that was asked is only about not printing the backtrace 18:49
lizmat the problem is that it's very hard to stop the backtrace from being generated without a SORRY
it's quite a bit of a mess there... ;-(
ugexe it is possible that it is too hard to DTRT. if that is the case i'm not sure we'd want to sort-of DTRT instead vs what we have now which does allow this behavior with slightly added verbosity 18:51
For this parameter route I think at a minimum it needs to 1) be renamed to like `print-backtrace` or some such, and 2) the backtrace stays on the exception object. That being said I'm still not sure how acceptable I personally find that 18:55
lizmat ok, not going to touch the PR for a while :-) 19:00
19:05 lucs joined
lizmat for our friends on Discord: www.therage.co/persona-age-verification/ 20:12
20:31 Aedil left 21:45 wayland left 22:20 El_Che left 22:21 El_Che joined