00:13:48 <esolangs> [[Tsaf]] M https://esolangs.org/w/index.php?diff=86518&oldid=86502 * PythonshellDebugwindow * (+49) /* external resources */ cats
00:33:23 <^[> zzo38: Could you elaborate on "associated" and "key"?
00:33:57 <^[> Do you mean something along the lines of hard or symbolic links?
00:35:45 -!- spirgel_ has quit.
00:44:26 <zzo38> ^[: I mean that if you have a link to two files, that pair of links will be like the name of the temporary file
00:46:29 <^[> But either piece of the pair can't be sufficient on its own to access the contents of the temporary file?
01:29:58 -!- oerjan has joined.
02:09:32 -!- delta23 has quit (Quit: Leaving).
02:15:08 -!- Lord_of_Life_ has joined.
02:16:40 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
02:16:40 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
04:46:11 -!- andydude has joined.
05:10:47 <esolangs> [[PlusOrMinus]] https://esolangs.org/w/index.php?diff=86519&oldid=79476 * Voltage2007 * (-287)
05:24:58 -!- andydude has quit (Quit: andydude).
05:25:44 -!- oerjan has quit (Quit: Nite).
06:29:17 -!- arseniiv has joined.
07:06:23 -!- Lord_of_Life has quit (Read error: Connection reset by peer).
07:06:50 -!- Lord_of_Life has joined.
07:09:55 -!- Sgeo has quit (Read error: Connection reset by peer).
07:34:19 -!- tech_exorcist has joined.
07:51:02 -!- imode has quit (Ping timeout: 255 seconds).
07:59:40 -!- riv has quit (Quit: Leaving).
08:06:35 -!- hendursa1 has joined.
08:08:59 -!- hendursaga has quit (Ping timeout: 244 seconds).
09:08:52 -!- mcfrdy has joined.
09:17:12 -!- pikhq has quit (Ping timeout: 252 seconds).
09:17:21 -!- pikhq has joined.
10:21:16 -!- tech_exorcist has quit (Remote host closed the connection).
10:21:44 -!- tech_exorcist has joined.
10:54:52 <esolangs> [[TextGarbage]] N https://esolangs.org/w/index.php?oldid=86520 * Dominicentek * (+2756) Created page with "TextGarbage (previously named [[Gibberish]] but that's already taken) is an esoteric programming language created by [[User:Dominicentek]]. It's commands are only 1 character..."
10:55:28 <esolangs> [[User:Dominicentek]] https://esolangs.org/w/index.php?diff=86521&oldid=86246 * Dominicentek * (+48)
10:57:22 <esolangs> [[Gibberish (programming language)]] M https://esolangs.org/w/index.php?diff=86522&oldid=49043 * Dominicentek * (+35) /* See also */
10:58:22 <esolangs> [[TextGarbage]] M https://esolangs.org/w/index.php?diff=86523&oldid=86520 * Dominicentek * (+54)
10:59:14 -!- PinealGlandOptic has quit (Quit: leaving).
11:19:44 <esolangs> [[Language list]] https://esolangs.org/w/index.php?diff=86524&oldid=86509 * Dominicentek * (+18) /* T */
12:04:07 -!- arseniiv has quit (Ping timeout: 265 seconds).
12:55:55 -!- arseniiv has joined.
13:15:18 <esolangs> [[PlusOrMinus]] M https://esolangs.org/w/index.php?diff=86525&oldid=86519 * PythonshellDebugwindow * (-4) Headers
13:16:11 -!- slavfox_ has joined.
13:18:44 -!- Corbin has quit (Ping timeout: 255 seconds).
13:18:44 -!- slavfox has quit (Ping timeout: 255 seconds).
13:18:46 -!- jix has quit (Ping timeout: 255 seconds).
13:18:46 -!- b_jonas has quit (Ping timeout: 255 seconds).
13:18:46 -!- Cale has quit (Ping timeout: 255 seconds).
13:18:46 -!- jix has joined.
13:18:46 -!- slavfox_ has changed nick to slavfox.
13:18:58 -!- b_jonas has joined.
13:19:15 -!- jix has quit (Client Quit).
13:19:30 -!- jix has joined.
13:19:36 -!- Cale has joined.
13:23:07 -!- tech_exorcist has quit (Quit: tech_exorcist).
13:30:10 -!- Guest8999 has joined.
13:33:13 <fizzie> Yes? Maybe. Who knows.
13:34:04 <Guest8999> is the discord more active than the IRC or?
13:36:37 <Taneb> There's a discord?
13:36:42 <Taneb> This place is pretty active
13:37:28 <fizzie> There's at least two discords.
13:37:37 <fizzie> I think there was some sort of a factional schism between them?
13:38:10 <fizzie> (All I know about the topic is what I read between the lines from the community portal page.)
13:48:30 <Guest8999> I'm about to submit a revision but still not sure about whether I should or not
13:48:56 <Guest8999> completely alters the explanation for Deadfish/Constants, page hasn't been touched for 6 years
14:33:23 -!- delta23 has joined.
14:39:32 -!- Sgeo has joined.
14:46:08 -!- ecs has joined.
14:48:27 -!- Thelie has joined.
14:51:04 -!- Guest8999 has quit (Quit: Client closed).
15:07:16 <esolangs> [[TextGarbage]] M https://esolangs.org/w/index.php?diff=86526&oldid=86523 * Dominicentek * (+56) Added interpreter
15:08:57 <fizzie> The words "pretty active" may have been overselling it a little.
15:12:41 <Taneb> It's more active than other IRC channels I'm in!
15:12:50 <Taneb> There's sometimes even multiple conversations a day!
15:17:14 -!- hendursa1 has quit (Quit: hendursa1).
15:17:39 -!- hendursaga has joined.
15:28:58 <b_jonas> hmmm... I should look up those Discords. I use Discord now, and might as well look what we direct people to from the wiki
15:37:14 -!- Thelie has quit (Remote host closed the connection).
15:37:43 <fizzie> Someone moved Esolang:Community portal to Help:Community portal.
15:38:44 <fizzie> For no apparent reason that I can think of.
15:42:31 <b_jonas> and all the links point to the former
15:43:21 <b_jonas> even the sidebar links to the former
15:43:58 <fizzie> Yeah, it's just going to be a little noisy. But "Help:" isn't a namespace we really use -- there's just two redirects *from* Help: to Esolangs: namespace pages, and two very random pages (Help:Dottyweb and Help:Too vague) in it. https://esolangs.org/wiki/Special:AllPages?from=&to=&namespace=12
15:44:00 <b_jonas> and it's a new user, that's their only edit after Introduce yourself
15:44:34 <fizzie> I think I'll move it back with a description suggesting discussing on the talk page if there's a specific reason why it would be better under Help:.
15:44:37 <b_jonas> no [[Help: I'm stuck in a wiki factory]] or similar? ok
15:46:57 <esolangs> [[Special:Log/move]] move_redir * Fizzie * moved [[Help:Community portal]] to [[Esolang:Community portal]] over redirect: Revert "Community portal" page back to "Esolangs" namespace - please discuss on talk page if there's a reason why "Help" would be better
15:46:57 <esolangs> [[Special:Log/move]] move_redir * Fizzie * moved [[Help talk:Community portal]] to [[Esolang talk:Community portal]] over redirect: Revert "Community portal" page back to "Esolangs" namespace - please discuss on talk page if there's a reason why "Help" would be better
15:46:57 <esolangs> [[Special:Log/delete]] delete_redir * Fizzie * Fizzie deleted redirect [[Esolang:Community portal]] by overwriting: Deleted to make way for move from "[[Help:Community portal]]"
15:46:57 <esolangs> [[Special:Log/delete]] delete_redir * Fizzie * Fizzie deleted redirect [[Esolang talk:Community portal]] by overwriting: Deleted to make way for move from "[[Help talk:Community portal]]"
15:48:15 <fizzie> Of course I got the namespace wrong ("Esolangs" vs. "Esolang") in the edit message. :/
15:48:26 <b_jonas> that's why I type Project:
15:48:39 <b_jonas> easy to type and works on basically all mediawikis
15:48:49 <fizzie> Singular project name + plural domain is a good combination.
15:49:00 <b_jonas> no need to learn the localized names of the wikis
15:49:14 <b_jonas> in wikimedia projects those are so random in languages
15:49:22 <b_jonas> some were even changed after they got created
15:51:42 <b_jonas> the namespace should have been called Meta: originally, but it's too late for that now
15:52:06 -!- imode has joined.
15:52:06 <fizzie> In any case, what I was *going* to say before I got distracted by the move was, there was some mild edit-warring on Community portal (around March 2021) regarding what seemed to be like some sort of a disagreement between the two Discord servers.
15:54:22 <fizzie> By the way, are those things called "servers" because you actually host them in some way, or is it something you just set up on the singular service provider's infrastructure?
15:54:36 <b_jonas> "server" is completely inappropriate
15:54:48 <fizzie> Thanks, I've been wondering.
15:54:58 <b_jonas> they're just a group of channels with shared moderators/owners
15:55:49 <b_jonas> or at least shared main owners by default, I think you can set more fine-grained permissions for moderation under them
16:04:49 -!- riv has joined.
16:26:42 -!- Corbin has joined.
16:26:46 <int-e> https://www.chiark.greenend.org.uk/~sgtatham/puzzles/js/loopy.html#10x10t0dh#316277475083927 has way too many 2-s.
16:38:54 -!- tech_exorcist has joined.
16:48:27 <Melvar> I think the discord servers are actually called “guilds” in the API. Because it’s supposed to be a thing for gaming groups.
17:03:33 <esolangs> [[TextGarbage]] M https://esolangs.org/w/index.php?diff=86529&oldid=86526 * Dominicentek * (+7) Fixed example
17:10:03 <int-e> I guess "group" was too mundane when they were looking for more mainstream nomenclature.
17:21:29 <fizzie> Clan, tribe, cult, sect, clique, coterie, ... lots of words they could've used.
17:21:33 <Melvar> I think maybe a group refers to “group dm”, i.e. a pseudo-channel located in one’s private messages rather than in a guild.
17:23:08 <fizzie> `` wn coterie -over | tail -n1
17:23:10 <HackEso> 1. clique, coterie, ingroup, inner circle, pack, camp -- (an exclusive circle of people with a common purpose)
17:27:14 <int-e> fizzie: these all seem to have weird connotations
17:28:52 <zzo38> I think that IRC is much better than Discord with many ways, inclduing that you do not need to use their service and you do not need any Discord software to access IRC, you can use it even without IRC software too (although it works better if you do have, still it is at least doable without). Although some have bridges to connect between IRC and Discord (and possibly other protocols/services too)
17:30:24 <zzo38> The IRC for ZZT discussions is a bridge with the Discord that I had suggested and someone implemented it, I think there are only two people who mainly use the IRC (I am one of them)
17:33:11 <zzo38> I saw a program that is bridging many more services/protocols too than just that (although I have not used it)
17:35:32 <zzo38> You mention the "Help:" namespace in wiki is not of much use, but a summary of the wiki formatting might be a thing to put there, I suppose
17:39:52 <riv> IRC doesn't have images or voice calls though
17:41:32 <fizzie> I don't have strong opinions on what should live in the "Esolang" (project) namespace vs. "Help" namespace, I just didn't see a particular reason to move Esolang:Community portal, especially since it has a links to the old name. Things that are clearly more help-pagey could be there, I suppose, though it seems we've opted to redirect Help:Contents and Help:Editing to Esolang:Help instead.
18:20:27 <oren> It seems to be impossible to do separate compilation in safe Rust
18:21:17 <oren> A rust file cannot declare an external Rust function and call it without a unsafe {}
18:23:01 <keegan> what do you mean by separate compilation? each crate is compiled separately
18:23:36 <keegan> if you mean building .o files from two crates completely independent of each other and then linking them together then yes, that has to go through the C ABI
18:23:56 <oren> yes I mean separate compilation
18:24:28 <keegan> the native rust model is that you don't have header files, rather the metadata embedded in an already-compiled crate is what provides the information needed for safe and high-level linking
18:25:52 <keegan> so you have to build a crate before you can build something that depends on it
18:26:05 <keegan> and you can't have circular dependencies between crates
18:26:34 <keegan> (but you can have circular deps between the modules / .rs files within a single crate, because those are all combined into one logical AST and compiled at once)
18:26:46 <keegan> (modules are the unit of namespacing and visibility; crates are the unit of compilation and linking)
18:27:36 <oren> Why is the metadata not included inside the .o file
18:28:29 <keegan> it's included in a .rlib file which is Rust's version of a .o file
18:28:36 -!- tech_exorcist has quit (Quit: tech_exorcist).
18:28:45 <keegan> you rarely encounter raw .o files in a rust project
18:28:56 <keegan> only if you're making a component that will be linked into a C / C++ / other old school system
18:29:55 <oren> Okay. Can I compile two .rs files into their respective .rlib files and then link them into an executable?
18:30:06 <keegan> the point though is that the equivalent to a header file is generated by the compiler, not written by the programmer, and therefore you need to compile a crate before you can compile things that depend on them
18:30:21 <keegan> oren: yes but not independently of each other. you have to compile one before the other can import it
18:30:50 <keegan> because the .rlib contains the information equivalent to what a header file provides in C++
18:30:54 <keegan> function signatures, types, etc
18:31:47 <keegan> it's rare to be mucking around at this level
18:31:51 <keegan> almost all rust projects use cargo
18:32:05 <keegan> which handles all this stuff
18:32:31 <keegan> you just say what crates you want to use and they are built and made available
18:33:01 <keegan> it's nice, but it's not the same as C or C++, so if you want to force it to work the way C or C++ works then you'll probably have a bad time
18:33:23 <oren> But I don't want to download all my dependencies and recompile them every time
18:33:31 <keegan> it doesn't recompile them every time
18:33:35 <keegan> it's cached in the build directory
18:33:44 <keegan> and also downloads are cached systemwide i think
18:34:06 <keegan> idk it's been a long time since i worked with this stuff
18:34:09 <keegan> maybe you should ask in a rust help channel
18:38:05 <keegan> cargo can also handle local deps and not only stuff downloaded from crates.io
18:38:26 <keegan> you can have a whole tree of crates each containing many modules and build the whole thing with a single cargo invocation
18:38:37 <keegan> and it will cache results and only rebuild what it needs to
18:39:21 <keegan> crates are typically pretty big though. an entire library or a substantial chunk of one
18:39:53 <keegan> when C was invented in nineteen dickety twelve computers had tiny amounts of RAM and it made sense to compile practically every function separately and then link them
18:40:19 <keegan> these days whole-program or whole-library compilation is common even in the C/C++ world
18:41:21 <oren> I did on a rust discord.... apparently noone ever tried to uhhh
18:41:21 <oren> declare an extern "rust" { fn b(x:i32) -> i32; } and then call it
18:41:21 <oren> like, the rust compiler doesn't trust itself to generate safe object code
18:41:35 <keegan> since Rust is a newer design it went with a larger default for compilation unit size; all the .rs files within a crate are a single compilation unit and can refer to each other
18:42:18 <keegan> Rust doesn't have a stable ABI; if you built such extern "rust" stuff with two different compiler versions and then linked it, you could get undefined behavior
18:42:40 <keegan> do you have an actual reason to do things this way instead of the way you're supposed to?
18:43:16 <keegan> if you pretend that Rust is the same as C with externs and header files and independent compilation then you're gonna have a bad time
18:45:52 -!- oren has quit (Ping timeout: 252 seconds).
18:46:11 -!- oren has joined.
18:46:13 <keegan> just because it's a systems language, does not mean that they have to do everything the same way C does it based on design constraints that are 60 years out of date
18:47:20 <oren> separate compilation means that an error in once file doesn't cause every other file to not compile
18:48:11 <keegan> you can't compile a crate without first compiling its dependencies
18:48:33 <keegan> i'm hardly a rust stan so if you think this means rust is garbage then feel free
18:49:07 <b_jonas> keegan: yes, and this model with crates only works if (1) you recompile everything, because the ABI isn't yet stable between versions of rust, and (2) you don't have circular dependencies among crates. Otherwise, you have to use the C model of exporting a stable foreign interface with a stable C ABI, importing those with explicit header files (this can be done in pure rust, no C bridge), then your ABI
18:49:13 <b_jonas> is stable and you can have circular dependencies and don't have to rebuild everything when you upgrade the compiler.
18:49:38 <keegan> but you lose the ability to use rust's expressive types in your interface
18:49:56 <keegan> you're really not supposed to have circular dependencies between crates
18:49:57 <b_jonas> The choice of which one you want to do is yours. And I think, "future" C++ is moving towards this model too, with new style C++ modules or whatever they're called, and GHC already used this model with Haskell.
18:50:22 <oren> But like... the only thing preventing me from calling the function is rustc's insistence that doing so is unsafe
18:50:28 <keegan> it's very similar to GHC except that GHC keeps the .hi files separate from .o files, whereas Rust bakes it into a special metadata section (and calls the result a .rlib)
18:50:30 <b_jonas> keegan: yes, but I don't particularly mind losing those types, because I'm a C++ programmer and I know how I want to represent my data, especially between compilation units, so I don't feel like that's a drawback.
18:50:44 <b_jonas> keegan: the drawback is that the import header isn't typechecked to the export header.
18:50:50 <b_jonas> Is there a way to automate that?
18:50:55 <keegan> oren: it is unsafe, because you could link objects created with different rustc versions that compile the same type in different ways
18:51:22 <oren> But the object files contain metadata that says what they were generated by
18:51:48 <keegan> oren: but what if the object files don't exist yet?
18:52:07 <keegan> if you already compiled the other crate then you don't need this nonsense
18:52:12 <keegan> you can just use it in the normal supported way
18:52:30 <keegan> with 'extern crate' or whatever it is these days
18:52:52 <keegan> you objected to the idea that you have to compile a crate before you can compile things that depend on it
18:53:30 <oren> yes. I'm saying that if it's so scared of linking to object files generated by a different version, then it could raise an error at link time
18:53:30 <keegan> because then it's not "separate compilation"
18:54:17 <oren> (since, rustc's .o files actually don't work with any linker besides rustc afaict)
18:54:35 <keegan> i suppose it could also check at link time that your declared headers match what was in that metadata
18:54:40 <keegan> still, i don't see the point
18:54:48 <keegan> i'm not saying it's impossible to implement this feature
18:54:56 <keegan> but it doesn't really fit with the rust compilation model
18:55:15 <oren> The point is to enable a separation of concerns between what happens inside a library and what happens outside
18:55:25 <keegan> that's just the crate system
18:55:41 <keegan> i think you should study how rust works more before you assume they don't have solutions to such basic problems
18:56:17 <keegan> your objection seems to be that I can't compile my project without first compiling its dependencies, and this means I can't find errors in my code if the dependencies don't build
18:56:32 <keegan> however, obviously those errors may depend on what's actually in those dependency crates
18:56:49 <keegan> if i used some function or type from a library wrong, then it needs to know what's in that library to know i used it wrong
18:57:04 <keegan> whether by compiling it or just having a header file for it (as in C/C++)
18:58:15 <keegan> fwiw it's common in large projects to put a bunch of types and traits in their own crate that everything else depends on
18:58:26 <keegan> and this decreases the potential for circular dependencies between those other crates
18:58:47 <keegan> you can use the trait system kind of like header files
18:59:17 <keegan> where one bit of code operates on a generic type bounded by a trait
18:59:26 <keegan> and another bit of code (which could be in a separate crate) provides the concrete implementation
18:59:46 <keegan> and those two pieces can be compiled independently because they only depend on the core "types" crate
18:59:47 <oren> You also can't change a library without recompiling all calling code
19:00:07 <keegan> (the actual machine code generation still happens at the end though)
19:00:09 <oren> seems ripe for a leftpad problem
19:00:13 -!- Guest89 has joined.
19:01:04 <keegan> seems unrelated to leftpad though
19:01:11 <keegan> that wasn't a compilation issue (javascript isn't even compiled)
19:01:22 <keegan> it's just that someone pulled a library that a lot of people depended on
19:01:38 <keegan> there are lots of ways to deal with that in rust without needing to change the compilation model
19:02:08 <keegan> one is just to vendor your dependencies
19:02:49 <keegan> also crates.io is designed so that once you "yank" a crate people who were already using that version can still use it
19:04:05 <keegan> there's no supported way to take your code off crates.io permanently
19:05:02 <keegan> of course the site admins could still do it
19:05:12 <keegan> if you pushed a crate with nuclear secrets or child porn or something
19:06:42 -!- hendursaga has quit (Ping timeout: 244 seconds).
19:08:08 <keegan> if your point is just that rust encourages you to have lots of transitive dependencies then i agree
19:08:14 <keegan> that's the tradeoff for making code reuse really easy
19:08:17 <keegan> people start reusing code
19:08:40 -!- hendursaga has joined.
19:09:04 <keegan> i know it makes many people and organizations nervous to pull lots of code from the internet willy nilly and that's valid
19:09:12 <keegan> and they can set whatever policy about using external crates they like
19:09:52 <keegan> i believe there are even ways to host your own local crates.io-like repository for your organization that contains only your trusted crates
19:09:58 <keegan> and use that on your airgapped build machines
19:11:13 <keegan> i'd rather at least have the option to reuse code rather than the C world where external libraries are such a pain and cause so much user bitching (ask me how i know) that every project just hand rolls their own broken shitty implementations of basic data structures and algorithms
19:11:19 -!- delta23 has quit (Quit: Leaving).
19:41:32 <oren> external libraries are very common in C ??*
19:41:55 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86530&oldid=86162 * Dtuser1337 * (+63)
19:44:52 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86531&oldid=86530 * Dtuser1337 * (-14) /* Function Commands */
19:45:04 <pikhq> They are but they’re a complete pain in the ass to use, so there’s strong incentives to minimize their use.
19:45:13 -!- Guest89 has quit (Quit: Client closed).
19:46:01 <keegan> when i was a mosh maintainer we got so much shit over every external dependency
19:46:11 <keegan> from distros with weird packaging requriements and from users who want to build on ancient systems etc
19:46:24 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86532&oldid=86531 * Dtuser1337 * (+54) /* Function Commands */
19:46:37 <keegan> so yes I did reimplement some of the smaller things just to avoid those headaches
19:46:38 <pikhq> (And if you think they aren’t, I suggest you get acquainted with other language environments, at least to know what alternate environments can look like)
19:47:40 <oren> Rust gets around this my just not working on any exotic environments
19:48:14 <shachaf> I'd much rather the C model than the npm model.
19:49:05 <pikhq> I want an actually good model. If such a thing can exist.
19:49:25 <pikhq> I think it’s a hard problem though.
19:49:58 <keegan> there were several scrapped attempts to make a dependencies and build system for Rust before the current Cargo system
19:50:27 <keegan> when I was working on servo, Cargo in its current form didn't exist
19:50:37 <keegan> we used complex makefiles and it was a mess
19:50:38 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86533&oldid=86532 * Dtuser1337 * (+96) /* Function Commands */
19:50:48 <oren> I mean the rust model could be made to work by uhh... just having the compiler trust external rust code to be valid rust code. I get the ABI issue but just... idk they have to have a stable aBI eventually right?
19:51:04 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86534&oldid=86533 * Dtuser1337 * (+1) /* Function Commands */
19:51:05 <shachaf> Now I'm thinking something that's probably slightly moralizing, along the lines of, the experience of doing a thing should be similar to its actual cost.
19:51:21 <keegan> it took C++ decades to have a stable ABI on common platforms
19:51:40 <keegan> have you seen what goes into a document like that?
19:51:46 <keegan> the Rust language is still evolving pretty quickly
19:51:51 <keegan> they are able to maintain backwards compat at the source level
19:51:57 <keegan> but maintaining ABI compat is a whole different issue
19:52:18 <keegan> I think stable ABI is a long-term goal but it's fairly far down the list
19:52:26 <keegan> it doesn't solve a pressing problem for most users
19:52:46 <keegan> whereas the things that stable ABI would impede (faster development of new language features) do
19:53:28 <pikhq> Cargo, and failing that, having the external ABI of a library be C-shaped, seem to be good enough for most use cases for now.
19:53:49 <keegan> most people have no problem with the fact that you have to compile a crate's dependencies first
19:53:56 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86535&oldid=86534 * Dtuser1337 * (+154) /* Function Commands */
19:54:15 <shachaf> C interfaces are generally much better than C++ interfaces, between different components of a system. You probably don't need C++ interfaces for anything.
19:54:40 <shachaf> Components should be coarse-grained with no ABI stability inside a component.
19:55:30 <keegan> it's true that compile times are a common pain point
19:55:33 <keegan> but that's only somewhat related
19:55:41 <keegan> since only the crates that have changed, and crates that depend on them, will be rebuilt
19:55:45 <keegan> and in many cases that's unavoidable
19:56:04 <keegan> if I change a type in some library crate then I have to recompile everything that uses that library at least as far as checking that it uses the new type correctly
19:56:39 <keegan> certainly you can get nightmare situations in C when you change a header file and don't recompile the corresponding library
19:58:19 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86536&oldid=86535 * Dtuser1337 * (+302) /* Implementation Dependent Commands */
19:59:11 <zzo38> I would rather to not have too many external dependencies, regardless of what programming language it is
19:59:21 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86537&oldid=86536 * Dtuser1337 * (+1) /* Implementation Dependent Commands */
20:00:36 <keegan> oren: anyway it's not just a matter of trusting that the same ABI was used, you also have to trust that the "header files" or equivalent faithfully represent the code in the library you're linking against
20:00:57 <keegan> right now that is accomplished by making them a side product of the compilation of the library itself
20:01:31 <keegan> this is very convenient, it means all the information used by the compiler as it compiles the library is also available to describe how to link the library
20:02:07 <keegan> if you moved to a system of manually written header files, not only would that be more work for the programmer, but the compiler would still need to generate this metadata so that the linker can check the manually written header file against it at link time
20:02:16 <keegan> otherwise you have the possibility of undefined behavior
20:03:01 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86538&oldid=86537 * Dtuser1337 * (+238) /* File I/O Commands */
20:03:17 <oren> i don't advocate manually writing header files
20:03:45 <keegan> your 'extern "rust" { ... }' block serves the purpose of a header file
20:04:04 <oren> Yes because that is currently the only way
20:04:22 <keegan> GHC supports manual header files in the form of .hs-boot. but if you screw up and don't faithfully represent the corresponding .hs file then your code can segfault
20:04:36 <oren> What I'd like is a system that works like this:
20:04:54 <keegan> oren: look, the type signatures for a library have to come from somewhere. either they are a product of building the library (the current Rust solution) or they are written by the programmer (C solution)
20:04:56 <oren> rustc --generate-headers a.rs -o a.rsh
20:05:42 <oren> But see, that is a *separate* step from the step of compiling object code
20:05:59 <keegan> and what if there's a syntax error in a.rs
20:06:17 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86539&oldid=86538 * Dtuser1337 * (+4) /* File I/O Commands */
20:06:19 <keegan> but your goal for separate compilation was that the deps don't even need to build properly in order to use them
20:06:41 <keegan> what's the point of making this a separate step anyway?
20:06:43 <oren> Correct. if a.rs fails to build, you still have old a.rsh
20:07:02 <keegan> and what if you change a.rs and don't rebuild the a.rsh?
20:07:16 <keegan> now it might have inaccurate signatures
20:07:20 <keegan> and your code can segfault
20:08:08 <keegan> anyway if you're talking about manually invoking rustc then you're probably doing something wrong
20:08:23 <keegan> 99.9% of rust users use cargo
20:08:31 <keegan> which already has a comprehensive solution for dependencies
20:08:35 <keegan> whether local or downloaded
20:09:01 <oren> the entire point is that you can make changes in a.rs that *don't* change the signatures of externally visible functions, and in that case, *only* a.rs, and not the files using it, need to be recompiled.
20:09:21 <shachaf> None of this would be an issue if the compiler wasn't so slow, right?
20:09:47 <keegan> I think the more rusty way to do this would be to compare the old and new metadata emitted by compiling a.rs
20:09:57 <keegan> and if they match then don't recompile things that depend on it
20:10:11 <keegan> then there is no separate .rsh file and no janky manually regenerating it
20:10:33 <keegan> but I think you'll find that most of the time changes really do require downstream libs to be rebuilt
20:10:37 <keegan> especially when generics come into play
20:10:45 <keegan> remember Rust monomorphizes generics
20:11:05 <keegan> you know how templated C++ libraries are entirely header files?
20:11:18 <oren> templates are bad
20:12:01 <keegan> Rust's generics are a bit saner semantically than C++ templates, but the compilation strategy is the same
20:12:08 <oren> Yes, and that makes Rust bad
20:12:22 <riv> rust has macros
20:13:12 <keegan> it sounds like you have ample reasons not to use Rust and that separate compilation is not the one thing holding you back
20:13:29 <keegan> i don't use rust either
20:13:49 <keegan> i don't really have a use case for it anymore and i don't like the community and i don't enjoy programming for its own sake
20:13:50 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86540&oldid=86539 * Dtuser1337 * (+322)
20:15:17 <Melvar> Other amusement: with GHC IIUC the ABI doesn’t just differ between versions, but is also different if you’re compiling with profiling (because all heap objects have to have extra metadata for that).
20:15:53 <shachaf> GHC also generates different memory layout for types with optimizations on.
20:15:58 <keegan> and threaded vs unthreaded runtime
20:16:05 <oren> doesn't GHC use C as a IL tho
20:16:14 <keegan> oren: usually not, these days
20:16:48 <keegan> as of a few years ago they removed the peformance-oriented via-C backend
20:16:59 <keegan> keeping only the "unregisterized" version for support of obscure platforms
20:17:01 <Melvar> I think the answer is “sort of”, in that it uses a C-- representation internally at one point, but this is not written out or fed to a separate compiler.
20:17:15 <keegan> Cmm is not really anything like C
20:17:27 <keegan> it is an IR similar in purpose to LLVM
20:17:45 <keegan> the start of GHC development predates LLVM by a long time so they had to make their own IR
20:17:46 <Melvar> Okay sorry, don’t really know anything about its structure.
20:18:12 <Melvar> Yeah, and nowadays there actually *is* an LLVM backend apparently?
20:18:20 <keegan> the pipeline these days is like AST -> Core -> STG -> Cmm -> LLVM -> machine code
20:18:27 <keegan> or direct from Cmm to machine code
20:18:46 <keegan> the direct-to-asm backend is faster to compile but supports fewer architectures and has fewer optimazitons
20:19:11 <keegan> the "registerized" (perf-oriented C) backend was basically there to piggyback on GCC backend optimizations
20:19:19 <keegan> the stuff it generated was not portable C in any sense
20:19:23 <keegan> it was grotesquely GCC specific C
20:19:38 <keegan> and the assembly output of GCC would be further postprocessed by a 4,000 line Perl script known as the Evil Mangler
20:20:05 <keegan> because some basic things you need in a functional lang backend IR (like computed tail calls) are impossible to represent in portable C
20:20:10 <keegan> anyway that whole nasty mess is gone
20:20:17 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86541&oldid=86540 * Dtuser1337 * (+417) /* loadallfile() */
20:20:32 <keegan> and remains only the relatively saner "unregisterized" C output which does not try to be performant
20:20:43 <keegan> they may have removed that too in the years since i stopped paying attention
20:21:08 <Melvar> I’m pretty sure it still exists, but the only reason it does is to allow bootstrapping ghc to a new architecture.
20:21:15 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86542&oldid=86541 * Dtuser1337 * (+2) /* loadallfile() */
20:21:31 <keegan> i had some fun trying to bootstrap GHC onto ARM Android long ago
20:21:37 <oren> GHC had perl as a dependency? wild
20:21:55 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86543&oldid=86542 * Dtuser1337 * (+28) /* Function Commands */
20:22:10 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86544&oldid=86543 * Dtuser1337 * (+0) /* Function Commands */
20:22:16 <keegan> other fun facts about GHC internals: GHCi has its own multiplatform dynamic linker
20:22:18 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86545&oldid=86544 * Dtuser1337 * (+6) /* Function Commands */
20:22:26 <keegan> this means that despite being an "interpreter" it is the least portable part of GHC
20:22:51 <keegan> getting ghci to work on a new platform is a whole additional can of worms
20:23:17 <keegan> it works this way because they want to call into native code compiled haskell libs from bytecode-interpreted code
20:23:34 <keegan> i'm not sure why they don't use dlopen() or some other standard mechanism for code loading
20:23:41 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86546&oldid=86545 * Dtuser1337 * (-4) /* Stacks */
20:23:43 <keegan> but there are probably reasons
20:24:00 <keegan> compiled Haskell code looks very different from compiled C code
20:24:12 <keegan> there aren't really any functions in the sense of call/ret pairs
20:24:29 <keegan> as i recall most basic blocks end in a computed jump
20:24:32 <Melvar> Of course, architecture support is entwined with having a runtime implementation that works on that architecture and the primitives that call into it.
20:24:38 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86547&oldid=86546 * Dtuser1337 * (+1) /* Commands */
20:24:45 <keegan> this is the nature of the spineless tagless G-machine (which is neither spineless nor tagless, oh well)
20:25:03 <keegan> there isn't a normal call stack either
20:25:17 <keegan> except when you make a FFI call then obviously it has to set up a C like stack
20:25:30 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86548&oldid=86547 * Dtuser1337 * (-5) /* Implementation Dependent Commands */
20:25:33 <oren> well, it makes sense not to use a call stack because it would be huge
20:25:35 <keegan> and this gets into the difference between "safe" and "unsafe" FFI calls
20:26:27 <keegan> debugging ghc produced code in gdb is great fun
20:27:10 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86549&oldid=86548 * Dtuser1337 * (-19) /* Simple Calculator */
20:28:46 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86550&oldid=86549 * Dtuser1337 * (+13) /* Function Commands */
20:29:10 <Melvar> Fun stuff: I was recently wondering if, in a data constructor with multiple unboxed Word8# fields, those fields would be packed efficiently or be put into a word each. I couldn’t find an answer online, but I did find that GHC exposes some heap introspection modules so I could, after some back and forth, create such a value and then get info about the heap object representing it.
20:29:57 <keegan> oh yeah that stuff is fun
20:29:59 <Melvar> (I found that the Word8#s were in fact packed into one word.)
20:31:02 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86551&oldid=86550 * Dtuser1337 * (-68) /* Simple Turn-based Game */
20:32:09 <b_jonas> So much discussion here, I'll have to check the scrollback.
20:32:24 <b_jonas> I was doing esoteric experiments with factorio, and there are more esoteric experiments that I want to try.
20:33:23 <Melvar> I was wondering this in the first place because a beginner came around asking if there was any lower-overhead type for 32-byte blobs that they needed to be handling a lot. Even a primitive ByteArray# is boxed and stores its own length and thus has two words of overhead, so even a Short Bytestring that wraps it has four words of overhead, which is as big as the payload on 64-bit.
20:35:12 <esolangs> [[TextGarbage]] https://esolangs.org/w/index.php?diff=86552&oldid=86529 * Dtuser1337 * (-2) /* See also */
20:35:58 <Melvar> So I had the harebrained idea that the lowest-overhead option (two words) would be a data constructor with four Word64# fields, but that means you have to do bitshifting and masking to get at individual bytes.
20:36:15 <b_jonas> keegan: in rust, can I export and import foreign functions with a C-like API but rust mangling of the names, and does that mangling contain partial type information like in C++ mangling?
20:36:35 <Melvar> So I started wondering whether a data constructor with 32 Word8# fields would be efficiently packed.
20:36:59 <b_jonas> I guess I should ask in ##rust insteead
20:39:29 <Melvar> (There was another harebrained solution I thought of, which was to use an LLVM-backend-specific SIMD vector type.)
20:39:53 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86553&oldid=86551 * Dtuser1337 * (+2) /* Function Commands */
20:45:21 <Melvar> (Passing around a Word8X32# should have zero overhead, right?)
20:47:53 <zzo38> In some C codes I have passing and returning a structure of two 32-bit integers. How efficiently is that implemented on 64-bit x86 Linux?
20:49:46 <esolangs> [[FlinnScrip]] https://esolangs.org/w/index.php?diff=86554&oldid=86553 * Dtuser1337 * (+27)
20:50:54 <zzo38> typedef struct { union { Sint32s; Uint32 u; }; Uint32 t; } Value; Also what will it be on the other computers too? How does it compare to the use of a 64-bit integer type?
20:51:52 <riv> i think its better to use integers
20:52:02 <riv> bitshifting
20:52:02 <fizzie> At least in terms of the x86-64 sysV ABI, I don't think there's much of a difference between that and a 64-bit integer type.
20:52:17 <fizzie> It does get returned in a single 64-bit register.
20:56:54 <b_jonas> fizzie: I don't think so: in the x86-64 calling convention, plain vector types are returned in a register, if it's just one vector, not a structure with multiple vectors
20:57:26 <b_jonas> I mean it is returned in a vector register, not a general register, which may be better or worse
20:57:28 <fizzie> `` echo -e '#include <stdint.h> \n typedef struct { union { int32_t s; uint32_t u; }; uint32_t t; } Value; Value foo(void) { return (Value){ .u = 0x01234567, .t = 0x89abcdef }; }' | gcc -x c - -o - -S -O2 | grep -v '\.' | grep -A 2 'foo:'
20:57:30 <HackEso> foo: \ movabsq$-8526495043095935641, %rax \ ret
20:57:34 <fizzie> See, it gets returned in rax.
20:58:36 -!- arseniiv has quit (Ping timeout: 252 seconds).
20:59:15 <b_jonas> fizzie: that uses integer types, not SIMD vector types
20:59:23 <fizzie> Yes, but so did the question.
20:59:48 <fizzie> "If the class is INTEGER, the next available register of the sequence %rax, %rdx is used."
21:00:52 <fizzie> `` echo -e '#include <stdint.h> \n typedef struct { uint32_t a, b, c, d; } Value; Value foo(void) { return (Value){ .a = 1, .b = 2, .c = 3, .d = 4 }; }' | gcc -x c - -o - -S -O2 | grep -v '\.' | grep -A 3 'foo:' # returned in those two GPRs
21:00:54 <HackEso> foo: \ movabsq$8589934593, %rax \ movabsq$17179869187, %rdx \ ret
21:02:29 <b_jonas> fizzie: Melvar mentioned "SIMD vector type" and "Word8X32#"
21:02:55 <fizzie> Well, I was answering zzo38's question.
21:03:14 <int-e> hmm, actually, does gcc have an option to produce hex literals in assembly?
21:04:18 <b_jonas> so I was looking at a wrong question
21:04:35 <int-e> (probably not, but it would really be helpful sometimes)
21:04:43 <fizzie> And I wasn't looking at the backscroll at all, so I didn't even realize there was a question it could be confused with.
21:05:00 <b_jonas> there was so much backscroll\
21:05:01 <int-e> `` dc <<<16o8589934593p17179869187p
21:05:15 <b_jonas> and my head is still full with testing esoteric designs in factorio
21:05:25 <fizzie> int-e: I don't think it does, but clang puts the hex version in a comment.
21:05:41 <b_jonas> because there are so many different possibilities to test, and some of them behave in an unpredictable way that takes a long time to converge to some equilibrium
21:05:53 <b_jonas> (that's of course because I'm testing those tricky cases specifically)
21:06:27 <b_jonas> It started with asking an innocent question, and the answer turns out to be... maybe, it depends on a lot of factors
21:06:47 <fizzie> No clang in the HackEso installation. But it produces `movabsq $8589934593, %rax # imm = 0x200000001` + `movabsq $17179869187, %rdx # imm = 0x400000003`.
21:21:28 <int-e> Hmm, why does xboard consult a chess program to check the legality of move, and why do said chess programs have trouble with black's moves in b1bkb1b1/1b1b1b1b/b1b1b1b1/1b1b1b1b/b1b1b1b1/1b1b1b1b/b1b1b1b1/1bBbKb2 ...
21:22:57 <int-e> err, that's missing the missing the w - - 0 2 part (white to move, etc.)
21:32:51 -!- mnrmnaugh has joined.
22:16:25 <b_jonas> int-e: what notation is that?
22:17:05 <b_jonas> is that like a checkered pattern of black bishops?
22:17:14 <b_jonas> why does it have "1" everywhere instead of a column number?
22:17:14 <int-e> With one hole at h1, yes.
22:17:26 <int-e> 1 is for one empty square
22:17:57 <b_jonas> oh, so this is like a RLE, not like the other kind of encoding that uses absolute column numbers to fill with empty squares
22:19:12 <zzo38> As far as I know, FEN is a common kind of encoding for chess; I don't know what other kind of encoding you mean
22:20:01 <int-e> b_jonas: Yeah. Usually you get bigger numbers than that :) The starting position has /8/8/8/8/ in the middle. Also lower case is black and upper case is white.
22:20:01 -!- V has quit (Remote host closed the connection).
22:21:17 -!- V has joined.
22:28:05 <int-e> https://paste.debian.net/1205297/
22:29:39 <int-e> I actually saw it here: https://www.youtube.com/watch?v=jglvRpbJZzk
22:58:22 -!- dutch has quit (Quit: WeeChat 3.2).
23:03:46 -!- dutch has joined.
23:11:35 -!- delta23 has joined.
23:17:24 -!- oerjan has joined.
23:23:34 <oerjan> <Guest8999> completely alters the explanation for Deadfish/Constants, page hasn't been touched for 6 years <-- hm didn't i write that
23:28:42 <oerjan> seems Mroman wrote the basics and i expanded to >256
23:31:04 <oerjan> looking at it the second sentence of the second paragraph is a bit confusing and technically wrong
23:31:55 <oerjan> i think it's mixing backward and forward thinking
23:35:27 <oerjan> i guess i'll wait to see Guest8999's rewrite
23:43:59 <esolangs> [[StairCase]] M https://esolangs.org/w/index.php?diff=86555&oldid=86507 * PythonshellDebugwindow * (-242) /* To Do */ Remove non-categories
23:49:19 -!- delta23 has quit (Quit: Leaving).
23:51:42 -!- delta23 has joined.