Hi all,
Trying to learn nim's FFI by importing some openssl functionalities into my nim
code. The code that I ended up with performs well, and is comparable to that of
shasum. Then I went on to make it a bit more "OS neutral" by adding the proper
library checks from nim's openssl.nim, and immed
maybe with static, when and inject:
import strformat
# https://forum.nim-lang.org/t/6616#40996
#[
template createVar(name, value) =
var name {.inject.} = value
createVar(variable, 100)
]#
template doSth(i: static[int]): untyped =
w
You sure can!
Use `inject` pragma. Here's an example:
[https://github.com/moigagoo/norm/blob/develop/src/norm/sqlite.nim#L36](https://github.com/moigagoo/norm/blob/develop/src/norm/sqlite.nim#L36)
I don't know if a template is the right way to do it, but this is what I'm
trying to do:
template doSth(i: int): untyped =
if i>=1:
let x = "X"
if i>=2:
let y = "Y"
.
proc someOtherProc() =
doSth(1)
The listed error kind of points to a failed SSL handshake. AFAIK, openssl
requires some basic initilisaton steps. . Your example does not list them but I
trust you're performing those steps?
import net, openssl
SSL_library_init()
OpenSSL_add_all_algorithms()
#
lum,
Thanks for the help!
My example is somewhat misleading as I was just trying to make a short and easy
to read example of the problem. So I chose a simple web connection. I agree
with you, if I was trying to reach a web server or any server that used a web
api, **httpClient** would be the w
My machine has `OpenSSL 1.1.1f 31 Mar 2020` installed on it. I find no
references to `libressl`.
And, I see the following libs:
./usr/lib/i386-linux-gnu/libssl.so.1.1
./usr/lib/x86_64-linux-gnu/libssl.so.1.1
Run
Is openssl problematic?
I see a "nimssl" package in
Hello !
I am having a hard time making Nim compile static (compile-time) expressions
using procedure closures with the JavaScript backend.
Example:
import std/[sugar]
func f (): int =
let
a = 1
b = (i: int) => a + i
a + b(a)
when
Ok, yeah then I get what you're getting at :) A certain amount of overhead must
always be expected from a scheduler but this suggests there's room for
improvements (Weave is relatively young after all).
True a busier CPU is better. Though the timer in there pretty much assures that
the application is not CPU limited and the extra CPU cycles points to needless
spinning threads. I have edited the examples to have the application complete a
fixed piece of work. The thread-pool example is marginall
Thanks for the advice. I'll watch for your next video.
I've recently experimented with using the [compiler
API](https://github.com/nim-lang/Nim/blob/devel/tests/compilerapi/tcompilerapi.nim)
for hot code reloading. I know there is already an [hcr
module](https://nim-lang.org/docs/hotcodereloading.html), but I think using the
Nimscript interpreter c
Isn't a high CPU usage a good thing when it comes to multithreading? It means
more of the cpu is utilized. But if they are doing the same work in the same
amount of time then I understand your concerns. Have you benchmarked how fast
Weave and threadpool takes to finish? Are they equally fast?
I recently converted my threadpool + async (asynctools) tool to use just
threadpool or weave cause asynctools no longer builds for me.
I notice that weave is certainly slower than threadpool - at least 20-30%
slower.
Build:
git clone https://github.com/genotrance/autodup
cd a
I love weave but I think the CPU usage is still way higher then threadpool
native for my needs. The lowest CPU usage I could get in this contrived example
below is 7.3% for weave and 0.09% for threadpool.
proc fib(n: int): int =
# int64 on x86-64
if n < 2:
return
The answer is one you are probably not wanting: don't use global vars in a web
page unless that structure is specifically designed to be thread-safe. Some
work arounds:
1\. If the var is not changing, make it a `const`. Global constants are
perfectly safe in a thread.
2\. You can use a templat
When I look at the Nim Forums source, the globals don't have any special
pragmas:
[https://github.com/nim-lang/nimforum/blob/master/src/forum.nim](https://github.com/nim-lang/nimforum/blob/master/src/forum.nim)
However when I compile my own Jester web app in release mode, the globals fail
if th
Personally, I use `object` as much as possible.
What is lost by some copies, I expect it to be recovered by an optimizer which
will not be disturbed by assignments via references. For global optimization,
better use a strong typed language and avoid aliasing.
I think that, on this respect, over
> Unfortunately we have only 20 releases left up to 1.0, so I can not make a
> new release for each tiny bug.
Ummm, what?
You do know that two-digit minor-version numbers like 0.10.x, 0.11.x, ...,
0.99.x are possible, right?
HELLO
gintro 0.8.0
a) I really blame myself for not having thought of changing "cstring to string"
it was the error for my modules which used gtk3
gintro # head
b) I recompiled my programs with "gtk-VTE" and there I no longer have any "ttt"
problems
c) following the "ttt" problem: b) i was t
You can also use **httpClient** (stdlib) for this:
import httpClient
let client = newHttpClient()
var content = client.getContent("https://google.com";)
Run
If you want to send custom https request use this:
import httpclient, json
I can't say much without a code snippet.
The introspection capabilities of Nim's macro system do not allow for "get all
types" etc.
One good option is to use the Nim compiler as a library, see
[https://github.com/nim-lang/Nim/blob/devel/tests/compilerapi/tcompilerapi.nim](https://github.com/nim-lang/Nim/blob/devel/tests/compilerapi/tco
I'm sitting on a codebase where `ref object` is everywhere (the Nim compiler).
It's hard to reason about and error prone, today I wouldn't write the code this
way anymore. The optimizers I write also don't like `ref` semantics and that
will be reflected in the performance. Eventually.
24 matches
Mail list logo