1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
|
<html>
<head>
<title> sch-rnd modularization </title>
</head>
<body>
<H1> sch-rnd modularization </H1>
<H2> Why bother... </H2>
I believe good software should be modular. This is especially important in
the context of large software, such as CAD applications. There should be
a thin core that can model the world and provide the basic operations defined
on it but anything else should go in separate modules.
<p>
Sch-rnd is built up from scratch with modularity in mind.
<p>
I believe such modularization has benefits on multiple levels:
<ul>
<li> it is possible to compile smaller, potentially faster executables by omitting features the specific user would never use anyway
<li> in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
<li> such plugins have to have some sort of APIs if they want to reference each other or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
</ul>
<H2> Code size in charts </H2>
<h3> Overall distribution </h3>
All numbers are in <a href="http://en.wikipedia.org/wiki/Source_lines_of_code">SLOC</a>
and are acquired running sloccount on the given directory. While lines of
code alone is not a true measure of complexity, it's a good estimation. The
slices of pie charts are the major components of the sch-rnd executable.
<p>
<table border=1 cellspacing=0><tr><td><img src="after.png"><tr><td>Main components</table>
<p>
The main components are:
<ul>
<li> libcschem: library that is operating the data model and the modular compiler
<li> sch-rnd app: application code: main() and the central infrastructure
<li> 3rd minilibs: 3rd-party minilibs shipped with sch-rnd; these minilibs are specialized in narrow tasks
<li> plugins: optional modules implementing the actual functionality (each can be disabled)
</ul>
<h3>Zooming on to the plugins</h3>
<p>
<table border=0 width="100%">
<tr>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="mods.png"><tr><td><b>total size per class</b></table>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="io.png"><tr><td>IO plugins</table>
</table>
<table border=0 width="100%">
<tr>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="feature.png"><tr><td>feature plugins </table>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="export.png"><tr><td>export plugins</table>
</table>
<table border=0 width="100%">
<tr>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="gui.png"><tr><td>GUI plugins</table>
<td width="50%"><table border=1 cellspacing=0><tr><td><img src="engine.png"><tr><td>engine plugins</table>
</table>
<p>
(Red means the plugin doesn't really work).
<H2> Progress in numbers </H2>
Below is a table with the summary of core plugins.
<table border=1 cellspacing=0>
<tr><th>module <th>size [sloc] <th> status <th> configure<br>default <th> class <th> description
<tr><th align=left>act_draw<td>278
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> Actions for drawing objects on a graphical sheet or symbol
<tr><th align=left>act_read<td>333
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> Data access related API as actions
<tr><th align=left>backann<td>1128
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> interactive back annotation
<tr><th align=left>construct<td>465
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> construct complex objects from atoms, break up groups
<tr><th align=left>diag<td>71
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> Actions for sch-rnd core diagnostics, intended for developers. These are not in core because end users normally don't need these. As a plugin, due to dynamic loading, it can be dropped on an existing sch-rnd installation with minimal risk of scaring away a reproducible bug.
<tr><th align=left>export_abst<td>194
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> export
<td> export project's abstract model to text
<tr><th align=left>export_bom<td>254
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> export
<td> export a BoM based on the components of the abstract model, using configurable templates
<tr><th align=left>export_lpr<td>14
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> export
<td> Export to lpr (using export_ps to generate postscript)
<tr><th align=left>export_png<td>267
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> export
<td> png, jpeg and gif render
<tr><th align=left>export_ps<td>576
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> export
<td> PostScript, Encapsulated PostScript exporter
<tr><th align=left>export_spice<td>474
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> export
<td> SPICE netlist exporter for circuit simulation
<tr><th align=left>export_svg<td>219
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> export
<td> Scalable Vector Graphics exporter
<tr><th align=left>export_tedax<td>259
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> export
<td> export netlist as a tEDAx netlist block
<tr><th align=left>gui<td>1415
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> gui
<td> sch-rnd-specific GUI elements
<tr><th align=left>io_altium<td>2444
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> io
<td> Load schematics from altium schdoc
<tr><th align=left>io_geda<td>1236
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> io
<td> Load schematics and symbols from gEDA format.
<tr><th align=left>io_lihata<td>1576
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> io
<td> Load and save the schematics and symbols in the native lihata format.
<tr><th align=left>io_ngrp_fawk<td>259
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> io
<td> non-graphical schematic sheets in form of fawk scripts.
<tr><th align=left>io_ngrp_tedax<td>393
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> io
<td> Load non-graphical schematic sheets in tEDAx format.
<tr><th align=left>io_tinycad<td>1511
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> io
<td> Load schematics from TinyCAD .dsn xml format.
<tr><th align=left>lib_alien<td>623
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> io
<td> Format-independent helper functions for reading alien files
<tr><th align=left>lib_netlist_exp<td>62
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> export
<td> Helper functions for exporting netlists
<tr><th align=left>lib_ngrp<td>241
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> io
<td> Helper functions for handling non-graphical sheets
<tr><th align=left>lib_plot<td>639
<td bgcolor="lightgreen" > works
<td bgcolor="red"> disable-all
<td> gui
<td> subdialog for plotting and navigating graphs
<tr><th align=left>lib_target<td>133
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> export
<td> Helper functions for implementing target plugins
<tr><th align=left>place<td>137
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> place complex objects such as terminals from template
<tr><th align=left>propedit<td>2203
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> List and edit properties of a group of objects.
<tr><th align=left>query<td>4245
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> sch-rnd query language: execute expressions on objects and rules for the programmed drc.
<tr><th align=left>renumber<td>333
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> Systematically change the name of selected symbols
<tr><th align=left>sch_dialogs<td>6545
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> gui
<td> Standard schematics editor dialog boxes
<tr><th align=left>sim<td>1695
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> abstract differences of circuit simiulation implementations, provide an unified interface (infrastructure, CLI and actions)
<tr><th align=left>sim_gui<td>2138
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> GUI for the the a unified high level simulation interface
<tr><th align=left>sim_ngspice<td>438
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> ngspice specific execution glue (for the GUI)
<tr><th align=left>std_cschem<td>342
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> engine
<td> Handles: component connect
<tr><th align=left>std_devmap<td>1007
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> engine
<td> Handles slotting, device mapping and port mapping
<tr><th align=left>std_forge<td>2088
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> engine
<td> Handles: attribute forging
<tr><th align=left>std_tools<td>1461
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> feature
<td> Tools for drawing standard cschem concrete primitives
<tr><th align=left>symlib_fs<td>119
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> symlib
<td> access symbol libraries stored on the local file system
<tr><th align=left>symlib_local<td>696
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> symlib
<td> access symbol library stored within the sheet
<tr><th align=left>target_none<td>46
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> engine
<td> Display original names
<tr><th align=left>target_pcb<td>176
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> engine
<td> Attribute transformations for the PCB workflow
<tr><th align=left>target_spice<td>1096
<td bgcolor="lightgreen" > works
<td bgcolor="lightgreen"> buildin
<td> engine
<td> Attribute transformations for the SPICE workflow
</table>
<H3> Classes </H3>
<p>
Each plugin implements a class (rarely a set of classes). Classes are:
<table border=1 cellspacing=0>
<tr><th>name <th> description
<tr><td>feature <td> random features directly accessible for the user, usually actions
<tr><td>lib <td> support code library for other plugins (core doesn't depend on these); functionality not directly accessible for the user but other plugins may depend on it
<tr><td>import <td> load alien formats into the design space
<tr><td>export <td> save (parts of) the design space in alien formats
<tr><td>io <td> native file format (save & load) implementation
</table>
<H3> Status </H3>
<p>
Common status column values mean:
<table border=1 cellspacing=0>
<tr><th>name <th> description
<tr><td>works <td> production quality code - configures, compiles, tested
<tr><td>WIP <td> work in progress: the plugin may be avaialble for testing but is not yet production quality
<tr><td>abandoned <td> unmaintained plugin; may be in working condition but there is no developer supporting it
<tr><td>deprecated <td> legacy plugin scheduled for removal; may still work but will soon be removed; if your workflow depends on it, please report ASAP
</table>
<H3> Plugin dependency map </H3>
<p>
<img src="deps.svg" alt="sch-rnd plugin dependency graph">
</body>
</html>
|
