|
fletcher posted:more eyeballs on it in general. I just want to highlight that this has turned out to be one of the greatest fallacies about free software. Nothing against you in particular, OP: it's a commonly-held belief. In fact, if any college goons want a good master's project, try bringing some code up on GitHub, have some cohorts download it, then insert some super-blatant remote shell capabilities into it and see if any automated systems flag that. Maybe they do! I sort of suspect they won't, though. cruft fucked around with this message at 23:30 on Aug 31, 2023 |
# ? Aug 31, 2023 23:28 |
|
|
# ? Apr 19, 2024 06:33 |
|
The vulnerability database is really useful, too: https://pkg.go.dev/vuln/
|
# ? Sep 1, 2023 00:43 |
|
I write a bit of cgo every now and I sometimes get annoyed by how they’ve made it very difficult to add stuff to the CFLAG headers. However, the reasoning as to why they did it is solid - less chances for arbitrary code execution where you wouldn’t expect it. Anybody who has experienced a NPM package going rogue for political reasons would hopefully sympathise with Go keeping a very tight lid on “neat” dependency manager features.
|
# ? Sep 1, 2023 12:53 |
|
Can some kind soul help me out herecode:
I'm pretty sure the actual answer is "LOL it's not 1987 you have enough RAM to not care", but it's the principle of the thing, you see.
|
# ? Nov 7, 2023 16:42 |
|
cruft posted:Can some kind soul help me out here If you will be rearranging the list a lot then making it pointers will make it run faster, if you will be iterating over the list a lot then making it not pointers will make it run faster.
|
# ? Nov 7, 2023 16:44 |
|
cruft posted:Can some kind soul help me out here Memory usage is not the only consideration. Using pointers, you can modify an attendee and you'll see the update no matter how you access that Attendee.
|
# ? Nov 9, 2023 09:00 |
|
consensual poster posted:Memory usage is not the only consideration. Using pointers, you can modify an attendee and you'll see the update no matter how you access that Attendee. Particularly since each attendee is duplicated 3x in that struct, it makes sense to work with pointers. Speaking of that, I'd ask if you really expect to have so many attendees and do so many lookups by both email and by username that it makes sense to duplicate them 3 different ways. My first instinct would be to just hold the slice of Attendees, then iterate for lookups. Iteration is cheaper than you think (especially in this case which won't even have nested loops), and a lot easier than mucking around with 3 different stored representations of the same data.
|
# ? Nov 9, 2023 16:45 |
|
|
# ? Apr 19, 2024 06:33 |
|
Pham Nuwen posted:Speaking of that, I'd ask if you really expect to have so many attendees and do so many lookups by both email and by username that it makes sense to duplicate them 3 different ways. My first instinct would be to just hold the slice of Attendees, then iterate for lookups. Iteration is cheaper than you think (especially in this case which won't even have nested loops), and a lot easier than mucking around with 3 different stored representations of the same data. Haha, great minds think alike, and so do ours! My Scheme training kicked in and I wound up doing exactly this: there's now a type AttendeeList []Attendee that provides some indexing functions by iterating over the slice. Thanks, everyone. Your replies did steer me toward a nice solution.
|
# ? Nov 9, 2023 16:59 |