>move 1 ..\1\
The system cannot find the path specified.
0 file(s) moved.
But the issue is you can't ensure LLM will generate the command with trailing slash. So there is no difference in Windows or Linux for this particular case.
> When Gemini executed move * "..\anuraag_xyz project", the wildcard was expanded and each file was individually "moved" (renamed) to anuraag_xyz project within the original directory.
> Each subsequent move overwrited the previous one, leaving only the last moved item
In a different scenario where there was only one file, the command would have moved only that one file, and no data would have been lost.
The Linux (GNU?) version (mv) can change its behaviour according to what you want.
e.g. "mv --backup -- ./* wrong-location-that-doesnt-exist" will rename your files in an unhelpful fashion, but won't lose any.
e.g. "mv --no-clobber -- ./* wrong-location-that-doesnt-exist" won't overwrite files.
It's trivial to setup an alias so that your "mv" command will by default not overwrite files. (Personally I'd rather just be wary of those kinds of commands as I might be using a system where I haven't customised aliases)
Short for Not Invented Here syndrome... when developers ignore existing libraries or solutions and implement their own version. Usually this is meant negatively, i.e. developers thinking they -need- to implement their own version, at great expense, when they could have just used an off-the-shelf library. However this article is positing that writing your own code is a good thing in some cases.
It is a good thing in some cases for a couple of reasons - first, off the shelf libraries often do a lot more things than are needed for the project at hand which can have the same effect that adding extra lanes to a highway does on traffic - more effort in the same space that could have been avoided. Second, OTS libraries can be opinionated, which winds up bending the existing codebase in ways that aren't optimal or aligned with the other code in a given ecosystem.
My guess? Most green things you see are a darker green. The extremely bright green (lime according to the W3C) is less useful, so they probably chose the color based on what they thought the user would expect.
Given that RGB is well-known, I suspect their assumption was wrong, but I have nothing to back that up.
Also, green is the brightest primary after accounting for typical human vision and typical monitors. The YUV formulas put at nearly twice as bright as red.
So a normal display has more green than you'd need, and 00ff00 green has terrible contrast against ffffff white
Extra nitpick.. green isn't even a primary colour. Red, Yellow, Blue are the primary colours that our eyes perceive. Perhaps this contributes to why the RGB numbering doesn't meet human perception of green?
Those are primary pigment colors (arguably... Should be magenta, cyan, and yellow). Those remove light to make color. Red, green, and blue are the additive primary colors.
No you have S, M and L cones in your eyes, which represent (roughly) blue, green and red.
Your eyes are most sensitive to green and yellow because the spectrum of the M and L cones overlaps. This is why a lot of sRGB is green and why the Bayer pattern has one red, one blue and two green elements.
Red, yellow and blue are the primary colors used in art education.
A #00ff00 green is gonna be much, much brighter and more intense than a #0000ff blue. If we call #0000ff "blue", it makes sense that the color called "green" should be of similar brightness/intensity to the color we call "blue".
Not that it's very consistent. The color called "red" is #ff0000, which looks brighter than both #008800 and #0000ff IMO. And arguably, "blue" shouldn't be #0000ff, since that's just not a very pleasent color. I think I might've been tempted to go with something like, red = #cc0000, green = #008800, blue = #0055ff. Or maybe go all the way and specify the colors in some perceptual color space rather than using RGB. But oh well.
(The color #0000ff for "blue" is super over used IMO. Most terminal emulators default to it as well and it just makes blue text hard to read in most out-of-the-box configurations. To get a nice blue color, you need some green in there.)
The naming is supposed to make sense for humans, not machines. Technically the "greenest green" from a technical POV is #00FF00, but the humans understanding of "green" is something more like #008000.
In Unity3D Game Engine, "Yellow" as a named color is not #ffff00 but #ffeb04, the documentation says "RGBA is (1, 0.92, 0.016, 1), but the color is nice to look at!". I bet this bit the ass of thousands of developers that used it assuming it would be #ffff00 and then wondering why the output color somewhere was wrong.
This comes from the original HTML 3.2 spec (1996) which defined 16 colors matching the Windows VGA palette, where pure #00FF00 was deemed too bright for general use, so they chose the more muted #008000 for "green" and later kept it for backward compatibility.
(A workaround exists: downgrading to version 1.2.2, but that comes with its own issues.)
The last time I experimented with audio in Python, I was surprised by how lacking its multimedia libraries are.
For example, when I needed to read audio files as data, I tried `SoundFile`, `librosa` (a wrapper around `SoundFile` or `audioread`), and `pydub`, and none of them was particularly satisfying or has seen much active development lately.
If you need to read various formats, pydub is probably your best bet (it does this by invoking ffmpeg under the hood). I was hoping for a more "native" solution, but oh well. Unfortunately, `pydub` is also unmaintained and has some serious performance issues (for example: https://github.com/jiaaro/pydub/issues/518 )
Oh, thanks for pointing this out. This was an early unpublished draft. I later changed to `playsound3` which is a modern fork of `playsound`. I've updated the web page.
Totally unrelated to the content, but about the website itself.
The site completely breaks when I visit it. After some investigation, I found out that if I enable Stylus (a CSS injection extension) with any rules (even my global ones), the site becomes unusable. Since it's built using the React framework, it doesn't just glitch; it completely breaks.
After submitting a ticket and getting a quick response from the Stylus dev, it turns out that this website (and any site built with caseme.io) will throw an error and break if it detects any node injected into `<html>`.
I don't currently use Stylus, but it breaks for me too; it looks like CSS isn't applied at all: I get some big logo images, and the text uses standard fonts. Not sure which extension triggers it, probably Dark Reader. I could still read it, so no biggie.
I'm Copilot customer since day 1 and I'm mostly satisfied with it, until a few months ago.
I noticed a mini project I was working on suddenly stopped showing any autocomplete results.
The log shows the API returns empty `model deployment ID: []` constantly.
Upon investigation, I found the reason is that my code includes the word "ass", because it is a project about parsing .ass subtitle format (Advanced SubStation Alpha).
I have to rename all my variables to work around it, and eventually this isn't enough: I have a subprocess.run to call ffmpeg to burn subtitles on video when encoding. And the VF (video filter) for that is called.. ass.
Here is an MRE (try typing anything after the line `subprocess.run` and observe the copilot log):
import subprocess
from pathlib import Path
STORAGE_DIR = R"G:\test"
def process(f, subtitle, output):
subprocess.run([
"ffmpeg", "-v", "error", "-stats", "-i", output, "-vf", f"fps=60,ass={subtitle}", "-c:a", "copy",
'-c:v', 'h264_nvenc', "-pix_fmt", "yuv420p", output, "-y"
])
def main():
for f in Path(STORAGE_DIR).iterdir():
process(f, f.with_suffix('.txt'), f.with_name(f.stem + '_ouptut' + '.mkv'))
if __name__ == '__main__':
main()
Other people have reported similar issues [1] about other "bad" words. I mean, I get it, but don't they think having "ass" in that "profanity blacklist" would cause way too many false positives? To make it worse, MS/GitHub seem refusing to make any solution or even communicate about this issue.
I've opened a ticket on GitHub's support system too, but got no response whatsoever after weeks. I'm very disappointed as a paid user.
To any GitHub employee if you're by chance reading this, it would be tremendously helpful if you can help mention this issue internally. Thank you in advance.
A similar thing happens when the word "password" is present in the file. Copilot stops autocompleting.
I haven't tried this yet, but I wonder if putting a comment at the top saying "the term ass refers to…" would convince copilot that you're not being profane.
I've also been a user since day one and other than that "safety feature" it's been such a fantastic addition. I turned off intellisense because copilot does a much better job (more accurate, longer auto completions) albeit with slightly increased latency
