Yes, I am fine with using it in the copr builds for now. Do we need to submit a PR for the libngspice package to let the packager pick it up more easy? I have not seen any activity from him.
On Tue, 15 Jan 2019 at 20:58, Steven A. Falco <stevenfa...@gmail.com> wrote: > On 1/15/19 9:21 AM, Wayne Stambaugh wrote: > > Hi Steve, > > > > On 1/15/2019 8:51 AM, Steven A. Falco wrote: > >> I'll look at that. The worst burst of backspaces is about 7 characters > long, so I could accumulate 14 chars or so before making a decision. In > other words, run a circular buffer, and when I see the first non-backspace > after a string of backspaces, then process the buffer. > >> > >> But I'm starting to think that the better approach is to drop this > patch from the official tree, and just put my original patch into > Fedora-only, as a temporary patch, to be removed when the library issue is > corrected. > > > > This may be the way to go as this is only temporary until the ng-spice > > library is fixed. I'm assuming this issue is specific to Fedora. If > > not, we can re-evaluate it at the time that it is broken on another > > platform. > > I committed my original patch into the Fedora build system. A new build > will appear in rawhide in a day or two, and it will appear in Fedora 29 > after a week or two, once the karma process runs its course. Thus Fedora > users can start enjoying ngspice soon. I'll keep track of the ngspice > library, and if a fix appears there, then I'll remove my patch. > > I did take a stab at a new, efficient patch which addresses Seth's concern > - but after studying the dynamics of the message passing, I don't think it > really matters. Messages always seem to break on carriage-return > boundaries, so either patch will work without any loss of data. > > I attached the new patch here so it won't get lost. It behaves about the > same as the earlier one, but it does print some extra '%' characters that > are left over after the backspaces are processed. Thus, I actually prefer > the original patch, because it produces slightly cleaner output. > > Nick - Do you want to put either version into the Copr builds? > > Steve > > P.S. - This time, I tried to follow the coding style, as per Wayne's > email. :-) > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp