नए टूल की मदद से WebAssembly को डीबग करना

Ingvar Stepanyan
Ingvar Stepanyan

अब तक सड़क

एक साल पहले, Chrome ने शुरुआती सहायता का एलान किया था Chrome DevTools में नेटिव WebAssembly डीबगिंग के लिए.

हमने बुनियादी सुविधाओं को जारी रखने के बारे में बताया और अवसरों के बारे में बात की के बजाय, DWARF जानकारी का इस्तेमाल करना आने वाले समय में, हमारे लिए सोर्स मैप खुलेगा:

  • वैरिएबल के नामों को हल करना
  • सुंदर प्रिंटिंग के प्रकार
  • सोर्स भाषाओं में एक्सप्रेशन का आकलन करना
  • ...और ऐसी ही अन्य बातें!

आज हमें यह बताते हुए खुशी हो रही है कि इसमें बेहतरीन सुविधाएं शामिल की गई हैं साथ ही, Emscripten और Chrome DevTools की टीमों ने जो प्रोग्रेस की है उसे खास तौर पर, C और C ऐप्लिकेशन के लिए.

शुरू करने से पहले, कृपया ध्यान रखें कि यह अब भी बीटा वर्शन है तो आपको सभी टूल के सबसे नए वर्शन का इस्तेमाल करना होगा पर रिपोर्ट करें और अगर आपको कोई समस्या आती है, तो कृपया उसकी शिकायत करें https://bugs.chromium.org/p/chromium/issues/entry?template=DevTools issue.

चलिए, पिछली बार की तरह ही आसान C उदाहरण से शुरुआत करते हैं:

#include <stdlib.h>

void assert_less(int x, int y) {
  if (x >= y) {
    abort();
  }
}

int main() {
  assert_less(10, 20);
  assert_less(30, 20);
}

इसे कंपाइल करने के लिए, हम सबसे नए एंस्क्रिप्टन का इस्तेमाल करते हैं और डीबग को शामिल करने के लिए, मूल पोस्ट की तरह ही एक -g फ़्लैग पास करें जानकारी:

emcc -g temp.c -o temp.html

अब हम जनरेट किए गए पेज को localhost HTTP सर्वर ( उदाहरण के लिए, serve के साथ) और इसे सबसे नए Chrome कैनरी में खोलें.

इस बार हमें एक ऐसे हेल्पर एक्सटेंशन की भी ज़रूरत होगी जो Chrome के साथ इंटिग्रेट हो DevTools और इसकी मदद से, डीबग करने की सभी जानकारी को समझना आसान हो गया है WebAssembly फ़ाइल में एन्कोड किया गया. कृपया इस पर जाकर इसे इंस्टॉल करें लिंक: goo.gle/wasm-debugging-extension

DevTools में WebAssembly डीबग करने की सुविधा को भी चालू करना होगा एक्सपेरिमेंट. Chrome DevTools खोलें और गियर () आइकॉन पर क्लिक करें DevTools पैनल के सबसे ऊपर दाएं कोने में, एक्सपेरिमेंट पैनल पर जाएं और WebAssembly डीबगिंग: DWARF सहायता चालू करें पर सही का निशान लगाएं.

DevTools की सेटिंग का एक्सपेरिमेंट पैनल

सेटिंग बंद करने पर, DevTools खुद को फिर से लोड करने का सुझाव देगा सेटिंग लागू करनी है, तो बस इतना ही करें. एक बार के लिए बस इतना ही सेटअप.

अब हम स्रोत पैनल पर वापस जा सकते हैं, रोकें चालू करें अपवाद (⏸ आइकॉन) का इस्तेमाल करें. इसके बाद, छूटे हुए अपवादों पर रोकें चुनें और पेज को फिर से लोड करें. आपको एक अपवाद पर DevTools को रोका हुआ दिखना चाहिए:

सोर्स पैनल का स्क्रीनशॉट, जिसमें &#39;शामिल किए गए अपवादों पर रोकें&#39; को चालू करने का तरीका दिखाया गया है

डिफ़ॉल्ट रूप से, यह Emscripten से जनरेट किए गए ग्लू कोड पर रुक जाता है, लेकिन दाईं ओर, आपको एक कॉल स्टैक व्यू दिखेगा, जो और उस मूल सी लाइन पर जा सकते हैं जिसका इस्तेमाल शुरू किया गया था. abort:

DevTools `asrt_less` फ़ंक्शन में रुक गया है और स्कोप व्यू में `x` और `y` वैल्यू दिख रही हैं

अब, स्कोप में देखने पर, आपको मूल नाम दिखेंगे और C/C कोड में वैरिएबल की वैल्यू को फ़्लैग कर सकता है. जानिए कि $localN जैसे विभाजित नाम का क्या मतलब है और वे आपके लिखे गए सोर्स कोड में कोई बदलाव नहीं हुआ है.

यह न सिर्फ़ पूर्णांकों जैसे शुरुआती वैल्यू पर लागू होता है, बल्कि कंपाउंड पर भी लागू होता है संरचना, क्लास, अरे वगैरह जैसे टाइप भी!

रिच टाइप की सुविधा

आइए, अब इन्हें दिखाने के लिए ज़्यादा मुश्किल उदाहरण पर नज़र डालें. यह समय, हम एक मैंडलब्रॉट फ़्रैक्टल बनाएंगे इस C कोड का इस्तेमाल करें:

#include <SDL2/SDL.h>
#include <complex>

int main() {
  // Init SDL.
  int width = 600, height = 600;
  SDL_Init(SDL_INIT_VIDEO);
  SDL_Window* window;
  SDL_Renderer* renderer;
  SDL_CreateWindowAndRenderer(width, height, SDL_WINDOW_OPENGL, &window,
                              &renderer);

  // Generate a palette with random colors.
  enum { MAX_ITER_COUNT = 256 };
  SDL_Color palette[MAX_ITER_COUNT];
  srand(time(0));
  for (int i = 0; i < MAX_ITER_COUNT;   i) {
    palette[i] = {
        .r = (uint8_t)rand(),
        .g = (uint8_t)rand(),
        .b = (uint8_t)rand(),
        .a = 255,
    };
  }

  // Calculate and draw the Mandelbrot set.
  std::complex<double> center(0.5, 0.5);
  double scale = 4.0;
  for (int y = 0; y < height; y  ) {
    for (int x = 0; x < width; x  ) {
      std::complex<double> point((double)x / width, (double)y / height);
      std::complex<double> c = (point - center) * scale;
      std::complex<double> z(0, 0);
      int i = 0;
      for (; i < MAX_ITER_COUNT - 1; i  ) {
        z = z * z   c;
        if (abs(z) > 2.0)
          break;
      }
      SDL_Color color = palette[i];
      SDL_SetRenderDrawColor(renderer, color.r, color.g, color.b, color.a);
      SDL_RenderDrawPoint(renderer, x, y);
    }
  }

  // Render everything we've drawn to the canvas.
  SDL_RenderPresent(renderer);

  // SDL_Quit();
}

आप देख सकते हैं कि यह ऐप्लिकेशन अब भी काफ़ी छोटा है-यह एकल फ़ाइल में 50 पंक्तियों का कोड है-लेकिन इस बार मैं कुछ बाहरी एपीआई, जैसे कि SDL लाइब्रेरी और साथ ही, कॉम्प्लेक्स नंबर C स्टैंडर्ड लाइब्रेरी.

मैं इसे ऊपर बताए गए उसी -g फ़्लैग के साथ कंपाइल कर रहा/रही हूं और मैं Emscripten से SDL2 उपलब्ध कराने के लिए भी कहूँगी और आर्बिट्ररी साइज़ की मेमोरी की अनुमति दें:

emcc -g mandelbrot.cc -o mandelbrot.html \
     -s USE_SDL=2 \
     -s ALLOW_MEMORY_GROWTH=1

जब मैं ब्राउज़र में जनरेट किए गए पेज पर जाता हूं, तो मैं कुछ बेतरतीब रंगों के साथ फ़्रैक्टल आकार:

डेमो पेज

DevTools खोलने पर, मुझे फिर से ओरिजनल C फ़ाइल दिख रही है. यह समय, हालांकि, हमें कोड में कोई गड़बड़ी नहीं मिली (वाह!), तो आइए सेट करते हैं कोड की शुरुआत में कुछ ब्रेकपॉइंट जोड़ सकते हैं.

जब हम पेज को फिर से लोड करते हैं, तो डीबगर हमारी C सोर्स:

`SDL_Init` कॉल पर DevTools को रोका गया

दाईं ओर हमारे सभी वैरिएबल पहले से ही दिख रहे हैं, लेकिन सिर्फ़ width ही दिख रहे हैं और height इस समय शुरू किए गए हैं, इसलिए की जांच करें.

आइए, अपने मुख्य मेंडलब्रॉट लूप में एक और ब्रेकपॉइंट सेट करें और फिर से शुरू करें करने के लिए इसका इस्तेमाल किया जा सकता है.

DevTools को नेस्ट किए गए लूप में रोका गया है

इस समय, हमारा palette कुछ रैंडम रंगों से भरा गया है, और हम अरे के साथ-साथ व्यक्तिगत तौर पर यह पक्का करने के लिए कि SDL_Color स्ट्रक्चर तैयार करता है और उसके कॉम्पोनेंट की जांच करता है सब कुछ अच्छा लगता है (उदाहरण के लिए, "ऐल्फ़ा" चैनल हमेशा सेट रहता है पूरी ओपैसिटी (पूरी अपारदर्शिता) में बदलना. इसी तरह, हम अपने विश्लेषण के मकसद से, center वैरिएबल में सेव किए गए कॉम्प्लेक्स नंबर के काल्पनिक हिस्से.

अगर आपको डीप नेस्ट की गई ऐसी प्रॉपर्टी को ऐक्सेस करना है जो आपके लिए मुश्किल है स्कोप में जाकर, कंसोल का इस्तेमाल किया जा सकता है का आकलन भी किया जा सकता है! हालांकि, ध्यान दें कि ज़्यादा जटिल C एक्सप्रेशन अभी तक काम नहीं कर रहा है.

`palette[10].r` का नतीजा दिखाने वाला कंसोल पैनल

कुछ बार फिर से एक्ज़ीक्यूशन करते हैं और देख सकते हैं कि अंदरूनी x कैसा है दायरा व्यू में दोबारा देखकर, वैरिएबल के नाम को वॉच लिस्ट में जोड़ सकता है, कंसोल में इसका आकलन कर सकता है या सोर्स कोड में वैरिएबल पर कर्सर घुमाना:

सोर्स में वैरिएबल `x` पर टूलटिप की वैल्यू `3` दिख रही है

यहां से, C स्टेटमेंट पर गौर किया जा सकता है या चरण-दर-चरण अपनाया जा सकता है. साथ ही, यह देखा जा सकता है कि अन्य वैरिएबल भी बदल रहे हैं:

`रंग`, `पॉइंट`, और अन्य वैरिएबल की वैल्यू दिखाने वाले टूलटिप और स्कोप व्यू

ठीक है, डीबग करने की जानकारी उपलब्ध होने पर, यह सब अच्छी तरह से काम करता है, लेकिन अगर हम किसी ऐसे कोड को डीबग करना चाहें जो डीबग करने की सुविधा की मदद से नहीं बनाया गया हो, तो क्या होगा विकल्प?

रॉ WebAssembly डीबग करना

उदाहरण के लिए, हमने Emscripten से इसके लिए पहले से बनी SDL लाइब्रेरी उपलब्ध कराने के लिए कहा हमें स्रोत से जोड़ने के बजाय, कम से कम फ़िलहाल, डीबगर के लिए, जुड़े हुए सोर्स ढूंढने का कोई तरीका नहीं है. आइए, SDL_RenderDrawColor के बारे में फिर से जानते हैं:

`mandelbrot.vasm` को अलग करने वाला व्यू दिखाने वाला DevTools

हम रॉ WebAssembly डीबग करने के अनुभव पर वापस आ गए हैं.

अब, यह थोड़ा डरावना लग रहा है और यह कुछ ऐसा नहीं है जिसे ज़्यादातर वेब डेवलपरों को कभी-कभी समस्याओं का सामना करना पड़ता है, लेकिन कभी-कभी डीबग करने की जानकारी के बिना बनाई गई लाइब्रेरी-चाहें, क्योंकि यह तीसरे पक्ष की लाइब्रेरी जिन पर आपका कोई कंट्रोल नहीं है या हमें ऐसी गड़बड़ियों का सामना करना पड़ता है जो सिर्फ़ प्रोडक्शन के दौरान होती हैं.

ऐसे मामलों में आपकी मदद करने के लिए, हमने डीबग करने का अनुभव भी.

सबसे पहले, अगर आपने पहले कभी रॉ WebAssembly डीबगिंग का इस्तेमाल किया था, तो ध्यान दें कि पूरा असेंबली अब एक ही फ़ाइल-नहीं में दिखता है यह अनुमान लगाने में ज़्यादा मदद मिलेगी कि सोर्स एंट्री wasm-53834e3e/ wasm-53834e3e-7 किस फ़ंक्शन से जुड़ा हो सकता है.

नया नाम जनरेट करने की स्कीम

हमने डिसअसेंबली व्यू में भी नामों में सुधार किया है. पहले आपको दिखेगा कि सिर्फ़ न्यूमेरिक इंडेक्स या फ़ंक्शन के मामले में कोई नाम नहीं होना चाहिए.

अब हम अलग करने वाले दूसरे टूल की तरह ही नाम जनरेट कर रहे हैं. WebAssembly के नाम वाले सेक्शन से मिले संकेतों का इस्तेमाल करके, पाथ इंपोर्ट/एक्सपोर्ट करना और आखिर में, अगर बाकी सब कुछ फ़ेल हो जाता है, तो $func123 जैसे आइटम के टाइप और इंडेक्स के हिसाब से तय किया जाता है. आप ऊपर दिए गए स्क्रीनशॉट में देखें कि कैसे, ऊपर दिए गए स्क्रीनशॉट में और आसानी से पढ़ने लायक स्टैकट्रेस और डिसअसेंबली.

डेटा के टाइप के बारे में कोई जानकारी उपलब्ध न होने पर, उसकी जांच करना मुश्किल हो सकता है प्रिमिटिव के अलावा कोई भी वैल्यू दिखेगी. उदाहरण के लिए, पॉइंटर दिखेंगे वे नियमित पूर्णांकों के तौर पर काम करते हैं, जिनमें यह जानने का कोई तरीका नहीं है कि उनके पीछे क्या सेव है मेमोरी.

मेमोरी की जांच करना

पहले, सिर्फ़ WebAssembly के मेमोरी ऑब्जेक्ट को बड़ा किया जा सकता था. यह ऑब्जेक्ट को देखने के लिए, दायरा व्यू में env.memory के ज़रिए दिखाया जाता था अलग-अलग बाइट. यह कुछ साधारण स्थितियों में काम करता था, लेकिन ऐसा नहीं था खास तौर पर, इसे बड़ा करने के लिए सुविधाजनक है. साथ ही, इसे दोबारा समझने की सुविधा नहीं है बाइट वैल्यू के अलावा अन्य फ़ॉर्मैट में. हमने आपकी मदद के लिए एक नई सुविधा जोड़ी है इसके साथ ही: एक लीनियर मेमोरी इंस्पेक्टर भी.

env.memory पर राइट क्लिक करने पर, अब आपको मेमोरी की जांच करें नाम का विकल्प:

स्कोप पैनल में `env.memory` के कॉन्टेक्स्ट मेन्यू में &#39;मेमोरी की जांच करें&#39; दिखता है आइटम

क्लिक करने पर, आपको मेमोरी इंस्पेक्टर दिखेगा जिसे हेक्साडेसिमल और ASCII व्यू में WebAssembly मेमोरी की जांच की जा सकती है, नेविगेट करने के लिए, और साथ ही पता चलता है कि अलग-अलग फ़ॉर्मैट में:

DevTools में मेमोरी इंस्पेक्टर पैनल में मेमोरी के हेक्स और ASCII व्यू दिखाए गए हैं

बेहतर स्थितियां और सावधानियां

WebAssembly कोड की प्रोफ़ाइल बनाई जा रही है

DevTools खोलने पर, WebAssembly कोड "टीयर" दिखता है से लेकर डीबग करने की सुविधा चालू करने के लिए ऑप्टिमाइज़ नहीं किया गया वर्शन. यह वर्शन बहुत धीमा है, इसका मतलब है कि आपको console.time और performance.now पर भरोसा नहीं किया जा सकता और आपके कोड की स्पीड मापने के दूसरे तरीके हैं, जबकि DevTools नहीं, क्योंकि आपको प्राप्त होने वाले आंकड़े वास्तविक दुनिया के प्रदर्शन को नहीं बिलकुल भी नहीं.

इसके बजाय, आपको DevTools परफ़ॉर्मेंस पैनल का इस्तेमाल करना चाहिए जो कोड को पूरी स्पीड से चलाएगा और आपको अलग-अलग फ़ंक्शन में लगने वाले समय का ब्यौरा:

Wasm के अलग-अलग फ़ंक्शन दिखा रहा प्रोफ़ाइलिंग पैनल

इसके अलावा, आपके पास DevTools बंद करके अपने ऐप्लिकेशन को चलाने का विकल्प है. साथ ही, कंसोल की जांच करने के बाद उन्हें खोलें.

हम आने वाले समय में, प्रोफ़ाइल बनाने की स्थितियों को बेहतर बनाने की कोशिश करेंगे. हालांकि, अभी के लिए ध्यान रखें. अगर आपको WebAssembly के बारे में ज़्यादा जानना है टियर करने के लिए अलग-अलग टियर के लिए, WebAssembly कंपाइलेशन पाइपलाइन पर हमारे दस्तावेज़ देखें.

अलग-अलग मशीनों पर बनाना और डीबग करना (इसमें Docker / होस्ट शामिल है)

Docker, वर्चुअल मशीन या रिमोट बिल्ड सर्वर पर बनाते समय, आपको ऐसी स्थितियों का सामना करना पड़ सकता है जिनमें सोर्स फ़ाइलों के पाथ बिल्ड के दौरान इस्तेमाल किया जाने वाला डेटा, आपके फ़ाइल सिस्टम के पाथ से मेल नहीं खाता, जहां Chrome DevTools चल रहे हैं. इस स्थिति में, फ़ाइलें सोर्स पैनल, लेकिन लोड नहीं हो सका.

इस समस्या को ठीक करने के लिए, हमने इसमें पाथ मैपिंग फ़ंक्शन लागू किया है C/C एक्सटेंशन विकल्प चुनें. इसका इस्तेमाल करके, आर्बिट्रेरी पाथ को फिर से मैप किया जा सकता है और इससे DevTools को सोर्स ढूंढने में मदद मिलेगी.

उदाहरण के लिए, अगर आपकी होस्ट मशीन पर प्रोजेक्ट किसी पाथ के अंदर है C:\src\my_project, लेकिन इसे Docker कंटेनर के अंदर बनाया गया, जहां वह पाथ /mnt/c/src/my_project के रूप में दिखाया गया था, तो आप दोबारा मैप कर सकते हैं उन पाथ को प्रीफ़िक्स के तौर पर बताकर, डीबग करने के दौरान इसे फिर से डीबग करता है:

C/C   डीबग करने के एक्सटेंशन के विकल्पों वाला पेज

पहला मेल खाने वाला प्रीफ़िक्स "wins". अगर आपको अन्य C डीबगर, यह विकल्प set substitute-path कमांड से मिलता-जुलता है या LLDB में target.source-map सेटिंग हो.

ऑप्टिमाइज़ किए गए बिल्ड को डीबग करना

किसी भी दूसरी भाषा की तरह, डीबग करने की सुविधा सबसे अच्छी तरह से तब काम करती है, जब ऑप्टिमाइज़ेशन बंद किया गया. ऑप्टिमाइज़ेशन की मदद से, फ़ंक्शन को इनलाइन करके दूसरे फ़ंक्शन में डाला जा सकता है. या कोड के कुछ हिस्सों को हटा सकता हूं-और इन सभी में डीबगर को भ्रम में डालने की संभावना है और इस कारण आपको एक उपयोगकर्ता के रूप में भी सूचित किया जा सकता है.

अगर आपको डीबग करने का सीमित अनुभव नहीं है और फिर भी आपको किसी ऑप्टिमाइज़ किए गए बिल्ड को डीबग करने, तो ज़्यादातर ऑप्टिमाइज़ेशन इस तरह से काम करेंगे फ़ंक्शन इनलाइनिंग को छोड़कर. हमारी कोशिश है कि बाकी जगहों पर भी हम आने वाले समय में समस्याएं आ सकती हैं, लेकिन अभी के लिए, कृपया -fno-inline का इस्तेमाल करके इसे किसी भी -O लेवल के ऑप्टिमाइज़ेशन के साथ कंपाइल करते समय बंद करें, उदाहरण के लिए:

emcc -g temp.c -o temp.html \
     -O3 -fno-inline

डीबग की जानकारी को अलग करना

डीबग करने की जानकारी में आपके कोड के बारे में काफ़ी जानकारी होती है टाइप, वैरिएबल, फ़ंक्शन, स्कोप, और जगहों की जानकारी-जो भी हो सकता है डीबगर के लिए उपयोगी होगी. इस वजह से, यह अक्सर कोड खुद बनाना शुरू कर देते हैं.

WebAssembly मॉड्यूल के लोड और कंपाइलेशन की रफ़्तार के लिए, आपको को इस डीबग जानकारी को एक अलग WebAssembly में बांटना फ़ाइल से लिए जाते हैं. Emscripten में ऐसा करने के लिए, -gseparate-dwarf=… फ़्लैग को पसंदीदा फ़ाइल नाम:

emcc -g temp.c -o temp.html \
     -gseparate-dwarf=temp.debug.wasm

इस स्थिति में, मुख्य ऐप्लिकेशन में सिर्फ़ फ़ाइल नाम सेव होगा temp.debug.wasm शामिल है और हेल्पर एक्सटेंशन DevTools खोलने पर इसे लोड करें.

ऊपर बताए गए ऑप्टिमाइज़ेशन के साथ इस्तेमाल करने पर, यह सुविधा इसका इस्तेमाल, आपकी वेबसाइट के करीब-करीब ऑप्टिमाइज़ किए गए प्रोडक्शन बिल्ड को भेजने के लिए भी किया जा सकता है और बाद में उन्हें लोकल साइड फ़ाइल की मदद से डीबग करें. इस मामले में, हमें अतिरिक्त एक्सटेंशन की सहायता करने के लिए साइड फ़ाइल ढूंढें, उदाहरण के लिए:

emcc -g temp.c -o temp.html \
     -O3 -fno-inline \
     -gseparate-dwarf=temp.debug.wasm \
     -s SEPARATE_DWARF_URL=file://[local path to temp.debug.wasm]

जारी रखना है...

वाह, इसमें कई नई सुविधाएं थीं!

इन सभी नए इंटिग्रेशन के साथ, Chrome DevTools एक बेहतर विकल्प बन गया है. यह एक दमदार डीबगर है, जो सिर्फ़ JavaScript के लिए ही नहीं, बल्कि C और C ऐप्लिकेशन के लिए भी इस्तेमाल किया जा सकता है. कई अलग-अलग सुविधाओं के साथ तैयार किए गए, ऐप्लिकेशन इस्तेमाल करना अब पहले से ज़्यादा आसान हो गया है और उन्हें शेयर किए गए, क्रॉस-प्लैटफ़ॉर्म वेब पर लाया जा सकता है.

हालांकि, हमारा सफ़र अभी खत्म नहीं हुआ है. कुछ चीज़ों के बारे में हम जानेंगे मैं यहां से इस पर काम कर रहा हूं:

  • डीबग करने की प्रोसेस में, अनचाहे किनारों को हटाना.
  • कस्टम टाइप फ़ॉर्मैट करने वालों के लिए सहायता जोड़ी जा रही है.
  • हम इसमें सुधार करने के लिए काम कर रहे हैं प्रोफ़ाइलिंग भी सेट अप कर सकते हैं.
  • कोड कवरेज के लिए सहायता जोड़ना, ताकि इसे ढूंढने में आसानी हो इस्तेमाल नहीं हुआ कोड.
  • कंसोल के आकलन में एक्सप्रेशन के लिए, सहायता को बेहतर बनाना.
  • अन्य भाषाओं के लिए भी यह सुविधा जोड़ी जा रही है.
  • …और ऐसे ही अन्य ट्रेंड!

तब तक, कृपया अपने कोड पर मौजूदा बीटा वर्शन इस्तेमाल करके और हमें मिले किसी भी कोड की शिकायत करके, हमारी मदद करें समस्याएं https://bugs.chromium.org/p/chromium/issues/entry?template=DevTools issue.

झलक दिखाने वाले चैनलों को डाउनलोड करें

Chrome Canary, Dev या बीटा को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. झलक दिखाने वाले इन चैनलों की मदद से, DevTools की नई सुविधाओं को ऐक्सेस किया जा सकता है और वेब प्लैटफ़ॉर्म के बेहतरीन एपीआई की जांच की जा सकती है. साथ ही, उपयोगकर्ताओं से पहले ही अपनी साइट की समस्याओं का पता लगाया जा सकता है!

Chrome DevTools की टीम से संपर्क करना

पोस्ट में नई सुविधाओं और बदलावों या DevTools से जुड़ी किसी भी अन्य चीज़ के बारे में चर्चा करने के लिए, नीचे दिए गए विकल्पों का इस्तेमाल करें.

  • crbug.com के ज़रिए हमें कोई सुझाव या फ़ीडबैक सबमिट करें.
  • ज़्यादा विकल्प   ज़्यादा दिखाएँ > का इस्तेमाल करके DevTools से जुड़ी समस्या की शिकायत करें सहायता > DevTools में DevTools से जुड़ी समस्याओं की शिकायत करें.
  • @ChromeDevTools पर ट्वीट करें.
  • DevTools YouTube वीडियो या DevTools के बारे में सलाह YouTube वीडियो में नया क्या है, इस पर टिप्पणी करें.