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.
- {typeseg-0.2.5 → typeseg-0.2.7}/PKG-INFO +17 -3
- {typeseg-0.2.5 → typeseg-0.2.7}/README.md +16 -2
- {typeseg-0.2.5 → typeseg-0.2.7}/pyproject.toml +1 -1
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/PKG-INFO +17 -3
- {typeseg-0.2.5 → typeseg-0.2.7}/LICENSE +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/setup.cfg +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/tests/test_cupy_parity.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/tests/test_distribution.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/tests/test_postprocess_parity.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/tests/test_postprocess_perf.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/__init__.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/__main__.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_cli.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_color.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_cupy_backend.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_mamba_kernel.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_numpy_backend.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_onnx_backend.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_options.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_postprocess.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_runtime.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_segmentation.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/_tokenize.py +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/data/mamba_al.npz +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/data/mamba_al.onnx +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/data/manifest.json +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/data/unet_al.npz +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg/data/unet_al.onnx +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/SOURCES.txt +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/dependency_links.txt +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/entry_points.txt +0 -0
- {typeseg-0.2.5 → typeseg-0.2.7}/typeseg.egg-info/requires.txt +0 -0
- {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.
|
|
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
|
-
|
|
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** — ~
|
|
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
|
-
|
|
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** — ~
|
|
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.
|
|
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.
|
|
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
|
-
|
|
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** — ~
|
|
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
|
|
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
|
|
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
|