readSystemSoftware adds to each node what the topology needs from its
system software: a switch's SSID and learning time, a host's wireless
SSID, a router's RIP switch, the manual routes and the firewall of a
router or home router. All 23 corpus files match Java.
- A router's firewall is one object its constructor hangs in two places;
the corpus writes it under the web server's "konfig" plug-in. The
places are merged.
- The decoder keeps entries a constructor made in a map, reached by
get(key) (installed applications), like the elements of a list.
- The Java oracle loads every file twice and writes values that differ
as null: what FILIUS rolls (MACs, a switch's SSID) without text search.
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