A "Nimble Canonical" category makes sense, but many other repositories (npm,
IDE marketplaces etc.) crowdsource the decision of what's "canonical" by
showing usage numbers and offering a rating system. If nimble had this, maybe
even with a more differentiated rating system (compliance with best
@nucky9: same versions of VS-Code and Nim here.
@honhon: checked for leftover/crashed nimsuggest instances, none found.
Vs-Code's Nim plugin starts multiple nimsuggest instances, one for every folder
(Nim package) in the workspace. The problem remains even after a fresh install
of Nim and
I use Visual Studio Code with the Nim plugin and automatic code checking
stopped doing anything a while ago, meaning I don't see red error markers
anymore when I type nonsense. Didn't change the config (files.autoSave is
"afterDelay", nim.lintOnSave is true) and there's apparently no related
> fun(bar()) # n.len=1 ?? why not 0?
Because fun is a macro, not a function. A macro call is not supposed to
"evaluate" its arguments - definitely not untyped ones - before using them. It
takes pieces of code, transforms them into AST nodes (in this case: one node,
hence n.len = 1) and makes a
In the JVM world, maven for Java and sbt for Scala have been used to build
pretty large projects. Obviously, they run into the multi-version-dependency
problem too, and they can handle it without "partial code upgrades" (not the
smartest name IMHO). They use shading, which roughly means
> Interesting, I guess this works because quote doesn't touch the passed in
> backticked identifier and this is then returned intact to the template?
Yes. The different meanings of backtick-quoting ("make an identifier" in the
template, "evaluate in local scope and put here" in the quote block)
@mratsim: The code needs two changes to work:
import macros
macro defthing(name: untyped): untyped =
# used this instead of parseStmt
result = quote do:
let `name` = 1000
# Now things get really weird: added a dummy argument and things work as
To complete the picture: the generated HTML file should be run with emrun
main-wasm.html.
To learn about GC behaviour in WASM, probably any Nim code for testing the GC
(like the one from [here](https://forum.nim-lang.org/t/2646)) could be run in
the browser. If someone already had some
Never lost sleep over undefined and bottom. You are really lucky I'm not
Libman, this could be a two page excursion.
@StasB: The first definition is just a complicated way to write the second one.
typedesc parameters make a proc generic, just like square bracket parameters
(apart from special binding behaviour). And yes, that's an ambiguity and
therefore should result in a compiler error.
About the ugliness:
Never liked using a special bracket character for generic type parameters.
# this is not a "generic procedure", it's a procedure constructor.
proc threeOf[A](a: A): array[3, A] =
for i in 0 .. 2:
result[i] = a
# the procedure constructor is called with a
Question to mods: should I reply to this or do we just let the thread die and
hope it stays dead?
@refobj: I agree, some of the names picked by IT-nerds sound somewhat immature
to people. I think that's a cultural thing, partly a reaction to the pompous
fake seriousness of some of the non-nerds in the industry, partly due to the
generally more informal language used in the US-american tech
The [blog entry about profiling
etc.](https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#profiling-with-valgrind)
might help. Here's the short version:
If your'e on Windows: can't help you. Maybe try Linux Subsystem for Windows 10.
If your'e on MacOs or
> There is an easy solution to this problem: case insensitive and style
> insensitive search (which is supported by nimgrep)
Most people edit their code in an editor or IDE, not with an external program.
And they don't like it when a language pushes another tool on them that, from
their
The error is actually not very bizarre, it just says that a proc has been
called with one parameter when it expected two. The procedure is
proc myProc(a: string, b: TcpServer) = echo a
and with some debugging output in the right place
var prc_call =
> I personally urge using a copyfree license for the Nim implementation.
How about Apache v2? It makes it harder for patent lawyers to screw people over
and it is even one-way-ompatible with GPL3, unlike most of the more relaxed
licenses, including copyfree ones.
Trying to compile _use_c_function.nim_ results in
Error: execution of an external compiler program 'gcc -c -w
-I/home/ftep/.choosenim/toolchains/nim-0.17.2/lib -o
/tmp/cftest/nimcache/use_c_function.o /tmp/cftest/nimcache/use_c_function.c'
failed with exit code: 1
which
About concept body proc syntax:
type
ConceptA = int # to avoid the bug
ConceptB = concept c
# both of these work:
# c.myProc(ConceptA) # standard
proc myProc(c: Obj, x: ConceptA)# declarative
Try _epochTime()_.
@boia01: If a faster hash function is used, your code is one third faster than
python.
For those who want to try: clone
[xxHash](https://github.com/Cyan4973/xxHash.git) right next to the Nim source
file and insert this below the _import_ statement:
import hashes
const
> Your syntax for macro's call is OK
Exactly.
@slimshady, @dataPulverizer: General tip: if a macro call is passed to
_dumpTree_ as a block argument and that compiles and prints the call as a
(pre-symbol-binding) AST, then the call syntax is ok:
import macros
dumpTree:
OK, I hope this time I understand what you want
This must be imported in your code example and the macro line defining _iter_
has to be commented out (supplying a closure iterator should also work):
import macros
# gets the name and bound symbol of a constant and does
Added some type safety, used _fieldPairs_ instead of _items_ as an iterator:
import macros, tables, strutils
type
SettingsType = tuple[x: int, y: int, Q: float]
const ProgramName = "MyProgram"
const Settings = (x: 5, y: 3, Q: 12.0)
template
A concept definition would look more like this:
type
CellEditableConcept* = concept c
# some compile-time-checkable criterion that all CellEditables have in
common,
# e.g. a certain proc p (Note the concept-specific syntax).
c.p(string) is bool
> When you think that concepts may work for this case then I will try that,
> thanks.
Just an idea, didn't really analyze your case. To my experience: basic concepts
work, generic and refined concepts can cause trouble as of now.
The call to _setCommand_ ends the nimble run, that's why the second file was
not processed. One possible solution: make testing a file a task of its own
named e.g. _testFile_ and call it as often as needed from another task like
this:
exec "nimble testFile "
Inside
@LeuGim
> Regarding implementation, macro vs. built-in: I wanted to implement such a
> thing some (long) time ago via macros and concepts and was faced then with
> some VM limitations; maybe they were eliminated from then.
Would you be interested in checking that?
> but its implementation is a one liner iirc.
That's ok, these "language extension" packages would be for people who don't
know how straight forward things can be implemented because they are no macro
wizards, like the vast majority of programmers. Once they look at the source,
they will maybe
Just in case I didn't make that clear enough: _explicit_ and _satisfies_ would
be **optional**, I don't want to restrict concepts ore take anything away from
them in any way.
> Concepts in C++ was designed to be used without explicitly stating the
> interface. I thing golang interfaces work
Recently, a thread starting with a simple question went OT and became a
different exchange starting [here](https://forum.nim-lang.org/t/3128/2#19739).
The short version:
"Methods (inheritance based dispatch) and concepts (user defined type classes
with VTable based dispatch) are two solutions
> These are two models, inheritance and type classes, which are different
> answers to the same problem. I can see no good reason to provide both in the
> same language..
I see one difference: with concepts the type match is an implicit one, the
person creating the matching concrete type
> At least Nim would have to instantiate all methods that could be called at
> runtime.
I see. Calculating the minimal set of necessary method instances at compile
time looks hard-to-impossible to me though, at least with multiple-dispatch
methods.
> I think there were suggestions about
Thx for your answers guys.
@def: Does that mean that in order to make methods work with generics, Nim
would have to be able to instantiate methods for generic parameters after
dynamic dispatch (at runtime)?
@Udiknedormi: I see how that would make sense. There is that ambiguity that
_a.host = 34_ can mean two completely different things inside the module:
* call the assignment operator
* call a procedure named _host=_
But Nim seems to consciously embrace ambiguity to accomplish separation of
Probably an [object
variant](https://nim-lang.org/docs/manual.html#types-object-variants). Or maybe
wait until concepts are implemented.
That's because of the sequence. If you would store the objects in two separate
sequences for _Console_ and _ViewportConsole_ instead, you would get the
expected result. Apparently, _var consoles: seq[Console]_ sets the runtime type
of the elements to **exactly** _Console_.
Correct. This is why the name of the field was changed to something other than
_host_ in the updated example code.
The example from the tutorial is a bit misleading, try the updated [version
from the language
manual](https://nim-lang.org/docs/manual.html#procedures-properties) instead.
The _host_ field of a _Socket_ object is invisible to code from a different
module, but the tutorial example code accesses
As I said,
> Currently, I produce the entire block with an emit pragma.
I'm using something similar to your solution now (_emit_ pragma produced by
macro). Good to know that there's apparently no way around the _emit_ here, so
I can stop looking for some _importc_/_importcpp_ magic to
I want to wrap a C++ _#define_ macro in a way that my Nim code is translated to
this in C++:
CPP_DEFINED_MACRO(cpp_defined_identifier) {
cpp_defined_function(param1);
other_cpp_defined_function(param2, param3);
}
Currently, I produce the entire block with an
> Compile my public nim files to make sure they are all syntactically correct.
> Again, the hurdle appears to be identifying the files.
If by "public nim files" you mean files exposed for import by other packages,
nimble seems to have a rule for this: put all non-public files in a source
@andrea Right. And even for a _proc_ returning a non-concrete type (the
original question), calling code would have to know the size of the thing it
gets back, so that cannot work.
As I understand it now:
type
C = concept c
c.num is int
Cvt = vtref C #
@coffeepot Same crash with this:
proc a[T](b: T): string =
$b
var s = @[a]
Seems to be a general problem with non-concrete types (all type classes?).
To clarify: by "bypassing scope rules" I meant that code from the _tables_
module somehow knows about the _hash_ proc defined (privately!) in your code.
Seems strange to me, but maybe I don't know all the rules.
As for whether the behavior is supposed to be as it is: as I recently learned,
the
Wow, read about VTable types for the first time. Sounds as if we will be able
to invent our own kinds of traits, mixins or whatever with this. One degree of
freedom more than any statically typed language I know, great.
# System setup
System: Linux (4.11.3-1-ARCH) 64bit on i5-3475S CPU @ 2.90GHz, 8205MB RAM
Software versions:
* Nim 0.17.0
* emscripten 1.37.12
* clang 4.0.0
* Firefox 53.0.3 (64-bit)
* Chromium 59.0.3071.86 (64-Bit)
# Benchmark results
Benchmarks were cloned from
> I tested with 0.16.1. With current 0.17.1
I used 0.17.0 (stable), same behavior. So now we now what Nim does here:
* _do_ is auto-converted to _do ()_
* The following block does **not** automatically form a scope of its own
The second point is corroborated by the fact that bluenote's
Hi,
> Did any of you try to build the rosseta code opengl example for webasm?
No, I didn't. If I ever try, I will first read the chapter about OpenGL support
in the Emscripten manual. That would tell me something about the various OpenGL
APIs Emscripten offers, how to select one and what
WebAssembly is a 32 bit target (for now), so compiling for 64 bit will not work.
Aah, thx. So maybe a more precise statement would be:
"For dynamic dispatch to work on an object argument, it must be passed as a
reference to the multi-method."
The original sentence from the manual seems a bit ambiguous, especially with
the code example below it, which uses ref _types_.
@mratsim: sry for telling you bs.
Did I misunderstand the manual section about multi-methods? It says:
"For dynamic dispatch to work on an object it should be a reference type as
well."
Methods (multiple dynamic dispatch) will only work for your object type if it
is _ref object_, if this is relevant to your purpose.
@vic1107: Emscripten must be installed so that its compiler is found (through
the PATH environment var I think), didn't mention that in my original post.
Since I did this on Linux and You seem to be on Windows, changing some settings
may be necessary. The compiler user guide probably has some
Yeah, honestly didn't expect that. We need some heavier benchmarking to be sure
that it's viable though, I'm working on that.
As soon as the browser wasm VMs offer access to the HTML page DOM and some
globals (as planned), we could actually bury and forget JavaScript. For me,
personally, this
Since support for WebAssembly 1.0 was just introduced in the nightly builds of
Firefox and Chromium, I gave it a try and things look good, at least with
firefox-nightly. The following nim.cfg
@if emscripten:
cc = clang
clang.exe = "emcc"
clang.linkerexe = "emcc"
Great talk to get people interested. Reminded me of why I got into Nim:
isomorphic programming without much pain and the fact that Nim manages to cover
so many of the basic language features that often seem mutually exclusive. The
question from the audience about easy debugging shows how
@lltp
> You have a look at it and you see a perl-ish "Nim" that you spend weeks to
> learn
No, with skins done right, you wouldn't: the Perl afficionado would have used
an editor which supports a perlish skin for AST display, but saves the source
code as Nim proper (the default skin). You
@dom96 But picknim was much cuter. Is Nintendo now so legally trigger happy
that they will sue over name similarity to Pickmin?
@Libman Once choosenim is ready for prime time, maybe we don't need to rely on
OS specific packages. If choosenim becomes to Nim what rustup is to Rust or
what stack
@Krux02: yes, nim-git is in the AUR. I use it and I'm a fan of AUR in general.
But since Libman wants to offer people the "easy, quick and convenient way" of
installing nim, it is still a pity that we have to point people to the AUR.
Looks a little like "See, we didn't even make it to the
* Arch Linux: 0.15.0, orphaned
I like the idea of "skins", but I think to sell it to people one would have to
change their idea of what a "programming laguage" is.
In the case of web pages, we have three kinds of files: CSS, (X)HTML and XSLT.
They define (in that order) presentation, content/structure and transformation
of
> I only hope that the community starts to grow up
I'm sure you meant just _grow_ here.. :O)
For as much as I have seen, the percentage of "children" and trolls here is
remarkably low. Which could actually change a little once the community grows.
63 matches
Mail list logo
