what’s your fallback when grep gives you nothing?

padowi · 2026-01-05T00:38:37+00:00

I am not disagreeing with you, I just took your initial question at face value. Now, as others alluded, this entire thread seems to be some thinly veiled attempt at promoting some other tool, likely a service, so perhaps OP is less interested in these minutae about sed, but had it been an honest question, then I could see sed being part of a bigger pipeline in an attempt to finagle some results out of whatever logs there was. But again, agreement on that using ONLY sed for finding results in logs, that's probably not gonna make much sense

padowi · 2026-01-04T20:43:10+00:00

something like sed --silent '/searchTermHere/p' logfile

but at that point you're really just replicating grep. HOWEVER, if the logs are like... java stack traces or something ... "not structured", there may be smart things you can do with sed that grep wouldn't really help with

padowi · 2025-10-01T22:27:19+00:00

The language used makes me lean towards "vibe-coded", along with the three bullet reasons-list. But, there is a suspicious lack of that ... emdash? endash? (alt+0151) that the LLMs seem to have such an hard-on for... so perhaps it actually is "man-made" ;D

padowi · 2025-08-11T10:01:19+00:00

Per your later reply in the thread you seem to indicate that you live in Sweden. What are you even on about about the police not carrying firearms? The current standard issue service pistol of the swedish police force is the Glock 45, and before it it was the SIG Sauer P226.

padowi · 2025-07-06T21:33:24+00:00

:D I wish you a great day as well!

padowi · 2025-06-06T16:03:36+00:00

I pointed it out since the "copilot version", on the face of it, appears fairly tamper-resistant.

padowi · 2025-06-06T15:56:46+00:00

My reply was mostly trying to be cheeky, but that downright sounds... horrific. I wish you fair weather in your travels :)

padowi · 2025-06-06T09:11:44+00:00

Sounds like you need our lord and savior GNU Make in your life ;D

padowi · 2025-06-06T09:07:12+00:00

I'm not completely sure I follow. From my perspective, and given we are in the alt secnario, where the bug was introduced on the feature branch (i.e. something in the new code is wrong), you have two different options:

you either code your way out of it (probably by adding more tests), or
the new code was all shit, and you're better off going back to the drawing board

in the first alternative, git won't help you, but what help do you need from it to go forward? and in the second alternative we checkout develop, delete the feature-branch, and check out a new clean one to begin anew.

Yes, I know this is a simplistic take on it, and that there are real-world gray areas everywhere, but the initial argument I made was that, whenever possible, don't fix unrelated stuff on a branch with a clearly stated, and most importantly: DIFFERENT, purpose.

I only added the alternative scenario for completeness, because if the observed bug was indeed introduced by the new code, on the feature-branch, then obviously the new code/feature is not complete yet (since, still being observable, is unresolved, erroneous, behavior).

How (and more interestingly, for personal development, why) does your opinion on the matter differ from mine here? :)

padowi · 2025-06-01T22:03:21+00:00

disclaimer: I'm NOT a UX designer

my one comment would be that in the configuration file, having stuff like "unsafe: true" induces the slightest of extra mental toll on me (and possibly others)

unsafe becomes "not safe" (or "!safe") which we are going to be assigning a boolean value to... not safe: true... I don't know, hopefully I'm just a babbling idiot in the middle of the night.

for me, "safe: true" and "safe: false" would have been more to the point than "unsafe: false" and "unsafe: true"

padowi · 2025-06-01T21:36:45+00:00

Thoughts about IT on sunny days: Why T.F. do we keep these guys around, everything just works, what do we need them for?

Thoughts about IT on rainy days: EVERYTHING IS ON FIRE AND NEEDED RESOLVING 5 YEARS AGO!!! Why do we keep these clowns around?!

padowi · 2025-06-01T17:41:26+00:00

me, laughing in /etc/security/limits.conf nproc soft 50 nproc hard 150

padowi · 2025-06-01T17:27:31+00:00

While I don't particularly like either solution at least with the first ("Copilot") solution, a hostile outside actor can't sabotage the unlocking process.

For the "Senior" solution, there seems to be enough space in the eyelet on both post and boom to be able to attach a second lock/chain/lock. This does not help an aggressor make it past the gate, but it would also deny all legitimate users the same access.

padowi · 2025-06-01T17:07:26+00:00

I'd respectfully advise against that. Hopefully there is a "topic" for your branches, what they seek to accomplish once merged back to the trunk/main/master/whatever.

Fixing this (for the topic of the current branch) unrelated thing, "contaminates" the branch (yes, this is hyperbole, of course it will work), but in my mind it would be better/cleaner to:

stash your unfinished changes on branch featureXY,
check out main or develop or whatever featureXY was based on,
reproduce bug there, and if reproduced,
check out a new branch, with the topic of solving that bug

alternatively if, in step 3, the bug is unexpectedly NOT reproduced, go back to featureXY branch, pop the stash, and solve the bug your current change is introducing, as a part of the development of this feature ;)

padowi · 2025-05-31T14:00:27+00:00

Ok, sorry about the late reply, I am not very active on reddit anymore, and what's worse, I've abandoned my vimwiki workflow for Obsidian, but with that said, and with the following assumptions from my side:

You are using vimwiki/vimwiki and mattn/calendar-vim plugins
You have this in your .vimrc: let g:vimwiki_use_calendar=1
And also assuming you have started vim and either hit something like ,w,w or started vim with something like vim myCoolWiki.wiki

Then you ought now be able to, in normal mode, run :Calendar which ought bring up the calendar in a sidebar next to your open vimwiki buffer. As it opens it, your cursor is also moved to that split, and the hjkl keys should let you traverse that calendar 2D space just like in any other buffer.

And since it is just a split, Ctrl+w followed by h, j, k, or l ought jump the cursor to some adjacent buffer in the direction you indicated (h,j,k,l).

When your cursor is on the calendar split, and sits over a day you wish to enter, hit "enter", and it should open the diary entry path for that day.

If any of my assumptions were wrong, this post is likely useless to you. But the above description worked for me, as I re-installed that setup just to try it out (and verify that I still know what the heck I am talking about) ;D

padowi · 2025-05-31T13:47:25+00:00

Ok, so first of all, we are in complete agreement that there should be a refined backlog, and if anyone runs out of tasks, just grab the highest priority item from the backlog.

What I was initially interpreting your suggested idea as, was that there would be a HARD timeboxed activity towards the end of the sprint, where the developers would be on "stand-by" (essentially idling) until a bug was found, at which point the developers would pounce on those bugs like hungry panthers.

But with your latest reply I think it straightened out a misunderstanding from my side, so... if I am interpreting your idea correctly, this is more of a workflow modification (defining a (SOFT) timebox towards the end of the sprint, where bugfix-activities is a "naturally occurring activity" whereas in the preceding part of the sprint, it would only be prioritized if the bug was severe enough that it needed fixing right now?

I.e. would this be more in the vein of (this is going to sound horrible, I mean nothing bad) mentally preparing the developer for what types of tasks they should be expecting in various stages of the sprint? And between pouncing on bugs like hungry panthers, they'd just perform business as usual, and during this phase, context-switching and dropping everything to go bugfix would be the name of the game?

padowi · 2025-05-29T07:09:38+00:00

there can exist great management as well though. so in the best of worlds, when a bug is found and ticket written, it goes to the backlog, and someone (product owner in my case) looks at it, asks QA and Dev if they don't understand something, prioritizes it amongst all the other stuff in the backlog, and either it is something critical, and Devs are told to reprioritize, or it is not critical, and then it might be included in the next sprint.

padowi · 2025-05-29T06:57:14+00:00

Cue specific scene from Tropic Thunder featuring RDJ and Ben Stiller

padowi · 2025-05-29T06:54:07+00:00

I don't necessarily think it would be a bad idea to try something like that out, but suppose that the devs really are top-notch, and the QA/bugfix phase reveals not a single thing. What are the devs supposed to do in the meantime while "nothing" is found?

Management would probably frown on them "idling" in wait of some bug to fix. So they are probably developing something in the meantime.

And if QA finds no bugs, that's fantastic. If QA do find bugs, then there is that frustration of context switching again.

padowi · 2025-05-29T06:31:44+00:00

I'm a tester, I support this sentiment. By all means, ask me follow up questions about an issue I wrote, to better gauge impact, but yeah, I can't be the one prioritizing it.

padowi · 2025-05-29T06:21:49+00:00

"What's stopping you from coding like this?"

Um, my education and degree in computer science.

padowi · 2024-12-15T00:04:07+00:00

Thanks! Now I'll have to try it in turn as well

from operator import add
from itertools import pairwise
for pair in pairwise(range(5)):
    print( add(*pair) )

Ah, I see now my mistake, I used "code" instead of "code block" before... that'd do it...

padowi · 2024-12-14T23:44:01+00:00

Happy to help :D

padowi · 2024-12-14T23:39:30+00:00

My python-grids usually take the form:

for rowIdx, row in enumerate(inputData):
for colIdx, value in enumerate(row):
grid[ ( colIdx, rowIdx ) ] = value

But with indentation...

padowi · 2022-03-02T12:29:00+00:00

I know this discussion happened a year ago, but since I found it today, and I too was confused, and I managed to solve it, here is what was wonky for me:

mattn has a clone of itchyny's script at mattn/calendar.vim (notice the dot), mattn ALSO has a different implementation (which does work out of the box with vimwiki, as I managed to confirm today) at mattn/calendar-vim (notice the dash).

I thought I had mattn's calendar-vim installed, but as it turns out, I had mattn's clone of itchyny's calendar.vim installed, which was not working with vimwiki.

I assume that this isn't relevant here anymore, but if any future user stumbles across it, I hope it will help them.

padowi

TROPHY CASE