kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

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 <stevenfalco@xxxxxxxxx> 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. :-)
>
>