| --- Log opened Mon Mar 12 00:00:41 2018 |
| 00:12 | <@macdjord> | [R]: True, but markup supports bold sections longer than one word. |
| 00:14 | <&[R]> | Right |
| 00:15 | <&[R]> | What kind of footnotes is going to have that problem though? |
| 00:19 | <@macdjord> | [R]: How about "Remember, the big red button triggers the emergency shutdown, *so anyone who touches it* will be fired* (* Footnote: Except in an actual emergency, of course.)" |
| 00:19 | <@macdjord> | Intended behaviour: Bold section running from 'so' to 'fired'. |
| 00:20 | <@macdjord> | Actual behaviour: Bold ends at 'it'. |
| 00:22 | <@macdjord> | There's also the fact that, if I had omitted the space between the asterisk and the word 'footnote', that could incorrectly be processed as the start of a bold section. |
| 00:24 | <&[R]> | Honestly, I mentally parsed that exactly how markdown would've |
| 00:24 | <&[R]> | IMO that's just poor communication, IE garbage in. |
| 00:26 | <&McMartin> | Humans bend themselves to the shape of their tools |
| 00:26 | <&[R]> | I haven't actually used markdown in several years now TBH |
| 00:31 | <@macdjord> | [R]: It's bad communication /if it's someone writing plaintext and using asterisks for emphasis/. It's a flaw in the markup when someone writes text with a footnote in it and it breaks their formatting. |
| 00:35 | < Mahal> | I'd like to point out that that sentence is perfectly valid parsed either way |
| 00:35 | < Mahal> | ANYONE WHO TOUCHES IT will be fired (except in an actual emergency) |
| 00:35 | < Mahal> | or |
| 00:35 | <&[R]> | Also generally, asterisk footnotes are at the end of a sentence. |
| 00:35 | < Mahal> | ANYONE WHO TOUCHES IT (except in an actual emergency) WILL BE FIRED |
| 00:35 | < Mahal> | those are both grammatically valid, and similar in meaning, sentences. |
| 00:36 | <&[R]> | But I haven't seen the footnote on the same line as the expansion in any text I can recall. |
| 00:41 | <@macdjord> | Mahal: Again, that's something the writer would have to consider if they're using asterisk both to indicate emphasis and to flag a footnote. It is not something they should have to consider because the markup language designer picked a string feature which already appears commonly in unemphasized text to indicate a processing directive. |
| 00:42 | <@macdjord> | [R]: Footnotes mid-sentence are common enough. To explain a word of phrase, for example. |
| 00:43 | <@celticminstrel> | Should be easy to tell the difference between a bold run and a footnote, provided the footnote doesn't appear in a bold run (like in your example >_> ) |
| 00:43 | < Mahal> | macdjord: my point is purely that yes, the writer needs to consider emphasis vs footnotes |
| 00:43 | < Mahal> | because otherwise they can change the meaning of their sentences through inattention |
| 00:47 | <&[R]> | macdjord: asterisk footnotes were explicitly specified here |
| 00:48 | <@macdjord> | celticminstrel: For a human, yes. But another example: "The pointer *foo indicates the bar structure* for the current baz operation (* See section B for an explanation of bar structures)". There's /no/ intended bold in there, but markup would see some. |
| 00:49 | <@macdjord> | [R]: ? I never said anything about non-asterisk footnotes. |
| 00:49 | <&[R]> | <macdjord> [R]: Footnotes mid-sentence are common enough. To explain a word of phrase, for example. |
| 00:49 | <@celticminstrel> | Hmm, that's a weird example though. |
| 00:49 | <&[R]> | Numeric footnotes appear generally anywhere |
| 00:53 | <@macdjord> | [R]: Uh, that's not been my experience. Both numeric and symbolic footnotes are more common at the end of a sentence than the middle, but the ratio is about the same for both in my experience. |
| 00:58 | | Kindamoody is now known as Kindamoody[zZz] |
| 01:21 | <&[R]> | I git add'd a file, how do I see the diff of it's current state and the last revision? |
| 01:22 | <&[R]> | nm |
| 01:22 | <&[R]> | git diff HEAD file |
| 01:31 | <&ToxicFrog> | [R]: note a subtle difference here: `git diff <rev> -- FILE` shows you the state of FILE in the working copy vs <rev> |
| 01:31 | <&ToxicFrog> | `git diff --cached <rev> -- FILE` shows you the state of FILE in the index vs <rev> |
| 01:32 | <&ToxicFrog> | Ff you just `git added` it, "in the index" and "in the working tree" are the same thing, but if you added it and then did some more edits, without `--cached` it'll show you the diff with those extra edits. |
| 01:34 | | * McMartin struggles a bit but finally manages to get sprites working on the Genesis. |
| 01:34 | <&[R]> | Working copy vs index means what exactly? |
| 01:34 | | * [R] isn't 100% on all the terminology |
| 01:41 | <@macdjord> | [R]: Working copy is 'file as currently exists on disk'; index is 'file as it was when you did `git add`'. |
| 01:42 | <&[R]> | Thank you kindly |
| 01:53 | <&ToxicFrog> | Yeah. The index is also sometimes called the "staging area" since it's what will get committed if you do "git commit". |
| 03:00 | <&[R]> | "This approach has lead to an incredible amount of badly code around the world. " |
| 04:28 | | Derakon is now known as Derakon[AFK] |
| 04:30 | <&[R]> | I'm writting a C client/server application (it does both at once, just so we're clear). Is select() still the thing I want to use to deal with multiple sockets? |
| 05:46 | <&McMartin> | afaik yes |
| 05:54 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has quit [[NS] Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] |
| 06:07 | | celticminstrel [celticminst@Nightstar-gil1m1.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 06:18 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 06:18 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 06:24 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 06:30 | | macdjord is now known as macdjord|slep |
| 06:50 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 06:50 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 07:31 | | Kindamoody[zZz] is now known as Kindamoody |
| 07:44 | | Kindamoody is now known as Kindamoody|afk |
| 11:04 | | Degi [Degi@Nightstar-ve55hn.dyn.telefonica.de] has joined #code |
| 12:14 | < simon_> | is Data.List.sort neat enough for sorting three elements? I can see that it isn't a hybrid linear sort for smaller lists like e.g. Java's. |
| 12:14 | < simon_> | (this is Haskell.) |
| 12:14 | | Degi_ [Degi@Nightstar-l60cpt.dyn.telefonica.de] has joined #code |
| 12:17 | | Degi [Degi@Nightstar-ve55hn.dyn.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 12:19 | | Degi_ [Degi@Nightstar-l60cpt.dyn.telefonica.de] has quit [Connection closed] |
| 13:50 | | Vornlicious [Vorn@Nightstar-mb2qoc.sub-174-210-19.myvzw.com] has joined #code |
| 13:52 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 14:30 | <@Pi> | simon_: The (linked) list based sorts are probably fundamentally different to array-based sorts, in terms of performance comparisons. |
| 14:30 | <@Pi> | It probably doesn't make much sense to compare their internal details too closely. |
| 14:34 | <@Pi> | If I'm not mistaken, GHC's Data.List.sort is a relatively standard (?) merge sort, while Java uses the array-based TimSort. |
| 14:55 | | Vornlicious [Vorn@Nightstar-mb2qoc.sub-174-210-19.myvzw.com] has quit [[NS] Quit: Bye] |
| 14:55 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 15:06 | < simon_> | Pi, yep |
| 15:06 | < simon_> | Pi, someone suggested I was doing premature optimization. |
| 15:07 | <@Pi> | What are you doing? |
| 15:08 | < simon_> | ummm, answering newbie StackOverflow questions instead of working. :D |
| 15:08 | <@Pi> | Is that the premature optimization. :) |
| 15:08 | <@Pi> | ? |
| 15:09 | < simon_> | https://stackoverflow.com/questions/49231996/how-to-remove-second-largest-element-in-a-list-in-haskell/49235121#49235121 -- the premature optimization would be some if-then-else'ing or min/max'ing instead of calling sort. |
| 15:11 | < simon_> | whoops, I spotted a bug. |
| 15:14 | <@Pi> | The naive solutions of finding and filtering out the maximums are probably best there. |
| 15:15 | <@Pi> | They're all asymptotically O(N); sorting is probably not helping anything here. |
| 15:17 | <~Vornicus> | THere's quicksort-like algorithms that return any rank/quantile from a list in O(N) time |
| 15:17 | < simon_> | Vornicus, yeah, I was dead fascinated by that when I had algorithms. |
| 15:18 | <@Pi> | Heap sort can do that, but it's probably overkill in this case, unless you're doing something like trying to optimise for a large K-of-N removals. |
| 15:18 | <@Pi> | For small K of 1 or 2, it probably doesn't help anything. |
| 15:21 | <~Vornicus> | I keep seeing people use `filter (/= maximum xs) xs` |
| 15:21 | < simon_> | Pi, yeah, okay. I'm not sure why I went and complicated it. now it's simpler. |
| 15:22 | <~Vornicus> | I'm gonna be a grumpy grognard and point out that this will remove many elements instead of just one in the case of ties |
| 15:22 | < simon_> | Vornicus, where do you keep seeing that? |
| 15:22 | <~Vornicus> | It's in yours |
| 15:22 | < simon_> | Vornicus, I'm assuming he wants all occurrences of biggest elements removed. |
| 15:24 | < simon_> | Vornicus, but what I'm forgetting, now that I think of it, is that if the elements of xs are only partially ordered, it will only remove one maximum. but I guess that's at the responsibility of the author of the instance Ord. |
| 15:25 | <~Vornicus> | yes partial ordering is annoying |
| 15:25 | <~Vornicus> | but if you're doing that then you're in trouble anyway |
| 15:29 | | * TheWatcher uughs at this staff member who has a tenuous grip on java and python and he keeps trying to write code that's a mashup of both -_- |
| 15:29 | < simon_> | TheWatcher, Jython! |
| 15:30 | < simon_> | from javax.swing import * |
| 15:31 | <@TheWatcher> | I have been calling it 'javon', but yeah |
| 15:36 | < simon_> | Jython actually exists. |
| 15:37 | | * simon_ is currently dealing with a code pipeline that, in multiple steps, performs regexes on a string containing HTML code. |
| 15:39 | < simon_> | "Is this URL piped through DoubleClick?" becomes $html =~ m!...! and "Has this URL already been rewritten to contain a clickback URL?" becomes $html =~ m!;click=!. for all those who dislike using the DOM as their datatype on front-end javascript work, this is being done in the back-end by Perl code. -_- |
| 16:00 | <@TheWatcher> | hah |
| 16:02 | | Vornlicious [Vorn@Nightstar-mb2qoc.sub-174-210-19.myvzw.com] has joined #code |
| 16:05 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 17:08 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
| 17:25 | | Vornlicious [Vorn@Nightstar-mb2qoc.sub-174-210-19.myvzw.com] has quit [[NS] Quit: Bye] |
| 17:32 | | Vorntastic [Vorn@Nightstar-mb2qoc.sub-174-210-19.myvzw.com] has joined #code |
| 17:51 | <&jeroud> | I keep hoping that once I've written enough Go code I'll start getting some idea of how to build useful abstractions. |
| 17:52 | <&jeroud> | Jython is Python on the JVM, and it's quite horrible unless you specifically want to use Java libraries. |
| 17:53 | <&jeroud> | Then it's even worse, because you need to build Java datastructures in the Java way. |
| 17:55 | <&McMartin> | I find myself wondering if Rob Pike and the Go designers still believe it achieves the goal they had when they started the project |
| 17:55 | <&jeroud> | I'm pretty sure it does. |
| 17:56 | <&jeroud> | Having watched a bunch of Rob Pike keynotes. |
| 17:56 | <&McMartin> | This makes me wonder about what exactly he does with it. |
| 17:56 | <&jeroud> | I also think those are the wrong goals. |
| 17:56 | <&McMartin> | Since ISTR his initial complaint was that he has to write too much boilerplate in other languages to convince the compiler to build his code |
| 17:57 | <&McMartin> | And, well, I have a higher opinion of my Go experience than you do of yours, but we are entirely in accord re: the amount of boilerplate Go requires. |
| 17:57 | <&jeroud> | Ah, but this isn't boilerplate. It's concurrency and error handling! |
| 17:57 | <&McMartin> | and generics and virtual dispatch and |
| 17:58 | <&jeroud> | I'd probably be somewhat less grumpy about it if I weren't also writing a lot of Elixir code, which gets all this stuff exactly right. |
| 17:58 | <&McMartin> | Meanwhile, I've been writing a lot of C code, which... produces similar delusions and that's why I'm wondering what he thinks. |
| 17:59 | <&McMartin> | (It seems to be a very common experience to go from a large-application-scale language down to C and feeling like an enormous weight has been lifted from one's shoulders.) |
| 17:59 | <&jeroud> | There's a bunch of good stuff about how to build sensible error handling machinery. |
| 17:59 | <&McMartin> | (This is at least in part because the fact that you have gone down to C means you are now attacking smaller problems) |
| 18:00 | <&McMartin> | (But also at least in part because C++ in particular is drowning in the unfortunate implications of its own core abstractions) |
| 18:01 | <&jeroud> | For a stdlib example of that sort of thing, looks at bufio.Scanner or whatever it's called. |
| 18:02 | <&jeroud> | But that only applies to certain kinds of code structures. |
| 18:02 | | Vornlicious [Vorn@Nightstar-is868d.sub-97-46-132.myvzw.com] has joined #code |
| 18:03 | <&jeroud> | I couldn't apply it to the exercism problem I fought with yesterday, which was about parsing a matrix of integers out of a string. |
| 18:03 | | Vorntastic [Vorn@Nightstar-mb2qoc.sub-174-210-19.myvzw.com] has quit [Ping timeout: 121 seconds] |
| 18:04 | | Vornlicious [Vorn@Nightstar-is868d.sub-97-46-132.myvzw.com] has quit [[NS] Quit: Bye] |
| 18:04 | | Vorntastic [Vorn@Nightstar-1l3nul.res.rr.com] has joined #code |
| 18:06 | <&jeroud> | Because that would have cleaned up the call site by moving all the actual code into a bunch of messy methods on a structure that exists only to collect and check the errors. |
| 18:06 | <&McMartin> | "exercism"? |
| 18:06 | <&jeroud> | Rather than a single-responsibility abstraction. |
| 18:06 | <&jeroud> | exercism.io |
| 18:06 | <&McMartin> | Aha |
| 18:07 | <&McMartin> | To be clear: you are talking about Go here and not Elixir - the closest thing to bufio.Scanner I am finding are the routines in the IO module and those seem to use a flexibly-structured version of "Eiher" |
| 18:07 | <&McMartin> | *Either |
| 18:08 | <&jeroud> | iobuf, maybe? |
| 18:09 | <&jeroud> | https://golang.org/pkg/bufio/#Scanner |
| 18:09 | <&jeroud> | That one. |
| 18:12 | <&McMartin> | Ah yes |
| 18:13 | <&McMartin> | How strict are Elixir's alternatives? |
| 18:13 | <&McMartin> | (In particular, can the compiler tell that you have failed to match a possible return case?) |
| 18:13 | <&jeroud> | Elixir (like Erlang) is very dynamically typed. |
| 18:14 | <&McMartin> | That is not quite what I was asking. |
| 18:14 | <&jeroud> | But dialyzer (the static analysis tool) finds places where you're not matching different return values. |
| 18:14 | <&McMartin> | Yeah. |
| 18:15 | <&McMartin> | What I was seeing from the Elixir docs, assuming that I was reading them correctly, was that signatures were being specified/documented in a way that it could tell what you were doing. |
| 18:15 | <&jeroud> | Assuming you have typespecs, which most released code does. |
| 18:16 | <&McMartin> | And any case where there is a return statement that does not trivially match said typespec is presumably also a code smell at least and a detectable warning at worst |
| 18:16 | <&McMartin> | Even if that's technically a drop in power the same way "never use mutable strings as your format strings" is. |
| 18:16 | <&jeroud> | https://github.com/praekeltfoundation/relay/blob/master/lib/log_wrapper.ex |
| 18:18 | <&jeroud> | That's some code I wrote last week to make the bloody tool shut up about the return value of logging calls that I explicitly do not care about. |
| 18:18 | <&McMartin> | I'm looking at the stuff like https://hexdocs.pm/elixir/IO.html#binread/2 |
| 18:18 | <&McMartin> | The second line there looks like a deduced type specification. |
| 18:19 | <&jeroud> | That's from the typespec annotation. |
| 18:21 | <&jeroud> | The standard in Elixir is to return {:ok, result} or {:error, reason}, and then most callers pattern-match on the {:ok, result} tuple and let the process crash with a match error otherwise. |
| 18:22 | <&jeroud> | But if you care, you shove it in a case expression to match other responses as well. |
| 18:22 | <&McMartin> | That is a relatively direct translation of the Either alternative I mentioned above. |
| 18:23 | <&McMartin> | (Or Rust's Result<T,E>, which is a more direct and self-describing version) |
| 18:23 | <&McMartin> | (Since Either is Left/Right and one of them is dedicated for success in a way that is necessary for monadic composition to work but I never remember offhand which is which) |
| 18:23 | <&jeroud> | Yeah, this is kind of a poor-man's option type made out of tuples and pattern matching. |
| 18:24 | <&McMartin> | Yep, which feels similar to my experiences writing this sort of code in Lisp |
| 18:24 | <&McMartin> | And matching on :ok to get the result out does produce the desired effect of automating the error check. |
| 18:25 | <&jeroud> | That works really well in Elixir/Erlang because matching only the success case is a runtime error instead of a failure to compile. |
| 18:25 | <&McMartin> | Yeah. |
| 18:25 | <&McMartin> | Note that Rust lets you do the same thing with .unwrap() |
| 18:25 | <&McMartin> | Which is a match and return of wrapped success type or panic as needed |
| 18:26 | <&McMartin> | But the Rust community frowns on actually using it in production code because they frown on panics |
| 18:26 | <&jeroud> | And the runtime system is explicitly designed around supervision trees of processes that crash if they get unhappy. |
| 18:26 | <&McMartin> | That is an important additional qualification, yes. |
| 18:27 | <&jeroud> | In Rust, it crashes your program. In Erlang, the nearest supervisor shrugs and spawns a replacement process to try again. |
| 18:29 | <&jeroud> | So you get a really nice balance between local error handling where it makes sense and bailing out completely for someone else to deal with the problem. |
| 18:29 | <&jeroud> | I typed "catch" into an Elixir program for the first time ever today. |
| 18:30 | <&jeroud> | I have no plans to type "rescue" into any Elixir programs. |
| 18:31 | <&jeroud> | Oddly, Erlang/Elixir has throw/catch for nonlocal flow control and raise/rescue for exception handling. |
| 18:31 | <&jeroud> | And neither of them are used to any meaningful degree. |
| 18:32 | <&McMartin> | nonlocal flow control feels like a very systems-level thing to want. |
| 18:32 | <&McMartin> | Which is ironic because it fits very uneasily with systems-level programming disciplines. |
| 18:32 | <&jeroud> | Because instead of bothering with that shit, you just crash and let your supervisor worry about what to do. |
| 18:33 | <&jeroud> | I don't really know what either of those "exception" mechanisms are really used for. |
| 18:34 | <&McMartin> | Does Elixir have a notion of Lisp's unwind-protect or some exception systems's "finally"? |
| 18:35 | <&jeroud> | That codebase I linked a snippet of above raises ArgumentError occasionally because the stack trace is nicer to read than a failure to find a matching function clause. |
| 18:35 | <&jeroud> | Yes, but I forget the precise syntax. |
| 18:36 | <&McMartin> | This is in fact one of the things that soured me on exceptions as an actual thing that gain you anything |
| 18:36 | <&jeroud> | I want to say "after", but I think that's a timeout on a receive expression. |
| 18:36 | <&McMartin> | Anything delicate enough that you have to worry about exceptional conditions will *also* be delicate enough that you will need to Do Something to restore the system to a stable state on the way out |
| 18:37 | <&McMartin> | Which means that they aren't actually nonlocal at all! It's a return followed by an if-goto. |
| 18:37 | <&McMartin> | Which is also what pattern-matching results are |
| 18:37 | <&jeroud> | Yeah, that's the fundamental underlying principle of Erlang. If you get in a weird state, throw everything into the furnace and start fresh. |
| 18:37 | <&McMartin> | Well |
| 18:38 | <&McMartin> | That implies a model where "everything can be thrown into the furnace" and that it is feasible to do a generic reset, yes |
| 18:38 | <&McMartin> | This is... not true on the systems I play in :) |
| 18:38 | <&jeroud> | How much that "everything" covers depends how deep in the supervision hierarchy you are. |
| 18:38 | <&McMartin> | "I/O device state" is the one I think of where this is usually not feasible. |
| 18:39 | <&McMartin> | The driver's job is to make sure that when it's told "OK, context X no longer makes sense" that the device is OK with that. |
| 18:40 | <&jeroud> | So for my HTTP SSE client thing, any kind of connection error (timeout, peer reset, whatever) is "throw the whole client process in the furnace" and the supervisor starts a new one. |
| 18:40 | <&jeroud> | For that low-level interaction with stateful devices and such, you use a different approach. |
| 18:40 | <&McMartin> | Right |
| 18:41 | <&McMartin> | What I'm saying is that exceptions are used to do that low-level interaction with stateful devices and that it is wrong to do so. |
| 18:41 | <&jeroud> | Yeah, I agree with that. |
| 18:41 | <&McMartin> | I seem to be in broad company on that one |
| 18:42 | <&jeroud> | But you don't write device drivers in Erlang or Python or Java. |
| 18:42 | <&McMartin> | But you *do* occasionally do so in C++. |
| 18:42 | <&McMartin> | I'm in less broad but better company with the further claim "compiler-enforced checking of error codes a la Rust using the ML-like enum syntax" |
| 18:42 | <&McMartin> | is the right way to handle said low-level stuff |
| 18:43 | <&jeroud> | Erlang has "ports", which I'm not entirely clear on, but which appear to be the "outside world" abstraction. |
| 18:43 | <&McMartin> | Also, Java maintains stateful connections that get in a bad state without carefully structured finally blocks all the time, particularly in the space of network and database connections |
| 18:44 | <&jeroud> | At the level of "database connection" I think a certain amount of throwing in fires is reasonable. |
| 18:44 | <&McMartin> | Oh yes, and that's exactly the thing Java isn't doing that is the problem |
| 18:44 | <&McMartin> | BEAM knows enough about how to reset that when a client dies the database connections are closed and its resources freed |
| 18:45 | <&McMartin> | That's part of the implementation of fire inthrowing. |
| 18:45 | <&McMartin> | Java ends up with zombie connections because finalizers don't run at any predictable or useful time or indeed maybe not at all. |
| 18:45 | <&McMartin> | It's a nondeterministic leak. |
| 18:46 | <&jeroud> | That's what ports are for. |
| 18:47 | <&jeroud> | IIRC, a port is owned by a particular process, and when that process exits the port gets cleaned up. |
| 18:47 | <&jeroud> | However! This is not guaranteed to happen immediately. |
| 18:48 | <&McMartin> | For these cases "immediately" isn't necessary but "soon" is. |
| 18:48 | <&jeroud> | Which is why I have an annoying amount of code for dealing with EADDRINUSE. |
| 18:51 | <&jeroud> | Fun fact: supervisors don't retry child processes that fail to start, only child processes that crash after successfully starting. |
| 19:01 | <&jeroud> | I suspect that cleanup is driven by the GC. |
| 19:02 | | * McMartin nods |
| 19:02 | <&McMartin> | Can rescue attempts fail? |
| 19:02 | <&jeroud> | Which Java people are always obsessed with, but I don't think I've ever seen any discussion of in an Erlang/Elixir context beyond "yeah, we have one of those". |
| 19:03 | <&jeroud> | Rescue as in catching exceptions? |
| 19:03 | <&McMartin> | Right |
| 19:03 | <&jeroud> | Not unless you catch the wrong one. |
| 19:03 | <&McMartin> | Mmm |
| 19:03 | <&McMartin> | Rescue + Reraise gives you unwind protect for free |
| 19:03 | <&jeroud> | It's possible for your process to be murdered in the face without any notice. |
| 19:06 | <&jeroud> | https://elixir-lang.org/getting-started/try-catch-and-rescue.html has all the Elixir error/exception/whatever stuff. |
| 19:07 | <&jeroud> | "after" is the equivalent of "finally". |
| 19:07 | <&McMartin> | Okay |
| 19:07 | <&jeroud> | You can also apply it directly to a function clause. |
| 19:07 | <&McMartin> | If you can use an after to attempt shutdown on your way to crashing, that means you can get precise destructors/freeing of resources |
| 19:08 | <&jeroud> | So def/after/end. |
| 19:08 | <&McMartin> | But that doesn't, as you note, mean you don't still have to handle all those EADDRINUSE things |
| 19:08 | <&McMartin> | It will mean they happen *less*, though, and if it's a performance issue that may matter |
| 19:08 | <&jeroud> | That sort of thing won't protect you from kill signals. |
| 19:09 | <&McMartin> | That's not what you're defending against. |
| 19:09 | <&McMartin> | You're defending against any crash that comes from inside you. |
| 19:09 | <&McMartin> | The fact that this defense is incomplete is why it does not make your code smaller, but instead larger. |
| 19:09 | <&jeroud> | But your process can trap exits and receive the kill (which includes unrescued errors from your own code) as a message. |
| 19:09 | <&McMartin> | So you would only do this if you were being somehow impeded by late cleanup enough to impact the system as a whole |
| 19:10 | <&jeroud> | And the GenServer machinery uses this in its dispatch loop to invoke the terminate callback. |
| 19:11 | <&jeroud> | If the process that owned the listening socket belonged to me, that's what I'd do. |
| 19:12 | <&jeroud> | But in my case it's buried in a transitive dependency written in Erlang. |
| 19:13 | <&jeroud> | There's also a different issue, which is that even when you clean up properly the kernel may not release the port immediately in some operating systems. |
| 19:14 | <&jeroud> | Which is a much shorter race, but it's still possible to hit that sometimes. |
| 19:15 | <&jeroud> | Of course, in the real world I don't really care about this. |
| 19:15 | <&McMartin> | Yeah |
| 19:15 | <&McMartin> | In Java, the "won't clean up immediately" can be "minutes to hours" |
| 19:16 | <&McMartin> | In DOS, it can be "not even when the process exits, reboot the whole machine" |
| 19:17 | <&jeroud> | Because I'm not starting and stopping the guts of my program to test that the supervision tree is applying the appropriate restart strategies. |
| 19:20 | <&jeroud> | I'd just do this testing on random high ports if I could, but the library doesn't give me a way to get the port if I listen on 0 |
| 19:22 | <&jeroud> | And I don't really want to roll my own gRPC server. |
| 19:42 | | Degi [Degi@Nightstar-l60cpt.dyn.telefonica.de] has joined #code |
| 20:15 | <@Alek> | heh. it's funny to see what seems to be weed slang in code talk. |
| 20:15 | <&McMartin> | There was a fair amount of overlap for some time |
| 20:15 | <&McMartin> | Though it's also an old enough phrase it may even mean tobacco. |
| 20:27 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has joined #code |
| 20:27 | | mode/#code [+o Reiv] by ChanServ |
| 20:29 | <@gnolam> | Alek: ? |
| 20:29 | <&McMartin> | 12:22 <&jeroud> And I don't really want to roll my own gRPC server. |
| 20:33 | | Vornicus [Vorn@Nightstar-1l3nul.res.rr.com] has quit [Ping timeout: 121 seconds] |
| 20:51 | <&jeroud> | Yeah, definitely a tobacco reference. |
| 20:52 | <&jeroud> | There aren't many places where one can buy a carton of machine-rolled spliffs. |
| 21:34 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 21:40 | <@Alek> | well, it's weed culture now. :P |
| 21:40 | <@Alek> | but yeah, gotcha. tobacco. |
| 21:41 | <@Alek> | weed culture kept all those tobacco accessories alive, even as older smokers who rolled their own kept dying out, I believe. |
| 21:42 | <@Alek> | not to mention some who mix weed and tobacco in their spliffs and possibly bongs and hookahs, I gather. |
| 21:43 | <@Alek> | yes, I do read a lot. people add in details they know when they write stories. >_> |
| 22:03 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Ping timeout: 121 seconds] |
| 22:06 | | Degi [Degi@Nightstar-l60cpt.dyn.telefonica.de] has quit [Connection closed] |
| 22:13 | | Kindamoody|afk is now known as Kindamoody |
| 23:10 | | himi [sjjf@Nightstar-1drtbs.anu.edu.au] has joined #code |
| 23:10 | | mode/#code [+o himi] by ChanServ |
| 23:44 | | Kindamoody is now known as Kindamoody[zZz] |
| 23:51 | | celticminstrel [celticminst@Nightstar-gil1m1.dsl.bell.ca] has joined #code |
| 23:51 | | mode/#code [+o celticminstrel] by ChanServ |
| --- Log closed Tue Mar 13 00:00:43 2018 |