#workspace + shell = DX breakdown

1 messages · Page 1 of 1 (latest)

proud dome
#

🧵

#

I'm adding ToyWorkspace.shell() and it's not going well 😛

#

I have to choose between A) returning stdout or B) saving container changes (via chaining). Model expects both

dry heath
proud dome
#

How do we address this in a fundamental way? cc <@&946480760016207902>

#

oh wow lots of people on the maintainers group 🙂 sorry

#

Should we treat this as A) "you're holding it wrong" or B) "we're going to need a better DX"

#

In other words, is it a superficial problem, or a deeper one

proud dome
fringe peak
#

Need clarification on the problem, is it that in the shell you want to keep operating on chained objects across multiple shell invocations? Like today you have to do

thing=$(some command)
thing2=$(thing | some other command)
thing3=$(thing2 | yet another command)

?

proud dome
# fringe peak Need clarification on the problem, is it that in the shell you want to keep oper...

For me at least:

  • It's not about what I want but what the LLM expects 🙂
  • The llm sees a function called shell and assumes it works like a regular shell in a regular mutable system. We simulate this in the rest of the workspace (read, write) but can't for shell, because the same function can't both return a chainable state, and a string
  • I am not saying that I want the ability to return both a chainable state and a string. I don't know what the right course of action is - hence the batsign
dry heath
proud dome
#

I'm going to prioritize multi-object today. It might force us to revisit some of these assumptions anyway

fringe peak
#

I'm not following, hence my other message about reviewing the PR, hopefully that'll help fill in some gaps along with some more playing with it locally 😄

dry heath
#

Based on your earlier question I'll point out that shell here isn't dagger shell, it's a func (m *MyMod) shell() *MyMod {} that runs a shell command in a container/workspace

proud dome
#

oh yeah sorry

fringe peak