Hacker Newsnew | past | comments | ask | show | jobs | submit | smcameron's commentslogin

Scott Manley has a couple of nice videos about wormholes:

https://www.youtube.com/watch?v=V7e-1bRpweo

https://www.youtube.com/watch?v=PVO8nvb1o2w

The second video is about how the first video was made.


Philomena Cunk also discusses wormholes with Prof.Brian Cox, https://www.youtube.com/watch?v=YPX0v9NzzrM.


Presumably, not to be confused with Rexx[1]. Namespace collisions ... or perhaps "wrecks".

1. https://en.wikipedia.org/wiki/Rexx.


It was for me and I intended to comment regarding same.


It requires trivial effort to search for prior art before naming something.

OP: Worth doing if you'd like others to invest time lookong at your project.


Yeah but pretty much every name will be taken by something? As long as it's not too close to your new project, I think it doesn't matter that much.


The sample set of programming languages means that every name is most certainly not taken, and every language is too close for identical names for unrelated languages being acceptable.


Must be nice. I live in Virginia, outside Richmond. For the past 8 years, the power company has failed to provide me with even 3 nines of power availability (that means at least 9 hours of outage every year for the past 8 years. Just had a 17 hour outage as of last night, lost everything in my fridge. Again.)


I wonder if you could replace the whole github issues feature with just a directory within each git repo named "Issues/". Within that, have another couple directories, "open/", and "closed/". Within "open", have a directory per issue, e.g. "such-and-such-does-not-work/". Within each issue directory, have "issue.txt", or "issue.md", which takes the place of the page for each issue on github. You could store other things in the issue directory which "issue.md" could reference, e.g. screen shots, logs, whatever. When an issue is closed, it gets git mv'ed to "closed/". You want to see a list of open issues sorted by time? Just "ls -ltr Issues/open". Want to see open issues related to the frakfrobber? "grep -i frakfrobber Issues/open/*". Add a comment to an issue? "vim Issues/open/my-issue/issue.md; git add !$; git commit -m 'Updated my-issue';" It would move the entire issues subsystem back under control of bare "git" and make it portable. Undoubtedly, I am not the first to think of such a thing.


The whole point of issues is that users can create them when they don't have repo write access.


Check out Haxxy, it has a lot of fresh ideas related to issues/pr management

https://youtu.be/iBDUTaKWVdU


I don't think a YouTube link is the best way to evangelize a new tool.


Thanks for pointing me to that! Definitely some cool ideas in there. Almost seems like some of those ideas could be incorporated into git itself.



I built a model sailboat[1] one time, and if it were for myself and not a gift, I would have named it "Sea Hacker".

[1] It was "Schooner Irene" from here: http://www.bearospaceindustries.com/boats2.html


I recently was sent patches for my open source space game[1] that added cascaded shadow mapping[1] and gravitational lensing[3] for black holes, both things that I've wanted for years, but found too difficult to tackle. The patches were made with Claude Opus doing pretty much all the work, guided by a human. The quality of the patches was, in my estimation, pretty damn good. It didn't do weird things, it used the infrastructure already present, it looked like what I wish I could have written. It was clearly not plagiarized in bulk, in as much as it was so well integrated with my existing code, though I imagine all CSM code/shaders and gravitational lensing shaders tend to look pretty similar, or at least do similar things. It was eye-opening to find out that Claude was capable of doing such a thing.

Neither of these changes affect the game play, they are both purely aesthetic in their effects, without introducing anything which might be called "art" in a traditional sense, unless you count crudely modeling the behavior of light in shaders and C code as "art", but at that point the distinction between code and art vanishes. I had previously had a "no-ai" policy in my codebase, just as a kind of over-reaction, and kind of, "if I ban it, then I don't have to think about it" response. But these patches... after studying them, there's just no way I wasn't accepting them.

[1] https://github.com/smcameron/space-nerds-in-space [2] https://en.wikipedia.org/wiki/Shadow_mapping [3] https://en.wikipedia.org/wiki/Gravitational_lens


For TTS I wonder how this compares to nanotts[1] with the en-GB voice, which is sort of unreasonably good.

[1] https://github.com/gmn/nanotts


At my local hackerspace, people sometimes laser cut solder stencils out of transparencies -- the plastic sheets you use with overhead projecters. The trick is to put a piece of paper under the transparency when laser cutting, otherwise they tend to melt too much and deform, but somehow the piece of paper prevents this, maybe the laser needs something non-transparent to interact with to get the heat in quickly and move on quickly. Anyway they worked pretty well, but obviously not as durable as steel, so after some number of uses they start to wear out. (Can't remember how many really, but probably something like 20? more than just 3 or 4 I think. Probably also depends on the density of holes, a big swiss cheesed area will fail sooner.) If the circuit's not too big you can cut several stencils out of one transparency all in one go.


That breaks git bisect.


Squash all your temporary commits before you push.


No, you don't commit trash to a public branch, EVER, if you can help it. Your commits are as perfect as you can make them, and that does not mean squashed in a trash compactor. That means one logical idea per commit, compiles and works as perfectly as you can make it. Use stgit, and this is easy. You do not break git bisect. No need to squash your trash in a trash compactor. Your standards are lower than mine, not higher.


Disagree. You need small, git bisectable commits. Use stgit to do it and it's nearly effortless.


Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: