จะเขียน web แบบใช้ WebAssembly ไปเลยได้ไหม ?

ผมว่ามันทำได้ crate นี้เขาเรียก alert ของ JS จาก Rust ได้เลย แล้ว target เป็น WebAssembly ด้วย มี demo ให้ดูด้วย เรียก alert ได้เรียกอย่างอื่นก็น่าจะได้

อีกโครงการหนึ่ง stdweb เขาจัดการเรื่อง interop ให้ Rust ไปเรียก function ของ JavaScript ได้ เช่น สั่ง:


document().query_selector(...)


ใน Rust ได้เลย แต่ดูเหมือน target ยังเป็น asm.js อยู่ แต่ต่อไปจะทำเป็น WebAssembly แทนก็คงจะได้

ถ้าสมมุติว่าเขียน web แล้วต้องมา align protein sequence บน web browser กันเลย หรือคำนวณอะไรอย่างอื่นหนัก ๆ compiler มาเป็น WebAssembly มันก็คงเร็วขึ้น แต่ถ้าแค่เอามา regular expression มา check ว่าเบอร์โทรศัพท์ที่กรอกในฟอร์มถูกหรือเปล่า ใช้ WebAssembly ไปว่าก็ไม่น่าจะมีประโยชน์ ดีไม่ดีจะช้าลงด้วยหรือเปล่าก็ไม่ทราบ

เทียบ WebAssembly กับ Java Bytecode แบบงู ๆ ปลา ๆ

ทั้ง WebAssembly และ Java Bytecode มันเสมือนทำงานบน stack machine ไม่มี resister เหมือน MIPS 8088 หรือ PIC 16F84 เอาจริง ๆ CPU หรือ MCU ที่ผมเคยใช้ เคยอ่านมาก็มี register หมด

คำสั่งมันก็คล้าย ๆ CPU โดยเฉพาะพวก MIPS และสาย MCU แต่ว่ามันไม่มี register มีคำสั่งพวก load store compare branch (ประมาณ if) มีบวกลบคูณหาร ฯลฯ คล้าย ๆ กันทั้ง wasm และ Java Bytecode

สิ่งที่ดูคร่าว ๆ แล้วต่างกันคือเรื่อง memory ของ Java bytecode มีคำสั่งมาสร้าง array สร้าง object เลย คือแบบ high-level มาก ๆ แล้วก็น่าจะผูกมัดกับภาษาด้วย ก็แหงเพราะเขาทำมาให้ใช้ Java ส่วนของ wasm นี้ไม่มีแม้กระทั่งคำสั่งที่ตรงกับ malloc ในภาษา C แต่ก็ใช่ว่าจะไม่มีอะไรเลย มี grow_memory ที่ท่านว่าคล้าย ๆ sbrk ของ unix-like ผมลองเปิด code ของ NetBSD ดู ใน malloc มันไปเรียก sbrk อีกที

Web Assembly ใช้ JIT ได้ไหม ?

วันนี้อ่านเรื่อง Silverlight ที่อจก.เขียนแล้วก็มานึกถึง Web Assembly ผมคิดว่า WASM ตอนแปลงเป็น machine code นี่มันต้องเป็น AOT อย่างเดียว หรือเปล่าจะเป็น JIT ได้ไหม ?

ผมก็เดาเอาว่าน่าจะเป็น JIT + Hotspot แบบที่ JVM ทำได้ เพราะว่า JVM ก็ใช้ bytecode ก็เป็นแบบที่ระบุ type มาเหมือนกัน มันยังมีประเด็นอื่น ๆ ให้ optimize อีกนอกจากเรื่องมาเดา type ว่าเป็น type อะไรแบบที่ทำกับพวกภาษา dynamic

พอคิดถึง Android แต่ก่อน Dalvik ก็ใช้ JIT แล้วพอมาถึงช่วง Android 4.4 ถึง 5 ก็เปลี่ยนมาใช้ ART ที่เป็น AOT พอมา Android 7 ก็เอา JIT มาใส่ ART อีก ก็เลยคิดว่ามันก็น่าจะมีเหตุผลที่จะเอา JIT มาใช้เหมือนกันต่อให้ใช้ AOT ด้วยก็ตาม มันน่าจะมีข้อมูลประกอบการ optimize มากขึ้นพอรันไปสักพัก

ป.ล. ไม่รู้จะมาคิดเรื่องนี้ทำไม
ป.ล. 2 ที่ผมพ่น ๆ มาก็น่าจะมั่วเป็นส่วนใหญ่ ถ้าผิดพลาดก็ขออภัย และช่วยชี้แนะด้วยครับ

Macro ใน Rust

C/C++ preprocesor อยู่ในระดับคำ (Lexical) แต่ Macro ของ Rust อยู่ในกลุ่มเดียวกับภาษา Lisp อยู่ในระดับวากยสัมพันธ์ (syntax) [1] คือสามารถเปลี่ยนแปลง abstrct syntax tree ของ source code ได้เลย โดยที่เขียน pattern ไป match tree แต่ละแบบแล้วให้สร้าง source code ออกมา [2]

ประมาณว่าเราเพิ่ม syntax ใหม่ ๆ เข้าไปในภาษาได้ระดับหนึ่ง

ยกตัวอย่างเช่น เวลาสร้าง HashMap หน้าตา code จะประมาณนี้

let mut h = HashMap::new();
h.insert("cat", "แมว");
h.insert("dog", "หมา");
h.insert("rat", "หนู");

แต่ว่าอยากจะเขียน macro มาทำให้ syntax คล้าย ๆ Ruby ก็ได้ ซึ่งพอเขียนแล้วทำแบบนี้ได้เลย

let h = hashmap!{"cat" => "แมว", "dog" => "หมา", "rat" => "หนู"}

แต่ว่าเขียนอยู่ไรก็ดูตาม [2] และ [3] ได้ครับ
[1] https://en.wikipedia.org/w/index.php?title=Macro_(computer_science)&oldid=791385647

[2] https://doc.rust-lang.org/book/first-edition/macros.html

[3] https://github.com/bluss/maplit

คมชัดดีเหลือเกิน

OsString

ช่วงสัปดาห์ก่อนเจอประเด็นเรื่อง character encoding ของชื่อไฟล์บน Windows มา ประมาณว่าไฟล์ส่งมาจาก GNU/Linux ดี ๆ แต่เอามาลง Windows แล้วกลายเป็นตัวแปลก ๆ โดยเฉพาะบน Python 3.6 ที่อ่านเจอจาก นเรศ เก็จรัมย์ นอกจากนั้นก็ลอง app บน Windows ก็เจอแบบที่ใช้ได้บ้างไม่ได้บ้าง

ทีแรกผมก็นึกว่า Windows เก่า ๆ มันอาจจะไม่รองรับ Unicode เลย แต่ไปอ่านดูมันก็รับเหมือนกันแต่ว่ามีทั้ง API เก่าใหม่ แบบเก่าเข้าใจว่าเป็น ANSI แบบใหม่เป็น UTF-16

ส่วนของ GNU/Linux ใช้ UTF-8 ซะงั้น

ทำให้เพิ่งนึกได้ว่า stdlib ของ Rust จะมี OsString ไปทำอะไร

https://doc.rust-lang.org/std/ffi/struct.OsString.html

threadpool ใน Rust แบบจำกัดขนาด job queue

ปกติเวลาใช้ threadpool มันจะเอา job ใส่ queue ไปเรื่อย ๆ เลย สมมุติว่าสัก 10 ล้าน job แล้วแต่ละ job มันทำงานช้า queue มันก็อาจจะกลายเป็นว่า queue ที่ใช้ channel มาทำมันใช้ memory เยอะเพราะมี job คาอยู่ใน channel เพียบเลย

 

extern crate threadpool;

use threadpool::ThreadPool;
use std::time::Duration;

fn main() {
    let pool = ThreadPool::new(3);
    
    for i in 0..100 {
        println!("Enqueue: {}", i);
        pool.execute(move|| {
            std::thread::sleep(Duration::from_millis(1000));
            println!("Dequeue: {}", i);
        });
    }
    pool.join();
}

ถ้าเขียน code ด้านบนมันจะ enqueue 0 ถึง 99 จนครบเลย แล้วค่อย dequeue ออกมาดังนั้น channel ก็จะกิน memory ตามนั้น แต่ผมไม่อยากได้แบบนี้ ผมอยากให้แบบพอใส่ไป สัก 0..5 แล้วก็ให้หยุดใส่ก่อน จะได้ไม่กิน memory มาก ก็เลยไปโมให้ pool.execute มัน block หรือหยุดก่อนเวลา queue มีขนาดประมาณหนึ่ง ซึ่งก็แก้ตาม commit/changeset นี้ หลัก ๆ ก็คือไปเปลี่ยน channel เป็น sync_channel แทน

พอแก้เสร็จเสร็จแล้วรันโปรแกรมอีกทีก็จะเห็น enqueue ประมาณ 3 (ยกเว้นตอนเริ่ม) ครั้ง กับ dequeue ประมาณ 3 ครั้งสลับกันไปประมาณ

จริง ๆ ผมก็ไม่แน่ใจว่าทำแบบนี้ดีหรือเปล่า ก็เลยมาเขียน blog เล่าให้ฟังถ้าหากมีอะไรเพิ่มเติมโปรดชี้แนะด้วยครับ

สิ่งที่ฟังสมัยวัยรุ่น

ส่วนมากคนรุ่นราวคราวเดียวกับผมก็มักจะรู้จักเพลงแกรมมี่ อาร์เอส ผมก็รู้จักเหมือนกัน แต่ก็มีบางส่วนที่หาย ๆ ไป บางคนอาจจะสงสัยว่าไปอยู่ไหนมา อยู่บ้านฟังอะไร ไปอยู่ต่างประเทศมาหรือเปล่า ส่วนหนึ่งของคำตอบก็คือนี่ล่ะครับ ฟังเทปการแสดงสดของคณะเพชรพิณทอง

 

ภาษาโปรแกรมสำหรับเขียนลงกระดาษเวลาสอบ

ช่วงนี้มีดราม่าเรื่องทำไมต้องเขียนโปรแกรมลงกระดาษด้วย ซึ่งผมยังไม่ได้อ่านรายละเอียดและไม่มีแผนจะอ่านรายละเอียด (แต่ไม่แน่ว่าง ๆ ก็อาจจะอ่าน)

• ถ้าเป็นผมก็คงไม่ค่อยอยากเขียน:
  Java แบบมี getter/setter เยอะ ๆ ในกระดาษเหมือนกัน
• หรือว่าเขียนคำว่า function ซึ่งยาว
• return มันยาว ๆ
• ใส่ $ หน้าตัวแปรทุกครั้ง
• ต้องใส่ type ทุกครั้งเช่น Array<Tuple<Integer, String>> ซึ่งก็ยาวเหมือนกัน
• จับคู่วงเล็บ ไม่ว่าจะป็นแบบ ((( ))) หรือ { { { } } } หรือ ({ })
• ไม่ต้องมาใส่ end แทนวงเล็บ
• ใส่ ;

ดังนั้นถ้าจะเขียนโปรแกรมในกระดาษมันไม่ควรจะมีที่ว่ามาข้างบน ก็เลยลองเอาภาษาที่อยู่ใน Redmonk rank มาไล่ดู

1. JavaScript ตกไปโดนไป 3-4 ข้อ
2. Java โดนไป 5 ข้อ
3. Python โดนข้อ return ไป 1 ข้อ
4. C# โดนไป 3-4 ข้อ
5. C++ แบบใหม่ ๆ หน่อย 3-4 ข้อ
6. Ruby โดนไป 1 ข้อเรื่อง end
7. C แน่นอน 4 ข้อ
8. Objective-C เหมือน C
9. Scala โดนไปประมาณ 1-2 ข้อ
10. Shell เข้าใจว่าคือ Bash โดนไป 3 ข้อ
11. Swift น่าจะประมาณ 3-4 ข้อ
12. R โดนไป 2 ข้อ
13. Go โดนไป 3-4 ข้อ
14. Perl โดนไป 4 ข้อ
15. TypeScript ก็ไม่ได้ดีกว่า JS
16. PowerShell ก็คล้าย Shell
17. Haskell ผ่านทุกข้อไม่โดนหักคะแนนเลย
18. Clojure โดนหักวงเว็บ
19. CoffeeScript ผ่านทุกข้อ

ภาษาที่ผ่านเกณฑ์ก็มี Haskell กับ CoffeeScript แต่ก็อาจจะรู้สึกว่า Haskell, monad กับ pure function เป็นประเด็นให้ไม่อยากเขียน Haskell ได้  CoffeeScript อาจจะมีความซับซ้อนของ JS มากเกินไป ภาษาที่แบบไม่ค่อยนิยม จริง ๆ ไม่รู้ว่ามีใครเขียนหรือเปล่า เช่น Scheme + WISP [implementation] ก็น่าดี

รีวิว Nokia 3

As a consumer and a fanboy

ผมใช้มาได้ประมาณ 30 ชั่วโมงก็จะรีวิวเลย เพราะว่าถ้านานกว่านี้ก็อาจจะไม่ต้องรีวิวละ

มาจาก TG Fone ที่เดอะมอลล์บางปิราคา 4850 บาท ลองจับ ๆ ดู Nokia 5 มันน่าใช้กว่าอีก แต่ว่า Nokia 3 มันสีขาวและเบา ๆ ดีก็เลย Nokia 3 ก็ได้

• หน้าตาทำให้ระลึกถึง Sony Xperia M แต่ว่าอย่างน้อยก็ดีว่าปุ่ม home ปุ่ม back แยกออกมาจากจอ
• จอ 5 นิ้วแต่ออกไปทางยาว ๆ ไม่ค่อยชอบเท่าไหร่ เพราะมันกลายเป็นยังคับให้ keyboard แคบบไปด้วย
• การใช้ WiFi ในห้องน้ำซึ่งห่างจาก Access point โทรศัพท์ที่ใช้ล่าสุด 5 เครื่อง มี 2 เครื่องมีปัญหา แต่ Nokia 3 ผ่านสบาย
• Touchscreen ไม่รวน กดแล้วก็ตอบสนองพอได้
• ใช้มาประมาณ 26 ชั่วโมงโดยไม่ restart เลยก็ยังไม่มีอาการค้าง
• ความเร็วพอใช้ Facebook Twitter ได้ แต่เวลาใช้ Facebook บางทีก็รู้สึกหน่วง ๆ
• กล้อง: มี Auto focus แต่ภาพออกมาแล้วรวม ๆ ก็คือผมไม่ชอบ ถ้าคิดว่าจะเอามาเป็นกล้องหลักและมีงบผมว่าก็น่าจะเอารุ่นอื่น
  
• ลำโพงผมรู้สึกว่าไม่ได้ถึงกับเสียงดี แต่ชอบการออกแบบที่เอาลำโพงมาไว้ข้าง port micro USB ทำเปิดเพลงได้โดยไม่ต้องวางโทรศัพท์ด้วยท่ายาก
  
• จับถือรู้สึกไม่ค่อยถนัดเท่าไหร่ ถ้าเทียบกับ Lumia 630 แล้ว Lumia 630 รู้สึกดีกว่า แต่ก็พอจับได้อยู่
• GPS ผมลองเปิด Google Maps มาก็ขึ้นเลยไม่ได้ช้าอะไร แต่สำหรับจับโปเกม่อนผมไม่แน่ใจว่าจะไหวไหม
• มี NFC ด้วย แต่ว่ากล้องที่ผมใช้ก็ดันไม่มี NFC ก็เลยยังไม่ได้ใช้ประโยชน์อะไร
• เสียงสนทนาชัดเจนดี
• แบตก็รู้สึกงั้น ๆ นะไม่ได้ใหญ่ แต่ก็ไม่ได้หมดเร็วผิดปกติ

โดยสรุปผมคิดว่าสำหรับผมก็พอใช้แล้ว touchscreen ไม่ลั่นไปกด angry ให้เองโดยที่ผมไม่ได้กดอะไรเลย WiFi ใช้ได้ทั่วบ้าน  กล้องนี้ผมไม่ได้ใช้เป็นกล้องหลักอยู่แล้วถ่ายได้แค่นี้ก็พอทน

View original post