transchan(3tcl)

📦
version 9.0.4 · 3 versions
, in ubuntu resolute, ubuntu stonking

✨ transchan — bestie edition ✨

okay so you want to know about transchan, the Tcl built-in command page for the command handler API for channel transforms implemented in Tcl code. it's from the 3tcl manual, and it's genuinely iconic once it clicks. let's go 💅

💖 NAME 💖

transchan — the command handler API for channel transforms implemented in Tcl code. that's it, that's the whole vibe. 🦋

🌸 SYNOPSIS 🌸

chan push channel cmdPrefix

cmdPrefix clear handle
cmdPrefix drain handle
cmdPrefix finalize handle
cmdPrefix flush handle
cmdPrefix initialize handle mode
cmdPrefix limit? handle
cmdPrefix read handle buffer
cmdPrefix write handle buffer

🎀 DESCRIPTION 🎀

so the Tcl-level handler for a channel transformation has to be a command with subcommands. the manpage calls it an ensemble — but lowkey don't panic, that does not mean it has to be made with namespace ensemble create. this mechanism is not tied to namespace ensemble in any way, fr fr. they're just using the word. 🙈

cmdPrefix is literally whatever you passed in the call to chan push, and bestie, it may consist of multiple arguments — it all gets expanded into multiple words in place of the prefix. so don't @ me when your prefix is three words long.

of all the possible subcommands, the handler must support initialize and finalize. that's the non-negotiable core. then:

  • transformations for writable channels must also support write
  • transformations for readable channels must also support read
heads up: in everything below, cmdPrefix might be more than one word, and handle is the value returned by the chan push call you used to create the transformation. don't lose that handle. she's your main character. 👑

🌈 GENERIC SUBCOMMANDS 🌈

these ones are relevant to all types of channel. everyone's invited to this party. 🫶

  • cmdPrefix clear handle — this optional subcommand gets called to tell the transformation that any data stored in internal buffers — incoming or outgoing, both of them — must be cleared. it's called when a chan seek is performed on the channel being transformed. so basically: wipe the slate, babe. 🧹
  • cmdPrefix finalize handle — this one is mandatory. it's called last for the given handle, and then never again, periodt. its whole job is to let you clean up any Tcl-level data structures associated with the transformation.
⚠️ Warning! Any errors thrown by this subcommand will be ignored. and it is not guaranteed to be called if the interpreter is deleted. so don't put your hopes and dreams in there. 💀
  • cmdPrefix initialize handle mode — this one is also mandatory. it's called first, and then never again for the given handle. its responsibility is to initialize all parts of the transformation at the Tcl level. the mode is a list containing any of read and write:
    • write implies that the channel is writable.
    • read implies that the channel is readable.

the return value of the subcommand should be a list containing the names of all subcommands supported by this handler. and listen — any error thrown by the subcommand will prevent the creation of the transformation. that thrown error will appear as an error thrown by chan push. so if you fumble the initialize, the whole thing never gets born. no cap. 😭

these are the ones for handling transformations applied to readable channels. technically read is optional, but — and this is the important part — it must be supported if any of the others is, or the channel will be made non-readable. choose wisely bestie. 🙈

  • cmdPrefix drain handle — optional subcommand, called whenever data in the transformation input (i.e. the read buffer) has to be forced upward — toward the user or script. the result returned by the method is taken as the binary data to push upward to the level above this transformation (the reader, or a higher-level transformation).

in other words: when this method gets called, the transformation cannot defer the actual transformation operation anymore. she has to transform all data waiting in her internal read buffers and return the result of that action. no more procrastinating. ✨

  • cmdPrefix limit? handle — optional subcommand, called to let the Tcl I/O engine figure out how far ahead it should read. if it's present, it should return an integer number greater than zero which indicates how many bytes ahead should be read, or an integer less than zero to indicate that the I/O engine may read as far ahead as it likes. (yes the subcommand name has a ? in it. we love a quirky queen. 💅)
  • cmdPrefix read handle buffer — this subcommand must be present if the transformation is going to work with readable channels. it's called whenever the base channel, or a transformation below this transformation, pushes data upward. the buffer contains the binary data which has been given to us from below. it is the responsibility of this subcommand to actually transform the data. the result returned by the subcommand is taken as the binary data to push further upward to the transformation above this transformation. this can also be the user or script that originally read from the channel. 🫶

and note — the result is allowed to be empty, or even less than the data we received. the transformation is not required to transform everything given to it right now. it's allowed to store incoming data in internal buffers and to defer the actual transformation until it has more data. so, y'know, hoarding is legal here. 🍓

these are for handling transformations applied to writable channels. again, write is technically optional, but it must be supported if any of the others is, or the channel will be made non-writable. the stakes are real. 🔥

  • cmdPrefix flush handle — optional subcommand, called whenever data in the transformation 'write' buffer has to be forced downward — toward the base channel. the result returned by the subcommand is taken as the binary data to write to the transformation below the current transformation. this can be the base channel as well.

in other words: when this subcommand is called, the transformation cannot defer the actual transformation operation anymore. she has to transform all data waiting in her internal write buffers and return the result of that action. clock's ticking, babe. ⏰

  • cmdPrefix write handle buffer — this subcommand must be present if the transformation is going to work with writable channels. it's called whenever the user, or a transformation above this transformation, writes data downward. the buffer contains the binary data which has been written to us. it is the responsibility of this subcommand to actually transform the data. 💪

the result returned by the subcommand is taken as the binary data to write to the transformation below this transformation. this can be the base channel as well. and note — the result is allowed to be empty, or less than the data we got. the transformation is not required to transform everything which was written to it right now. it's allowed to store this data in internal buffers and to defer the actual transformation until it has more data. iconic behaviour honestly. 👑

👑 SEE ALSO 👑

chan(3tcl), refchan(3tcl) — go read your sisters, bestie, they're part of the same friend group. 💜

🌟 KEYWORDS 🌟

API, channel, ensemble, prefix, transformation

and that's the whole page, bestie!! you ate this. 💖✨🎀🦋🌸💅🫶

sign-off time 🥰 — this is from Tcl, version 8.6, and the manual section is transchan(3tcl). go transform some channels, queen. 💅🌈

📦 where this page comes from