typeseg 0.2.5__tar.gz → 0.2.7__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (33) hide show
  1. {typeseg-0.2.5 → typeseg-0.2.7}/PKG-INFO +17 -3
  2. {typeseg-0.2.5 → typeseg-0.2.7}/README.md +16 -2
  3. {typeseg-0.2.5 → typeseg-0.2.7}/pyproject.toml +1 -1
  4. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/PKG-INFO +17 -3
  5. {typeseg-0.2.5 → typeseg-0.2.7}/LICENSE +0 -0
  6. {typeseg-0.2.5 → typeseg-0.2.7}/setup.cfg +0 -0
  7. {typeseg-0.2.5 → typeseg-0.2.7}/tests/test_cupy_parity.py +0 -0
  8. {typeseg-0.2.5 → typeseg-0.2.7}/tests/test_distribution.py +0 -0
  9. {typeseg-0.2.5 → typeseg-0.2.7}/tests/test_postprocess_parity.py +0 -0
  10. {typeseg-0.2.5 → typeseg-0.2.7}/tests/test_postprocess_perf.py +0 -0
  11. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/__init__.py +0 -0
  12. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/__main__.py +0 -0
  13. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_cli.py +0 -0
  14. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_color.py +0 -0
  15. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_cupy_backend.py +0 -0
  16. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_mamba_kernel.py +0 -0
  17. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_numpy_backend.py +0 -0
  18. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_onnx_backend.py +0 -0
  19. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_options.py +0 -0
  20. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_postprocess.py +0 -0
  21. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_runtime.py +0 -0
  22. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_segmentation.py +0 -0
  23. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_tokenize.py +0 -0
  24. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/data/mamba_al.npz +0 -0
  25. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/data/mamba_al.onnx +0 -0
  26. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/data/manifest.json +0 -0
  27. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/data/unet_al.npz +0 -0
  28. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/data/unet_al.onnx +0 -0
  29. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/SOURCES.txt +0 -0
  30. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/dependency_links.txt +0 -0
  31. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/entry_points.txt +0 -0
  32. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/requires.txt +0 -0
  33. {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/top_level.txt +0 -0
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: typeseg
3
- Version: 0.2.5
3
+ Version: 0.2.7
4
4
  Summary: Fine-grained, character-level content-type segmentation for textual inputs (U-Net + Mamba).
5
5
  Author: Martin Dallinger
6
6
  License-Expression: Apache-2.0
@@ -33,7 +33,9 @@ Dynamic: license-file
33
33
  `typeseg` labels every character position of a text with one of 35 content types
34
34
  (`html`, `css`, `javascript_typescript`, `python`, `powershell`, `encoding_base64`, …),
35
35
  recovering the internal structure of mixed, malformed, or convention-breaking inputs.
36
- The only runtime dependency is `numpy`.
36
+ Runtime dependencies are just `numpy` and `onnxruntime` — both pulled by `pip install
37
+ typeseg`, so the fast ONNX CPU backend works out of the box at arbitrary input length,
38
+ no GPU required. (A pure-numpy fallback also ships, used when onnxruntime is absent.)
37
39
 
38
40
  <p align="center">
39
41
  <img src="https://typeseg.martin-dallinger.me/images/llm_segmentation.png" alt="Correct model output on a heavily mangled HTML input with a hidden shell payload" width="460">
@@ -153,7 +155,7 @@ honestly.
153
155
 
154
156
  **Per-model device (auto).** The two models reach the GPU by different routes:
155
157
 
156
- - `fast()` (U-Net) runs on **onnxruntime-gpu** — ~3–4× faster on GPU; ~140k chars/s.
158
+ - `fast()` (U-Net) runs on **onnxruntime-gpu** — ~2× faster than CPU end-to-end; ~140k chars/s.
157
159
  - `precise()` (Mamba) runs its selective-scan through a **custom CUDA scan kernel**
158
160
  (a CuPy `RawKernel`, `cupy-cuda12x`), reaching ~58k tokens/s for the raw forward —
159
161
  edging out the research model's JAX `associative_scan` (54.9k tok/s). The selective-scan
@@ -210,6 +212,7 @@ typeseg.backend_info()
210
212
  # 'fast_providers': ['CUDAExecutionProvider', 'CPUExecutionProvider'],
211
213
  # 'precise_providers': ['CuPyCUDA:NVIDIA GeForce RTX 5070 Laptop GPU']}
212
214
 
215
+ text = "<div>hi</div>\n.btn { color: red; }\nalert('x');"
213
216
  typeseg.fast(text) # U-Net on onnxruntime-gpu (~140k chars/s)
214
217
  typeseg.precise(text) # Mamba on the CuPy scan (~58k tokens/s raw forward)
215
218
  ```
@@ -281,3 +284,14 @@ result = precise(text, raw)
281
284
 
282
285
  The trade-off is noisier segments (single-character runs, frayed boundaries); the
283
286
  default keeps post-processing on for cleaner, deployment-style output.
287
+
288
+ ## Acknowledgments
289
+
290
+ This work was carried out with extensive technical feedback from and many informative discussions with
291
+ Dr. Yanick Fratantonio and Dr. Luca Invernizzi from Google Security Research (authors of
292
+ [Magika](https://github.com/google/magika)), who also provided generous access to Google Cloud compute
293
+ resources. Gemini models were used to create and refine the dense segment annotations and to act as the
294
+ active-learning oracle. Thanks also go to Univ.-Prof. Stefan Rass (JKU Secure Systems Group) for his
295
+ guidance, especially regarding parsing and classical computer-science approaches. I am especially
296
+ grateful for his detailed feedback on the accompanying master's thesis and for him supporting this
297
+ academic collaboration.
@@ -10,7 +10,9 @@
10
10
  `typeseg` labels every character position of a text with one of 35 content types
11
11
  (`html`, `css`, `javascript_typescript`, `python`, `powershell`, `encoding_base64`, …),
12
12
  recovering the internal structure of mixed, malformed, or convention-breaking inputs.
13
- The only runtime dependency is `numpy`.
13
+ Runtime dependencies are just `numpy` and `onnxruntime` — both pulled by `pip install
14
+ typeseg`, so the fast ONNX CPU backend works out of the box at arbitrary input length,
15
+ no GPU required. (A pure-numpy fallback also ships, used when onnxruntime is absent.)
14
16
 
15
17
  <p align="center">
16
18
  <img src="https://typeseg.martin-dallinger.me/images/llm_segmentation.png" alt="Correct model output on a heavily mangled HTML input with a hidden shell payload" width="460">
@@ -130,7 +132,7 @@ honestly.
130
132
 
131
133
  **Per-model device (auto).** The two models reach the GPU by different routes:
132
134
 
133
- - `fast()` (U-Net) runs on **onnxruntime-gpu** — ~3–4× faster on GPU; ~140k chars/s.
135
+ - `fast()` (U-Net) runs on **onnxruntime-gpu** — ~2× faster than CPU end-to-end; ~140k chars/s.
134
136
  - `precise()` (Mamba) runs its selective-scan through a **custom CUDA scan kernel**
135
137
  (a CuPy `RawKernel`, `cupy-cuda12x`), reaching ~58k tokens/s for the raw forward —
136
138
  edging out the research model's JAX `associative_scan` (54.9k tok/s). The selective-scan
@@ -187,6 +189,7 @@ typeseg.backend_info()
187
189
  # 'fast_providers': ['CUDAExecutionProvider', 'CPUExecutionProvider'],
188
190
  # 'precise_providers': ['CuPyCUDA:NVIDIA GeForce RTX 5070 Laptop GPU']}
189
191
 
192
+ text = "<div>hi</div>\n.btn { color: red; }\nalert('x');"
190
193
  typeseg.fast(text) # U-Net on onnxruntime-gpu (~140k chars/s)
191
194
  typeseg.precise(text) # Mamba on the CuPy scan (~58k tokens/s raw forward)
192
195
  ```
@@ -258,3 +261,14 @@ result = precise(text, raw)
258
261
 
259
262
  The trade-off is noisier segments (single-character runs, frayed boundaries); the
260
263
  default keeps post-processing on for cleaner, deployment-style output.
264
+
265
+ ## Acknowledgments
266
+
267
+ This work was carried out with extensive technical feedback from and many informative discussions with
268
+ Dr. Yanick Fratantonio and Dr. Luca Invernizzi from Google Security Research (authors of
269
+ [Magika](https://github.com/google/magika)), who also provided generous access to Google Cloud compute
270
+ resources. Gemini models were used to create and refine the dense segment annotations and to act as the
271
+ active-learning oracle. Thanks also go to Univ.-Prof. Stefan Rass (JKU Secure Systems Group) for his
272
+ guidance, especially regarding parsing and classical computer-science approaches. I am especially
273
+ grateful for his detailed feedback on the accompanying master's thesis and for him supporting this
274
+ academic collaboration.
@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
4
4
 
5
5
  [project]
6
6
  name = "typeseg"
7
- version = "0.2.5"
7
+ version = "0.2.7"
8
8
  description = "Fine-grained, character-level content-type segmentation for textual inputs (U-Net + Mamba)."
9
9
  readme = "README.md"
10
10
  license = "Apache-2.0"
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: typeseg
3
- Version: 0.2.5
3
+ Version: 0.2.7
4
4
  Summary: Fine-grained, character-level content-type segmentation for textual inputs (U-Net + Mamba).
5
5
  Author: Martin Dallinger
6
6
  License-Expression: Apache-2.0
@@ -33,7 +33,9 @@ Dynamic: license-file
33
33
  `typeseg` labels every character position of a text with one of 35 content types
34
34
  (`html`, `css`, `javascript_typescript`, `python`, `powershell`, `encoding_base64`, …),
35
35
  recovering the internal structure of mixed, malformed, or convention-breaking inputs.
36
- The only runtime dependency is `numpy`.
36
+ Runtime dependencies are just `numpy` and `onnxruntime` — both pulled by `pip install
37
+ typeseg`, so the fast ONNX CPU backend works out of the box at arbitrary input length,
38
+ no GPU required. (A pure-numpy fallback also ships, used when onnxruntime is absent.)
37
39
 
38
40
  <p align="center">
39
41
  <img src="https://typeseg.martin-dallinger.me/images/llm_segmentation.png" alt="Correct model output on a heavily mangled HTML input with a hidden shell payload" width="460">
@@ -153,7 +155,7 @@ honestly.
153
155
 
154
156
  **Per-model device (auto).** The two models reach the GPU by different routes:
155
157
 
156
- - `fast()` (U-Net) runs on **onnxruntime-gpu** — ~3–4× faster on GPU; ~140k chars/s.
158
+ - `fast()` (U-Net) runs on **onnxruntime-gpu** — ~2× faster than CPU end-to-end; ~140k chars/s.
157
159
  - `precise()` (Mamba) runs its selective-scan through a **custom CUDA scan kernel**
158
160
  (a CuPy `RawKernel`, `cupy-cuda12x`), reaching ~58k tokens/s for the raw forward —
159
161
  edging out the research model's JAX `associative_scan` (54.9k tok/s). The selective-scan
@@ -210,6 +212,7 @@ typeseg.backend_info()
210
212
  # 'fast_providers': ['CUDAExecutionProvider', 'CPUExecutionProvider'],
211
213
  # 'precise_providers': ['CuPyCUDA:NVIDIA GeForce RTX 5070 Laptop GPU']}
212
214
 
215
+ text = "<div>hi</div>\n.btn { color: red; }\nalert('x');"
213
216
  typeseg.fast(text) # U-Net on onnxruntime-gpu (~140k chars/s)
214
217
  typeseg.precise(text) # Mamba on the CuPy scan (~58k tokens/s raw forward)
215
218
  ```
@@ -281,3 +284,14 @@ result = precise(text, raw)
281
284
 
282
285
  The trade-off is noisier segments (single-character runs, frayed boundaries); the
283
286
  default keeps post-processing on for cleaner, deployment-style output.
287
+
288
+ ## Acknowledgments
289
+
290
+ This work was carried out with extensive technical feedback from and many informative discussions with
291
+ Dr. Yanick Fratantonio and Dr. Luca Invernizzi from Google Security Research (authors of
292
+ [Magika](https://github.com/google/magika)), who also provided generous access to Google Cloud compute
293
+ resources. Gemini models were used to create and refine the dense segment annotations and to act as the
294
+ active-learning oracle. Thanks also go to Univ.-Prof. Stefan Rass (JKU Secure Systems Group) for his
295
+ guidance, especially regarding parsing and classical computer-science approaches. I am especially
296
+ grateful for his detailed feedback on the accompanying master's thesis and for him supporting this
297
+ academic collaboration.
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes