The Swift people learned from their experience with libclang.
There is now for code completion a source kit daemon, i.e. out-of-process.
@tschuett, thanks for the comment. I think I understand what you mean but could you probably elaborate for the students that will be skimming through this thread trying to make sense of it?
Sorry for being terse. I wanted to hint at that there is prior art in moving Clang/Swift execution into a separate process. People wait for Clang/Swift to crash.
The hard question is the zero-cost restoring of the state. For example, if we use some checkpointing approach we could relatively reliably restore the state of the session before crashing, however, we would penalize the people who write correct code. There have been some outside-of-the-kernel approaches to restore the session in cheaper ways but that’s pretty much a research goal for this project. That is, figure out what’s out there and if/how we could use it and at what cost in terms of performance but also maintenance, etc…
In an ideal world, could we somehow have a scratch area and a stable area where we run the new portion of the code in the scratch area and move it into the stable area after it was run (possibly fixing instruction PLT, GOT and what not again). This way we could restore cheaply by throwing away the scratch area and start over…
This project feels in some ways like it was made for me. A couple years ago when covid broke out I decided to read SICP, which lead me down the rabbit hole of interpreters, and more recently (only after accepting that I’m an addict), into the world of compilers with the Chez Scheme Nanopass framework. At that time, I was writing a philosophy dissertation on the internal languages of topoi in Badiou’s Logics of Worlds, which was gradually being pushed into a direction far flung from my genuine interests by my supervisor, causing me to recently decide to return to working in software as my interest in interpreters & compilers started to outweigh my interests in the ontology of mathematics.
During this time, I’ve become particularly interested in the use of continuations and CPS to build big-step interpreter based REPLs that allow for stepping through code execution and editing the substitutions of various parts of the code on the fly using partial evaluation, following the works of Kenichi Asai, Kent Dybvig, and Nada Amin on this subject, and experimenting with various techniques that they demonstrate in various papers.
Before returning to academia, I worked as an interactive VFX designer for stage & events using C++ openFrameworks, something that I’ve continued for particularly big comissions throughout this time (most recently for a public art commission in downtown Singapore last summer). At the same time, I have no experience in C++ outside of openFrameworks & openGL, and I have no experience with LLVM, but I feel confident in my ability to immerse myself in it from now until the summer, and be able to offer solid contributions. I’m also trying to make a transition of career into open source tools of some sort, and have never worked “in the industry”; I’ve only ever worked as a private contractor, primarily as a one-man show. I contribute to GNU Guix and Guile Scheme, but never in any kind of professional capacity.
I believe I meet the intern requirements of GSoC, and I feel confident in my ability to add valuable contributions to this effort, and hopefully breach the stretch goal. I believe the direct relation of this project to my current interests will motivate some great work if you’re still accepting interns for this project.
here is a talk from past students of Vassil Vassilev concerning their work on Clang-REPL if anyone is interested:
Hi @cybersyn, thanks for reaching out and your interest!
That project might indeed help broaden your expertise with C++, compilers and low-level infrastructure. I’d propose to build clang-repl and start playing with it to get a feeling of what the work would be like. Perhaps firing a debugger and going deeper into the JIT can be helpful.
After these steps if you are still interested you could send me (in private) your CV. Then one needs to write a proposal gathering proactively feedback from the mentors. It needs to include major work items, deliverables and a timeline. We generally recommend having a patch or two in llvm fixing some “good first issue” from the llvm bug tracker. That usually increases the chances for successful application.
Hello @vvassilev, I have a experience with C++ and am also interested in this project idea but am less experience with compilers. Are there any good resources that will get me up to speed on the knowledge necessary? And around when do you recommend submitting first proposal draft?
I would recommend starting from the LLVM documentation and the Kaleidoscope tutorials. You can find other resources on these topics over the years in the presentations from past LLVM Dev meetings (videos should be available on youtube).
It is good to start drafting a proposal early. We recommend to build the project and start playing with it. That would give you a hint about the type of the work is in front of you. If you like it, then the proposal should be ready by the deadlines announced by GSoC. However, you should probably ask the mentors for feedback couple of weeks before the deadline.
@cybersyn and @Daniel-Yang if you are still interested in pursing these project I’d like to let you know that you should start working on your proposals and get some feedback by the mentors to increase your chances.
Ok will do! I’ve been busy preparing for final exams but I’ll send over my proposal draft to you as soon as I am done.
Hi all, sorry for having missed to reply in this thread so far. It would be great to review your proposals. Please PM me if you want to share yours!
A few notes from my side: This project does involve some serious C++, if you have no experience with it then it will be hard. If doesn’t necessarily require prior experience in working on compilers. It’s more about extending the RPC capabilities in LLVM ORC and wiring it up in JITed code for value printing. You will have to debug through (at least some) assembly code.
Last but not least: This is not about running the compiler in a separate process as SourceKit appears to do, but rather the JITed code itself.
Hi all, so far we have not seen any proposal draft. If you are still interested in working on this project we have couple of days left to write a strong proposal.