#initialisms yak shave
1 messages · Page 1 of 1 (latest)
time="2025-06-10T14:37:47Z" level=info msg="http: panic serving @: argument \"url\" not found\ngoroutine 448 [running]:\nnet/http.(*conn).serve.func1()\n\t/usr/lib/go/src/net/http/server.go:1947 +0xbe\npanic({0x2abb700?, 0xc0209dfab0?})\n\t/usr/lib/go/src/runtime/panic.go:792 +0x132\ngithub.com/dagger/dagger/dagql.Field[...].Args(0x0?, {0xc011214160, 0x8, 0xc00fd64630?})\n\t/app/dagql/objects.go:1230 +0x4f4\ngithub.com/dagger/dagger/core/schema.(*gitSchema).Install(0xc0227abe80)\n\t/app/core/schema/git.go:50 +0xa5e\ngithub.com/dagger/dagger/core/schema.(*CoreMod).Install(0x3989000?, {0xc0209de4a0?, 0xc003fc0840?}, 0xc00116cc40)\n\t/app/core/schema/coremod.go:61 +0x63e\ngithub.com/dagger/dagger/engine/server.(*Server).initializeDaggerClient(0xc000778608, {0x3996f78, 0xc003ac1680}, 0xc0001ffe00, 0xc001162fc0, 0xc0006627d0)\n\t/app/engine/server/session.go:583 +0x15d1\ngithub.com/dagger/dagger/engine/server.(*Server).getOrInitClient(0xc000778608, {0x3996f78, 0xc003ac1680}, 0xc0006627d0)\n\t/app/engine/server/session.go:824 +0xbd6\ngithub.com/dagger/dagger/engine/server.(*Server).serveHTTPToClient(0xc000778608, {0x3989230, 0xc001117960}, 0xc0001ff7c0, 0xc0006627d0)\n\t/app/engine/server/session.go:995 +0xef6\ngithub.com/dagger/dagger/engine/server.(*Server).ServeHTTP.httpHandlerFunc[...].func1(0xc0001ff7c0)\n\t/app/engine/server/session.go:1548 +0x31\nnet/http.HandlerFunc.ServeHTTP(...)\n\t/usr/lib/go/src/net/http/server.go:2294\ngithub.com/dagger/dagger/engine/server.(*Server).ServeHTTP(0xc000778608, {0x3989230, 0xc001117960}, 0xc0001ff7c0)\n\t/app/engine/server/session.go:904 +0x162\nmain.main.func2.2({0x3989230?, 0xc001117960?}, 0x0?)\n\t/app/cmd/engine/main.go:423 +0x9d\nnet/http.HandlerFunc.ServeHTTP(0xc003ac1050?, {0x3989230?, 0xc001117960?}, 0x419534?)\n\t/usr/lib/go/src/net/http/server.go:2294 +0x29\ngolang.org/x/net/http2/h2c.h2cHandler.ServeHTTP({{0x3964740?, 0xc026f58e10?}, 0xc001254f50?}, {0x3989230, 0xc001117960}, 0xc0001ff7c0)\n\t/go/pkg/mod/golang.org/x/net@v0.41.0/http2/h2c/h2c.go:125 +0x673\nnet/http.serverHandler.ServeHTTP({0xc003ac1020?}, {0x3989230?, 0xc001117960?}, 0x6?)\n\t/usr/lib/go/src/net/http/server.go:3301 +0x8e\nnet/http.(*conn).serve(0xc001128ea0, {0x3996f78, 0xc0034e68a0})\n\t/usr/lib/go/src/net/http/server.go:2102 +0x625\ncreated by net/http.(*Server).Serve in goroutine 407\n\t/usr/lib/go/src/net/http/server.go:3454 +0x485"
here's how it looks in the CLI:
❯ dagger-dev -m workspace shell
▼ connect 9.1s ERROR
! start session: connect buildkit session: read response: unexpected EOF
├─● starting engine 0.0s
├─▶ connecting to engine 9.1s
╰─✘ starting session 0.1s ERROR
! connect buildkit session: read response: unexpected EOF
gonna nuke the volume and start fresh in case it's somehow related
commit 94398f28962a76056d9d8e9383a876af59ec954d (upstream/main, upstream/HEAD, main)
Author: Justin Chadwell <me@jedevc.com>
Date: Tue Jun 10 15:01:09 2025 +0100
chore: prep for v0.18.10 (#10559)
first time was against 7a93970f5
huh i'm also seeing this inside dagger call test specific --run Interface/IfaceCall (test unrelated, it's just what i happened to run)
so the stack trace seems like there's an issue with setting up the dagql handlers
we're trying to attach docs for url - but somehow it's not being found
docker volume rm dagger-engine.dev finally finished, so trying a fresh dev engine now
very strange how CI wouldn't have caught this if it's a real thing
nope, same error
time="2025-06-10T14:53:40Z" level=info msg="http: panic serving @: argument \"url\" not found\ngoroutine 357 [running]:\nnet/http.(*conn).serve.func1()\n\t/usr/lib/go/src/net/http/server.go:1947 +0xbe\npanic({0x2abc780?, 0xc000b48080?})\n\t/usr/lib/go/src/runtime/panic.go:792 +0x132\ngithub.com/dagger/dagger/dagql.Field[...].Args(0x0?, {0xc000ab0160, 0x8, 0xc0009b2360?})\n\t/app/dagql/objects.go:1230 +0x4f4\ngithub.com/dagger/dagger/core/schema.(*gitSchema).Install(0xc0006a8b50)\n\t/app/core/schema/git.go:50 +0xa5e\ngithub.com/dagger/dagger/core/schema.(*CoreMod).Install(0x398a440?, {0xc00066feb0?, 0xc00066b860?}, 0xc000882930)\n[... snipped ...]
okay super weird, i do not see the same issue 🤔
something something random iteration order, and my CPU is in a different timezone?
will poke through code and see what i can find
oh this could be related to local changes
i started shaving the initialisms/acronyms yak
AH
and "url" is a little 
ngl that does sound very sus
i got here because LLM() was being turned into l-lm 
okok, most likely false alarm, sorry for the immediate post-release scare 😂
😅
confirmed 🙇♂️
initialisms yak shave
alright im gluing the hair back on the yak, this seems like a nightmare. unless someone really wants me to keep going
😢 damn, yeah, it really is.
we're so dependent on magic casing in so many places
basically, we want "LLM" to convert to "llm" when used as an arg, but "EvalsLLM" instead of "EvalsLlm" for ToCamel
which doesn't seem possible with strcase?
i seem to rajat gave it a go a while back, and he converted a load of stuff
ah right
the problem at it's core is that doing this in a backwards compat way is not? super fun
this has been in the back of my head for an eventual v1.0, we would completely rip out strcase and centralize everything neatly in one place
yeah for sure
we've also got our custom implementation in the go sdk
er, codegen
yup, each sdk does it's own thing as well 😢
which i started moving to the go sdk so we can at least share it between CLI/codegen/engine, but yeah, that's the smallest part
i know @tawny zodiac is working on / interested on working on a thing to centralize some of the logic of codegen in one place
that feels like a step towards the right place?
this would be a surefire candidate for that yeah
i had a thought to just have a .json file of our casing rules or something, so all the SDKs can load it up
wonder if there's any prior art to this
🤔 that's a fun idea
i've thought about having the engine do all the splits? and then the sdks just send/recv nameParts []string or something
but also, yes, horrible
just about anything is better than the status quo haha. that could be an API or something 
an oddly specific one, but it kinda makes sense, we already have a notion of 'original name' vs. 'converted name' so it's within the fold to some extent
i mean if it's all in the typedef api, then we could just hook in a nameParts field to everything there
then each sdk could pick up on those... it would even be possible to have a easy backwards-compat check (if <version, use old name, otherwise, join together nameParts in some way)
i think you would still need knowledge of initialisms on top of that when joining, but that also becomes language specific. Ruby would want EvalsLlm, Go would want EvalsLLM
maybe it's not just []string? something like []struct{part string, isInitialism bool}
or similar
Yeah, I started experimenting with that in the codegen module. I think it's a good solution, that can be added to TypeDefs. Basically you'd keep initialisms here, like:
LLMevals LLM
So Go would preserve the casing before upper casing each start of each word:
LLMEvalsLLM
Typescript would lower case everything and camel case it:
llmevalsLlm
Python would lower case everything and replace the separator with underscore (similar for CLI):
llmevals_llm
It could be up to each SDK to return the right word split so the engine, or at least have it has a possibility for override in case the engine does it wrongly. As for the other direction, could also be converted to target conventions by the engine rather than languages so SDK just has to pick the right result from convention rather than doing the conversion itself.
ah yeah that's a cute way to condense the info into just []string
if lowercase => not acronym
if uppercase => acronym, decide whether to preserve (language-specific)
Yeah, that's been on my mind for a long time for centralizing codegen, which I want it to be based on typedefs rather than graphql schema, but this could be added to typedefs directly as a first step. Would make these conversions much simpler and consistent between languages.