[Kicad-developers] Problems with Boost library building Kicad from git sources on Slackware64-current Linux

[TPCkicad]

I managed to do this successfully a few weeks back with boost-1.69.0.  Now 
with boost-1.70.0 it fails.


The relevant parts of my (SlackBuilds based) build script are,

SLKCFLAGS="-O2 -fPIC"
LIBDIRSUFFIX="64"
  cmake \
-DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \
-DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \
-DCMAKE_INSTALL_PREFIX=/usr \
-DLIB_SUFFIX=${LIBDIRSUFFIX} \
-DMAN_INSTALL_DIR=/usr/man \
-DCMAKE_BUILD_TYPE=Release ..
make -j8


I tried a couple of things.

(1) Initially the cmake (as above) stage fails with,

-- Found Boost 1.70.0 at /usr/lib64/cmake/Boost-1.70.0
--   Requested configuration: QUIET REQUIRED COMPONENTS regex
-- Found boost_headers 1.70.0 at /usr/lib64/cmake/boost_headers-1.70.0
-- Found boost_regex 1.70.0 at /usr/lib64/cmake/boost_regex-1.70.0
-- No suitable boost_regex variant has been identified!
--   libboost_regex.so.1.70.0 (shared, BUILD_SHARED_LIBS not ON, set 
Boost_USE_STATIC_LIBS=OFF to override)
CMake Error at /usr/lib64/cmake/Boost-1.70.0/BoostConfig.cmake:95 
(find_package):

  Found package configuration file:

/usr/lib64/cmake/boost_regex-1.70.0/boost_regex-config.cmake

  but it set boost_regex_FOUND to FALSE so package "boost_regex" is
  considered to be NOT FOUND.  Reason given by package:

  No suitable build variant has been found.

Call Stack (most recent call first):
  /usr/lib64/cmake/Boost-1.70.0/BoostConfig.cmake:124 
(boost_find_dependency)

  /usr/share/cmake-3.14/Modules/FindBoost.cmake:266 (find_package)
  CMakeLists.txt:587 (find_package)


-- Configuring incomplete, errors occurred!
See also "/tmp/SBo/kicad-git/build/CMakeFiles/CMakeOutput.log".


(2) After adding '-DBUILD_SHARED_LIBS=ON' to the cmake command line it 
completes but the make process fails at one of the link stages with many 
boost class library related error such as,


/usr/bin/ld: CMakeFiles/qa_sexpr.dir/test_sexpr.cpp.o: in function 
`Sexpr::AsStringInt::test_method()':
test_sexpr.cpp:(.text+0xf9): undefined reference to 
`boost::unit_test::unit_test_log_t::set_checkpoint(boost::unit_test::basic_cstring, unsigned long, boost::unit_test::basic_cstring)'
/usr/bin/ld: test_sexpr.cpp:(.text+0x2f1): undefined reference to 
`boost::unit_test::framework::add_context(boost::unit_test::lazy_ostream 
const&, bool)'
/usr/bin/ld: test_sexpr.cpp:(.text+0x36d): undefined reference to 
`boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result 
const&, boost::unit_test::lazy_ostream const&, 
boost::unit_test::basic_cstring, unsigned long, 
boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned 
long, ...)'

I am using gcc-9.1.0.

Any thoughts?

Thanks
Tom Crane

--
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email:  t.cr...@rhul.ac.uk
Fax:+44 (0) 1784 472794

___
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

Re: [Kicad-developers] Eeschema unit testing

[John Beard]

On 24/04/2019 13:38, John Beard wrote:


I have here a couple of patches that enable unit tests in eeschema's
library code.



this is a proposal to merge the changes attached, at the cost of
another heavy link. However, having a working eeschema test suite will
allow such things as eeschema's netlisting functions to get some
tests, so I think it's a valuable tool.


Does anyone have any better ideas for this? Or objections?

I feel like eeschema is really crying out for some unit tests, as the 
ERC stuff is 1) a highly deterministic and testable module and 2) 
critical for hardware correctness.


Cheers,

John

___
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

Re: [Kicad-developers] IMPORTANT build change for OSX users

[Jeff Young]

OK, so the config statement is in the dev docs, but I’m not sure it should be.  
Now that 4.x is a few versions behind us, I think we should retire all the doc 
about building without kicad-mac-builder.  Does that sound reasonable?

Either way, we need to update the config of kicad-mac-builder.

Cheers,
Jeff.


> On 9 May 2019, at 18:57, Jeff Young  wrote:
> 
> I don’t know whether the configure statement is in them or not.  (I haven’t 
> been able to check because it seems the server is down.)
> 
> New folks won’t need the rest of the instructions as they’ll be building from 
> scratch.
> 
> Cheers,
> Jeff.
> 
> 
>> On 9 May 2019, at 17:28, Michael Kavanagh > > wrote:
>> 
>> Should the build instructions in the developers docs be updated?
>> 
>> Cheers,
>> Michael
>> 
>> On Thu, 9 May 2019 at 00:03, Jeff Young > > wrote:
>> I’ve added a check in the headers that will fail a compile if 
>> wxUSE_UNICODE_UTF8 is set.  This will allow us to remove a bunch of our 
>> mutex hacks.  (It turns out that it’s only on for OSX; the other platforms 
>> already have it off.)
>> 
>> You’ll need to do 3 things in your wxWidgets tree:
>> 
>> 1) git fetch (your origin should be set to g...@github.com 
>> :KiCad/wxWidgets.git and you should be on branch 
>> kicad/macos-wx-3.0)
>> 2) run your configure command without the --enable-UTF8 option [1]
>> 3) make install (in wxWidgets/build)
>> 
>> (You’ll probably need to do a clean and a re-build of Kicad after this.)
>> 
>> Cheers,
>> Jeff.
>> 
>> [1] This is the configure I used:
>> 
>> ../configure \
>> --prefix=`pwd`/../wx-bin \
>> --with-opengl \
>> --enable-aui \
>> --enable-html \
>> --enable-stl \
>> --enable-debug \
>> --enable-debug-gdb \
>> --with-libjpeg=builtin \
>> --with-libpng=builtin \
>> --with-regex=builtin \
>> --with-libtiff=builtin \
>> --with-zlib=builtin \
>> --with-expat=builtin \
>> --without-liblzma \
>> --with-macosx-version-min=10.13 \
>> --enable-universal-binary=x86_64 \
>> CC=clang \
>> CXX=clang++
>> 
>> ___
>> 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 
>> 
> 
> ___
> 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

___
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

Re: [Kicad-developers] Developer doc web page down

[Nick Østergaard]

It should work now, and it may also be a bit more responsive.

On Thu, 9 May 2019 at 16:16, Nick Østergaard  wrote:
>
> I know. I will report back when it works.
>
> tor. 9. maj 2019 16.15 skrev Jon Evans :
>>
>> Still down
>>
>> On Wed, May 8, 2019 at 3:27 PM Wayne Stambaugh  wrote:
>>>
>>> Still no luck :(
>>>
>>> On 5/8/19 10:12 AM, Nick Østergaard wrote:
>>> > Ok, thank you for the notification.
>>> >
>>> > It looks like the publish job jot stuck in a retry loop, I have
>>> > restarted it and it should be back within half an hour I hope.
>>> >
>>> > On Wed, 8 May 2019 at 15:15, Ben Hest  wrote:
>>> >>
>>> >> It's down for me.
>>> >>
>>> >> On Wed, May 8, 2019 at 6:20 AM Wayne Stambaugh  
>>> >> wrote:
>>> >>>
>>> >>> Can anyone else get to the developers doc web page?  I still getting a
>>> >>> 504 Gateway Time-out error since yesterday afternoon.  I am in the
>>> >>> process of finishing up the v6 road map along with some other developer
>>> >>> doc updates and I wanted to see if anything else needed updating.  Any
>>> >>> help would be appreciated.
>>> >>>
>>> >>> Cheers,
>>> >>>
>>> >>> Wayne
>>> >>>
>>> >>> ___
>>> >>> 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
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> -Ben
>>> >> ___
>>> >> 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
>>>
>>> ___
>>> 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

___
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

Re: [Kicad-developers] PATCH: Raytracing - a more pleasing way sequencing blocks to render ?

[Wayne Stambaugh]

Hi Henner,

On 5/1/19 9:44 AM, Henner Zeller wrote:
> On Wed, 1 May 2019 at 06:14, John Beard  wrote:
>>
>> On 01/05/2019 13:57, Mário Luzeiro wrote:
>>> Hi John,
>>>
>>> yeah the Morton code is to improve cache hits.
>>>
>>> Regarding the speed test, since OS are multi-tasking there could be some 
>>> interference on the results so 1s difference is not a very measurable 
>>> difference ( 4% ).
>>> A possibility would be to run the same scene multiple times and make an 
>>> average of the times.
>>
>> Sure, it was just a fun observation. It does change a bit from run to
>> run, but I was at least expecting a small penalty. Next up, wipes[1] and
>> then perhaps Snake :-D
>>
>> A more robust benchmarking harness would probably be the way to go if we
>> really were serious about putting the pedal to the metal here.
>>
>> But I think the centre-first approach is certainly better usability, but
>> I'm unsure about the checkerboard.
> 
> I agree, without checkerboard it makes it quicker to see what is going
> on in the center. Attached the (even simpler) just spiraling out from
> the center patch.

I tested this patch and it works as advertised.  Would you please fix a
few minor coding policy issues (missing spaces after opening and before
closing parentheses) and resubmit it?  There is now a clang-format
(>=3.9) commit hook[1] that allows you to check your code formatting
before you commit.

Thanks,

Wayne

[1]:
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html#tools

> 
>>
>> Cheers,
>>
>> John
>>
>> [1]: https://www.youtube.com/watch?v=cGqAu9gj_F0
>>
>> ___
>> 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



___
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

Re: [Kicad-developers] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

[Piotr Esden-Tempski]

Hi,

Just a thought. This feature could also be very useful to import/export of FPGA 
physical constrain files (PCF). This would allow us to keep the pin naming in 
sync between the schematic and HDL. Maybe even simplify pin swapping?

Cheers,
Piotr

> On May 9, 2019, at 7:55 AM, Johannes Wågen  wrote:
> 
> Hi
> 
> The open source FPGA tools also have this.  It might be worth to take a look 
> at[1]. It is written in JavaScript, but it does perhaps give some indication 
> of what such a tool could be capable of.
> 
> [1] https://github.com/nturley/netlistsvg
> 
> 
> -Johannes Wågen
> 
> Den 09.05.2019 14:32, skrev Reece R. Pollack:
>> You might want to take a look at how Xilinx ISE and similar products handle 
>> this. Their tools take in Verilog or VHDL and can produce a graphical 
>> representation of the resulting logic. It's not as readable as a hand-drawn 
>> schematic but it exists and enough people find it useful that Xilinx 
>> maintains it.
>> 
>> -Reece
>> 
>> On 5/3/19 6:38 PM, Russell Oliver wrote:
>>> I have no doubt about the difficulty of plumbing something like this
>>> feature into KiCad. Most things are easier said than done.
>>> 
>>> A few thoughts in response
>>> 
>>> 1. My initial thought was to skip generating a graphical schematic,
>>> and to simply join in essence two or more netlists while avoiding name
>>> conflicts. It seems convoluted to start with essentially a
>>> connectivity graph, only to create a graphical representation for it
>>> be be evaluated to create a connectivity graph. It begs the questions
>>> then, should/could there be a text based representation of the
>>> connectivity graph created by eeschema with the information needed to
>>> perform ERC?
>>> 
>>>   No ERC would be performed between the eeshema Netlist and the Skidl
>>> netlist. This would be left as a design task. The only ERC check would
>>> be on the hierarchical pins which would be predefined by the user as
>>> the interface to the SKIDL generated netlist. Users could be warned
>>> that ERC information doesn't exist for some components.
>>> 
>>> 2. Thinking about it further the task of generating a graphical
>>> schematic shouldn't be too difficult using the SKIDL library. I
>>> suspect Dave would be disappointed in me for being addicted to
>>> schematics. A simple grid based layout with plenty of room between
>>> symbols and using straight line between pins to create connections
>>> would be possible. This would easiest once Eeschema has python support
>>> and the new file format.
>>> 
>>> 2. Editing SKIDL scripts as subsheets I envisage would either be
>>> through a user defined text editor, or a basic one implemented into
>>> KiCad. Once the edit has been done, the file would be evaluated
>>> through the python runtime with the Skidl library (or for a more
>>> generic solution a user specified command line, with the output
>>> captured back as a netlist or schematic).
>>> 
>>> 3. Editing of the resulting components through the edit symbol fields
>>> dialog I think would be possible but only as a one way operation once
>>> the generated netlist/schematic has been added. In that sense it would
>>> be up to the user to maintain that information in the script so that
>>> it is generated each time.
>>> 
>>> Kind Regards
>>> Russell
>>> 
>> 
>> 
>> ___
>> 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
> 
> 
> 
> ___
> 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


___
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

Re: [Kicad-developers] IMPORTANT build change for OSX users

[Jeff Young]

I don’t know whether the configure statement is in them or not.  (I haven’t 
been able to check because it seems the server is down.)

New folks won’t need the rest of the instructions as they’ll be building from 
scratch.

Cheers,
Jeff.


> On 9 May 2019, at 17:28, Michael Kavanagh  wrote:
> 
> Should the build instructions in the developers docs be updated?
> 
> Cheers,
> Michael
> 
> On Thu, 9 May 2019 at 00:03, Jeff Young  > wrote:
> I’ve added a check in the headers that will fail a compile if 
> wxUSE_UNICODE_UTF8 is set.  This will allow us to remove a bunch of our mutex 
> hacks.  (It turns out that it’s only on for OSX; the other platforms already 
> have it off.)
> 
> You’ll need to do 3 things in your wxWidgets tree:
> 
> 1) git fetch (your origin should be set to g...@github.com 
> :KiCad/wxWidgets.git and you should be on branch 
> kicad/macos-wx-3.0)
> 2) run your configure command without the --enable-UTF8 option [1]
> 3) make install (in wxWidgets/build)
> 
> (You’ll probably need to do a clean and a re-build of Kicad after this.)
> 
> Cheers,
> Jeff.
> 
> [1] This is the configure I used:
> 
> ../configure \
> --prefix=`pwd`/../wx-bin \
> --with-opengl \
> --enable-aui \
> --enable-html \
> --enable-stl \
> --enable-debug \
> --enable-debug-gdb \
> --with-libjpeg=builtin \
> --with-libpng=builtin \
> --with-regex=builtin \
> --with-libtiff=builtin \
> --with-zlib=builtin \
> --with-expat=builtin \
> --without-liblzma \
> --with-macosx-version-min=10.13 \
> --enable-universal-binary=x86_64 \
> CC=clang \
> CXX=clang++
> 
> ___
> 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 
> 

___
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

Re: [Kicad-developers] IMPORTANT build change for OSX users

[Michael Kavanagh]

Should the build instructions in the developers docs be updated?

Cheers,
Michael

On Thu, 9 May 2019 at 00:03, Jeff Young  wrote:

> I’ve added a check in the headers that will *fail* a compile if
> wxUSE_UNICODE_UTF8 is set.  This will allow us to remove a bunch of our
> mutex hacks.  (It turns out that it’s only on for OSX; the other platforms
> *already* have it off.)
>
> You’ll need to do 3 things in your wxWidgets tree:
>
> 1) git fetch (your origin should be set to g...@github.com
> :KiCad/wxWidgets.git and you should be on branch kicad/macos-wx-3.0)
> 2) run your configure command *without* the --enable-UTF8 option [1]
> 3) make install (in wxWidgets/build)
>
> (You’ll probably need to do a clean and a re-build of Kicad after this.)
>
> Cheers,
> Jeff.
>
> [1] This is the configure I used:
>
> ../configure \
> --prefix=`pwd`/../wx-bin \
> --with-opengl \
> --enable-aui \
> --enable-html \
> --enable-stl \
> --enable-debug \
> --enable-debug-gdb \
> --with-libjpeg=builtin \
> --with-libpng=builtin \
> --with-regex=builtin \
> --with-libtiff=builtin \
> --with-zlib=builtin \
> --with-expat=builtin \
> --without-liblzma \
> --with-macosx-version-min=10.13 \
> --enable-universal-binary=x86_64 \
> CC=clang \
> CXX=clang++
>
> ___
> 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
>
___
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

[Kicad-developers] eemodern - segfault on eeschema when aborting a paste operation with "esc" key on commit 5f4a6e33a0054489434b7f388e8dc559707140f6 (also in previous)

[Dino Ghilardi]

Hi,
In today's version I experience a segfault anytime a paste operation is 
aborted using the "esc" key.



How to reproduce the behaviour.

-Create a new schematic
-Add a GND symbol
-Copy it with ctrl-c
-Paste it with ctrl-v, without confirming with click or enter
-ESC key to abort,

then an assertion:

ASSERT INFO:
/home/dinoghi/SANDBOXKICAD5/src/kicad/common/view/view.cpp(386): assert 
"viewData->m_view == this" failed in Remove().


BACKTRACE:
[1] make_fcontext

then segmentation fault, even if "continue" is clicked in the "assert" 
windows.


-Same behaviour copying a graphic line in an existing schematic.

On the terminal output also I had the messages:
-
/home/dinoghi/SANDBOXKICAD5/src/kicad/common/view/view.cpp(386): assert 
"viewData->m_view == this" failed in Remove().
/home/dinoghi/SANDBOXKICAD5/src/kicad/common/dlist.cpp(175): assert 
"aElement && aElement->GetList() == this" failed in remove().

Segmentation fault
---


P.S.: Some other points (not so critical and I do not know if it is a 
desired effect or not, so I report):hyerarchical sheet pins imported 
from a sub-sheet using "Place hyerarchical sheet pin corresponding to 
..." be moved outside the subsheet border (select, press M for "move" 
and they can be moved everywhere).



Let me know it makes sense to file bug reports for this.

Thanks,
Dino.

___
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

[Kicad-developers] eemodern - segfault on eeschema when aborting a paste operation with "esc" key on commit 5f4a6e33a0054489434b7f388e8dc559707140f6 (also in previous)

[Dino Ghilardi]

...I forgot to paste version information... here they are

--
Application: kicad
Version: (5.1.0-512-g5f4a6e33a), debug build
Libraries:
wxWidgets 3.0.2
libcurl/7.52.1 OpenSSL/1.0.2r zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 
(+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3

Platform: Linux 4.9.0-8-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.69.0
OpenCASCADE Community Edition: 6.8.0
Curl: 7.52.1
Compiler: GCC 6.3.0 with C++ ABI 1010

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON

___
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

Re: [Kicad-developers] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

[Johannes Wågen]

Hi

The open source FPGA tools also have this.  It might be worth to take a 
look at[1]. It is written in JavaScript, but it does perhaps give some 
indication of what such a tool could be capable of.


[1] https://github.com/nturley/netlistsvg


-Johannes Wågen

Den 09.05.2019 14:32, skrev Reece R. Pollack:
You might want to take a look at how Xilinx ISE and similar products 
handle this. Their tools take in Verilog or VHDL and can produce a 
graphical representation of the resulting logic. It's not as readable 
as a hand-drawn schematic but it exists and enough people find it 
useful that Xilinx maintains it.


-Reece

On 5/3/19 6:38 PM, Russell Oliver wrote:

I have no doubt about the difficulty of plumbing something like this
feature into KiCad. Most things are easier said than done.

A few thoughts in response

1. My initial thought was to skip generating a graphical schematic,
and to simply join in essence two or more netlists while avoiding name
conflicts. It seems convoluted to start with essentially a
connectivity graph, only to create a graphical representation for it
be be evaluated to create a connectivity graph. It begs the questions
then, should/could there be a text based representation of the
connectivity graph created by eeschema with the information needed to
perform ERC?

  No ERC would be performed between the eeshema Netlist and the Skidl
netlist. This would be left as a design task. The only ERC check would
be on the hierarchical pins which would be predefined by the user as
the interface to the SKIDL generated netlist. Users could be warned
that ERC information doesn't exist for some components.

2. Thinking about it further the task of generating a graphical
schematic shouldn't be too difficult using the SKIDL library. I
suspect Dave would be disappointed in me for being addicted to
schematics. A simple grid based layout with plenty of room between
symbols and using straight line between pins to create connections
would be possible. This would easiest once Eeschema has python support
and the new file format.

2. Editing SKIDL scripts as subsheets I envisage would either be
through a user defined text editor, or a basic one implemented into
KiCad. Once the edit has been done, the file would be evaluated
through the python runtime with the Skidl library (or for a more
generic solution a user specified command line, with the output
captured back as a netlist or schematic).

3. Editing of the resulting components through the edit symbol fields
dialog I think would be possible but only as a one way operation once
the generated netlist/schematic has been added. In that sense it would
be up to the user to maintain that information in the script so that
it is generated each time.

Kind Regards
Russell




___
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




___
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

Re: [Kicad-developers] Developer doc web page down

[Nick Østergaard]

I know. I will report back when it works.

tor. 9. maj 2019 16.15 skrev Jon Evans :

> Still down
>
> On Wed, May 8, 2019 at 3:27 PM Wayne Stambaugh 
> wrote:
>
>> Still no luck :(
>>
>> On 5/8/19 10:12 AM, Nick Østergaard wrote:
>> > Ok, thank you for the notification.
>> >
>> > It looks like the publish job jot stuck in a retry loop, I have
>> > restarted it and it should be back within half an hour I hope.
>> >
>> > On Wed, 8 May 2019 at 15:15, Ben Hest  wrote:
>> >>
>> >> It's down for me.
>> >>
>> >> On Wed, May 8, 2019 at 6:20 AM Wayne Stambaugh 
>> wrote:
>> >>>
>> >>> Can anyone else get to the developers doc web page?  I still getting a
>> >>> 504 Gateway Time-out error since yesterday afternoon.  I am in the
>> >>> process of finishing up the v6 road map along with some other
>> developer
>> >>> doc updates and I wanted to see if anything else needed updating.  Any
>> >>> help would be appreciated.
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Wayne
>> >>>
>> >>> ___
>> >>> 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
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> -Ben
>> >> ___
>> >> 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
>>
>> ___
>> 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
>>
>
___
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

Re: [Kicad-developers] Developer doc web page down

[Jon Evans]

Still down

On Wed, May 8, 2019 at 3:27 PM Wayne Stambaugh  wrote:

> Still no luck :(
>
> On 5/8/19 10:12 AM, Nick Østergaard wrote:
> > Ok, thank you for the notification.
> >
> > It looks like the publish job jot stuck in a retry loop, I have
> > restarted it and it should be back within half an hour I hope.
> >
> > On Wed, 8 May 2019 at 15:15, Ben Hest  wrote:
> >>
> >> It's down for me.
> >>
> >> On Wed, May 8, 2019 at 6:20 AM Wayne Stambaugh 
> wrote:
> >>>
> >>> Can anyone else get to the developers doc web page?  I still getting a
> >>> 504 Gateway Time-out error since yesterday afternoon.  I am in the
> >>> process of finishing up the v6 road map along with some other developer
> >>> doc updates and I wanted to see if anything else needed updating.  Any
> >>> help would be appreciated.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>> ___
> >>> 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
> >>
> >>
> >>
> >> --
> >>
> >> -Ben
> >> ___
> >> 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
>
> ___
> 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
>
___
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

Re: [Kicad-developers] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

[Reece R. Pollack]

You might want to take a look at how Xilinx ISE and similar products handle 
this. Their tools take in Verilog or VHDL and can produce a graphical 
representation of the resulting logic. It's not as readable as a hand-drawn 
schematic but it exists and enough people find it useful that Xilinx maintains 
it.

-Reece

On 5/3/19 6:38 PM, Russell Oliver wrote:

I have no doubt about the difficulty of plumbing something like this
feature into KiCad. Most things are easier said than done.

A few thoughts in response

1. My initial thought was to skip generating a graphical schematic,
and to simply join in essence two or more netlists while avoiding name
conflicts. It seems convoluted to start with essentially a
connectivity graph, only to create a graphical representation for it
be be evaluated to create a connectivity graph. It begs the questions
then, should/could there be a text based representation of the
connectivity graph created by eeschema with the information needed to
perform ERC?

  No ERC would be performed between the eeshema Netlist and the Skidl
netlist. This would be left as a design task. The only ERC check would
be on the hierarchical pins which would be predefined by the user as
the interface to the SKIDL generated netlist. Users could be warned
that ERC information doesn't exist for some components.

2. Thinking about it further the task of generating a graphical
schematic shouldn't be too difficult using the SKIDL library. I
suspect Dave would be disappointed in me for being addicted to
schematics. A simple grid based layout with plenty of room between
symbols and using straight line between pins to create connections
would be possible. This would easiest once Eeschema has python support
and the new file format.

2. Editing SKIDL scripts as subsheets I envisage would either be
through a user defined text editor, or a basic one implemented into
KiCad. Once the edit has been done, the file would be evaluated
through the python runtime with the Skidl library (or for a more
generic solution a user specified command line, with the output
captured back as a netlist or schematic).

3. Editing of the resulting components through the edit symbol fields
dialog I think would be possible but only as a one way operation once
the generated netlist/schematic has been added. In that sense it would
be up to the user to maintain that information in the script so that
it is generated each time.

Kind Regards
Russell




___
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

[Kicad-developers] swig 4.0.0 patch

[mdoesbur]

Sorry about that, here's the patch



From e7586acb334955de22786d76e28f5374d2446d2c Mon Sep 17 00:00:00 2001
From: Mark 
Date: Thu, 9 May 2019 09:53:46 +0200
Subject: [PATCH] Fix for SWIG 4.0.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.21.0"

This is a multi-part message in MIME format.
--2.21.0
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

---
 scripting/build_tools/fix_swig_imports.py | 3 +++
 1 file changed, 3 insertions(+)


--2.21.0
Content-Type: text/x-patch; name="0001-Fix-for-SWIG-4.0.0.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Fix-for-SWIG-4.0.0.patch"

diff --git a/scripting/build_tools/fix_swig_imports.py b/scripting/build_tools/fix_swig_imports.py
index 160d7e2d9..4f97df079 100644
--- a/scripting/build_tools/fix_swig_imports.py
+++ b/scripting/build_tools/fix_swig_imports.py
@@ -40,6 +40,9 @@ if (len(lines)<4000):
 txt = b""
 
 for l in lines:
+if l.startswith(b"if _swig_python_version_info < (2, 7, 0):"): # ok with swig version >= 4.0.0
+l = l.replace(b"_swig_python_version_info < (2, 7, 0)", b"False")
+doneOk = True
 if l.startswith(b"if _swig_python_version_info >= (2, 7, 0):"): # ok with swig version >= 3.0.10
 l = l.replace(b"_swig_python_version_info >= (2, 7, 0)", b"False")
 doneOk = True

--2.21.0--


___
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

Re: [Kicad-developers] swig 4.0.0 patch

[Nick Østergaard]

Nothing attached

tor. 9. maj 2019 09.45 skrev :

>
>
> ___
> 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
>
___
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

[Kicad-developers] swig 4.0.0 patch

[mdoesbur]

___
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

Re: [Kicad-developers] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

[Maciej Suminski]

Hi Russell,

On 5/4/19 12:38 AM, Russell Oliver wrote:
> 2. Thinking about it further the task of generating a graphical
> schematic shouldn't be too difficult using the SKIDL library. I
> suspect Dave would be disappointed in me for being addicted to
> schematics. A simple grid based layout with plenty of room between
> symbols and using straight line between pins to create connections
> would be possible. This would easiest once Eeschema has python support
> and the new file format.

You could also completely skip wire connections and place net labels on
every pin.

Cheers,
Orson

___
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