Desmond  Gerber

Desmond Gerber


How to Install GNU Debugger GDB on Linux Mint 21

GNU Debugger, commonly referred as GDB is a powerful and open-source debugging tool that can run on Linux and Unix-type operating systems. The GDB tool was specifically designed for C and C++ languages; due to its wide range of supportive languages, it can debug other languages as well like Ada, Fortran, Go, Pascal, and many others. It is used by developers to examine variables, calling functions, debug preprocessor macros, server-client debug architecture, and many other rich features that one can think of it.

Install GDB on Linux Mint 21

In Linux, we have two ways to install GDB on Linux Mint 21 system: 

  • Using Terminal
  • Using GUI

Method 1: Install GDB Using Terminal

To follow the terminal approach, you must update the system repository first to let update all the packages:

$ sudo apt update


Now, run the following installation command to install GDB on Linux Mint 21 system:

$ sudo apt install gdb


Type the version command to check if your system has installed the GDB tool successfully:

$ gdb --version

To run GDB on your system through terminal, execute the following command:

$ gdb

You can also remove GDB from your system by executing the following command:

$ sudo apt remove gdb

Method 2: Install GDB Using GUI

Open the software manager, search for the GDB using the search bar, and hit the accurate output from the several results:

Click on the Install button to let it install on Linux Mint 21 system:

This requires sudo privileges as you can only get it if you’re working as super user. Type the Linux Mint password and click to Authenticate:

It will start installing the program after authentication:

The GDB tool is installed on your Linux Mint 21 system, click on the Launch button to open it on your system.

You can also remove it by hitting on the Remove button.


GDB is an open-source, popular and portable debugger tool used by developers to debug programs written in C, C++, FORTRAN, Go, Pascal, and many other languages. This tool also helps to trace instructions of programs and debug it. Using this guide, we have learned how to install GDB on Linux Mint 21 system using a terminal and GUI.

Original article source at:

#linux #install #debugger 

How to Install GNU Debugger GDB on Linux Mint 21
Rupert  Beatty

Rupert Beatty


Dap-mode: Emacs Debug Adapter Protocol



Emacs client/library for Debug Adapter Protocol is a wire protocol for communication between client and Debug Server. It’s similar to the LSP but provides integration with debug server.

Project status

The API considered unstable until 1.0 release is out. It is tested against Java, Python, Ruby, Elixir and LLDB (C/C++/Objective-C/Swift).


The main entry points are dap-debug and dap-debug-edit-template. The first one asks for a registered debug template and starts the configuration using the default values for that particular configuration. The latter creates a debug template which could be customized before running. dap-debug-edit-template will prepare a template declaration inside a temporary buffer. You should execute this code using C-M-x for the changes to apply. You should also copy this code into your Emacs configuration if you wish to make it persistent.

dap-mode also provides a hydra with dap-hydra. You can automatically trigger the hydra when the program hits a breakpoint by using the following code.

(add-hook 'dap-stopped-hook
          (lambda (arg) (call-interactively #'dap-hydra)))

Docker usage

You can also use this tool with dockerized debug servers: configure it either with a .dir-locals file or drop an .lsp-docker.yml configuration file (use lsp-docker for general reference). Basically you have one function dap-docker-register that performs all the heavy lifting (finding the original debug template, patching it, registering a debug provider e.t.c). This function examines a configuration file or falls back to the default configuration (which can be patched using the .dir-locals approach, take a note that the default configuration doesn’t provide any sane defaults for debugging) and then operates on the combination of the two. This mechanism is the same as in lsp-docker.

Note: currently you cannot use this mode when using a network connection to connect to debuggers (this part is yet to be implemented). Still want to talk to debuggers over network? In order to do so you have to look at the launch-args patching done by dap-docker--dockerize-start-file-args, you have to somehow assign nil to dap-server-path before it is passed further into session creation.

If you want to stick to a configuration file, take a look at the example below:

    # 'lsp-docker' fields
    - source: "/your/host/source/path" # used both by 'lsp-docker' and 'dap-docker'
      destination: "/your/local/path/inside/a/container" # used both by 'lsp-docker' and 'dap-docker'
    type: docker # only docker is supported
    subtype: image # or 'container'
    name: <docker image or container that has the debugger in> # you can omit this field
    # in this case the 'lsp-docker' ('server' section) image name is used
    enabled: true # you can explicitly disable 'dap-docker' by using 'false'
    provider: <your default language debug provider, double quoted string>
    template: <your default language debug template, double quoted string>
    launch_command: <an explicit command if you want to override a default one provided by the debug provider>
    # e.g. if you have installed a debug server in a different directory, not used with 'container' subtype debuggers




Extending DAP with new Debug servers



  • Daniel Martin - LLDB integration.
  • Kien Nguyen - NodeJS debugger, Edge debuggers, automatic extension installation.
  • Aya Igarashi - Go debugger integration.
  • Nikita Bloshchanevich - launch.json support (+ variable expansion), debugpy support, (with some groundwork by yyoncho) runInTerminal support, various bug fixes.
  • Andrei Mochalov - Docker (debugging in containers) integration.

Download Details:

Author: Emacs-lsp
Source Code: 
License: GPL-3.0 license

#swift #javascript #ruby #java #go #debugger 

Dap-mode: Emacs Debug Adapter Protocol
Monty  Boehm

Monty Boehm


See Your Plugin Logs, inspect The State Of Sketch Documents

Sketch DevTools

See your plugin logs, inspect the state of Sketch documents, explore actions, and more.


From a release (simplest)

  • Download the latest release of the plugin
  • Un-zip
  • Double-click on the sketch plugin

From the sources

  • Clone the repo
  • Install the dependencies (npm install)


If you want to show some proper logs in the DevTools, you need to use Sketch >= 52.

You might notice performance issues when the DevTools are opened, that's because it's listening to all actions. Closing it will go back to normal.


Lots of room for improvement, let's build it together :) Check out the issues and pick one!

Download Details:

Author: Skpm
Source Code: 
License: MIT license

#sketch #debugger #devtools 

See Your Plugin Logs, inspect The State Of Sketch Documents
Rupert  Beatty

Rupert Beatty


A UIView Debugger That Can Be Embedded in an App


InAppViewDebugger is a library that implements a view debugger with a 3D snapshot view and a hierarchy view, similar to Reveal and Xcode's own view debugger. The key distinction is, as the project title suggests, that this can be embedded inside the app and used on-device to debug UI issues without needing to be tethered to a computer.



  • 3D snapshot view implemented in SceneKit: Gesture controls for zooming, panning, and rotating.
  • Hierarchy (tree) view that synchronizes its selection with the 3D view: This is a feature I really wanted in Xcode, to be able to visually find a view and see where it is in the hierarchy view
  • Support for iPad and iPhone: Layouts are designed specifically for each form factor.
  • Extensible: The base implementation supports UIView hierarchies, but this is easily extensible to support any kind of UI framework (e.g. CoreAnimation or SpriteKit)


  • iOS 11.0+
  • Xcode 10.1+ (framework built for Swift 4.2)



Add the following line to your Podfile:

pod 'InAppViewDebugger', '~> 1.0.3'


Add the following line to your Cartfile:

github "indragiek/InAppViewDebugger" "1.0.3"



import InAppViewDebugger

@IBAction func showViewDebugger(sender: AnyObject) {


@import InAppViewDebugger;

// alternative import (they're the same):
// #import <InAppViewDebugger/InAppViewDebugger-Swift.h>

- (IBAction)showViewDebugger:(id)sender {
  [InAppViewDebugger present];


(lldb) expr -lswift -- import InAppViewDebugger
(lldb) expr -lswift -- InAppViewDebugger.present()

The present function shows the UI hierarchy for your application's key window, presented over the top view controller of the window's root view controller. There are several other methods available on InAppViewDebugger for presenting a view debugger for a given window, view, or view controller.


Focusing on an Element

To focus on the subhierarchy of a particular element, long press on the element to bring up the action menu and tap "Focus". The long press can be used both in the hierarchy view and the 3D snapshot view. The "Log Description" action will log the description of the element to the console, so that if you're attached to Xcode you can copy the address of the object for further debugging.

Focusing on an Element

Adjusting Distance Between Levels

The slider on the bottom left of the snapshot view can be used to adjust the spacing between levels of the hierarchy:

Adjusting Distance Between Levels

Adjusting Visible Levels

The range slider on the bottom right of the snapshot view can be used to adjust the range of levels in the hierarchy that are visible:

Adjusting Visible Levels

Showing/Hiding Headers

Each UI element has a header above it that shows its class name. These headers can be hidden or shown by long pressing on an empty area of the snapshot view to bring up the action menu:

Showing/Hiding Headers

Showing/Hiding Borders

Similarly to the headers, the borders drawn around each element can also be shown or hidden:

Showing/Hiding Borders


Colors, fonts, and other attributes for both the snapshot view and the hierarchy view can be changed by creating a custom Configuration. The configuration is then passed to a function like InAppViewDebugger.presentForWindow(:configuration:completion:).

Extending for Other UI Frameworks

The current implementation only supports UIView hierarchies, but this can easily be extended to support other UI frameworks by conforming to the Element protocol. See ViewElement to see what an example implementation looks like — by providing a the frame, a snapshot image, and a few other pieces of information, all of the features described above will work for your own framework.

A Snapshot instance represents a recursive snapshot of the current state of a UI element hierarchy, and is constructed using an Element. The snapshot can then be passed to


to show the view debugger.


  • Kyle Van Essen for this tweet picturing Square's implementation that inspired me to build this
  • AudioKit SynthOne, an amazing open-source audio synthesizer app for the iPad that made for a great demo as pictured above


Download Details:

Author: indragiek
Source Code: 
License: MIT license

#swift #visualization #debugger 

A UIView Debugger That Can Be Embedded in an App

Rebugger.jl: An Expression-level Debugger for Julia


Rebugger is an expression-level debugger for Julia. It has no ability to interact with or manipulate call stacks (see Gallium), but it can trace execution via the manipulation of Julia expressions.

The name "Rebugger" has 3 meanings:

  • it is a REPL-based debugger (more on that in the documentation)
  • it is the Revise-based debugger
  • it supports repeated-execution debugging

JuliaCon 2018 Talk

While it's somewhat dated, you can learn about the "edit" interface in the following video:

However, the "interpret" interface is recommended for most users.

Installation and usage

See the documentation:

Note that Rebugger may benefit from custom configuration, as described in the documentation.

In terms of usage, very briefly

  • for "interpret" mode, type your command and hit Meta-i (which stands for "interpret")
  • for "edit" mode, "step in" is achieved by positioning your cursor in your input line to the beginning of the call expression you wish to descend into. Then hit Meta-e ("enter").
  • also for "edit" mode, for an expression that generates an error, hit Meta-s ("stacktrace") to capture the stacktrace and populate your REPL history with a sequence of expressions that contain the method bodies of the calls in the stacktrace.

Meta means Esc or, if your system is configured appropriately, Alt (Linux/Windows) or Option (Macs). More information and complete examples are provided in the documentation. If your operating system assigns these keybindings to something else, you can configure them to keys of your own choosing.


Rebugger is in early stages of development, and users should currently expect bugs (please do report them). Neverthess it may be of net benefit for some users.

Download Details:

Author: Timholy
Source Code: 
License: View license

#julia #debugger 

Rebugger.jl: An Expression-level Debugger for Julia

Debugger.jl: Julia Debugger


A Julia debugger.

Note: If you are looking for the docs for the Juno IDE debugger, see this link instead


Install Debugger using Pkg:

julia> import Pkg; Pkg.add("Debugger")


Starting the debugger interface

The debug interface is entered using the @enter macro:

using Debugger

function foo(n)
    x = n+1
    ((BigInt[1 1; 1 0])^x)[2,1]

@enter foo(20)

This interface allows for manipulating program execution, such as stepping in and out of functions, line stepping, showing local variables, setting breakpoints and evaluating code in the context of functions.

Debugger commands

Below, square brackets denote optional arguments.

All of the following commands work when the prompt is 1|debug>:


  • o: open the current line in an editor
  • q: quit the debugger, returning nothing
  • C: toggle compiled mode
  • L: toggle showing lowered code instead of source code
  • +/-: increase / decrease the number of lines of source code shown

Stepping (basic):

  • n: step to the next line
  • u [i::Int]: step until line i or the next line past the current line
  • s: step into the next call
  • so: step out of the current cal
  • sl: step into the last call on the current line (e.g. steps into f if the line is f(g(h(x)))).
  • c: continue execution until a breakpoint is hit
  • f [i::Int]: go to the i-th function in the call stack (stepping is only possible in the function at the top of the call stack)
  • up/down [i::Int] go up or down one or i functions in the call stack

Stepping (advanced):

  • nc: step to the next call
  • se: step one expression step
  • si: same as se but step into a call if a call is the next expression
  • sg: step into a generated function


  • st: show the "status" (current function, source code and current expression to run)
  • bt: show a backtrace
  • fr [i::Int]: show all variables in the current or ith frame


  • w
    • w add expr: add an expression to the watch list
    • w: show all watch expressions evaluated in the current function's context
    • w rm [i::Int]: remove all or the i:th watch expression


  • bp
    • bp add
      • bp add "file.jl":line [cond]: add a breakpoint att file file.jl on line line with condition cond
      • bp add func [:line] [cond]: add a breakpoint to function func at line line (defaulting to first line) with condition cond
      • bp add func(::Float64, Int)[:line] [cond]: add a breakpoint to methods matching the signature at line line (defaulting to first line) with condition cond
      • bp add func(x, y)[:line] [cond]: add a breakpoint to the method matching the types of the local variable x, y etc with condition cond
      • bp add line [cond] add a breakpoint to line of the file of the current function with condition cond
    • bp show all breakpoints
    • bp rm [i::Int]: remove all or the i:th breakpoint
    • bp toggle [i::Int]: toggle all or the i:th breakpoint
    • bp disable [i::Int]: disable all or the i:th breakpoint
    • bp enable [i::Int]: enable all or the i:th breakpoint
    • bp on/off
      • bp on/off error - turn on or off break on error
      • bp on/off throw - turn on or off break on throw

An empty command will execute the previous command.

Changing frames with f i::Int will change the prompt to $i|debug>. Stepping commands will not work until you return to f 1, but a subset of normal commands will continue to work.

In addition to these debugging commands, you can type ` to enter "evaluation mode" indicated by a prompt $i|julia>. In evaluation mode, any expression you type is executed in the debug context. For example, if you have a local variable named n, then once in evaluation mode typing n will show you the value of n rather than advancing to the next line.

Hit backspace as the first character of the line to return to "debug mode."


To add and manipulate breakpoints, either the bp add command in the debug interface or the JuliaInterpreter breakpoint API, documented here can be used.

It is common to want to run a function until a breakpoint is hit. Therefore, the "shortcut macro" @run is provided which is equivalent of starting the debug mode with @enter and then executing the continue command (c):

julia> using Debugger

julia> breakpoint(abs);

julia> @run sin(2.0)
Hit breakpoint:
In abs(x) at float.jl:522
>522  abs(x::Float64) = abs_float(x)

About to run: (abs_float)(2.0)
1|debug> bt
[1] abs(x) at float.jl:522
  | x::Float64 = 2.0
[2] sin(x) at special/trig.jl:30
  | x::Float64 = 2.0
  | T::DataType = Float64

Breakpoint on error

It is possible to halt execution when an error is thrown. This is done by calling the exported function break_on(:error).

julia> using Debugger

julia> break_on(:error)

julia> f() = "αβ"[2];

julia> @run f()
Breaking for error:
ERROR: StringIndexError("αβ", 2)
In string_index_err(s, i) at strings/string.jl:12
>12  @noinline string_index_err(s::AbstractString, i::Integer) =

About to run: (throw)(StringIndexError("αβ", 2))
1|debug> bt
[1] string_index_err(s, i) at strings/string.jl:12
  | s::String = "αβ"
  | i::Int64 = 2
[2] getindex_continued(s, i, u) at strings/string.jl:218
  | s::String = "αβ"
  | i::Int64 = 2
  | u::UInt32 = 0xb1000000
  | val::Bool = false
[3] getindex(s, i) at strings/string.jl:211
  | s::String = "αβ"
  | i::Int64 = 2
  | b::UInt8 = 0xb1
  | u::UInt32 = 0xb1000000
[4] f() at REPL[5]:1

julia> JuliaInterpreter.break_off(:error)

julia> @run f()
ERROR: StringIndexError("αβ", 2)

Place breakpoints in source code

It is sometimes more convenient to choose in the source code when to break. This is done for instance in Matlab/Octave with keyboard, and in R with browser(). You can use the @bp macro to do this:

julia> using Debugger

julia> function f(x)
           if x < 0
               println("All good!")
f (generic function with 1 method)

julia> @run f(2)
All good!

julia> @run f(-2)
Hit breakpoint:
In f(x) at REPL[6]:2
 1  function f(x)
 2      if x < 0
>3          @bp
 4      else
 5          println("All good!")
 6      end
 7  end

About to run: return
1|debug> bt
[1] f(x) at REPL[6]:3
  | x::Int64 = -2

Compiled mode

In order to fully support breakpoints, the debugger interprets all code, even code that is stepped over. Currently, there are cases where the interpreter is too slow for this to be feasible. A workaround is to use "compiled mode" which is toggled by pressing C in the debug REPL mode (note the change of prompt color). When using compiled mode, code that is stepped over will be executed by the normal julia compiler and run just as fast as normally. The drawback is of course that breakpoints in code that is stepped over are missed.

Syntax highlighting

The source code preview is syntax highlighted and this highlighting has some options. The theme can be set by calling Debugger.set_theme(theme) where theme is a Highlights.jl theme. It can be completely turned off or alternatively, different quality settings for the colors might be chosen by calling Debugger.set_highlight(opt) where opt is a Debugger.HighlightOption enum. The choices are HIGHLIGHT_OFF HIGHLIGHT_SYSTEM_COLORS, HIGHLIGHT_256_COLORS, HIGHLIGHT_24_BIT. System colors works in pretty much all terminals, 256 in most terminals (with the exception of Windows) and 24 bit in some terminals.

Download Details:

Author: JuliaDebug
Source Code: 
License: MIT license

#julia #debugger 

Debugger.jl: Julia Debugger
Reid  Rohan

Reid Rohan


Interactive debugger, REPL and runtime for Imba, inspired by PsySH

Imba Shell  

Interactive debugger and REPL for Imba.




npm i -g imba-shell


yarn global add imba-shell


To start using imba-shell, run the following command:


Note, you can also use imbas instead of imba-shell.


To use multi-line mode, use the .editor command:

>>> .editor

This will open a multi-line editor.


When using multi-line mode, you can use the Shift+Tab key combination to indent the current line.

To remove a tab, use the Backspace key.


To clear the imba-shell, use the clear helper:

>>> clear!

You can also use the .clear command.


To exit out of imba-shell, use the exit helper:

>>> exit!

You can also use the .exit command.

Imba Runtime

You may use imba-shell as a runtime:

imbar file.imba

imbar aliases: imba-r, imba-runtime, ir .

Passing arguments to your script:

imbar craftsman.imba mail:send --help

Continously build and watch project (development purposes):

imbar --watch server.imba

flag: --watch

alias: -w

Creating a self executing script:


#!/usr/bin/env imbar

const name = process.argv.slice(2)[0] ?? 'stranger'

console.log "Hello {name}"

If you're using Linux, FreeBSD or MacOS, you can make your script executable:

chmod u+x hello

Note: when creating a script that doesn't end with ".imba", the Imba Runtime will clone your script into a hidden file that ends with .imba and execute it instead of your original script. When done executing, the hidden file will be removed.

Running the script:

./hello Donald    # Hello Donald
./hello           # Hello stranger


imba-shell can also be used as a module. Here's an example:


import { ImbaRepl } from 'imba-shell'

const repl = new ImbaRepl 'imba> '!


const { ImbaRepl } = require('imba-shell');

const repl = new ImbaRepl('imba> ');;

Note, you can pass an object of Node.js repl options in the run function.


Here's an example of how to enable the history feature:


import { ImbaRepl } from 'imba-shell'
import os from 'os'
import path from 'path'

const repl = new ImbaRepl 'imba> ', path.join(os.homedir!, '.my_repl_history')!


const { ImbaRepl } = require('imba-shell');
const os = require('os');
const path = require('path');

const repl = new ImbaRepl('imba> ', path.join(os.homedir(), '.my_repl_history'));;

You can set any valid path as your history file.


You can register commands with the registerCommand function:


repl.registerCommand 'goodbye', do
    console.log 'Goodbye!'


repl.registerCommand('goodbye', () => {


You may register functions and properties to be available in the REPL using the registerCallback function:


const repl = new ImbaRepl

repl.registerCallback do(ctx) = 'bar'


const repl = new ImbaRepl();

repl.registerCallback((ctx) => { = 'bar'

When calling foo in the REPL, it will return bar.


  • ☑ Code completion.
  • ☑ Multiline Editor.
  • ☑ Async/Await.
  • ☑ Extensible API.
  • ☒ Syntax highlighting.
  • ☒ Imba Compile Errors.



Install dependencies:

$ npm i


Build from source:

$ npm run build


Test Imba-Shell:

$ npm run test


If you discover any security related issues, please email instead of using the issue tracker.

Author: Donaldp
Source Code: 
License: MIT license

#javascript #shell #debugger 

Interactive debugger, REPL and runtime for Imba, inspired by PsySH
Nat  Grady

Nat Grady


The Easiest Way to Run and Debug Test Cases in Electron with Jest


Easiest way to run jest unit test cases in electron.

When we run unit test in Jest, it is actually running in the node environment, or virtual browser environment(e.g. JSDOM) mocked by NodeJS. Sometimes we need a lot of Jest mocks for running code with no throw, such as: jest-canvas-mock, jest-storage-mock, @jest/fake-timers and so on. This is solved by Jest-Electron.  

  1. Technological ecology of Jest.
  2. Complete and real browser environment.
  3. Multi-renderer for running performance.
  4. Running and debug is better then mock.


  • Add into devDependencies
$ npm i --save-dev jest-electron
  • Update Jest config
  "jest": {
+    "runner": "jest-electron/runner",
+    "testEnvironment": "jest-electron/environment"

Notice: update the runner configure, not testRunner.


Those will be helpful when run test case with jest-electron.


Run test cases with jest-electron for continuous integration.

  • GitHub action

Running on macOS will be ok.

- runs-on: ubuntu-latest
+ runs-on: macOS-latest
  • travis

Update .travis.yml with electron supported.

language: node_js
  - "8"
  - "9"
  - "10"
  - "11"
  - "12"
+ addons:
+   apt:
+     packages:
+       - xvfb
+ install:
+   - export DISPLAY=':99.0'
+   - Xvfb :99 -screen 0 1024x768x24 > /dev/null 2>&1 &
+   - npm install
  - npm run test

Depending on your executor, you might need to disable sandbox and shared memory usage:

export JEST_ELECTRON_STARTUP_ARGS='--disable-dev-shm-usage --no-sandbox'
npm run test


  • debug mode

Keep the electron browser window for debugging, set process env DEBUG_MODE=1.

  • additional startup arguments

Run electron with arbitrary arguments.


Run electron with --no-sandbox, set process env JEST_ELECTRON_STARTUP_ARGS='--no-sandbox'.

JEST_ELECTRON_STARTUP_ARGS='--no-sandbox' jest

Author: Hustcc
Source Code: 
License: MIT license

#electron #jest #debugger 

The Easiest Way to Run and Debug Test Cases in Electron with Jest
Rupert  Beatty

Rupert Beatty


Laravel-tracy: A Laravel Package to integrate Nette Tracy Debugger

Nette Tracy for Laravel 5

Better Laravel Exception Handler        

Laravel Tracy


  • Visualization of errors and exceptions
  • Debugger Bar (ajax support @v1.5.6)
  • Exception stack trace contains values of all method arguments.

Online Demo



To get the latest version of Laravel Exceptions, simply require the project using Composer:

composer require recca0120/laravel-tracy --dev

Instead, you may of course manually update your require block and run composer update if you so choose:

    "require-dev": {
        "recca0120/laravel-tracy": "^1.8.14"

Include the service provider within config/app.php. The service povider is needed for the generator artisan command.

'providers' => [


php artisan vendor:publish --provider="Recca0120\LaravelTracy\LaravelTracyServiceProvider"

if you see Route [] not defined. pleace run artisan route:clear once

artisan route:clear


return [
    'enabled' => env('APP_DEBUG') === true,
    'showBar' => env('APP_ENV') !== 'production',
    'accepts'      => [
    // appendTo: body | html
    'appendTo' => 'body',
    'editor' => 'subl://open?url=file://%file&line=%line',
    'maxDepth' => 4,
    'maxLength' => 1000,
    'scream' => true,
    'showLocation' => true,
    'strictMode' => true,
    'panels' => [
        'routing' => true,
        'database' => true,
        'model' => true,
        'view' => true,
        'event' => false,
        'session' => true,
        'request' => true,
        'auth' => true,
        'html-validator' => true,
        'terminal' => true,

Editor Link


copy <vendor path>/recca0120/laravel-tracy/tools/subl-handler/subl-handler.vbs to any directory where you want to place

double click subl-handler.vbs and select editor (support eclipse, sublime, notepad++, else...)

If you use Vagrant and have issues with the incorrect path being called, you can create a symlink as illustrated at:


Prefer PhpStorm, you can edit config/tracy.php's key of editor like this:

'editor' => 'phpstorm://open?file=%file&line=%line',

Debugger Bar

Directive bdump


Ajax Debugger Bar














Custom Auth

// app/Providers/AppServiceProvider.php

namespace App\Providers;

use Recca0120\LaravelTracy\BarManager;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
    public function boot(BarManager $barManager)
        $barManager->get('auth')->setUserResolver(function() {
            return [
                'id' => 'xxx',
                'username' => 'xxx',

Html Validator

Html Validator

Web Artisan

web artisan is another package recca0120/terminal Terminal


if you install terminal before, this panel will throw errors, please remove folder app/resources/views/vendor/terminal


require __DIR__.'/../vendor/autoload.php';

use Recca0120\LaravelTracy\Tracy;

// before outout
$tracy = Tracy::instance();

$authPanel = $tracy->getPanel('auth');
$authPanel->setUserResolver(function() {
    return [
        'email' => ''

function sql($sql)
    $tracy = Tracy::instance();
    $databasePanel = $tracy->getPanel('database');

sql('select * from users');
sql('select * from news');
sql('select * from products');



Author: recca0120
Source Code: 
License: MIT license

#laravel #debugger #php 

Laravel-tracy: A Laravel Package to integrate Nette Tracy Debugger

Associations-debugger: AssociationsDebugger Plugin for CakePHP

AssociationsDebugger plugin for CakePHP

AssociationsDebugger is a simple plugin that is made for debugging associations. The point of this plugin is to quickly show different associations of your CakePHP application without you needing to browse through the model files.


  • CakePHP 3.x
  • PHP 7.2 >

Installing Using Composer

cd to the root of your app folder (where the composer.json file is) and run the following command:

composer require zunnu/associations-debugger

Then load the plugin by using CakePHP's console:

./bin/cake plugin load AssociationsDebugger


You can see the tree by going to http://app-address/associations-debugger Here you can filter by association type. Tree

This same tree can be also viewed in the CakePHP debugKit. DebugKit tree

Association structure is explained here: Structure

Author: zunnu
Source Code: 
License: MIT license

#php #debugger #cakephp 

Associations-debugger: AssociationsDebugger Plugin for CakePHP

VScode-go: Go Extension for Visual Studio Code

Go for Visual Studio Code

The VS Code Go extension provides rich language support for the Go programming language.

📣 Remote attach debugging is now available via Delve's native DAP implementation with Delve v1.7.3 or newer. It enchances remote debugging with the same debugging features that are already in use for local debugging. It is now the default with the Go Nightly build of the extension and will become the default for the stable releases in mid 2022. We recommend switching your remote attach configurations in launch.json to use "debugAdapter":"dlv-dap" now to verify that this works for you. Please file a new issue if you encounter any problems.

📣📣 Watch Debugging Treasure Hunt from GopherCon 2021 for a fun take on a debugging demo with VS Code Go and Delve DAP.

Quick Start

Welcome! 👋🏻
Whether you are new to Go or an experienced Go developer, we hope this extension fits your needs and enhances your development experience.

(Install Missing Tools)

You are ready to Go :-)    🎉🎉🎉

Please be sure to learn more about the many features of this extension, as well as how to customize them. Take a look at Troubleshooting and Help for further guidance.

If you are new to Go, this article provides the overview on Go code organization and basic go commands. Watch "Getting started with VS Code Go" for an explanation of how to build your first Go application using VS Code Go.


This extension provides many features, including IntelliSense, code navigation, and code editing support. It also shows diagnostics as you work and provides enhanced support for testing and debugging your programs. See the full feature breakdown for more details and to learn how to tune its behavior.

(Code completion and Signature Help)

In addition to integrated editing features, the extension provides several commands for working with Go files. You can access any of these by opening the Command Palette (Ctrl+Shift+P on Linux/Windows and Cmd+Shift+P on Mac), and then typing in the command name. See the full list of commands provided by this extension.

(Toggle Test File)

⚠️ Note: the default syntax highlighting for Go files is provided by a TextMate rule embedded in VS Code, not by this extension.

For better syntax highlighting, we recommend enabling semantic highlighting by turning on Gopls' ui.semanticTokens setting. "gopls": { "ui.semanticTokens": true }


The extension uses a few command-line tools developed by the Go community. In particular, go, gopls, and dlv must be installed for this extension to work correctly. See the tools documentation for a complete list of tools the extension depends on.

In order to locate these command-line tools, the extension searches GOPATH/bin and directories specified in the PATH environment variable (or Path on Windows) with which the VS Code process has started. If the tools are not found, the extension will prompt you to install the missing tools and show the "⚠️ Analysis Tools Missing" warning in the bottom right corner. Please install them by responding to the warning notification, or by manually running the Go: Install/Update Tools command.

Setting up your workspace

Go modules are how Go manages dependencies in recent versions of Go. Modules replace the GOPATH-based approach to specifying which source files are used in a given build, and they are the default build mode in go1.16+. While this extension continues to support both Go modules and GOPATH modes, we highly recommend Go development in module mode. If you are working on existing projects, please consider migrating to modules.

Unlike the traditional GOPATH mode, module mode does not require the workspace to be located under GOPATH nor to use a specific structure. A module is defined by a directory tree of Go source files with a go.mod file in the tree's root directory.

Your project may involve one or more modules. If you are working with multiple modules or uncommon project layouts, you will need to configure your workspace by using Workspace Folders. Please see this documentation about supported workspace layouts.


The extension needs no configuration and should work out of the box. However, you may wish to adjust settings to customize its behavior. Please see the settings documentation for a comprehensive list of settings. See advanced topics for further customizations and unique use cases.


If the extension isn't working as you expect, you can take a look at our troubleshooting guides. There is one for general troubleshooting, and another specifically for troubleshooting the debugging feature.

Ask for help

If the troubleshooting guides did not resolve the issue, please reach out to us by filing an issue, starting a GitHub discussion, or by asking a question on Stack Overflow.

Also, you can take a look at and for more general guidance on using Go.

Preview version

If you'd like to get early access to new features and bug fixes, you can use the nightly build of this extension. Learn how to install it in by reading the Go Nightly documentation.


We welcome your contributions and thank you for working to improve the Go development experience in VS Code. If you would like to help work on the VS Code Go extension, please see our contribution guide. It explains how to build and run the extension locally, and describes the process of sending a contribution.

Code of Conduct

This project follows the Go Community Code of Conduct. If you encounter a conduct-related issue, please mail

Author: Golang
Source Code: 
License: View license

#go #golang #vscode #debugger 

VScode-go: Go Extension for Visual Studio Code

Neo Smart Contract Debugger for Visual Studio Code

Neo Smart Contract Debugger

The Neo Smart Contract Debugger enables Neo developers to debug their smart contracts in Visual Studio and Visual Studio Code. It is built on the same virtual machine as the core Neo project to ensure maximum compatibility between the debugger and how contracts will execute in production.

Neo supports writing smart contracts in a variety of languages. However, the debugger needs the smart contract complier to emit additional information the debugger uses to map Neo Virtual Machine instructions back to source code. The debug information format is fully documented. This format is supported by a variety of Neo smart contract compilers including

Versioning Strategy

As of March 2022, the Neo Smart Contract Debugger project has adopted VS Code recommended guidance for version numbers. This will allow the VS Code Marketplace to offer production and pre-release versions of this extension. Developers will be able to choose which version to install and VS Code will automatically keep the extension up to date.

Going forward, the minor version of this extension will be even for production releases and odd for preview releases. The first production release under this new versioning strategy will ve v3.2. The first pre-release of this extension will be v3.3.

Note, this project uses NerdBank Git Versioning to manage release version numbers. As such, patch versions of public releases will typically not be sequential.


The Neo Smart Contract Debugger requires a .NET runtime to be installed. The version of .NET Core needed depends on the version of the Neo Smart Contract Debugger.

Neo Smart Contract Debugger Version.NET Core Version
v3.1v6.0 (for Neo N3 contracts)
v3.1 (for Neo Legacy Contracts)
v3.0v5.0 (for Neo N3 contracts)
v3.1 (for Neo Legacy Contracts)
v2.0 (unsupported)v5.0 (for Neo N3 contracts)
v3.1 (for Neo Legacy Contracts)
v0.9 (unsupported)v3.0
v0.5 (unsupported)v2.2

Visual Studio

The Neo Smart Contract Debugger for Visual Studio is currently in preview. To install it, download a recent release of neodebug-vs-{version}.vsix from the GitHub release page to your local machine then double click on the file.

The Neo Smart Contract Debugger for Visual Studio requires Visual Studio 2019 Community, Professional or Enterprise. It has not been tested with Visual Studio 2022 preview releases. Additionally, The Neo Smart Contract Debugger for Visual Studio requires .NET v5.0 in order to debug Neo N3 contracts as described above. Debugging Neo Legacy contracts is not supported in the Neo Smart Contract Debugger for Visual Studio.

Additional documentation on using The Neo Smart Contract Debugger for Visual Studio is available.

Visual Studio Code

The Neo Smart Contract Debugger for Visual Studio Code can be installed via the Visual Studio Code Marketplace. It can be installed by itself or as part of the Neo Blockchain Toolkit.

The Neo Smart Contract Debugger requires a .NET runtime to be installed. The version of .NET Core needed depends on the version of the Neo Smart Contract Debugger.

As of version 2.0, the Neo Smart Contract Debugger for Visal Studio Code supports both Neo N3 and Neo Legacy.

Ubuntu Installation

Using the checkpoint functionality on Ubuntu requires installing libsnappy-dev and libc6-dev via apt-get.

> sudo apt install libsnappy-dev libc6-dev -y

MacOS Installation

Using the checkpoint functionality on MacOS requires installing rocksdb via Homebrew

> brew install rocksdb

Install Preview Releases

The Neo Smart Contract Debugger has a public build server. You can install preview builds of the debugger by navigating to the build you wish to install, pressing the "Artifacts" button in the upper right hand corner and downloading the VSIX-package artifact. The artifact is a zip file containing the debugger VSIX file, which can be installed manually. For more information on installing VSIX extensions in VSCode, please see the official VSCode docs.

A Message from the Engineer

Thanks for checking out the Neo Smart Contract Debugger! I am eager to hear your opinion of the product.

If you like the debugger, please let me know on Twitter, email or the Neo Discord server.

If there are things about the debugger you don't like, please file issues in our GitHub repo. You can hit me up on Twitter, Discord or email as well, but GitHub issues are how we track bugs and new features. Don't be shy - file an issue if there is anything you'd like to see changed in the product.

Most software is built by teams of people. However, the Neo Smart Contract Debugger so far has been a solo effort. I'm looking forward to having other folks contribute in the future, but so far it's just been me. That means that the debugger has been designed around my experiences and my perspective. I can't help it, my perspective is the only one I have! :) So while I find the debugger intuitive, I realize that you may not feel the same. Please let me know if this is the case! I didn't build the Neo Smart Contract Debugger for me, I built it for the Neo developer community at large. So if there are changes we can make to make it more accessible, intuitive, easier to use or just flat-out better - I want to hear about them.

Thanks again for checking out the Neo Smart Contract Debugger. I look forward to hearing from you.

- Harry Pierson (aka DevHawk), Chief Architect ngd enterprise

Download Details:
Author: neo-project
Source Code:
License: MIT license

#neo  #blockchain  #smartcontract #debugger #visualstudiocode #csharp 

Neo Smart Contract Debugger for Visual Studio Code
Ray  Patel

Ray Patel


Common Anti-Patterns in Python

Improve and streamline your code by learning about these common anti-patterns that will save you time and effort. Examples of good and bad practices included.

1. Not Using with to Open Files

When you open a file without the with statement, you need to remember closing the file via calling close() explicitly when finished with processing it. Even while explicitly closing the resource, there are chances of exceptions before the resource is actually released. This can cause inconsistencies, or lead the file to be corrupted. Opening a file via with implements the context manager protocol that releases the resource when execution is outside of the with block.

2. Using list/dict/set Comprehension Unnecessarily

3. Unnecessary Use of Generators

4. Returning More Than One Object Type in a Function Call

5. Not Using get() to Return Default Values From a Dictionary

#code reviews #python programming #debugger #code review tips #python coding #python code #code debugging

Common Anti-Patterns in Python
Samanta  Moore

Samanta Moore


What Remote Debugging Means For Java Applications

Remote debugging is becoming a best practice for cloud application development due to gaps with logging and breakpoints, so how does this work for Java apps?

Following the lingering promise of managed infrastructure, reduced operational cost, and resiliency, cloud computing has seen phenomenal trends in adoption since the past decade. As software development marches towards the cloud, we soon realize that this shift warrants the need to rethink our debugging strategies. This is because as software systems are now leveraging these advancements in cloud computing and distributed systems we see gaps emerging in debugging that cannot be satisfied by the traditional methods of logging and breakpoints.

For example, a major issue while using breakpoints is that the codebase needs to be run in debug mode. Therefore, we are not actually replicating the actual state of our systems taking into consideration multi-threading, distributed services, and dependencies on remote services in a cloud-native environment along with multi-service architecture. Similarly, logs offer no respite, as they may be cumbersome and even costly to execute and store.

Therefore, considering the new era of technology and software, we see a movement to redefine debugging practices to better suit this new world. This is where we see the birth of remote debugging. A debugging technique that aims to provide the solution for cloud development and all its pitfalls when it comes to traditional debugging in the cloud or basic remote landscape. It allows debugging a system when the system itself is not in the local environment of the developer by setting up a connection between the developer’s local environment and the service to be debugged that sits on a remote server.

Therefore, this article aims to expand on why remote debugging is needed, the disadvantages that may arise, and how we can go about remote debugging Java applications.

#java #testing #cloud computing #monitoring #jvm #debugging #observability #debugger #java libraries #remote debugging

What Remote Debugging Means For Java Applications

Rider 2021.1: Updates to Docker and C# Support, Scaffolding in ASP.NET, and More!

Update to Docker Support

Adding Docker support to a project in Rider is now easier – you can generate the Dockerfile while creating a new project. Just select Docker Support in the New project dialog. If you want to add a Dockerfile to an existing project, use** Add | Docker Support** in the context menu for a project in the Solution Explorer tool window.

Rider can also run Dockerfiles generated by Visual Studio with no additional changes required from you.

#net-tools #releases #debugger #c# #c++ #c

Rider 2021.1: Updates to Docker and C# Support, Scaffolding in ASP.NET, and More!