Table des matières
switch-wifi : Séparer les mesures réseau de l’interface
switch-wifi est un tableau de bord réseau pour Switch avec une interface Borealis. Il sépare les calculs portables de l’application console pour permettre de tester le cœur sans la chaîne de compilation Switch.
- Langages
- 3Répartition du code
- Composants documentés
- 2Explorer les modules
- Documents source
- 2Lire les instructions
Langages du dépôtC++ 86.58%3
Parts calculées à partir des octets GitHub Linguist.
| Langage | % | Octets |
|---|---|---|
| C++ | 61 640 | |
| CMake | 5 914 | |
| Python | 3 639 |
1. Aperçu
1.1. Pourquoi il existe
Utilitaire C++ natif communiquant directement avec les services wlan de l'OS Switch.
1.2. Cas d’usage
Configuration réseau rapide pour console Switch sans interface complexe.
2. Cas d’utilisation
Application homebrew pour Nintendo Switch qui affiche l'état du Wi-Fi, mesure le lien HTTPS et lit l'état Bluetooth.
- Vérifier le lien Wi-Fi
- Joueur sur SwitchHorizon NIFM / BTM
L'onglet Dashboard lit le type de lien, le SSID, l'IPv4, la passerelle, le DNS et les barres de signal 0 à 3 via NIFM (NetworkService) ; le RSSI vient de wlan:inf seulement si le micrologiciel l'expose.
- Mesurer la connexion
- Joueur sur SwitchServeur de débit HTTPS
SpeedTestEngine lance 8 sondes de latence HTTPS, puis un téléchargement de 25 Mio et un envoi de 10 Mio remplis de zéros avec libcurl vers speed.cloudflare.com par défaut, avec médiane, P95 et gigue.
- Voir les réseaux enregistrés
- Joueur sur SwitchHorizon NIFM / BTM
L'onglet Networks montre les métadonnées de base des profils enregistrés et les canaux autorisés par Horizon, avec le calcul de chevauchement de core/metrics ; les identifiants ne sont jamais affichés.
- Inspecter le Bluetooth
- Joueur sur SwitchHorizon NIFM / BTM
BluetoothService lit l'état radio BTM et le nombre d'appareils, puis lance un balayage BLE passif limité qui renvoie au plus dix adresses uniques.
- Exporter un rapport
- Joueur sur Switch
L'onglet About écrit sdmc:/switch-wifi-diagnostics.txt avec la version, la cible de compatibilité, les détails réseau et les compteurs Bluetooth, sans identifiants.
2.1. Scénario : Comparer deux canaux de routeur sur Switch
- Compiler build-switch/switch-wifi.nro dans le conteneur devkitpro/devkita64 et le vérifier avec python3 scripts/verify_nro.py.
- Copier le NRO sur la carte SD et le lancer depuis le menu homebrew.
- Ouvrir l'onglet Dashboard pour confirmer que la Switch est en Wi-Fi et noter les barres de signal.
- Lancer l'onglet Benchmark et lire la latence médiane, le P95, la gigue et les débits descendant et montant.
- Changer le canal du routeur, relancer la mesure et comparer les graphiques d'historique.
- Exporter sdmc:/switch-wifi-diagnostics.txt depuis l'onglet About pour garder le résultat.
Fichiers consultésREADME.mddocs/ARCHITECTURE.mddocs/BENCHMARKING.mdinclude/switch_wifi/network/speed_test.hppsrc/ui/main_tabs.cppscripts/verify_nro.py
3. Démarrage
Ces commandes viennent de la documentation du dépôt. Elles n’ont pas été exécutées pendant cette revue.
git clone --recursive https://github.com/antoinebou12/switch-wifi.git
cd switch-wifipython3 scripts/verify_nro.py build-switch/switch-wifi.nrocmake -S . -B build-switch -DPLATFORM_SWITCH=ON -DUSE_GLFW=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build-switch --target switch-wifi.nro --paralleldocker run --rm \
-v "$PWD:/work" -w /work \
devkitpro/devkita64:latest \
bash -lc 'cmake -S . -B build-switch \
-DPLATFORM_SWITCH=ON \
-DUSE_GLFW=ON \
-DCMAKE_BUILD_TYPE=Release && \
cmake --build build-switch --target switch-wifi.nro --parallel'4. Références du dépôt
Extraits des guides du dépôt, dans leur langue d’origine. Les liens ouvrent la version du code consultée.
Prérequis et premier essai
4.1. Native devkitPro installation
README.md
Configuration et utilisation
4.2. Wi-Fi environment
README.md
- Basic saved-network metadata without requesting full saved credential profiles.
- Authentication/encryption labels.
- Horizon allowed-channel query on HOS 6.0.0+.
- 2.4 GHz and 5 GHz channel/frequency helpers.
- Tested channel-overlap and contention-proxy math.
- Nearby AP scan kept behind a hardware-verification boundary until opaque Horizon AP records can be decoded safely across firmware versions.
- RF noise floor and SNR shown as unavailable rather than inferred from unrelated values.
Développement et contributions
4.3. Unit tests
README.md
The platform-independent metric, history, channel and benchmark-statistics code is tested on the host. The suite is split into:
- switch_wifi_metrics_tests;
- switch_wifi_history_tests;
- switch_wifi_benchmark_tests. Sanitizer build:
4.4. Development rules
CONTRIBUTING.md
- Keep Horizon/libnx IPC out of the Borealis UI layer.
- Add a host-side test for calculations and parsers whenever possible.
- Gate firmware-dependent behavior explicitly.
- Do not add code that retrieves Wi-Fi passphrases just to display profile information.
- Do not call a derived AP-overlap value “noise floor”, “SNR”, or “channel utilization” unless the underlying metric is actually measured.
- Keep Bluetooth diagnostics read-only.
5. Fonctions et composants 2
- Cœur de calcul portable
- CMake construit switch_wifi_core depuis src/core/metrics.cpp. Les tests hôtes utilisent cette bibliothèque indépendamment de Borealis. Ils couvrent les métriques, l’historique et les benchmarks, avec des sanitizers optionnels.
- Intégration console
- La cible applicative rassemble les modules src et lie Borealis, les bibliothèques libnx et libcurl. Le réseau et l’interface dépendent donc de la plateforme, tandis que le cœur numérique peut rester indépendant.
6. Architecture
Ouvrez un composant pour suivre ses connexions, ou explorez le diagramme complet.
Échantillons réseau
Cœur de métriques portable
- Depuis Échantillons réseau
- Vers Historique et résultats
- Depuis Tests unitaires hôtes
Historique et résultats
Tableau de bord Borealis
- Depuis Historique et résultats
Tests unitaires hôtes
Mermaid Diagramme interactif
Vue générale des composants et des échanges vérifiés dans le dépôt.

flowchart LR
n0["Échantillons réseau"]
n1["Cœur de métriques portable"]
n2["Historique et résultats"]
n3["Tableau de bord Borealis"]
n4["Tests unitaires hôtes"]
n0 --> n1
n1 --> n2
n2 --> n3
n4 --> n1
Version texte du diagramme
- Échantillons réseau → Cœur de métriques portable
- Cœur de métriques portable → Historique et résultats
- Historique et résultats → Tableau de bord Borealis
- Tests unitaires hôtes → Cœur de métriques portable
Suivre un parcours dans le code
Partez de la bibliothèque et de ses tests, puis examinez le module réseau qui fournit les mesures. Un débit HTTPS dépend du serveur et du trajet réseau; ce n’est pas une lecture directe de la capacité radio Wi-Fi.
7. Dossier technique
Établi à partir du code au commit 8ff883f (30 fichiers). Chaque élément vient d’une correspondance de motif dans le code: ouvrez le fichier lié avant de vous y fier.
7.1. Couches et modules
Les dossiers sont classés par couche selon leur nom, de l’interface utilisateur jusqu’à l’accès aux données. Comme le classement repose sur les noms seulement, le diagramme ne dit rien des appels entre couches.
Mermaid Vue en couches
flowchart TB
subgraph L_presentation["Présentation"]
direction TB
presentation_0["switch_wifi/ui<br/>3 fichiers"]
presentation_1["ui<br/>3 fichiers"]
end
subgraph L_interface["Points d’entrée et API"]
direction TB
interface_0["src<br/>1 fichier"]
end
subgraph L_application["Services applicatifs"]
direction TB
application_0["scripts<br/>3 fichiers"]
application_1["bluetooth<br/>1 fichier"]
application_2["switch_wifi/bluetooth<br/>1 fichier"]
end
subgraph L_domain["Domaine et règles métier"]
direction TB
domain_0["core<br/>1 fichier"]
domain_1["switch_wifi/core<br/>1 fichier"]
end
subgraph L_infrastructure["Données et infrastructure"]
direction TB
infrastructure_0["network<br/>1 fichier"]
infrastructure_1["switch_wifi/network<br/>1 fichier"]
end
subgraph L_core["Source principale"]
direction TB
core_0["switch_wifi<br/>1 fichier"]
end
subgraph L_tests["Tests"]
direction TB
tests_0["tests<br/>3 fichiers"]
tests_1["network<br/>1 fichier"]
tests_2["switch_wifi<br/>1 fichier"]
end
subgraph L_hosting["Build, CI et hébergement"]
direction TB
hosting_0[".github<br/>8 fichiers"]
hosting_1["(root)<br/>1 fichier"]
hosting_2["library<br/>1 fichier"]
end
L_presentation ~~~ L_interface
L_interface ~~~ L_application
L_application ~~~ L_domain
L_domain ~~~ L_infrastructure
L_infrastructure ~~~ L_core
L_core ~~~ L_tests
L_core ~~~ L_hosting
| Module | Couche | Fichiers | Types | Extensions |
|---|---|---|---|---|
scripts | Services applicatifs | 3 | 0 | .py |
switch_wifi/ui | Présentation | 3 | 3 | .hpp |
ui | Présentation | 3 | 6 | .cpp |
bluetooth | Services applicatifs | 1 | 0 | .cpp |
core | Domaine et règles métier | 1 | 0 | .cpp |
network | Données et infrastructure | 1 | 1 | .cpp |
src | Points d’entrée et API | 1 | 0 | .cpp |
switch_wifi | Source principale | 1 | 0 | .hpp |
switch_wifi/bluetooth | Services applicatifs | 1 | 1 | .hpp |
switch_wifi/core | Domaine et règles métier | 1 | 10 | .hpp |
switch_wifi/network | Données et infrastructure | 1 | 1 | .hpp |
7.2. Modèle C4
Du contexte du système aux déclarations du code. Chaque niveau conserve les limites des sources disponibles.
UML 1 · Contexte du système
La vue C4 la plus large : qui utilise le projet et sur quels systèmes et stockages externes il s’appuie. Rendu avec uml-mcp.
Source PlantUML
@startuml
!include <C4/C4_Context>
LAYOUT_LEFT_RIGHT()
System(SYS, "switch-wifi", "switch-wifi est un tableau de bord réseau pour Switch avec une interf…")
@enduml
UML 2 · Conteneurs
Un niveau plus près : les parties qui s’exécutent séparément dans le projet, leur langage principal et le chemin des appels entre elles. Rendu avec uml-mcp.
Source PlantUML
@startuml
!include <C4/C4_Container>
LAYOUT_LEFT_RIGHT()
System_Boundary(SYS, "switch-wifi") {
Container(APP, "switch-wifi", "C++")
}
@enduml
UML 3 · Composants et couches
Modules regroupés par couche du code. Les limites indiquent l’organisation, sans affirmer une isolation à l’exécution ni des appels. Rendu avec uml-mcp.
Source PlantUML
@startuml
!include <C4/C4_Component>
LAYOUT_TOP_DOWN()
System_Boundary(SYS, "switch-wifi") {
Boundary(L0, "Présentation", "layer") {
Component(M0_0, "switch_wifi/ui", "C++", "3 fichiers")
Component(M0_1, "ui", "C++", "3 fichiers")
}
Boundary(L1, "Points d’entrée et API", "layer") {
Component(M1_0, "src", "C++", "1 fichiers")
}
Boundary(L2, "Services applicatifs", "layer") {
Component(M2_0, "scripts", "Python", "3 fichiers")
Component(M2_1, "bluetooth", "C++", "1 fichiers")
Component(M2_2, "switch_wifi/bluetooth", "C++", "1 fichiers")
}
Boundary(L3, "Domaine et règles métier", "layer") {
Component(M3_0, "core", "C++", "1 fichiers")
Component(M3_1, "switch_wifi/core", "C++", "1 fichiers")
}
Boundary(L4, "Données et infrastructure", "layer") {
Component(M4_0, "network", "C++", "1 fichiers")
Component(M4_1, "switch_wifi/network", "C++", "1 fichiers")
}
Boundary(L5, "Source principale", "layer") {
Component(M5_0, "switch_wifi", "C++", "1 fichiers")
}
Boundary(L6, "Tests", "layer") {
Component(M6_0, "tests", "C++", "3 fichiers")
Component(M6_1, "network", "C++", "1 fichiers")
Component(M6_2, "switch_wifi", "C++", "1 fichiers")
}
Boundary(L7, "Build, CI et hébergement", "layer") {
Component(M7_0, ".github", ".yml, .txt, .md", "8 fichiers")
Component(M7_1, "(root)", ".txt", "1 fichiers")
Component(M7_2, "library", ".txt", "1 fichiers")
}
}
@enduml
UML 4 · Code
Déclarations, champs et méthodes sélectionnés, regroupés par fichier source. Aucun héritage ni appel n’est déduit. Rendu avec uml-mcp.
Source PlantUML
@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
top to bottom direction
hide empty members
package "switch-wifi" {
package "include/switch_wifi/core/metrics.hpp" as F0 {
class "RingHistory" as T0_0 {
push()
clear()
size()
capacity()
empty()
values()
}
class "ConnectionSnapshot" as T0_1 {
std
ip
}
class "IpConfig" as T0_2 {
std
ip
}
class "BluetoothDevice" as T0_3 {
std
}
class "BluetoothScanResult" as T0_4 {
std
}
class "BluetoothSnapshot" as T0_5 {
std
}
class "LatencyStats" as T0_6 {
std
}
class "NearbyWifiNetwork" as T0_7 {
std
}
class "SavedNetwork" as T0_8 {
std
}
class "SpeedSample" as T0_9 {
std
}
}
package "src/network/network_service.cpp" as F1 {
class "NifmBasicProfileWire" as T1_0 {
uuid
networkName
profileType
connectionType
ssidLen
ssid
authentication
encryption
}
}
}
@enduml
7.3. Interface publique
Du code extérieur peut utiliser tout ce qui est listé ici. Le projet déclare aussi 22 types publics.
Points d’entrée
src/main.cppfichier d’entrée
En-têtes publics 8
include/switch_wifi/bluetooth/bluetooth_service.hpp include/switch_wifi/core/metrics.hpp include/switch_wifi/network/network_service.hpp include/switch_wifi/network/speed_test.hpp include/switch_wifi/ui/main_tabs.hpp include/switch_wifi/ui/signal_shader.hpp include/switch_wifi/ui/sparkline.hpp include/switch_wifi/version.hpp
7.4. Interface privée
Ces noms sont internes selon les conventions du langage: tiret bas initial, private, static ou pub(crate).
- Espace de noms anonyme
- 3
namespace { }src/bluetooth/bluetooth_service.cpp:13namespace { }src/network/network_service.cpp:12namespace { }src/ui/main_tabs.cpp:23
7.5. Services
Service 2
NetworkServiceshutdown, snapshot, savedNetworks et 2 autresBluetoothServicesnapshot, passiveScan
7.6. Entités et modèle de données 10
Mermaid Diagramme de classes des entités
classDiagram
direction LR
class E0["NifmBasicProfileWire"] {
+Uuid uuid
+char networkName
+u8 profileType
+u8 connectionType
+u8 ssidLen
+char ssid
}
class E1["ConnectionSnapshot"] {
+:string std
+IpConfig ip
}
class E2["IpConfig"] {
+:string std
+IpConfig ip
}
class E3["BluetoothDevice"] {
+:string std
}
class E4["BluetoothScanResult"] {
+:string std
}
class E5["BluetoothSnapshot"] {
+:string std
}
class E6["LatencyStats"] {
+:vector std
}
class E7["NearbyWifiNetwork"] {
+:string std
}
class E8["SavedNetwork"] {
+:size_t std
}
class E9["SpeedSample"] {
+:string std
}
E1 --> E2 : ip
E6 --> E3 : std
Une flèche relie un champ à l’entité que son type nomme.
| Entité | Nature | Premiers champs |
|---|---|---|
NifmBasicProfileWire | Structure de données | uuid, networkName, profileType, connectionType, ssidLen, ssid, authentication, encryption |
ConnectionSnapshot | Structure de données | std, ip |
IpConfig | Structure de données | std, ip |
BluetoothDevice | Structure de données | std |
BluetoothScanResult | Structure de données | std |
BluetoothSnapshot | Structure de données | std |
LatencyStats | Structure de données | std |
NearbyWifiNetwork | Structure de données | std |
Afficher 2 entités de plus
SavedNetwork | Structure de données | std |
|---|---|---|
SpeedSample | Structure de données | std |
7.7. Logique métier
Une fois écartés le code d’interface et les services et entités ci-dessus, ces classes ont le plus de méthodes.
RingHistoryDomaine et règles métier, 6 méthodespush, clear, size, capacity, empty, values
7.8. Intégrations externes
Clients HTTP
7.9. Stack et dépendances
Dépendances externes
2 paquets déclarés (2 à l’exécution, 0 pour le développement) dans CMakeLists.txt.
Tableau des paquets 2
| Paquet | Version | Usage | Rôle | Registre |
|---|---|---|---|---|
Threads | — | exécution | — | C/C++ (CMake) |
PkgConfig | — | exécution | — | C/C++ (CMake) |
7.10. Pipeline CI/CD
3 workflows GitHub Actions, 8 tâches. Chaque boîte est une tâche ; les boîtes à double bord publient ou déploient, et les flèches suivent les dépendances needs.
Mermaid Déroulement du pipeline
flowchart LR
subgraph wf0["CI"]
direction LR
wf0_host_tests["Host tests<br/>ubuntu-latest"]
wf0_sanitizers["ASan + UBSan<br/>ubuntu-latest"]
wf0_switch_nro["NRO<br/>ubuntu-latest"]
wf0_switch_nro_libnx_master[["NRO (current libnx master)<br/>ubuntu-latest"]]
end
subgraph wf1["Publish dist NRO"]
direction LR
wf1_build_and_publish["Build and publish dist/switch-wifi.nro<br/>ubuntu-latest"]
end
subgraph wf2["Release"]
direction LR
wf2_validate[["Validate release<br/>ubuntu-latest"]]
wf2_build_nro[["Build release NRO<br/>ubuntu-latest"]]
wf2_publish[["Publish GitHub Release<br/>ubuntu-latest"]]
end
t0(["push · demande de fusion · lancement manuel"])
t1(["push · lancement manuel"])
d0[("Versions GitHub")]
t0 --> wf0_host_tests
t0 --> wf0_sanitizers
t0 --> wf0_switch_nro
t0 --> wf0_switch_nro_libnx_master
t1 --> wf1_build_and_publish
t1 --> wf2_validate
wf2_validate --> wf2_build_nro
wf2_validate --> wf2_publish
wf2_build_nro --> wf2_publish
wf2_publish -.-> d0
| Workflow | Déclencheurs | Tâches | Publie vers |
|---|---|---|---|
CI.github/workflows/ci.yml | push, demande de fusion, lancement manuel |
| — |
Publish dist NRO.github/workflows/publish-dist.yml | push, lancement manuel |
| — |
Release.github/workflows/release.yml | push, lancement manuel |
| Versions GitHub |
7.11. Déploiement
Mermaid Schéma de déploiement
flowchart LR
repo[("Dépôt GitHub")]
ci[["GitHub Actions<br/>3 workflows"]]
pub_GitHub_Releases[("Versions GitHub")]
repo -->|"push ou demande de fusion"| ci
ci -->|"publie"| pub_GitHub_Releases
Où il s’exécute
Publié vers
7.12. Sécurité
Chaîne d’approvisionnement
7.13. Tests automatisés
- Fichiers de test
- 5
- Fichiers source
- 17
- Tests unitaires
- 4
- Tests performance
- 1
Aucun rapport chiffré de couverture dans les sources analysées.
Où sont les tests
tests 3 include/switch_wifi/network 1 src/network 1
Intégration continue
UML Pipeline CI
Le workflow GitHub Actions principal suit ces étapes. Les tâches lancées en parallèle sont côte à côte. Rendu avec uml-mcp.
Source PlantUML
@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
title CI
start
fork
partition "Host tests" {
:actions/checkout;
:Configure;
:Build;
:Unit tests;
}
fork again
partition "ASan + UBSan" {
:actions/checkout;
:Configure sanitizers;
:Build;
:Unit tests;
}
fork again
partition "NRO" {
:stable-image;
:latest-image;
:Checkout with Borealis;
:Toolchain inventory;
:Configure Switch build;
:Build NRO;
:Verify NRO structure;
:Build checksum;
}
fork again
partition "NRO (current libnx master)" {
:Checkout with Borealis;
:Build current libnx master;
:Configure Switch build;
:Build and verify NRO;
:Upload current-libnx NRO;
}
end fork
stop
@enduml
Rien trouvé pour: Base de données, Supervision.
8. Déploiement et exploitation
Les ports, le stockage et les relations de démarrage ci-dessous viennent de la configuration du dépôt. depends_on indique l’ordre de démarrage, pas la disponibilité du service.
9. Types et structure des fichiers
27 types déclarés, dont 12 dans l’aperçu des relations de base.
Diagramme des types
classDiagram
direction TB
class tec54ffc64505["BluetoothService"] {
snapshot()
passiveScan()
}
class t17625c2744a3["IpConfig"] {
<<struct>>
}
class t7988c53361f7["ConnectionSnapshot"] {
<<struct>>
}
class t4a309fd00cd7["SavedNetwork"] {
<<struct>>
}
class tc583422c7f0f["NearbyWifiNetwork"] {
<<struct>>
}
class tff9ef4d0d29e["LatencyStats"] {
<<struct>>
}
class t2488d1629c51["SpeedSample"] {
<<struct>>
}
class t60189b23c9ad["BluetoothDevice"] {
<<struct>>
}
class t28065228e336["BluetoothSnapshot"] {
<<struct>>
}
class t6f2d7c0133a5["BluetoothScanResult"] {
<<struct>>
}
class tcd996a2f6785["RingHistory"] {
RingHistory()
push()
clear()
size()
}
class tba04fe8b8282["NetworkService"] {
initialize()
shutdown()
snapshot()
savedNetworks()
}
Les bases non résolues restent identifiées; les signatures complètes ne sont pas reconstruites.
10. Référence
25 / 25 fichiers admissibles lus (51 dans l’arbre); 0 trop volumineux, 0 échec de lecture et 3 diagnostic de syntaxe.
Ce que couvre l’analyse
Les dossiers connus de dépendances et de compilation, les fichiers d’identifiants et les binaires sont exclus. La collecte couvre les README, les manifestes reconnus et les fichiers source pris en charge.
Les statistiques Linguist couvrent l’ensemble du dépôt et peuvent inclure d’autres langages.
12. Fichiers à lire 3
13. Glossaire
Dépôt
Les fichiers source, la configuration et l’historique versionné d’un projet.
README
Le document d’entrée du dépôt, qui présente généralement son rôle et son installation.
Dépendance
Une bibliothèque, un outil ou un service nécessaire à la compilation ou à l’exécution d’un composant.
HTTP
Un protocole de requête et réponse utilisé par les navigateurs et services web. Une requête comprend une méthode, un chemin, des en-têtes et parfois un corps.
Port publié
Un port de l’hôte associé au port d’un service dans un conteneur. Sa publication peut rendre le service accessible hors du réseau des conteneurs.
Compilation
Les étapes qui transforment les sources et dépendances en programme exécutable ou en livrable distribuable.
14. Références
- antoinebou12. (2026, 5 novembre). switch-wifi. [Software repository] github.com.
- antoinebou12. (2026, 5 novembre). switch-wifi: README. [Repository documentation] github.com.
- antoinebou12. (2026, 5 novembre). CMakeLists.txt. [Source file] github.com.
- antoinebou12. (2026, 5 novembre). src/core/metrics.cpp. [Source file] github.com.
- antoinebou12. (2026, 5 novembre). src/main.cpp. [Source file] github.com.
- Boucher, A. (2026, 23 octobre). switch-wifi : Séparer les mesures réseau de l’interface. [Project article] antoineboucher.info.
Les sources sans date de publication indiquent la date de leur dernière vérification, le 5 novembre 2026. Les liens des fichiers conservent la révision inspectée lorsqu’elle est disponible.