jschlatter's comments

They started with Ink but have since switched to their own renderer:

> We originally built Claude Code on Ink, a React renderer for the terminal. [...] Over the past few months, we've rewritten our rendering system from scratch (while still using React).

https://github.com/anthropics/claude-code/issues/769#issueco...

> They have the technical means to control what goes on there or not.

They have less control than you may think.

Any ethereum miners (or proof-of-stake validators) who block some class of transactions immediately become vulnerable to denial of service attacks.

This came up back in 2016 with the DAO hack on ethereum[1]. Some ethereum miners considered blocking transactions that moved the stolen funds, but then realized that this was infeasible: if you block such transactions, then the DAO hacker can spam you with them. Such spam on ethereum is usually prevented by requiring the sender to spend money on each transaction (ie pay gas fees). But that fee is only charged when the transaction is included in a block -- if you refuse to include it, then the spammer pays nothing. The kicker is that, by Rice's theorem, there is no way in general to distinguish "malicious" transactions from non-malicious ones (for _any_ definition of "malicious") short of just executing them to see what they do.

So if you as an ethereum miner (or validator) try to block certain transactions, you can be forced to do unbounded amounts of work for free, ie DoS'd.

[1] https://hackingdistributed.com/2016/07/05/eth-is-more-resili...

I do subscribe to channels and my feed is also flooded with these scams. (Though usually it is not this bad -- it got much worse starting on the day of SpaceX's Inspiration 4 launch.)

I'm assuming the algorithm is showing them to me because I watch lots of SpaceX and other space videos. The descriptions in these videos are even ripped directly from legit videos that I actually watched!

You're not the only one. I've been getting annoyed by these, too.

I was encouraged today to discover that youtube has a report history page that lets you know the outcome of your reports. Most of the videos I've reported have been removed, including most of the ones I've reported in the last 12 hours. So at least _something_ is being done about them, even though the current effort is not sufficient against the unending inflow of new scam videos.

Here's the report history page: https://www.youtube.com/reporthistory

LiteIDE was probably using gdb as a backend. gdb is not a very reliable debugger as of the last few Go releases. Here's a demo of a common failure mode of gdb on Go: occasionally running the entire program when you try to take a single step https://youtu.be/qo4RAPxCTa0?t=351

This failure mode is a large part of why I decided to write godebug.

Thanks for the concrete example. The transformed source code that would get compiled for this example looks like:

  scope.Declare("x", &x)
  godebug.Line(ctx, scope, 3)
  x = 1
  godebug.Line(ctx, scope, 4)
  x = 2
  godebug.Line(ctx, scope, 5)
  bar()

The value of x is visible to all of the godebug.Line calls, so the compiler should know that it can't move x = 2 to after the call to bar.

"Also, having the debugging library alter the semantics of the program is 100% guaranteed to lead to bugs that are not visible when using the library, etc"

Can you give an example of the kind of bug you expect to see?

Thanks! gopherjs is a really great project. This was my first time using it and I was impressed.

I've considered putting it up as a permanent playground like http://play.golang.org, where you can debug little Go snippets on the web. Is that something that you would find useful?

Yeah, that should be relatively easy to do. We would just skip the "am I the goroutine under the debugger" check here [1] and add some kind of channel communication here [2]. The hardest thing is probably just the UI. How should that functionality work? I'm imagining something like this:

  >>> pause all
  All goroutines paused
  >>> show goroutines
  1: foo.go:16
  2: foo.go:24
  3. bar.go:10 [current]
  >>> next
  -> // some code from goroutine 3
  >>> goroutine 2
  Now tracing goroutine 2. Current location:
  /*
     Code listing from goroutine 2's current location
  */
  >>> next
  -> // some code from goroutine 2

Is this the kind of interface you were imagining?

[1] https://github.com/mailgun/godebug/blob/5c173f56b398bc13fd41... [2] https://github.com/mailgun/godebug/blob/5c173f56b398bc13fd41...

EDIT: formatting

Good question. I think https://news.ycombinator.com/item?id=9411158 is right, but I haven't looked at it closely yet. Thanks for bringing it up!

Author here. Yes, only one goroutine is paused at a time. I'm planning to add commands to show and jump between goroutines. Still sketching those out, though. Do you think it would be helpful to have multiple goroutines paused by the debugger at once?

> Another is that you may inadvertently corrupt or change the behavior of the code in an unintentional way if you modify it incorrectly

I'm concerned about this, too. One of my next high priorities for godebug is to download many open source projects and search for behavior differences caused by the debugger. I would also like to generate new programs and test them as well.

> But, you get the easy 80% with this for sure. I'm just prodding you to work on the other 20%.

I will. I'm excited about the project and want to make it as useful as I can.

Thanks, I didn't know that. The go/token docs don't say much about it. Do you know if there is better documentation somewhere?

Author here. I agree that this could cause surprises. Are there specific cases you have in mind?

Two cases I have thought of are stack traces and logging that inspects the stack. In the former case, if you get a stack trace while debugging it will not mean much because the lines do not match those of your code. In the latter case, logging statements may print the wrong things if they depend on being called a certain number of stack frames below user code. glog does this, for example[1]. I don't have solutions to either case yet, but I have some ideas of how to start. I think the utility the tool provides is well worth those two issues, and I'm hopeful that both can be fixed.

[1] https://github.com/golang/glog/blob/master/glog.go#L536

I made a very similar extension last week (https://chrome.google.com/webstore/detail/always-smile/fpaap...) and encountered this issue, too. You can resolve it by going to http://smile.amazon.com and choosing your charity. After that, the extension should work as expected.