Re: [Kicad-developers] kicad promotion in help menu
On Thu, Oct 6, 2016 at 11:40 PM, Wayne Stambaugh wrote: > > On 10/6/2016 3:23 AM, Chris Pavlina wrote: >> On Thu, Oct 06, 2016 at 08:51:54AM +0200, jp charras wrote: >>> Le 06/10/2016 à 08:13, Cirilo Bernardo a écrit : Hi folks, Any comments on this patch I proposed a few weeks ago? https://lists.launchpad.net/kicad-developers/msg26412.html The patch adds a menu item in the main menu Help list to launch the system's default browser and bring up the "Contribute to KiCad" page (http://kicad-pcb.org/contribute/). The idea is to promote awareness of how users can get involved, whether it's helping with documentation, libraries, etc. I think we have a great little group at the moment, but more experts helping out or new users learning about the internals of the software is always better. :) - Cirilo >>> > > @Cirilo, I didn't forget about it I've just been really busy. I will > try to get to it this weekend. > Thanks, I understand; I've been far too busy recently to work on the other items I'd promised to look at like the generic progress dialog for external apps. - Cirilo >>> To be honest, if I like the idea, I am not thrilled by this (large?) patch. >>> A link in our About Kicad dialog (Information panel) could be better (only >>> 2 lines of code to add). >>> On this Information panel (the default panel when opening the dialog) there >>> are already the most >>> important links. >> >> As we discussed with Wayne on IRC a while ago, nobody will ever see it >> there. > > AFAIR I suggested adding this link to the about dialog as well but I > don't really have a strong opinion one way or the other. Cirilo is > correct that it could get lost along with all of the other information > in the about dialog. > >> >>> >>> >>> -- >>> Jean-Pierre CHARRAS >>> >>> ___ >>> 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 ___ 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] Spice simulation on windows.
Yes, I override three Spice variables:
- unset interactive
Disable interactive mode. You should expect hang ups when the option is
enabled and you get an error during parameter evaluation (it asks you
whether you want to continue, but there is no way to confirm).
- set noaskquit
Do not ask the user whether to quit the simulation.
- set nomoremode
Disables stopping output until a return key is pressed whenever there is
a large number of lines to be displayed.
I hope these three settings are reasonable. I override them as they have
no meaning when ngspice is used as a shared library, but in a different
configuration they cause troubles. Note that I do not put them into any
config files, these options are set only when simulation is run in KiCad.
Regards,
Orson
On 10/14/2016 03:12 PM, Wayne Stambaugh wrote:
> I didn't look that carefully but are you overriding any settings from
> the user config? I would prefer that you didn't so I don't spend time
> trying to figure out why my config settings are not being respected.
>
> On 10/13/2016 11:13 AM, Maciej Sumiński wrote:
>> It still loads the original configuration files (when possible) and
>> afterwards it checks a few extra locations (relative to the executed
>> binary path). This gives a chance to package maintainers to provide a
>> proper spinit file. If it fails to find a custom spinit file, but it
>> detects a path to codemodel libraries correctly, it will just load them.
>>
>> Regards,
>> Orson
>>
>> On 10/13/2016 04:08 PM, Wayne Stambaugh wrote:
>>> Does this patch override the users configuration or does it just solve
>>> the default configuration issue on windows and osx? If so, that's not a
>>> good thing. I'm fine if respects the users config. I still stand by my
>>> original investigation that this is a package configuration issue, not a
>>> broken code issue but if no one is willing to resolve those issues and
>>> your patch respects the user config, then I'm OK with it.
>>>
>>> On 10/13/2016 9:49 AM, Maciej Sumiński wrote:
Finally, I could get back to the issue. If we really focus about the
consequences, the real problem is not that spinit is not processed, but
the codemodel libraries are not loaded.
Looking at the default spinit file:
- most of the lines are comments
- one causes problems ('set interactive', has to be unset later)
- three others have no special meaning in shared library mode (aliases
and 'set x11lineararcs')
- the only meaningful lines are the ones that load codemodel libraries
To fix the problem, there is a patch which:
- Allows ngspice to load the default spinit/.spiceinit files (no changes
here).
- Looks for codemodel files in a few paths relative to eeschema
executable. If a valid path is found, then an ngspice variable __CMPATH
is set.
- After the default initialization, looks for spiceinit (note it is
spiceinit not .spiceinit) file in a few paths relative to eeschema
executable. If one is found, then it is executed. If we decide to
provide our spiceinit file (see the attachment), then thanks to __CMPATH
variable we can point to the right codemodel directory.
- If no spiceinit was found, but we know the correct path to codemodels,
then they are simply loaded.
- Unsets a few variables which may cause simulator hangups.
Once the patch is committed, codemodels should work out of the box for
the common msys2 builds and nightly Windows installers, even without a
custom spiceinit. If OSX bundles provide codemodel libraries, then there
is a chance it will work for them as well, otherwise we can add another
search path.
I know it may look like an ugly hack, but sincerely I have no better
idea at the moment. I am going to leave it here for comments for a few
days, if there are no objections, I will commit the changes.
Regards,
Orson
On 10/06/2016 05:53 PM, Wayne Stambaugh wrote:
> I have some additional information that may prove useful:
>
> 1) Using relative paths in the spinit file does not work on windows.
>
> 2) Placing a spinit file in the path where the ngspice and libngspice
> binaries reside works with no need to set any environment variables.
>
> Option 2 could be used by the installer. The installer itself would
> have to create the spinit file by substituting the install path for the
> path of the .cm files. I'm not sure if this would work on osx. Maybe
> one of our osx devs could test this. If it does, than that would
> resolve the simulation init issues.
>
> I've attached a simple circuit that demonstrates the issue. When the
> .cm files are not located, the simulation will run with the following
> warnings and cause the output of the op-amp to be an impossibly high 260V:
>
> Error on line 0 :
> a$poly$e.xu1.eos %v
Re: [Kicad-developers] Spice simulation on windows.
I didn't look that carefully but are you overriding any settings from
the user config? I would prefer that you didn't so I don't spend time
trying to figure out why my config settings are not being respected.
On 10/13/2016 11:13 AM, Maciej Sumiński wrote:
> It still loads the original configuration files (when possible) and
> afterwards it checks a few extra locations (relative to the executed
> binary path). This gives a chance to package maintainers to provide a
> proper spinit file. If it fails to find a custom spinit file, but it
> detects a path to codemodel libraries correctly, it will just load them.
>
> Regards,
> Orson
>
> On 10/13/2016 04:08 PM, Wayne Stambaugh wrote:
>> Does this patch override the users configuration or does it just solve
>> the default configuration issue on windows and osx? If so, that's not a
>> good thing. I'm fine if respects the users config. I still stand by my
>> original investigation that this is a package configuration issue, not a
>> broken code issue but if no one is willing to resolve those issues and
>> your patch respects the user config, then I'm OK with it.
>>
>> On 10/13/2016 9:49 AM, Maciej Sumiński wrote:
>>> Finally, I could get back to the issue. If we really focus about the
>>> consequences, the real problem is not that spinit is not processed, but
>>> the codemodel libraries are not loaded.
>>>
>>> Looking at the default spinit file:
>>> - most of the lines are comments
>>> - one causes problems ('set interactive', has to be unset later)
>>> - three others have no special meaning in shared library mode (aliases
>>> and 'set x11lineararcs')
>>> - the only meaningful lines are the ones that load codemodel libraries
>>>
>>> To fix the problem, there is a patch which:
>>> - Allows ngspice to load the default spinit/.spiceinit files (no changes
>>> here).
>>>
>>> - Looks for codemodel files in a few paths relative to eeschema
>>> executable. If a valid path is found, then an ngspice variable __CMPATH
>>> is set.
>>>
>>> - After the default initialization, looks for spiceinit (note it is
>>> spiceinit not .spiceinit) file in a few paths relative to eeschema
>>> executable. If one is found, then it is executed. If we decide to
>>> provide our spiceinit file (see the attachment), then thanks to __CMPATH
>>> variable we can point to the right codemodel directory.
>>>
>>> - If no spiceinit was found, but we know the correct path to codemodels,
>>> then they are simply loaded.
>>>
>>> - Unsets a few variables which may cause simulator hangups.
>>>
>>> Once the patch is committed, codemodels should work out of the box for
>>> the common msys2 builds and nightly Windows installers, even without a
>>> custom spiceinit. If OSX bundles provide codemodel libraries, then there
>>> is a chance it will work for them as well, otherwise we can add another
>>> search path.
>>>
>>> I know it may look like an ugly hack, but sincerely I have no better
>>> idea at the moment. I am going to leave it here for comments for a few
>>> days, if there are no objections, I will commit the changes.
>>>
>>> Regards,
>>> Orson
>>>
>>> On 10/06/2016 05:53 PM, Wayne Stambaugh wrote:
I have some additional information that may prove useful:
1) Using relative paths in the spinit file does not work on windows.
2) Placing a spinit file in the path where the ngspice and libngspice
binaries reside works with no need to set any environment variables.
Option 2 could be used by the installer. The installer itself would
have to create the spinit file by substituting the install path for the
path of the .cm files. I'm not sure if this would work on osx. Maybe
one of our osx devs could test this. If it does, than that would
resolve the simulation init issues.
I've attached a simple circuit that demonstrates the issue. When the
.cm files are not located, the simulation will run with the following
warnings and cause the output of the op-amp to be an impossibly high 260V:
Error on line 0 :
a$poly$e.xu1.eos %vd [ xu1.53 xu1.98 ] %vd ( xu1.3 net-_u1-pad1_ )
a$poly$e.xu1.eos
MIF-ERROR - unable to find definition of model a$poly$e.xu1.eos
Warning: Model issue on line 0 :
.model a$poly$e.xu1.eos spice2poly coef = [ 1.7e-3 1 ] ...
Unknown model type spice2poly - ignored
Error on line 0 :
a$poly$e.xu1.eref1 %vd [ vdd 0 0 0 ] %vd ( xu1.98 0 ) a$poly$e.xu1.eref1
MIF-ERROR - unable to find definition of model a$poly$e.xu1.eref1
Warning: Model issue on line 0 :
.model a$poly$e.xu1.eref1 spice2poly coef = [ 0 0.5 0.5 ] ...
Unknown model type spice2poly - ignored
Error on line 0 :
a$poly$e.xu1.eref2 %vd [ net-_u1-pad1_ 0 /out 0 ] %vd ( xu1.97 0 )
a$poly$e.xu1.eref2
MIF-ERROR - unable to find definition of model a$poly$e.xu1.eref2
Warning: Model issue on line 0 :
.model a$poly$e.xu1.eref2 spice2poly coef = [ 0 0.5 0.5 ] ...
Unk
Re: [Kicad-developers] kicad promotion in help menu
On Thu, Oct 6, 2016 at 2:40 PM, Wayne Stambaugh wrote: > > On 10/6/2016 3:23 AM, Chris Pavlina wrote: > > On Thu, Oct 06, 2016 at 08:51:54AM +0200, jp charras wrote: > >> Le 06/10/2016 à 08:13, Cirilo Bernardo a écrit : > >>> Hi folks, > >>> > >>> Any comments on this patch I proposed a few weeks ago? > >>> > >>> https://lists.launchpad.net/kicad-developers/msg26412.html > >>> > >>> The patch adds a menu item in the main menu Help list to launch the > >>> system's default browser and bring up the "Contribute to KiCad" page > >>> (http://kicad-pcb.org/contribute/). The idea is to promote awareness > >>> of how users can get involved, whether it's helping with documentation, > >>> libraries, etc. I think we have a great little group at the moment, > but > >>> more experts helping out or new users learning about the internals of > >>> the software is always better. :) > >>> > >>> > >>> - Cirilo > >> > > @Cirilo, I didn't forget about it I've just been really busy. I will > try to get to it this weekend. > Reminder and shameless plug for a short newsletter piece just published by the people of the CERN & Society Foundation: https://giving.web.cern.ch/content/kicad-development-1 Please help spread the word through your favourite channels. Thanks! Javier ___ 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
