It is not very easy to read for me as a non native speaker unfortunately...
> Before you can successfully wrap the required procedures, you are going to
> have to first define four types.
>
> One of the biggest advantages that a language which can be translated to
> JavaScript but also used
Well syntax check kinda works for me while editing because I have autosave on
:) I guess thats all a matter of settings.
The error/warning highlight does indeed work but it only works after you save
the file! Because its not checking in real time for error/warnings, it can trow
people think it does not work. I also was under the impression it did not work.
By the way: Another nice add-on is:
I'm using nimble to build, this is my vscode launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug",
"type": "gdb",
"request": "launch",
"target": "./bin/testapp",
The VSCode plugin is supposed to do all of this very well. That is if @araq
does not break it the day I promote that editor a lot :) ... Check out the
newest Nim version in devel this may solve your problem. And see here for some
screens of how it works:
[Screen
didlyborn, did you restart VSCode after installing the plugin? The plugin
supports autocompletion, go to definition, error/warning highlight and few
other things. If it doesn't even highlight errors for you, it most likely is
not enabled or cannot find Nim. Error highlight relies on nim check
OderWat, I quite like VS Code in general (the latest version in particular is
really great). However I find that the nim plugin for atom works much better
than the one for VSCode. The nim plugin for Atom uses nimsuggest and does on
the fly syntax checks (marking the lines with syntax errors
Probably because you use the less optimized way of converting the slice with $.
This one does not reallocate the string but creates a new one every time.
**OderWat** Thank you, everything was actually easier than I thought. In
MemFiles have stringify operator **$** for type MemSclise. What is interesting,
with **lines** iterator code works somehow faster than code with iterator
**memSlices**. Why?
Works 4 seconds for a file in rows 3_000_000