As I said, Nimscript doesn't support `terminal.nim` (on Windows, maybe on Posix
it works).
No, it's just about whether error messages go to `stderr` or `stdout`. Pure
nonsense.
I'm not a git expert, but I'm in great favor of your suggestion. We can make
`devel` an alias for `master` for a transition period afaik.
I don't like `unittest.nim` at all. For all sorts of reasons, historically,
unittest would trigger compiler bugs that the test itself wouldn't.
`unittest`'s implementation is far too messy and tests should be simple. Tests
that are run by Nim's "testament" tool should use `doAssert` instead.
Unittesting is not good enough for Nim, we also have tests that check the
compiler outputs warnings/errors etc. How are you gonna "unittest" that? The
Nim compiler uses integretation tests, not unit tests. Not too mention that the
tester supports testing the different backends, runs tests in
Yes, these two statements will be identical.
The `nil` memory address will mean `""/@[]` but cannot be written as `nil` in
Nim, it's just an implementation detail in order to not allocate these.
Q2: yes.
I have used Nim's macro system to generate Squeak source code but the easiest
route might be to use the compiler as a library and adapt
`compiler/renderer.nim` to produce Pascal code.
0.19 is overdue but there are still hard to fix regressions left. If 0.19
doesn't make it this month, we will backport the most pressing problems to
0.18.2. :-/
Very nice but I think it should adhere to style guide.
Can't think of a solution except patching the compiler.
Doesn't this mean that you have to use multiple connections? Which seems easy
enough to do.
> I guess the lack of reply on the actual RFC means it's not happening, or
> maybe it ran into some kind of roadblock?
Any proposal which cannot deal with macros is hard to accept. There seems to be
an overlap between the people who like cyclic imports and those who use OO
designs with
Use `macros.bindSym` for clean symbol bindings.
Happy New Year!
Interestingly, you cannot do that for now. All you can do is to do something
like
when not defined(cpp):
{.error: "compile via the 'cpp' command".}
`fsmonitor` is still in `lib/packages` so add that to your `--path`, this is
not machine specific (but maybe your config is). fsmonitor is Linux specific
and that's why it shouldn't be in the standard library.
> To me this kind of optional symbol table seems both backward compatible and
> forward looking and strikes a good balance for a stdlib.
I have to admit, this is quite convincing. Especially since it's just an
addition to parseopt, breaking nothing, I hope.
Ok, well, I have never seen that happen/reported before.
Possible. The compiler dislikes enums that try to outsmart/override its chosen
native representation.
My current plans for `method` are:
* Change the semantics slightly: Only the first argument is considered in the
dynamic lookups. Nothing else will change really.
The only problem with that is that then we have 3 ways to do dynamic binding:
1. via closures.
2. via proc type fields with
> _It might be trivial with userland iterators, but they are difficult to
> implement without concepts._
Maybe, I dunno. The real problem seems to be that functional programming simply
doesn't work for performance. You always end up transforming the return type
`T` to a `var T` parameter and
Nimsuggest is documented here:
[https://nim-lang.org/docs/nimsuggest.html](https://nim-lang.org/docs/nimsuggest.html)
Unfortuantely it still lacks examples, PRs are welcome.
> How do I avoid accidentally trashing the refcounts?
protect and dispose only give you a `pointer` that you can cast to `ptr
JsonObj` and so RCs are not affected.
> But as you mentioned before, I can force it with a cast. Is that part of the
> solution you're suggesting?
Well yes. But you
> has the idea of openArray being a concept been considered? It seems to make
> sense - an array has a set of properties that concept describes well:
> indexable, len, etc
Certainly, but I want to keep `openArray` and turn into borrowed array slices.
The borrowing aspect is hard to achieve
> For instance, why introduce {.pure.} with enums to require full
> qualification? If the compiler does not respect the pragma, there are syntax
> errors in the code. Typing and naming should be enough to avoid enums names
> clashes.
Wouldn't work with Nim's disambiguation rules. Think of enum
I'd rather have a new website today than a new website with a nice mascot
tomorrow. So please help dom96 in finishing the website.
It seems to be valid Nim code. It's also a design right from the 90ies, slow,
impossible to parallelize, hard to serialize.
'var' can be faster since the semantics differ: Essentially a return type
promises a "fresh" memory location, 'var' doesn't promise anything and so can
be faster. Btw please join IRC or gitter instead of flooding this forum with
newbie questions, no offense.
Thanks. Fixed, this note is not relevant anymore, Nim has closures.
import macros
macro tpub*(x: untyped): untyped =
## Marks a proc with an export asterisk when ``-d:testing`` is defined.
expectKind(x, RoutineNodes)
when defined(testing):
let n = name(x)
x.name = newTree(nnkPostfix, ident"*", n)
result = x
Well bugs are bugs and only critical bugs are scheduled to be fixed before v1.
The JS backend is not special in this regard, it's widely used and quite stable
too.
[https://github.com/nim-lang/Nim/issues/4470](https://github.com/nim-lang/Nim/issues/4470)
seems to be the worst offender here.
Well without the test data that `sort` fails on, there is little I can do.
https://github.com/nim-lang/Nim/issues/4653
The problem is that a `nil` check can always be inserted manually, but it's
harder to get rid of it when the compiler emits it. Conversions to `cstring`
should be as fast as possible and code size should be small.
It's one of those days ...
[https://nim-lang.org/blog/2017/05/17/version-0170-released.html](https://nim-lang.org/blog/2017/05/17/version-0170-released.html)
Enjoy! (Yes, all the concepts enhancements made it into this release!)
The full output of `sh build.sh && bin/nim c koch && ./koch tools` would be
useful.
I don't like the dots and think we should deprecate them.
> I was not off-topic. This thread got pivoted to discussion of preferred
> communication methods by Araq himself before I got here.
Oh yeah and I regretted this remark... It's fine to ask newbie questions here,
the forum will get a section for this.
Now consider this thread **
Well the "compilation cache" / "symbol files" / "incremental recompilation"
feature is in the works and indeed it treats `slurp` like `include` and so will
notice if the dependency changed or not. But this feature is not yet ready for
anything. Regardless of it, macros are always re-evaluated
Seqs own the data they contain, views don't, conceptually there is no safe way
to create a seq from a view without a copy.
You can pass zero-copy slices in a `parallel` statement
`--gc:regions` will let you do that and is not far away, maybe a couple of
weeks...
Your solution is just fine once you replace `quote do:` by a dirty
template+getAst (the preferred way to construct ASTs these days).
> I got tired of creating reference using the PIMPL or the following pattern
var s:ref Person
new(s)
s.age ...
Er, I think you use Nim wrong, (ref) object construction can be done like this:
var s = (ref Person)(age: 3, name: "Burns")
No tuples, no
This is not supported via `exportc`, but you can also use a `.codegenDecl`
annotation to achieve it, no need for `.emit`.
Yeah, that change needs to be reverted, I got other reports about this problem.
Redox looks impressive and while it would be nice for us if it were written in
Nim, it's high time people stop writing C code. It's a nice project.
Too bad it implements a Unix which means a **stringly typed** programming
environment, defective shell scripting languages, tons of red tape,
Yes, you are needed, it's not overkill when 2 people work on the most wanted
feature for Nim. :)
1. Agreed, I like this better too.
2. Dunno, will tell you when I review your code.
3. Agreed and `default(T)` at least is useful on its own.
4. Dunno.
Btw neither yours nor Zahary's work
`importcpp` works just fine with generics, every generic instantiation is then
imported in the same way.
Stop wasting everyone's time. Consider this thread closed.
Status of concepts:
* The documentation is outdated.
* "Generic concepts" (Foo[T] = concept) don't work.
* Symbol lookup rules in concepts need to be refined.
* Unlikely to become stable for v1.
> You will be forced to moderate posts like this soon.
But I did moderate. I guess I should censor the next time.
Compiler bug aside, you need to instantiate the procs, like
`@[presentModeA[string], presentModeB[string]]`.
Not strange, MingW uses the libc that ships with Windows since Win95 days
whereas VCC keeps updating its libc. It's actually a feature of MingW so that
the executables have no external deps. Hard to fix these issues except perhaps
getting rid of libc altogether (there are some Nim development
> Quiz 2: Now, imagine that you are a nim newbie. Try to fix the errors with
> the help of nim manual and compiler error messages. Or,better yet, ask a nim
> beginner to fix the code and watch the frustration grow.
Or better yet, you ask a beginner who can read a tutorial again to look at some
Cross module inline procs are inlined across modules without link time
optimization, the Nim compiler duplicates the inline procs in the generated C
code.
It needs to be documented, c2nim generates it, so it's "officially" a part of
Nim.
Untested idea:
template cppDefinedMacro(def, body: untyped) =
{.emit: "CPP_DEFINED_MACRO(", def, ") {", body, "}".}
cppDefinedMacro "yay":
cpp_defined_function(param1)
other_cpp_defined_function(param2, param3)
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
1. When I said "we need to do something about it", I had something in mind
like `12f` instead of `12'f32` which is what we have now for several versions.
2. Most of `math.nim` supports both floats and doubles.
3. `Vector3d` etc need to be made generic, no language change required.
That
Maybe you don't have a user level PATH environment variable then?
> It seems Araq doesn't really like my way of thinking. I can also see how Araq
> reacted to pointing out formatFloat's odd behaviour for 0 (which was quite
> odd to me, too). I, for instance, didn't notice it myself as I don't really
> use Nim for numerical calculations (I use For
* I would discuss it on this forum, but if you're keen on having a "threaded"
discussion, we can also try reddit.
* In my experience if you're looking for collaboration, IRC or Gitter work
much better. You may not need real-time, but it helps. ;) Just compare how long
it took me to reply
We use `koch xz` to build the tarballs which does populate "dist":
proc xz(args: string) =
bundleNimbleSrc()
bundleNimsuggest(false)
...
Use this: `sequtils.toSeq` to prevent the compiler from trying to use nre's
version of it. Oh and don't use nre.
If you are on a 64 bit machine, Nim's `int` is 64 bits, C's is 32 bits. Use
`int32` for a fair comparison. Seems unlikely to be the cause of the slowdown,
but you never know. Definitely an interesting difference to look into. (Factor
of 3-4 wtf...)
The implementation and the spec are developed together and I don't want to say
more until I'm sure it's not embarrassingly wrong. But things are starting to
look really good, expect a blog post about this in a couple of days.
Well the C standard solution nowadays is that the cast must go through a union
type and the code generator already can do that. PRs are welcome.
> So what do you do: do you tell these teams not to use refs? Or do you tell
> them to go ahead and use refs and garbage collection, and deal with the
> consequences?
To be honest I would fire teams who model business taxonomies with C++ classes
(OMG), keeping all the data in RAM (OMG) and not
`expandMacros` with its conversion to `typed` is really fragile with today's
compiler. Instead use this to see what's going on:
import future
import macros
macro decDumbType(): untyped =
result =
macros.quote do:
type Dumb = ref object of RootObj
Sorry, I couldn't test this program, but I fixed the memory allocator and
hopefully this bug disappears now. Please retry with devel.
Please, focus on Nimble lockfiles.
> Nimble (and Nim itself for that matter) don't support a dependency on two
> different versions of the same package. Is this a problem that will bite us
> in the future?
No, IMO it's a very reasonable limitation.
Interesting observation (and worth a github issue!), but as far as I'm
concerned that `fwrite` is correct and `fputs` must not do any encoding
conversions either. Either set the codepage to UTF-8 or use Nim's `encodings`
module.
Looking at
[https://docs.python.org/3/library/string.html](https://docs.python.org/3/library/string.html)
I don't see too many things wrong with Nim's documentation. Yes you can ignore
stuff in `{. .}` (and we should hide it). On the other hand, at least every
parameter has its type listed
Lol, please don't. I'm tired of nano improvements that make me touch thousands
of lines of code. We need to ship what we have and call it a day. I don't
remember mistyping these names all too often. And for other defines you can do:
when defined(foo):
const useFoo = true
Regarding the development process: Forum posts like yours are perfectly
acceptable to start a discussion but then the results should be extracted into
a "Nim enhancement proposal" (NEP) that are for new kept on the github wiki.
(We only have NEP-1 so far, the Nim style guide.)
In your snippet you don't have to split up this in 2 different procs. And even
if you do, you can pass `server` as a parameter.
> And, more generally, does that mean I still need to use shared-heap to pass
> messages/signals across async tasks?
I think you can also use (async) queues instead.
> Why can't someone else do it?
Fair enough, somebody else can do it. My work is then only to review the patch.
The problem is though, that on top of the "it's work for me" argument, I don't
want the feature. I don't see the point. The conflicts that do arise are all
about ALLCAPS and I don't
Cool, I will try it out! what would it take to merge this project with Aporia?
Well `object` is the obvious replacement, but this indeed does not cover all
the use cases of named tuples. I like to remove named tuples to simplify the
language. Maybe this means `object` needs to grow minor new capabilities.
> I'm not sure if the DSL I'm designing would work without them.
Well? Anything we can do about that?
proc pprint(annotation: string): (proc(t0: T1): T1) =
# ... some usage of annotation parameter ..
Parenthesis help.
Well I edited the document a bit but as soon as all the missing examples are
added I don't see the advantage over the existing tutorials and introductions.
I think it's better to focus on the advantages vs disadvantages aspect and not
turn it into another tutorial. Advantages could include
Well rewrite rules need to be able to target these `var result` operations (as
I call them) so they need to exist anyway.
@jlp765 On what OS do you get that much jitter?
var myPendingRequests {.threadvar.}: HashSet[ptr MsgBase]
myPendingRequests.init()
The compiler made you write this, it disallows `var myPendingRequests
{.threadvar.} = initSet[ptr MsgBase]()`. Ever wondered why? Because it would
only run for the main thread. I improved its error
> @[] and "" don't have to actually differ from nil, it could be an
> implementation detail. Pretty much like option[ref T not nil] can be
> implemented as ref T.
Yep. And that's how it will be done.
We finally pulled the plug, new release has arrived. See
[http://nim-lang.org/news/2016_09_30_version_0_15_0_released.html?ref=forum](http://forum.nim-lang.org///nim-lang.org/news/2016_09_30_version_0_15_0_released.html?ref=forum)
for the details.
There are actually "filters" and "parsers" and "standard" means the standard
indentation based syntax/parser. Which is also the default and so the `|
standard` part can be left out.
Your WORST solution is what the C backend would have emitted.
> Why not add a flag to set/disable the iteration limit like he wants? I'm sure
> that as the user base grows, more people are going to hit the limit and get
> annoyed.
Because I am curious whether it can be supported out of the box by a
"reasonable" limit first.
Well you can always switch it off and see what happens, "complex real world
example" or not. You can also disable it selectively per thread or per time
critical code part. you can also break up cycles manually via `ptr` and that's
where Nim should be improving. Swift too embraces this model.
No, that's not supported. You can implement it as a compiler plugin but you
need to ensure that no codegen phase starts before your plugin did its
transformation which is kind of hard to ensure with the current pipelined
architecture in the compiler.
It's also not a wise thing to attempt, it
Try instead
macro duplicate(procStmt: untyped): untyped =
...
Let's go through your examples now.
type StrangeConcept[T] = concept c
c is T # Equivalent to "c is any", which is true
float(c) is T # Equivalent to "float(c) is any", which is true
$c is T # Equivalent to "$c is any", which is true
when int is StrangeConcept:
Yeah ok, you can only compile a single Nim program to JS. But that program can
consist of as many Nim modules as necessary.
It always was the plan to use `^` and only `^` for exponentiation, so please go
ahead with your PR. :)
Can you please keep us up-to-date about your game?
In fact, this problem is so severe (every proc returning a string is affected)
I thought about more language support for it:
Every routine `foo(result: var T; args)` can be used as an expression of type
`T` via the transformation into `(var res = default(T); foo(res, args); res)`
You have your own `withLock` implementation that the instantiation of `mget`
prefers which introduces a new scope and so `hasKey` is outside of the scope.
Probably sharedtables should be changed so that `withLock` is not used as a
mixin. In the meantime, name yours `withL` and it compiles if
Works just fine:
import macros
macro model(name: string; body: untyped): untyped =
echo treeRepr body
model "Person":
field Name(string):
max_length = 128
field Age(int):
unsigned
validate Age > 20
The only thing you
1 - 100 of 1662 matches
Mail list logo
