00:03:59 <Melvar> TIL about memfd_create, which is an operation I expected to exist for years (I think) but only found today.
00:10:24 <esolangs> [[Wariolang]] M https://esolangs.org/w/index.php?diff=88090&oldid=86323 * Nakilon * (+0) typo in category template
00:36:29 <nakilon> imagine ( and ) to mark a piece of funge code as one instruction for # and j
00:36:42 <nakilon> so #(would jump over all this)
00:37:05 <nakilon> bad thing is that there is no vertical ( ) in ascii at least
00:40:15 <fizzie> In Funge-98, the ; instruction jumps to the next ; on the path of the IP in the same delta in no time (as if it was empty space).
00:41:49 <fizzie> (So arguably it's less of an instruction and more a syntax for denoting a space-time wormhole.)
00:42:17 <nakilon> this just makes one-line branching easier
00:42:24 <nakilon> no need to calculate j shift
01:36:05 -!- oerjan has quit (Quit: Nite).
02:18:43 -!- earendel has quit (Quit: Updating details, brb).
02:18:53 -!- earendel has joined.
03:49:37 <Sgeo> The transpose and inverse of a rotation matrix are the same, according to some FAQ. I feel like that can help clear up some questions I had recently
04:17:37 <Sgeo> Hmm, are translations not considered a form of rotation in a higher dimension? The transpose of a translation matrix certainly doesn't look like it inverts the translation
04:25:18 -!- delta23_ has joined.
04:25:59 -!- delta23 has quit (Killed (NickServ (GHOST command used by delta23_))).
04:26:01 -!- delta23_ has changed nick to delta23.
04:59:22 -!- tromp has joined.
05:00:24 -!- tromp has quit (Client Quit).
05:02:02 <earendel> if you want to first A) translate and then B) rotate .. you can calculate the final matrix by multiplying B with transposed A matrix (A*)
05:03:24 <earendel> the order here is important. as translating first would set the pivot point of the rotation.
05:05:57 -!- int-e has quit (Ping timeout: 245 seconds).
05:06:06 -!- int-e has joined.
05:08:19 <earendel> you can do all kind of transformations by multiplicating the inverse matrices continuously...ending up with a final matrix which you can apply to all points. usually the last one is some projection matrix resulting in some pixel coordinates for the 2D screen
05:34:42 <earendel> oh. the transpose and inverse of a rotation matrix. A* is transposed A. right? no clue what inversed A is. yet.
05:38:18 -!- delta23_ has joined.
05:38:21 -!- delta23_ has quit (Client Quit).
05:41:05 -!- delta23 has quit (Ping timeout: 268 seconds).
07:04:04 -!- imode has quit (Ping timeout: 252 seconds).
07:11:42 -!- tromp has joined.
07:18:22 -!- monoxane has quit (Ping timeout: 252 seconds).
08:02:47 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
08:05:59 -!- hendursa1 has joined.
08:09:24 -!- Sgeo has quit (Read error: Connection reset by peer).
08:09:27 -!- hendursaga has quit (Ping timeout: 276 seconds).
08:19:59 -!- tromp has joined.
09:04:35 <earendel> i was just thinking about rotational speed of a spinning body.. and
09:14:22 <earendel> wondered how relativity laws would play in such.. realizing that measure of total speed is 0 at center .. and grows larger with radius.. also know ice-dancers when pulling their arms in.. gain speed .. why? and .. is a center even moving at all? can this be calculated with calculus and ..
09:17:42 <earendel> also like a few days ago, i read about a function that could approximately calculate a continous sin wave, with a starting value of sth with sin^2 and stepsize .. a wild association to the question if rotation is sth like translation but different :p
10:01:14 <nakilon> someone on reddit asked wtf is the "summer shower"
10:02:59 <nakilon> like this one https://dachnye-reshenia.ru/wp-content/uploads/2016/11/%D0%AD%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC-1.jpg
10:04:08 <riv> i dont have that
10:04:26 <riv> does it kill you?
10:27:19 -!- spruit11 has joined.
10:31:08 -!- spruit11_ has quit (Ping timeout: 268 seconds).
11:07:37 -!- tech_exorcist has joined.
11:12:48 -!- monoxane has joined.
11:29:16 -!- tech_exorcist has quit (Ping timeout: 252 seconds).
12:23:29 <riv> the X + X = N thing is kind of like this http://www.inference.org.uk/cds/part3.htm
12:23:42 <riv> except this is X - X = Z/nZ I guess
12:24:51 -!- riv has quit (Quit: Leaving).
12:30:10 -!- riv has joined.
12:36:29 -!- arseniiv_ has joined.
12:39:35 <riv> could you do X - X = N?
12:39:51 <riv> i suppose powers of 2 would work
12:40:13 <riv> maybe fibs too?
12:51:01 -!- Thelie has joined.
12:55:10 -!- earendel has quit (Quit: Connection closed for inactivity).
12:56:36 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
13:00:27 -!- spruit11 has quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.).
13:03:41 -!- tromp has joined.
13:15:44 -!- arseniiv_ has quit (Quit: gone too far).
13:18:20 -!- arseniiv has joined.
13:20:49 -!- riv has quit (Quit: Leaving).
13:22:28 -!- riv has joined.
13:32:38 -!- Thelie has quit (Remote host closed the connection).
13:43:00 -!- tech_exorcist has joined.
13:47:01 -!- hendursa1 has quit (Quit: hendursa1).
13:47:27 -!- hendursaga has joined.
13:59:57 <esolangs> [[Special:Log/newusers]] create * Leomok2009 * New user account
14:03:18 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
14:08:28 -!- src has joined.
14:30:01 -!- tromp has joined.
15:05:46 <esolangs> [[Special:Log/newusers]] create * Iamn00b * New user account
15:09:41 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=88091&oldid=88070 * Iamn00b * (+272)
15:15:15 <esolangs> [[User:Iamn00b]] N https://esolangs.org/w/index.php?oldid=88092 * Iamn00b * (+123) Created page with "sup <br /> is me, iamn00b <br /> my discord is <pre> randomguy#0047 </pre> so far, i've made 1 lang spec: LCCBED, coming up"
15:15:23 -!- earendel has joined.
15:38:02 <esolangs> [[LCCBED]] N https://esolangs.org/w/index.php?oldid=88093 * Iamn00b * (+1809) Created page with "LCCBED stands for "Letter Command Brainf*** Enhanced Derivative. It was created by [[User:Iamn00b]] in 2021. Its goal was simple: to make a slightly more confusing yet wonderf..."
16:02:40 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
16:15:09 -!- river has joined.
16:17:28 -!- riv has quit (Ping timeout: 252 seconds).
16:23:02 -!- arseniiv has quit (Ping timeout: 268 seconds).
16:46:51 -!- imode has joined.
16:54:19 -!- arseniiv has joined.
17:16:22 -!- tromp has joined.
17:20:30 -!- immibis_ has changed nick to immibis.
17:27:47 -!- arseniiv has quit (Ping timeout: 268 seconds).
17:30:21 -!- delta23 has joined.
17:33:42 <Melvar> earendel: Pulling their arms in to gain speed: It’s preservation of angular momentum. Pulling in the arms decreases their moment of inertia, requiring their angular velocity to increase in order to maintain angular momentum.
17:39:55 -!- arseniiv has joined.
17:47:58 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
17:58:38 <earendel> are you sure it is inertia? how is the angular momentum calculated? like impulswe? mv? [and furtner on the relativity shizle: imagine the length of their arms beim 0,4 lightyears long. and no friction. and they would turn full angle once per year. so the speed of her fingertips would close on speed of light o)o ]
18:03:25 <earendel> [ .. is angular velocity somehow accumulative with the movement of something which radius is bigger > 0 through space? ]
18:03:26 <j-bot> earendel: |spelling error
18:03:26 <j-bot> earendel: | .. is angular velocity somehow accumulative with the movement of something which radius is bigger > 0 through space? ]
18:09:17 -!- ais523 has joined.
18:09:31 <earendel> okay. it wouls obviously take some energy to slow down roatation of earth. and that inertia is due to its mass. and if you would shrink the earth, but keeping the mass, it would turn faster. right?
18:09:57 -!- tromp has joined.
18:11:10 <ais523> I'm currently trying to figure out how to implement Java-style interfaces in a new language I'm working on (a Java-style interface is basically a set of methods that can be implemented by more than one class, classes can implement more than one interface, and you can have a reference to an object that conforms to a particular interface without knowing what class it has, and call methods of the interface on it)
18:11:12 <earendel> the dancer doesn't lose weight. it just centers towards its fuckn massenscshwerpunkt. can u roger taht.lol. ok. spacecowboys. sry for spamming.
18:12:09 <ais523> I feel like there has to be an easier way than the standard methods of doing it, but can't think of one
18:12:27 <APic> ais523: You do not even need to do the Sokoban-Solver now because somebody else did 😸
18:12:37 <ais523> APic: I don't think I was working on a Sokoban solver
18:12:43 <APic> But it would still rock to pack it into the NetHack4-Frontend 😉
18:12:48 <ais523> I was working on a Sokoban /generator/ at one point, but that's a different problem
18:13:12 <ais523> oh, unless you count TAEB's Sokoban-solving routines, but they just used a hardcoded/memorized solution rather than actually solving the puzzle
18:13:17 <APic> But when You have a good Generator, the Solver is not that far ahead
18:13:35 <ais523> I could probably adapt the generator into a solver, but it isn't really a "good" generator yet
18:14:21 <APic> If it can solve _my_ SokoBan on NetHack.ALT.Org and/or nethack@EU.HardFought.Org i am very glad to try it out in two Days, when the green Cheese will be highly illuminated again
18:15:38 <ais523> hmm, this conversation has indirectly taught me something about German grammar: "jemand" is technically a pronoun, not a noun, so it doesn't start with a capital letter
18:16:27 <ais523> the hard part of an automated Sokoban solver for playing NetHack isn't the actual solving, though, but doing the inputs (and fighting monsters along the way)
18:16:51 <APic> Yes, so i can procrastinate my other Tasks further 😸
18:17:44 <earendel> pardon. i was confusing you with somebody else.
18:18:01 -!- ais523 has quit (Quit: sorry about my connection).
18:18:15 -!- ais523 has joined.
18:18:16 <APic> Especially because of my Hebephrenia.
18:18:43 <ais523> …oh wow, I think I've seen this problem before
18:18:53 <ais523> vtables for interfaces is the "match these inputs to these outputs" problem
18:19:50 <ais523> i.e. given a set of (input, expected output) pairs, to generate a function that maps each of the provided inputs to the matching output, and it doesn't matter what the function does with other inputs
18:20:39 <ais523> I found a really neat solution to this a while ago in terms of minimizing the size of the generated function: https://codegolf.stackexchange.com/questions/105303/help-me-recognise-my-monster/214222#214222
18:20:49 <APic> Reminds me or good old Bobby Tables 😉
18:21:01 <ais523> although, it may have bad performance
18:22:02 <ais523> x86-64 has finite field builtins nowadays, but most of them deal with GF(2⁸), you'd want GF(2⁶⁴) for this
18:22:29 <ais523> would be fun to see VPCLMULQDQ in a virtual method lookup routine
18:22:32 <ais523> (but probably not efficient)
18:24:57 <APic> Epic Mnemonic.
18:25:47 <ais523> maybe some sort of cuckoo hash is the right solution here? what we want is effectively a map structure with a) space-efficient storage, b) fast lookup; being able to modify it efficiently is not important
18:25:54 <ais523> the construction I linked above handles a) but probably not b)
18:28:58 <earendel> i think the crux is really to program against those interfaces. instead of mapping whatever model you have straight onto a view. better make it smalltext, longtext, headertext instead of isbn, vendor-description, vendor-titla-bla .. i mean. in the end you always end up with listst of some (expandible) blocks containing text, graphics, and buttons, and maybe moving parts. a detailed view of items. a formular to edit. [beside the genereric
18:28:58 <earendel> extension things which are cool and final .net]
18:29:18 -!- Everything has joined.
18:29:24 <earendel> this would distinct interfaces from adapters which just map things together.
18:30:09 <earendel> designing the interface. like not writing a line of code for years. is dharma-body of buddha.
18:32:44 <ais523> Rust's solution to this is to make "as" magic, I think; when casting from an object-pointer to an interface-pointer type, it adds extra metadata that specifies a vtable for that object implementing that interface
18:32:56 <ais523> I'm not sure how it handles casts from an interface-pointer type to a different interface-pointer type
18:33:01 <ais523> time to try some experiments, I think
18:33:03 <earendel> what i mean is: imagine you have that mediaplayer interface. and you want to be able to sick it at your robotsexslave, ../
18:37:37 <earendel> i mean something like decorators is also not bad. mechanics: simple, bootstrap: little, lazyppl: lit
18:39:06 <earendel> started viewing rust tutorial yesterday. u r right. first we have to rewrite the browser in rust. yes.
18:41:52 <ais523> …oh wow, I think you *can't* cast from one interface-pointer type to another in Rust
18:42:05 <earendel> then we create p2p distributed ai rss seti graph protocoll for querying news feeds.
18:47:19 <ais523> after searching a bit more, I discovered that there are crates which add extra metadata to allow casting from one trait object type to another, which makes it very likely that there's no way to do it using Rust's usual implementation of trait objects (otherwise you wouldn't need the crate)
18:47:32 <earendel> all i got so far is it has this owner concept. vars belond to some actors/subjects and can be lend to others, and kinda im/explicitly passed back etc. variables and scopes and garbage collector follow stricter rules. also no inheritanve but composing traits.
18:47:51 <earendel> crates were like packages or sth right?
18:48:54 <keegan> there's no garbage collector in rust
18:49:24 <keegan> it's all based on smart-pointers and references
18:49:27 <keegan> very similar to modern C++
18:49:44 <keegan> but unlike C++, the compiler is able to check at compile time that references don't outlive the thing they refer to
18:50:20 <ais523> I think of Rust as being a language which lets you write clever code, but you need to be able to prove that what you're doing makes sense (and the proof ends up inside the source code as documentation of what it's doing)
18:50:59 <keegan> not only that but it enforces a "many readers xor one writer" rule for references
18:51:23 <keegan> if you have a &mut reference to something then it checks that other references are not being touched at the same time
18:51:36 <keegan> this prevents iterator invalidation errors, which are a huge source of undefined behavior in C++
18:51:40 <earendel> it's really for the solid bone of something. but still they say its only liek 10% less performant (with gui and bglah) than c cod .. that guy said.
18:52:00 <keegan> any kind of broad performance comparion like that is useless
18:52:03 <keegan> it deends on the use case
18:52:11 <ais523> I still don't really like the &mut name – the invariant is that while the reference is alive, it's the only way to refer to the object, it isn't really related to mutability
18:52:25 <ais523> you can mutate things through & references if they're designed appropriately
18:52:28 <keegan> and you can always bypass the static checking and do it the exact same way you would in C
18:52:35 <keegan> if you can't figure out a zero overhead way to make the static checking happy
18:53:35 <ais523> I guess the reason for the name is that in order to mutate something in Rust, you have to prove that the mutation of it is safe, and "this is the only reference" is an easy way to prove that it's safe
18:54:04 <keegan> but as you said there are other types that let you prove that another way
18:54:14 <keegan> Cell, RefCell and AtomicFoo
18:54:19 <earendel> keegan: sorry. but i think its worth to take note of its high performance. dont say its useless when it can give u a hint if u can need it or not. like 1 of 5.
18:54:31 <ais523> and Mutex, that's about it for the main ones
18:54:47 <earendel> its some overhead you need that you can avarage down not calling it a benchmark.
18:55:15 <ais523> …it just crossed my mind how similar Mutex and RefCell are
18:55:40 <ais523> Mutex is basically just thread-safe RefCell, isn't it?
18:57:21 <keegan> earendel: what i'm saying is there's nothing in Rust that provides an omnipresent overhead like a garbage collector or VM
18:57:27 <keegan> it's bare metal compiled language
18:57:47 <keegan> any overhead solely comes from whether you can express the most efficient way of doing things within the static safety constraints or not
18:58:09 <keegan> it's kind of like arguing about the overhead of C++ versus C
18:58:19 <keegan> would anyone say that C++ is 10% slower than C? of course not, it depends on how you write your C++
18:58:24 <keegan> if it's full of virtual methods it might be slower
18:58:30 <keegan> if you write very C-like code it might be the same
18:58:32 <ais523> keegan: there is some overhead in the existing backends (not inherent in the language), e.g. in ensuring that the stack is always aligned and backtraceable; I'm the sort of person who gets irrationally annoyed by this
18:58:41 <keegan> if you make heavy use of template metaprogramming it might even be faster than C
18:58:48 <keegan> due to better opportunities for compile time specialization
18:59:57 -!- tech_exorcist has quit (Quit: see you tomorrow).
19:00:15 <keegan> a lot of C idioms are inefficient
19:00:30 <ais523> keegan: that doesn't surprise me but I can't think of any examples right now
19:00:36 <keegan> a lot of time a function pointer / void* dynamic polymorphism pattern is used when only static polymorphism is needed
19:00:55 <keegan> whereas in C++ or Rust you would use generics and end up with more direct code and more optimization opportunities
19:01:03 <ais523> ah right, the function pointer + void* method is a good example, ye
19:01:13 <keegan> (of course this also relates to the compilation unit)
19:02:24 <ais523> although there are tradeoffs, &dyn T (which is effectively equivalent to the function pointer + void * method) could be more efficient than &impl T if the generic function is large enough that instruction cache pressure is more of a bottleneck than branch mispredictions
19:02:54 <ais523> that seems unlikely, though, branch mispredictions cost quite a lot so you'd need a huge amount of cache pressure to make the mispredictions cheaper
19:04:46 <b_jonas> “<ais523> […] German grammar: "jemand" is technically a pronoun, not a noun, so it doesn't start with a capital letter” => and in Hungarian, you can only capitalize proper names if they're nouns, not adjectives, which I think is very silly, but we can't really change it now
19:05:51 <keegan> in embedded code you might prefer the dynamic version to save on code space
19:05:57 -!- chiselfuse has quit (Ping timeout: 276 seconds).
19:06:09 <keegan> but it's often the case in C that a "generic" library is only instantiated at /one/ client type
19:06:22 <keegan> and in that case the static version would probably produce smaller code by specializing and removing unused stuff
19:06:36 <ais523> I think a good example are things like qsort, which are generic due to being compiled ahead-of-time but are often used at only one type in any given program
19:07:24 -!- chiselfuse has joined.
19:07:29 <ais523> actually, memcpy is a really good example
19:07:30 <shachaf> Templated C++ programs sometimes monomorphize and end up with huge binaries and ridiculous type names in stack traces and things.
19:07:40 <ais523> although I think compilers special-case that one nowadays
19:08:11 <ais523> shachaf: I think most modern systems langauges give a choice between monomorphization and dynamic dispatch, but there can be some debate about which to use
19:08:27 <ais523> dynamic dispatch is needed if you have a heterogenous list, but there are many cases where both would work
19:08:48 <ais523> the language I'm working on does both, but I realised I wasn't sure how to implement dynamic dispatch efficiently
19:09:20 <shachaf> Dynamic dispatch is often implemented with some sort of boxing.
19:09:34 <b_jonas> ais523: re type interfaces, to figure out what design you want, I think there are at least three questions about intended use that you should decide. 1. who is allowed to declare that a type implements an interface? only the module that defines the class, or only the module that defines the interface, or both? 2. in what namespace are the names of methods that interfaces provide? are they global, so you
19:09:35 <shachaf> But another alternative is the equivalent of passing in type size and alignment dynamically, but still having just one implementation.
19:09:40 <b_jonas> can define an interface after a method name is commonly used without an interface? namespaced so that if you define an interface and a method in it, existing methods with accidentally the same name won't clash with it?
19:09:44 <shachaf> I think maybe Swift does that?
19:10:22 <ais523> b_jonas: I'm pretty sure that the correct solution for 2) is for the method name to be namespaced, so that two interfaces can define methods with the same names and a class can implement them both with different implementations if it wants to
19:11:04 <ais523> most languages (e.g. Java) gets this wrong; Rust has an interesting compromise in which it gets it right, but with horrible syntax for disambiguating which method you need if you actually need to call the method after doing that
19:11:38 <shachaf> I wonder whether methods are an idea that makes sense at all.
19:12:15 <ais523> they're useful when writing code out of order
19:12:32 <ais523> like, writing generic code before you know what types it's going to be useful for
19:12:48 <ais523> monomorphisation is very useful if it does end up getting used at only one type in practice
19:13:35 <shachaf> Go resolves interfaces by doing type checking (including string comparison of method names and so on) at runtime.
19:13:42 <b_jonas> ais523: in rust, when you define a trait, you can define that it's the subtrait of another trait, which more or less means that the vtbl has a reference to the vtbl of the supertrait. note also that rust doesn't allow you to cast from a ref to interface to a ref to a specific type that implements it, like C++'s dynamic_cast. if you want that, you have to define a method that does such a cast to one
19:14:26 <ais523> b_jonas: Rust lets you downcast to concrete types via Any nowadays, but it doesn't let you upcast from a trait to its supertrait
19:15:07 <ais523> you can call methods of the supertrait on a trait object of the subtrait, but can't upcast to a supertrait object (which initially surprised me, but I couldn't figure out how it was implemented and discovered that it was illegal while experimenting, so maybe it's disallowed due to difficulty of implementation)
19:17:37 <ais523> ah, seems relevant: https://stackoverflow.com/questions/28632968/why-doesnt-rust-support-trait-object-upcasting
19:20:13 <b_jonas> ais523: re Mutex, yes, that's a good approximation, though I think the multi-threaded version of RefCell is std::sync::RwLock, which is slightly more powerful than Mutex. also Arc is the multi-threaded vesrion of Rc; and you can kind of think of std::sync::atomic::AtomicU32 as the multi-threaded version of Cell<u32>, though that analogy is more strained
19:23:19 <b_jonas> you can't upcast from a trait to a supertrait? hmm
19:23:29 <ais523> I'm surprised there isn't a single-reader version of RefCell, actually; it would seem useful for performance in cases where you don't need multiple readers (unless the multiple-readers case is just as fast, which would seem unlikely)
19:24:55 <ais523> it looks like the Rust developers want to implement trait→supertrait upcasting but doing so is hard
19:25:18 <b_jonas> though rust now has default methods, and just like in haskell, only the trait can define what its supertraits are, so explicitly adding a method for upcasting from a trait to a specific supertrait should be easy enough,
19:25:28 <b_jonas> so it's probably not a big problem
19:25:47 <b_jonas> ais523: re "single-reader version of RefCell, do you mean a RefCell that you can only mut borrow??
19:26:28 <b_jonas> I'm not sure if you could implement that more efficiently than the current RefCell if you never borrow from it
19:26:40 <b_jonas> that said, if you want something like that, you can impelment it yourself from UnsafeCell
19:27:10 <ais523> I actually implemented effectively that myself in a program I'm working on – I had what in effect wanted to be a Cell that held an enum, so I added an extra option to say that it was currently borrowed and unavailable
19:27:15 <ais523> and then swap it out of the Cell whenever I want to work on it
19:28:07 <ais523> this is pretty similar in practice to a single-reader RefCell
19:29:33 <b_jonas> that could perhaps work, though I imagine if the enum is very large, then the optimizer might not see through that method properly
19:31:10 <b_jonas> the inner enum doesn't happen to be the node type for the balanced tree library that you wanted to do at some point, right?
19:31:41 <ais523> it switches between particular list implementations for an esolang
19:32:08 <ais523> in which lists can potentially be larger than the computer's address space, and sometimes have their elements calculated lazily because of that
19:33:42 -!- Everything has quit (Quit: leaving).
19:39:55 <b_jonas> ais523: are the lists semantically mutable, and if not, can it change between representations after a value is created?
19:47:47 <b_jonas> yeah, the second one is probably a silly question, obviously yes if you need a Cell
19:51:37 <ais523> b_jonas: they're semantically immutable, but they can change representation after creation
19:51:47 <ais523> (whilst still keeping the same value)
19:54:05 <b_jonas> right. that comes up sometimes.
20:00:24 <ais523> one idea I had for implementing vtables would be a sort of golomb-rulerish implementation where the address of each method was at a fixed offset from the start of the vtable, and you interleaved vtables in the dead space of each other in order to pack them more tightly in memory
20:00:25 -!- oerjan has joined.
20:00:42 <ais523> but I don't know what the optimal packing density for that would be, or what sort of algorithm you'd use to achieve it
20:03:00 <Corbin> Huh. Isn't finding a Golomb ruler NP-complete?
20:03:35 <b_jonas> I'll also note that if you care that much about efficiency, you can impelment your custom dynamically typed object abstraction in rust with unsafe pointer dereferences, you aren't required to use the built-in dyn objects
20:04:06 <b_jonas> Corbin: not if you don't want the shortest possible one
20:04:16 <Corbin> Ah, we don't know, but I was thinking of *optimal* Golomb rulers, which are harder.
20:04:18 <b_jonas> Corbin: also not if you only have single-inheritance by the way
20:04:39 <b_jonas> Corbin: also Fortran compilers are required to solve that sort of thing, so it's a kind of tradition
20:04:49 <b_jonas> I don't know if they're ever NP-complete by the way, just that it's not trivial
20:08:07 <b_jonas> I was thinking about the custom object thing in rust by the way, mostly because I want a *closed* set of types (enum as opposed to trait), dynamically allocated and you can't change their types, but with variable length, where you have to look at the discriminator (or custom flag bits) to figure out which methods and which destructor and deallocator to call
20:08:47 <b_jonas> rust is trying hard to make sure that anything you would write in C you can implement as efficiently in unsafe rust
20:09:38 <b_jonas> it's not quite there yet, because C compilers have grown a ton of extensions, often platform-specific ones, by now, but most of the time it's fine
20:11:43 <b_jonas> rust has features that are there specifically to satisfy this, such as you can directly call C new style vararg functions from rust
20:12:34 <ais523> Corbin: finding just any Golomb ruler is easy, finding optimal ones is hard
20:13:05 <b_jonas> https://doc.rust-lang.org/nightly/unstable-book/language-features/c-variadic.html
20:13:53 <b_jonas> it's there so you can interface with existing C programs that define or call a variadic function
20:13:56 <ais523> I vaguely remember that unsafe Rust has some way to simulate a C-style flexible array member
20:14:55 <b_jonas> ais523: flexible array member: kind of, but not really. you can define a struct that notionally has a flexible array as its last member, and that struct is non-Sized,
20:15:27 <b_jonas> but the problem is, there's no reasonable way to *create* a value of such type, you more or less have to use pointer arithmetic for it. you can access such a type through pointers though.
20:15:30 <ais523> your size-variable enums are also non-Sized
20:15:58 <b_jonas> yes, this is more or less the correct approach,
20:16:45 <b_jonas> but C++ at some point planned to add a feature where there's an official way to declare a variable-sized type that knows its own size from a member that stores its size, and a way to construct them on the heap in a reasonably safe way, I think
20:17:08 <ais523> one thing that I'd like to do in a systems language is to record type, lifetime, etc. information directly into pointers by allocating them in different parts of memory
20:17:44 <ais523> so that, e.g., Cow<'static> would just be a single pointer, and you check to see whether the pointer is on the heap or in the executable in order to determine whether it's owned or borrowed
20:17:50 <ais523> but, you can't do that in current Rust because of Box::leak
20:18:01 <ais523> (which creates dynamically allocated static references)
20:18:18 <b_jonas> what I'd really like is https://github.com/rust-lang/rfcs/blob/master/text/1861-extern-types.md to become stabilized
20:18:46 <b_jonas> that lets you create types that are explicitly non-Sized so much that the language doesn't even know the size at runtime
20:19:04 <b_jonas> that would be more general than just non-Sized array members
20:19:24 <b_jonas> so far that feature is unstable
20:19:57 <b_jonas> and yes, they're more or less equivalent in power
20:20:30 <b_jonas> but saying that you have an unknown sized char array member is just notionally more silly than saying that you have an unknown type member
20:21:29 <ais523> well, a flexible u8 array at least has the semantics that you're allowed to read the bytes
20:21:59 <ais523> maybe that's correct for things that are Copy and have no trap/invalid representations? and an unknown type member for things that aren't?
20:22:05 <ais523> probably an unknown type member is correct in most cases
20:22:52 <Melvar> earendel: Yeah the thing is that unlike linear momentum that is mass times velocity, angular momentum is moment-of-inertia times angular velocity. Moment of inertia is basically rotational inertia, but the neat thing is that it depends on the shape of the object (relative to the axis of rotation). For a single particle, the moment of inertia I = r²m, where m is the mass and r the rotational
20:22:53 <Melvar> radius, and the angular velocity ω = v/r where v is the linear velocity component perpendicular to the radius at any instant, giving the angular momentum L = Iω = rmv, so a single particle’s angular momentum is its instant linear momentum times the radius of rotation if it is circularly orbiting the center of rotation.
20:23:07 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
20:23:30 <b_jonas> allowed to read which byte? it can be zero-sized.
20:23:48 <ais523> any bytes that are proven to be there using size_of_val
20:24:03 <ais523> (assuming that size_of_val is implemented, which it might not be I guess)
20:24:06 <b_jonas> I don't think that applies
20:24:31 <b_jonas> the point of these types that unlike with slices and str and trait objects, even the compiler doesn't know how to compute the size of the object
20:25:14 <b_jonas> you can only access the trailing part unsafely, when you guarantee you know (a lower bound) for the size, and can only deallocate it unsafely
20:26:13 <b_jonas> this is mostly just a type system as in notation to avoid errors kind of thing, you can already use unsafe pointer dereferencing to implement all this
20:26:38 <ais523> on that note: I think the programming world really needs to decide whether a) the allocator tracks the length of things that it allocates, in which case it might as well also track type information; or b) the allocating program tracks the length of things it allocates, in which case it should tell the allocator so that the allocator doesn't have to record that information separately
20:27:11 <ais523> most existing programs/libraries try to do a) and b) simultaneously, leading to a lot of redundant work
20:27:29 <b_jonas> ais523: I think you can genuinely want both of those
20:27:46 <ais523> but for different allocations? or for the same allocation?
20:28:02 <b_jonas> for different allocations. you must allow the caller to track the object size so that you can allocate small fixed size objects, like cons cells, without too much memory overhead;
20:28:29 <b_jonas> but you must allow something in the library or language to track the size so that you can allocate Box<[T]> or Vec<T>
20:29:04 <ais523> hmm, perhaps there should be malloc8, malloc16, malloc24, malloc32 functions for allocating specific small numbers of bytes (and a corresponding free8, free16, free24, free32)
20:29:20 <ais523> existing mallocs can't normally do less than 8 bytes anyway
20:29:28 <ais523> and are quite wasteful for very small allocations
20:30:03 <b_jonas> ais523: yes, you can have the allocator be an inline function that handles the fast case, and calls a non-inline function for the difficult case, and nudge the compiler to constant fold the common case of known size
20:30:13 <b_jonas> C++ new/delete hopefully already does that
20:30:16 -!- user3456 has changed nick to rip-libera-offto.
20:30:28 -!- rip-libera-offto has changed nick to user3456.
20:32:44 <b_jonas> ais523: in rust, the public interface for the default allocator is Box, which can do both fixed size (Sized) and dynamic size (slice) allocations, and has an interface to turn a Box<T> to a plain pointer or pointer plus size (to simulate new) and back to a Box later (to simulate delete)
20:34:05 <b_jonas> and since T in Box<T> is a type parameter, it is very likely that the compiler will constant fold the size to the inline part of the function
20:34:23 <ais523> b_jonas: C++ new/delete doesn't seem to do that at present: https://godbolt.org/z/so19cnK93
20:34:31 <b_jonas> generic parameters, in both C++ and rust, are the current state of the art to strongly nudge the compiler to constant-fold a value, since it's hard to figure that out otherwise
20:34:44 <b_jonas> I think ziglang has an explicit notation for a parameter that should be constant-folded
20:35:38 <ais523> in Rust, I think it's more interesting to look at the public interface *from* the allocator (i.e. if you're replacing an allocator, what it gets to see)
20:36:08 <ais523> https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html
20:36:21 <b_jonas> ais523: I admit I've never looked at that
20:36:30 <b_jonas> I don't think I'll want to replace the global allocator
20:36:43 <b_jonas> write a custom allocator that only my code uses, sure
20:36:48 <ais523> it looks like it's the responsibility of the code to track the size, under Rust's API
20:37:02 <ais523> but there's no ability to specialise on the `Layout` parameter
20:37:44 <b_jonas> to a large part this is because if I want a custom allocator, I probably want it to have a special interface, and not impelement it to work as a global allocator
20:37:56 <oerjan> <riv> could you do X - X = N? <-- as a bijection? no. you obviously will get 0 in many ways.
20:39:14 <ais523> I guess part of the problem is that when allocating arrays, the element type will usually be known at runtime but the number of elements might not be
20:40:48 <b_jonas> I don't see why that's a problem
20:40:48 <oerjan> oh, in the cyclic difference thing you explicitly exclude that particular case
20:41:58 <ais523> b_jonas: the reason why you can't just make the layout a generic/compile-time parameter and specialise on it, as opposed to a runtime parameter
20:42:38 <ais523> although, I guess you can just use an if statement, and hope that link-time optimisation will inline the relevant part of the function?
20:43:08 <ais523> hmm, knowing whether something is an array seems like important information for an allocator
20:43:12 <b_jonas> you will need both allocations with compile-time known size, and ones with only runtime known sized
20:43:21 <ais523> e.g. "this will never be realloc()ed" could be a useful piece of information to know for performance optimisations
20:43:22 <b_jonas> and you will want this distinction in the type of the smart pointer
20:44:05 <b_jonas> oh, you want a fancy realloc that doesn't just check the capacity and malloc,memcpy,free if too small?
20:44:17 <b_jonas> I rarely think of that optimization
20:44:32 <b_jonas> I'm not sure it's really worth
20:45:03 <ais523> one example is, if something is fairly large (at least pages) and reallocable, to mmap it at a random memory address so that you can expand it with mremap if necessary, rather than having to copy to different physical memory
20:45:25 <ais523> whereas things that aren't reallocable make more sense to pack densely
20:45:46 <b_jonas> maybe, that's just not a case I thought of much
20:47:05 <ais523> I think it probably makes more sense for the program to track the size for small non-resizable things, and for the allocator to track the size for large resizable things
20:47:43 <ais523> …now I'm wondering if programs get to read their own page tables, probably not
20:48:12 <ais523> I think it's up to the kernel to decide whether it maps the page tables (or parts of them) somewhere a process can see them or not
20:48:38 <ais523> (I remember an experiment in which someone wrote a kernel module to let programs write directly to their own page tables at runtime, in order to investigate how the processor handled changes)
20:49:50 <b_jonas> the program read its own page tables? that would rarely be useful for a user-space probram
20:50:52 <ais523> Web of Lies had some reason to do it, IIRC
20:51:24 <ais523> although it accomplished it by parsing /proc/self/maps, which isn't very efficient (and even then that doesn't tell it the physical addresses, but it didn't care about that)
20:53:25 <b_jonas> ais523: it's hard to care about the physical addresses, because the kernel has the right to change them at any time
20:53:44 <b_jonas> it'll rarely do that, mostly for suspending the computer or hotswapping RAM, but still
20:54:00 <ais523> right, the only time I can think of when it actually would would be during hibernate+unhibernate
20:54:21 <b_jonas> no, it can also do that to swap them out, but you can stop swapping with mlock
20:54:35 <b_jonas> and in theory it could also do that to automatically turn them to hugepages
20:54:48 <b_jonas> and to compress or deduplicate them, but those are mostly just swapping
20:54:57 <ais523> a program could look at its own page tables to see if memory was swapped out at the time
20:55:03 <ais523> but I think there's an API to check that, isn't there?
20:55:06 <b_jonas> but if you care about the physical address, you probably mlock the memory
20:55:09 <ais523> actually there's a processor instruction to check that
20:55:24 <ais523> so you don't even need to ask the kernel
20:55:28 <b_jonas> ais523: iirc there's some new API too for some reason, not just the processor instruction
20:55:38 <b_jonas> why you need it with the instruction there I don't remmeber
20:56:14 <ais523> ah no, VERR checks a /segment/, not an address
20:56:40 -!- tromp has joined.
20:56:45 <ais523> that… doesn't seem very useful
20:57:00 <ais523> no wonder VERW got repurposed for some sort of Spectre mitigation
20:57:05 <b_jonas> it's rarely useful, but it was added for some specific weird reason
20:57:58 <ais523> (VERR/VERW run in microcode and don't require privilege to use, so it was possible to patch it to flush the caches that needed to be flushed to stop some specific Spectre abuse, then do the intended functionality of VERW afterwards just in case someone was using it for its intended purpose)
20:59:24 <b_jonas> ais523: is that with or without some extra prefix to VERR?
20:59:57 <ais523> b_jonas: no prefix needed
20:59:59 <b_jonas> x86 has some prefixed combinations that do the same as without the prefix on all existing CPUs but also isn't required to do the same thing, so they can be repurpused for things like this
21:00:20 <ais523> in order to be backwards-compatible it had to be some existing instruction that wasn't supervisor-only and is a no-op on older CPUs
21:00:56 <ais523> there are backwards-compatible NOPs like endbr64, but those are hardcoded to not do anything on existing processors, you can't change what they do with a microcode update
21:01:33 <ais523> VERR and VERW are near-no-ops (they just change one flag) and so are quite easy to work into a program
21:01:37 <b_jonas> sounds like an interesting partial workaround
21:01:51 <ais523> and their functionality can be updated in firmware
21:02:10 <b_jonas> but I'm also glad I could just buy a cpu that was already designed to be careful with Spectre-like vulns\
21:02:58 <ais523> well, Spectre affects all major CPU families with speculative execution, I think (it's Meltdown that was Intel-specific)
21:03:25 <b_jonas> ais523: yes, so there need to be separate fixes for Intel and AMD, to multiple similar vulns
21:04:07 <b_jonas> but the point is that the Spectre and its relatives are now old enough that the latest CPU microarchitectures were designed when they were already known and so designed to avoid them
21:04:37 <b_jonas> and IIUC the CPU that I bought for my new home computer is one of those
21:05:12 <b_jonas> though I still wouldn't want to run one of those evaluator bots like HackEso or perlbot on my normal home desktop
21:05:17 <ais523> I'm not sure if they're fully designed to avoid them because it would hurt performance, they just have mitigations
21:06:17 -!- Lord_of_Life has quit (Ping timeout: 265 seconds).
21:06:36 <b_jonas> I'll only run such bots if I have a separate computer hardware for that kind of thing, or if I pay for a separate virtual machine at a hosting provider
21:06:48 -!- Lord_of_Life has joined.
21:07:19 <b_jonas> ais523: they probably can't protect from all the timing attacks, yes
21:08:01 <b_jonas> but they can protect from the ones where you can do an indexed memory access or jump where the address is speculatively evaluated and effectively *read* memory that you don't have access to from that
21:10:05 <b_jonas> this means that if you decode a block cypher then verify the program, and write it carefully to not leak timing data, then another process won't be able to read your ephemeral key or cleartext etc
21:10:23 <b_jonas> unless it's like leaked in the form of variable power usage or wifi interference
21:11:33 <b_jonas> whereas on old CPUs without mitigations, some other process could often just directly read bits of the ephemeral key if it was in cache and could guess the address
21:12:32 <b_jonas> that was just too bad for cryptography in practice
21:13:20 <b_jonas> or similarly, they might be able to read bits of private data in another process, regardless of whether cryptography is involved
21:14:02 <b_jonas> there are still side-channels for lots of things, but hopefully fewer practical ones
21:18:43 <esolangs> [[User:PolySaken]] https://esolangs.org/w/index.php?diff=88094&oldid=84930 * PolySaken * (+252)
21:23:46 <b_jonas> they sent me an encrypted pdf file that I can't open, the pdf reader says incorrect password
21:23:49 <b_jonas> I wonder what could be wrong
21:24:42 <b_jonas> I hope it's not something stupid like I need a newer version of the PDF reader or something
21:25:56 <ais523> who's "they"? this sounds like the sort of thing that people would do if trying to infect your computer with a malicious PDF file
21:26:13 <b_jonas> ais523: no, it's a document that I do expect to receive today in email
21:26:43 <b_jonas> in theory it could be that the one they sent me didn't arrive and some clever targetting spammer send me a similar looking email
21:26:58 <b_jonas> they are a covid PCR testing clinic
21:27:13 <b_jonas> who took PCR test sample from my body earlier today
21:27:34 <b_jonas> and this is supposed to be the paper where they officially claim that their lab analyzed the sample and as far as they know I'm not infected with covid
21:28:48 <ais523> I'm not sure what the motivation to encrypt such a PDF would be
21:29:02 <oerjan> it's health data, obviously
21:29:09 <ais523> I can understand *signing* it, though – perhaps there's some confusion between signing and encrypting
21:29:27 <b_jonas> confidential health data, they're probably required by law to encrypt it
21:29:32 <ais523> but it's very temporary health data
21:30:02 <ais523> it might be important to keep a positive test result secret – maybe you therefore have to keep the negative results secret too, to prevent people figuring it out by elimination
21:30:31 <b_jonas> ais523: or they might want to keep it secret what kind of test they did on me, since they do medical stuff other than covid PCR test
21:30:55 <b_jonas> or even who they did the test on, if I use my email address for testing my hypothetical small child
21:31:37 <b_jonas> but mostly they probably don't have separate rules for not encrypting PCR test results but encrypting other medical documents when they send it in email
21:32:21 <fizzie> I imagine if you have a lot of friends who think the whole thing is a hoax, just the fact of revealing you got a test in the first place might have consequences. I'm not surprised at all they would consider those test results confidential by default.
21:32:56 <b_jonas> fizzie: that doesn't work, since encrypting the contents while the sender is there doesn't really hide the fact that I did a test
21:33:14 <fizzie> Well, it does, because like you said, they do a lot of other things too.
21:33:26 <fizzie> Unless they put "here's your COVID test results" in the unencrypted subject line or something.
21:33:45 <b_jonas> fizzie: in theory yes, but in practice they won't evaluate most of them on a Sunday
21:34:08 <b_jonas> it could be some urgent blood test or something
21:34:22 <b_jonas> but there's a high chance that it's a covid test
21:34:33 <b_jonas> and no, the subject line and even the cleartext body is pretty generic
21:34:47 <fizzie> I wonder if there's some size-based side channel where you can distinguish positive and negative result PDFs just based on file size.
21:35:00 <fizzie> If they put a bunch of more detail in one but not the other, or something.
21:35:01 <b_jonas> it does say laboratory result, and the From address tells which lab
21:36:06 <b_jonas> fizzie: hehe, well there's a much bigger side channel where if it's positive then I'll tell my boss that I won't go into the office, plus they may be required to tell the police that I'm ordered to quarantine myself, but sure
21:37:32 -!- delta23 has quit (Quit: Leaving).
21:42:34 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
21:43:10 <fizzie> Re the other topic, I run fungot now on a KVM/qemu virtual (Alpine) system on the store room PC (itself a Debian). Previously it was running on that system directly (well, in a plain old-fashioned chroot jail). That whole computer's kind of less sensitive, but it does host some nominally private things (metrics, IRC logs, whatnot).
21:43:11 <fungot> fizzie: comments are useful. it's a lot easier. i do use perl fingerprint *could* interact badly with ick has no problem with thinking that way of doing just fnord i said ' c's brain-damaging _syntax_.'
21:45:34 <fizzie> Not that I think fungot is necessarily as problematic as HackEso. You'd probably have to be pretty motivated to do a Spectre-style attack using brainfuck (or Underload) as interpreted through a Befunge interpreter.
21:45:34 <fungot> fizzie: doesn't sound so bad. chicken and plt
21:45:55 <esolangs> [[Gluck]] N https://esolangs.org/w/index.php?oldid=88095 * PolySaken * (+523) Created page with "'''Gluck''' is a successor to [[Clart]], designed by [[User:PolySaken]] to be used for a [[Virtual Machine]]. There are a few major differences from the original Clart rules,..."
21:46:17 <esolangs> [[Gluck]] https://esolangs.org/w/index.php?diff=88096&oldid=88095 * PolySaken * (+8)
21:48:44 <ais523> fizzie: neither BF nor Underload has any way to read the side channel on its own, potentially unless fungot's timeouts are time-based rather than instruction-count-based
21:48:44 <fungot> ais523: he was the guy i thought you meant
21:49:33 <oerjan> fungot: do your interpreters have any zero-day vulnerabilities twh
21:49:33 <fungot> oerjan: will do. the player to start needs to be
21:50:38 -!- tromp has joined.
22:00:47 <esolangs> [[User:PolySaken]] https://esolangs.org/w/index.php?diff=88097&oldid=88094 * PolySaken * (+216)
22:02:08 <esolangs> [[Gluck]] https://esolangs.org/w/index.php?diff=88098&oldid=88096 * PolySaken * (+10)
22:04:24 <esolangs> [[Gluck]] https://esolangs.org/w/index.php?diff=88099&oldid=88098 * PolySaken * (+2)
22:07:55 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:10:08 <esolangs> [[Gluck]] https://esolangs.org/w/index.php?diff=88100&oldid=88099 * PolySaken * (+33)
22:10:11 -!- earendel has quit (Quit: Connection closed for inactivity).
22:10:39 <esolangs> [[Gluck]] https://esolangs.org/w/index.php?diff=88101&oldid=88100 * PolySaken * (+2)
22:10:54 <esolangs> [[Gluck]] https://esolangs.org/w/index.php?diff=88102&oldid=88101 * PolySaken * (-49)
22:14:25 -!- tromp has joined.
22:45:28 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
22:46:46 -!- src has quit (Ping timeout: 252 seconds).
22:58:12 -!- tromp has joined.
23:16:28 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
23:17:59 -!- dutch has quit (Quit: WeeChat 3.2.1).
23:19:06 -!- dutch has joined.
23:22:46 -!- ais523 has quit (Quit: quit).
23:34:26 -!- arseniiv has quit (Ping timeout: 260 seconds).