Skip to content
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

Tag 1.0 and move towards a 1.1 release #6

Open
maxsu opened this issue Oct 12, 2019 · 1 comment
Open

Tag 1.0 and move towards a 1.1 release #6

maxsu opened this issue Oct 12, 2019 · 1 comment

Comments

@maxsu
Copy link

maxsu commented Oct 12, 2019

1.0 Tag

Hi doc, really love the idea of impala, and might like to make additions (like the Make Set component someone else mentioned). I'd like to review the code in context of the Aug 30, 2019 release. Can you tag the commit that accurately represents the code as seen in 1.0?

1.1 Release

Once we have a 1.0 tag I'd like to review the improvements made since then, and look at issues that might make it into a 1.1 release. Would you mind starting a 1.1 tag or project, and earmarking some the issues you think would be good for 1.1?

Thanks for your work!

@dcascaval
Copy link
Owner

I've created a tag and a branch of the 1.0 release version - Let me know if you have questions about it! Only a couple improvements have been made since then, almost all infrastructural:

  • Improved method generation. Impala relies heavily on the generated methods to provide the actual 'parallelism' - more detail can be found on the wiki. I rewrote the method generator to be a lot cleaner in F#, though providing identical functionality.

  • Experimenting with reimplementing GH_Component and GH_Structure. Current profiling indicates that a lot of the overhead present in Impala operations right now is due to representations - structure maintain sorted lists and dictionaries, and everything has to be boxed and unboxed. Since the parallel functions loop over data in a very structured way, in most cases it should be possible to pre-compute the result size and take advantage of preallocating result structures (particularly, between components). Should this pan out, it's definitely worth a major version bump, as none of the components will have the same GUIDs.

  • Added a RemoveDuplicateLines component. It's not quite perfect, but I think it's worth including in a future release, perhaps with extra tweaks. This is a good candidate for going in a 1.1 release. I've created a candidate branch here that includes it.

All that being said - I think for a 1.1 release, a good aim is to extend functionality in terms of components. This can include Make Set for various types, and maybe a few more math ops (comparisons, etc.) The wiki documents all of the existing components. Are there other points functionality you think would be good to have? I'd also like components that work with BReps, but this has proven problematic - kept hitting race conditions in the RhinoCommon native code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants