https://www.boundaryml.com logo
Powered by
so basically both v1 and v2 are used to
# contributing
g
so basically both v1 and v2 are used to parsed the llm output in the user defined structure, it just that model rebuild compiled the validation logic of each class written in type.py, due to which converting the llm output into class object become faster for v2,where as in v1 we have the just python code for validation which is basically a interpreted language, and its validation is slow and in our pr, for 2.1.0 pydantic verstion we have the issue of forward ref, so we explicitly mention the model rebuild at last, so model resbuild is doing both work : handling forward reference and giving compiled validation logic but only in case pydantic v2, for v1 it just solve the forward reference.
Actually what happen is, the class that breaks isn't actually inside a cycle — it just uses a recursive alias. For example, RecursiveAliasDependency has a field value: JsonValue, and JsonValue is the recursive one. So the existing cycle results don't catch it, because they only tell me what's in a cycle, not which classes that are not part of cycle but will ulimately reached to a cycle. To find those classes, I have to follow the dependency links from each class. That's why I ended up building my own graph and walking it The reason I rebuilt it is that the IR only carries the cycle results, not the dependency graph. The real graph (class_dependencies) and the Tarjan pass live in parser-database. So now what i was thinking is to do this inside parser-database, reusing the existing class_dependencies graph instead of building a new one, and then expose the result so the Python generator just uses it. Is that the direction you want, or is there an existing function you'd prefer I build on?
a
hey gorspeed, we unfortunately have detected you might be a bot, and might have to block you. You might have to join an office hours call to keep being in the discord
g
ok
a
CC it seems @baml-sam already msged you?? Sorry if we got it wrong!
b
The updated version of https://github.com/BoundaryML/baml/pull/3819 looks good to me, hopefully this works!
Looks like a bunch of CI stuff is failing. I usually have good success with this by telling Claude to look at .github/workflows/primary.yml and run all of the jobs in it by hand, and then once pushed it'll usually be good. Also looks like all the tests are passing now, just needs to pass fmt/lint - once that's all addressed we can merge
g
the only real failure was rust-format. The other lint jobs (clippy, python, typescript) weren't actually failing, they got cancelled by fail-fast once rust-format failed. I fixed that. @baml-sam , actually Right now the dependency-graph and reachability code lives in lib.rs (the generator). I think the cleaner approach is to move it into parser-database, since most of what we need is already there. Breaking it down: - Cycle results (the seed): already available in parser-database, so we reuse them and write nothing new. - The dependency graph: parser-database already has class_dependencies, so we don't rebuild it. This is the part that gets eliminated from the generator. - The reachability check ("does this class reach the seed?"): this still needs to be written, but it runs on the existing class_dependencies graph instead of building a new one. Then we expose the result on the IR, and lib.rs just consumes it in one line. So we reuse the graph the engine already has, instead of rebuilding it in the generator. but if you are ok with current approach, then i have already raised the fix for CI issues, please approve the workflow.
b
Queued to merge!
The existing implementation is the right one (reusing the cycle fixpoint sets) - parser-database is compiler internals that we try very very hard to not expose to anyone because it gives too much uncontrolled/unprincipled access to the source code structs.
Merged! We'll try to get this released next week 🙂
g
ok
PreviousNext
Powered by