Any #regex wizards here?
Is there a way to match multiple linebreaks regardless of the content but only if the number of linebreaks exceeds a value like 5?
#TIL Today I learnt that adding ? after * transforms a #regex expression from being "greedy" into "lazy" (important for performance, safe validators, and protection against DoS attacks).
I don't know how I missed this bit of knowledge for so long. :blobfoxbox:
@castarco I don't see how it protects against DoS attacks. The DoS problem is caused by badly written regexes that take "forever" to fail, so the regex engine is busy trying all possible variations to make the regex match a given string (assuming a standard backtracking implementation).
Making quantifiers non-greedy (by appending ?) does not change the number of ways a regex can match, nor does it shortcut the matching process. It simply changes the order in which alternatives are tried.
In the case of X*, the normal order is to try to match as many X's as possible and only "give back" matches if the rest of the regex fails to match. With X*?, the regex engine will try to match as few repetitions as possible (i.e. 0 at first) and only consume more if the rest of the regex fails to match. In either case all possibilities are tried before giving up.
@thunderbird Just updated Thunrderbird. Got a web page asking for donations. Page design is kinda sus (doesn't tell you who's behind it, there are no links with more info or "about us", etc., not sure this is even legal in Germany), but I decided to click the Donate button anyway. Got nothing; button doesn't work, just reloads the page. Might want to fix that.
ChatGPT
In the provided PHP code, you are defining a constant named lol and creating an array $lol with two elements. Let's break down what the echo statement will output:
"$lol[010]": This part will not output as expected. In PHP, variables inside double-quoted strings are parsed, but array indices are not parsed correctly if they are not enclosed in curly braces. Therefore, this part will not output the value of $lol['010'].
"${lol[010]}": This is a correct way to access an array element within a double-quoted string. The curly braces allow PHP to correctly parse the array and its index. This will output "Merry".
"${ lol[010]}": This is similar to the previous part, but with a space after the opening curly brace. PHP is generally tolerant of such spaces, so this should also output "Merry".
However, there's an important note about the array indices: "8" will be interpreted as an integer index (8), but "010" is a bit tricky. In PHP, a number starting with a 0 is considered octal (base 8). However, since 010 is an invalid octal number (octal digits are 0-7), PHP will interpret it as a string index instead. Thus, '010' remains as the string "010".
Putting it all together, the output of the echo statement will be something like:
Notice: Undefined variable: lol in your_script.php on line X<br></br>Merry Merry<br></br>
This notice is generated because $lol[010] is not recognized as a valid array element in the first part of the echo statement. The other two parts correctly output the string "Merry".
a #haskell question. Is there an active community around here?
I can understand how typeclasses are implemented for typeclass functions that have the implementation type as first argument (such as (>>=) in the Monad typeclass).
But for signatures like return (a -> m a) is there some special magic happening?
I currently assume its compile time type inference from return being used in a context of (>>=), as >>= expects a function (a -> m b)
@kephalos Due to the type signature of >>=, all the m type variables have to be the same in your example. The type checker then has to unify m a (from the argument of >>=) with Just 1 :: Maybe Integer and concludes m = Maybe.
@hstde@Spore Even better, the alphabetical index of function names was generated in English first and then translated, meaning the documentation looks like a scrambled mess in any other language because it is alphabetized according to what the English equivalent would be. #excel
Today I spent a few hours trying to track down a problem deep in a helper module of a complex production application written in #Haskell. Among other things, it involves threads, a monad transformer stack (3 or 4 levels deep, I think?), an SQL database, and HTTP calls to an external service.
In the end, I managed to boil one issue in the code down to the following crucial lines:
forever_mpl :: Monad m => m a -> m b<br></br>forever_mpl m = fix (m >>)<br></br><br></br>forever_mpf :: Monad m => m a -> m b<br></br>forever_mpf m = fix (self -> m >> self)<br></br>
In theory, both of these should be equivalent to forever from the base library. However ...
In one place in the code, using forever_mpl (the first definition) works correctly: It repeats an action forever. But switching to forever_mpf (the second definition) makes the code hang instead (at 0% CPU). Why?!
I know the answer now, so here's a #debugging challenge: Can you think of a reason why these two definitions should behave differently? Can you implement a Monad instance with a >> that distinguishes between them somehow?
The trick that mathematicians haven't quite figured out yet is that you can combine multiple letters into "words" and use those to name things. Then you don't need five scripts and three separate fonts just to give everything its own unique letter. #subtoot
ahhhhhrhgghghr. I finally got around to digging into a Switch game for the first time, because someone wanted me to hack one, and the first thing I see is a filename:
img/unity_logo.png
The future is now (lemmy.sdf.org)