File: pre.html

package info (click to toggle)
sch-rnd 1.0.10-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 17,696 kB
  • sloc: ansic: 119,120; awk: 1,502; makefile: 1,421; sh: 1,404; yacc: 905; lex: 172; xml: 160
file content (70 lines) | stat: -rw-r--r-- 3,002 bytes parent folder | download | duplicates (2)
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
<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