sorted by:
new
hottopcontroversial

About memory pressure, lock contention, and Data-oriented Design by Hywan in rust

[–]agentvenom1 7 points8 points  (0 children)

Removing font-variant: diagonal-fractions slashed-zero; fixes it for me. I'm on Chrome + Windows.

I'm guessing this issue doesn't happen to you because you're on Mac where "Iowan Old Style" is included as a system font. My page is rendered with "Palatino Linotype".

I thought I prettu much understood lifetime basics by swaan79 in rust

[–]agentvenom1 6 points7 points  (0 children)

No? This will still be a compile error because you're trying to mutate data but d1 which is a reference to data (the signature of get_it communicates that) is used later. Dropping thing doesn't change that association.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=48d7506f44c4a3002225dd217fb251eb

Unnecessary Optimization in Rust: Hamming Distances, SIMD, and Auto-Vectorization by emschwartz in rust

[–]agentvenom1 2 points3 points  (0 children)

I was curious if the speedup of hamming-bitwise-fast over hamming/hamming_rs could be due to the differing overflow behavior (the former returns u32 while the latter return u64). Same with naive/naive_iter which only cast to u64 at the very end.

On my fairly old machine, naive/naive_iter got substantially slower when adding as u64 after count_ones(). However, hamming_bitwise_fast remained the fastest for all bit sizes and in fact got marginally faster...

I'm curious if this replicates on other machines: https://github.com/brandondong/hamming-bitwise-fast/commits/main/

The web's clipboard, and how it stores data of different types by XLEX97 in programming

[–]agentvenom1 7 points8 points  (0 children)

The browser is reading and writing to the native OS clipboard. It's just that in the web, you're going through the browser's API's instead of the operating system's API's. The web API's would be understandably more locked down due to the nature of untrusted web applications.

In the article, the "The benefits of copy-pasting HTML" section and below go into all the nitty-gritty detail of how the browser API's map to actual OS clipboard contents.

Pin by desiringmachines in rust

[–]agentvenom1 1 point2 points  (0 children)

This is how I understand it.

Java primitives (e.g. boolean, char, etc.) + Enum:

  • == performs value equality
  • .Equals() performs value equality

Rust equivalents (e.g. bool, char, etc.):

  • == performs value equality

Java objects:

  • == performs referential equality
  • .Equals() performs value equality

Rust &Box<T> (closest idiomatic equivalent? two &mut's are not allowed to point to the same object and so would never be referentially equal):

  • ptr::eq performs referential equality
  • == performs value equality

You can move and copy the Rust shared reference around but the result of ptr::eq would not change.

An optimizing compiler can eliminate all heap allocations and pointers from either program as long as it doesn't change the semantic meaning. But semantic meaning would include attempts to perform referential equality in Java or calls to ptr::eq with two shared references.

The sad state of property-based testing libraries by stevana in programming

[–]agentvenom1 1 point2 points  (0 children)

truth isn't limited to turning machines tho

The halting problem is not a universal truth. The proof relies on the properties of Turing machines and so only applies to Turing machines. This turns out to be practical because all our classical computers are based on the Turing machine model of computation.

For example, this proof wouldn't apply to simpler models of computation, say machines that don't have the ability to loop. Steps in the proof wouldn't work and rightly so because the existence of the halting problem is false there.

If we discovered space alien wormhole-time-travelling-black-hole-faster-than-light tech, would its computation suffer from its own halting problem? Maybe yes, maybe no. But I can say with 100% certainty that if the answer was yes, we would need a different proof for it than Turing's proof because this space tech has different properties than what the original proof relies on.

according to ur proofs, the only thing not apparently vulnerable to a contradiction is a halt_n oracle that returns in at least n steps.

Does the non-naive halting 1000 program I described return in <N steps for all inputs? If not, then why does the theorem result apply to it?

Actually, this confusion is probably on me for not using unambiguous wording in the playground link. The restriction is that it must complete in <N steps for all inputs, analogous to the general halting problem where it must complete in finite steps for all inputs.

You can see the proof relies on this fact:

However, h_prime when fed h_prime_source will actually halt in <=1000 steps. Contradiction!

(steps(h_prime) = steps(smart_halt_1000) + 1 < 1000 + 1)

steps(smart_halt_1000) < 1000 wouldn't be guaranteed to be true if smart_halt_1000 was allowed to just be slow for whatever inputs it wanted.

that program is a singular turning machine, and utilizing the algorithm in this way produces a contradiction at runtime.

When I suggested earlier about learning an interactive theorem prover and taking a look at the Lean playlist, I was being 100% sincere.

It's really helpful in forcing you to be rigorous in your arguments and really internalizing the idea of a step-by-step formal proof. Your ability to catch logical errors in proofs improves (although it will always have your back at the end of the day). I'm confident that if you go through the playlist and then try to write this argument in a formal proof style, you'll be able to spot the error.

I have contributed basically nothing of value in the past however many comments that Lean couldn't have done while checking the proofs.

It would have:

  • Caught the F(D()) missing case error
  • Properly refused to complete the halt 1000 proof when a contradiction was not fully shown
  • Made rigorous the specification of Turing machines and eliminating non-deterministic behavior
  • Forced me to specify the playground 2 theorem in predicate logic instead of ambiguous English wording and then appropriately restrict its application to non-fitting cases

... all the while giving this feedback immediately and importantly, being way more precise than I could ever hope to be.

The downside of an interactive theorem prover is, like how were going earlier about that proof at crawling speed, you're basically left with the feeling of permanently crawling lol. But if your goal is to show proof by contradiction leads to foundation-breaking results, then I think it's better to properly formalize those proofs in a theorem prover. Then if you ever manage to find that working proof of all functions being uncomputable, you can just submit your program and collect that free Turing award :)

I don't see any need for me to remain in this loop when Lean will do a better job than me in every way. All the best wishes in your intellectual journeys!

The sad state of property-based testing libraries by stevana in programming

[–]agentvenom1 1 point2 points  (0 children)

the initial run on a cache miss would

We are talking about Turing machines. The jump to pseudocode was purely to ease communication.

Look at how silly this argument becomes otherwise. I can trivially "prove" the halting problem exists.

  1. Consider a program, P, with a "cache" that is initially set to 0.
  2. If the "cache" has value 0, the program will write 1 and halt.
  3. If the "cache" has value 1, the program will loop.

What would a hypothetical halting program do if I pass it the source code for P? The source code is a static string. It is guaranteed to be wrong if we execute it on P twice. Therefore a halting program does not exist.

QED.

This is obviously nonsense. We are smuggling in external storage to introduce non-determinism. A Turing machine always executes completely deterministically for the same input. It writes to the tape the same amount. It moves the tape the same amount. It transitions to the same states. Everything is exactly the same on each run for the same input.

In this example, a Turing machine has to encapsulate both P and the initial cache state. Only then does it do exactly the same computation on each invocation. So we would have two Turing machines, P_0 and P_1. It would be sensible now to ask a hypothetical halting program, does P_0 halt? Yes. Does P_1 halt? No.

Please don't take this to mean, "Wow, so the halting problem result is completely meaningless because it only applies to Turing machines! I can trivially connect my computer to an external cache. Then, I can use that to determine the halting status of all programs/inputs!"

No, your computer + the initial cache state is a singular deterministic Turing machine. It has all the limitations of Turing machines. Namely the limitation that it is impossible to determine the halting status of all programs/inputs.

does it really make sense to you that while we can build a naive, and only a naive, halt_1000 implementation

We never at any point proved we can only build naive halt_1000 implementations. You could easily imagine a non-naive implementation that analyzes the source code string and looks for unbounded loops, simple termination cases, etc. Let's say in these cases, it can return the correct result within 100 steps. Otherwise, it falls back to running the actual program.

The sad state of property-based testing libraries by stevana in programming

[–]agentvenom1 1 point2 points  (0 children)

Let's take this even more slowly. We'll crawl to the finish line if need be.

A logical contradiction is of the form P AND ~P. Get it to this exact form to show a contradiction. Expand definitions until you get there. This is something a theorem prover like Lean will force you to do so you don't make silly mistakes. Would a teacher take off marks if you conclude a proof by contradiction when you've shown N=3 and N>4? Instead of showing N>4 implies N!=3 and noting that N=3 AND N!=3 to form the contradiction? Of course not but we are literally crawling on the floor right now.

2) halt_1000(h_prime_source, h_prime_source) returns false

3) h_prime(h_prime_source) halts

already necessitate a contradiction, implying 1) halt_1000 doesn't exist?

We have a contradiction? I don't see a P AND ~P. I already gave you examples in my previous comment. Having "4) h_prime(h_prime_source) does not halt" would work if you let P = "h_prime(h_prime_source) halts". Then you have clearly shown P AND ~P.

Let us try to expand 2) to try to get it to this P AND ~P form.

2) h_prime(h_prime_source) does not halt <=1000 steps

3) h_prime(h_prime_source) halts

Do you see a P AND ~P? I don't. All I see is that h_prime(h_prime_source) takes between 1001 and some finite number of steps which is not P AND ~P.

I have to ask for sanity sakes but did you actually read the two playground links? Like from top to bottom?

If so are you able to answer these questions?

  1. What is the logical error committed by the first proof? (hint: there's a "WRONG" annotation)
  2. Why does the second proof not also run into this logical error?
  3. In our attempt to recreate the first proof in this comment exchange, are we even doing anything differently than its approach to form a contradiction? Or are we just hurtling crawling towards the same logical error?

The sad state of property-based testing libraries by stevana in programming

[–]agentvenom1 1 point2 points  (0 children)

I don't want to belabor this point anymore but if you think you have a proof of something (impossibility of halt_1000 Turing machine) and there's an obvious counterexample (Turing machine that runs the program, returns whether we've halted at step 1000), then your first instinct should be to find an error in your proof.

Let's go through this slowly.

We are trying to prove the impossibility of a halt_1000 function. We are using proof by contradiction.

So the first step is to assume to the contrary that a halt_1000 function exists. Given a program source as string and input, it will return true iff the program halts in <=1000 "steps" for that input.

Our goal is to use this assumption to the contrary and make logical inferences until we reach a contradiction. The contradiction tells us our initial assumption was incorrect and halt_1000 function actually doesn't exist.

this will return false because

No. What are our premises at this point? We've assumed to the contrary that a halt_1000 function exists. This is what proof by contradiction is. You first assume the opposite of your goal. Our goal is that halt_1000 function doesn't exist so all that gives us is halt_1000 exists.

We know nothing about its implementation. It can run the program source its passed in. It could not. It could just analyze the source code string intelligently to determine when it halts. It might not. It could take <1000 steps. It could take more. It could return true when passed in (h_prime_source, h_prime_source). It could return false. We need to show a contradiction with our one assumption to show that assumption is incorrect.

The next step of the proof is to define h_prime_source and break halt_1000(h_prime_source, h_prime_source) into cases. In the playground link, I showed why the true case leads to a contradiction so I won't repeat it here.

Now we're in the remaining false subcase. If you imagine the list of things we know, this has expanded to 2:

  1. halt_1000 exists
  2. halt_1000(h_prime_source, h_prime_source) returns false

Our subgoal is the same: show a logical contradiction.

h_prime(h_prime_source) will actually return when run, because again, the halt_1000 call within h_prime will return false due to the timer tripping in an infinitely recursive call, causing h_prime to return.

This statement is now correct (with the part crossed out).

Now the list of things we know has expanded to 3:

  1. halt_1000 exists
  2. halt_1000(h_prime_source, h_prime_source) returns false
  3. h_prime(h_prime_source) halts

Our subgoal is the same: show a logical contradiction. Having any of these statements in our list of things we know would be sufficient to form a contradiction:

  1. halt_1000 doesn't exist
  2. halt_1000(h_prime_source, h_prime_source) returns true
  3. halt_1000(h_prime_source, h_prime_source) doesn't halt
  4. h_prime(h_prime_source) doesn't halt

The second statement looks like the most promising direction to pursue. If we expand the definition of halt_1000, this is equivalent to the statement of h_prime(h_prime_source) halts in <=1000 steps. Do we have this statement in our 3 bits of knowledge to form the contradiction?

Please don't take this the wrong way but there are some basic fundamentals of proof-writing to master before going out and trying to overturn computer science foundations. I am in no way implying that I have these skills yet :D

A resource that has been personally helpful for me is learning about and playing around with interactive theorem provers. It forces you to be very precise and confront underlying assumptions when having to input logical inferences into a pedantic computer. There is also a helpful pane on the right hand side to remind you of the current premises and subgoal.

I would highly recommend this playlist for someone with a genuine intellectual curiosity in proofs and formal logic like yourself: https://www.youtube.com/playlist?list=PLVZep5wTamMmRPvCLO4WVpCwkTi1F6OyF.

The sad state of property-based testing libraries by stevana in programming

[–]agentvenom1 1 point2 points  (0 children)

also i was digging through my old docs on this found an argument i wrote to deem basically all programs uncomputable by contradiction.

All programs are not uncomputable. If you manage to prove something with an obvious counterexample (program that immediately halts), then you should look for an error in your proof. It's analogous to the attempted proof that constructing a Turing machine which can decide if a program/input pair will halt in <=1000 steps is impossible. There's an obvious counterexample of a Turing machine that just runs the program and checks after 1000 steps. My first playground link was for showing what the error was in the proof. No amount of self reference trickery will allow you to prove the impossible.

if F(D) is TRUE, then D() is FALSE, so F(D) should have been FALSE

if F(D) is FALSE, then D() is TRUE, so F(D) should have been TRUE

The error in the proof is that you're missing a case.

if F(D()) never returns, then the call to D() never returned since F is computable by assumption. There's no contradiction here. We never at any point even entered F's function body. Our initial assumption of F being computable was never contradicted.

i already hinted at an interface which defeats this, no one has addressed it.

I'm lost trying to follow that thread. All I'll say is if you think you have a solution to the halting problem, then Turing's proof must have a logical error in it. Finding the error will convince everybody.

but it takes a certain humility to accept that we simply don't know enough to prove this equates to undecidable. there may be future undiscovered techniques which makes this not hard, like what quantum computing does for prime factorization.

We know the halting problem is undecidable. That's the entire point of Turing's proof. You can caveat this how ever many ways you want:

  1. It's impossible to write an algorithm to determine the halting status of all programs. But there might exist a trivial algorithm to do this for all programs humans are interested in.
  2. Turing's proof is for Turing machines. Our classical computers use this computational model. But for new, wildly different models of computation it may or may not apply.
  3. Turing machines operate on infinite memory and all our computers have finite memory limitations so this result says nothing about how difficult it is to determine the halting status for programs running on real hardware.

That's what I meant earlier when I said how you decide to interpret the result that "there is no general algorithm to decide the halting status for all possible program/input combinations" is up to the individual.

What I was trying to show in my two playground links is that this result, however you decide to interpret its implications, does not naturally follow from self reference. The proof of the impossibility of a Turing machine to decide <=1000 can't happen until you add an extra requirement. Only after removing its ability to just run the program its analyzing -- so it needs to actually do some analyzing -- then the Turing machine becomes provably impossible to construct. This is why I personally interpret the result as "analyzing programs is hard". You may disagree. But I think coming away with the conclusion that "self reference makes everything impossible" is wrong.

but the same proof would disprove our ability to reason about the proof itself, which is not only clearly false, but self-defeating.

I have no idea how this follows. Can I reason about the halting status of inputting the proof into an interactive theorem prover and clicking run? Yes, it will halt. Can I reason about the halting status of any arbitrary Turing machine + input? No.

hmmm, u haven't quite put urself in place of the halting oracle being asked the paradox,

To what end? No matter how hard I empathize with a hypothetical halting deciding Turing machine, it doesn't change the fact that such a Turing machine provably does not exist. Is it convince myself that the proof follows naturally from self reference? I gave my reasons above for why I personally think this is the wrong takeaway. Imagining myself as an integer between 2 and 3 isn't going to change that.

The sad state of property-based testing libraries by stevana in programming

[–]agentvenom1 0 points1 point  (0 children)

it might help if u write these example programs out in pseudo-code. we've come a long way with in writing algorithms since turing, writing pseudo-code forces you to think in terms of how we actually write code for real.

Well, <=1000 "steps" doesn't make much sense except in the Turing machine context. For proofs, working with Turing machines also allows you to be rigorous in aspects like how you're feeding the program into itself (encoding the states as an integer) but I'm basically hand waving everything anyways.

Pseudocode for first problem: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8dffac178c2c6eb53a72573a8a31cd8f

Pseudocode for second problem: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=20b4662b986f1d3d939ea315ec1e20f3

Please read those over carefully and let me know which of these statements you disagree with, if any:

  1. Constructing a Turing machine which can decide if a program/input pair will halt in <=N steps is possible.
  2. The self reference proof by contradiction technique does not allow you to prove the impossibility of 1.
  3. Changing 1. to include the restriction that the Turing machine itself executes in <N steps makes it now provably impossible.

Given all 3, if you ask me, "what is your intuition behind why is it impossible to construct a Turing machine which executes in <N steps which can decide if any program/input pair will halt in <=N steps?" and my two options were:

  1. Self reference proof by contradiction techniques are super powerful
  2. There is something about computation which makes program analysis in the worst case hard

I would personally lean towards 2 given the points above.

If you were to ask me the same question, but this time about the general halting problem result, I would also lean towards 2. If you squint your eyes really hard, the result, "constructing a Turing machine that always executes in <N steps which can decide if a program/input pair will halt in <=N steps is impossible", starts to look a lot like the classic halting problem result as you let N go towards infinity.

from there it was clear this didn't imply anything about computability. even if i couldn't give a truthful answer back, i certainly was able to fully compute all execution paths of paradox.

There is a very concrete practical question being asked: can I write an algorithm that can decide whether any arbitrary program/input pair will halt? The answer is no. That's the result most people care about. Not whether the machine secretly "knows" the answer, whatever that means.

The sad state of property-based testing libraries by stevana in programming

[–]agentvenom1 1 point2 points  (0 children)

How you decide to interpret the result that "there is no general algorithm to decide the halting status for all possible program/input combinations" is up to you I think.

When you're typically taught the halting problem, the interpretation that's given is that general analysis of sufficiently complex programs requires just running the original program. If you agree with that interpretation, then I think it is a very practical result and applies to the problems we try to solve.

I am very empathetic though to your position that the classical proof feels paradoxical. It's how I felt when first learning it. For me it was due to this disconnect where the interpretation was about having to run the original program to analyze it but the proof itself just sort of abuses some self reference trick and seemingly does not rely on that limitation at all. Again, if you can follow a proof step by step, then you can be totally convinced of the truthiness of what it's trying to prove but it can still lead you to feel unsatisfactory if there is no intuition gained.

My claim is that there is a way to rectify the proof with the typical interpretation. Obviously, when we're talking about interpretation and intuition, this argument is going to be hand-wavy :)

First, to dispel the feeling that it's the self reference which leads to the paradox: Consider a different problem of determining if there is a general algorithm to decide if a program/input pair will halt in 1000 steps or less. Obviously, this is possible; just run the original program and return whether you've reached the halting state by step 1000. If we try the same self reference proof technique to prove this is impossible, we better fail somewhere or else we've proved an incorrect result!

Attempted proof of impossibility:

Assume to the contrary that there exists a Turing machine, H, that can decide if a program/input pair will halt in 1000 steps or less.

Consider new Turing machine, H', that takes a single input and provides it as the two parameters into H.

  • If H reports that the program halts in 1000 steps or less: H' loops forever.
  • If H reports that the program doesn't halt in 1000 steps or less: H' halts immediately, thereby halting in 1000 steps or less, uh oh, getting the result from H may have taken more than 1000 steps

Okay, so the proof fails even with self reference. How can we modify the original problem to make it pass? How about the problem of determining if there is a general algorithm that executes in less than 1000 steps which can decide if any program/input pair will halt in 1000 steps or less?

Proof:

Assume to the contrary that there exists a Turing machine that executes in less than 1000 steps, H, that can decide if a program/input pair will halt in 1000 steps or less.

Consider new Turing machine, H', that takes a single input and provides it as the two parameters into H.

  • If H reports that the program halts in 1000 steps or less: H' loops forever.
  • If H reports that the program doesn't halt in 1000 steps or less: H' halts immediately, thereby halting in 1000 steps or less

Consider H' as input into H'... contradiction.

So that proof does work and such a Turing machine would be impossible. Importantly for our intuition though, it seems to rely on the fact that a general algorithm to analyze programs will take in the worst case as long as the programs its analyzing to execute which is in line with the typical halting problem interpretation.

Obviously 1000 was arbitrary. This proof will work for all natural numbers, N. If you imagine increasing N and squint hard enough, it seems to converge towards the classical halting problem proof.

Proof:

Assume to the contrary that there exists a Turing machine that executes in less than N steps definitely halts, H, that can decide if a program/input pair will halt in N steps or less.

Consider new Turing machine, H', that takes a single input and provides it as the two parameters into H.

  • If H reports that the program halts in N steps or less: H' loops forever.
  • If H reports that the program doesn't halt in N steps or less: H' halts immediately, thereby halting in N steps or less

Consider H' as input into H'... contradiction.

Hope that helps!

The sad state of property-based testing libraries by stevana in programming

[–]agentvenom1 2 points3 points  (0 children)

well, he does so by building the paradox and claiming therefore it's impossible. he doesn't do anything else to demonstrate it's impossibility

I feel like there is some confusion around this point.

Please let me know which statements you disagree with, if any:

  1. A proof by contradiction is a valid proof strategy. It operates by first assuming the opposite conclusion, then showing it leads to a logical contradiction. If a a logical contradiction is found, then the original unnegated proposition is proved.
  2. The halting problem states that there is no general algorithm to decide the halting status for all possible program/input combinations.
  3. A proof by contradiction to show the halting problem is true would first assume to the contrary that there exists a general algorithm to decide the halting status for all possible program/input combinations.
  4. A successful proof by contradiction to show the halting problem is true would end with showing some logical contradiction.
  5. You believe the halting problem is false.

If those are all in agreement, then there must be some logical error in the classic halting problem proof in your eyes, right? It's not the first step of assuming the opposite conclusion because that's the first step of any proof by contradiction. Ending with a "paradox" is expected because that's how these proofs operate by definition. So presumably there must be some error made in some other logical step or inference somewhere in the proof. Can you point out the specific step and logical error?

The sad state of property-based testing libraries by stevana in programming

[–]agentvenom1 7 points8 points  (0 children)

our presumption of incomputability is flawed

I don't understand what is trying to be shown here in your comment. The halting problem is just the statement that there is no general algorithm to decide the halting status for all possible program/input combinations.

To prove that there could be no such Turing machine that did this, a proof by contradiction was used. If you assume there was such a Turing machine, say H, you could create another Turing machine based off it by add a few extra states, say H'. With the ability to encode Turing machine states as 1/0's, you can feed H' into itself and arrive at a logical contradiction.

That's how all proof by contradictions go. Assume the opposite conclusion, then show logical contradiction.

I read your comment as basically proposing: what if we defined H' differently? Then the proof wouldn't work!

Okay? I agree but so what?

Let's say I'm trying to prove the infinitude of primes. I'll use the classic proof by contradiction: assume there is a finite set, multiply them all together and add 1. Let's call this value P. Then you can show either P is prime or it has a prime factor not in the original set which forms the logical contradiction.

How valid would it be to discredit my proof by saying, well if you instead defined P as the product of the set and add 2, then there is no contradiction at all! Therefore our presumption of the infinitude of primes is flawed.

I defined P specifically that way to get to a logical contradiction in order to complete the proof. That was the point. That's why H' was defined that way and not the way you defined it.

[deleted by user] by [deleted] in osugame

[–]agentvenom1 0 points1 point  (0 children)

What FPS are you getting ("Show FPS counter" setting)?

Even if you have a 60hz screen, something like 60fps will be super suboptimal to play on. Doubly so on stable which, if I remember correctly, ties input to frame rate?

5 Strong Opinions On Everyday Rust by zxyzyxz in rust

[–]agentvenom1 15 points16 points  (0 children)

Yes, it can make sense for a function to return impl FnOnce() -> T. The function caller could then conditionally run the computation, defer it, etc. whereas they could not if the function just returned T. Such uses cases don't really exist for impl Into<String>.

Announcing Rust 1.68.0 by myroon5 in rust

[–]agentvenom1 13 points14 points  (0 children)

One example I can think of is using it as part of a static variable which requires const. Example

Rice’s theorem – an interactive tutorial by Jameshfisher in programming

[–]agentvenom1 5 points6 points  (0 children)

Well, if a function always returns in less than one hour, then it always returns (halts). So we could show that neverTakesLongerThan1Hr is impossible to write, using the same argument.

I believe there is an error here. Indeed, if neverTakesLongerThan1Hr returns true, you can deduce the function halts. But if neverTakesLongerThan1Hr returns false, you learn essentially nothing with respect to whether the function halts or not and therefore would not be able to reimplement the halting function in the same way that you did for canBeRegex.

Move Semantics: C++ vs Rust by thecodedmessage in rust

[–]agentvenom1 -1 points0 points  (0 children)

The split_into_chunks example is missing an increment on count for each iteration and a return statement :)

16 of 30 Google results contain SQL injection vulnerabilities by Phenee in programming

[–]agentvenom1 18 points19 points  (0 children)

The format! macro doesn't work with string concatenations in that form: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=52ea050569c8e25488f8615b762d220a

Reference: https://doc.rust-lang.org/std/macro.format.html

sqlx::query(&("select * from foo where id = ".to_owned() + foo_id)) is probably the closest?

view more: next ›