sure the DLLs also compiled in same arch, if compiling 32 bit, use 32 bit
DLL, 64 bit use 64 bit DLL.
Run
where i can download x86 dlls?
https://www.libsdl.org/download-2.0.php
make sure the DLLs also compiled in same arch, if compiling 32 bit, use 32 bit
DLL, 64 bit use 64 bit DLL.
> any major changes in the last few months?
1. Strings and seqs defaulted to empty, not nil.
2. Any instance of assigning strings and seqs with nil will make
compiling-error.
3. Use option `--nilseqs:on` to make the transition lean from 0.18.0 to 0.19.0
i put all dlls and, nimedit does not start. just i trying to open
nimedit.exe(double click), and Nothing happens
Take my advice with caution as I'm no Windows expert but I think you need to
put the .dll into a standard path like C:WindowsSystem.
> any major changes in the last few months?
You don't have to initialize your strings and sequences manually anymore.
i installed mingw64, and nimedit compiled sucessfully, but it needs SDL2.dll. i
put it to directory with nimedit.exe, but it needs SDL2.dll again. what i need
do, for start nimedit.exe?
Are you sure you've downloaded and installed Nim and MingW for the right
architecture (32-bit vs 64 bit) and matching your Windows arch?
**(1)** I think both nimedit and aporia were small experimental projects that
didn't get very far and that no one really uses. [More than
half](https://nim-lang.org/blog/2018/10/27/community-survey-results-2018.html)
of Nim devs use [vscode](https://code.visualstudio.com), which has by far the
I couldn't reproduce the problem, neither on nim v0.19.0 release nor today's
#devel, running under Ubuntu 18-10.
For my test I created two basic download loop daemons:
**dlHttpClient.nim** using Nim stdlib as above -
import os, times, httpClient
var client = newHttpClient(
i tried compile using gcc, but compilation failed:
: execution of an external compiler program 'gcc.exe -c -w
-mno-ms-bitfields -DWIN32_LEAN_AND_MEAN
-IC:\Users\╨Р╨┤╨╝╨╕╨╜╨╕╤Б╤В╤А╨░╤В╨╛╤А\Desktop\nim-0.19.0\lib -o
C:\Users\╨Р╨┤╨╝╨╕╨╜╨╕╤Б╤В╤А╨░╤В╨╛╤А\nimcache\nimedit_d\stdlib_str
That error means that you either have no gcc (gnu C compiler) installed or it's
not in your Path.
If I remember correctly on Nim's download page you can download a .zip file
that also includes MingW. Once you have it unzipped there is an .exe (the docu
provides the name of that .exe file) that
Hello. I use Linux but I might be able to help.
If I'm understanding properly, it looks like Windows does not recognize `gcc`
as a command. What happens if you run `gcc` in a `cmd` window? Do you get an
error? I think that MinGW isn't installed or isn't in the `PATH`.
By the way, `nimedit` and
I'm glad to see that your itch is gone ;)
Let me explain my view a bit better (also for future reference for others).
A language is design + lots and lots of (hopefully good) work. Most people only
see the work but not the design which is largely about making the right choices
and decisions.
T
hi, how i can compile nimedit on "aporia edit"? i'm tried compile nimedit,
:\Users\Администратор\Desktop\nimedit-master>nim -d:useNimx c nimedit.nim
Hint: used config file
'C:\Users\╨Р╨┤╨╝╨╕╨╜╨╕╤Б╤В╤А╨░╤В╨╛╤А\Desktop\nim-0.19.0\config\nim.cfg' [Conf]
Hint: used config file
'
Seems like there was a misunderstanding here.
Note that there are different iterations of the tests, and we are talking about
the ones published as " **round 17** ".
Also note that there are 12 result tab combinations: 6 tests times 2 test
environments. **Nim participated in four of the twelve
One more thing. If there is no warning then I think by default there should be
a warning about style inconsistency which people can turn off if they want,
maybe the warning says how to turn it off.
As far as user adoption / feedback, I think that the extraordinary efforts that
a small number of
I was just dealing with case typos in a C++ program this morning. I wasted a
few minutes with stupid mistakes. It is making me consider converting the whole
thing to Nim because of that and other issues.
The FAQ on this is totally correct.
You absolutely should not get rid of this style insensi
The code below used to work prior to 0.19.0. This procedure runs in a thread
and the resulting FlowVar is stored in a sequence in the calling routine. It
seems to only error out if the folder does not exist, but I'm not certain about
that. It runs fine sequentially (without threading). This is r
"Let's then remove _ as a digit separator because of grep." \- It's not as
common to grep for numerical values as for names.
I don't care much if there's a vote or not, but I really don't think it should
be changed.
But I do think Nim should issue warnings about difference in style though. I
t
It means allocations >= 1GB are requested from the OS directly and returned
back to the OS directly.
> Does that mean that the GC works like a memory pool and subsequent ref types
> new are "costless" from a memory point of view?
Well the allocator asks the OS for a "chunk" of memory and subdiv
Hello all,
Several months ago, life started to get quite busy and now I have much less
present here since August. For me, coding is a hobby, and I haven't had much
time for it lately. Luckily, I have a bit more free time, and I'm really
curious what's been happening with Nim in the last few mon
I think a vote is good, will be voting no for the change though
Let's then remove _ as a digit separator because of grep.
maybe we could add a naive topN based on sort + slice last N elements, so
clients can start using that, and then they'd benefit when a proper topN is in
stdlib
## example implementations
*
[https://dlang.org/library/std/algorithm/sorting/top_n.html](https://dlang.org/library/std/algorithm/so
Is it 1GB per allocation, or total memory allocated?
Does that mean that the GC works like a memory pool and subsequent ref types
`new` are "costless" from a memory point of view?
Will that change with destructors?
Do you plan to implement nimgrep for github and IDEs too? Btw, removing this
"feature" wouldn't dumb down Nim because this feature is already dumb - the
fact that we need to change our standard tools for its mythical benefits
already tells a lot about the ecosystem for an outsider.
And that's why there is a nimgrep.
No, keep it. Style insensitivity is nice and quite easy to understand. Dumbing
down Nim is a road to nowhere. BTW Nim style insensitivity is an eccentric
feature but not unique:
[http://mozart-dev.sourceforge.net/xl_features.html#namestyle](http://mozart-dev.sourceforge.net/xl_features.html#name
> I like the idea of a vote not because I believe that language design is some
> kind of democracy (really, where do people get these ideas?) but because
> language design is partly UI design, UI design is guided by users, and one
> way to get user feedback is a vote.
Agree 100%
@moerm grep -i is not style-insensitive, it's only case-insensitive which means
it'll be useless most of the time. This feature shouldn't be in any language.
I like the idea of a vote **not** because I believe that language design is
some kind of democracy (really, where do people get these ideas?) but because
language design is partly UI design, UI design is guided by users, and one way
to get user feedback is a vote. Ideally, it would be more than
> httpbeast isn't #14, it's #10
I think we are looking at different techempower results. Please link to what
you're looking at, and keep in mind that it might not be the most recent run or
the most reliable.
> Would you recommend httpbeast (or jester, or ...) for production use? If I
> remembe
Nim's memory manager does give memory back to the OS, but only if the
allocation is over `HugeChunkSize`, which is roughly 1 GB. And yeah, returning
memory back to the OS is difficult because `munmap` is fundamentally broken but
that's a story for another day.
> Global variables are never collected as they never go out of scope
Indeed, but we can set them to nil or for case of string or seq assign virgin
copy.
My first guess was indeed that his observation was related to global variable,
so I tried a variant of his code, where I made the seq local to
Itch gone :)
No problem that you want to focus on 1.0, was just wondering about the async
story for Nim since last I visited.
I guess io-lib today support non-blocking-io for async/await. A fiber
implementation should be able to build ontop of this, saving a lot of work.
Also awaiting results from a spawned procedure call is relevant for a
hypotetical fiber implementation. Interesting, this almost seems doable :) I
do
I agree with @dom96. We have threading (even a luxury comfort version) and we
have asynch. That's the basis for a modern language (which many do _not_ have).
Fibers are a gadget. Nice to have but if that comes only in 2.0 that's good
enough imo.
Excuse my somewhat harsh statement but right now
> because they are provably false
So is yours :p
> Nim is #1 on JSON and #14 on Plaintext.
httpbeast isn't #14, it's #10
> Whoa. That's a bit unfair, don't you think? My replies are certainly more
> direct than usual, but they are in no way mocking or derogatory.
No, calling someones stat
Glad you find it useful! The macro checks for an existing `module.exports`
object, and if one exists, it appends its exports to the existing object
without overriding previous exports. There could be collisions if two different
files try to export an object with the same name, but for now I thin
Just a fresh example: I was searching for a function in someone's github repo
and I couldn't find it - guess why - the author used camel case in the examples
while it was defined with snake case in the code. This feature only caused me
issues so far.
> Every great invention was built on the shoulders of giants, and the light
> bulb is no exception. Attributing it to a single man is misleading.
Correct. But: Out of billions of people only a select few did invent or create
things. Others could have stood on the same shoulders of giants - but d
Global variables are never collected as they never go out of scope
Thanks @nepeckman, it is very helpful for me at least.
but... I see some issues if created more export modules then the global
variables and functions theoretically could be overwritten from latest imported
module. My suggestion is wrap the export code into {. emit: """(function(){"""
.} {
Style insensitivity is bad when you try to use tools like grep, sed etc. and it
also confuses a lot of people. **I want a vote.**
It may be on the cards for the far future. But for 1.0 we are betting on async
await. Here are some of the things that I have planned to make async await
better, but again this might be long after 1.0:
* Alloc-free futures to reduce overhead as much as possible
* Integration of the Nim threa
> Just like the light bulb Nim wasn't invented by a democratic vote. It was
> created by one particular smart man.
Every great invention was built on the shoulders of giants, and the light bulb
is no exception. Attributing it to a single man is misleading.
This also goes for Nim. Araq doesn't m
> I have recently also noticed @dom96 being snarky in his replies on the
> internet on posts related to Nim.
Whoa. That's a bit unfair, don't you think? My replies are certainly more
direct than usual, but they are in no way mocking or derogatory. But if they
were then that certainly wasn't my
After some time away from Nim I now notice that the async story for Nim seems
to be based around async/await. Is this correct?
I have some bad experience working with async/await in big Typescript projects.
async/await is much better that callbacks and promises, but still, the
async/await has a
> You find my "suggestions" ridiculous? It's sad to hear that from a central
> figure in our Nim community. It's sad to see that attitude. And quite
> different it seems to me than @Araq's always positive and constructive
> attitude; when someone recently really criticized Nim Araq actually aske
I have recently also noticed @dom96 being snarky in his replies on the internet
on posts related to Nim. I do not know why is that. Did something recently
change ?
@moerm
People first need to have a use case for such components in Nim. You can see
the use case for all the libs @mratism and oth
I think what everybody is missing is that it's not about "we can make it work",
but about removing the weakest (easiest to attack) surfaces in "let's adopt Nim
discussions". I like the insensitivity and it seems like a smart choice, but if
I have to choose between this and 15 other good Nim feat
@miran
Oops, my bad, you are right. But I guess one can get my point anyway.
TL;DR: The name of something should be what the developer writes. Period.
And: I happen to be a convinced fan of case sensitivity but I can understand
the arguments of the other side (and can live well with both).
@andrea
I get your point and you are probably right. My apologies.
What I meant was that Nim seems not (yet) to be far and/or good enough to be in
the upper rankings - which, of course, may also be due to simply not yet having
adequate code to TE.
That's why I pointed out and insisted that I'm
@moerm I think the misunderstanding stems from your claims
> To be frank, almost everything seems to be faster than Nim in the techempower
> benchmark. > A quick look at Single query, Multiple queries, Fortunes, Data
> updates (all "physical"), each with all sub-categories, showed that Nim was
56 matches
Mail list logo
