🔵 عنوان مقاله
Go's Support for Valgrind Instrumentation
🟢 خلاصه مقاله:
این مقاله درباره پشتیبانی آزمایشی Go از Valgrind است؛ چارچوبی که با ابزارهایی مانند Memcheck، Helgrind، DRD، Cachegrind، Callgrind و Massif برای پروفایلینگ و یافتن خطاهای حافظه و همزمانی به‌کار می‌رود. با این پشتیبانی، برنامه‌های Go می‌توانند به شکل عمیق‌تری پایش شوند—به‌ویژه در مرزهای cgo—و علاوه بر ابزارهای داخلی مانند pprof و race detector، گزینه‌های تشخیصی بیشتری در اختیار دارند. بااین‌حال، به دلیل سربار اجرایی بالا و ماهیت آزمایشی، نتایج ممکن است شامل خطا یا مثبت کاذب باشد و بهتر است با بیلدهای دیباگ و بارهای کاری کنترل‌شده استفاده شود. این قابلیت مکمل ابزارهای بومی Go است و جایگزین آن‌ها محسوب نمی‌شود.
#Go #Valgrind #Instrumentation #Profiling #MemoryLeaks #Concurrency #Performance #Debugging
🟣لینک مقاله:
https://golangweekly.com/link/174628/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Go's Support for Valgrind Instrumentation
🟢 خلاصه مقاله:
این مقاله درباره پشتیبانی آزمایشی Go از Valgrind است؛ چارچوبی که با ابزارهایی مانند Memcheck، Helgrind، DRD، Cachegrind، Callgrind و Massif برای پروفایلینگ و یافتن خطاهای حافظه و همزمانی به‌کار می‌رود. با این پشتیبانی، برنامه‌های Go می‌توانند به شکل عمیق‌تری پایش شوند—به‌ویژه در مرزهای cgo—و علاوه بر ابزارهای داخلی مانند pprof و race detector، گزینه‌های تشخیصی بیشتری در اختیار دارند. بااین‌حال، به دلیل سربار اجرایی بالا و ماهیت آزمایشی، نتایج ممکن است شامل خطا یا مثبت کاذب باشد و بهتر است با بیلدهای دیباگ و بارهای کاری کنترل‌شده استفاده شود. این قابلیت مکمل ابزارهای بومی Go است و جایگزین آن‌ها محسوب نمی‌شود.
#Go #Valgrind #Instrumentation #Profiling #MemoryLeaks #Concurrency #Performance #Debugging
🟣لینک مقاله:
https://golangweekly.com/link/174628/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
❤3
🔵 عنوان مقاله
How to Reproduce and Fix an I/O Data Race with Go and DTrace
🟢 خلاصه مقاله:
در این مقاله نویسنده با یک باگ مبهم روبه‌رو می‌شود که فقط در CI رخ می‌دهد: یک data race در سطح I/O فایل‌ها که باعث شکست گهگاه تست‌ها می‌شود. چون این رقابت در مرز فایل‌سیستم رخ می‌دهد و نه در حافظه مشترک، ابزار race detector در Go آن را تشخیص نمی‌دهد. برای بازتولید محلی، نویسنده شرایط شبیه CI را ایجاد می‌کند: اجرای تکراری تست‌ها، افزایش همزمانی، و ایجاد تنوع زمانی تا ترتیب‌های نادری که خطا را می‌سازند آشکار شوند. با استفاده از DTrace و رصد فراخوانی‌های سیستمی مانند open، write، fsync و rename، الگوی واقعی آشکار می‌شود: خواندن فایل همزمان با نوشتن/حذف جزئی یا قبل از تحویل اتمی محتوا.
راهکار با اتمی‌سازی و هماهنگ‌سازی است: نوشتن در فایل موقت و سپس os.Rename برای تحویل اتمی، افزودن fsync در نقاط لازم، و در صورت نیاز قفل/کانال برای سریال‌سازی دسترسی به مسیرهای مشترک. در تست‌ها نیز از t.TempDir() برای جداسازی حالت، پرهیز از تکیه بر mtime، و اتکا به سیگنال‌های قطعی به‌جای تأخیرهای زمانی استفاده می‌شود. نتیجه، حذف flaky بودن در CI و همگرایی رفتار محلی و CI است؛ و درس اصلی اینکه برای رقابت‌های I/O باید به ابزارهای ردیابی سطح سیستم تکیه کرد و پروتکل I/O را صریح و اتمی طراحی نمود.
#Go #DTrace #Concurrency #CI #Filesystem #Testing #Debugging #RaceCondition
🟣لینک مقاله:
https://golangweekly.com/link/175360/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
How to Reproduce and Fix an I/O Data Race with Go and DTrace
🟢 خلاصه مقاله:
در این مقاله نویسنده با یک باگ مبهم روبه‌رو می‌شود که فقط در CI رخ می‌دهد: یک data race در سطح I/O فایل‌ها که باعث شکست گهگاه تست‌ها می‌شود. چون این رقابت در مرز فایل‌سیستم رخ می‌دهد و نه در حافظه مشترک، ابزار race detector در Go آن را تشخیص نمی‌دهد. برای بازتولید محلی، نویسنده شرایط شبیه CI را ایجاد می‌کند: اجرای تکراری تست‌ها، افزایش همزمانی، و ایجاد تنوع زمانی تا ترتیب‌های نادری که خطا را می‌سازند آشکار شوند. با استفاده از DTrace و رصد فراخوانی‌های سیستمی مانند open، write، fsync و rename، الگوی واقعی آشکار می‌شود: خواندن فایل همزمان با نوشتن/حذف جزئی یا قبل از تحویل اتمی محتوا.
راهکار با اتمی‌سازی و هماهنگ‌سازی است: نوشتن در فایل موقت و سپس os.Rename برای تحویل اتمی، افزودن fsync در نقاط لازم، و در صورت نیاز قفل/کانال برای سریال‌سازی دسترسی به مسیرهای مشترک. در تست‌ها نیز از t.TempDir() برای جداسازی حالت، پرهیز از تکیه بر mtime، و اتکا به سیگنال‌های قطعی به‌جای تأخیرهای زمانی استفاده می‌شود. نتیجه، حذف flaky بودن در CI و همگرایی رفتار محلی و CI است؛ و درس اصلی اینکه برای رقابت‌های I/O باید به ابزارهای ردیابی سطح سیستم تکیه کرد و پروتکل I/O را صریح و اتمی طراحی نمود.
#Go #DTrace #Concurrency #CI #Filesystem #Testing #Debugging #RaceCondition
🟣لینک مقاله:
https://golangweekly.com/link/175360/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
🔵 عنوان مقاله
The Concurrency Conundrum: A Story of Curiosity and Code
🟢 خلاصه مقاله:
**این مقاله داستان برخورد با یک مشکل رایج در همزمانی است: سرویس ظاهراً سالمی که زیر بار گاهی قفل می‌کرد و درخواست‌ها معطل می‌ماندند. با افزودن لاگ‌های ساخت‌یافته، ابزارهای رهگیری و یک تست حداقلیِ قابل‌بازتولید، ریشه مشخص شد: ترتیب‌گیری نادرست قفل‌ها و بخش‌های بحرانی طولانی که به بن‌بست و گاهی رقابت در دسترسی به متغیرها منجر می‌شد. راه‌حل با تعریف نظم ثابت در ترتیب اخذ قفل‌ها، جایگزینی قفل سراسری با قفل‌های ریزدانه و read-write، کوچک‌کردن بخش‌های بحرانی و پرهیز از I/O زیر قفل، به‌کارگیری try-lock با backoff و timeout، و در مسیرهای پرتردد، حرکت به سمت پیام‌محوری به‌جای وضعیت مشترک اجرا شد. سپس با Thread Sanitizer و ابزارهای تشخیص بن‌بست در CI، تست‌های تنشی و مبتنی بر ویژگی، و سنجه‌های مربوط به تراکم قفل، سامانه سخت‌جان‌تر شد. جمع‌بندی: مدل همزمانی را ساده نگه دارید، داده‌های نامتغیر و عملیات idempotent را ترجیح دهید، از سازوکارهای سطح‌بالا استفاده کنید، و ترتیب قفل‌ها و ناوردایی‌ها را مستند و پایش‌پذیر کنید.
#Concurrency #Locking #Deadlock #RaceConditions #Multithreading #Debugging #SoftwareEngineering #Reliability
🟣لینک مقاله:
https://golangweekly.com/link/176333/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
The Concurrency Conundrum: A Story of Curiosity and Code
🟢 خلاصه مقاله:
**این مقاله داستان برخورد با یک مشکل رایج در همزمانی است: سرویس ظاهراً سالمی که زیر بار گاهی قفل می‌کرد و درخواست‌ها معطل می‌ماندند. با افزودن لاگ‌های ساخت‌یافته، ابزارهای رهگیری و یک تست حداقلیِ قابل‌بازتولید، ریشه مشخص شد: ترتیب‌گیری نادرست قفل‌ها و بخش‌های بحرانی طولانی که به بن‌بست و گاهی رقابت در دسترسی به متغیرها منجر می‌شد. راه‌حل با تعریف نظم ثابت در ترتیب اخذ قفل‌ها، جایگزینی قفل سراسری با قفل‌های ریزدانه و read-write، کوچک‌کردن بخش‌های بحرانی و پرهیز از I/O زیر قفل، به‌کارگیری try-lock با backoff و timeout، و در مسیرهای پرتردد، حرکت به سمت پیام‌محوری به‌جای وضعیت مشترک اجرا شد. سپس با Thread Sanitizer و ابزارهای تشخیص بن‌بست در CI، تست‌های تنشی و مبتنی بر ویژگی، و سنجه‌های مربوط به تراکم قفل، سامانه سخت‌جان‌تر شد. جمع‌بندی: مدل همزمانی را ساده نگه دارید، داده‌های نامتغیر و عملیات idempotent را ترجیح دهید، از سازوکارهای سطح‌بالا استفاده کنید، و ترتیب قفل‌ها و ناوردایی‌ها را مستند و پایش‌پذیر کنید.
#Concurrency #Locking #Deadlock #RaceConditions #Multithreading #Debugging #SoftwareEngineering #Reliability
🟣لینک مقاله:
https://golangweekly.com/link/176333/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Wawandco
The Concurrency Conundrum: A Story of Curiosity and Code | Wawandco
Building a simple reservation system sounds easy—until concurrency steps in. As a product grows, naive checks break down. This post unpacks why atomicity isn’t enough, and how pessimistic vs. optimistic locking prevent overbooking at scale.
❤1👍1
🔵 عنوان مقاله
A look into how JavaScript source maps work
🟢 خلاصه مقاله:
خلاصه‌ای از ساخت‌وکار source map در JavaScript: کدی که در مرورگر اجرا می‌شود معمولاً پس از transpile، bundle و minify با کد اصلی تفاوت دارد. source map پلی است میان این دو تا بتوانید در DevTools مثل کد اصلی breakpoint بگذارید و خطاها را بخوانید. یک source map فایل JSONی است با فیلدهایی مثل version، file، sources، names، sourcesContent و یک رشته mappings که با Base64 VLQ فشرده شده و با بخش‌های دلتایی موقعیت‌های کد تولید‌شده را به سطر/ستون‌های فایل‌های اصلی (و در صورت وجود، نام‌ها) نگاشت می‌کند. ابزارهایی مثل TypeScript و Babel نگاشت را هنگام تبدیل می‌سازند، Webpack/Rollup/esbuild آن‌ها را ترکیب می‌کنند و Terser در مرحله minify این زنجیره را حفظ می‌کند؛ این همان chain شدن source map است. مرورگر از طریق دستور sourceMappingURL (فایل خارجی یا data URI) map را می‌خواند و با رعایت CORS آن را decode کرده و در DevTools نمایش و دیباگ را بر اساس کد اصلی ممکن می‌سازد؛ همچنین پلتفرم‌هایی مثل Sentry با دریافت map می‌توانند stack traceهای production را de-minify کنند. در عمل، به خاطر اندازه و حریم خصوصی، بهتر است در production از الگوهایی چون hidden-source-map یا nosources-source-map، میزبانی امن، و فشرده‌سازی/کش استفاده کنید. محدودیت‌ها شامل دقت ستونی ناقص در برخی تبدیل‌ها، کدهای dynamic/eval، ناسازگاری مسیرها و سوگیری‌های نگاشت است. بهترین رویه‌ها: فعال‌سازی map در تمام مراحل build، اعتبارسنجی در DevTools، اطمینان از CORS مناسب برای ابزار خطا، کنترل نسخه ابزارها و آزمون remap شدن خطاها در CI.
#JavaScript #SourceMaps #WebDev #Debugging #DevTools #Bundlers #Performance
🟣لینک مقاله:
https://golangweekly.com/link/176649/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
A look into how JavaScript source maps work
🟢 خلاصه مقاله:
خلاصه‌ای از ساخت‌وکار source map در JavaScript: کدی که در مرورگر اجرا می‌شود معمولاً پس از transpile، bundle و minify با کد اصلی تفاوت دارد. source map پلی است میان این دو تا بتوانید در DevTools مثل کد اصلی breakpoint بگذارید و خطاها را بخوانید. یک source map فایل JSONی است با فیلدهایی مثل version، file، sources، names، sourcesContent و یک رشته mappings که با Base64 VLQ فشرده شده و با بخش‌های دلتایی موقعیت‌های کد تولید‌شده را به سطر/ستون‌های فایل‌های اصلی (و در صورت وجود، نام‌ها) نگاشت می‌کند. ابزارهایی مثل TypeScript و Babel نگاشت را هنگام تبدیل می‌سازند، Webpack/Rollup/esbuild آن‌ها را ترکیب می‌کنند و Terser در مرحله minify این زنجیره را حفظ می‌کند؛ این همان chain شدن source map است. مرورگر از طریق دستور sourceMappingURL (فایل خارجی یا data URI) map را می‌خواند و با رعایت CORS آن را decode کرده و در DevTools نمایش و دیباگ را بر اساس کد اصلی ممکن می‌سازد؛ همچنین پلتفرم‌هایی مثل Sentry با دریافت map می‌توانند stack traceهای production را de-minify کنند. در عمل، به خاطر اندازه و حریم خصوصی، بهتر است در production از الگوهایی چون hidden-source-map یا nosources-source-map، میزبانی امن، و فشرده‌سازی/کش استفاده کنید. محدودیت‌ها شامل دقت ستونی ناقص در برخی تبدیل‌ها، کدهای dynamic/eval، ناسازگاری مسیرها و سوگیری‌های نگاشت است. بهترین رویه‌ها: فعال‌سازی map در تمام مراحل build، اعتبارسنجی در DevTools، اطمینان از CORS مناسب برای ابزار خطا، کنترل نسخه ابزارها و آزمون remap شدن خطاها در CI.
#JavaScript #SourceMaps #WebDev #Debugging #DevTools #Bundlers #Performance
🟣لینک مقاله:
https://golangweekly.com/link/176649/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Do more with less. | Polar Signals
The Inner Workings of JavaScript Source Maps
A deep dive into how JavaScript source maps work under the hood, with examples showing how all the pieces fit together.
👍1
🔵 عنوان مقاله
Livecore: A Low-Pause Core File Dumper for Linux Processes
🟢 خلاصه مقاله:
این مقاله Livecore را معرفی می‌کند؛ ابزاری برای گرفتن core file از فرایندهای در حال اجرای Linux با وقفه بسیار کم. این ابزار که در یک جلسه «vibe coding» توسط Brad Fitzpatrick (عضو پیشین تیم Go) ساخته شده، امکان ساخت آنی و کم‌اختلال snapshot از حافظه و وضعیت اجرای فرایند را فراهم می‌کند تا بدون متوقف کردن سرویس، داده‌های لازم برای عیب‌یابی به‌دست آید. به‌جای تکیه بر crash یا توقف کامل فرایند، Livecore با بهره‌گیری از goref و قابلیت‌های Linux تلاش می‌کند تصویری دقیق و با سربار اندک تهیه کند و برای بررسی با ابزارهای post-mortem به کار رود. نتیجه، ابزاری عملی برای تیم‌های توسعه و SRE است که به observability کم‌اختلال—به‌ویژه در سرویس‌های Go روی Linux—نیاز دارند.
#Livecore #Linux #CoreDump #Debugging #Go #Observability #BradFitzpatrick #goref
🟣لینک مقاله:
https://golangweekly.com/link/176630/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Livecore: A Low-Pause Core File Dumper for Linux Processes
🟢 خلاصه مقاله:
این مقاله Livecore را معرفی می‌کند؛ ابزاری برای گرفتن core file از فرایندهای در حال اجرای Linux با وقفه بسیار کم. این ابزار که در یک جلسه «vibe coding» توسط Brad Fitzpatrick (عضو پیشین تیم Go) ساخته شده، امکان ساخت آنی و کم‌اختلال snapshot از حافظه و وضعیت اجرای فرایند را فراهم می‌کند تا بدون متوقف کردن سرویس، داده‌های لازم برای عیب‌یابی به‌دست آید. به‌جای تکیه بر crash یا توقف کامل فرایند، Livecore با بهره‌گیری از goref و قابلیت‌های Linux تلاش می‌کند تصویری دقیق و با سربار اندک تهیه کند و برای بررسی با ابزارهای post-mortem به کار رود. نتیجه، ابزاری عملی برای تیم‌های توسعه و SRE است که به observability کم‌اختلال—به‌ویژه در سرویس‌های Go روی Linux—نیاز دارند.
#Livecore #Linux #CoreDump #Debugging #Go #Observability #BradFitzpatrick #goref
🟣لینک مقاله:
https://golangweekly.com/link/176630/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
GitHub
GitHub - bradfitz/livecore: Linux low-pause core file dumper from an existing running process
Linux low-pause core file dumper from an existing running process - bradfitz/livecore
🔵 عنوان مقاله
Claude Code Can Debug Low-Level Cryptography
🟢 خلاصه مقاله:
** فیلیپو که به‌خاطر کارهای مداومش روی رمزنگاری در Go شناخته می‌شود، به‌تازگی پیاده‌سازی‌ای از الگوریتم امضای پساکوانتومی ML-DSA ساخته است. او هنگام توسعه با باگی روبه‌رو شد که در سطح پایین رخ می‌داد و با روش‌های معمول به‌سادگی آشکار نمی‌شد.
او از Claude Code کمک گرفت و این ابزار توانست همان «باگ سطح پایینِ نسبتاً پیچیده» را شناسایی کند و علت ریشه‌ای مشکل را روشن سازد. این تجربه نشان می‌دهد که دستیارهای کدنویسی مبتنی بر هوش مصنوعی می‌توانند در پروژه‌های حساسِ رمزنگاری نیز به کشف سریع‌تر خطاها کمک کنند—البته همچنان نیاز به آزمون‌های قابل بازتولید، اعتبارسنجی سخت‌گیرانه و بازبینی انسانی باقی است.
#Cryptography #PostQuantum #MLDSA #Go #Debugging #AI #CodeAssistants #ClaudeCode
🟣لینک مقاله:
https://golangweekly.com/link/176658/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Claude Code Can Debug Low-Level Cryptography
🟢 خلاصه مقاله:
** فیلیپو که به‌خاطر کارهای مداومش روی رمزنگاری در Go شناخته می‌شود، به‌تازگی پیاده‌سازی‌ای از الگوریتم امضای پساکوانتومی ML-DSA ساخته است. او هنگام توسعه با باگی روبه‌رو شد که در سطح پایین رخ می‌داد و با روش‌های معمول به‌سادگی آشکار نمی‌شد.
او از Claude Code کمک گرفت و این ابزار توانست همان «باگ سطح پایینِ نسبتاً پیچیده» را شناسایی کند و علت ریشه‌ای مشکل را روشن سازد. این تجربه نشان می‌دهد که دستیارهای کدنویسی مبتنی بر هوش مصنوعی می‌توانند در پروژه‌های حساسِ رمزنگاری نیز به کشف سریع‌تر خطاها کمک کنند—البته همچنان نیاز به آزمون‌های قابل بازتولید، اعتبارسنجی سخت‌گیرانه و بازبینی انسانی باقی است.
#Cryptography #PostQuantum #MLDSA #Go #Debugging #AI #CodeAssistants #ClaudeCode
🟣لینک مقاله:
https://golangweekly.com/link/176658/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
words.filippo.io
Claude Code Can Debug Low-level Cryptography
Surprisingly (to me) Claude Code debugged my new ML-DSA implementation faster than I would have, finding the non-obvious low-level issue that was making Verify fail.
👍1