-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request to add pointer to sdf
project
#51
Comments
@soypat I think you'll be more likely to get a pointer in the sdfx README if you reword the sdf README a bit first and then send @deadsy a PR. If you want to do this, I'd refactor the parts around the words "questionable" and "needlessly". Here's why those jumped out at me:
I'm glad to see you in particular tackling open source solid modeling -- it's been sorely needed to make better progress in space transportation, and I'm especially interested because you're apparently into both GN&C and structures and are working in a modern language; humanity needs more of that. (My own background includes NASA supercomputing and the USAF. I run a shop making stuff for everyone from suborbital to superheavy, and once incubated a newspace startup that's still flying 15 years later. Can't complain.) Support for advanced modeling and advanced manufacturing of aerospace systems was the context behind #24, #26, #27, and #50. When you get to the point of code generation to rapidly evolve structure, engine, flight dynamics, and manufacturability together, it helps to have error returns instead of panics in order to more cleanly inform your genetic algorithm's fitness function. I'm trying to figure out whether there is any mind-meld that can come out of your work on sdf and Jason's work on sdfx. The whole point of open source is this sort of evolvability, and because it's all just Go I think we'll be able to avoid https://xkcd.com/927/ to some extent, though I can see how APIs are going to matter sooner or later. I'll keep thinking. |
@stevegt While I agree with your points I've actually been pleading with deadsy to simplify the The performance gain was just a nice bonus, I really wasn't counting on it when I set out to simplify the codebase. Reading over the aforementioned issue I still feel Jason was dismissive about my concerns on simplicity and better API and more worried about whether the existing implementation could reach the same performance given it was changed. I maybe took it a little too personal and let it show on the README, it will be changed. It's great to meet a another engineering oriented soul on here meddling in the same area. After the software I've seen in the aerospace industry I can wholeheartedly agree it is in dire need of a modern language. I hope to someday have a pure-go pipeline to do what you describe- so far I've got all the individual pieces in early state
Guess I'll have it ready by the end of this life sometime, I hope heh. As for the mind-meld: yes please. I really don't like the idea of splitting the community. It'd be great if we could talk and consider eachother's point of view. I was in the wrong thinking no one had use for errors today. It'd be great if Jason heard me out on some of my concerns too on the way sdfx was headed. Some wise engineer once said
To which his yet wiser friend replied
|
Hey! I've made a library based on
sdfx
and was wondering if it could be added tosdfx
's readme to inform users of options when it comes to CAD with Go.The text was updated successfully, but these errors were encountered: