-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
658 lines (370 loc) · 18.3 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
<!DOCTYPE html>
<html>
<head>
<title>Title</title>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="shortcut icon" href="favicon.svg" />
</head>
<body>
<script src="remark-latest.min.js"></script>
<textarea id="source">
class: center, middle
# Portage Python sur Webassembly
## 2023/02/18, 11:00
## Slides : [Pour quoi, pour qui](https://docs.google.com/presentation/d/1vzk1gcDIIxZgHY-YC4WNH6PdphM1pcPVGBsY8EdUDA8)
## Live Démos :[Comment ?](#2)
[top]: #1
[home]: #2
???
#2
---
Outils utilisés:
Hôte (laptop) : Chromium Appimage, python3.8+ module http.server (stdlib) et websockify
Invité (wasm) : libpython 3.11.1 + pygbag 0.7 (git)
1. Ce qu'il ne faut pas faire : [fibonnacci](#3)
1. Ce qu'il faut éviter : [Le html](#4)
1. Les Terminaux : [vt100/vt420](#6)
1. Les Jeux dans le terminal : [Tetris](#7)
1. Les Jeux avec pygame : [Penguins can't fly](#8)
1. IoT : l'internet des objets connectés [test_iot](#9) : requiert esp8266 + moteur pas à pas + localhost
1. 3D avec Harfang : [Cube simple](#10) : requiert WebGL
1. IoT+3D == [Téléprésence Robotique](#11) : requiert esp8266 + moteur pas à pas + localhost
1 [la même mais sans iot et webcam simulée](demo-arm-robot/build/web/)
[TOP][top]
???
#3
---
Le classique :
```python
def fibonacci_of(n):
if n in {0, 1}:
return n
return fibonacci_of(n - 1) + fibonacci_of(n - 2)
```
ne fonctionnera pas correctement.
il faut rendre la main à l'OS !
On pourait pu utiliser des itérateurs mais async/await fait tres bien l'affaire
[`<`url`>`/python.html?-i#live/fib/recursive_yield.py](python.html?-i#live/fib/recursive_yield.py)
???
#4
---
HTML
Bien sûr il faut en parler, car tout le monde est tenté au 1er abord de faire du
web dans un navigateur côté client. C'est tout à fait possible et même assez simple.
Toutefois sur le court terme - à mon avis - il n'y a que peu
de domaines d'application réalistes.
Un usage intermédiaire comme l'inclusion est + souhaitable, par exemple
[pour de la documentation](live/embedding.html)
liée à l'utilisation de python ou d'un de ses modules.
[RETOUR INDEX][home]
???
#5
---
embedding
Si le but est un document interactif et ressemble même vaguement à un cahier scientifique :
Utilisez JupyterLite ou basthon. Leur moteur - pyodide - est fait pour celà.
Vous faites une application accessible ou multilingues avec scripts complexes ?
Dans ce cas oui utilisez python+web et :
- publiez des modules pour amméliorer ce type d'applications
- militez pour qu'il fonctionnent aussi correctement avec pyscript/Brython/Skulpt.
Mais attention : pas de hâte !
l'interfaçage avec le contenu web (DOM) n'est pas encore normalisé
entre les différents exécuteurs python sur le web !
Le temps est à la concertation.
[RETOUR INDEX][home]
???
#6
---
## Terminaux
### python-script :
[`<`url`>`/live/terminal-stdio.html?-i](live/terminal-stdio.html?-i)
```terminal
python3 -x live/terminal-stdio.html
```
### python-app :
REPL:
[`<`url`>`/python.html?-i](python.html?-i)
Ligne de commande :
[`<`url`>`/python.html?-i#live/terminal-stdio/terminal-stdio-argv.py](vt.html?-i#live/terminal-stdio/terminal-stdio-argv.py)
[RETOUR INDEX][home]
???
#7
---
Içi on utilise une librairie de rendu vt100 asynchrone, appelée nurses_2
[`<`url`>`/python.html?-i#live/tetris_main.py](vt.html?-i#live/tetris_main.py)
[RETOUR INDEX][home]
???
#8
---
En utilisant pygame-ce il est tres facile de faire des jeux à présenter
directement dans le navigateur.
Très facile à héberger chez itch.io ou github.io
[Exemple de package Pygbag](live/packaged_game)
Ce jeux est un portage et il y a un bug dans la gestion des scores.
Regardons de plus près comment çela se déroule et comment corriger le stockage
des scores.
[PenguinsCantFly_main.py](2d.html?#live/PenguinsCantFly_main.py)
[RETOUR INDEX][home]
???
#9
---
[test_iot.py](python.html?-i#live/test_iot.py)
[RETOUR INDEX][home]
???
#10
---
[HG3D Cube](live/harfang_cube.html)
[RETOUR INDEX][home]
???
#11
---
[telepresence-robot-arm.py](3d.html#live/telepresence-robot-arm.py)
[RETOUR INDEX][home]
---
class: center, middle
[présentation](https://docs.google.com/presentation/d/1vzk1gcDIIxZgHY-YC4WNH6PdphM1pcPVGBsY8EdUDA8/edit)
# Notes : à la suite
---
Pour quoi ? Pour des applications polyvalentes et très dynamiques.
- vt100 / vt420 : fontes à chasse fixe.
Mais moderne avec support d'unicode, d'image sixel
et de liens que l'on peut cliquer
- traitement de données avec des ressources distantes
ou via socket pour les base de données + traditionnelles
- Applications 2D : framebuffer:plein écran, fenêtrée: X11/Wayland/natif.
accélération matérielle : SIMD/NEON
- Applications 3D/VR/Compute.
accélération matérielle : GL/GLES/Vulkan/Metal OpenCL/CUDA
interface : EGL/GLX/DirectX/Metal 1 & 2
- Applications accédant aux capteurs matériels
audio/gyro/accel/touch/usb/série/gestion energie.
accès aux bus : usb / i2c / spi etc
- Applications désirant fournir des couches d'accessibilité fiables.
intentionnellement pas de Web dans cette liste :
Si vous avez une app en django/flask/quart ou d'autre outils web ne changez
rien WebAssembly ne va probablement pas révolutionner votre univers.
WebAssembly est pratique pour tout sauf pour faire du frontend Web.
---
# Pour qui ? des utilisateurs variés sur des machines qui le sont encore plus.
- Windows : pas de vt100/420 ni de serveur X, pas toujours unicode.
- systeme de types unix : pas de vt420, pas toujours unicode.
- mac : pas toujours de serveurs X
- couches 3D hétéroclites : opengl / gles / vulkan / directX / metal.
- système kiosques : tres hétérogènes et souvent tres restreint.
- ultraportables/webos : difficultés pour lancer Python, se le procurer ou l’adapter aux besoins.
Cas d'android ou il est difficile de lancer une application 100% python sans passer par une application tierce
difficulté pour installer ( side-loading ) des applications métiers qui ne respecteraient pas les conditions d'utilisation d'un "store"
conditions qui changent au fil du temps ou voire même oblige a changer de matériel.
---
- dans tous les cas des versions hétéroclites de Python et un support tierce partie souvent incomplet
ou qui lag derrriere les changement d'OS comme sur mac.
- peut etre une impossiblité d'installer ou d'éxécuter une application avec les simples droits d'utilisateur
- et souvent des couches d'accessibilité négligées ou non standardisées.
[ une mention spéciale pour certains environnements bardés d'antivirus qui génèrent des faux positifs sur beaucoup d'applications opensource.
ou "maison" faites avec pyinstaller par exemple. Le cas est récurrent dans les "game jam" ou dans les dépendances binaires de Python. ]
---
# Le Cauchemar du portage:
- problème du portage natif : la méthode difficile est trop difficile ...
- Solutions ?
---
## Le Cauchemar du portage:
### problème du portage natif : la méthode difficile est trop difficile ...
- trouver et redistribuer des terminaux vt420 pour toutes les plateformes.
mintty / mlterm / mac?
- utiliser uniquement des dénominateurs communs ?
à toutes les platformes graphiques :
DirectFB : trop bas niveau.
SDL1, car SDL2 a fait des compromis et le framebuffer/rendu logiciel n'est plus aussi bien supporté qu'avant.
et pour tous les capteurs plyer https://github.com/kivy/plyer#supported-apis )
[ IMAGE PLYER ]
NB: le meilleur support de plyer est pour une plateforme non supportée par Python !
- maintenir des binaires pour toutes les combinaisons hardware+software/os
win32/win64/winarm, android x4, GNU/Linux 32/64 x4, ios, macos
- ou trouver une couche d'accessibilité pour un linux embarqué sans passer par android ?
Treize à la douzaine à multiplier par le nombre de version de Python ... (NxM)
---
# Le Cauchemar du portage: Solutions ?
le problème ne date pas d'hier ! https://en.wikipedia.org/wiki/UNCOL#cite_note-2
S'écarter des solutions natives semblerait être la solution :
mais il faut un bon compromis simplicité/performance/sécurité.
on ne peut avoir les 3 en même temps donc quel argument de vente choisir ?
Si l'idée ne date pas d'hier pourquoi on a pas de solutions existantes ?
--
en fait il y en a:
au fil du temps, il y a eu de nombreuses machines virtuelles offrant un niveau d’abstraction pour des langages de haut niveau
Mais elles ont dévoyé et plus ou moins essayé d’imposer un langage …
et/ou des api natives pour les taches courantes : api dures, voire impossible à porter.
pascal : UCSD Pascaln, en 1977 utilisait du bytecode appelé "p-code".
Merci wikipedia sinon je n'en aurais jamais entendu parler.
perl : 1987 - bon début - mais problème à faire adopter la version 6 vers la fin
qui pourtant est une implémentation assez valable du concept et appelée parrot
python : 1991 pas encombrant (à l'époque) , pas de sécurité pour maximiser les performances
-> OS dépendant pour plein d'éléments ( X11/Tk, api win32, différences de libc ... )
ruby : assez similaire.
java : 1995
- implémentations concurrentes
- Gestion de la mémoire déconcertante.
- souvent des performances au détriment de la sécurité avec jni
malgré de nombreux frontends jython/jruby/quercus(php)
la mayonnaise ne prend pas et probablement problème de license(s)
llvm-ir 2000:
n'est pas utilisable par les humains, seulement les compilateurs
N'a meme pas une machine virtuelle soignée/portable.
en 2016 le perroquet n'etait pas mort, même si finalement en 2019 Perl 6 semble l'être*.
Probablement faute de compilateurs.
* devenu Raku sur MoarVM
--
et même des tentatives "universelles" (en apparence) sur le web :
--
la + connue :
plugin_flash.gif
--
la + ouverte :
plugin_java.jpg
--
qui pour l'utilisateur se résument souvent à :
plugin_none.png
--
[ apparté ]
Si on étudie au cas par cas il semblerait que la partie compilateur soit la
plus complexe à gérer. Peut être le problème a-t-il été abordé dans le mauvais sens ?
[ reprenons l'histoire ]
nodejs 2009 : "v8" pas mal, le seul probleme de taille c'est qu'il ne comprend que le javascript ...
asm.js 2013 : on prend le dénominateur commun de quasi tout le monde : le C
Et on le fait cibler une vm universelle bien moins complexe que llvm : un vm qui tourne même dans nodejs
implémentée au sein même du langage javascript. Elle profite des puissants moteurs JIT développés à grand frais
pour accélérer javascript.
ouf enfin autre chose que du javascript donc même si c'est de l'assembleur autant lui donner une chance ...
De toute façons le code javascript "minifié" ressemblait déjà à de l'assembleur !
Ceci constitue un modèle viable et en preuve de concept au lieu de Doom il fait tourner un clone de quake3* en réseau.
* BananaBread Cube 2: Sauerbraten engine
Et dans Firefox il est plutôt rapide même si le navigateur a discrètement été optimisé pour.
WebAssembly 2015 : C/C++/rust compilent sans problème pour une machine virtuelle.
Machine qui elle même est tres facile à compiler partout ou un compilateur C a vu le jour.
Genre 5 minutes sur la WII qui est pourtant powerpc/big-endian.
CloudABI (Ed Schouten) ** qui résume les points communs des OS à une cinquante d'appel système
donne indirectement naissance à WASI ( WebAssembly System Interface )
---
La machine virtuelle sera partout grâce à W3C en 2019 !
Pourquoi wasm a gagné ?
Sécurité et simplicité
- Le 1er argument de vente choisi est idéal et c'est la sécurité !
- WebAssembly est composé d’un microprocesseur simple : pas de registres, pas de goto == nombreux problèmes de sécurité réglés : c'est un vrai bac à sable.
WebAssembly n'a pas de registres, et pas de goto. problème réglé c'est un vrai bac à sable.
Cerise sur le gateau les performances ne sont pas mauvaises.
Sur certaines architectures on peut même transformer le code machine wasm en code natif ( AOT )
Certain aspect du design sacrifie l'encombrement pour obtenir + de simplicité mais
à l'ère de la fibre optique et des gigaoctets de ram dans les mobiles :
l'encombrement ne semble plus un si grand problème.
L'autre point fort : c'est juste un standard (MVP 1.0) que tout monde peut implémenter ou il veut, comme il veut. Pas de problème de license.
Et il n'est pas si compliqué ( tout l'opposé de llvm-ir ou jvm ) : le coût de maintenance devient très faible et il y a une sérieuse batterie de tests.
Et surtout les GAFAM en ont besoin sur le web [.]
---
Mais même les PME/TPE en ont besoin:
---
---
FRA
---
CHECK TIME
---
-------- FACULTATIF --------------
Pendant ce temps du coté portabilité Python il y a eu ...
comme personne ne voulait sacrifier les performances ...
---
## La méthode "force brute" : docker
sécurité pas forcément au point ...
---
## Les méthodes classiques ( à tendance lourde).
PyQt : super, mais problème de license.
Kivy : super, mais installation d'un python complet et d'une pile de librairies pour chaque app.
Electron+flask : installation d'un browser complet pour chaque app, afin de résoudre les problemes de GUI.
sécurité - vraiment - discutable même si code source fourni ( eg supply chain attack ).
-------- /FACULTATIF --------------
---
# Simplifier l'accès aux applications via WebAssembly.
Et si on pouvait utiliser un python complet ( comme fait kivy ) ? Mais commun
à toutes les applications.
utiliser la VM d'un navigateur deja installée et entretenue par le vendeur ?
De quoi avoir un OS avec une compatiblité constante au fil du temps.
---
## Le navigateur internet : vers une machine virtuelle universelle ?
Le navigateur EST une machine virtuelle :
asm.js : poc, lent. Mais plus besoin de coder en javascript !
aujourd'hui remplacé par WebAssembly : à peine 2x moins rapide que natif.
on y a bien Terminaux, 2D (canvas, framebuffers) / 3D (WebGL, WebGPU ) / Audio (in/out)
Le navigateur a un accès universel à presque tout les capteurs !
ramener à nouveau le tableau de plyer, ajouter colonne support navigateur/javascript.
et une très bonne couche d'accessibilité.
---
| Feature | Telemetrix | StandardFirmata |
|-------|:----------:|:-----------------:|
| Entrée analogique (DAC) | X | X |
| Sortie analogique (PWM) | X | X |
| Entrée Numérique | X | X |
| Sortie Numérique | X | X |
| Servo Moteurs | X | X |
| Motor Pas à Pas | X | |
| Capteurs Temperature/Humidité (DHT) | X | |
| Télémètre ultrasonique HC-SR04 | X | |
| bus SPI | X | |
| bus OneWire | X | |
| bus i2c | X | X |
| Client Python Asyncio Inclu | X |
| Support For STM32 Boards (Black Pill)| X |
| Extensions utilisateurs | X | |
| Debugger | X | |
| Documentation pour tout | X | |
---
## pygbag: test serveur local + hello world avec input
async.png
## pygbag: fibonnaci: montrer que ça ne fonctionne plus
async-noblock.png
solution : sched_yield.
expliquer que la vm python pourrait corriger le probleme au lieu de forcer
a écrire du async/await partout (rant!)
SOUS RESERVE DE LA TECHNO WASI:
pygbag+xtermjs-sixel ( comme évolution/remplacement de la POC python-wasm de Ethan Smith )
pygbag+SDL2 : pygame ( comme évolution/remplacement de replit/kata.games )
un ou 2 jeux vite fait.
## packaging image , son ,
mais on peut aussi packager des modeles 3d et shaders :
FRA: demo possible du bras robot virtuel
BONUS:
pygbag+WebGL : Harfang3D une solution alternative au toolkits 3D en javascript et bien + portable.
pygbag sur mobile via debugger chromium ?
-> cable usb avec une tablette ou téléphone ( un qui pédale par contre le wasm est LENT à compil )
webusb : démontrer la possibilité d'un atelier technique en présentiel ?
-> websocket / telemetrix / retour par cam
faire démo opencv / AR en live ?
balancer un QR sur VPI pour expérience participative via mobile
( eg prog P2P ou système de vote pour questions réponses)
Revenir à la slide finale pour les questions
---
# Conclusion
## Super ça marche ! Mais ( car il y a toujours un mais ...)
Ne PAS faire la course à la nouveauté ( 64bits/threads/servicesworkers/webgpu/simd-neon)
=> coller à MVP.
Ne PAS pousser le hardware.
=> GLES 1/2 devrait suffire aux besoins.
Mettez au maximum votre app dans un module, et utilisez des imports relatifs.
Ne pas perdre son temps à obfusquer le code, annotez le pour le compiler + tard avec mypyc.
Programmer de façon éco-responsable sur du vieux matériel.
Privilégier l'accessibilité. Surtout sur mobile.
Car le but est d'amener toutes les applications, à tout le monde, partout.
---
Merci.
REF:
CLOUDABI :
https://youtu.be/3N29vrPoDv8
** CloudABI is based on the Capsicum lightweight OS capability and sandbox framework developed at the University of Cambridge Computer Laboratory.
Is WebAssembly the return of Java Applets & Flash? :
https://steveklabnik.com/writing/is-webassembly-the-return-of-java-applets-flash
Accessiblité :
https://flet.dev/docs/guides/python/accessibility/
https://rmll.ubicast.tv/videos/comment-les-aveugles-jouent-ils/
How Blind People Play Videos Games : https://www.youtube.com/watch?v=PJ1yiHkEL5c
</textarea>
</body>
<script defer>var slideshow = remark.create();</script>
</html>