Mirror of forum.nim-lang.org

7367 :: Google Summer of Code, Feb 19, 2021

• mratsim (orginal) [2021-01-10T11:01:51+01:00] view original

  Just to mention that GSOC deadline is Feb 19, 2021 if we want to participate.

  https://summerofcode.withgoogle.com/how-it-works/#timeline

---

• bpr (orginal) [2021-01-13T20:53:24+01:00] view original

  Here's a blast from the past.

  What would that page look like for 2021? Very different I think.

---

• Araq (orginal) [2021-01-14T09:43:40+01:00] view original

  Even if we don't get accepted (as usual), it's a good idea to participate in order to write down ideas and goals for Nim in 2021.

---

• adokitkat (orginal) [2021-01-14T10:11:48+01:00] view original

  If you got accepted I would love to try to join as a intern / student :)

---

• bpr (orginal) [2021-01-14T20:01:02+01:00] view original

  So, what would some ideas be? Looking at the old page, current RFCs, and git/forum activity, here are a few unfinished/contentious directions in Nim space that look interesting to me

  Nim Compiler

  • Incremental Compilation (IC)

  • Concepts: (the technology of tomorrow, always has been, always will be) this needs to get

    finished yesterday

  • static[T]: I haven't used Nim in a while, what is the state of static[T] today
  • What to do about method (Is this how we want to do dynamic polymorphism in Nim?)

  • Delimited continuations in Nim: It's like Nim was visited by Oleg Kiselyov. I don't know if this will be

    achieved, but, if done right, will change everything.

  • https://github.com/nim-lang/Nim/pull/11992, same as others on this list: "What to do about closure

    iterators"

  Standard Library

  • Async: Continuations change things, right?

  Tools and Infra:

  • I used Rust for a bit over a year and I have to say, I really like Cargo. The Chapel team is cloning it with their Mason tool. Maybe I need to use Nimble more but I never had the same feeling of ease of use as with Cargo

---

• Stefan_Salewski (orginal) [2021-01-14T22:18:26+01:00] view original

  Incremental Compilation, Concepts, Async: Continuations

  So a student, generally unexperienced in Nim, often without much CS knowledge, shall solve these task on which the brightest Nim devs work since years?

  Some years ago I saw a female student working on improving a Gnome game or converting it to Vala in a GSOC task. I think game was "five in a row" or something. That is more the typical task for GSOC students. Well I have seen really smart students, maybe 10 years ago someone worked on a PCB topological autorouter for the gEDA project, creating some thousand lines of C code which no other one was able to understand, and of course he vanished fast after the GSOC period without really finishing it. So the code was removed from the gEDA projects some years later.

---

• bpr (orginal) [2021-01-15T00:08:28+01:00] view original

  Yup, I call that stuff "academic abandonware". It's certainly common.

  You can take a look at pages like https://summerofcode.withgoogle.com/archive/2020/organizations/4947391960055808/

  to see what people have achieved before. Working on hard advanced, stuff requires a bright student and an active mentor. If you think what I listed is too far out of scope, add more relevant stuff to the list.

---

• kobi (orginal) [2021-01-15T21:23:32+01:00] view original

  I propose finally fixing the GUI story!

  we want a portable and idiomatic gui libs, of the ones i tested, nimx and nigui looked best but had so few controls even for a very simple app.

  i haven't tried gintro or wxnim, they might be complete and portable enough.

---

• jasonfi (orginal) [2021-01-16T17:59:30+01:00] view original

  My proposal is to work on better error messages, especially when using a feature (e.g. tables) that doesn't have the relevant module imported. This could be turning away a lot of newcomers, who may not give this feedback because they don't know what the real issue is.

---

• hugogranstrom (orginal) [2021-01-16T23:40:38+01:00] view original

  I actually see Nim's error messages as really good. I can easily see the codepath which caused my error. The problem with that specific example is that the compiler can't know where for example Table could be defined. It could be from the stdlib tables but nothing is stopping you from defining your own type named Table. So the best thing the compiler can say is that Table is undeclared. And once you understand what that means you should quickly be able to learn that either you misspelled something or that you have forgotten to import a module. Does any other language have these kinds of error messages warning you that you haven't imported specific modules?

---

• doofenstein (orginal) [2021-01-17T00:11:11+01:00] view original

  I think partially what @jasonfi was talking about was about lazily resolved functions like hash and ==. If you're object doesn't define those, only once you use table procs which use those you get an error and also one which seems to come from inside the standard library, instead of your code. Though there's not much which can be done from a tooling standpoint, because the compiler doesn't have the information necessary to decide the case there's a problem with the table from there's a problem with the table type. The solution would be concepts, then the error could be flagged once the table type is instantiated.

---

• hugogranstrom (orginal) [2021-01-17T11:05:07+01:00] view original

  Ah ok that's a fair point :) I have fallen into that pit many times myself. In this case concepts seems to be a great fit. It's not really related to imports in any way though, more about unclearities on which procs must be defined for objects.

---

• mratsim (orginal) [2021-01-17T12:19:11+01:00] view original

  I agree with Stefan, we can't expect the students to be super advanced on concepts or continuations and even if they are they are more likely to work on Haskell or OCaml than Nim. Similarly, problems that involve generics/static including symbol resolution/visibility are likely to complex to tackle in 3 months of a student given the ramp up time to understand the type system in the compiler.

  We would likely have more impact on concrete stuff that don't require millions of tests to get stable enough for use. Things like:

  • debugger integration
  • Sphinx docgen integration
  • Markdown support for docgen
  • Docgen: public procs/types to json file with all documentation and metadata to allow more tooling to be created.
  • missing part of the standard library (I can mentor on bigints for example)

  More advanced things should not be on the critical path of the Nim compiler (no IC, async, continuations), however exploring niche stuff that is relegate to much later is interesting:

  • DrNim / Z3 integration, potentially implementing https://github.com/nim-lang/RFCs/issues/222#issuecomment-626618230, may be able to mentor
  • Better OpenCL, better Nvidia Cuda C++ or better AMD HIP C++ integration mentioned in the GSoC 2015 is interesting as well. (Stage 1 would be just setuping the compilers, and step 2 would be AST to C++ codegen), can mentor on stage 1 and some easy PoC, would need help on the codegen part.
  • Make the Nim DLL and Nim plugin story great again.
  • Concurrent data structures (channels/queues or one concurrent table or a model checker for concurrent data structures), can mentor.

---

• saz (orginal) [2021-01-28T00:33:49+01:00] view original

  Better OpenCL, better Nvidia Cuda C++ or better AMD HIP C++ integration mentioned in the GSoC 2015 is interesting as well. (Stage 1 would be just setuping the compilers, and step 2 would be AST to C++ codegen), can mentor on stage 1 and some easy PoC, would need help on the codegen part.

  Today perhaps Vulkan Compute would be the most general solution that supports the most GPU vendors and platforms.

---