From: <na...@li...> - 2011-03-22 05:18:58
|
Hello Paolo, I updated the table of conventions, maybe it is better to write it here as text, so every maintainer can see it easily and make suggestions: ------------------------------------------------------------ Convention Description ------------------------------------------------------------ TypeWriter Typewriter words denote keywords, examples, command strings, or used defined names. <argument> Text between inequality signs, denotes an user-defined argument (identifier or value). | Vertical bars, used as an OR operator, separate possible choices for a simple argument. [ ] Brackets denotes optional arguments. When used with vertical bars, denote list of options. { } Braces denote list of options, separated by vertical bars, where it is mandatory to use one of the arguments of the list ... Three dots (...). In general forms ngspice description, denotes that it is possible to repeat the previous argument. In examples, denotes that text was omitted. xxx, yyy, zzz Three x, y, or z following a component letter denote arbitrary alphanumeric string. ----------------------------------------------------------------- I think that to overcome the ambiguity of brackets used as vector or options, we could put the vector indicators between braces { }. For example: .MODEL MODELNAME MODELTYPE + ( PARAMNAME1= { [ } <pvalue> [ <pvalue> ... ] { ] } ... ) What do you think? Best regards, Andrés -----Original Message----- From: Paolo Nenzi <pne...@gm...> To: Ngspice developers mailing list. <ngs...@li...> Sent: Mon, Mar 21, 2011 5:49 am Subject: Re: [Ngspice-devel] Documentation Hello Andres, The table desicribing the typographical conventions is a good thing, and following the common style for IT text is right. We have some issue with the command language in ngspice as braces have a meaning in ngspice (parameters and vectors). We should make clear when a brace is used to denote options and when is used to specify a vector. Ciao, Paolo On Mar 19, 2011, at 6:10 PM, na...@li... wrote: Holger, I think that the first thing to do is to create a table with conventions, some thing like: "Conventions used in this document The following table describes the typographic and syntax conventions used in this document: --------------------------------------------------------------------------------------------------- Convention Description ---------------------------------------------------------------- TypeWriter Typewriter words denotes keywords, examples, commands strings, or used defined names. [ ] Brackets denote optional arguments <identifier> Text between inequality signs denotes an user-defined identifier or value. ... Three dots (...) in ngspice command description, denotes that it is possible to repeat the previous argument In examples, denotes that text was omitted. | Vertical bars, used as an OR operator, separate possible choices for a simple argument. { } Braces are used with vertical bars, denotes list of options. It is mandatory to use one of the arguments of the list. --------------------------------------------------------------------------------------" Then, the command syntax should be rewritten. Examples: .SUBCKT Line General form: .SUBCKT <subname> <node> [<node> <node> ...] [<pname=pvalue> <pname=pvalue> ... ] .PLOT Lines General form: .PLOT { DC | AC | TRAN | NOISE| DISTO } <ovn> [<ovn> ...] Devices Models General form: .MODEL <mname> {TYPE} ( <PNAME1=pval1> <PNAME2=pval2> ... ) I'm not a native english speaker, so I think that it's better if the maintainers check the patches before the integration. Best regards, Andrés -----Original Message----- From: Holger Vogt <hol...@un...> To: Ngspice developers mailing list. <ngs...@li...> Sent: Sat, Mar 19, 2011 5:45 am Subject: Re: [Ngspice-devel] Documentation Andrés, many thanks for your offer to help! The manual in fact would need some standardisation of syntax. Maybe firstly you describe what you intend to do. We (maintainers) should discuss and agree. This would also help to obtain a small manual on how to write the manual. We then have to figure out how to apply your patches. Maybe it is best to send them directly to me, I will care for their integration. Holger Am 19.03.2011 06:42, schrieb na...@li...: > Hi, > I'd like to help to correct the manual, I'd like to use conventions for > the command syntax descriptions. Should I send patches to these list to > the changes be approved? or how could I help? > > Thanks > > Andrés > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > > > > _______________________________________________ > Ngspice-devel mailing list > Ngs...@li... > https://lists.sourceforge.net/lists/listinfo/ngspice-devel ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Ngspice-devel mailing list Ngs...@li... https://lists.sourceforge.net/lists/listinfo/ngspice-devel ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d_______________________________________________ Ngspice-devel mailing list Ngs...@li... https://lists.sourceforge.net/lists/listinfo/ngspice-devel = ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Ngspice-devel mailing list Ngs...@li... https://lists.sourceforge.net/lists/listinfo/ngspice-devel |