@Araq,
Fiddled around in the generated C file in the **nimcache** directory by adding
code to load the library **libpython3.5m.so.1.0** in C directly and it throws
the same error!
The added code (added to the generated **PyInit_nim_module** function) is:
N_CDECL(..., PyInit_nim_m
I love vendoring. I will vote for vendoring. I think some thing like this would
be cool:
It would be cool if nimble install X just installed stuff in the current
folder's 'lib/pkgs/deps' directory and updated/created .nimble to reflect the
installed dependancies and their versions.
Its magical
**@dom96** The idea is that any release zip of source code would contain the
vendor libraries. Most of the time you wouldn't check them in.
The NuGet package manager for .net does something similar (as does nom), in
that packages for a project are local to the project, and stored in a
"packages
Speaking of which, it's useful to track what dependencies (and exact versions)
were used in a build and ship this information with the binary.
This can be used to automatically identify if a binary was built against
libraries affected by known vulnerabilities or that use obsolete protocol/file
> Often times they don't even have a project. Creating a .nimble file just to
> play around with a package would be tedious.
it isn't, as long as it's just a nimble init away. AFAIK
[stack](https://docs.haskellstack.org/en/stable/README/) and other modern build
tools work this way and they're d
@jxy yes there is a difference betwen `ref A` and `ptr A`. When the ref is
implemented as an `std::shared_ptr` (I think Araq mentioned an option once to
do that), then `ref A` takes over the ownership and as soon as the reference is
deleted, also the memory will be deleted. You don't want that,
**@euant**
> In addition to what you've mentioned, Nimble also really could do with having
> the ability to vendor packages within a package/application rather than
> always relying on a global package store.
It seems that a lot of people really want vendoring. But to me it just seems
like a p
**@andrea**
> For some reason, though, I often see libraries that recommend to do nimble
> install to make them available.
I believe the reason this recommendation is so widespread is that developers
very often prefer to test out packages before adopting them into their project.
Often times th
**@Araq** thanks! Your feedback is highly appreciated!
**@jangko** well, as far as I can understand you want something like this:
from mycode import MyType
from nesm import serialize
... # there is no code generation of the serialize procedure for MyType
let obj = MyType
I thought it would be a nice idea to create a better nimble readme:
[https://github.com/yglukhov/better-nimble-doc/blob/master/README.md](https://github.com/yglukhov/better-nimble-doc/blob/master/README.md)
The basic idea is to define the readme as if better nimble already existed.
How would one
I think one thing that would hlp with your first point would be to add a new
option to nimble, such as nimble install --save tempdir (using one of my
packages for example). This is stolen from NPM (node's package manager) which
uses both \--save and \--save-dev to mean that the package argument
I'm using
template asarray*[T](p:pointer):auto =
type A{.unchecked.} = array[0..0,T]
cast[ptr A](p)
for now.
Is there a difference between `cast[ptr A](p)` and `cast[ref A](p)` here?
> I question the results when something beats C for speed. Either it is poor C
> code, or there is something weird going on.
Or, the compiler is able to take advantage of information in language X source
not available from the C source to generate better code than available C
compilers? That's
When creating a software project, it is important that it is reproducible. This
means that the dependencies for that project are not, for instance, globally
installed on the developer machine, but there is an automated way to retrieve
them and make it available.
Many language-specific package m
thanks **@bpr**
I can reproduce the problem but have no idea how this happens. In the end it
looks like a hang pipe-process.
I moved my findings to
[https://github.com/nim-lang/Nim/issues/5796](https://github.com/nim-lang/Nim/issues/5796)
as there are lengthy listings presented which might be not of general in
[@euant](https://forum.nim-lang.org/postActivity.xml#18478): I timed your code
but I didn't see a consistent speed-up. Sometimes it was a few milliseconds
faster, sometimes slower, so I would guess it and the original compile down to
the same C. But I like the idea that there are still tweaks to
> (for example, doesn't have a field of type Socket/File/stream/callbacks)
in this case, user intervention is needed, but using non-intrusive serializer,
the intervention is minimal.
And the code to manage this special case can be put among the other serializer
routines, no need to modify the s
@mashingan Yes, I can convert the iterator to seq and all works. But it not the
way I want. I hope the iterator is same as seq, like following code:
print collectz(1..5, @[toSeq(1..it)])
print collectz(@[1,2,3], @[toSeq(1..it)])
print collectz(countup(1,4), @[toSeq(1..it)])
**@slangmgh**,
[accumulateResult](https://nim-lang.org/docs/system.html#accumulateResult.t,expr)
cannot help?
@cdome That doesn't work, because iterator is treated as untyped, and untyped
parameter cannot be overloaded. The following code cannot compile.
proc f1(t: seq[int]) = discard
template f1(t: untyped) = discard
f1(@[1])
f1(countup(1,3))
> I don't think Nim is ready for 1.0 yet. It's close, but not quite there.
I agree with you, so please take
[this](https://engtech.wordpress.com/2007/04/20/shoot-the-engineers-and-ship-the-product/)
in good fun .
Hey @dom96, it works on OS X, great job!
> I shouldn't need to remind you that Nim is an open source project developed
> by passionate people in their spare time (this is still mostly the case
> nowadays), we really need everyone to pitch in
An article/tutorial/example for starting hacking the Nim would greatly help, I
think
**@vonH
> Agreed, but we have some issues.
Every language has issues. But I get your point: you want 1.0 to be released
ASAP. I want that too, but I also believe that we have to be careful, releasing
1.0 before Nim is truly ready could be disastrous for its future.
I don't think Nim is ready for 1.0 ye
> It's time to write thoughtful comments that encourage developers to use Nim
Agreed, but we have some issues. Consider the excellent article in 'How I
start: Nim', which begins
> Nim is a young and exciting imperative programming language that is nearing
> its 1.0 release.
Wat? Nim has been n
> @vonH People told you why they downvoted you. And no, it's not time for a
> "Nim Evangelism Strikeforce", this isn't something to aim for. It's time to
> write thoughtful comments that encourage developers to use Nim, not
> "drive-by" comments that give our community a bad name
I don't think
27 matches
Mail list logo
