| 00:00.44 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 00:08.23 | *** join/#gsoc mihneapc2002 (~smuxi@82.77.78.46) |
| 00:12.14 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 00:16.37 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 00:31.40 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 00:46.41 | *** join/#gsoc LordOfBikes (~armin@dslb-092-075-148-087.092.075.pools.vodafone-ip.de) |
| 00:54.08 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 01:06.58 | r0bby | anth_z: ignored is org wide |
| 01:07.11 | r0bby | I ignore spam proposals and proposals I know are ineligible |
| 01:08.12 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 01:22.12 | r0bby | anth_z: ignore is only available to org admins |
| 01:22.29 | r0bby | I don't remember not being one |
| 01:22.38 | r0bby | Was the case for one year |
| 01:29.58 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 01:48.03 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 01:58.21 | *** join/#gsoc bjorn (quassel@quassel.woboq.de) |
| 01:58.21 | *** join/#gsoc bjorn (quassel@pdpc/supporter/active/bjorn) |
| 01:58.24 | *** join/#gsoc quwex (~quwex@quwex.com) |
| 01:58.59 | *** join/#gsoc dbs (~dan@pdpc/supporter/professional/dbs) |
| 01:59.02 | *** join/#gsoc weltall (~weltall@192.3.160.211) |
| 01:59.24 | *** join/#gsoc janluca (~naumann@Wikimedia/Jan-Luca) |
| 02:12.26 | anth_z | Thanks, both. |
| 02:16.59 | r0bby | anth_z: no problem -- we support each other |
| 02:23.40 | *** join/#gsoc teepee (~teepee@unaffiliated/teepee) |
| 03:31.46 | noam | (insert dramatic "because nobody else will") |
| 03:35.09 | *** join/#gsoc somebpdy (966b0acf@150.107.10.207) |
| 03:37.36 | obviyus | ^^ |
| 03:37.57 | obviyus | r0bby Mc if you don't mind me asking how many proposals did your orgs get? :D |
| 03:38.41 | obviyus | a friend is the admin for a small new org and he received 43 |
| 03:38.43 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 03:38.45 | obviyus | seems super high |
| 03:40.36 | vasanth2 | I thought mentors won't be able to view the final proposals until some days later.. are you able to view the submissions of all students? |
| 03:42.02 | anth_z | vasanth2: Mentors are able to view final proposals as soon as the submission window closed. |
| 03:49.07 | r0bby | anth_z: 12 serious; 15 spam or ineligible(no contact prior or just spammy and unrelated) and 2 Drafts |
| 03:49.28 | r0bby | anth_z: one student knew he wasn't getting in so never finalized |
| 03:50.17 | r0bby | and one student didn't know how to set privacy settings so no access |
| 04:31.18 | *** join/#gsoc souravgopal25 (75d6495d@117.214.73.93) |
| 04:46.20 | valorie | weeeee, we got only two spammy ones |
| 04:46.47 | valorie | about the ignore question -- that's what the ignore button is for |
| 04:47.36 | valorie | at this point, we don't really use it because we move all the students and their proposals into a spreadsheet and do all the sorting there |
| 04:47.50 | valorie | ignoring some would throw the numbers off |
| 04:48.32 | valorie | stars -- each org decides how to use that as well |
| 04:49.11 | valorie | I mean, we got ~20 serious ones, which is low but about what I expected |
| 04:49.37 | valorie | slightly fewer than normal, based on how many questions were asked in IRC |
| 05:16.19 | r0bby | valorie: We had one student who didn't quite understand how GSoC worked |
| 05:16.25 | r0bby | actually 2 of them |
| 05:17.08 | r0bby | One actually annoyed me -- like if you don't understand it, ask questions |
| 05:17.14 | r0bby | or...Read stuff I post |
| 05:27.44 | *** join/#gsoc ricekot (~ricekot@unaffiliated/ricekot) |
| 05:40.12 | mhaeuser[m] | sounds like a good time :D |
| 05:40.31 | *** join/#gsoc asmeurer (~asmeurer@c-174-50-89-15.hsd1.nm.comcast.net) |
| 05:51.43 | *** join/#gsoc ricekot (~ricekot@unaffiliated/ricekot) |
| 05:53.31 | mhaeuser[m] | This is probably the wrong place to ask, but as nothing else is going on, I hope nobody minds. Opinions on Rust? I see it being attempted to be integrated in many places, but often arguments by people are simply wrong, e.g. memory leak provability in Rust vs C. I do realize the compiler ensures safety more internally though. Second thoughts? |
| 06:05.44 | *** join/#gsoc thelounge13 (~thelounge@164.90.213.20) |
| 06:07.49 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 06:08.16 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 06:15.57 | obviyus | mhaeuser[m]: i've been experimenting with Rust quite a bit these days, i feel this is a well written piece talking about introducing Rust to QEMU: https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg00800.html |
| 06:16.36 | obviyus | anecdotally, Rust is the most "fun" i've had programming these last few months :) |
| 06:17.14 | obviyus | having said that, I still use Python/Go for the majority of projects I sometimes work on due to the sheer ease of use |
| 06:22.20 | mhaeuser[m] | obviyus: thanks for the writeup, it's sadly just the typical vague advantages. I'll research this ofc, so this is more if a head-dump rhetoric question, but first thing I wonder when I read "panic() when safety cannot be proven" is wherher it can be disabled or used for static analysis |
| 06:22.52 | mhaeuser[m] | i.e. a kernel, a firmware, an OS, etc must not panic because some memory alloc fails |
| 06:50.49 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 06:52.52 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 07:03.06 | *** join/#gsoc thc202 (~thc202@unaffiliated/thc202) |
| 07:25.57 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 08:20.08 | *** join/#gsoc meflin (~meflin@73.95.135.35) |
| 08:20.08 | *** mode/#gsoc [+o meflin] by ChanServ |
| 09:38.10 | PulkoMandy | mhaeuser[m], I think Rust is not perfect, but anything is better than C. Having said that, I will continue to use C++ wherever I can ð |
| 11:38.51 | *** join/#gsoc Marc (~Marc@phpbb/manager/marc) |
| 12:13.10 | *** join/#gsoc jdc6284 (446335fc@ip68-99-53-252.cl.ri.cox.net) |
| 12:13.52 | jdc6284 | does anyone know when orgs are notified of the number of slots they will receive |
| 12:20.12 | teepee | somewhere between May 3rd and 13th I would assume |
| 12:29.44 | jdc6284 | :) Â thanks |
| 12:31.28 | *** join/#gsoc ricekot (~ricekot@unaffiliated/ricekot) |
| 12:32.08 | noam | obviyus: > most programmers have not thought about object lifetimes and ownership |
| 12:32.20 | noam | and that is probably why those programmers write buggy C code |
| 12:33.27 | obviyus | i've heard some people claim how writing safe code in Rust is less "cognitive load" |
| 12:34.01 | noam | People can claim whatever they want. I've heard a lot of claims about how using Rust requires shifting algorithms and such in ways that are worse for cognitive load /shrug |
| 12:39.08 | obviyus | fair enough |
| 13:35.58 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 13:39.45 | mhaeuser[m] | I have also heard that "simple" stuff like a doubly-linked list becomes a pain as declaring a clear memory owner is non-trivial |
| 13:40.16 | mhaeuser[m] | the issue is when there are such Rust proposals, you mostly get the view of the people who want to embrace it, and such are more likely to ignore or work around flaws without drawing attention to them |
| 13:52.06 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 14:04.06 | |Kev| | mhaeuser[m]: FWIW (as a non-Rust dev, but one who's looking into it), those panic()s you're talking about there are exactly in the situations that people typically don't want ignored in e.g. their kernels, like buffer overflows etc. It's not so much "Can't prove it's correct" and "Couldn't prove at compile time that it was correct, so fails at runtime if it's incorrect" |
| 14:04.22 | |Kev| | s/and/as/ |
| 14:05.00 | mhaeuser[m] | I know, and the correct way is graceful error-handling (e.g. aborting the current operation), not panicing |
| 14:05.19 | |Kev| | Sure, but graceful error handling is the caller's responsibility. |
| 14:05.38 | mhaeuser[m] | yes, it is, so it must get appropriate feedback, instead of some panic() routine being invoked |
| 14:05.50 | *** join/#gsoc diehlpk_work (~diehlpk_w@unaffiliated/diehlpk) |
| 14:06.01 | |Kev| | The panic is what happens when you ignored e.g. the error result and deferenced it anyway. |
| 14:06.27 | mhaeuser[m] | that is for memory accesses, a panic can also occur on failed memory allocation |
| 14:06.38 | |Kev| | I haven't yet found an example, in my limited (but many-day) look into it where Rust panics in anything other than programmer error. |
| 14:06.51 | mhaeuser[m] | allocs :) |
| 14:08.02 | |Kev| | Ah, that on is interesting. I hadn't reached that, I'll be honest. Although also I've never seen C(++) code that managed to cope with mallocs failing in a useful way, no matter how hard it tried :) |
| 14:08.06 | |Kev| | s/on/one/ |
| 14:08.10 | mhaeuser[m] | that was a concern in the discussion of Linux adoption as well, and it seems like alloc can be adapted somehow |
| 14:18.49 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 14:46.30 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 14:55.37 | noam | |Kev|: I'm working on a project which uses multiple workers, and on OOM re-adds the current job to the task queue and temporarily reduces worker count |
| 14:58.07 | noam | "Most projects mishandle OOM" isn't an excuse to to an even worse job, let alone in the kernel |
| 15:40.21 | |Kev| | I don't disagree - I said that OOM (well, alloc failures) wasn't a thing I realise Rust aborted on. |
| 15:40.35 | |Kev| | (In fact, it looks like failed alloc isn't even a panic, if I'm reading this right) |
| 15:54.02 | |Kev| | The proposal for how to cope with it looks pretty sensible to me, though, having failable allocators in the standard lib on the data structures. |
| 15:54.15 | |Kev| | (Or the proposal I found, anyway). |
| 16:09.10 | *** join/#gsoc Kristine86 (4a45dc0c@gateway/web/cgi-irc/kiwiirc.com/ip.74.69.220.12) |
| 16:43.30 | *** join/#gsoc folti58 (5d8d2066@93-141-32-102.adsl.net.t-com.hr) |
| 16:43.33 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 17:03.07 | *** join/#gsoc Andre_H (~german_wi@dslb-088-076-207-240.088.076.pools.vodafone-ip.de) |
| 17:09.26 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 17:32.06 | *** join/#gsoc Ra33 (0593c8d1@5.147.200.209) |
| 17:33.06 | *** join/#gsoc Reiko2 (~Reiko2@5.147.200.209) |
| 17:53.43 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 18:00.41 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 18:02.00 | *** part/#gsoc Ra33 (0593c8d1@5.147.200.209) |
| 18:21.45 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 18:22.51 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 18:26.28 | *** join/#gsoc ximion (~ximion@2a02:8071:ad8:8200::d1e4) |
| 18:54.05 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 19:29.34 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 19:30.34 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:3854:7b48:8b55:dd5a) |
| 19:48.47 | *** join/#gsoc OliverMadine (~OliverMad@90.199.221.25) |
| 19:52.54 | *** join/#gsoc Lord_of_Life_ (~Lord@unaffiliated/lord-of-life/x-0885362) |
| 20:01.26 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:2db2:e050:fcb5:dae9) |
| 20:20.05 | *** join/#gsoc meflin (~meflin@73.95.135.83) |
| 20:20.05 | *** mode/#gsoc [+o meflin] by ChanServ |
| 20:22.24 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:2db2:e050:fcb5:dae9) |
| 20:27.47 | *** join/#gsoc bkuhn (~bkuhn@conservancy/staff/bkuhn) |
| 20:30.41 | *** join/#gsoc OliverMadine (~OliverMad@90.199.221.25) |
| 21:46.27 | *** join/#gsoc meflin_ (~meflin@73.95.135.83) |
| 21:46.28 | *** mode/#gsoc [+o meflin_] by ChanServ |
| 22:13.54 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:2db2:e050:fcb5:dae9) |
| 22:33.53 | *** join/#gsoc RT|Chatzilla (~chatzilla@reactos/tester/RT) |
| 22:49.03 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:2db2:e050:fcb5:dae9) |
| 23:57.20 | *** join/#gsoc OliverMadine (~OliverMad@2a02:c7f:5e77:ad00:2db2:e050:fcb5:dae9) |