Skip to content
This repository has been archived by the owner on Dec 13, 2018. It is now read-only.

Hack: Clicking on errorcount in statusbar jumps on line above #2

Closed
SiebelsTim opened this issue May 24, 2015 · 2 comments
Closed

Hack: Clicking on errorcount in statusbar jumps on line above #2

SiebelsTim opened this issue May 24, 2015 · 2 comments

Comments

@SiebelsTim
Copy link

I guess it's supposed to jump on the line with the error, displaying the error. But the cursor is on the line above when clicking on it.

To be clear what I am meaning with errorcount in statusbar:
nucl4

Not sure if this is Atom Linter related.
@SiebelsTim SiebelsTim changed the title Clicking on errorcount in statusbar jumps on line above Hack: Clicking on errorcount in statusbar jumps on line above May 24, 2015
@steelbrain
Copy link

It's an AtomLinter thingy, We've already fixed it in it's rewrite repo https://github.com/AtomLinter/linter-plus/pull/3#issuecomment-105521081

jgebhardt pushed a commit that referenced this issue Aug 31, 2015
@rameshvarun
Service Framework 3.0 Diff #2 - TypeRegistry
e3c43a6
@ssorallen
Copy link
Contributor

Closing this since Nuclide now uses its own nuclide-diagnostics-ui and this issue was for the AtomLinter.

ghost pushed a commit that referenced this issue Apr 22, 2016
Use faster setText when replacing entire buffer contents
539c6d7 
Summary:`setText` is 3-4x faster than `setTextViaDiff`. Using it when replacing
the entire contents of the buffer makes clicking through files in the
diff-view tree show the file up to 100ms faster.

**Test run #1**

setText, 39.4ms:
{F60653266}

setTextViaDiff, 170.5ms:
{F60653267}

**Test run #2**

setText, 68.4ms:
{F60653269}

setTextViaDiff, 171.8ms:
{F60653270}

Reviewed By: mostafaeweda

Differential Revision: D3203887

fb-gh-sync-id: 7d78e07373d688654f6f6f723f30013ffe9e06fd
fbshipit-source-id: 7d78e07373d688654f6f6f723f30013ffe9e06fd
ghost pushed a commit that referenced this issue Jun 17, 2016
@jgebhardt
Bump version to 0.144.0 #2
e5b14a4 
Reviewed By: zertosh

Differential Revision: D3447867

fbshipit-source-id: ab27d1f90fcb2f6fa01c284ee6323e7ace06cb89
ghost pushed a commit that referenced this issue Jun 23, 2016
@johnislarry
Console diff #2 -- Limit the number of records sent per evaluation re…
1ee55a7 
…quest

Summary: Fixes a bug where the console gets sent multiple records while stepping

Reviewed By: yinghuitan

Differential Revision: D3413092

fbshipit-source-id: 95d22fa774eddb47ed3398e769e13038ed2ed01f
ghost pushed a commit that referenced this issue Jun 24, 2016
@johnislarry
Slog + debugger diff #2 -- Start slog automatically when debugger att…
b8f3a02 
…aches

Reviewed By: jgebhardt

Differential Revision: D3473898

fbshipit-source-id: a77344d82b31ceee96f5b7f89551434e1e177ffa
facebook-github-bot pushed a commit that referenced this issue Jul 29, 2016
@johnislarry
breakpoint notifications #2 -- genericize the atom service singleton …
4d80b10 
…as AtomServiceContainer

Summary:
As per the comments on D3625375, this genericizes the singleton class used to hold the output
service, so that it can hold other atom services as well, such as the notification service.

Reviewed By: yinghuitan

Differential Revision: D3642633

fbshipit-source-id: da1da2d538665f3986796b8c1f75cd45e9a878f3
ghost pushed a commit that referenced this issue Aug 9, 2016
@zertosh
Delay quick-open panel creation until used
f3a446d 
Summary:
This diff reduces Nuclide's startup time by ~80ms. Most of this expense is the result of two forced layouts caused by quick-open: (1) measuring the document's height for the scrollable area `max-height` calculation, and (2) adding the panel to the DOM.

To fix #1, instead of setting the height in javascript of the scrollable area, it's set using CSS. The `max-height` is now `calc(100vh - GAPpx)`. Not only is this less taxing on Atom, but the modal now shrinks smoothly as you resize.

To fix #2, moved the panel creation code into the Activation class' render. Since that function got kinda big, I trimmed some of the unnecessary bits - like most of the styling on the modal parent.

Reviewed By: jgebhardt

Differential Revision: D3683543

fbshipit-source-id: 3b09bdcdd7f3aabb4e9162d68fbf6cdc44434f40
ghost pushed a commit that referenced this issue Aug 23, 2016
@johnislarry
Debugger Eval #2 -- Refactor WES logic out of the Bridge
37af0fa 
Summary:
Prior to this diff, the Bridge handled a lot of evaluation logic.  This is sub-optimal for two reasons:

1. It overloads the Bridge, whose purpose is to just be a forwarding layer to/from chrome's model/the backend.
2. It makes following the lifetime of an evaluation request complicated, because you have to understand how the WES and Bridge interoperate.

This diff pulls the logic out of the Bridge entirely, and puts it into the WES.  When the Bridge gets evaluation responses from the backend, it uses flux actions to communicate this with the WES.

Reviewed By: yinghuitan

Differential Revision: D3699243

fbshipit-source-id: 10bd479e46dc58dced9c384888476cdda416dbf8
ghost pushed a commit that referenced this issue Sep 23, 2016
@johnislarry
request sender #2 -- Add http sender package boilerplate
610f043 
Summary: boilerplate for http sender package

Reviewed By: jgebhardt

Differential Revision: D3807371

fbshipit-source-id: aab89cf5cd43a8abf4267572a724d9f34216a672
ghost pushed a commit that referenced this issue Sep 23, 2016
@johnislarry
request sender #2.5 -- Hook up http-request-sender to services
ae92dae 
Summary: We want to provide a service from this package that other packages can consume, so that they can provide default form values such as uri, request method, and other request data

Reviewed By: jgebhardt

Differential Revision: D3837523

fbshipit-source-id: 044667c710d1b68413a3ce0aa5e7ae1085c79cf5
facebook-github-bot pushed a commit that referenced this issue Oct 7, 2016
@johnislarry
iwdp debugger #2 -- refactor to use WebSocketServer
414f7a9 
Summary: yinghuitan introduced this class and it's a better way to organize this boilerplate-y websocket/rpc service code that the nuclide-side of the debugger needs.

Reviewed By: jgebhardt

Differential Revision: D3969919

fbshipit-source-id: ca7d2e43eb2d7b48b358aa0f92312a2b817c1cf3
facebook-github-bot pushed a commit that referenced this issue Dec 6, 2016
@johnislarry
Relax ordering restriction for eval ids
e0725e7 
Summary:
Here is a correct scenario in which evaluation requests can be completed "out of order":

1. eval request #1 is sent, push #1 onto stack
2. eval request #2 is sent, push #2 onto stack
3. response for #1 comes back from HHVM, pop #2 off stack
4. #1 != #2 so the invariant is triggered

So we can be more lax about the expected order that we receive responses.  In general, there's no reason to impose any restrictions on the ordering in which requests and responses happen, so let's just use a set.

Changelog: Fix for PHP debugger evaluation crashes.

Reviewed By: yinghuitan

Differential Revision: D4282772

fbshipit-source-id: 7d6169fa660d489b06b1a28e07140fa11a5464e4
facebook-github-bot pushed a commit that referenced this issue Feb 3, 2017
@johnislarry @facebook-github-bot
disposal #2: Introduce onDispose API for DebuggerConnection
0893ec8 
Summary:
This new API is used to couple the lifetimes of resources related to a DebuggerConnection, which will
simplify bottom up disposal.

Differential Revision: D4505686

fbshipit-source-id: ca0b9905b41f79432eaf4c3c205cb033e8a9c77b
facebook-github-bot pushed a commit that referenced this issue Sep 28, 2017
@ebluestein @facebook-github-bot
Support launching native debug targets in the Nuclide terminal
b2bcb8b 
Summary:
This change will allow launching of a native binary under the debugger using the Terminal where available. The user can opt out of this via a new config setting.

When launching in the terminal, STDIN and STDOUT will be redirected to the terminal, so the user can interact with the target app in addition to interacting with the debugger engine (which is still done via the Console pane).

For Native targets, we support configuring the CWD as well as passing environment variables for the terminal to use when launching.

Since Linux doesn't have a mechanism to create process suspended, if we just launch the target directly and then try to attach LLDB, there is a race where we risk missing initial breakpoints set early in the program's startup, this would not be acceptable. To make this work properly, a wrapper script and some synchronization is needed to ensure LLDB is attached to the process before it gets to start executing.

The synchronization flow in this diff works like this:

1. Nuclide front-end (from LaunchProcessInfo) calls prepareForTerminalLaunch on the Nuclide native debugger RPC service
2. The backend determines the proper paths for python, the wrapper (launch.py in this diff) and the executable.
3. The backend spawns a TCP socket server that listens on a new port and waits.
4. The backend returns the values from step #2, and the port from step #3 to the front-end as launch instructions.
5. The front-end launches the wrapper script *in a new terminal pane* using the path and args the back end gave it.
6. The wrapper script connects to the listening TCP socket to talk to the debugger back end, and writes its own PID into the socke and then issues a read on the TCP socket - *this causes it to block*
7. The debugger backend receives the PID, attaches LLDB to the specified PID and then writes to the TCP socket to unblock the wrapper
8. The wrapper is unblocked from TCP read and issues an execv() syscall to replace itself with the target image, which is now free to begin execution with LLDB attached.
9. The backend closes the TCP sockets and cleans up the server.
... debugging continues as normal from here on.

Reviewed By: rightparen

Differential Revision: D5898651

fbshipit-source-id: 1c48b7eff53e0c9a2e665a42fe0de2f884c88b5b
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ssorallen @SiebelsTim @steelbrain