Metaissue: Improve the interpreter

[straight-shoota]

What's missing for the interpreter:

• [x] #11159
• [x] Type promotion for variadic arguments (#11795)
• [x] Crystal::Loader integration (#11579)
• [ ] Syscalls
• [x] Pending lib bindings (libxml, libyaml)
  • [x] libyml (#11801)
  • [x] libxml2 (#11802)
• [ ] Musl libc support
  • [ ] Support for statically linked compiler
• [ ] Check concurrency implementation
• [ ] Documentation (manpages, crystal-book)
• [x] Improved REPL UX
  • [x] Specs for REPL (https://github.com/crystal-lang/crystal/pull/11717#issuecomment-1007430185)
  • [x] History and line edit (#11340)
  • [x] Syntax highlighting (#11366)
• [x] Windows support (#14964)
  • [x] Runtime loader for windows (https://github.com/crystal-lang/crystal/pull/12140)
• [ ] asm support (interpreter bytecode)
• [ ] Stack alignment (#14832)
• [ ] Arm support ( #12299)
• [ ] More specs
• [ ] 100 other TODOs in src/compiler/crystal/repl

Feel free to post comments for additional items here.

No discussion on individual items. Thank you 🙇‍♂️

That should be moved to dedicated issues. If none exists, please open one or start an informal discussion at https://forum.crystal-lang.org/

[asterite]

I think pry doesn't work well in many cases. For example, block arguments are not visible. In general, I feel that pry has still a long way to go

[asterite]

After https://github.com/crystal-lang/crystal/pull/11578 is merged, the first thing I would do is to write at least one spec for debugger and pry. There's a lot to fix and improve there, and without tests it's going to be tough.

My idea was to have tests specify three things:

• a source, which has a debugger call in it
• given input
• expected output

For example:

assert_interpreter_debugger(
  code: "a = 1; debugger; a",
  input: "a",
  expected_output: "1",
)

That is, after debugger is reached, the user types "a" on the console, and they expect to get "1" as the output.

This will require adapting the interpreter so that the input and output are not tied to STDIN and STDERR, which might also eventually make it possible to hook the interpreter into code editors.

These tests will also be independent of the underlying implementation, so they will be extremely useful and resilient to changes.

With those tests in place, I could start working on some of them to fix existing bugs, like https://github.com/crystal-lang/crystal/issues/11555#issuecomment-989295051

[beta-ziliani]

@asterite just to clarify, each of the lines stating BUG: missing handling... is a TODO waiting to be completed, right? (Just stumble across one of this).

[asterite]

That's it! Maybe I should have put a TODO there 😅

[watzon]

I assume the issue that happens when attempting to require "openssl" or anything that relies on openssl is included in one of these subtasks? The issue seems to be different based on whether you require openssl in the repl or in a file the interpreter is running, but both break.

If other people aren't having this problem for some reason I'll gladly make a new issue.

[HertzDevil]

That is, after debugger is reached, the user types "a" on the console, and they expect to get "1" as the output.

#12119 does this for LLDB. We could probably use FileCheck here or even share the same test source files for multiple CLI debuggers (another one I have in my mind is GDB).

[mwgkgk]

https://github.com/Ivo-Balbaert/programming_crystal/blob/master/exercises/crystal_new/fibers.cr

Something really slow about channels. crystal i <filename> this thing grinds my computer to a halt i barely Ctrl-c'd at 1507 out of 10000 iterations. crystal r <filename> completes smoothly in a blink of an eye. Linux x86-64

# START:p1
chan = Channel(String).new
i = 0
num = 10000
num.times do
  spawn do
    chan.send "fiber #{i}: I like crystals!"
  end
  i += 1
  puts chan.receive
end
# =>
# fiber 1: I like crystals!
# fiber 2: I like crystals!
# fiber 3: I like crystals!
# fiber 4: I like crystals!
# ...
# fiber 10000: I like crystals!
# END:p1

[mdwagner]

Can confirm similar results on MacOS (Intel) with Crystal 1.5.0

[asterite]

Yes, the interpreter is slower than compiled mode. And I have no immediate plans to improve its speed.