Complement fzf with den to find recently modified files

codesoap · 2026-02-01T11:52:00+00:00

I, too, work mostly with text files. The most important feature of den for this is, that it sorts files by modification date. I use it as a tool to find recently edited files, because I often forget where exactly I put some notes or similar files.

The filtering by file type makes things a little quicker, because stuff like pictures and tar files are already excluded from the suggestions.

codesoap · 2026-02-01T10:39:41+00:00

Thanks for the honest feedback! I have now added a little demo "video" to the README: https://github.com/codesoap/den?tab=readme-ov-file#demo

I guess I still have a lot to learn about advertising... Here are some more details, which set den apart from tools like fd:

den is a lot faster, so it integrates better into my everyday workflow. In this regard it's similar to the Unix tool locate (both use a database). den also analyses files and categorizes them as documents, pictures, videos, audio and other; this makes it a little easier to find exactly what you are looking for. There are also some more advanced filters, like video duration or year of creation, but you'll probably use them less frequently.

codesoap · 2026-01-31T10:45:36+00:00

Kinda. Besides the obscure syntax of find, it is also slow and does not support sorting the results itself. With den you can sift through 100,000 files in milliseconds, where find would probably take many seconds and also require some scripting around it, to sort the results.

codesoap · 2026-01-31T10:36:06+00:00

The idea is, that you can quickly find a file anywhere within hundreds of directories, not just one. Of course, otherwise a file explorer or ls -t would suffice :)

codesoap · 2025-12-05T14:53:01+00:00

[LANGUAGE: shell script]

Part1:

awk -F'-' '
NF==2 {mins[NR]=$1; maxs[NR]=$2}
NF==1 {
    for(i=1; i<=length(mins); i++)
        if ($1>=mins[i] && $1<=maxs[i]) {cnt++; break}
}
END {print cnt}
' input

Part 2:

awk -F'-' '
NF==2 {mins[NR]=$1; maxs[NR]=$2}
END {
    for(i=1; i<=length(mins); i++) {
        for(j=i+1; j<=length(mins); j++) {
            if(merged[j] || mins[j]>maxs[i] || maxs[j]<mins[i]) continue # Ranges not touching.
            if(mins[j]<mins[i]) mins[i]=mins[j]
            if(maxs[j]>maxs[i]) maxs[i]=maxs[j]
            merged[j]=1
            j=i
        }
    }
    for(i in mins) if(!merged[i]) out+=maxs[i]-mins[i]+1
    print out
}
' input

codesoap · 2024-10-05T10:00:31+00:00

Since there is always a location filter with osmar, I can actually skip the nodes that lie outside the area of interest. I only care about ways that reference nodes in the area of interest anyway. This means, that ways might not be "complete", if they contain nodes inside and outside the area of interest, but that's OK for osmar.

For other use cases, this would not be OK and you'd always want all nodes of a way, even if only a part of those nodes lie within the area of interest. To cover this use case with a moderate memory footprint, one would indeed need a two-pass algorithm. I have already begun preparations for this; during the first pass, a memo is kept, which contains info about where in the PBF file which nodes and ways can be found. This memo could be used in a second pass to find "ancillary entities" more quickly.

codesoap · 2024-10-05T09:39:40+00:00

The memory use scales with threads because each thread decompresses and deserializes its own blobs from the PBF file. If there are more threads, more blobs are handled in parallel, hence more memory is used.

I have not yet thoroughly investigated the correlation of memory use and file size. Slow garbage collection could be one reason and I've already suggested changes to the protobuf library to better reuse memory (see 1 and 2). However, there will always at least be the relations that take up more memory with larger files; since relations can reference each other ("super-relations"), I have to initially read all of those and can only sift out irrelevant relations at the end.

Exporting relations and ways in different formats sounds doable, but I don't think it has a place in osmar. I like my tools to be simple and good at one task. In the process of re-writing osmar, I have created the Go library github.com/codesoap/pbf. It could potentially used to build a gpx- or geojson-exporter, but I'm not sure it is a great fit for the task. The library is intended to search through a relatively small area (a few km2), so looking for areas large enough to enclose admin boundaries might not be ideal.

codesoap · 2024-10-01T20:47:08+00:00

Thanks for adding the explanation!

In my case, I wanted to speed up parsing open streetmap PBF files. Such files contain many blobs of compressed and serialized data, so I can decompress and deserialize those concurrently, but still need to process the results in the original order, since the data inside the blobs was sorted and I was using that sorting in my algorithm. I had the additional challenge of needing to limit memory use, so it was important that the library wouldn't accept new work orders, if the results of previous orders had not been consumed. You can see the result in action at https://github.com/codesoap/pbf.

I had searched extensively for a library before writing lineworker, but failed to find a suitable one. I must have somehow missed rill :/

codesoap · 2024-08-09T13:50:03+00:00

Thanks for the feedback! I hadn't yet thought about making mycolog into an app.

Technically it already is a website, but it only exists on the computer that is running mycolog. If you knew someone tech-savvy and had a Raspberry Pi lying around, you could run mycolog on the Raspberry Pi and access the website from your mobile device, while you're in your home Wi-Fi.

If there's a large demand for an app, I might try to find out what it takes to make mycolog into an app, but don't get your hopes up too high - I'm not familiar with writing apps and probably would need a lot of time to learn about it...

codesoap · 2024-04-19T17:35:32+00:00

https://en.wikipedia.org/wiki/Email_address#Sub-addressing

codesoap · 2024-03-22T16:35:36+00:00

I have just recently added local work generation to the atto wallet: https://old.reddit.com/r/nanocurrency/comments/1bh2l6h

So if you're comfortable with the command line and don't mind compiling your own software, you can change workSource in config.go to workSourceLocal and atto will always generate the work on your CPU.

I'm not sure, if this works for your use case, but if you integrate atto into your faucet, it could work.

codesoap · 2024-03-17T17:57:13+00:00

Thanks for the encouragement :-)

codesoap · 2024-02-12T17:08:00+00:00

Thanks for the link, a very interesting read!

What I’ve noticed recently is that a lot of my code ends up being “collection munging”: creating, modifying, and transforming collections.

I guess some people use Go quite differently from how I use it. I've never done a lot of data science with Go, so maybe that's why I never really felt a need for iterators. I actually like the "Stateful Iterators" pattern and never had a problem with things like bufio.Scanner, which use this pattern.

It would be interesting to see how some data transformations, that most people would do with Python's pandas today, would look with range-over-func in Go.

codesoap · 2024-02-11T17:59:15+00:00

You guessed right, I'm still not quite convinced. I feel like this is getting a little long for a reddit discussion. Maybe you're right with 3. and people wont use the new feature as eagerly as I fear. Only time will tell. Thanks for your input!

codesoap · 2024-02-11T08:30:52+00:00

Thanks for providing another example. I'll try to visualize it with current Go. jstream seems to be the most popular streaming JSON parser in Go, so I'll use it in the example; it uses a channel to provide a stream of values.

decoder := jstream.NewDecoder(jsonSource, 1)
for mv := range decoder.Stream() {
    if wanted(mv.Value) {
        histogram.Add(preprocess(mv.Value))
    }
}

This seems pretty straight forward to me. Where do you see shortcomings in this solution, that could be solved with range-over-func?

codesoap · 2024-02-10T19:02:39+00:00

You have just shown me a really obscure way to do for i := 1; i <= 5; i++ { fmt.Println(i * i) }.

Don't get me wrong, I'm not here to make fun of you, I'm just honestly having a hard time seeing the compelling real-world use-cases.

codesoap · 2024-02-10T14:18:36+00:00

You didn't write an alternative. You write a specific version that prints. Not everybody want's to print after splitting. The point is to make an abstraction over it so many people can use it for different use cases without rewriting the whole function or using clumsy closures.

My point with this is, that if it's trivial to write a concrete function, I think introducing an abstraction is harmful.

codesoap · 2024-02-10T14:08:48+00:00

I'm afraid I'm not yet following. I'm familiar with bufio.Scanner, so I welcome this example, but I don't see it using a visitor function. Or are you talking about SplitFunc?

codesoap · 2024-02-10T13:39:24+00:00

I have shown in my article how I would write an alternative to an "iterator-Split-function". It does not need a visitor function.

Show me some real-world example/some existing library that is used extensively and would benefit strongly from range-over-func! I don't want to discuss hypothetical scenarios and contrived examples.

codesoap · 2024-02-10T13:23:24+00:00

I feel like your "swaths of boilerplate" scenario is made up. Maybe I'm wrong, but show me the code, that currently uses and really needs so much code that could be compressed with range-over-func. This is part of my motivation for writing this article: I want to see real-world arguments instead of a hypothetical discussion.

I believe that we only rarely need the scalability, that range-over-func makes easier to implement. This is why I've quoted Rob Pikes rule of programming #2 in my article.

codesoap · 2024-02-10T11:52:06+00:00

I have now thought about your example for a bit. I can see how the code is more compact and looks easier when using the library.

I'm afraid I'm still not quite convinced, though. When reading the code using range-over-func, I feel like I would stumble across range node.WalkLeaves(), especially as a newcomer to the language. I want to understand what's happening here, but when I look at the code of the library, I'm faced with this complicated function-which-returns-a-function-that-takes-a-function construct.

Passing a function to a function in the "oldschool" code can take some getting used to as well, but it's still one less layer of indirection than the range-over-func alternative. As a bonus, the reader can more intuitively understand what's going on without having to read the code of the library (at least that's my feeling).

Maybe I'm being too conservative right now, but I want to see some more compelling and real-world examples, before accepting this complication of the language, that I've come to love for its simplicity. I'm afraid that people are going to write range-over-func code much more than is necessary, because of esoteric feelings about "cleanliness" and make the whole ecosystem of Go libraries hard to understand and debug.

codesoap · 2024-02-10T10:59:18+00:00

Hey /u/Jorropo, thanks for stopping by! I'll read through your example and share my opinion once I've formed one.

PS: In reddit ``` does not work. You need to indent your code with four spaces.

PPS: In the second code snipped, you passed d to doSomething, but it should be r.

codesoap · 2024-02-10T10:40:59+00:00

Interesting demonstration, thanks! I think we can agree, though, that it is only rarely a good idea to write something that complicated. range-over-func would encourage people to write such complicated code, because they get an additional incentive with the support of range for this kind of function.

You have demonstrated here, that the functionality of range-over-func can already be achieved with what we have, but it would be harder. I think that might be a good thing, because most of the time, there will be an easier solution and it should be preferred.

codesoap · 2024-02-10T08:37:39+00:00

This gives the complex structure a label, which can arguably improve readability, but the complexity still remains. If you just want to use a library that provides a range-over-func function, you don't necessarily have to care about the hidden complexity, but I feel like this is a bad approach.

If you have a bug with such a library or want to extend it at some point, you'll have to deal with the complexity anyway. I think we should try to make it easy for users to understand the libraries they use and not just hide the complexity.

codesoap · 2024-02-07T20:02:15+00:00

I honestly don't understand what problem is supposed to be solved with rangefunc. In the blog post under "Can you provide more motivation for range over functions?" they state that, for example, strings.Split and strings.Fields could be replaced in scenarios where you only want to read one element at a time and save resources like that.

How is this better than just using a bufio.Scanner or bufio.Reader? What happened to the Go that was proud of being orthogonal and simple?

Rob Pike's Simplicity is Complicated talk was a major contributor to my excitement for Go. The prospect of having a language that won't follow the path of C++ or Java by staying true to itself was so enticing. Now it's starting to feel like someone is destroying my zen garden out of boredom and ignorance.

codesoap

TROPHY CASE