HackerTrans
トップ新着トレンドコメント過去質問紹介求人

kretaceous

3,133 カルマ登録 6 年前
https://abhijithota.com

投稿

[untitled]

1 ポイント·投稿者 kretaceous·一昨日·0 コメント

The Website Is Down

thewebsiteisdown.com
10 ポイント·投稿者 kretaceous·11 日前·0 コメント

OpenCode drops Claude Pro/Max subscription support per Anthropic's legal request

github.com
6 ポイント·投稿者 kretaceous·4 か月前·1 コメント

Obamify

obamify.com
2 ポイント·投稿者 kretaceous·8 か月前·2 コメント

Nanotyrannus confirmed as a new species, not juvenile T-Rex

nature.com
2 ポイント·投稿者 kretaceous·8 か月前·0 コメント

CMU team claims vector-based system can turbocharge PostgreSQL

theregister.com
2 ポイント·投稿者 kretaceous·9 か月前·0 コメント

Grounding with Google Maps in the Gemini API

blog.google
7 ポイント·投稿者 kretaceous·9 か月前·0 コメント

The algorithm will see you now

worksinprogress.co
2 ポイント·投稿者 kretaceous·10 か月前·0 コメント

コメント

kretaceous
·2 か月前·議論
A digital theremin! Very fun.
kretaceous
·3 か月前·議論
Can you give examples of how they are different? I've only done OOP in JS so I'm not aware of what I'm missing or what's supposed to be different.
kretaceous
·5 か月前·議論
Suppose there's the following situation:

    Summary A = summarise(message 1 to P)
    Summary B = summarise(Summary A, message P+1 to Q)
    Summary C = summarise(Summary B, message Q+1 to R)
What does calling lcm_expand(Summary C) do? Does it unroll all messages from message 1 to message R or does it unroll to Summary B and message Q+1 to R?

> volume is potentially arbitrarily large is that one sub-agent can call lcm_expand multiple times - either vertically or horizontally

I'm assuming from this that it's the latter? In that case, that addresses my concern about not blowing up the context window immediately.
kretaceous
·5 か月前·議論
Re: the lcm_expand(summaryID) tool

> Because expansion can recover arbitrarily large volumes of earlier conversation, this tool is restricted to sub-agents spawned via the Task tool; the main agent cannot call it directly. This restriction prevents uncontrolled context growth in the primary interaction loop.

What if the lcm_expand is called for a summary that has 1000s of messages that immediately floods the sub-agent's own context window?

Does lcm_expand only unroll one "layer" of the DAG and unrolls more if needed by another subagent?
kretaceous
·5 か月前·議論
This is really cool and something I've envisioned building for a long time!

There is a bug in the entity tracking. For the entity "github", it shows a positive sentiment. HN does NOT like GitHub (for reasons good or bad). If you click on it, it shows you stories about other seemingly unrelated stories.

https://ethos.devrupt.io/entities/github
kretaceous
·7 か月前·議論
Getting into reading again this year after a long break.

The most memorable read of this year was "The Count of Monte Cristo" (1846) by Alexander Dumas .

It's one of the greatest stories ever told. It's ~1250 pages but I sped through it in 3 weeks even if I'm a slow reader.

Highly recommended!

I also read The Stranger by Camus and the two top Orwells which lived up to the hype.
kretaceous
·7 か月前·議論
I'm confused by what Cursor is trying to be. They shipped plan mode and debug mode which are developer focused tools and I'm happy about them.

On the other hand, features like these are kinda distracting to me. I wouldn't mind if it wasn't for the core product and developer features getting buggier day by day.

I've been facing a number of rough edges lately. The plan mode's support for multiple plans in a single chat breaks often, todos don't get created or marked properly, the new changed files UX is atrocious (just take me to the file), it's not able to adhere to simple prompts in a low context window usage chat (Sonnet 4.5), etc.

It sucks to try different editors every few months but I might have to do that if this continues.
kretaceous
·7 か月前·議論
> We’ve seen 2x speed improvements in type checking times for internal projects when using TSGO.

That's a lot less that what TSGO promised when it was first announced (A 10x faster Typescript¹). Hopefully this is just the result of it being experimental.

1: https://devblogs.microsoft.com/typescript/typescript-native-...
kretaceous
·7 か月前·議論
Interesting things from this:

- Smallest animal: Myxobolus Shekel. Smaller than a WBC at 10 micrometeres.

- Biggest butterfly: Queen Alexandra's Birdwing. Bigger than human brain at 18cm.

- Largest insect to ever live: Meganeura (283 MYA). At 40cm long, a dragonfly larger than a house cat.

- Rafflesias are larger than German Shepherds

- Earth's largest crab: Japanese Spider Crab. 1m, legs pan of 3.75m. More than half the size of a human.

- Always thought Mososaurs were largest animal to ever live but it's the Blue whale at 26m. I don't think I ever appreciated how unfathomably huge they are. (The largest Mosasaur found was 13m. There's a speculated size of 17m as well.)

- World's largest living tree: Hyperion - a giant redwood in california at 115m.

Love seeing something so polished and inspiring. Amazing illustrations and even better music.

Thanks Neal for these projects!
kretaceous
·7 か月前·議論
Exactly my thoughts. The only incompatibility with Bun is the unavailability of the `using` keyword:

> If you are using Bun (which doesn't natively support using and uses a transpiler which is incompatible with this library)...

I skimmed the issues but I couldn't find any issues on Bun regarding this except for: https://github.com/oven-sh/bun/discussions/4325
kretaceous
·7 か月前·議論
A linter rule provided by the library could be helpful here. I know it's just a workaround but probably easier than going for a solution that does compile time checks.
kretaceous
·10 か月前·議論
I need the search service so bad.

I attempted something like this because I wanted a good books search service which provided me at-a-glance information I needed from Storygraph & Goodreads. The main things I look for when I search a book is genres/Storygraph's "moods", number of pages, whether it's part of a series, rating across services & how much does it cost.

Could never make it work properly.
kretaceous
·4 年前·議論
That's fair. Go is not as fast and cannot manage resources as well as the languages you mentioned.
kretaceous
·4 年前·議論
Seems like you need Go then? You mention you want memory management, type safety and proper abstractions, hence the suggestion.

Of course, you also mentioned C's syntax as awkward for you, so you might feel the same with Go's syntax.