-- Leo's gemini proxy
-- Connecting to gemini.tuxmachines.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en-GB
Tux Machines
Posted by Roy Schestowitz on May 29, 2023
> To print the list various methods such as the “for” loop, “join()”, “List Comprehension”, “str()” function, and “asterisk” ‘*’ operators are used in Python.
> To remove spaces from the string various methods such as “replace()”, “translate()”, “Regex Expression”, “strip()”, “isspace()” method, etc. are used in Python.
> Python "readlines()" method is used to read all lines from a text file and return them as a list. It is used to read specific bytes from a file or whole file.
> Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language–and is widely used by (currently) 1074 other packages on CRAN, downloaded 29.3 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 535 times according to Google Scholar.
> Let me state upfront that this strategy of keeping WebKit synchronized with parts of web-platform-tests has worked quite well for me, but I’m not at all an expert in this area so you might want to take advice from someone else.
> Once I've identified what tests will be impacted by my changes to WebKit, including what additional coverage might be needed, I create a branch in my local web-platform-tests checkout to make the necessary changes to increase coverage. I try to be a little careful here so it'll result in a nice pull request against web-platform-tests later. I’ve been a web-platform-tests contributor quite a while longer than I’ve been a WebKit contributor so perhaps it’s not surprising that my approach to test development starts with web-platform-tests.
> Introduction Yesterday I had the need to see data that had a grouping column in it. I wanted to use the tidy_four_autoplot() function on it from the {TidyDensity} library on it.
> I started programming in Rust several years ago, and it has gradually changed the way I design programs in other programming languages, most notably in Python. Before I started using Rust, I was usually writing Python code in a very dynamic and type-loose way, without type hints, passing and returning dictionaries everywhere, and occasionally falling back to “stringly-typed” interfaces. However, after experiencing the strictness of the Rust type system, and noticing all the problems that it prevents “by construction”, I suddenly became quite anxious whenever I got back to Python and wasn’t provided with the same guarantees.
> To be clear, by “guarantees” I don’t mean memory safety here (Python is reasonably memory safe as-is), but rather “soundness” – the concept of designing APIs that are very hard or outright impossible to misuse and thus prevent undefined behaviour and various bugs. In Rust, an incorrectly used interface will usually cause a compilation error. In Python, you can still execute such incorrect program, but if you use a type checker (like pyright) or an IDE with a type analyzer (like PyCharm), you can still get a similar level of quick feedback about a possible problem.
> One thing that all programs on your computer have in common is a need for memory. Programs need to be loaded from your hard drive into memory before they can be run. While running, the majority of what programs do is load values from memory, do some computation on them, and then store the result back in memory.
> In this post I'm going to introduce you to the basics of memory allocation. Allocators exist because it's not enough to have memory available, you need to use it effectively. We will visually explore how simple allocators work. We'll see some of the problems that they try to solve, and some of the techniques used to solve them. At the end of this post, you should know everything you need to know to write your own allocator.
> In this blog post, I delve into the comparison of memory consumption between asynchronous and multi-threaded programming across popular languages like Rust, Go, Java, C#, Python, Node.js and Elixir.
> Some time ago I had to compare performance of a few computer programs designed to handle a large number of network connections. I saw huge differences in memory consumption of those programs, even exceeding 20x. Some programs consumed little over 100 MB, but the others reached almost 3 GB at 10k connections. Unfortunately those programs were quite complex and differed also in features, so it would be hard to compare them directly and draw some meaningful conclusions, as that wouldn’t be an apple-to-apple comparison. This led me to an idea of creating a synthetic benchmark instead.
> I’ve been writing some massively concurrent code for mgmt lately. The concurrency makes it incredibly bug prone. In this case it’s usually races or deadlocks. I’ve got a new trick to make the process more pleasant. The Problem: I’m sure many of you have written some code like this before: // just a small excerpt for { select { case <-someEvent: // some awesome thing happened! case <-ctx.Done(): return ctx.
-- Response ended
-- Page fetched on Thu Jun 13 12:41:26 2024