| lkcl | ghostmansd, no, use multiple instructions per test: see latest commits. | 02:27 |
|---|---|---|
| lkcl | i saved some time by creating one (shared) PowerDecoder. | 02:27 |
| lkcl | one other way to get even more instructions per test is to use LD/STs | 02:28 |
| lkcl | even write a small program that does a loop counter, writes to memory. | 02:28 |
| lkcl | but let's see how just hitting 32 bcd instructions at a time works, first | 02:29 |
| justinrestivo[m] | lkcl: I am trying to build the various libre-soc repos on ubuntu. To install all the dependencies/build the libre-soc repos, should I just be sequentially running all the scripts here: https://git.libre-soc.org/?p=dev-env-setup.git? Or should I word-for-word be following the script on 1.2 here: https://libre-soc.org/docs/? | 02:31 |
| lkcl | no use the instructions at https://libre-soc.org/HDL_workflow/devscripts/ | 03:55 |
| lkcl | you need the base dependencies first | 03:55 |
| lkcl | ./install-hdl-apt-reqs | 03:56 |
| lkcl | inspect the contents, it should be reasonably self-evident | 03:56 |
| lkcl | one thing: you *must not* let pip install sub-dependencies | 03:58 |
| lkcl | pip is a f****g nuisance. | 03:58 |
| lkcl | it goes, "oh you want nmigen-boards? let me go get a completely random version of nmigen for you, and screw you over" | 03:58 |
| lkcl | to stop that the hdl repos *have* to be done in the order listed in ./hdl-dev-repos | 03:59 |
| programmerjake | found this nice article on why Kraken is switching from PHP (and other stuff) to Rust | 06:07 |
| programmerjake | https://blog.kraken.com/post/7964/oxidizing-kraken-improving-kraken-infrastructure-using-rust/ | 06:07 |
| justinrestivo[m] | Ah that's clearer. Will give it a shot, thanks. | 10:49 |
| lkcl | programmerjake, this is the Libre-SOC Project, we don't use PHP (or kraken) | 13:31 |
| lkcl | can we please keep this channel focussed on issues related to Libre-SOC? | 13:32 |
| programmerjake | yeah, but it does explain a lot of why I've been advocating for Libre-SOC to use Rust more, so I'd consider it on-topic | 13:33 |
| programmerjake | I probably should have stated that in my original message | 13:35 |
| lkcl | when speaking with the team in India, none of them knew of nmigen however all of them knew of python and had used it | 13:35 |
| lkcl | i will say it again - in stronger terms this time - it would be really, really stupid of us to use rust as the primary language for Libre-SOC HDL | 13:36 |
| lkcl | we would be LITERALLY the only users of the HDL | 13:36 |
| lkcl | we would have serious training and recruitment problems | 13:36 |
| lkcl | and it would severely jeapordise our chances of success | 13:36 |
| lkcl | rust is NOT an appropriate lanugage as a critical hard dependency for a project that is this complex | 13:37 |
| lkcl | we are already in serious need of contributors | 13:37 |
| lkcl | to force every single person to have to learn a language that is NOT WIDELY ADOPTED forces us to train them and pay them for that training time | 13:38 |
| lkcl | because python is known by 30% of the world's programmers that cost is ELIMINATED | 13:38 |
| lkcl | sorry to have to keep repeating this, jacob, please understand and accept it | 13:38 |
| lkcl | we went through this right at the beginning of the project, in the review and choice of the HDL | 13:39 |
| lkcl | we picked nmigen because it has a vibrant pre-existing community and its primary developer is extremely smart and committed | 13:40 |
| lkcl | if we developed a rust-based HDL we would first have to develop that HDL and we would set the entire project back by at least another YEAR. | 13:40 |
| lkcl | then because we were literally the only team that would be using it we would be completely incapable of finding developers | 13:41 |
| lkcl | we went through this | 13:41 |
| lkcl | so pleae | 13:41 |
| lkcl | please don't keep advocating rust all the time | 13:41 |
| programmerjake | maybe not using Rust for the HDL, but other surrounding software? | 13:41 |
| lkcl | the exact same logic applies. | 13:41 |
| lkcl | we need to augment gcc. | 13:42 |
| lkcl | gcc is not written in rust | 13:42 |
| lkcl | we need to augment binutils | 13:42 |
| lkcl | binutils is not written in rust | 13:42 |
| lkcl | we need to augment llvm | 13:42 |
| lkcl | llvm is not written in rust | 13:42 |
| lkcl | we need to augment u-boot and coreboot | 13:42 |
| lkcl | u-boot and coreboot are not written in rust | 13:42 |
| lkcl | we need to port libc6 to SVP64 | 13:42 |
| lkcl | libc6 is not written in rust | 13:42 |
| lkcl | every single *immediate* focus - everything on the critical path - that we have to do and have funding for - is *not* written in rust | 13:43 |
| lkcl | i've said that a number of times as well | 13:43 |
| lkcl | i appreciate fully that you love rust: the danger is that it's becoming an obsession for you. | 13:44 |
| lkcl | i've had that happen, myself: it's how i got so much done. | 13:45 |
| lkcl | but | 13:45 |
| programmerjake | I'm not saying rewrite binutils/etc. in Rust, I'm saying new software can be written in Rust -- because the software doesn't exist or is of such quality that it needs rewriting -- NOT because the software just happens to be not in Rust | 13:45 |
| lkcl | i also had to be told, when i was around your age, by managers at companies that i worked for, that i needed to focus on the tasks that were in front of me | 13:45 |
| lkcl | then the same things apply | 13:46 |
| lkcl | if we do that, we have to pay people to train them in rust | 13:46 |
| lkcl | and because it's not a commonly well-known language, we place the project at risk by choosing that language | 13:46 |
| lkcl | you're the *only* person in the entire world who knows pia, for example. | 13:47 |
| lkcl | finding someone to help work on it is seriously problematic for us | 13:47 |
| lkcl | by contrast if you pick literally any random programmer in the world, there's a 1-in-3 chance that they'll know python | 13:48 |
| lkcl | this is what i've been trying to get across to you for a long, long time: | 13:48 |
| lkcl | it's *not* just about how good the language is | 13:48 |
| lkcl | we have to think, "how can we find resources and a supportive ecosystem" | 13:49 |
| programmerjake | hmm, cole might know pia...also 1 in 12 or so programmers know Rust so it's not as if no one knows it... | 13:49 |
| lkcl | picking a language that is only known by a small percentage of the world's population is extremely unwise | 13:49 |
| lkcl | 1 in 12 | 13:49 |
| lkcl | vs 1 in 3 | 13:49 |
| lkcl | *below* ten percent. | 13:50 |
| lkcl | it's far too great a risk | 13:50 |
| lkcl | plus, when analysing available projects that might do a similar job (and could be adapated), there's *just not enough available* yet. | 13:51 |
| lkcl | part of the applications to NLnet required doing a comparative analysis | 13:51 |
| programmerjake | also, I went out of my way to add Python-visible docs to pia | 13:51 |
| lkcl | "please give a list of similar projects and compare them" | 13:52 |
| lkcl | basically they wanted to know if the money was being wasted on duplicating existing effort | 13:52 |
| lkcl | i know you did - that's missing the point though | 13:52 |
| lkcl | this is basic project management | 13:53 |
| lkcl | the capabilities of a given language itself is a *minor* factor | 13:53 |
| lkcl | adoption | 13:53 |
| lkcl | mindshare | 13:54 |
| lkcl | maturity | 13:54 |
| lkcl | stability | 13:54 |
| lkcl | these are FAR more important | 13:54 |
| lkcl | i'm reading that article, i get why they chose rust. they're security-minded, they have to protect users. | 13:55 |
| lkcl | it's a good choice | 13:56 |
| lkcl | because they are developing a networking product in software | 13:56 |
| lkcl | Libre-SOC's development has *nothing to do with networking* | 13:56 |
| programmerjake | ok. so the adoption ... etc. is more of a factor than you just don't want to learn rust now | 13:56 |
| lkcl | we're not developing a networking product | 13:57 |
| lkcl | it's both. | 13:57 |
| lkcl | i have to focus on the immediate critical tasks, none of which require rust in any way | 13:57 |
| programmerjake | ummm...we got funding for a router ... how's that not networking? | 13:57 |
| lkcl | i also have to think "how can i find other people and encourage them to participate" | 13:57 |
| lkcl | there's a firebreak between using a language because it has secure features | 13:58 |
| lkcl | which protects against networking errors at the software level | 13:58 |
| lkcl | and | 13:58 |
| lkcl | we have some HDL that has to be be expressed somehow | 13:58 |
| jn | toolchain components won't run on the hardware that will use the Libre-SoC; in that sense, the toolchain components aren't network software | 13:59 |
| lkcl | there's a cognitive break between the two | 13:59 |
| lkcl | basically, yes. | 13:59 |
| lkcl | once we have a processor that EXECUTES rust programs, then there is security involved in the DEVELOPMENT of those programs | 14:00 |
| programmerjake | but we will be writing networking software...a router is fine and good but is just an expensive heater without software | 14:00 |
| lkcl | however that has ABSOLUTELY NOTHING to do with the tools USED to develop the hardware THAT executes those end-user programs | 14:00 |
| jn | not all software that is somehow related to LS might be classified as "toolchain", but then we get into details rather than general tendencies | 14:00 |
| lkcl | yeeees... | 14:00 |
| lkcl | but just as i said | 14:00 |
| lkcl | that software has *nothing to do with the tools used to develop that hardware* | 14:00 |
| lkcl | how can it? | 14:00 |
| lkcl | there is one example which helps illustrate this | 14:01 |
| lkcl | if we were to develop some special custom hardware feature, such as Cambridge Capability | 14:01 |
| lkcl | or memory pointer type-safety | 14:01 |
| lkcl | (in hardware) | 14:01 |
| lkcl | this btw was something that both lowRISC are researching, and IIT Madras as well, both in different ways | 14:01 |
| programmerjake | good luck on compiler support! | 14:02 |
| lkcl | THEN we are focussing on hardware-assisted security | 14:02 |
| lkcl | this would... yes :) | 14:02 |
| lkcl | this would "tie in" to the actual software (and, yes, the compilers need to be taught about it) | 14:02 |
| lkcl | example, IIT Madras developed hardware pointer "tracking" | 14:02 |
| lkcl | every 64-bit memory pointer had a "mirror" tag (also 64-bit) | 14:02 |
| lkcl | when memory was allocated, that "tag" was set to a hash. | 14:03 |
| lkcl | when memory is freed, it's set to zero | 14:03 |
| jn | re. the Router funding, is this the right page? https://libre-soc.org/nlnet_2021_crypto_router/ | 14:03 |
| lkcl | therefore (theory goes), if you access that memory after it's been freed, hardware checks the tag, and if it's zero, you throw an ILLEGAL MEMORY ACCESS exception | 14:03 |
| lkcl | jn: yes | 14:03 |
| lkcl | now, there, it *would* be appropriate to teach the rust compiler about that featuer | 14:04 |
| programmerjake | depending on the level of tracking, it could easily break fundamental memory model assumptions of C, Rust, LLVM and others | 14:04 |
| lkcl | in fact, the IIT Madras team member told me that they were actually looking at rust to do exactly that | 14:04 |
| lkcl | yes, they were *actually* designing the malloc-tracking *specifically* for rust, not just to help with c / c++ | 14:05 |
| lkcl | that *IS* an appropriate circumstance to involve the rust language with actual hardware | 14:05 |
| jn | programmerjake: hmm, in that context, knowledge of Rust internals is useful while designing these HW features (pointer tracking etc.) | 14:05 |
| programmerjake | for instance, Rust explicitly treats memory as untyped bytes, it doesn't have C/C++'s type-based-alias-analysis | 14:05 |
| lkcl | however they got special funding to do so | 14:05 |
| lkcl | there are several other examples like that, where the compiler and/or language actually ties in directly with hardware features | 14:06 |
| lkcl | RV has a JIT SIG where they are designing instructions to help accelerate all types of JIT (java bytecode, javascript, many others) | 14:07 |
| programmerjake | so, in Rust, casting a `*const f32` to a `*const i32` and dereferencing is perfectly legal (though it requires an unsafe block), whereas in C that is UB | 14:07 |
| lkcl | however when developing a general-purpose processor, you want to pick a *hardware* language appropriate for developing *hardware*. | 14:08 |
| lkcl | we're taking a huge risk by using nmigen, as it is. fortunately it outputs verilog. | 14:08 |
| lkcl | i spent some considerable time explaining to the team in India about the Dynamic Partitioned Signal | 14:09 |
| lkcl | and illustrated to them how insane it would be to try that same thing in verilog or VHDL | 14:09 |
| programmerjake | :) | 14:09 |
| lkcl | they took it quite well, and got it | 14:10 |
| programmerjake | it might be doable in VHDL due to it's nice Ada roots, but definitely not Verilog | 14:10 |
| lkcl | i've put them onto the wishbone streaming task, because the initial work can be done in verilog | 14:10 |
| lkcl | that'll give them time to get up to speed | 14:10 |
| programmerjake | it would definitely not be usual VHDL though | 14:11 |
| lkcl | yehyeh | 14:11 |
| lkcl | it's the operator-overloading in python, the fact that it's a full OO language, that makes it possible to do PartitionedSignal | 14:11 |
| lkcl | there's still things that will limit us, it's going to be quite awkward | 14:12 |
| lkcl | but it's possible | 14:12 |
| lkcl | things can still be expressed "m.d.comb += result.eq(x + y)" | 14:12 |
| programmerjake | hmm, operator-overloading isn't strictly necessary...as is evidenced by nmigen's a.eq(b) | 14:13 |
| lkcl | that's an annoying one, there's no operator-overload for "assignment" | 14:13 |
| lkcl | pyrtl overloaded... what was it.... i think they overloaded the "<<=" operator to mean "assignment" | 14:14 |
| lkcl | (blech) | 14:14 |
| jn | it's a convenience feature, as "x + y" is shorter, more convenient than "x.add(y)" would be | 14:14 |
| lkcl | more readable, yes. | 14:14 |
| programmerjake | jn: yup! | 14:14 |
| lkcl | esp. when you get nested expressions. | 14:14 |
| lkcl | we will seeeriously have to keep an eye on the gate count though | 14:15 |
| lkcl | look at the yosys graphs to make sure it's not totally insane | 14:15 |
| programmerjake | though it's not always more convenient to write a + b instead of a.add(b) | 14:15 |
| lkcl | ironically, "x + y" ends up allocating a nmigen module "behind the scenes" | 14:15 |
| lkcl | so the yosys graphs *really do* have boxes named "add", with 2 inputs and 1 output | 14:16 |
| lkcl | rather than the usual oval with a "+" symbol in the middle | 14:16 |
| programmerjake | well, yosys represents verilog's + operator using the `$add` cell (equivalent to a submodule) anyway | 14:17 |
| lkcl | still need the integration of PartitionedSignal into nmigen itself to be done | 14:17 |
| * lkcl checking that, haven't looked at a yosys graph in a while | 14:17 | |
| lkcl | ah yes it does | 14:18 |
| lkcl | however the inputs are on the left and the output on the right | 14:18 |
| lkcl | which makes for a pretty graph | 14:18 |
| lkcl | forward-progress | 14:18 |
| lkcl | with PartitionedSignal, x + y calls x.__add__(y) which behind-the-scenes creates a PartitionedAdd module instance | 14:19 |
| lkcl | and (sigh) modules have all inputs and outputs on the *left* side of the box. | 14:19 |
| lkcl | the graphs therefore look a bit of a mess | 14:19 |
| * lkcl eep, it's 2:20pm and i haven't had lunch yet! | 14:20 | |
| programmerjake | well...I should get some more sleep...I woke up at 4am | 14:21 |
| lkcl | off to make noodles+veg. later all | 14:21 |
| lkcl | :) | 14:21 |
| lkcl | yeahh that's a familiar one :) | 14:21 |
| lkcl | i was up _until_ 4am lol | 14:21 |
| lkcl | sleep well | 14:21 |
| programmerjake | :) | 14:21 |
| ghostmansd | As for *f32 to *i32 cast, this is UB by standard, by in fact works and is widely accepted, and basically depends on compiler & architecture combo. I recall a lot of such stuff regarding unions. Even despite recent changes in Standard (was it C99? C11?), many still think type punning doesn't work. It works, but you must know for sure where and how you do it. | 21:19 |
| ghostmansd | If you ask me, the whole aliasing brings more problems than it ever intended to solve. | 21:19 |
| ghostmansd | I can give another example: casting (void *) to function pointer. It is UB, again, because pointer to data might not be the same thing as pointer to code. | 21:21 |
| ghostmansd | Now guess what, have you met such platforms IRL for recent years? | 21:21 |
| ghostmansd | And have you used dlsym or GetProcAddr? | 21:21 |
| ghostmansd | So it's UB per Standard, but certainly well-defined per superset standards (POSIX, WinAPI, whatever else crap they have these days). | 21:22 |
| programmerjake | casting void* to a function pointer is implementation-defined iirc | 21:23 |
| ghostmansd | And actually UB has its benefits, especially performance-wise. | 21:23 |
| ghostmansd | 6.3.2.3:8 A pointer to a function of one type may be converted to a pointer to a function of another type and back again; the result shall compare equal to the original pointer. If a converted pointer is used to call a function whose type is not compatible with the pointed-to type, the behavior is undefined. | 21:23 |
| ghostmansd | Literally the first discussion I found. I'm too lazy and AFK to check it. | 21:23 |
| programmerjake | gcc (and clang and all other compilers that follow gcc) defines type-punning *through a union*. type punning via pointer casting is still UB | 21:24 |
| ghostmansd | Meanwhile it works. | 21:24 |
| ghostmansd | Granted that you know for sure where, when and how you do it. | 21:25 |
| ghostmansd | For example, you disable aliasing completely. | 21:25 |
| ghostmansd | Yes, C has a different mindset than Rust. I don't see pros or cons there, and for me this is not a reason to prefer one or another. | 21:25 |
| ghostmansd | However, rationale shown above looks fair. | 21:26 |
| ghostmansd | I mean, project-wise. | 21:26 |
| ghostmansd | For local stuff, e.g. drivers in Linux, I have no objections, unlike some other kernel developers. | 21:27 |
| programmerjake | yup, I'm not saying Rust's type punning makes it better than C there, just different. if not properly accounted for in designing CPU-level pointer checking extensions, you can break a lot of software | 21:28 |
| ghostmansd | But the idea to rewrite the kernel itself would look like an anecdote to me, a purely essential for virtually one purpose: to prove that you can do it. | 21:28 |
| ghostmansd | You can break a lot of software even writing it in Python. | 21:28 |
| ghostmansd | After all, "you can write Fortran in any language". | 21:28 |
| programmerjake | hmm, hope no one has to write fortran in BF :) | 21:29 |
| ghostmansd | I for sure think there might be enthusiasts even for this task :-D | 21:30 |
| programmerjake | well, if you want to have fun with weird compilers, check out: https://github.com/xoreaxeaxeax/movfuscator | 21:31 |
| ghostmansd | I think starting an independent project in Rust might be OK. Some system service which is a res per se, independent from other things. Or maybe even shiny new libc. Or, well, even hobbyist kernel. | 21:31 |
| ghostmansd | I saw it, nice stuff. I mean, this is for pure fun, but hey, what's not. | 21:32 |
| ghostmansd | At least they prove that mov is Turing-complete IIRC | 21:33 |
| ghostmansd | So it has some educational value, if this is correct. | 21:33 |
| programmerjake | x86 mov is, mov on something like RISC-V or Power isn't | 21:36 |
| ghostmansd | I think anyone can learn Rust; the actual rationale to do it is unclear. This is debate like "Why Plan9 has never won over Unix, despite being awesome". | 21:36 |
| ghostmansd | (I don't really think it is, but hey, the authors likely thought it was) | 21:37 |
| programmerjake | well, Rust has waay more adoption than Plan9 iirc | 21:37 |
| ghostmansd | That's due to all this hype and large corporations starting to use it. | 21:38 |
| ghostmansd | Same with Go. | 21:38 |
| ghostmansd | BTW, the team is the same, and lot of concepts came into Go from Plan9. | 21:38 |
| ghostmansd | I mean, just look closer. Channels? Goroutines? These "interfaces"? Just compare Plan9 C library and compiler, and you see where it comes from. | 21:39 |
| programmerjake | well, unlike Go, Rust does have some useful stuff that isn't in more mainstream languages | 21:39 |
| programmerjake | (not that Go isn't useful, but you can find all it's features in other mainstream languages) | 21:40 |
| ghostmansd | Memory safety? C'mon, some languages don't even have pointers, and some have immutable objects. | 21:40 |
| ghostmansd | That's like saying "Haskell has useful stuff". | 21:40 |
| programmerjake | yes, but immutable objects and GCs are slow at all the wrong times | 21:41 |
| ghostmansd | Well, even assembler has some cool stuff! | 21:41 |
| ghostmansd | One might argue that you simply use it incorrectly. :-) | 21:41 |
| programmerjake | yup, which is why any decent systems programming language supports inline assembly, including Rust | 21:41 |
| ghostmansd | This sorta defeats "memory safety" mindset. | 21:42 |
| programmerjake | assembly has stuff you can't do in any other way (ever tried writing a syscall routine in JS?) | 21:42 |
| ghostmansd | Lol, this reminds me an old gag | 21:44 |
| ghostmansd | https://img-9gag-fun.9cache.com/photo/a576bNq_460swp.webp | 21:44 |
| programmerjake | no, Rust allows you to use all the potentially dangerous (that can cause UB) stuff in delimited unsafe blocks, allowing you to not have to check all code for memory safety (the way you have to with C/C++), all that's needed is checking the unsafe blocks | 21:44 |
| ghostmansd | I think we walk in circles. :-) | 21:45 |
| programmerjake | using unsafe blocks, you can build sound abstractions such that people calling your code from purely safe code can't cause UB intentionally/unintentionally | 21:47 |
| ghostmansd | I don't feel the need to advocate for C, I already know why I use it, and there's no need to persuade anyone. Same for Python. Same for anything else. I have no idea why there's a huge count of fans which feel these needs for Rust. If it's so awesome, people will find their way. | 21:48 |
| programmerjake | meaning the code that doesn't use unsafe doesn't need to be written carefully to avoid UB | 21:49 |
| ghostmansd | However, there are reasons to use languages other than Rust, and, regardless of personal beliefs, they do have right to be accepted, like them or not. I personally don't like makefiles for many thins, but do I go everywhere to advocate any meta-build-system? No, even though I personally find meson attractive. | 21:51 |
| programmerjake | I guess it's because I (and similar-minded Rust advocates) see the abstraction and safety powers that Rust gives while still being a systems programming language and see it as a massive improvement over other common languages | 21:52 |
| ghostmansd | Don't fall into the fallacy to think others don't see. | 21:52 |
| ghostmansd | Again, I feel we walk in circles. | 21:53 |
| ghostmansd | I have no intention to stop the bright future where everything is written in Rust. | 21:54 |
| ghostmansd | Perhaps I will use it for something one day. | 21:54 |
| programmerjake | yup, I don't think others are blind, but I see it as such a massive step-up that I can't help advocating for Rust in hopes others will be convinced to try it out and see for themselves | 21:54 |
| ghostmansd | Who knows, maybe lkcl is now re-writing the whole project in Rust, he just doesn't want to admit it... :HD | 21:56 |
| programmerjake | he seems to like Python... | 21:56 |
| ghostmansd | I don't like any language. | 21:57 |
| ghostmansd | Well, at some point I actually loved Latin, but that's another story. | 21:57 |
| programmerjake | XD | 21:57 |
| ghostmansd | I don't like languages, I like concepts which I create using those. I might like some features or not, but, after all, languages are just tools with pros and contras. | 21:58 |
| programmerjake | (i have an unusual fascination with Japanese and Unicode...) | 21:58 |
| programmerjake | I like Rust as a concept! | 21:59 |
| jn | lkcl's main point in promoting python for all of LS is the follow, as far as i understand it: 1. it is already the main implementation language of LS, due to nMigen; 2. it is fairly well known in general; 3. the benefit of an accessible programming language (due to 1. and 2.) outweigh the comparative advatages of alternative programming languages, esp. Rust | 21:59 |
| programmerjake | yup, I understand lkcl's reasoning (afaict) | 21:59 |
| jn | s/the follow/the following/ | 21:59 |
| ghostmansd | Unicode is elegant in some places, e.g. how it handles Hangul compositions, but is extremely awful in others (e.g. these cross-references across various parts of the standard). | 22:00 |
| jn | so, all the benefits of rust are good and interesting per se, but don't attack his argument | 22:00 |
| ghostmansd | Also, ICU is a total crap, which sadly can do anything Unicode contains. | 22:01 |
| ghostmansd | I mean, interfaces-wise, at least C and C++ versions. | 22:01 |
| programmerjake | I quite liked reading about harfbuzz | 22:01 |
| programmerjake | and all the mess that is font rendering | 22:02 |
| ghostmansd | I've never dealt with it, but can believe :-) | 22:03 |
| programmerjake | I do kinda wish that there never was UCS-2 or UTF-16, UTF-8 is good enough for everything. UTF-32 and code-point indexing is just a misleading dead-end -- makes people conflate code points with characters (grapheme clusters in Unicode-speak) | 22:05 |
| programmerjake | windows having separate Unicode apis is annoying | 22:05 |
| ghostmansd | Well, for Windows it's already a part of backward compatibility, there are pros and cons. | 22:07 |
| ghostmansd | BTW, UTF-8 is also from Plan9. | 22:07 |
| ghostmansd | 9p, procfs also are | 22:08 |
| ghostmansd | So the concepts found their way onto the outside world | 22:09 |
| programmerjake | windows should have just followed unix and plan9 and switched their ascii apis to utf-8 | 22:09 |
| ghostmansd | Maybe that's Rust's fate, who knows | 22:09 |
| ghostmansd | programmerjake: http://utf8everywhere.org/ | 22:11 |
| ghostmansd | I think you read it before, but anyway :-) | 22:12 |
| programmerjake | rust inspiring new features in other languages: that's already happening to some extent | 22:12 |
| programmerjake | yup, read utf8 everywhere multiple times | 22:13 |
| ghostmansd | I think other languages inspire as well. I don't think coroutines were that hyped before go, even though they existed decades before. | 22:14 |
| ghostmansd | (I actually love the concept, so "hype" is quite in a positive sense) | 22:17 |
| programmerjake | interestingly, I implemented generators in a realtime JS interpreter I wrote for a previous job | 22:18 |
| programmerjake | iirc the only major feature I left out was regex support (who needs that for emulating embedded devices) | 22:20 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
