Conference Guide

Dion Systems - Q&A
?
?

Keyboard Navigation

Global Keys

[, < / ], > Jump to previous / next episode
W, K, P / S, J, N Jump to previous / next marker
t / T Toggle theatre / SUPERtheatre mode
V Revert filter to original state Y Select link (requires manual Ctrl-c)

Menu toggling

q Quotes r References f Filter y Link c Credits

In-Menu Movement

a
w
s
d
h j k l


Quotes and References Menus

Enter Jump to timecode

Quotes, References and Credits Menus

o Open URL (in new tab)

Filter Menu

x, Space Toggle category and focus next
X, ShiftSpace Toggle category and focus previous
v Invert topics / media as per focus

Filter and Link Menus

z Toggle filter / linking mode

Credits Menu

Enter Open URL (in new tab)
0:01Ryan Fleury: How should we do this?
0:01Ryan Fleury: How should we do this?
0:01Ryan Fleury: How should we do this?
0:06Allen Webster: You start
0:06Allen Webster: You start
0:06Allen Webster: You start
0:18philliptrudeau Could this integrate with other, text-based languages like Zig / Odin / Jai, or is this a far larger enterprise?
0:18philliptrudeau Could this integrate with other, text-based languages like Zig / Odin / Jai, or is this a far larger enterprise?
0:18philliptrudeau Could this integrate with other, text-based languages like Zig / Odin / Jai, or is this a far larger enterprise?
0:29RF: Dion is a new base format for languages
0:29RF: Dion is a new base format for languages
0:29RF: Dion is a new base format for languages
1:15AW: Transition path to Dion
1:15AW: Transition path to Dion
1:15AW: Transition path to Dion
2:15Abner Coimbre: There's weird background noise coming from Ryan's end
2:15Abner Coimbre: There's weird background noise coming from Ryan's end
2:15Abner Coimbre: There's weird background noise coming from Ryan's end
2:48RF: Sorry for connection issues
2:48RF: Sorry for connection issues
2:48RF: Sorry for connection issues
2:54epsylon How do you deal with code order? (i.e. code order has influence on generated code, which means builds can be non-deterministic)
2:54epsylon How do you deal with code order? (i.e. code order has influence on generated code, which means builds can be non-deterministic)
2:54epsylon How do you deal with code order? (i.e. code order has influence on generated code, which means builds can be non-deterministic)
3:15AW: Dealing with code order
3:15AW: Dealing with code order
3:15AW: Dealing with code order
4:42forkingpaths Could you elaborate (maybe at the end) on your uniform input system?
4:42forkingpaths Could you elaborate (maybe at the end) on your uniform input system?
4:42forkingpaths Could you elaborate (maybe at the end) on your uniform input system?
4:51RF: Uniform input system
4:51RF: Uniform input system
4:51RF: Uniform input system
6:29AW: "Notepad" version of Dion
6:29AW: "Notepad" version of Dion
6:29AW: "Notepad" version of Dion
6:59kogyblack So it wouldn't matter if I use Vim and code in some specific language? Dion will have to have support for parsing the AST for that language and abstract the vim windows, which to me seems too complicated, so I guess it will need some specific editor, like 4coder, and only be possible to parse some specific languages that it has enough information. It's an impressive project, I just feel it seems that we have a strong change to migrate to it
6:59kogyblack So it wouldn't matter if I use Vim and code in some specific language? Dion will have to have support for parsing the AST for that language and abstract the vim windows, which to me seems too complicated, so I guess it will need some specific editor, like 4coder, and only be possible to parse some specific languages that it has enough information. It's an impressive project, I just feel it seems that we have a strong change to migrate to it
6:59kogyblack So it wouldn't matter if I use Vim and code in some specific language? Dion will have to have support for parsing the AST for that language and abstract the vim windows, which to me seems too complicated, so I guess it will need some specific editor, like 4coder, and only be possible to parse some specific languages that it has enough information. It's an impressive project, I just feel it seems that we have a strong change to migrate to it
7:35RF: Dion won't support all textual languages / editors
7:35RF: Dion won't support all textual languages / editors
7:35RF: Dion won't support all textual languages / editors
8:24andrewrk Does the language have conditional compilation (e.g. if Windows do this, if Linux do that) and, if so, how does that interact with the renaming feature?
8:24andrewrk Does the language have conditional compilation (e.g. if Windows do this, if Linux do that) and, if so, how does that interact with the renaming feature?
8:24andrewrk Does the language have conditional compilation (e.g. if Windows do this, if Linux do that) and, if so, how does that interact with the renaming feature?
8:45AW: Dion has the bones for conditional compilation
8:45AW: Dion has the bones for conditional compilation
8:45AW: Dion has the bones for conditional compilation
10:15the_danch I am curious: why did you decide to allow users to make errors (as opposed to tech like Scratch)? What benefits do you see there? Could you elaborate on that? Cheers! Good job!
10:15the_danch I am curious: why did you decide to allow users to make errors (as opposed to tech like Scratch)? What benefits do you see there? Could you elaborate on that? Cheers! Good job!
10:15the_danch I am curious: why did you decide to allow users to make errors (as opposed to tech like Scratch)? What benefits do you see there? Could you elaborate on that? Cheers! Good job!
10:26AW: Permissive error handling
10:26AW: Permissive error handling
10:26AW: Permissive error handling
12:54jhurst Are the rendering decisions stored in the AST or is there a different data structures? Like the Slice / View thing
12:54jhurst Are the rendering decisions stored in the AST or is there a different data structures? Like the Slice / View thing
12:54jhurst Are the rendering decisions stored in the AST or is there a different data structures? Like the Slice / View thing
13:03RF: Dion's rendering decisions
13:03RF: Dion's rendering decisions
13:03RF: Dion's rendering decisions
14:21AW: Editor vs Language vs Format Features
14:21AW: Editor vs Language vs Format Features
14:21AW: Editor vs Language vs Format Features
15:56henriquedelima Great job on the presentation! Question: Is Dion supposed to be a complete "eco-system", or could it be used with arbitrary languages (C, C++, Zig, Odin, etc.)?
15:56henriquedelima Great job on the presentation! Question: Is Dion supposed to be a complete "eco-system", or could it be used with arbitrary languages (C, C++, Zig, Odin, etc.)?
15:56henriquedelima Great job on the presentation! Question: Is Dion supposed to be a complete "eco-system", or could it be used with arbitrary languages (C, C++, Zig, Odin, etc.)?
16:06RF: Dion is not suitable for arbitrary languages
16:06RF: Dion is not suitable for arbitrary languages
16:06RF: Dion is not suitable for arbitrary languages
16:57AW: Extra-language problems fallback, e.g. version control
16:57AW: Extra-language problems fallback, e.g. version control
16:57AW: Extra-language problems fallback, e.g. version control
18:08moustapha Do you translate the AST to C then compile it into executable, or do you compile it directly?
18:08moustapha Do you translate the AST to C then compile it into executable, or do you compile it directly?
18:08moustapha Do you translate the AST to C then compile it into executable, or do you compile it directly?
18:20AW: Translation into C
18:20AW: Translation into C
18:20AW: Translation into C
19:12laurie Is there a risk that by tightly coupling so many parts of the system (language, editor, version control etc.), it will make it very difficult for it to gain traction? It feels like to succeed it will have to compete with so many other tools
19:12laurie Is there a risk that by tightly coupling so many parts of the system (language, editor, version control etc.), it will make it very difficult for it to gain traction? It feels like to succeed it will have to compete with so many other tools
19:12laurie Is there a risk that by tightly coupling so many parts of the system (language, editor, version control etc.), it will make it very difficult for it to gain traction? It feels like to succeed it will have to compete with so many other tools
19:25RF: Dion introduces the base format, uncoupled
19:25RF: Dion introduces the base format, uncoupled
19:25RF: Dion introduces the base format, uncoupled
20:18forkingpaths Can you give a glimpse of how a user would define its own language on top of Dion?
20:18forkingpaths Can you give a glimpse of how a user would define its own language on top of Dion?
20:18forkingpaths Can you give a glimpse of how a user would define its own language on top of Dion?
20:29AW: Defining a language on top of Dion
20:29AW: Defining a language on top of Dion
20:29AW: Defining a language on top of Dion
22:34usdaproved Will we be able to drag little code snippets anywhere on the screen at some point? Such that you can have to things side by side?
22:34usdaproved Will we be able to drag little code snippets anywhere on the screen at some point? Such that you can have to things side by side?
22:34usdaproved Will we be able to drag little code snippets anywhere on the screen at some point? Such that you can have to things side by side?
22:48RF: Code organisation ideas
22:48RF: Code organisation ideas
22:48RF: Code organisation ideas
24:06spex_guy It seems like saving to a text format would solve a lot of problems (version control, diffs, etc), can you expand on the reasons you chose not to do this?
24:06spex_guy It seems like saving to a text format would solve a lot of problems (version control, diffs, etc), can you expand on the reasons you chose not to do this?
24:06spex_guy It seems like saving to a text format would solve a lot of problems (version control, diffs, etc), can you expand on the reasons you chose not to do this?
24:20AW: Feature trade-offs
24:20AW: Feature trade-offs
24:20AW: Feature trade-offs
25:52nexo Is it possible to convert existing code to one used by Dion? If you use LLVM for example as a backend for compilation then I assume it should be not so hard to generate proper AST tree from "compilable code"
25:52nexo Is it possible to convert existing code to one used by Dion? If you use LLVM for example as a backend for compilation then I assume it should be not so hard to generate proper AST tree from "compilable code"
25:52nexo Is it possible to convert existing code to one used by Dion? If you use LLVM for example as a backend for compilation then I assume it should be not so hard to generate proper AST tree from "compilable code"
26:06RF: No story for converting from C to Dion
26:06RF: No story for converting from C to Dion
26:06RF: No story for converting from C to Dion
26:34AW: Transpiling from text-based to Dion's base format
26:34AW: Transpiling from text-based to Dion's base format
26:34AW: Transpiling from text-based to Dion's base format
27:32ginger_bill Because everything is effectively an AST, have you thought about representing different ideas with regards to control flow which would not be easily expressible in textual based languages?
27:32ginger_bill Because everything is effectively an AST, have you thought about representing different ideas with regards to control flow which would not be easily expressible in textual based languages?
27:32ginger_bill Because everything is effectively an AST, have you thought about representing different ideas with regards to control flow which would not be easily expressible in textual based languages?
27:40RF: Ideas for Dion's control flow: Loops
27:40RF: Ideas for Dion's control flow: Loops
27:40RF: Ideas for Dion's control flow: Loops
28:56AW: Ideas for Dion's control flow: Break / Continue
28:56AW: Ideas for Dion's control flow: Break / Continue
28:56AW: Ideas for Dion's control flow: Break / Continue
30:26dustin_bragg Is it a decent summary to say that Dion is redefining what "code" is, as a textualization of something much closer to the actual AST, as apposed to a new specific language? Instead of a C compiler compiling text files, they compile Dion files?
30:26dustin_bragg Is it a decent summary to say that Dion is redefining what "code" is, as a textualization of something much closer to the actual AST, as apposed to a new specific language? Instead of a C compiler compiling text files, they compile Dion files?
30:26dustin_bragg Is it a decent summary to say that Dion is redefining what "code" is, as a textualization of something much closer to the actual AST, as apposed to a new specific language? Instead of a C compiler compiling text files, they compile Dion files?
30:40RF: Dion is a base format
30:40RF: Dion is a base format
30:40RF: Dion is a base format
31:41azmr (Maybe out of scope for the talk...) Could you talk a bit about your thoughts on Dion as a protocol / file format that would be usable in other contexts / in tools made by others? Or is Dion expected to always be the base layer application platform?
31:41azmr (Maybe out of scope for the talk...) Could you talk a bit about your thoughts on Dion as a protocol / file format that would be usable in other contexts / in tools made by others? Or is Dion expected to always be the base layer application platform?
31:41azmr (Maybe out of scope for the talk...) Could you talk a bit about your thoughts on Dion as a protocol / file format that would be usable in other contexts / in tools made by others? Or is Dion expected to always be the base layer application platform?
31:54RF: Making tools to put Dion into practice
31:54RF: Making tools to put Dion into practice
31:54RF: Making tools to put Dion into practice
32:44usdaproved You brought up that Visual Studio falls over when it comes to preprocessor stuff. Did you solve this problem? I don't think I saw any preprocessing
32:44usdaproved You brought up that Visual Studio falls over when it comes to preprocessor stuff. Did you solve this problem? I don't think I saw any preprocessing
32:44usdaproved You brought up that Visual Studio falls over when it comes to preprocessor stuff. Did you solve this problem? I don't think I saw any preprocessing
32:54AW: Dion has no preprocessor
32:54AW: Dion has no preprocessor
32:54AW: Dion has no preprocessor
33:42forkingpaths Any thoughts on live code editing in Dion? Since you know exactly which parts of the AST must be recompiled
33:42forkingpaths Any thoughts on live code editing in Dion? Since you know exactly which parts of the AST must be recompiled
33:42forkingpaths Any thoughts on live code editing in Dion? Since you know exactly which parts of the AST must be recompiled
33:52RF: No story for hot reloading
33:52RF: No story for hot reloading
33:52RF: No story for hot reloading
35:16matias How would you address security issues such as reverse-engineering a project stored in the Dion format?
35:16matias How would you address security issues such as reverse-engineering a project stored in the Dion format?
35:16matias How would you address security issues such as reverse-engineering a project stored in the Dion format?
35:25AW: No more known security vulnerabilities in Dion
35:25AW: No more known security vulnerabilities in Dion
35:25AW: No more known security vulnerabilities in Dion
36:28greg I think a risk for this project is Microsoft catching wind of it and employing the team to work on VS-Dion. How would you avoid that, assuming you'd want to?
36:28greg I think a risk for this project is Microsoft catching wind of it and employing the team to work on VS-Dion. How would you avoid that, assuming you'd want to?
36:28greg I think a risk for this project is Microsoft catching wind of it and employing the team to work on VS-Dion. How would you avoid that, assuming you'd want to?
36:39RF: No plans or concerns for Microsoft
36:39RF: No plans or concerns for Microsoft
36:39RF: No plans or concerns for Microsoft
37:01AW: Wanting the problem to be solved, by whoever
37:01AW: Wanting the problem to be solved, by whoever
37:01AW: Wanting the problem to be solved, by whoever
37:59kogyblack Seems clear. The main question was about integration with existing text editors, like vim, and existing languages. If we need to create plugins for every tool we currently use or if we have to totally migrate to Dion tools only, which would be bad for any user
37:59kogyblack Seems clear. The main question was about integration with existing text editors, like vim, and existing languages. If we need to create plugins for every tool we currently use or if we have to totally migrate to Dion tools only, which would be bad for any user
37:59kogyblack Seems clear. The main question was about integration with existing text editors, like vim, and existing languages. If we need to create plugins for every tool we currently use or if we have to totally migrate to Dion tools only, which would be bad for any user
38:29RF: Migration to Dion
38:29RF: Migration to Dion
38:29RF: Migration to Dion
39:15usdaproved How do you think you will handle all the money and fame that is bound to come because of this project?
39:15usdaproved How do you think you will handle all the money and fame that is bound to come because of this project?
39:15usdaproved How do you think you will handle all the money and fame that is bound to come because of this project?
39:21RF: Keep working on Dion
39:21RF: Keep working on Dion
39:21RF: Keep working on Dion
39:28AW: Retire to an island to do game jams
39:28AW: Retire to an island to do game jams
39:28AW: Retire to an island to do game jams
39:48onatt0 Not sure if this was asked: Can the types be propagated through the AST?
39:48onatt0 Not sure if this was asked: Can the types be propagated through the AST?
39:48onatt0 Not sure if this was asked: Can the types be propagated through the AST?
39:55AW: Type info is not encoded in the AST
39:55AW: Type info is not encoded in the AST
39:55AW: Type info is not encoded in the AST
41:58tarriestpython One issue I have with a lot of existing IDEs / editors is that a lot of the helper information, such as highlighting / complete suggestions etc. is that for large or complicated codebases (especially with include stuff in C) is that the systems that provide these often don't / work or are so slow that you have to wait a long time for it to enable because it's being computed in the background. It seems with Dion most of these issues will be non-existent as most of the information needed to support these features are stored in the encoding of the source. Would you say this is a fair observation of what Dion is doing?
41:58tarriestpython One issue I have with a lot of existing IDEs / editors is that a lot of the helper information, such as highlighting / complete suggestions etc. is that for large or complicated codebases (especially with include stuff in C) is that the systems that provide these often don't / work or are so slow that you have to wait a long time for it to enable because it's being computed in the background. It seems with Dion most of these issues will be non-existent as most of the information needed to support these features are stored in the encoding of the source. Would you say this is a fair observation of what Dion is doing?
41:58tarriestpython One issue I have with a lot of existing IDEs / editors is that a lot of the helper information, such as highlighting / complete suggestions etc. is that for large or complicated codebases (especially with include stuff in C) is that the systems that provide these often don't / work or are so slow that you have to wait a long time for it to enable because it's being computed in the background. It seems with Dion most of these issues will be non-existent as most of the information needed to support these features are stored in the encoding of the source. Would you say this is a fair observation of what Dion is doing?
42:29RF: Dion's move to structured information
42:29RF: Dion's move to structured information
42:29RF: Dion's move to structured information
43:40michaebartnett You replied to me and someone else saying codebase scalability is something you think you can solve. Can you elaborate more? Curious on your thoughts with doing things like rename transformations or struct member addition / deletion across millions of "lines"
43:40michaebartnett You replied to me and someone else saying codebase scalability is something you think you can solve. Can you elaborate more? Curious on your thoughts with doing things like rename transformations or struct member addition / deletion across millions of "lines"
43:40michaebartnett You replied to me and someone else saying codebase scalability is something you think you can solve. Can you elaborate more? Curious on your thoughts with doing things like rename transformations or struct member addition / deletion across millions of "lines"
43:54AW: Dion's codebase scalability
43:54AW: Dion's codebase scalability
43:54AW: Dion's codebase scalability
46:39AC: We have time for a couple more questions
46:39AC: We have time for a couple more questions
46:39AC: We have time for a couple more questions
47:01RF: The ping number keeps going up
47:01RF: The ping number keeps going up
47:01RF: The ping number keeps going up
47:21jhuculak Given that you're storing as an AST and have sets, you could theoretically give a visual / graph representation like blueprints or visualize it as text. Are those things you're interested in? I would find it interesting, especially with the sets that people could visualize code in more extreme ways
47:21jhuculak Given that you're storing as an AST and have sets, you could theoretically give a visual / graph representation like blueprints or visualize it as text. Are those things you're interested in? I would find it interesting, especially with the sets that people could visualize code in more extreme ways
47:21jhuculak Given that you're storing as an AST and have sets, you could theoretically give a visual / graph representation like blueprints or visualize it as text. Are those things you're interested in? I would find it interesting, especially with the sets that people could visualize code in more extreme ways
47:47RF: Code representation
47:47RF: Code representation
47:47RF: Code representation
48:31AW: Implicit sets of operations
48:31AW: Implicit sets of operations
48:31AW: Implicit sets of operations
49:08benjipede How do you see this working with metaprogramming? Generating code as a string seems to not make sense, so only generating AST constructs directly seems to be available
49:08benjipede How do you see this working with metaprogramming? Generating code as a string seems to not make sense, so only generating AST constructs directly seems to be available
49:08benjipede How do you see this working with metaprogramming? Generating code as a string seems to not make sense, so only generating AST constructs directly seems to be available
49:19RF: Dion's relationship with metaprogramming
49:19RF: Dion's relationship with metaprogramming
49:19RF: Dion's relationship with metaprogramming
50:35AW: Replacing string generation with node generation
50:35AW: Replacing string generation with node generation
50:35AW: Replacing string generation with node generation
51:16ilia.demianenko How many hours of work was put into this project to get to the current state?
51:16ilia.demianenko How many hours of work was put into this project to get to the current state?
51:16ilia.demianenko How many hours of work was put into this project to get to the current state?
51:25AW: Started in March 2020, side-project time
51:25AW: Started in March 2020, side-project time
51:25AW: Started in March 2020, side-project time
51:52RF: All side-project time
51:52RF: All side-project time
51:52RF: All side-project time
52:12AC: Plug Handmade Seattle's Media Page1
52:12AC: Plug Handmade Seattle's Media Page1
52:12AC: Plug Handmade Seattle's Media Page1
52:44AC: Thanks to Allen and Ryan
52:44AC: Thanks to Allen and Ryan
52:44AC: Thanks to Allen and Ryan
52:54RF: Thanks, Abner
52:54RF: Thanks, Abner
52:54RF: Thanks, Abner
You have arrived at the (current) end of 2020