Of these bugs I have only run into one while testing the current Github head.
Broken Gerber export <—this one really makes it unusable.
I have contacted everyone involved in that commit via Github as well as their personal emails if available and no-one responded to my inquiry so it seems as if we are on our own to fix it. Unfortunately I am unable to help with any of these issues not being a very proficient coder and not knowing the libraries they use would mean starting from scratch to understand every single line of code.
My idea is to start a bounty to try and get people experienced with clipper and other involved libraries that should in theory be able to fix the problem much quicker than someone that has to learn everything.
The issue I have now run into is which bounty site should I start it on and what size bounty would be appropriate? Also is there anyone else willing to contribute to the bounty and what other issues should we look into having fixed right away so we can get another release?
P.s. If you have interest in fixing things please look through the Github issues and pull requests as some of the issues you want fixed may already have pull requests that fix them but have not been implemented yet.
The bug with the gerber output is where the polygons are not being closed and ends up connecting all the copper in the gerber output. I don’t know if it is when the SVG is imported or when it is run through the new ground fill or during export to Gerber. It was reported months ago and confirmed by others as well as myself so I can only guess it is in the code and not my build environment. Since I know very little about GUI programming and nothing about the clipper library used in the new gerber export I haven’t the faintest idea where to start looking for the underlying problem.
A comment from one of the folks involved with the commit indicated he thought that a “pen up command” was missing somewhere, he continued that he no longer had a development environment up to work on it. So it looks to be a fault in the coding that needs fixing rather than a compile type problem (which is much easier to fix).
It is doubtful. The change was a large scale change of gerber output (probably updating to later versions) and I don’t expect the old looks like the new at all. It needs someone that is familiar with the changes to figure out what needs to be fixed I expect. The change apparently involves 6000+ changes …
The worst part about this particular issue is it would be fairly trivial to reverse the commit but it is the main reason I want a newer Fritzing. The outlines are much cleaner and the copper fill fits around the pads and traces much nicer.
Yes I’d figured that. I think it is likely to be a fairly easy change if we can find someone that knows the changes that could provide a clue of where to look. It would also be a pity to lose that much work.
Not that I know anything about this, but why do we need to know the changes. Isn’t the code commented enough so that you can find the render section - still a big ask for 187MB of code -.
How worse can this get. because they left faulty code and washed their hands of the whole thing allowing it to die.
Unfortunatly documentation (and comments) are boring so while there are exceptions most open source projects are lightly commented (and what I have seen of the Fritzing source is lightly to not at all commented). Once you get used to the flow that isn’t too bad, and having a working program and debug tools helps some, but it still takes a huge effort to figure out how the code works and thus what you need to change. It was reasonably easy to find the cause of the Fritzing hang with a bad part: run it with a bad part under gdb and it comes up with a seg fault. Examine the code at the seg fault and it is easy to see it has returned without a loaded part when Fritzing expects one (the seg fault occurs when Fritzing trys to access the non existent part). The solution is to back out the changes the part has already made (and the code is there to do that somewhere, because it does it when you discard the changes, at least sometimes, when you load a part). I (once I finish the python script) have to trace the code that deletes the part to figure out what I need to do when there is an error on the part load. For someone who is familiar with the code this runs oh they forgot to call routine “delete the part data” and is reasonably simple. For me I have to find out what “delete the part” is really called and what parameters it wants which is a lot harder. The gerber stuff is similar in nature except it apparently calls an external package to do the gerber processing so we need to understand that as well. If we can find a fairly simple part that breaks (and this one may be it, a single pad and a hole is about as easy as it gets) we may be able to trace the code flow and figure out what we need to change. It is just going to be a lot slower and a lot harder than for someone who already knows the code. We will see once I manage to finish up with python (testing with parts in core just turned up yet more bugs) and can devote time to development again (probably delayed by fixing bugs in the python scriipt as I’m sure there are still lots there.) So the situation isn’t entirely hopeless. It will get even better if we can attract more developers as some folks with experience with the code and qt that can help newbies makes development easier and thus more likely to get done (and then we all win)
I feel the best way for new Fritzing developers to move forward regardless of knowing the code would be to roll everything back to the point of 0.9.3b release and then merge each pull request one at a time and test until we find what causes the new issues like the broken gerber. It may be that the new gerber code is fine but one of the other 30 or so pull requests that were merged at the same time are causing the issue. At least at that point you would know what bugs exist and are not fighting new bugs introduced in the commits without much testing.
Like Peter said knowing the code would mean knowing where to look each time something comes up. Years ago I did spent the time to understand two large programs well enough to contribute but it meant spending weeks reading code, experimenting and then implementing changes and even then I didn’t really understand the code just the few parts I wanted to change.
I thought there wasn’t many comments. It’s hard enough with good comments yet alone poor comments. If it’s not 10 lines of Basic I’m never going to work anything out.
Sub’s method sound like a plan.
Still they could have left us with a working code.
I don’t know if it matters but there was 2 off 9.3b’s. A faulty 186.482MB and a corrected 186.786MB on the 29.6.16.
Shouldn’t code / releases / 0.9.3b be the base of the release and the appropriate place to start from to add the commits? Remembering I know almost nothing about actually doing anything except downloading on github. I agree a good place to start would be with only the new gerber changes applied to 0.9.3b.
For Git to keep track of all the changes you need to roll back the commits to the point in time when the release was made. I can not be 100% sure the one I linked to was the correct one that matches the release because I couldn’t find a commit that said Increment version number or similar denoting when they made the release. I just went by the date when 0.9.3b was released in the Github Releases section. I am not entirely comfortable with Git as I can never remember the command line arguments and the GUIs for Linux are terrible. I believe Github has a windows program that makes it really easy.
I just managed to build (and run) the Fritzing-App from source. But I cannot reproduce the error. I tried e.g. an empty pcb with a jumper and a ground-fill, but that looked fine. Can you tell me how to reproduce it, or can someone post a sketch with the error?
Also, do you know where I can find a documentation how the Gerber files look like?
What I mean is that if I look at the gerber files with my version of gerbview (from KiCad version 4.0.2) then the files look fine. But also the example from the github issue (copy&pasted into a text editor) looks fine. Which online viewer can you recommend?
And: it looks like the files are missing the “G37*” commands to end the region statements.
as I’m sure there are still lots there.) So the situation isn’t entirely hopeless. It will get even better if we can attract more developers as some folks with experience with the code and qt that can help newbies makes development easier and thus more likely to get done (and then we all win)