Jon Despite MSVC Community being from MS, I see some advantages in using it, namely that it is basically a one-package solution: no msys2, no loads of other tools that have to be updated, etc.. My lack of cmake-foo meant I hit a roadblock when trying to build an MSVC recipe. One time I got so far
Hi All-
This is a friendly request for you (yes, you!) to create a user account
at GitLab. This can either be signing in with your existing GitHub
account over OAuth or creating a new account with the same e-mail as
your public GitHub email address.
We're not moving over to GitLab yet, but
I have not tried to get those working yet, I have them disabled by flags.
I can try to see what was involved in adding new packages.
-Jon
On Sun, Nov 24, 2019 at 5:17 PM Wayne Stambaugh
wrote:
> Hey Jon,
>
> I was playing around with vcpkg a couple of weeks ago and it's works
> surprisingly
Once all of the dependencies for vcpkg are in place, I could see
actually using VS for development (I can't beleive I'm actually typing
this) on windows. Who knew?
On 11/24/19 5:23 PM, Ian McInerney wrote:
> I think it is still missing the OCC/OCE package as well:
>
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
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 to build dependencies
and compile and link against them on windows. The dependencies I could
not find in vcpkg are ngspice and wxPhoenix/wxWidgets which means that
we
On 24/11/2019 18:20, Seth Hillbrand wrote:
>
> I generally like both of these. But part of that is because my IDE (VS
> Code and sometimes Eclipse) shows me the underlying type(...)
I second Seth. Also use VScode, great editor ;-)
T.
___
Mailing
On 2019-11-24 13:13, Mark Roszko wrote:
Can the use of 2FA be mandated across the entire group since we have a
fresh start?
It's been killing me that it's not required for GitHub and it really is
a vulnerability to not enforce. KiCad is a decent value target for
malicious code placement
Can the use of 2FA be mandated across the entire group since we have a
fresh start?
It's been killing me that it's not required for GitHub and it really is a
vulnerability to not enforce. KiCad is a decent value target for malicious
code placement since it is a desktop app.
Hi Devs,
I'd like to bring to your attention following bugs that are marked as
released for milestone KiCad 6.0.0-rc1, something that IMHO is not quite
possible yet. (Note: I'm concerned about status released, not committed):
A good IDE should be able to open up auto and typedef in a tooltip. Clang
library helps here, for example Qt Creator uses it and shows the actual
type when I hover over auto.
Eeli Kaikkonen
su 24. marrask. 2019 klo 19.10 Wayne Stambaugh (stambau...@gmail.com)
kirjoitti:
> On 11/24/19 7:12 AM,
I don't know, but I have https://gitlab.com/kicad_eda that I have been
using as a playground.
søn. 24. nov. 2019 15.42 skrev Seth Hillbrand :
> Hi All-
>
> As you have heard, we are moving from Launchpad to GitLab. However, we
> have been unable to secure the https://www.gitlab.com/kicad group
Hi all,
I got a build working using Visual Studio 2019 and vcpkg.
Attached are three patches I needed to make so far.
I'd appreciate some double-checking on these since cmake and wxwidgets can
be a bit perilous.
Thanks,
-Jon
From 87674cb5a87b4d77683248b65994ef625f8a7c47 Mon Sep 17 00:00:00 2001
Le 24/11/2019 à 18:09, Wayne Stambaugh a écrit :
> On 11/24/19 7:12 AM, Jeff Young wrote:
>> Personally I hate OPT (because it’s somewhat harder to read and
>> more-than-somewhat harder to debug).
>
> I tend to agree with Jeff. The older I get, the less I like having to
> dig around the code
On 2019-11-24 09:09, Wayne Stambaugh wrote:
I also dislike auto, except in the case of stl::’s overly-verbose
iterators. Again, they make the code harder to read more often than
not.
I'm seriously rethinking typedefs as well. I can never seem to
remember
the type they represent so I have
On 11/24/19 7:12 AM, Jeff Young wrote:
> Personally I hate OPT (because it’s somewhat harder to read and
> more-than-somewhat harder to debug).
I tend to agree with Jeff. The older I get, the less I like having to
dig around the code base to figure out what is going on because
templated code
Hi All-
As you have heard, we are moving from Launchpad to GitLab. However, we
have been unable to secure the https://www.gitlab.com/kicad group name
for the project. The name appears to already be taken. However, this
is not a public group or user, so we don't know who controls the name.
Hi Eeli,
no, you are actually right.
I just don't want to make a new dialog before we will be sure that we
definitely need it. But in case that you will propagate not only
references you suppose to have new one.
On Sun, 24 Nov 2019 at 12:27, Eeli Kaikkonen wrote:
>
> I probably don't understand
Personally I hate OPT (because it’s somewhat harder to read and
more-than-somewhat harder to debug).
I also dislike auto, except in the case of stl::’s overly-verbose iterators.
Again, they make the code harder to read more often than not.
Maybe I’m just showing my age….
> On 24 Nov 2019, at
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 probably don't understand everything which has been said, but as far as I
can see there are actually two things going on which could and should be
independent.
1. Doing geographical reannotation in pcb.
2. Propagating changes made in the pcb back to the schematic.
I believe they should be
21 matches
Mail list logo
