Threads for teymour
-
- Introduction to the Analysis of Algorithms by Philippe Flajolet and Robert Sedgewick. It’s a fantastic book, with a lot of useful mathematical techniques.
- Why Programs Fail by Andreas Zeller. Lots of good debugging theory and strategies.
There’s also the sled reading list which is really good.
-
Makes sense to me. Given that it’s a topic with interest that’s only about to grow.
-
I’m all for a tag, but I suspect that normies aren’t going to stay on the fediverse. They’ll either go back to Twitter or some other corporate social media product. Fediverse just feels like people and bots shouting into the void with relatively little interaction/diaglogue. I’m sure you can curate your experience, but I don’t think most people want to go through the hassle. My suspicion is that the Fediverse enthusiasm will fade in a few months.
-
Fediverse just feels like people and bots shouting into the void with relatively little interaction/diaglogue.
I have the complete opposite experience. Maybe you are holding it wrong?
My suspicion is that the Fediverse enthusiasm will fade in a few months.
How is that relevant at all? We have tags for
fortranordragonflybsdwhich are niches of niches sure we can have one for fediverse.-
I have the complete opposite experience. Maybe you are holding it wrong?
Maybe? I’ve tried it a lot on several different servers over the years, and tried to make it work, but there was rarely any interaction.
How is that relevant at all? We have tags for fortran or dragonflybsd which are niches of niches sure we can have one for fediverse.
My post literally opened with “I’m all for a tag”. 🙄 This bit was relevant because the parent claimed that fediverse was going to continue growing in popularity, and I was expressing that it’s unlikely to continue growing in popularity beyond the next month or two. You’re welcome to disagree, but I’m still on-topic.
-
-
-
-
-
-
-
-
-
I get that terms like “normie”, “muggle”, or “civilian” may be derogatory depending on context but I’m curious: what racist & antisocial groups are using that term, and what groups do they target with it?
-
I found this paper by googling “how to redpill normies”
Redpilling Normies: An Ethnography of Alt-Right 4chan Discourse.
Sounds like it should be a good entry point for your research.
-
-
-
-
-
-
-
-
carlmjohnson
5 months ago
|
link
| on:
Why Philosophers Should Care About Computational Complexity (2011)
As someone with a PhD in Philosophy, I read this when it came out and loved it, but as far as I know, it had no impact on the field.
-
There’s a quote by Noam Chomsky which is something to the effect of … “When I presented my ideas to mathematicians, they evaluated me on those ideas. When I presented my ideas to social scientists, they wanted to know what credentials I had before listening to me”.
Seems like this could be a similar issue. It does seem that many philosophers are more like the latter social scientists – they want to know WHO said something, not simply if it’s true or not.
From my limited exposure, a lot of philosophy is really about the meaning of words, and who invented a term, and not what’s actually true. There are a lot of convoluted arguments that could be made a lot more precise with simpler language and empirical tests.
For example, much of what I’ve read about “AI alignment” – which DOES seem to be done by “professional philosophers” with prestigious degrees – suffers greatly from this. They start with questionable premises, and then invent an elaborate framework of knowledge on top of it, which is almost certainly wrong.
That is, the game is to build more and more rhetoric/provocation on top of this new set of terms, without considering whether the premises are correct. It’s better if what you’re saying isn’t falsifiable for a long time.
e.g. the book “Superintelligence” is like this, and the funny thing is that he almost admits as much in the preface. Similarly with the “longtermism” thing. It reminds me of this funny quote
My No. 1 worry is: what if we’re focussed on entirely the wrong things?” he said. “What if we’re just wrong? What if A.I. is just a distraction?
from a long New Yorker article which I commented on here: https://news.ycombinator.com/item?id=32393700
BTW I also remember reading this Aaronson article on a train over 10 years ago! I’m pretty sure I found it on Hacker News. I got about halfway through and thought it was brilliant. The rest was over my head.
And I should probably add that my comments probably come off as a bit harsh, and apply mainly to certain things that have gotten a lot of attention, and that I’ve had a longstanding interest in. I did qualify it with “from my limited exposure” :-)
-
The full quote from Chomsky can be read here - http://www.autodidactproject.org/quote/chomsky1.html
-
-
-
Thanks for digging it up, I should have done that :)
It does seem like he is referring to political science, which puts it in a different light … Political arguments are notorious for “attacking the speaker, not the idea”
But I do think it’s relevant regardless because it’s hard to bring knowledge in from different fields … and arguably this is more of a problem as time goes on, simply because there’s more knowledge and more people writing about it
-
-
From my limited exposure, a lot of philosophy is really about the meaning of words, and who invented a term, and not what’s actually true.
That’s the effect of the academy, AFAICT. It’s not like the olden days where Aquinas could believe in God and so did all his colleagues, and they debated which proofs of God’s existence worked or didn’t. Now you have one guy studying Aquinas, one guy studying Plato, one guy studying Derrida, etc. and they don’t agree on anything fundamental, so to come to a consensus, you just talk about the history of the ideas and not their actual truth. You do get some actual disputes, but it’s all on technical minutiae, like “is justification internal or external?” That sort of thing.
There are a lot of convoluted arguments that could be made a lot more precise with simpler language and empirical tests.
Hume said the same thing. He was wrong. :-)
-
You do get some actual disputes, but it’s all on technical minutiae, like “is justification internal or external?” That sort of thing.
I think that this may be a bad example—or maybe I misunderstand your point. (I realize that you have a PhD in philosophy, but I’m also writing for others. I don’t mean to be teaching you things you don’t know about, e.g., the justified true belief theory of knowledge.)
A lot of people have thought that we can define knowledge as justified true belief. If we do that, we will need to understand what we mean by justified. Once we dig into that question, it is far from trivial whether justification is internal or external. I’m assuming we all agree that “What is knowlege?” is a real and significant question. Since we want to understand knowledge, and understanding justification seems required in order to understand one long-standing and influential account of knowledge, I think that whether justification is internal or external is a very real dispute and not merely technical minutiae. (As an additional point, I think that the arguments in favor of internalism and externalism themselves are interesting and well worth considering. There are strong reasons in favor of both, but both have problems. It’s a fascinating debate. YMMV, of course.)
Here’s a different way of putting this. People inside and outside of academic philosophy often long for the good old days when philosophy wasn’t so technical or hyper-specialized. (Lots of longing for the good old days when Bertrand Russell wrote on logic, ethics, and epistemology.) But I wonder whether that nostalgia isn’t parallel to (a hypothetical) longing for the good old days of Newtonian physics—you know, when physics was more straightforward and not so hyper-specialized. I don’t think we can (or should want to) go backwards. Philosophy is far more complicated and specialized, and this can be frustrating, but I don’t think that’s primarily or only because of (say) pressures to publish or sloppy thinking. The questions are genuinely, deeply difficult.
Bottom line: I am not convinced that contemporary philosophers have given up the pursuit of truth and replaced it with the history of ideas.
-
The key thing is context. Trying to avoid it brings problems. Just talk to the people you are talking to and stop stressing the global truth of your statements. See, I did it just now, I made a statement without a disclaimer and I trust that you understand that it is mostly in alignment with what I believe, not a global truth, but now that I’ve added this disclaimer I’m back to trying to climb the hill of global truth-y-ness.
Language is decentralized and ever changing. The western philosophy tradition is too obsessed with who was first or whatever instead of realizing that what we actually want is to pass the torch and teach the next generation our deeply held insights (without trapping them in minutiae and technical arguments, which can be important, but are also often a case of missing the forest for the trees).
-
I agree broadly.
I think the internalism/externalism debate qualifies as minutia in the sense that, it only makes sense as a question if you already accept the idea that knowledge is a justified true belief. We all agree that we want knowledge and it’s better to have knowledge than ignorance (or do we?), but only smaller number of people agree that knowledge is something like justified true belief. Among people who are debating JTB, there are Gettier problems and whatnot, and so they end up digging into well, what is justification anyway and how does that work? And then you can go further down and have various flavors of internalism/externalism and hybrid theories and controversies within them.
It’s fair though for someone else to look at the justification debate from outside and say, well, that’s all irrelevant because I have a pragmatic theory of knowledge, and JTB doesn’t apply, or I’m Nietzschean and “knowledge” is just the mask of will to power, etc. It would be really good if we could actually nail down all the big stuff before we really dig into the small stuff, but alas, that’s not how the hermeneutic circle works.
-
-
-
Enquiry Concerning Human Understanding 7.1
The chief obstacle, therefore, to our improvement in the moral or metaphysical sciences is the obscurity of the ideas, and ambiguity of the terms.[ …] And, perhaps, our progress in natural philosophy is chiefly retarded by the want of proper experiments and phaenomena, which are often discovered by chance, and cannot always be found, when requisite, even by the most diligent and prudent enquiry. As moral philosophy seems hitherto to have received less improvement than either geometry or physics, we may conclude, that, if there be any difference in this respect among these sciences, the difficulties, which obstruct the progress of the former, require superior care and capacity to be surmounted.
As for why it’s wrong, so far no attempt at doing philosophy in clear language has succeeded, but maybe we just need to give it another three hundred years.
-
-
-
There’s a quote by Noam Chomsky which is something to the effect of … “When I presented my ideas to mathematicians, they evaluated me on those ideas. When I presented my ideas to social scientists, they wanted to know what credentials I had before listening to me”.
This is the ideal we should all strive for and why anonymity is so important. Also why I believed datalisp would not require much rhetoric… although I should have realized that Ron Rivest was not enough to change the way we do the web so who am I? Still. The reason mathematicians behave this way is because they know that theorems hold up in reality.
-
-
-
There is a nearly perfect solution, namely equality saturation.
From the tutorial:
equality saturation explores all possible variants of a program that can be derived from a set of rewrites, and then it extracts the best one
You have to build your own equivalence relations which can be a lot of work. While nothing is perfect, this beats the heck out of doing this by hand.
-
In the article it is briefly mentioned that the Cranelift compiler backend is considering/planning to adopt equality saturation! It’s a very cool approach.
-
…all possible variants of a program…
Sounds like a great way to replace your problem with “come up with a useful set of rewrites that can be explored before the end of the universe”. Sounds like a fun paper to read! Lemme give it a skim…
Upon reaching a fixed point (saturation), 𝐸 will represent all equivalent ways to express 𝑝 with respect to the given rewrites. After saturation (or timeout), a final extraction procedure analyzes 𝐸 and selects the optimal program according to a user-provided cost function.
So it searches until some termination condition is reached or until it times out. On the one hand it sounds like a potentially really good approach and on the other it seriously pings my “all you need to do is tune your parameters right! Now you have two problems!” senses. I admit that being able to say “spend <= 5 seconds optimizing this program” or “spend <= 4 hours optimizing this program since this is running overnight in CI anyway” sounds pretty appealing. So, I’ll reserve judgement until I see it in practice more.
-
Author of that paper here. You are right that many sets of rewrites can spin out until the end of time. But, in practice, we’ve found that saturation is rarely necessary: you typically find what you’re looking for pretty early!
Obligatory ad for the Zulip if you’re into this kind of thing: https://egraphs.zulipchat.com/
-
-
-
Would be interesting to see if you could hook up a SAT solver somehow, to prove that no better case exists. I’ve thought about it in a more general case of ISAs, but that’s very hard to model for SAT, maybe it could be easier with egraphs.
-
I think you’re describing a variant of a superoptimiser?
-
I guess? There might be a difference from traditional ones though in that with e-graphs you can already get pretty close, and they might be easier and faster to model in solvers, since apparently they already use them for representation.
-
-
-
-
-
Thanks! I mostly spend my time in the /r/programminglanguages Discord for better or worse. People there mentioned that egraphs still have a hard time dealing with control flow equivalences though, have any good sources for discussion on the problems or solutions involved with that?
-
Yes, dealing with control flow is difficult. Ultimately, while the “put all your rewrites in and push go” story is easy to sell, I don’t think it’s realistic. I think where we need to go (and this is stuff we are currently working on) is how to combine egraphs with more conventional techniques. Being able to represent many programs “superimposed” on one another is just too good to give up. We have seen success in many domains with the more simplistic plug-and-chug approach, but it won’t scale to genera purpose languages. the cranelift folks realized this and are still carefully selecting what things to do in the egraph.
-
Thanks, it’s nice to know about the gotchas as well. At worst it sounds like there’s potential for good and flexible transformations within basic blocks, which is still pretty useful. Is the problem that the number of valid transformations/combinations explodes when you start considering control flow and it’s just hard to deal with, or that it’s hard to measure which program variant is best, or something else?
…oh, this just occurred to me. If I can bug you more… do you know if anyone has tried applying egraphs to SIMD auto-vectorization and and how well it works if so? Seems like a place it could shine, given how hard vectorization is to represent by other methods. …I might just have to start digging through google scholar and compiler conference talks…
-
E-graphs very naturally represent expressions; representing statements and control flow (or anything else that requires context) gets awkward. It’s definitely possible, just needs more work!
Re: vectorization https://www.cs.cornell.edu/~avh/diospyros-asplos-2021-preprint.pdf
-
-
-
-
-
-
-
-
I think CHERI is a big unknown here. If CHERI works, language level memory safety is less valuable, and Zig will be more attractive and Rust less.
I am pretty optimistic about CHERI. The technology is solid, and its necessity is clear. There is just no way we will rewrite existing C and C++ code. So we will have CHERI for C and C++, and Zig will be an unintended beneficiary.
-
For desktop and mobile applications, I’d prefer a safety solution that doesn’t require a billion or more people to throw out the hardware they already have. So whatever we do, I don’t think relying exclusively on CHERI is a good solution.
-
People throw away their hardware, at least on average, once every decade. I’d much rather a solution that didn’t require rewriting trillions of dollars of software.
-
People throw away their hardware, at least on average, once every decade.
True, the software upgrade treadmill forces them to do that. But not everyone can keep up. Around 2017, I made friends with a poor person whose only current computer was a lower-end smartphone; they had a mid-2000s desktop PC in storage, and at some point also had a PowerPC iMac. It would be great if current software, meeting current security standards, were usable on such old computers. Of course, there has to be a cut-off point somewhere; programming for ancient 16-bit machines isn’t practical. I’m afraid that 3D-accelerated graphics hardware might be another hard requirement for modern GUIs; I was disappointed that GNOME 3 chose fancy visual effects over desktop Linux’s historical advantage of running well on older hardware. But let’s try not to keep introducing new hardware requirements and leaving people behind.
-
-
-
Wouldn’t CHERI still discover these issues at runtime versus compile time? Do not get me wrong, I’m still bullish on CHERI and it would be a material improvement, but I do think finding these bugs earlier in the lifecycle is part of the benefit of safety as a language feature.
-
-
-
CheriABI paper measured 6.8% overhead for PostgreSQL benchmark running on FreeBSD in 2019. It mostly comes from larger pointer (128 bits) and its effect on cache.
-
Note that those numbers were from the CHERI/MIPS prototype, which was an in-order core with a fairly small cache but disproportionately fast DRAM (cache misses cost around 30ish cycles). Setting the bounds on a stack allocation was disproportionately expensive, for example, because the CPU couldn’t do anything else that cycle, whereas a more modern system would do that in parallel with other operations and so we typically see that as being in the noise on Morello. It also had a software-managed TLB and so couldn’t speculatively execute on any paths involving cache misses.
The numbers that we’re getting from Morello are a bit more realistic, though with the caveat that Arm made minimal modifications to the Neoverse N1 for Morello and so couldn’t widen data paths of queues in a couple of places where the performance win would have been huge for CHERI workloads relative to the power / area that they cost.
-
-
We’re starting to get data on Morello, though it’s not quite as realistic a microarchitecture as we’d like, Arm had to cut a few corners to ship it on time. Generally, most of the overhead comes from doubling pointer sizes, so varies from almost nothing (for weird reasons, a few things get 5-10% faster) to 20% for very pointer-dense workloads. Adding temporal safety on top, on the four worst affected of the SPECCPU benchmarks costs about 1% for two, closer to 20% for the others (switching from glibc’s malloc to snmalloc made one of those 30% faster on non-CHERI platforms, some of SPEC is really a tight loop around the allocator). We have some thoughts about improving performance here.
It’s worth nothing that any microarchitecture tends to be turned for specific workloads. In designed for CHERI would see different curves because some things would be sized where they are hitting big wins for CHERI but diminishing returns for everything else. The folks working on Rust are guessing that Rust would be about 10% faster with CHERI. I believe WASM will see a similar speed up and MSWasm could be 50% or more faster than software enforcement.
-
-
I don’t know if anyone has done root-cause analysis on them yet, but typically it’s things like the larger pointers reduce cache aliasing. I’ve seen one of the SPEC benchmarks get faster (I probably can’t share how much) when you enable MTE on one vendor’s core because they disable a prefetcher with MTE and that prefetcher happens to hit a pathological case in that one benchmark and slow things down.
It’s one of the annoying things you hit working on hardware security features. Modern CPUs are so complex that changing anything is likely to have a performance change of up to around 10% for any given workload, so when you expect your overhead to be around 5% on average you’re going to see a bunch of things that are faster, slower, or about the same. Some things have big differences for truly weird reasons. I’ve seen one thing go a lot faster because a change made the read-only data segment slightly bigger, which made two branch instructions on a hot path land in slightly different places and no longer alias in the branch predictor.
My favourite weird performance story was from some Apple folks. Apparently they got samples of a newer iPhone chip (this is probably about 10 years ago now), which was meant to be a lot faster and they found that a core part of iOS ran much, much slower. It turned out that, with the old core, it was always mispredicting a branch, which was issuing a load, and then being cancelled after 10 cycles or so. In the newer core, the branch was correctly predicted and so the load wasn’t issued. The non-speculative branch needed that load a couple of hundred cycles later and ended up stalling for 100-200 cycles waiting for memory. The cost of the memory wait fast over an order of magnitude higher than the cost of the branch misprediction. They were able to add an explicit prefetch to regain performance (and get the expected benefit from the better core), but it’s a nice example of how improving one bit of the hardware cause a huge systemic regression in performance.
-
Interesting, thanks – reminds me of some of the effects described in this paper (performance impacts of environment size and link order).
Once doing some benchmarking for a research project circa 2015 or so I found a MySQL workload that somehow got consistently somewhat faster when I attached strace to it, though I unfortunately never figured out exactly why or how it happened…
-
There was another similar paper at ASPLOS a few years later where they compiled with function and data sections and randomised the order of a bunch of benchmarks. They found that this gave a 20% perf delta and that a lot of papers about compiler optimisations were seeing a speed up simply as a result of this effect. Apparently the same team later produced a tool for properly evaluating optimisations that would do this randomisation and apply some statistics to see if your speed up is actually statistically significant.
-
-
-
-
-
-
-
Tests should be run in random order by default.
Random and parallel by default!
-
Parallel, yes, random, not so certain.
For me, the issue is reproducibility. One thing that has been the bane of my life are flaky tests (for whatever reason). So something that deliberately adds to this flakiness doesn’t help.
Whenever I do tests which include randomness (for instance Property based tests https://scalacheck.org/) I always end up specifying the seed so I can reproduce any issues.
-
RSpec (and I suspec most test frameworks) lets you specify seed for a run. When not specified it will pick one at random. So by default you have your tests ran in random order but when you have a flaky test you can specify seed and run tests in that particular order to debug it. Best of both worlds.
-
If you’re able to reproduce test failures (by failures returning the seed and runs able to take the seed as a parameter), and if you treat failures as actual bugs to fix (whether that be a bug in the application or a bug in the tests), then I don’t have a problem with randomised tests that pass sometimes and fail other times.
After all, the point of a testsuite is to find bugs, not to be deterministic. So if randomness is an effective way to find bugs, then I’m all for it!
-
After all, the point of a testsuite is to find bugs, not to be deterministic. So if randomness is an effective way to find bugs, then I’m all for it!
The issue I would bring up in the case of random test order is that while it does find bugs, the bugs it finds are often not in the application code under test – instead it tends to turn up bugs in the tests. And gets from there into the debate about cost/benefit tradeoffs. If putting in the time and effort (which aren’t free) to do testing “the right way” offers only small marginal gains in actual application code quality over doing a bare-minimum testing setup – and often, the further you go into “the right way” the more you encounter diminishing returns on code quality – then should you be putting in the time and effort to do it “the right way”? Or do you get a better overall return from a simpler testing setup and spending that time/effort elsewhere?
-
Tests are code. Code can have bugs. Therefore, tests can have bugs.
But as with any bug, it’s hard to say in general case what consequences are. Maybe it’s just a flaky test. Maybe it’s a bug that masks a bug in the application code.
You’re also right that software quality is on a spectrum. A one-off script in bash probably doesn’t need any tests. And formal correctness proof is very time/money-expensive. Another blog engine probably doesn’t need that level of correctness.
Of all the things one can do to improve software quality (including test code quality) running tests in random order is not that expensive.
-
-
-
For me, the issue is reproducibility. One thing that has been the bane of my life are flaky tests (for whatever reason). So something that deliberately adds to this flakiness doesn’t help.
Admittedly a truism, but: If the “test” is flaky, then it is not a test.
Whenever I do tests which include randomness (for instance Property based tests https://scalacheck.org/) I always end up specifying the seed so I can reproduce any issues.
Exactly. This is very good practice.
I have taken it a step further: When I build randomized tests, I have the failing test print out the source code of the new test that reproduces the problem.
-
Catch2 always prints its seed, so you can let it generate a random seed for your normal test runs, but if a test fails in CI or something, you can always look back at the log to see the seed and use that for debugging.
If you can’t reproduce a failing test because of randomness, that’s a failure of the test runner to give you the information you need.
-
-
Do you mean this url?
-
-
-
-
-
quad
6 months ago
|
link
| on:
Modular, structure-aware, and feedback-driven fuzzing engine for Rust
Bookmarked. I’m giving this a whirl the moment it’s available in stable.
-
-
Wow - completely coincidentally I also moved my website from Cloudflare to Fly.io (served using Caddy) this afternoon. No Nix though :)
-
-
Forgive me if I missed it. What is Web Assembly doing here? It sounds like the runtime uses the web assembly output? What is the benefit of this instead of running the rust code for whatever hardware your server is running?
Interesting project either way! The api seems nice at first glance.
I see security listed as a web assembly benefit, but that is for running untrusted code right? I imagine your web server code is trusted.
-
-
-
It definitely leverages a lot of WebAssembly’s features (e.g. very lightweight sandboxing, support for various languages, etc). The wasmtime documentation (the WebAssembly JIT which Lunatic uses) has a lot of information about how it executes WebAssembly, as well as the API it provides to manipulate WebAssembly programs and interface with them while running them.
In terms of concrete things Lunatic does (as I understand it)
- all IO operations are processed asynchronously øn the Rust side (so other processes can continue to run even while one process is waiting on the result of a blocking IO operation)
- every process is only permitted to run for a certain number of instructions before it is paused so that a different process can run
-
-
-
-
The wasm is because this is built on lunatic, which is a wasm runtime
-
-
I never got to take a compiler course in school, so I’m toying around with writing a compiler front-end (lexer/parser) from scratch. I’ve done stuff on my own with lex(flex)/yacc(bison) before, for this I’m not inventing a language or anything, just learning things. I wrote a math expression parser with order of operations including evaluation, simple, but it made me happy.
I’m torn between learning about type checking vs code generation, my goal is to get the point to generate a simple “hello world” standalone executable, maybe using QBE or LLVM as a backend.
-
-
I recommend Andreas Zeller’s “Why Programs Fail: A Guide to Systematic Debugging”, in which the author suggests keeping a log, where entries are in the form
- Hypothesis: The sample program works.
- Prediction: The output of sample 11 14 is “11 14.”
- Experiment: We run sample as previously.
- Observation: The output of sample 11 14 is “0 11.”
- Conclusion: The hypothesis is rejected.
(This is an example for a toy program, real examples are more complex)
Combined with algorithmic debugging, it is a really invaluable method for finding bugs
- Assume an incorrect result $R$ has the origins $O_1$, $O_2$, . . . , $O_n$.
- For each of the origins $O_i$ , algorithmic debugging inquires whether the origin $O_i$ is correct or not.
- If one of the origins $O_i$ is incorrect, algorithmic debugging restarts at step 1 with $R = O_i$.
- Otherwise, all origins $O_i$ are correct. Then, the infection must have originated at the place where $R$ was computed from the origins. The process terminates.
-
That’s the kind of thing I was looking for! TBH the above sounds somewhat heavy-weight for regular use (especially how hard describing some hypotheses can be, let alone summarizing results), but OTOH there is some unavoidable complexity in debugging and perhaps at some point this kind of overhead becomes negligible?
Thanks for the book recommendation! I’ll try to get my hands on it and use its suggestions as a starting point for further experimentation.
-
(especially how hard describing some hypotheses can be, let alone summarizing results)
I found this too when I first tried the techniques, but I’ve come to realise that if I can’t write down hypotheses about why the system isn’t working, then this usually means I need to try and understand the system better before I can effectively debug it.
TBH the above sounds somewhat heavy-weight for regular use… OTOH there is some unavoidable complexity in debugging and perhaps at some point this kind of overhead becomes negligible?
The author considers this too!
Not every problem needs the full strength of the scientific method or the formal content of a logbook. Simple problems should be solved in a simple manner—without going through the explicit process. If we find a problem we suppose to be simple, the gambler in us will head for the lighter process. Why bother with formalities? Just think hard and solve the problem.
The problem with such an implicit “quick-and-dirty” process is to know when to use it. It is not always easy to tell in advance whether a problem is simple or not. Therefore, it is useful to set up a time limit. If after 10 minutes of quick-and-dirty debugging you still have not found the defect, go for the scientific method instead and write down the problem statement in the logbook. Then, straighten out your head by making everything formal and exact—and feel free to take a break whenever necessary.
-
-
Calling it rust-analyzer’s SSR is a bit of a misnomer. SSR, like many other great ideas, came to ra from IntelliJ: https://www.jetbrains.com/help/idea/structural-search-and-replace.html.
-
-
I’ve somehow not heard of e-graphs, interesting! The end of the POPL 2021 presentation mentioned projects using egg that involved “Java testing” and “educational problems”, does anyone know what these are?
-
Author here: those projects are a little old, I should update the list. The java testing was a course project and the education problems was a project that I don’t think went anywhere ultimately (I was not involved in either directly).
-
-
The cranelift folks are exploring using an e-graph (based on egg) in their compiler: https://github.com/bytecodealliance/rfcs/pull/27
-
-
I use egg in my implementation of Cammy. It is a short single-file optimizer with little magic.
The library and approach are fine, but the language needs to be intentionally designed for it.
-
-
Cammy has trivial alpha- and eta-equivalence, and no lambda-abstractions. In fact, my jelly optimizer doesn’t know whether an atom refers to a builtin function or a composite. This was essential to getting equational reasoning which doesn’t need to manage scopes or shadowing. Also, Cammy is total and pure, so optimizations don’t have to speculate or otherwise be conditional on a context. Finally, Cammy’s textual syntax is a flavor of S-expressions which is parseable by Scheme, OCaml, and egg’s builtin
SymbolLang, so I did not have to write a new AST type in Rust.
-
-
-
-
-
-
I have heard great things about rr, but unfortunately I’ve never been able to try it: it doesn’t work on macOS and it doesn’t work in a VM (at least, it didn’t when I tried). So if you have Apple hardware at all it looks like you’re out of luck.
-
It doesn’t work on MacOS, but it will work on Apple hardware if you dual boot (also M1 iirc: https://github.com/rr-debugger/rr/pull/3144)
-
-
requires a reasonably modern x86 CPU. It depends on certain performance counter features that are not available in older CPUs.
Oh? Is this no longer dependent on having an Intel CPU? Might finally be time for me to play around with this.
Does anyone know if you get not-entirely-uninteligible results with Rust binaries? A cursory search didn’t turn up and mentions of support or explicit statements on non-support.
-
-
-
rr (somewhat experimentally I iirc) supports M1: https://github.com/rr-debugger/rr/pull/3144
-
-
-
teymour
8 months ago
|
link
| on:
zesterer/chumsky: A parser library for humans with powerful error recovery
Chumsky is a great library in and of itself. The fact that it has so few external dependencies is just the icing on the cake.
-
Just concentrate on making a great cross platform desktop client. Chasing mobile will only slow you down and make you lose focus.
-
-
LaTeX is a wonderful piece of software, but it’s often quite temperamental and the error messages are very cryptic (to me at least).
It gets worse when trying to convert LaTeX documents to HTML: https://desfontain.es/privacy/latex-to-html.html
-
Spaced repetition is really interesting, and there’s probably room for innovation in this space. What about using ML to generate “distractor” answers for multiple choice questions? Or social features so you can see how hard a question is for other users? Or VR so you can assign facts to physical locations in a “room” to make them easier to remember? There are only a few pieces of software in this space, and they’re all pretty old at this point so they don’t have these kinds of features.
-
Or VR so you can assign facts to physical locations in a “room”
A VR Memory Palace! Yes! Although apparently that technique is more specifically for recalling things in sequence, like the points of a speech or the plot of a story.
A voice interface to this software could be great too. Being able to say “Hey Cicero, I want to remember that the German word for ‘apple’ is ‘apfel’” or having Cicero randomly wake up and ask you questions during the day.
-
There’s definitely room for innovation in all these spaces, but (and maybe this is just a personal preference) I find that I like the the simplicity of current approaches. e.g. with Anki I’ve found that it can be used on old and/or resource constrained devices (which VR question generation might not be able to).
About multiple choice questions, I can’t remember exactly where the paper is, but I did see one suggesting that in order of effectiveness free recall was better than multiple choice which was better than close deletions which in term were better than merely being shown the answer periodically.
-
This book is more like work-in-progress book… right?
Yes I don’t think it will ever be “finished” either as its subject matter is (to some extent) continuously evolving.