imgyuri

it's easy to create one, or use something like https://github.com/jarrodwatts/claude-hud

the way compaction works is pretty simple and highly relies on another model to do it, the only part the user has control of is when to do the compaction, which actually means when doing large amount of work in one shot, it should be planned from the beginning to be separated into works that can be reviewed, afterwards the model can compact

How can the overall trajectory length be the same across reasoning efforts? I don't see how this is possible even if reasoning is not included in the trajectory length calculation.

I feel like all these fat skills on top of agents will become stale very quickly. Unless it is for a very specific workflow with a need for deterministic outputs, I just don't see them having high value.

If I do need such workflows I just use plan mode, and it is 90% sufficient. I created a skill that hooks on top of plan mode because of its shortcomings, but I'm pretty sure even this will become obsolete soon as models improve.

https://github.com/oliver-im/jidoka

for ghostty users check out https://ghostty.org/docs/help/macos-tiling-wms

agree on the quality, there's a reason it usually shows up top in the search results

because there are multiple abstractions in software that one is bound to come across once the software becomes complicated enough, and from that point on "passion" and "fundamentals" determine how effective they are at navigating that path

does anyone know how the new window shows the original terminal instead of the browser? do i need to switch the profile each time?

> And learning modern React ecosystem from the scratch is no easy undertaking even for experienced developer.

I don't see a scenario where this is likely, other than if you're contributing directly to the react codebase.

i'd recommend https://www.refactoringui.com/ to first get build your design "sense". it's fairly simple to build simple UI these days since the default components of design libraries are quite nice.

couldn't agree more. actually i don't understand how such a distinguished faculty can have such a primitive view of the industry.

indeed, it's almost a certainty that every framework and tool in the JS ecosystem becomes obsolete as time goes by.

I'm pretty sure the pinned tweet is an exact reference in one of his essays.

For those who don't know, their website https://vcstarterkit.com/ is pretty amusing as well.

What if the text was rendered as an image on the server, then sent to the device?

I don't know about his books(courses?), but his site PyImageSearch is one of the more well known sites regarding computer vision. I certainly got a lot of help from the site (Thanks Adrian).

In terms of capturing the screen input for training, the fps is capped at 10 fps. This is following the number suggested in NVIDIA's paper[1], which cautions against overfitting. The program captures faster when the steering angle gets larger, because it suggests that curvy road is ahead, which are the more challenging scenarios for the program.

In terms of testing, the max fps is determined by the performance of the GPU and the complexity of the model. I couldn't find any definitive studies done on the matter, but anywhere from 10-30 fps seems to work OK.

[1] https://arxiv.org/abs/1604.07316

Yes, and this is by design. However the controlling logic will probably have to be customized for each additional game.

Euro Truck Simulator was chosen because it runs on Windows/OS X/Linux, and because the game consists mainly of highway roads, which is an easier target than urban environments.

Also I just really like the game itself.

Wow, definitely did not expect this to blow up like this.

Thanks everyone!

OP