**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
Now I'm at a bottleneck.. Inside one of my dynamically-created procedures, I
need to access a sequence of tuples, dynamically created earlier in the AST
tree.
Is this horrible to do? Nim is giving me a warning about being non-GC-safe, but
all I'm doing is using the sequence to know which procs
Here a little trick to get GitHub style" Markdown as preview inside VSCode:
[GitHub Style formatted markdown in
VSCode](https://gist.github.com/oderwat/42e5fef8bba8a81db656937f25c5ce3a)
Code Blocks are not working yet (sadly)
I compile / run from withing VSCode using the mentioned "runner" Extension
together with some "magical" bash-script. The script is rough but supports
something similar to a "shebang" which I frequently use in my modules.
Generally it allows to "Hotkey" (F4 for me) the current active file in the
Well.. It is now listet. That page is a Wiki after all...
I think you can't simply cast the slice.data to a cstring. It has to be
delimited by a "0" which may "happen" for accident in your code. But it would
be really to have behind slice.size bytes in memory.
Looking into the memfiles module you can see how it is done to return lines as
strings
[her
**cblake**,thanks
I was just trying to work with memSlices, but I got strange results. I'm at a
loss. How to properly write? This test code:
import memfiles
import strutils
import nre
var count = 0
var line:string
var fMem = memfiles.open("1.txt", fmR
1. Strings are indexed by char, at least if you use `[]` or `items()` on
them. Nim has a "byte" type but it is not used frequently and just an alias for
"uint8". It also has int8, uint8 and char which are all "a byte".
2. `items()` is not a function so you can't call it like one. It is an
it
If you use memfiles then you can just map the whole file and let the OS page
things in from disk on demand as necessary. This gives you a "whole file buffer
for almost free" kind of user interface. After the first run or file
creation/etc. there may be zero/little IO and also very little copying
It is possible for this code to somehow use the blocks to read? Something like
**fIn.readBuffer(addr buf [0], 4096)**. I tried, but did not understand how to
do it correctly.
You're welcome, Garry.
Stefan - a simple check for whether pattern has any regex metacharacters (e.g.
'.', '*', etc.) can decide if a pattern is definitely not a regular expression.
If there are any metacharacters in pattern, well only the user can know and
there would have to be a command-line
My assumption was that "pattern.re" in the loop may create a new regex from the
string in each iteration. But maybe the compiler is indeed smart enough to
avoid that. Generally we may investigate the search pattern in advance and fall
back to plain string search when it is not a pattern. But I h
**Stefan_Salewski,cblake** Thank you so much! A simple thing - but tangible
results. On my machine, the code worked 6 seconds at normal reading file and 4
seconds using memfiles.
What Stefan means is doing something like this:
pattern = ARGS[1]
let rex = pattern.re
and then using `rex` instead of `pattern.re` in the two spots inside the
`while(fIn.readline(line))` loop.
That one change made this run about 4X faster on my machine. [ With memfiles
if line.match(pattern.re).isSome:
looks not really smart for me. You may create a new regex for each loop
iteration.
Sorry, but I do not quite understand your point. (Example, if you please).
Preliminary check **line.match(pattern.re).isSome** gives speed increase by
50-100 percent, in contrast to the embodiment, where it did not exist.
There are really some unnecessary allocations in the strutils module. E.g.
replace, which returns a substring. Please, contribute an in-place replace
version to stdlib to make your code faster ;)
Strings are searched for as regular expressions - checking in text editors is
also done using regular expressions.
Do you want to search for regular expressions or for plain strings?
Plain strings should be faster of course.
My next experiment is to use tables with procs, which gives useful compiler
warnings when our procs are not GC-safe.
import tables
# These three lines give GC-safe warnings when "gprocs[1] = ptest" runs.
# var gprocs*: Table[int, proc (test: Test): bool]
# gprocs = i
To summarise, given that _indexing_ of strings is for the bytes, it could be
easier to treat strings as a sequence of bytes.
`toSeq(foo.items)` did the trick. However, `foo.items.toSeq` did _not_ work. I
think that's odd. But all I really need are examples.
I definitely appreciate that Nim hand
Ok, when memory consuption is the problem and should be minimized, then there
are also better alternatives to ASCII. But that again is also a different
question.
@Krux02 : I was also put on the wrong leg by the original question.
But, looking more closely to the content of the program, it looks like
_cdunn2001_ is dealing with DNA sequencing data. That is one of those
exceptions. The alfabet used in such encodings is very limited (well within the
ASCII
I can only second what jibal said. Your question was wrong, you should have
asked for ASCII not UTF8. But I highly discourage you to do so, unless you are
writing a toy ascii art editor, where vertical alignment is important, and you
don't want to deal with varaying lengths in utf8. But even the
Can I do this code faster? On my computer for the file in the 3 million lines
it runs 14 seconds. When using memfiles - one second faster. While text editors
produce the same operation is much faster: AkelPad - 7 seconds, Notepad ++ -
2-3 seconds.
PS: Attempts to be played with a size of the bu
> Compile, Build and Run from within the editor
I solve that by using the integrated terminal in VSCode. And simply do the
standard: nim c xxx.nim
Or you can use the setting from the nim plugin:
"nim.buildOnSave": true,
"nim.buildCommand": "c",
"nim.lintOnSave": tru
Yea, its nice. Needs some more features like proper ftp/sftp management but its
already very productive. The first editor ( that is not on the nim suggest
list:
[https://github.com/nim-lang/Nim/wiki/editor-support](https://github.com/nim-lang/Nim/wiki/editor-support)
), that made me feel more a
hi,
I've been playing with Nim a bit to see if it's feasible to use it in my
company, I’ve tested it with a few editors and currently I’m using vscode.
I think that the language is just great, it’s so much fun to program with
it,just love it!! … but, there are a few things that must be addresse
@OderWat Is Atom slower? Possibly. If I install enough plugin on Atom to make
it seem like an IDE and open a project with it it can eat up to 4 GB of RAM
which is unacceptable. Is Atom ameturish? [vscode just introduced tabs and
find-replace](https://encrypted.google.com/url?sa=t&rct=j&q=&esrc=s
@idobai From my experience Atom is much slower than VSCode. They are completely
different developments.. Alone that I could open some bigger files in VSCode
where Atom gave an error was enough for me to try VSCode before it had all the
features it has now. Atom feels to me like the "amateurish"
I don't know if such constant is already defined (seems not), but you could use
something like this:
type Backend {.pure.} = enum
C, CPP, OBJC, JS, PHP
const backend = when defined(cpp): Backend.CPP
elif defined(objc): Backend.OBJC
VSCode is almost the same as Atom - just like their Nim plugins - except the UI
differs a little bit(VSCode is more like a Qt creator/brackets copy) and it has
less plugins. It's built on electron too so prepare for the leaks and
glitches(the app stuck on the screen for me after minimizing it)!
> In my case, all the values are ASCII
People don't have ESP. You should have stated this up front.
> so UTF8 is precisely the 8-bit character.
This has nothing to do with UTF8.
Nim is great on Atom. Haven't tried anything else lately. Are there any
specific benefits to VSCode over Atom?
34 matches
Mail list logo
