Compiles with no errors now. Thanks.
Thank you very much! This works well!
Use `tools\start.bat`? It contains
`chcp 65001`
And afterwards the console understands UTF-8.
yes, they're usually very careful with backwards compatibility (definitely pros
and cons about that though, on the cons side, certain flaws (eg auto-decoding
strings) might never be fixed)
hence the caveat: "can be previewed under the experimental -dip1008 flag"
Nevermind my question, because:
let enc2 = encodings.open("850", "UTF-8")
echo enc2.convert(message)
Run
as found in my own old thread (oh my god i need sleep) works for now:
[https://forum.nim-lang.org/t/2250#13725](https://forum.nim-lang.org/t/2250#13725)
So,
Thanks. I reinstalled the development version of the compiler (removed previous
~/.nimble dir and started new, verified the paths for conflicts). This is the
error from running "nimble build" :
... /home/gt/.nimble/pkgs/jester-#64295c8/jester.nim(551)
ctParsePattern
Hi!
I'd like to reevaluate nim for very small tasks. I have here a Windows 10 with
these compilers:
gcc --version
gcc.exe (x86_64-win32-seh-rev1, Built by MinGW-W64 project) 6.3.0
...
nim --version
Nim Compiler Version 0.18.0 [Windows: amd64]
...
I try to
since there's ongoing discussions about exceptions, just wanted to mention D's
recent-ish addition which was integrated in
[https://dlang.org/changelog/2.079.0.html#dip1008](https://dlang.org/changelog/2.079.0.html#dip1008)
void main() @nogc
{
throw new Exception("I'm
Wow, this is pretty scary:
[https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md#breaking-changes](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md#breaking-changes)
Does D not offer any backwards compatibility guarantees?
Thnx will try it out
Trying to get rid of GC and now exceptions... I'm afraid that Nim will become a
Rust dialect eventually.
I am running 8 websites in production environments and all with Nim as the
backend.
I have 3 different setups for maintaining and updating the websites:
1. Some of websites have base on GIT repositories and I have a small update
file, which preserves special configs such as API keys and IP's
I'm trying to compile my nim-libnx project for Windows, and it always seems to
hang on the last object compilation. If I execute the command on it's own in
the command line, it works fine, although it spits out a bunch of warnings (but
that should be irrelevant).
The command in question is:
Compile with `--cpu:i386 --passC:-m32 --passL:-m32`
How can I compile for windows x86 bit machine on windows x64 bit machine?
Ok, you're willing to pay the "penalty". I am not.
> Fully sliceable strings and arrays are always better.
The terminating zero doesn't preclude slicing (you can have a flag that
indicates whether the terminator exists) but slicing has inherent ownership
problems that the more convoluted
Doesn't Nim do the same mistake as C++ by adding the zero termination in the
string implementation?
The best solution in my opinion is to have an external "CString"
implementation. That will be a penalty for libraries that use zero terminated
strings. I'm willing to take that penalty for
1. In Nim string literals do not allocate either, but assignments copy.
2. They have a terminating zero for C interop.
3. The new string/seq implementation will eliminate more copies.
so the main reason is to avoid mangled names when exposing Nim functions (eg
via shared library or static link library) to a C (or C-like) program that
would call Nim code via extern "C"?
eg:
os/mylib.nim:
proc foo1()=discard
proc foo2() {. extern: "nos$1" .} =discard
in D, string literals don't allocate. (in C as well but they decay to pointers
so let's leave these aside from this discussion)
D:
// D20180718T163602
import std.stdio;
extern(C) void fun(const(char)* str){
printf("std:{%s}\n", str);
}
void main(){
This RFC captures my thoughts:
[https://github.com/nim-lang/Nim/issues/8363](https://github.com/nim-lang/Nim/issues/8363)
21 matches
Mail list logo
