"Vala" \- I think that tells us next to nothing. Simple reason: unlike Nim Vala
was linked to Gnome, i.e. a major (well, kind of) and well known name. When
Mozilla (Rust) burps the planet trembles, when Gnome (Vala) burps, the world
notices it ... and when Nim burps (or sings a nice song for
Dafny is a quite nice and actually useable tool but unfortunately .Net only.
You are all welcome
@cantanima
I disagree. Reasons, mainly:
a) Ada is intrinsically harder to work with. Likely reasons are its age
(decades older than Nim) and some almost anal typeing problems, probably also
due to its age; in a way J. Ichbiah had to try to emulate SA in the language
NaN is floating point. So something = if (condition): foo else: bar can't work
if 'foo' is of different type than the type of 'bar'.
You can use if (condition): Cell(x:j+1, y:i) else: Cell(-1, -1) or another
"special Cell" to indicate what you wanted to indicate using NaN.
Great, thanks so much Araq and Nim team!
I particularly love the SA/H3 and the .localPassC pragmas.
Quick question related to that: Assume that I have a Nim file which needs a C
file compiled but with different C compiler parameters than the Nim file. Is
there a way to tell which compiler
I'm strongly opposed to that plan! While I fully agree that Nim (currently)
does a lot of uncool stuff (e.g. static typing) I do not consider Python and C
good choices. Instead of Python we should be bold and directly walk into where
the future is: AI based image interpretation instead of
Just a sidenote: NO! The true news is that GCC finally gets at least some very
limited static analysis capabilities. Clang/llvm is light years ahead. Please
note that my statement is only addressing static analysis and not GCC in
general!
YAY! That's extremely good news. Thanks a lot!
I particularly love to see _full_ H3 - incl. 'invariant'. Are there also plans
to provide quantors ('forall', 'exists' (plus negation))? Even hotter: Are
there plans to provide a _compile time_ interface to Z3? I'm asking because
that would be the
The echo statement might trigger a call to getFrameWidth().
Try to do an "old style" echo like 'echo "Width: " & $width' directly after a
getFrameWidth() call and assigning its result ("let width =
getFrameWidth(...)".
Yes, that's the list I meant. Thanks.
Note however that that list is extremely "generous" and most entries are just
more or less reasonable _linters_ rather than static analyzers/verifiers.
I'll provide more info once I'm finished doing some verification of Nim C
output.
"constant time stuff" \- no, I don't know such a tool. Static verifiers are
only looking for code correctness, e.g. proper mem. boundaries, reachability,
loop invariants, etc. If you want to verify things like
**NO! NOT less secure than C** \- but less secure than _formally verified_ C.
That is a _very significant_ difference.
"Normal" C code, i.e. C code that has not been formally designed and verified
is considerably less secure than normal Nim code.
The point is that for C - unlike for most
I'm working in the field and Nim is my "everyday job language". Translation:
Nim is _considerably less qualified_ than Ada (much harder to master), Eiffel
(unattractive for some other reasons), and even Ocaml (less attractive for
multiple reasons), let alone F star (which however is
Thanks but I don't assume it's a Nim Bug. It rather looks like a mistake I made.
Thanks. In fact I doubt the proposition that warnings are only for humans. For
example stating "noreturn" but actually returning _should_ be considered as at
least questionable. Sure, one can do a lot of trickery but I have learned (the
hard way) that good code is clean code and I would never
Sorry, I meant the prng itself. Also while I understand that one might read it
as an optimization it actually was a question where I made an error that led to
"anti-optimization".
Well, whatever, I went the cumbersome path and found my suspicion confirmed.
`cast[PResult](s.x)` had Nim _copy_
Hmm, frankly, I'm not satisfied by the "it's just warnings" answer as we are
not talking about "variable declared but unused" bla bla. But I'll leave it at
that because my point isn't about creating a fuzz. I _know_ for a fact that
some warnings should be taken seriously and that it's no matter
Hello
I noticed that compiling fails (Nim 1.06) with `{.passC: "-Werror -pedantic".}`
i.e. when I follow my C habit to be stringent with code and ask gcc to treat
warnings as errors also in the Nim generated code. It seems the culprit is
stdlib_system.nim.c.
Error 1 `error: ISO C forbids
I disagree, at least regarding the question in the title.
A ref is always preferable unless one _needs_ a pointer. And the heap vs. stack
is not Nim specific.
Solved ... kind off
The line `c = bufx[k]´´ above was followed by ``key[j] = c`
(which already was a split for debugging and was originally `` key[j] =
bufx[start + j]``) and `key` was a `newStringOfCap(64)` var.
@Araq whom I want to thank and laud for his friendly help in our chat for
I have a strange problem with Nim (both 19.2 release and 19.9[most current]
nightly.
const MEG64 = 1024 * 1024 * 64
var somebuf: array[MEG64, char] # some large buffer
# ...
proc char_arr_stuff(bufx: openArray[char], start: int) =
var
j = 0
Update: The results I talked about yesterday were obtained with Nim simply
-d:release compiling but with quite some optimization for the C reference code.
Today I cleaned up some minor lose ends and did some polishing (for both, C and
Nim) and set Nim to compile with --opt:speed plus some
I don't know about graphics stuff, but
1. I found c2nim very helpful. Preprocessing C source beforehand is a very
small price to pay.
2. (and not directly related) **CONGRATS** to the Nim developers! I just
finished porting a (very time sensitive) modern fast hashing algorithm to Nim
and
The problem is that there seems to be no check for EOF.
This here works:
import asyncdispatch, asyncfile, os
proc main() {.async.} =
var filename = "test.txt"
var file = openAsync(filename, fmRead)
let fileSize = file.getFileSize()
while
cblake, tim_st et al
Yes. I never liked Nims easy going in some points like the one that shows its
ugly head here. Simple reason: ambiguity - as in "not _evidently and
strikingly_ clear" \- is known to be one of the major infectors in software,
comparable to rats in a city.
My personal rule,
I'm a bit careful and general in my reply because I don't know the library you
use. First, in Nim an array has a known and fixed size. If you need a dynamic
array have a lot of seq.
Basically you should differentiate between two cases:
* 1) The C func has a size parameter directly following
> Geany is a (more or less dead) zombie, PRs are not getting merged.
Ts, their last release was in january. It seems though that the Nim support
project did indeed end up somewhere between the taiga and a black hole.
For your other point: OK, OK, I see it and you are right. When I said "all" I
I know vim - and I also know that many strongly dislike it (and others like
it). For the kind of basic tool set for _everybody_ that I have in mind any
editor with a "religious" follower or a "religious" hater group seems to be a
bad choice.
That also means that it's not about "the best
1) Thanks for the hint! Now with the "trick" setting a breakpoint at a
proc does work. Great. Unfortunately though, the gdb problem is still there.
Maybe it's a version thing; I'll try a more current Gcc/Gdb later and will let
you know in case that works. Btw. the Nim version on FreeBSD is
First, thanks for your constructive and friendly reaction.
I have a module, let's call it F.nim with, say, proc "fsysctl" that calls into
FreeBSDs sysctl. Module F is imported into and called by, let's call it
prog.nim. Within prog.nim I have a "tmain" proc that sets up some variables and
then
I have wasted 2 days now hunting down a problem on FreeBSD and in particular to
get some acceptable way to debug my Nim code in the first place.
Result so far: about the only way to debug Nim code known to me is the bloated
perverse Visual Studio Code monstrosity - which isn't available on
Re question 1: Where does that `void Fl_Widget_TrackerDelete(Fl_Widget_Tracker*
& wt);` declaration come from? I doubt that it's coming from FLTK and I'm not
surprised that c2nim doesn't digest it. Are you sure that the `&` is really
there before `wt`?
We are not in your head nor do we have the C (or Basic?) source code in front
of us. So if you throw some code line at us without any context it'll be hard
for us to help you. Also note that the intersection of Nim and Basic developers
is probably very small (as opposed to Nim and C) so asking
The following _does_ work:
// file ccall.c
int some_weirdly_named_func(int p)
{
return(p += 10);
}
Run
# file ccaller.nim
{.compile:"ccall.c".}
proc weirdCcall(p: cint) : cint
{.importc:"some_weirdly_named_func".}
Although this thread is rather old I'll answer anyway because certain attitudes
and questions come up again and again. It might be useful to have something to
link to instead of saying it again and again.
Front-up: My first gut reaction to the OP was "Oh well, if he likes C# so much,
why
I'm somewhat torn between the two camps. My compromise: the Nim way for _short_
proc docu (1 - 2 liners) plus, if more than a couple of lines are needed I add
something like `More Info: `Details `_`.
This allows me to stay Nim style and still have a clear link to more elaborate
proc docu.
I don't think that's largely a question of what's your need and goal. If you
want programming as a hobby Python might a be better choice. If on the other
hand you plan to do programming more seriously learning Nim is probably a
better investment.
Reason for my opinion: Nim is a quite easy to
I'll add something to juancarlospaco's helpful explanation:
var
k: array[10, int]
for i in k.low .. k.high:
k[i] = (i + 1) * 10
if k[i] mod 2 == 0:
echo k[i]
Run
Note the `.low` and `.high` in the loop. That's a good way to avoid index
I agree with some points but that
> The NIM project founder is sort of a one person show in development and
> promotion.
is plain wrong.
Not having a large organization like Mozilla behind it Nim can obviously not
compete with some "competitors" in terms of how many full time developers it
Nice! Thanks, Nim team!
I agree with Araq's statement and in some cases talking bad about language XYZ
indeed is trying to lift up ones own or preferred language (or at least
strongly looks like it). But there's a big fat "but": Better languages, at
least to some significant degree, are often created _because_ of bad
use their favourite editor.
But I also know that the "is there an IDE for it?" question is one very many do
ask. Go, Zig, ... you name it, just look at stackoverflow, HN, quora, etc ...
that question is very prominent.(And again: I personally don't care that much
for an IDE. But the disc
Besides the fact that almost always the large IDEs also join in once a language
already has a solid base and uptake I fully agree with you. Again: My point was
_not_ that the Nim team should create our _own_ IDE. It just so happened to be
the case that two IDEs were made (and went quite far) by
> There is not much professional behaviour in your posts here, some would call
> you a troll, consider this to be my first and only warning.
My engagement is honest and my motivation is constructive. That's why I also
tried to help with concrete problems of users (like just today in the dll
My point wasn't that Nim must have its _own_ IDE. My point was that having an
IDE is a major point wrt uptake and that Nim just happened to have some
considerable effort going into 2 IDEs but left them unfinished.
Well noted, my line isn't what _I_ personally like or want but what is
generally
Here is your problem:
Fl_Callback* = proc(widget: ptr Fl_Widget, pData: ptr any)
# ...
proc ButtonClick (button: ptr FL_WIDGET, arg: ptr any):**cint {.cdecl.}** =
Run
In other words, `Fl_Callback` is not cdecl and its return type is void while
`ButtonClick`
So? We do not at all disagree on that. You basically just worded differently
what I meant (modulo some minor points like "imperative" vs. "imperative with
some functional").
I'm _not_ for relaxing those points. Quite the contrary. I was addressing
another question, namely whether fully
Can be a problem though because in today's "language rich" environment with
hundreds of languages catering to the needs of 10 niche groups not only highly
likes to fail gaining significant traction but also risks to lose its main
target group.
Re js: That's something I don't see as a problem
I'm a lousy marketing or sales guy but one thing even I understood and keep in
mind is this: the result of communication is _not_ what has been said but what
has been heard. As promoting a language (and arguably even building one meant
not only for oneself) is a "use case" of communication it
Thanks.
Great (although I personally prefer halfway stable releases) Thank you.
Out of curiosity: how come the jump from 19.2 -> 19.9?.
Front-up disclaimer: I went into the being exited trap due to what Nim has to
offer, too.
Re the OP issue: To promote a language one should first know what it actually
is one wishes to promote. So: what is Nim at its core? What is _the_
definition/goal of Nim?
Is it a system language or is it
Thanks for that clear statement. I'm learning and drawing my conclusions.
I see 2 major factors and the only reason I'm mentioning them is my optimistic
hope that someone concerned will read and think about it:
* Nim's docu is poor in many places, let's be honest.
* people should understand that there is a strong relation between the
quality of a question and the
As a somewhat rude demonstration: From the help for module system
proc GC_ref[T](x: ref T) {...} # empty
proc GC_ref[T](x: seq[T]) {...} # empty
proc GC_ref(x: string) {...}
marks the object x as referenced, so that it will not be freed until it is
unmarked via
* real documentation - as opposed to just proc comments
* Examples, examples, examples
* Explanations for more difficult matters like async, threading, etc.
Something like page or two only "generally" explaining how those work in Nim
(from there the user can go to the modules normal docu
We are in agreement if I understand you correctly.
I don't care whether Nim code runs 0.5% or 3% slower than C code. In fact, I
think that whole benchmarking is irrelevant except for a rough overview ("Nim
is within x% of C's speed").
Reason (and C/C++/D developers might want to read this
Yes and no. Yes, you are right, I had a wrong (and since then corrected)
statement in my post. And yes it does work but it's almost certainly not what
he wanted anyway (and a weird way). But yes, I got confused myself.
Yes and no.
Yes insofar as you can of course allocate whatever you please and pass those
pointers around and/or use them. No insofar as you must be careful to not
wildly mix up Nim-allocated objects and pointers. In your example
proc newMyObj(): MyObj =
result = MyObj(x:
The way you asked your question (hint: vague, general, not clear what you
really want) Araq responded perfectly correctly.
Now you ask us to read a 150 lines file and we are supposed to find out what
you want and what your problem is by reading through and make sense of your
code.. Chances for
I fully agree on Nim indeed _being_ a good language. My point though wasn't "I
can do faster code than ...".
My point was that one should a) _think_ about optimization starting from
"what's actually the point and what's the bottleneck or the most promising
approach?" (in this case it was "use
For what it's worth: I c2nim'd the simple.cpp and slightly adapted it to have a
`limit` parameter to (using `i`) limit the number of computed triples. Compile
time on my Ryzen box and using gcc as the backend was around 1.6s the first
time and about 0.25 s for following runs (said Nim).
Pardon me but it seems that you should change friends rather than language.
What your friend said about Nim being incomprehensible for people who don't
know Nim is simply ridiculous BS.
If I were in your place -[and](https://forum.nim-lang.org/postActivity.xml#and)
\- for whatever weird reason
> First of all, he states that not having such an indentation-based syntax
> allows for more freedom ...
He is right in that but only in one regard: Having explicit block markers (like
{ and } or `begin` and `end`) allows for (visually largely unstructured)
"streams" of code. If that were
Well, "the above code" from alehander42 is Nim's usual way to go about object
variants and the code you don't like is the usual way to go about "methods" of
object variants. You might want to write `result = ...` instead of `return ...`.
proc addTwo(self: C): int =
case
Sorry but "the above code" can be a lot of things and we are not in your head
and can't clearly know what you want. Please do not mistake this as rudeness
but I've found again and again that there is a relation between the quality of
a problem description and the quality of the responses. I'd
You are welcome.
Plus another side note: Nim templates _are_ (what C calls) macros albeit pimped
up and cleaner. One important point to remember is that templates (unlike Nim
macros) are basically but smart text substitution. This also means that any
variables one refers to must either be
This should do what you want:
template push(val: int) =
stack[p] = val
p.inc()
template pop(): int =
p.dec()
stack[p]
Run
The relevant point isn't the stack logic (p++ vs p--) but that a template that
is supposed to "return" something
type
CsTuple = tuple[first: cstring, second: cstring] CstSeq = seq[CsTuple]
proc test(p: openarray[CsTuple]) =
for t in p:
echo "first: " & $t[0] & ", second: " & $t[1]
let ts =
@[("a0".cstring,"a1".cstring),("b0".cstring,"b1".cstring),("c0".cstring,"c1".cstring)]
test(ts)
> Latest Nim is not that dumb for literals: _(example)_ Works fine, even the x
> / 2!
Excellent news, thank you.
> The fact that Nim does not do that many automatic type conversions is good
> for safety and performance ... And as Dom said, lenientOps exists now, but I
> think I will generally
@mrsekut
First, your code has a problem by passing a small 'a' but `parseStatement`
expects a capital 'A' or 'B'.
I'm a bit confused by your approach but I'll try to help anyway.
type
A = ref object of RootObj
name: string
value: string
> 1) When you work on very platform dependent code, you have to manually add a
> bunch of constants and so on.
My current solution: a single -d:[platform] switch and an include file with
some `when` logic. Probably by far not the smartest way but simple and working
2) Too picky with variables
Maybe I was just insanely lucky or maybe in your field there are particularly
dangerous spots - but I can't confirm your impression. My experience with Nim
is that it's surprisingly well working.
The probably biggest problem I see is **documentation**. It _seems_ to cover
most areas but it
Well noted, I'm not at all opposed to what you wish. It's just that I don't
agree with it being the big turbo for Nims uptake.
For a start, very many if not most professionals have little choice anyway;
projects are done in whatever language management decides. The next major user
group are
P.S. @Araq and team
If it's not too much trouble it might be a good thing to differentiate between
illegal memory access and _calling_ a nil proc. Would probably be helpful and
errors like the above would be easier to see/understand for new Nim users.
> I hope you scored all the brownie points with Araq
My respect for Araq is well earned and deserved. Thinking that it's about
brownie points tells more about you than about me.
As for the matter:
You were (and are) free to clearly show how Zig's importing C stuff is not
insignificantly
a) I don't see the big difference or how using C stuff in Nim is more labour or
more complicated than in Zig.
b) Again: Even _if_ you were right I wouldn't care because that would be a
discussion about a Ferrari being oh so much slower than a Lamborghini; looking
from the perspective of a
No, it doesn't. It just seems it does but as soon as a call like
`s.events.onload("some event"` is made it segfaults with `Illegal storage
access. (Attempt to read from nil?)`
Please note that the approach of @Araq also fails because in the OP
`wrapper.onload` was left nil which leads to the
> Zig and Kit have arguably better interop capabilities with C than Nim does atm
One might see it like that - I, however, do not. One reason is c2nim and the
other reason is that I'm interested in an easy comfortable way. In a way we
talk about different things; I talk about that it's easy
I'll stay away from game related stuff as I know next to nothing about game
development. One thing, however, I can say (certainly not adding to my being
liked around here): I personally and subjectively consider Nim's success in
some game development to be a warning and a grave danger.
> I do
> Nim needs a "killer app". This doesn't necessarily mean a specific app, like
> Rails was for Ruby - it can be a general pattern, some clear specific thing
> that Nim does better than its competitors.
I'm afraid neither will do. I'm afraid that "being the most libertarian
programming
Let me help you out. I'll emphasize the relevant word to make it easier for you.
> I can let other opinions stand and have no need to "facepalm" or similar to
> otherwise belittle or attack **anyone** here
Maybe, just maybe one might take my opinion re. D as "attack" or belittling IFF
I had it
So? You have your opinion and I have mine - and as you saw (with my no further
discussing with someone else) I _can_ let other opinions stand and have no need
to "facepalm" or similar to otherwise belittle or attack anyone here. In fact I
assume the differences in our views largely stem from
Thanks. I'll wait (and of course just like you have an interim work around).
Nice work btw. (NimCrypto).
I don't think the problem is with Nim. It's highly likely with floating point.
Unless you want to play with arbitrary precision FP you'll have to live with
the fact that while FP can represent mildly large integers it doesn't offer
precision with fractions.
Btw, that you use only up to 2
Thanks. I mentioned it (uint.high) mostly for general interest anyway because I
almost always use specific intXX and uintXX types.
What I said does hold true, however, also for and specifically for `uint64`.
`echo "max uint32: " & uint32.high` (and smaller sizes) does compile/work
but
`echo
`let h = high(int)` works
but
`let h = high(uint)` does not work
Suggestions?
Hmm, I see. A classical political correctness and Über-Ich argument ...
Well, no. I clearly said "personal summary" and I have no obligation to meet
any arbitrary conditions like e.g. "examples!" Well noted, I _could_ provide
more detail (and I did for Nim which is _worth it_ ) but I don't for
FWIW I had a look at D multiple times and learned to fervently dislike it. My
personal summary is that D is but yet another better C/C++ attempt with funny
gadgets added and an utter lack of consistence in concept and design.
To even put Nim and D next to each other is ridiculous.
Yes and no. Yes if the libraries are written in Nim but no, when they are not.
But: If they are written in Nim they can be both, snake_case or camelCase
_because_ Nim makes no difference.
Also note that than Nim can import C libraries and use any identifier style you
prefer anyway.
The trade
Why should they? Nim _has_ a good - and minimally restricting - rule. Types
start with a capital letter, vars and procs don't. There's nothing in your way
to, e.g. have all types start with 'T' (like Tperson or TPerson)
No, style insensitivity does _not_ allow your to do what you want. The reason
being that the language behind the scenes changes identifiers. The correct and
honest way to say it is that Nim gives you less freedom (in that regard).
Look: e.g. in C (and many other languages) you can have two
I'm one of those. I still sometimes find myself starting types with 'T'. But I
don't feel that to be a problem. And anyway, a rule that says that types must
start with a capital letter makes sense and is easily within what a language
can reasonably demand.
Style insensitivity, however, always
The getAddrInfo call doesn't return the full struct (only to 0xfff1). Moreover
the first couple of bytes are _not_ part of the IPv6 address and the first
address byte is the 5th byte after 0x50 (0x20, 0x1, ...).
Frankly, I don't think it worth putting more work into the current solution. If
Also note the conceptual difference:
`for x in someIterable: foo(x)` deals with the _elements_ of someIterable, e.g.
with the letters of a string.
`for i in 0 ..> something.len: foo(i)` is conceptionally quite different albeit
well known from most older languages and deals with the _indices_.
@satoru
Note that `getHostByName` is deprecated at least on linux.
@Libman
Nim (nativesockets) _does_ provide `getAddrInfo` but as you probably saw in
your research it's all but worthless because it's a mess. Which btw. is hardly
Nim's fault but rather a consequence of IPv6 being a makeshift
1. I _did_ describe my solution
2. I don't react as desired to paternalizing and trying to paint me as a bad
guy without a social conscience. Quite the contrary.
3. I try to avoid putting code here because I would always have to look up
the forum syntax how to do that.
Yes that's one way but not what I want. I mean, come on, it's not something
exotic to binary read/write from/to disk.
Anyway, I have found a working solution now after a lot of research. Thank you
all for sharing your thoughts.
I'm a human. _Of course_ I use higher level functionality when available and
adequate. I'm no less lazy than others - g
For configs for example I use high level modules (like json). But for some
things the ugly old way of using low level binary writing is needed.
Btw: I'm less afraid than many
Yes, that's in part what this (and, I assume, the problem) is about. I _did_
study the doc (and the source) carefully.
More docs on Nim "toBinary" and "fromBinary" magic in types, used. eg. in
FileStream read and write would be urgently needed IMHO.
1 - 100 of 136 matches
Mail list logo
