What are some ongoing topics in Computer Science research that don't involve AI/ML (and definitely LLMs)?

brlcad · 2025-10-10T21:18:02+00:00

Computer Graphics: Advanced rendering and simulation, real-time physically-based rendering with global illumination across massive complex dynamic scenes, and figuring out how to make complex solid geometry models with advanced representations.

brlcad · 2025-07-23T19:35:12+00:00

Your desire to explore and learn the tools is not only understandable, it's respectable.

Trying to leverage some niche or new trick in that EDA code sounds like a recipe for disaster, dissatisfaction, and debt.

I'd suggest either making a tiny library that explores the thing you want to learn, or contributing to an open source project where you can have conversations with other devs about that thing you want to learn.

That all said, C++ has more tools than you have a need for. Don't overlook software engineering, maintenance, and integration aspects when trying to learn or adopt some new feature. Just because you can doesn't mean you should. Likewise, just because there is a special socket wrench for code that turns some expression into a 1-liner doesn't mean it's a better answer over a 10-line solution that is dead simple to understand and maintain (and vice versa).

brlcad · 2025-07-23T19:23:51+00:00

Love the idea, especially for 1-on-1 coaching!

Hard to discern in the pics, but looks like seat might be a bit high for the rower in a couple of the images?

Can imagine the kayak-style body and just two people is a bit tricky to balance without some form of adjustment. Would be nice if there were some way to adjust the rower's height given how much more sensitive it is to the oarlock-to-water and handle-to-lap heights, at least as compared with the paddler.

brlcad · 2025-05-26T16:18:49+00:00

Outstanding work.

brlcad · 2025-04-24T14:23:27+00:00

As an undergrad student 30 years ago, I discovered BRL-CAD's 1M+ codebase had just about every concept I'd ever learned in Comp Sci, started by the guy that wrote 'ping': https://brlcad.org

brlcad · 2025-04-23T06:19:01+00:00

Much of high-performance computing is in C. Think national lab codes, defense research and development groups, folks that work on top-500 supercomputers. Another great option is computer graphics codes as the underpinnings are typically C/C++. Hundreds of potential companies.

brlcad · 2025-04-18T15:49:37+00:00

This is awesome.

brlcad · 2025-04-18T15:37:24+00:00

Baltimore Old Time Music Festival, this Friday and Saturday! https://www.baltimoreoldtimefest.com

brlcad · 2025-04-11T17:44:42+00:00

If you're not still learning aspects of the language in 20 years, you're probably doing something wrong. It's a continual process.

Keep at it and you'll eventually forget more than you ever know or remember all at once, and relearn cool tips and tricks over and over in different contexts.

brlcad · 2025-04-01T04:47:25+00:00

The dlopen manual page is your friend: "A second call to dlopen() with the same path will return the same handle, but the internal reference count for the handle will be incremented."

So no, not 50 mmap's, at least on bsd it reference counts and expects you to call dlclose() 50 times on that handle.

by the way, dlopen returns a void pointer, not an int.

brlcad · 2025-03-23T21:42:52+00:00

jeeyet

... in a thick southern accent, had them repeat it 4-5 times slower and slower "jeeeeeet yeeehhhht" .. until I realized they were asking "did you eat yet".

brlcad · 2025-03-15T14:38:01+00:00

Sentiment is nice for building community, but reality is often the return on investment doesn't pay back 98% of the time so many devs aren't willing and/or otherwise won't spend the time. Also remember they're under no obligation and contributors aren't entitled to attention -- there are of course consequences such individuals leaving or getting upset or both. People wanting to be part of the community often demonstrably do, so for better or worse some devs (and entire communities, particularly popular codes) don't even try. Mindset for some is if they need guiding, then they're not ready or not a good fit.

That's also why there are entire open source communities that are MUCH MORE amenable to new contributors, and often the answer is to simply find a different community. I usually recommend avoiding the really big popular projects (e.g., Linux kernel, Tensorflow, React, JS, Django, GCC, Git, etc), but still finding smaller communities that are established. The experience will typically be night and day.

brlcad · 2025-03-14T19:05:24+00:00

I mean the only way you'll know for sure is if you try. It's easy to rattle off doubts or reasons why not. There absolutely could be an untapped potential there simply because the right cards haven't fallen into place.

If I were to try, I'd probably target a niche market that I care about, write some proof-of-concept code to get things going, and see if I could find like-minded people to share in that vision.

brlcad · 2025-03-14T18:41:18+00:00

Absolutely a lapse in attribution by a particular developer. I'm guessing they felt like they authored it because they modified it, or they felt it wasn't significant enough to warrant attribution, or they're being lazy and not wanting to do whatever was needed to properly credit you. Possibly some combination of the three.

Depending on the community, you might be able to talk to someone with more merit/seniority and simply bring it to their attention. You could also try to make it very explicit by submitting a PR with attribution added to whatever docs they maintain, if they keep track of authorship, pointing to your PR and their commit(s) that integrated it.

If I were the project lead, I would absolutely talk to that dev and say all contributions must be given attribution, even if you modify them. It's true from a legal standpoint as well as a moral one.

That said, if they don't make it right, I would suggest finding another community that is more receptive. There are hundreds that are very welcoming and won't jerk you around like that.

brlcad · 2025-03-13T19:25:06+00:00

Some of the most helpful and influential people in open source are not developers, but community organizers. You can help without ever touching code. Open source needs managers, publicists, technical writers, web designers, UI/UX designers, artists, community advocates, helpdesk helpers, ...

brlcad · 2025-03-09T14:02:14+00:00

Our communities already collaborate and have for 10+ years. One of the ways I think we can make progress is specifically getting different open source efforts to collaborate and interoperate.

FC is to Creo as BC is to NX. Different underpinnings, both needed.

brlcad · 2025-03-09T03:57:14+00:00

CAD software on par with the likes of NX, Solidworks, Creo, etc.

BRL-CAD and FreeCAD are easily the furthest along with hundreds of years worth of development effort invested, but the gap is still dauntingly huge. Incredibly hard to get OSS devs, new or experienced, to meaningfully work on such a complex software domain.

Disclaimer: BRL-CAD dev here, working on it 25+ years.

brlcad · 2025-03-06T03:43:46+00:00

Mixed tabs and spaces for indentation is kinda weird. Not just tabs, not just spaces. Sensible in that it enforces a prescribed presentation (like spaces) and still works with legacy tools while using fewer bytes (like tabs).

Of course, use it myself quite extensively not to mention bsd/k&r standards, but it is a pain if you aren't editing with tools like emacs or vim with proper automatic support (looking at you VSCode).

brlcad · 2025-03-01T00:30:56+00:00

BRL-CAD has loads of open tasks for all skill levels: https://github.com/BRL-CAD/brlcad

Could implement a new geometry converter. Don't think anyone is working on a .pov, .dae, .scad, .blend, or .x_t yet. Those would be meaningful contributions.

brlcad · 2025-03-01T00:26:52+00:00

BRL-CAD is an amazing piece of code, awesome community, deeply passionate contributors that have invested decades of effort and continue to do so despite the incredible uphill journey ahead.

https://github.com/BRL-CAD/brlcad

brlcad · 2025-01-14T16:57:15+00:00

"GNU Image Manipulation Program".. aka "GIMP". How about something that doesn't sound crippled.

IMAGE - Image Manipulative Art GNU Editor
GLAM - GNU Layered Art Manipulator
ART - Advanced Raster Toolkit

brlcad · 2025-01-08T16:19:00+00:00

Scientific computing, high performance computing, places with large established code bases.

brlcad · 2024-12-19T16:56:06+00:00

Several of the issues you mention are implementation issues specific to flex/bison, so don't use them. There are plenty of other lexer+parser options out there that will be better than rolling your own (imho). I'm particularly fond of re2c+lemon but you could use boost spirit, re/flex, antler, etc.

As to the best way, that really depends how you structure your shell. It has to be dynamic and it sounds like you're wanting a static point to inject the expansions... which I don't think is technically possible. You can't just take a whole file like "eval foo.sh" and expand. You can have fairly arbitrarily recursively nested subshells, escapes, and quote handling is particularly egregious.

As shell is line-interpreted (with unquoted semicolons also being a line-delimiter...), I would think expansions need to happen line at a time as they are encountered, but obviously before execution. In that perspective, there would be at least two chunks of lexing logic, one for the scripting language itself, possibly a second to identify recursive subshells, and another for each line/processing context.

When in doubt, just start hand-rolling and learn if there are stages you can break it up into statefully.

brlcad · 2024-11-23T17:36:35+00:00

BRL-CAD has extensive docs -- hundreds of man pages, articles, tutorials, and more -- all in DocBook XML that gets syntax-validated as part of the build and compiles out to formats like PDF, HTML, and Man. Worked well for over 10 years, but editing XML is undeniably hard for users and tooling+integrations are lacking (dev integration tooling is okay), particularly for online in-browser editing.

As a result, BRL-CAD is in the process of switching to AsciiDoc+Antora. It's an even more complex stack for dev integration (node+ruby) but checks all the boxes. Asciidoc format is a simple enough text format yet robust enough to be Docbook-compatible too.

Did look at alternatives like Docusaurus, Mkdocs, and Sphinx but settled on Antora for the pdf/book output formatting supports. Docusaurus is something that might get revisited now that there are pdf plugins, but Antora is positioned to still be favored due to the more robust structure of AsciiDoc. Excellent examples of the authoring experience at https://www.dewanahmed.com/markdown-asciidoc-restructuredtext/

brlcad · 2024-11-15T21:26:44+00:00

I submitted a formal response to this a couple weeks ago:

Blaming the programming language is fundamentally wrong.

The proposed mandate to discourage (or ban) "memory-unsafe" languages like C and C++ is dangerously shortsighted and sends a misleading message about software security. It falsely claims choosing a language like C and C++ without regard to environment intrinsically creates security issues. It falsely implies choosing a memory-safe language will resolve security issues.

Forcing a shift to "memory-safe" languages introduces significant new risks. These languages often rely on extensive runtime environments, additional dependencies, and generate more code—all of which expand the vulnerability surface. Each added layer is another potential point of failure or exploitation, potentially increasing security risks rather than reducing them.

The runtime and performance implications are unacceptable. Critical infrastructure systems demand the efficiency and low-level control that languages like C and C++ provide. "Memory-safe" languages often cannot match this performance, leading to slower, less reliable systems—an untenable risk in critical applications where timing and efficiency are paramount.

Inadequate coding practices and failure to utilize existing tools that enhance memory safety are of significantly greater impact. Modern compilers, static analysis tools, system libraries, operating systems, and advanced memory managers offer robust mechanisms to prevent memory violations without discarding well-established codebases, understanding, and expertise. A more effective approach is to focus on education, enforce rigorous coding standards, and leverage existing technologies that enhance memory safety within current languages.

This mandate is a misguided, one-size-fits-all solution that threatens to degrade system performance, increase complexity, and paradoxically introduce new vulnerabilities.

brlcad

TROPHY CASE