Plans for the future

[Argmaster]

I have started this project long time ago and since then my approach to managing Python project changed significantly. Therefore this project IMO needs deep refactor in CI/support tools set. Another thing that should be changed is its monolytical architecture. I think that parser itself should be kept separately (probably will remain in this repo) when 2D and 3D backend should be migrated to two other repos (pygerber_backend_pillow, pygerber_backend_blender). My idea is to make it similar to how modularity is handled in my other project, CSSFinder. As for source, aproach to parsing is a bit too complicated and contains a lot of unexpected behaviors, thanks to heavy use of metaclasses. In general, it is quite likely that in some not so distant future updates to this software will arrive, hopefully bringing support for latest versions of blender and Python. I might need some help with compiling blender as python module on windows and macos for use in this project, as I don't currently have access to machines with those OSes.

[ajw287]

Great to hear what you are planning!

Could I check how complete the gerber parser is in the original project? It looks like there are some things used in KiCAD output (like '%' used for comments) that upset the tokenizer. I'm working from my fork to see if I can get some of them to work.

I'm happy to contribute to some extent, but I'm busy and not a very active coder - so I'm concerned about over promising and the quality of output. I can certainly provide electronics support in terms of example gerber files from a variety of PCB programs, these can be used for CI or demo.

I was wondering if your plan for new versions is likely to break the API as it stands?

I could maybe get involved in the CI aspects as I was impressed with this in pygmo. I can't help with windows as I don't use it either. I think that Circle CI might be able provide a windows instance (looking at pricing, I think its free for up to 6000 hrs).

[Argmaster]

Based on my most recent experience, current API is pretty much garbage, at least from point of organization. Additionally those whole division stuff may require complete rework. I would love to have access to more complex Gerber files which use somehow limited sets of features of this format, as this was major problem during development last time. I pretty much had like 3 more complex examplex and few really small from documentation. I you were to share some of possible Gerber files and open PR with them It would be great. You can pretty much just stuff them into tests/assets for now, we will manage it later.

I need couple of weeks (like 2-3 or so) to submit my bachelor's thesis and then I will be free to work on this project. Until then I will just into how it can be redesigned so it is all more managable.

[Argmaster]

Currently candidate for release 2.0.0 is developed on revolution/2.0.0 branch.

[ajw287]

Hey! Thanks for the info - I hope that the bachelors thesis is going well - concentrate on that till it's done!

Gerber is a bit of a weird standard - I think that different companies did their own thing with it. I would assume that KiCAD is pretty close to the standards but that is an assumption. I've made a pull request for a simple Alitum and KiCAD pcb, both are super simple circuits, but should exercise the renderer.

[Argmaster]

Surely we will make sure to accept - everything what KiCAD and similar software outputs, as it's main use case for this code. I have already encountered cases where by "Gerber" software ment Gerber X2 which has much more verbose syntax, thus it was partially implemented (mainly by tokenize - discard approach).

As for my Bachelor's, I have managed to defend my degree with highest grade, so I will have chance to pay more attention to this project.

[ajw287]

Yes, I think that the original gerber format is pretty well obsolete. Almost everyone uses Gerber X2 (famous last words!).

[ajw287]

Congratulations on your degree!

[Argmaster]

Congratulations on your degree!

Thanks