There is a tentative plan to change this to a `.kicad_pro` file in v6, but
it hasn't been completely thought through yet. See
https://gitlab.com/kicad/code/kicad/-/issues/2169#note_286814996.
-Ian
On Thu, May 7, 2020 at 5:05 PM RigoLigo RLC wrote:
> Hello everyone,
>
> The .pro project file
Is it still subject to the round-off errors (
https://gitlab.com/kicad/code/kicad/-/issues/4139)?
-Ian
On Sun, Apr 26, 2020 at 4:30 PM Jeff Young wrote:
> New bits up here: https://gitlab.com/kicad/code/kicad/-/merge_requests/193
>
> I claim this fixes the rotation problems and should markedly
ter, or is there some way to do a merge request from
> jeff/kicad:jeffDRC to kicad/code/kicad:master?
>
> On 26 Apr 2020, at 14:50, Ian McInerney wrote:
>
> Jeff,
>
> From the main repository page, simply click on "Fork" at the top of the
> page. Then you create it i
Jeff,
>From the main repository page, simply click on "Fork" at the top of the
page. Then you create it inside your Personal namespace. Once you do that,
the fork can just become a new remote in your git repository.
Google is running a program later this year called "Season of Docs" where
they partner technical writers with open source projects to update/expand
the project's documentation. Information here:
https://developers.google.com/season-of-docs.
It could be a good opportunity to get some help with the
We should try to limit our use of globals/statics in the code from now on.
We have definitely had quite a few bugs related to their use in the past.
-Ian
On Sun, Apr 5, 2020 at 4:20 PM Jeff Young wrote:
> I had to remove some globals from Eeschema that were causing problems
> (default line
On Sun, Apr 5, 2020 at 12:05 PM Carsten Schoenert
wrote:
> Am 05.04.20 um 11:25 schrieb jp charras:
> > I just removed the I18N mark of strings used in debug messages.
>
> Thanks, seems you have missed some of them?
>
> > pcbnew/altium2kicadpcb_plugin/altium_parser.cpp:THROW_IO_ERROR(
>
I think you meant to link
https://docs.kicad-pcb.org/doxygen/md_Documentation_development_ui-policy.html#quoting
-Ian
On Sun, Apr 5, 2020 at 1:32 PM Wayne Stambaugh wrote:
> The UI policy[1] requires single quotes. I think we did this because
> it's less typing than double quotes. I'm not
I am able to push to branches on my fork with no problem, so I wonder if
this is because you are trying to push to master. Try creating a new branch
and pushing that to your personal fork.
-Ian
On Sat, Mar 28, 2020 at 7:11 PM Mário Luzeiro wrote:
> Hi all,
> It worked all the time, now I
I don't think anyone would object if you want to tag it on the issues, but
it won't be part of the required steps for marking an issue as a duplicate.
-Ian
On Fri, Mar 20, 2020 at 12:14 PM Eeli Kaikkonen
wrote:
> On Fri, Mar 20, 2020 at 1:07 PM Ian McInerney
> wrote:
>
>>
There already is a label `status::duplicate` that can be used if someone
wants to (I occasionally use that on more critical issues as well as
marking as a duplicate so it is obvious to me in the issues list that
something is duplicated). It is just not required to be used.
-Ian
On Fri, Mar 20,
IMO, it would also be good to incorporate the project-local settings into
the template project system as well. That would allow for either generating
from the defaults if no settings files exist or using existing settings
files. (That way template projects can define their own settings - such as
So, first of all it seems like you have now switched to the master branch,
since that stack trace would be impossible to get on 5.1.5. I would suggest
opening a new issue with that stack trace and the exact steps that led to
it, since it is unrelated to the patch buffer issue.
-Ian
On Wed, 4 Mar
I think we should leave them in our Nightly builds. We don't seem to get
too many issues reported with them, and they usually indicate something is
wrong if they do trigger.
-Ian
On Wed, 26 Feb 2020, 11:10 Jeff Young, wrote:
> I’d be inclined to leave them on for nightlies.
>
> That being
Does anyone know which in-tree patches inside the patches/ folder are
actually still needed for building on any of our supported platforms for
master? Looking through the packaging scripts I only see
wxwidgets-3.0.2_mingw_fix_unicode_entry.patch in use for the Windows build
and the OSX build is
> 1) "Save" is not activated in the toolbar. It's activated in the File
menu. But when I click on the canvas, the button is activated.
This is going to be due to how the toolbar and menu states are updated. The
menus are CONDITIONAL_MENUS which rebuild whenever they are opened, but the
toolbars
Wayne,
According to an earlier email thread [1], the 10.14 packages should work on
10.15. There is just an issue with our naming of them not including
10.15,and the website not saying it.
[1]
https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg37489.html
On Thu, 13 Feb 2020,
Sylwester,
Would it be possible for you to submit these are two merge requests to the
KiCad GitLab repository: https://gitlab.com/kicad/code/kicad/-/tree/master.
We have started to use the merge requests to better track and review the
patches that are submitted.
Thanks,
-Ian
On Mon, Feb 10,
That looks like it is an internal error to wxPhoenix. Was wxPhoenix rebuilt
once Python 3.8 was pushed to Rawhide? It could be that there is a version
mismatch there.
I was going to try a VM install of Rawhide tonight and see if wxPhoenix can
be imported into a normal python console (my hunch is
Cihan,
I have been prototyping a CI environment in my fork here:
https://gitlab.com/imcinerney/kicad/-/tree/im/ci. The times you reported
aren't actually that bad, we just need to run with a timeout of 3 hours (a
full rebuild takes ~2 hours in my tests and a partial build can be as fast
as 45
It should automatically close them when you do that.
-Ian
On Mon, Feb 3, 2020 at 3:29 PM Jeff Young wrote:
> I just used:
>
>/duplicate #2402
>
> to mark a bug as a duplicate. Cool.
>
> But it didn’t close it. Do we want duplicates closed, or was that just
> how Launchpad did it?
>
>
Adam (et al.),
If you didn't have to package the single top executable (e.g. eeschema,
pcbnew) would this allow you to remove the symlinks? We have been
discussing adding command line flags to the main kicad executable to launch
the various frames as standalone (e.g. `kicad --eeschema` would
, 2020 at 8:50 PM Nick Østergaard wrote:
> Yes, I already pushed a test script on some branche but we need to push it
> to the docler registey.
>
> lør. 25. jan. 2020 21.13 skrev Ian McInerney :
>
>> Forgive my ignorance here, since I don't know how the scripts to generat
gt;
> fre. 24. jan. 2020 19.36 skrev Ian McInerney :
>
>> It looks like the dev docs aren't updating again. The current page says
>> it was generated on Dec 19, and definitely doesn't include the update to
>> the commit message policy that was made last month.
>>
>&g
, I will check it.
>
> On Thu, 19 Dec 2019 at 01:42, Ian McInerney
> wrote:
> >
> > It appears that the Doxygen for the developer documentation (
> https://docs.kicad-pcb.org/doxygen/index.html) is not updating the site,
> and the last update looks t
They look fine, no contamination with build files. Are you doing an in-tree
build (running cmake at the root of the repository)?
-Ian
On Tue, Jan 21, 2020 at 9:33 AM Jeff Young wrote:
> FWIW, my Git tried to add the two files again (I guess from its local
> history). I think I caught it in
The GitHub mirror will also need to be force pushed for its first update,
since it looks like it got the first of the large files already mirrored to
it and it was choking on the second of the files.
-Ian
On Mon, Jan 20, 2020 at 10:25 PM Simon Richter
wrote:
> Hi Wayne,
>
> On 20.01.20 21:25,
On Fri, Jan 17, 2020 at 4:46 PM Nick Østergaard wrote:
> On Fri, 17 Jan 2020 at 17:18, Ian McInerney
> wrote:
> >
> > There are 2 main issues I can see with rebasing:
> > 1) Rebuilding the history will change the commit hashes on master, which
> will throw off o
There are 2 main issues I can see with rebasing:
1) Rebuilding the history will change the commit hashes on master, which
will throw off our 5.1 cherry-picked commit messages that refer to the
master commit they came from (there are at least 4 that this would happen
to).
2) The GitLab merge
After the discussion on the list after the update to Boost 1.59, I have
drafted an updated support statement for the 3 supported Linux
distributions we have: https://github.com/KiCad/kicad-website/pull/470. I
would like feedback on this policy (either here or on GitHub).
Basically, Fedora and
Marco,
Delete every file inside include/ that ends with "_lexer.h" (note, don't
delete the dsnlexer.h file though). There was a change to the build a few
months ago that moved these generated files somewhere else, and so right
now your build is using the old ones instead of the new ones.
-Ian
ctise in this instance (given it’s a macro being
> >> called, and the macro could easily expand to something which causes
> >> issues in the Kicad codebase, but nowhere else).
> >>
> >> - Bevan
> >>
> >> *From:* Kicad-developers
h Seth’s option, then it’s just going to happen
> again….
>
> On 11 Jan 2020, at 23:28, Wayne Stambaugh wrote:
>
> I agree that adding the curly brackets would be the best option as well.
> It's less than ideal but it resolves the issue.
>
> On 1/11/20 6:21 PM, Ian McInerney wrot
That is probably the best option, since many things in wxWidgets are
implemented as macros but masquerade as functions.
-Ian
On Sat, Jan 11, 2020 at 10:07 PM wrote:
> I suppose that we could update our coding policy to require braces even
> for single line statements.
>
> -Seth
>
> On Jan 11,
In this case we should just need to clarify the scope (which I just pushed
a fix doing). In general... I am not as sure about.
-Ian
On Sat, Jan 11, 2020 at 9:28 PM Jeff Young wrote:
> This looks safe enough:
>
> if( n_changed )
> wxLogTrace( "CN", "Cluster %p : net : %d %s\n",
JP, is that mingw32 directly, or was it provided by mingw-w64 indirectly?
It appears that mingw32 (the original compiler version) doesn't have the
compatibility enabled but the forked version mingw-w64 does. (there was
discussion about this on the mingw users mailing list:
Is __USE_MINGW_ANSI_STDIO actually defined in the wxWidgets builds we use?
A quick search through their codebase for that symbol only shows them
testing for it and never actually defining it.
-Ian
On Fri, Jan 3, 2020 at 1:20 AM Jon Evans wrote:
> Hi all,
>
> Context:
>
in
master.
The main reason I am digging into this is to mark the DLIST class as
deprecated using the wxDEPRECATED_MSG macro (in response to
https://gitlab.com/kicad/code/kicad/issues/2623#note_258333603).
-Ian
On Sat, Dec 28, 2019 at 2:30 PM Ian McInerney
wrote:
> The commit that did it is this
la/show_bug.cgi?id=65974
>
> So it would spew out a tremendous amount of unrelated warnings and was
> useless. Maybe it was added because of that? Now, I don't think we
> should use that globally.
>
> On Sat, 28 Dec 2019 at 15:09, Ian McInerney
> wrote:
> >
> >
Is there a reason we disable warnings on deprecated declarations in debug
mode? Other than a lot of warnings about OpenGL being deprecated on MacOS
(gee, thanks Apple) that we can turn off pretty easily, I see no reason we
should be forcing this in our CMakeLists. I tried tracing this back through
Is there a planned outage at CERN for the webhosting DNS? I am trying to
get to the kicad-pcb.org site and it is throwing a DNS error (unable to
locate the IP for the site), and nslookup also can't find it.
-Ian
___
Mailing list:
version. You need that
> for the new multi-line text editor.
>
> Cheers,
> Jeff.
>
> On 22 Dec 2019, at 01:22, Ian McInerney wrote:
>
> Jeff,
>
> I was actually referring to the wxWidgets compilation configure commands
> not the KiCad configure commands.
kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages
>
> That’s with CLion, but it should be the same elsewhere.
>
> Cheers,
> Jeff.
>
>
> On 22 Dec 2019, at 00:11, Ian McInerney wrote:
>
> Jeff,
>
> What configure flags are you using with our fork of wxWid
Jeff,
What configure flags are you using with our fork of wxWidgets? When I use
the flags we list in the developer docs I hit the error you added about
wxUSE_UNICODE_UTF8 being defined. Completely removing Unicode support also
breaks KiCad builds (since that typdefs wxChar into char, and we get
It appears that the Doxygen for the developer documentation (
https://docs.kicad-pcb.org/doxygen/index.html) is not updating the site,
and the last update looks to be November 17.
-Ian
___
Mailing list: https://launchpad.net/~kicad-developers
Post to
Is the version string supposed to be able to be overridden on the CMake
command line (e.g. specifying -DKICAD_VERSION="blah")? It appears that the
version string defined by CMake is always taking priority (then the git
string is used afterwards if it exists), so this flag is being overwritten.
I
Already fixed by JP in
https://gitlab.com/kicad/code/kicad/commit/52db6acb8685068dc18688f2ef8c88aeea14fa5d
-Ian
On Fri, Dec 6, 2019 at 10:28 AM Simon Richter
wrote:
> ---
> common/gestfich.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
The weight field is the value that Launchpad displayed for the "flame"
icon. I am not sure if normal users are able to modify that field though,
so we are currently thinking of using the thumbs-up to say that people
support the issue/that it affects them.
-Ian
On Thu, Dec 5, 2019 at 10:22 AM
That was when we were first trying to figure out how to do the formatting
checks in the CI environment. It should be fixed in the current CI script
in master.
-Ian
On Thu, Dec 5, 2019 at 10:41 AM Franck Jullien
wrote:
> Hi,
>
> I'm exploring GitLab.
>
> Here you can see a job marked "passed"
The plan that has been proposed here:
https://gitlab.com/kicad/code/kicad/wikis/Developers/Guidelines/Issue-Tracker
is
that bugs in fix-committed, fix-released, fixed and duplicate will be in
the closed status. I had added the fix-committed/fix-released to our GitLab
tags so we can still keep
Adam/all,
Is the 10.14 installer also to be used for 10.15? Right now there is no
mention on the website about the 10.15 support (and actually says only
10.12-10.14 are supported).
-Ian
___
Mailing list: https://launchpad.net/~kicad-developers
Post to
y you wanted the hyphen, but I didn't really follow the
> discussion to much in this thread. What are the other multiword tags in
> gitlab?
>
> On Wed, 27 Nov 2019 at 12:13, Ian McInerney wrote:
>
>> I was trying to avoid creating long tags, and since our current tags seem
>> to be
ayne Stambaugh
>> wrote:
>> >> >
>> >> > I downloaded and installed 5.1.5 on my windows box and it looked like
>> >> > these worksheets were in the template folder. I didn't check the
>> entire
>> >> > list so maybe I got it wrong.
>&
Jeff,
I believe this change is related to the out of memory error in Eeschema
that JP reported after the CJK fonts were added (see list messages:
https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg36655.html
)
-Ian
On Tue, 3 Dec 2019, 00:29 Jeff Young, wrote:
> Hi Seth,
>
>
Sylwester,
Please bear with us for a little, since the move to GitLab has been at the
foreground for the last few weeks the lead developers haven't had time to
sit down and review patches as often. Once we have completed the migration
to GitLab for the code repository, you can submit this as a
Issues must live in a project, so the issues for the KiCad code must go in
the Kicad/code/kicad list. The other lists (KiCad and KiCad/code) just show
all issues for all the projects underneath that folder.
-Ian
On Sun, Dec 1, 2019 at 8:51 PM Jeff Young wrote:
> Kicad, Kicad/code or
to find any information on the suggested size (other than that Fedora
recommends they are 16:9).
Thanks,
-Ian
On Fri, Nov 29, 2019 at 5:39 AM Carsten Schoenert
wrote:
> Hello Ian,
>
> On 28.11.19 17:53, Ian McInerney wrote:
> > I would like to change the way we generate the ki
Linux Packagers,
I would like to change the way we generate the kicad.appdata.xml file to
have it be generated by CMake and include the version string inside of it
(that way the version will appear in the app stores and other places that
reference this). I don't think this will cause any issues,
They appear to be packaged in the update to Fedora, but I don't have a
Windows install handy to test on to verify what I see there:
/usr/share/kicad/demos/interf_u/pagelayout_logo.kicad_wks
/usr/share/kicad/template/A2_ISO5457-1999_ISO7200-2004-compact_ASMEY1435-2014_EN.kicad_wks
Technically Windows 10 has a 32-bit edition, and we specify we support all
of Windows 10. How long Microsoft keeps up a 32-bit release is anyone's
guess though. So we can't really cut out 32-bit releases yet (and I think
even JP still has a 32-bit machine he uses).
-Ian
On Wed, Nov 27, 2019 at
int is often abbreviated as fp, but symbol is
> rarely abbreviated.
>
> On 26 Nov 2019, at 20:45, Ian McInerney wrote:
>
> I do like fp-editor and sym-editor better. Note that for consistency with
> the other multiword tags for GitLab, I will use a hyphen.
>
> -Ian
>
> On
Mitja,
Thanks for expressing interest, and I would just like to say that you do
not have to be a C++ developer to contribute to KiCad. There is a healthy
Python presence in both the core codebase (the footprint generators and BoM
scripts) as well as the library management systems
editor).
>
> Mixing the two would be particularly obscure.
>
> Cheers,
> Jeff.
>
> > On 26 Nov 2019, at 19:40, Wayne Stambaugh wrote:
> >
> >
> >
> > On 11/26/19 2:20 PM, Ian McInerney wrote:
> >> I would like to introduce two new official tags
I would like to introduce two new official tags on the bug tracker to track
issues relating to the symbol and footprint editors. Currently we are
tracking these under the eeschema and pcbnew tags respectively, but those
are growing quite large (pcbnew has over 500). I think tracking these two
We should not limit the end points available to users to be only the KiCad
systems we decide, and also should not constrain plugins to be open source.
Doing this would constrain independent companies from developing plugins to
interface KiCad with their systems if they so choose (for instance, if
We have not officially migrated to GitLab yet, until we announce otherwise
the current platforms (Launchpad for bug reports/code, GitHub for
libraries/docs/translations) should be used. An announcement about the
transition will be made before it happens.
-Ian
On Tue, Nov 26, 2019 at 8:14 AM
I think it is still missing the OCC/OCE package as well:
https://github.com/microsoft/vcpkg/issues/4968
-Ian
On Sun, 24 Nov 2019, 22:17 Wayne Stambaugh, wrote:
> Hey Jon,
>
> I was playing around with vcpkg a couple of weeks ago and it's works
> surprisingly well. There is finally a sane way
What is the current consensus on using OPT types in the code? I know there
are some instances where we are already using them from the Boost library
(since our C++ version isn't high enough to include them), but is that
considered a good type to use more of?
I am curious, because I am thinking of
I think it would be good to define a new S-expression config file that can
be used to store the plot configurations of the simulator. This file should
just contain the plot information, such as lines displayed, their
style/color, axis configurations, colors, etc. (and maybe analysis
parameters, I
This is probably introducing major feature creep, but it would be nice to
develop a dialog that allows setting the per-trace characteristics (such as
color, line type, line width, etc) that this could go in. Where we put the
accessors to it, I am not sure (it would be great if we could link it
an action
on it, and then cancel the action (e.g. because a dialog appeared warning
you of some condition), it is frustrating that the selection is cancelled.
Regards
Ruth
On 20/11/2019 14:28, Ian McInerney wrote:
I'm on the fence about the text highlighting, on the one hand not doing it
does make
, 2019 at 3:16 PM Jeff Young wrote:
> I switch between 5.1 and master and back in the same tree. You have to
> run the clean each time you go from 5.1 to master.
>
> On 20 Nov 2019, at 14:34, Ian McInerney wrote:
>
> Thats correct, all those lexer files should now be in t
en include/ and
> build/common/.
>
> This is a fresh clone, I'm not sure how these files ended up in
> include/. I see that the files are not in the git file tree of either
> 5.1 or master branch. Maybe it happened when I built using
> kicad-mac-builder pointing it to my kicad sourc
I'm on the fence about the text highlighting, on the one hand not doing it
does make it so the text is still easily legible when selected, but on the
other it can be nice to show that it is part of the selected symbol. I
think this would definitely be a case where making it a configurable option
Jonatan,
The pcb_lexer.h in include/ shouldn't exist anymore. There was a switchover
a few months ago in how that file was generated, and that change moved it
into the build directory. As a consequence of that switchover, you need to
clean out the stray files that existed from old build.
Try
It has been cherry picked into the 5.1 branch, so it will be included in
5.1.6.
-Ian
On Mon, Nov 18, 2019 at 9:07 PM Steven A. Falco
wrote:
> On 11/16/19 1:14 PM, Seth Hillbrand wrote:
> > On 2019-11-16 08:42, Steven A. Falco wrote:
> >> It looks like Fedora may be switching from OCE to OCC,
/delete events into a rename event, which is not the case on
> my build.
>
> Best regards,
> Mikołaj Wielgus
>
>
> On Sat, Nov 16, 2019 at 5:21 PM Ian McInerney
> wrote:
>
>> Thanks for testing. I had noticed the selection issue on GTK as well, so
>> I will f
).
>
> Cheers,
> Jeff.
>
>
> On 16 Nov 2019, at 01:57, Ian McInerney wrote:
>
> Ok, so I dug into this some more and first of all, the changes that Jeff
> pushed still didn't work on GTK.
>
> The root cause of this doesn't appear to be our file system watcher, but
>
t; Best regards,
> Mikołaj Wielgus
>
>
> On Sat, Nov 16, 2019 at 1:02 AM Jeff Young wrote:
>
>> I pushed a smarter version of my original fix. @Mikolaj & @Ian if you
>> could test it on Windows and GTK that would be great.
>>
>> Cheers,
>> Jeff.
>>
I'm on Windows (the details are in the linked related bug report).
>
> Sorry for the return value problem -- I failed to notice the warnings in
> console.
>
> Best regards,
> Mikołaj Wielgus
>
>
> On Fri, Nov 15, 2019 at 11:07 PM Ian McInerney
> wrote:
>
>> I'l
I'll give it a test on GTK once my build here finishes, but I don't think I
have seen any issues with file watcher on GTK in the past.
-Ian
On Fri, Nov 15, 2019 at 10:03 PM Jeff Young wrote:
> Hi Mikolaj,
>
> The Mac compiler doesn’t like Rename() returning values when the return
> type is
I believe the US sizes are provided by the ASME Y14.1-2005 standard. Or at
least that seems to be the generic standard for these that I can find (I
didn't see anything for ANSI or IEEE).
-Ian
On Wed, Nov 13, 2019 at 6:37 PM Evan Shultz wrote:
> Thanks Seth!
>
> I didn't find the default
t keep the old
> 8-color palette?
>
> /Jonatan
>
> 11 nov. 2019 kl. 18:35 skrev Ian McInerney :
>
>
> Jonatan,
>
> Thank you for putting this together. Overall I think it looks good, but
> the only issue I saw was that the SIM_PLOT_FRAME::generateColor() function
I think it makes sense to transfer the reports that are fix committed but
not fix released. That way we can have the entire v6 history attached to
the new milestone and more easily reference those reports in the future.
Any that are fix released we can leave on Launchpad.
-Ian
On Tue, Nov 12,
I agree, we should only be transferring and renaming the non-generated
files rather than trying to account for every possible file under the sun.
If the user wants the generated files, they can regenerate them from the
new project.
-Ian
On Mon, 11 Nov 2019, 20:30 Jon Evans, wrote:
> In my
Jonatan,
Thank you for putting this together. Overall I think it looks good, but the
only issue I saw was that the SIM_PLOT_FRAME::generateColor() function
seems to be becoming a graveyard for old colors with 4 old attempts at
creating color profiles now commented out. I have merged it into
Thanks for this. Note though that when passing the functions into the
Connect method in wxWidgets, you should specify the fully qualified name
(including the class) of the function. When this is not specified, a build
error happens on my wxWidgets 3.0.4 Linux build. I have pushed a fix for
this to
Simon,
While Python 2 may be deprecated, I don't think we can change the defaults
for master yet. The main issue is the packaging of Windows and Mac still
requires Python 2 (based on the discussion in [1]) because the Python 3
packages are not validated/existing yet. Until we have Windows and OSX
JP,
Are you running this on your 3.0 or 3.1 build of wxwidgets? That looks like
there is an issue with their autosize calculation not factoring in the
width of the sorting bitmap.
-Ian
On Thu, 7 Nov 2019, 14:37 jp charras, wrote:
> Le 06/11/2019 à 23:18, Mikołaj Wielgus a écrit :
> > Hello,
>
Simon,
Continue to use Launchpad for the time being. I don't believe we have
officially created the KiCad repository yet, so all that is being done
currently is testing leading up to the migration.
-Ian
On Sun, Nov 10, 2019 at 7:10 PM Simon Richter
wrote:
> Hi,
>
> On Sun, Nov 10, 2019 at
:27 PM Tomasz Wlostowski
wrote:
> On 07/11/2019 21:14, Wayne Stambaugh wrote:
> > I am happy to announce that the KiCad project now has a new member of
> > the lead development team. Ian McInerney has accepted an invitation to
> > become a member of the lead development team.
I would guess that is a mistake. It seems that the intention is to
eventually have both linear and log scaling, so they would need to be
different. Right now though it looks like log scaling isn't handled
differently (a search for SPT_LOG_FREQUENCY returns a TODO comment and an
if check that is
I thought that was part of the connectivity stuff that Jon was working on
(it certainly wasn't me, and I don't know if there is another Ian
contributing code right now). I remember seeing some email threads on
real-time updates to the information in Eeschema.
The wishlist item that Wayne
We should also be thinking of when we want to officially drop the Python 2
support for KiCad. Since Python 2.7 will be end of life in just a few
months, it might be worth starting the transition over to Python 3 (it
looks like Windows and Mac builds ship with 2.7 currently).
-Ian
On Sat, Oct 26,
paths? Doing this will wipe out
> any compiler flags set by CMake.
>
> On 10/23/2019 11:16 AM, Ian McInerney wrote:
> > It looks like the build flags for KiCad are not getting NDEBUG defined
> > to remove the assertions. We should add -DNDEBUG to the flags passed
> > into
It looks like the build flags for KiCad are not getting NDEBUG defined to
remove the assertions. We should add -DNDEBUG to the flags passed into
CMake alongside the Debian flags.
-Ian
On Wed, Oct 23, 2019 at 6:38 AM Carsten Schoenert
wrote:
> Hello Seth,
>
> Am 22.10.19 um 18:10 schrieb Seth
g list.
>
> Cheers,
>
> Wayne
>
> [1]: https://bugs.launchpad.net/kicad/+bug/1849289
>
> On 10/21/2019 3:11 PM, Ian McInerney wrote:
> > There were two bugs still on the 5.1.5 milestone [1], [2] that related
> > to the editing of H/V/45 constrained polygons. I have bum
n Wed, Oct 23, 2019 at 1:05 AM Seth Hillbrand wrote:
> On 2019-10-22 16:06, Ian McInerney wrote:
>
> I dug into the website history and apparently the original intent should
> have been to support 16.04 LTS until its standard support ends in 2021 (
> https://github.co
ng.
> >
> > Thanks,
> > Diego
> >
> > On Mon, 21 Oct 2019 at 20:16, Ian McInerney > <mailto:ian.s.mciner...@ieee.org>> wrote:
> >
> > The listing I used when looking at whether our supported OS's had
> > Boost 1.59 were the date
We also seem to have assertions enabled in the Debian build (there have
been two reports from users [1], [2]). Is this something we control as
well, or is the the distribution packaging forcing them on?
-Ian
[1] https://bugs.launchpad.net/kicad/+bug/1847554
[2]
101 - 200 of 320 matches
Mail list logo
