Re: [Kicad-developers] eeschema depends on libngspice.so instead of libngspice.so.0?
Hi Stefan,
On 10/30/18 4:22 PM, Brüns, Stefan wrote:
[snip]
> Some inline comments:
>> diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
>> index e56f3c849..cd4d0d78e 100644
>> --- a/eeschema/CMakeLists.txt
>> +++ b/eeschema/CMakeLists.txt
>> @@ -7,6 +7,15 @@ add_definitions( -DEESCHEMA )
>> if( KICAD_SPICE )
>> set( INC_AFTER ${INC_AFTER} ${NGSPICE_INCLUDE_DIR} )
>> +
>> +# Find out the exact libngspice file name
>> +get_filename_component( NGSPICE_REAL_PATH "${NGSPICE_LIBRARY}" REALPATH
>> ) +get_filename_component( NGSPICE_LIB_FILE "${NGSPICE_REAL_PATH}" NAME
>> ) +
>> +set_property( SOURCE sim/ngspice.cpp
>> +APPEND PROPERTY COMPILE_DEFINITIONS
>> +NGSPICE_LIB_FILE="${NGSPICE_LIB_FILE}"
>> +)
>> endif()
>> include_directories( BEFORE ${INC_BEFORE} )
>> @@ -359,7 +368,15 @@ target_link_libraries( eeschema_kiface
>> legacy_gal
>> ${wxWidgets_LIBRARIES}
>> ${GDI_PLUS_LIBRARIES}
>> +${NGSPICE_LIBRARY}
>
> Likely duplicates the line below and probably breaks when NGSPICE_LIBRARY is
> unset
You are correct. I have noticed that as well and in the patch that has
been committed [1] NGSPICE_LIBRARY is linked only conditionally.
>> )
>>
>> +
>> +if( KICAD_SPICE )
>> +target_link_libraries( eeschema_kiface
>> +${NGSPICE_LIBRARY}
>> +)
>> +endif()
>
> This does not achieve what you likely intended. At least on openSUSE, kicad
> is
> linked with the as-needed linker flag, discarding any symbols and libraries
> not actually linked to.
Good point, thank you sharing the information. Do you know how smart is
the linker when the flag is enabled? Is it enough to call a function
from libngspice in a part of code that is actually never executed? Do we
need to create a dedicated dummy executable and install it as well?
Kind regards,
Orson
> Kind regards,
>
> Stefan
1.
https://git.launchpad.net/kicad/commit/?id=b445b0fab28f7dd41273801d06d7705215c57c0f
signature.asc
Description: OpenPGP digital signature
___
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 depends on libngspice.so instead of libngspice.so.0?
On Montag, 29. Oktober 2018 13:12:19 CET Maciej Sumiński wrote:
> Hi Carsten,
>
> On 10/27/18 11:50 AM, Carsten Schoenert wrote:
> [snip]
>
> > I'd really appreciate if the situation could be improved here somewhere
> > in the future!
>
> Can you check if the attached patch solves the problem? It still does
> not recognize the right libngspice file under Windows, but I need to
> know if it is a step in the right direction.
>
> Cheers,
> Orson
Some inline comments:
> diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
> index e56f3c849..cd4d0d78e 100644
> --- a/eeschema/CMakeLists.txt
> +++ b/eeschema/CMakeLists.txt
> @@ -7,6 +7,15 @@ add_definitions( -DEESCHEMA )
> if( KICAD_SPICE )
> set( INC_AFTER ${INC_AFTER} ${NGSPICE_INCLUDE_DIR} )
> +
> +# Find out the exact libngspice file name
> +get_filename_component( NGSPICE_REAL_PATH "${NGSPICE_LIBRARY}" REALPATH
> ) +get_filename_component( NGSPICE_LIB_FILE "${NGSPICE_REAL_PATH}" NAME
> ) +
> +set_property( SOURCE sim/ngspice.cpp
> +APPEND PROPERTY COMPILE_DEFINITIONS
> +NGSPICE_LIB_FILE="${NGSPICE_LIB_FILE}"
> +)
> endif()
> include_directories( BEFORE ${INC_BEFORE} )
> @@ -359,7 +368,15 @@ target_link_libraries( eeschema_kiface
> legacy_gal
> ${wxWidgets_LIBRARIES}
> ${GDI_PLUS_LIBRARIES}
> +${NGSPICE_LIBRARY}
Likely duplicates the line below and probably breaks when NGSPICE_LIBRARY is
unset
> )
>
> +
> +if( KICAD_SPICE )
> +target_link_libraries( eeschema_kiface
> +${NGSPICE_LIBRARY}
> +)
> +endif()
This does not achieve what you likely intended. At least on openSUSE, kicad is
linked with the as-needed linker flag, discarding any symbols and libraries
not actually linked to.
Kind regards,
Stefan
___
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] In-memory string io_benchmark and some docs
Hi Wayne,
On Mon, Oct 29, 2018 at 6:16 PM Wayne Stambaugh wrote:
>
> Patches 2 and 3 are merged. I merge the fixed patch when you post it.
Freshly Jenkins'ed for your consideration.
Cheers,
John
From be91dac4227ee6cce6e3188b3b8aebabfaa5efda Mon Sep 17 00:00:00 2001
From: John Beard
Date: Mon, 8 Oct 2018 19:11:46 +0100
Subject: [PATCH] Add an in-memory STREAM_LINE_READER benchmark
This adds an io-benchmark case of the STRING_LINE_READER
class, which reads a file into a std::string, *then*
reads it line by line.
As expected, due to it all being in memory, this is very fast.
Also fixes an issue in io_benchmark where the input file
must be in the current dir.
---
qa/qa_utils/stdstream_line_reader.cpp | 4 +-
tools/io_benchmark/io_benchmark.cpp | 75 ++-
2 files changed, 64 insertions(+), 15 deletions(-)
diff --git a/qa/qa_utils/stdstream_line_reader.cpp b/qa/qa_utils/stdstream_line_reader.cpp
index 3f6596fdb..d473f3442 100644
--- a/qa/qa_utils/stdstream_line_reader.cpp
+++ b/qa/qa_utils/stdstream_line_reader.cpp
@@ -68,7 +68,7 @@ void STDISTREAM_LINE_READER::SetStream( std::istream& aStream )
IFSTREAM_LINE_READER::IFSTREAM_LINE_READER( const wxFileName& aFileName ) :
-m_fStream( aFileName.GetFullName().ToUTF8() )
+m_fStream( aFileName.GetFullPath().ToUTF8() )
{
if( !m_fStream.is_open() )
{
@@ -79,7 +79,7 @@ IFSTREAM_LINE_READER::IFSTREAM_LINE_READER( const wxFileName& aFileName ) :
SetStream( m_fStream );
-m_source = aFileName.GetFullName();
+m_source = aFileName.GetFullPath();
}
diff --git a/tools/io_benchmark/io_benchmark.cpp b/tools/io_benchmark/io_benchmark.cpp
index 9442d9317..0c11a96c3 100644
--- a/tools/io_benchmark/io_benchmark.cpp
+++ b/tools/io_benchmark/io_benchmark.cpp
@@ -123,7 +123,7 @@ static void bench_line_reader( const wxFileName& aFile, int aReps, BENCH_REPORT&
{
for( int i = 0; i < aReps; ++i)
{
-LR fstr( aFile.GetFullName() );
+LR fstr( aFile.GetFullPath() );
while( fstr.ReadLine() )
{
report.linesRead++;
@@ -140,7 +140,7 @@ static void bench_line_reader( const wxFileName& aFile, int aReps, BENCH_REPORT&
template
static void bench_line_reader_reuse( const wxFileName& aFile, int aReps, BENCH_REPORT& report )
{
-LR fstr( aFile.GetFullName() );
+LR fstr( aFile.GetFullPath() );
for( int i = 0; i < aReps; ++i)
{
@@ -155,6 +155,53 @@ static void bench_line_reader_reuse( const wxFileName& aFile, int aReps, BENCH_R
}
+/**
+ * Benchmark using STRING_LINE_READER on string data read into memory from a file
+ * using std::ifstream, but read the data fresh from the file each time
+ */
+static void bench_string_lr( const wxFileName& aFile, int aReps, BENCH_REPORT& report )
+{
+for( int i = 0; i < aReps; ++i)
+{
+std::ifstream ifs( aFile.GetFullPath().ToStdString() );
+std::string content((std::istreambuf_iterator(ifs)),
+std::istreambuf_iterator());
+
+STRING_LINE_READER fstr( content, aFile.GetFullPath() );
+while( fstr.ReadLine() )
+{
+report.linesRead++;
+report.charAcc += (unsigned char) fstr.Line()[0];
+}
+}
+}
+
+
+/**
+ * Benchmark using STRING_LINE_READER on string data read into memory from a file
+ * using std::ifstream
+ *
+ * The STRING_LINE_READER is not reused (it cannot be rewound),
+ * but the file is read only once
+ */
+static void bench_string_lr_reuse( const wxFileName& aFile, int aReps, BENCH_REPORT& report )
+{
+std::ifstream ifs( aFile.GetFullPath().ToStdString() );
+std::string content((std::istreambuf_iterator(ifs)),
+std::istreambuf_iterator());
+
+for( int i = 0; i < aReps; ++i)
+{
+STRING_LINE_READER fstr( content, aFile.GetFullPath() );
+while( fstr.ReadLine() )
+{
+report.linesRead++;
+report.charAcc += (unsigned char) fstr.Line()[0];
+}
+}
+}
+
+
/**
* Benchmark using an INPUTSTREAM_LINE_READER with a given
* wxInputStream implementation.
@@ -163,11 +210,11 @@ static void bench_line_reader_reuse( const wxFileName& aFile, int aReps, BENCH_R
template
static void bench_wxis( const wxFileName& aFile, int aReps, BENCH_REPORT& report )
{
-S fileStream( aFile.GetFullName() );
+S fileStream( aFile.GetFullPath() );
for( int i = 0; i < aReps; ++i)
{
-INPUTSTREAM_LINE_READER istr( , aFile.GetFullName() );
+INPUTSTREAM_LINE_READER istr( , aFile.GetFullPath() );
while( istr.ReadLine() )
{
@@ -188,8 +235,8 @@ static void bench_wxis( const wxFileName& aFile, int aReps, BENCH_REPORT& report
template
static void bench_wxis_reuse( const wxFileName& aFile, int aReps, BENCH_REPORT& report )
{
-S fileStream( aFile.GetFullName() );
-INPUTSTREAM_LINE_READER istr( , aFile.GetFullName() );
+S fileStream( aFile.GetFullPath() );
+INPUTSTREAM_LINE_READER istr( ,
Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE
Hi Wayne, Did you have a chance to give a look at this patch? >From our side we are using it almost a year now, it works fine. Else, I don't know if an equivalent function is now under going in the version 6? If so, I will be glad to help in testing. Regards, Badr Le 2017-12-24 15:31, Wayne Stambaugh a écrit : > Badr, > > Thank you for your patch but we are currently in feature freeze for the > stable 5 release. This patch will have to wait until the stable 5 > version is release and the version 6 development is opened. I'm not > sure exactly when that will happen but I will review your patch then. > > Cheers, > > Wayne > > On 12/24/2017 05:56 AM, Badr Hack wrote: Hi, > Here is a patch to add the remote library management as a plugin. > I added the possibility to specify multiple urls in a single file, it > was useful for our case. > We tested this approach several weeks, it seems fine in term of > performance. > It doesn't support remote zip files as for pcbnew. I can manage to > implement it in a second time. > If this patch is ok I will write a detailed documentation on how to use it. > Regards, > Badr > > Le 2017-08-14 15:21, Wayne Stambaugh a écrit : You could modify the > SCH_LEGACY_PLUGIN_CACHE code to handle urls instead > of file names. That way you could hand remote and local files in the > same plugin. wxWidgets has classes to handle urls (wxUrl) and input > streams (wxInputStream) which can be use as the LINE_READER > (INPUTSTREAM_LINE_READER takes a pointer to a wxInputStream object). > The primary drawback to this is performance. Past testing has shown > that wxInputStream has a lot more overhead and is significantly slower > than either our FILE_LINE_READER and std::istream so that is why we > haven't used it anywhere. It is also why I recommended writing a new > plugin. I'm guessing with remote I/O, the wxInputStream performance hit > will be far less noticeable than the remote I/O time. > > Wayne > > On 8/14/2017 3:29 AM, Badr Hack wrote: I see, > I thought it would be better to upgrade SCH_LEGACY_PLUGIN_CACHE to > handle remote libraries seemlessly rather than creating a new plugin. > I will check how to add a new plugin for remote libs without adding > additional actions for the user. > > Badr > > Le 2017-08-14 02:44, Wayne Stambaugh a écrit : I think you misunderstood what > I was implying. You should not be > looking for a different symbol library header. This is a change that I > would reject since you are effectively changing the library file > format. > What I suggested was that you create new plugin that reads from a > remote url similar to the github plugin used for footprint libraries. > > I also do not like the idea of a separate LoadRemote() method being > added to the SCH_PLUGIN object. There is no reason to add it. All of > the symbol library methods take a wxString which could be a url instead > of a file name. It is not limited to files and up to the plugin > type to > handle it correctly. My preference is that you create a new plugin for > remote files similar in concept to the github plugin. That is the > whole > point of the current plugin interface. Take a look at the board > plugins > to see the preferred method of creating plugins. > > I never really intended for the legacy symbol file format to have > multiple plugins like the kicad board and footprint library file > formats > so I didn't create separate parser and formatter objects like I did > with > the board file formats. Nothing is preventing that from happening with > the current schematic and symbol library file formats. I would not > have > any objection to splitting the parser out of the > SCH_LEGACY_PLUGIN_CACHE > object. I am planning on make the parsers and formatters for the new > schematic and symbol library file format code separate so it can be > used > by any plugin. > > Cheers, > > Wayne > > On 8/13/2017 3:26 PM, Badr Hack wrote: Hi, > > Here in the attachment the patch that add the remote lib retrieval. > > Badr > Le 2017-08-13 17:29, Badr Hack a écrit : Hi, > > Those couple of days I was checking how to update EESCHEMA to add > remote libraries retrieval function. > > Since am familiar with legacy format, I updated the plugin: > SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files. > > The idea was to create a new type of library > EESchema-REMOTELIBRARY (I > put an example in the attachment) > The content of this library is the following: > EESchema-REMOTELIBRARY Version 1.0 > URL https://www.example.com/mylib1.lib > URL https://www.example.com/mylib2.lib > ... > > This lib file is saved localy and specify the path of each remote > library you want to retrieve. > > The updated code seemlessly check the type of the library, if it is > EESchema-LIBRARY it parse it like always, else if it is > EESchema-REMOTELIBRARY it download each remote lib and parse it when > it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY). > > The
Re: [Kicad-developers] eeschema depends on libngspice.so instead of libngspice.so.0?
On 10/30/18 6:57 AM, Carsten Schoenert wrote: > Hello Orson, > > Am 29.10.18 um 21:06 schrieb Maciej Suminski: >>> works for me with current HEAD from today within Debian testing. >>> >> I should have said it earlier: one of the goals is to make dh_shlibdeps >> happy, but I do not use Debian so I have no way of verifying it. > > to check this I'd need to do a complete packaging with importing > tarballs etc. > For now I've "just" tested your patch against the current HEAD so the > build will work and also simulation task later if eeschema is opened. > dh_shlibdeps is going through the list of listed *.so.* files for a > binary and collecting the belonging packages. > > If ldd on eeschema is showing libngspice.so.0 then also sh_shlibdeps > will add the package libngspice0. This is something I haven't tested > yesterday (due a lack of time). Alright, then I think the new patch should be sufficient. Also, the shared library name is no longer hard-coded, but detected in CMake configuration step. I have just pushed the patch to the master and 5.0 branches. Cheers, Orson signature.asc Description: OpenPGP digital signature ___ 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
