The model carries the captured beans of a project's own applications
(ownApplicationsByNodeId); the export writes them again on the system
software of their node, and their classes go with the archive's other
entries. Checked by Java: from the exported files FILIUS loads
Accumulator and Broadcast as from the original; the export test no longer
leaves own applications out, and a probe that drops them is caught.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The archive's entries besides the configuration — the project's own Java
applications under projekt/anwendungen (.java, .class,
EigeneAnwendungen.txt) — now go through the editor model:
openProjectArchive reads a whole .fls into the model and keeps them in its
archiveEntries, saveProjectArchive writes a whole .fls from the model with
them unchanged. They cannot run here, but must not be lost.
Checked on every corpus file: each entry comes back byte for byte (7 files
carry applications of their own); a probe that drops them is caught.
Installing such applications on a host is the next step; Java loads those
only through its full loading path, which the oracle is to use first.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
exportProject.ts, step X4a: each installed program of a PC or notebook as
the FILIUS application of its class, keyed by that class name as Java keys
them, with its settings: servers switched on as the model has them, a web
server's port and virtual hosts, the DNS server's recursion on port 53, the
echo server's port, the generic client's target (none as null, as its
constructor leaves it), the peer count, the personal firewall. E-mail
contents are the next step.
The model lost a web server's virtual hosts switch (useVHost, on for 3 web
servers in the corpus); Swift sets it off on import. The core now has
WebServerConfiguration.virtualHosts (Swift's name), the import carries
Java's value, and the Swift comparison names Swift's error.
Checked by Java: every corpus file, imported, exported and written, loads
with the programs of the original, with no new departure. In the synthetic
model the PC has every program with settings away from the defaults, the
notebook programs without settings (Java's defaults, 3 peers), where Java
makes /peer2peer itself. 12 mutation probes, each loaded by Java, were all
caught.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
exportProject.ts is the counterpart of importProject.ts: from the editor
model to the Java view topologyWriter.ts writes. Step X1, the topology:
each node becomes the Java device of its kind with name, position and label
flags; its ports become interfaces or ports; each link a cable drawn
between its nodes; each documentation item a GUIDocuItem. A port's MAC is
the one the simulation uses (the file's, or one derived from the port id);
a router's gateway and DNS server go to every interface, as Java's own
setters do (Java reads the first interface's only). A host with a wireless
card joins a switch by a wireless cable, the only wireless connection Java
makes. The import now enables a host's wireless by Java's card flag, also
without an SSID, where Swift enables it for every SSID.
Checked by Java: every corpus file, imported, exported and written, loads
in Java FILIUS to the topology of the original up to named departures of
the model (a derived MAC where Java rolls one at each load; documentation in
render order, with the model's empty text, Dialog 12 and minimum size where
Java has none or less). A synthetic model adds a label with IP and MAC,
positions between pixels, a five-port switch, a wireless notebook, a
three-interface router and a half-transparent bold text. 17 mutation
probes, each loaded by Java, were all caught.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The e-mail client and server of every host come into the model (core:
EmailClientConfiguration, EmailServerConfiguration, EmailMessage), from
Java's view:
- the server's accounts are those of /mailserver/konten.txt, as Java reads
them at every simulation start; without the file those of the bean list,
which Java would drop;
- the client's account is that of /konten.txt; without it the first of an
older file's kontoListe, which FILIUS 2.14 no longer reads;
- messages are numbered per program in folder order, as Swift does; the
sent folder's are sent; a date is taken only when the file gives one.
Departures from Swift: accounts and messages stay where Swift drops what
fails its checks; first and last name stay apart; a port that is no number
is the default, with a warning. On the corpus the model matches Swift's on
all 13 files; the one Swift error is named (it numbers a mailbox's messages
as their received time and writes that into the konten.txt it rewrites).
The Swift dump now carries the e-mail state, and the file system
comparison leaves out only Swift's hidden state files (and the directories
it makes for them) instead of all of /mail, /mailserver and /peer2peer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Java stays the reference for the .fls format, but its errors are no longer
copied. The Java oracle still measures Java as it is; each deliberate
departure is named in the tests with its reason (JAVA_BUGS) and must really
depart. The corpus - what Java itself writes - still reads exactly as in
Java.
- /dns/hosts: a label may start with a digit, holds no backslash, and the
last one is not all digits (RFC 1123, RFC 3696); A, MX and NS are read in
any case (RFC 4343); a negative TTL is invalid, so 3600 (RFC 2181). Also
for the e-mail server's domain.
- /mailserver/konten.txt: empty fields count (Java's StringTokenizer skips
them and shifts the rest, so an empty password breaks the account); a
short line alone is left out, with a warning (Java throws for the whole
file); a message keeps an empty text or subject (Java's split loses it);
a ";" in an unescaped subject stays in the message; CRLF lines.
- /konten.txt: the last complete line is the account, also with an empty
address (Java takes the last line and loses the account); CRLF lines.
- Static DHCP assignments: a broken entry alone is left out (Java loses
every entry after it).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Java's DNS server reads its records from the text file /dns/hosts on every
query. dnsHosts.ts ports that reading (DNSServer.leseRecordListe,
ResourceRecord, Dateisystem.holeDatei) and keeps in the model the records
Java answers: type exactly A, MX or NS, and a name Java accepted. The file
stays in the file system as it is.
Both oracles read 76 hand-picked hosts files (dns-hosts.cases.txt): the
Java oracle through DNSServer.holeResourceRecords (DnsHostsCases), the
Swift oracle through TopologyDNSHostsFileCodec (--dns-hosts). The Java view
matches Java on every case; the model matches Swift except for 33 named
cases in twelve reasons: Java splits at single spaces and LF only, has no
comments or "IN", turns a TTL that is no int into 3600, keeps duplicates,
and empties names with a leading digit. The Swift dump now carries each
server's records; the corpus comparison covers them on 16 files.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
importProject carries a host's installed programs into the model with
the settings Swift keeps (web server port, Gnutella peer limit, DNS
recursion and forwarder, personal firewall) and two it does not (the echo
server's port, the generic client's target), plus Java's "switched on".
The Swift oracle writes programs and settings; they match on the 13 files
Swift reads completely.
Intended differences, named in the test:
- every FILIUS program is kept; Swift drops command prompt, text
editor, file explorer, image viewer, echo server and generic client;
- a web server's files stay in /webserver, its document root; Swift
moves them to /www. No program state goes into a host's files.
- multicast_server.fls: maxTeilnehmerZahl refers to a shared Integer
(a button's icon text gap, 4); Swift falls back to 3.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
importProject turns a PC's or notebook's Java file tree into Swift's
virtual file system, as Swift's registerVirtualFileSystem does: images
by type or extension from Base64, text by type, unknown types as binary
data or text, unsafe names and collisions left out with a warning, and
the whole import rejected over the project quota. NSString.pathExtension
is measured in the oracle, which now writes every imported file system.
On the 13 files Swift reads completely every file matches, images
compared by hash. Intended: a host whose file has no file system stays
empty, as in Java, where Swift adds the demo files of a new device.
Pending the applications step, the comparison reads our /webserver as
Swift's /www and leaves out the e-mail and Gnutella state files.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The core gains Swift's virtual file system (paths, case-insensitive
lookup that keeps the spelling, quotas, atomic changes, the defaults of
a new device) and the string behaviour the ported code relies on without
saying so. Both are measured in the Swift oracle: 11 file system cases
(the three Swift tests among them) step by step, and trimming, lower
case, equality, ordering and Base64 case by case — whitespace and control
characters over all of Unicode.
Found by measuring:
- Swift trims NEL and ZERO WIDTH SPACE, not the BOM; JS trim() does the
opposite. The .fls import now trims with swiftTrim.
- lowercased() maps scalar by scalar: a word-final sigma stays σ.
- Foundation decodes "====" and "Y===" as empty data.
- Foundation on Linux counts 24,735 plane-14 scalars as control
characters, a table artefact; the port keeps Unicode Cc+Cf.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
importProject carries the DHCP client switch and server settings (hosts
and home routers), a home router's port forwarding rows and a modem's
pairing into the model; the core gains the types, ported from Swift.
The Swift oracle writes them too, and they match on the 13 files Swift
reads completely. Configuration text is now trimmed throughout, as Swift
trims every value it reads (routes and firewall rules included).
Outside those files Swift switches every DHCP server of the Internet
examples off: their "aktiv" refers to a shared Boolean it cannot follow.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
importProject carries the system software settings into the model the
core runs: switch SSID and learning time (an SSID Java would roll comes
from the node id, as in Swift), a host's wireless network, manual routes,
RIP and the firewall of every router and home router. The Swift oracle
writes these settings too; they match on the 13 files Swift reads
completely.
A router's default gateway — its first interface's, which Java routes to
(Weiterleitungstabelle.holeTabelle) — is imported into the router's
device configuration. Swift's model drops it; in internetwork_komplett
the way back from 141.99.5.10 depends on it. A test pings across three
routers in the core, with and without it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
importProject builds what the simulation core runs from Java's view of a
file: nodes with kinds and ports, links between port ids, device and
interface IP configurations, documentation items with Swift's derived
ids. The core gains the model types it needs (node, link, graph,
documentation item), ported from filius-ipad.
Checked against the Swift import, which the Swift oracle now writes in
full (corpus.swift.json, "state"), on the 13 files Swift reads
completely. Two differences are intended and named in the test:
- a device the file leaves unnamed has Java's default name
("Switch / WLAN"), not Swift's;
- multicast_server.fls: useIPAsName refers to a shared Boolean that
Swift cannot follow; Java shows the IP address, and so do we.
All 23 files import with as many devices and cables as Java has, and an
imported example pings across its router in the core.
Port counts of switches and routers follow Java's lists instead of
Swift's guess from references.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
julian.kiedaischandClaude Opus 5.5