Nim 1.6 vs 2 (1.9) Working with channels

This seems to be the fixed version... How should we know what was wrong in the other one? But two things... You use spawn, while the docs say > Note: Channels are designed for the Thread type. They are unstable when used > with spawn changed f

Nim 1.6 vs 2 (1.9) Working with channels

Works like a charm... > Nim Compiler Version 1.6.12 [MacOSX: arm64] Compiled at 2023-03-10 import os,locks #nim -r c -d:orc --threads:on test.nim var commStopDown: Channel[bool] var isDownloadLock:Lock var isDownload = false; proc reader() {.thread.

How to return from a function back to the main application loop

:) This one is reversed your way... admin input on the server side... Sorry... was for jumping on this codebase not fixing yours...

How to return from a function back to the main application loop

Hi Nate, just reversed client/server with loggedin and download without addional socket... sorry the structure is just better based on @Stefan_Salewski work... # reverseserver.nim # see also https://nim-lang.org/docs/asyncnet.html#examples-chat-server import asyncdispat

How to return from a function back to the main application loop

Hi Nate, i am located in europe so we have some time difference... Thanks for sharing your ideas! To quote @Stefan_Salewski Your desired tools will become really complicated, and as it should be a admin support tool, it has to be really robust and reliable. So i see two options. Keep it as it

How to return from a function back to the main application loop

That looks way nicer than the previous code... In my collection of code snippets from this forum i had something to handle the input properly... Also this line gave me some trouble, so i rearranged a bit Enter the command: Connected! Run proc ask(): stri

How to return from a function back to the main application loop

Oh you are 5 steps ahead with choosing the right async implementation right now with only one client at a time and strict request/reply we could get away without async or threads and a single socket... For multi clients there would be more to do.. that stdin in the main loop just would not work

Nim 1.6 vs 2 (1.9) Working with channels

Hi @demetera, this seems to be the basic way of setup, which should work fine for 1.6.12 For me it does... even with this slightly broken example... If you remove the comment from sleep(1) it fails for sure, with "Illegal storage access" Is there any chance that you have some kind of race cond

How to return from a function back to the main application loop

hmmm ok, it's most likely the mix of blocking and async or some not closed connections first you should try that spawn @Stefan_Salewski mentioned and get rid of the second input... since @Stefan_Salewski generously offered to have a look into it. I don't want to interfer... But maybe we c

How to return from a function back to the main application loop

Good that you send the whole output from client and server so i could make sure every byte was send ;) I've spotted another thing while true: let client = await server.accept() echo "New client connected" asyncCheck processClient(client, fileName)

Nim 1.6 vs 2 (1.9) Working with channels

Cool thanks!

Announce: LimDB 0.2.0

Thanks for this great library! Incredible easy to use :)

Nim 1.6 vs 2 (1.9) Working with channels

Hi, i am really intrested in this one. I guess i had similar issues with the channels before reading the docs carefully. Channels have to be stored i a global or set up the complicated way... which i never have tried... Are there any fundamental changes about this in 2.0? Would be a blast :)

How to return from a function back to the main application loop

i don't know exactly what i am talking about... but runForever() in the middle of the code looks like a problem... asyncCheck serve(fileName) should maybe be waitFor serve(fileName) and you can just remove the runForever() an echo after the call to the serve should show you when your call r

Using Socket for File Transfer

Hi @Naterlarsen somehow i don't know why i am writing... In the last trheads you worked on a client server tool. And it seems to work... This code has errors in the basic handling of the sockets... let (client_socket, _) = server.accept() Run Is this even nim? You kno

Only one line will load. Need all lines in directory to load.

@jyapayne you are absolutly right when it goes this way around... and the server requests stuff from the client, sockets are a better fit. I would have maybe put the serverside to the clients... and connect to them one after the other, but then you have to know them. Right now the server can on

Only one line will load. Need all lines in directory to load.

Just to say it loud, i didn't mean to criticize your code. Just wanted to point out why i think a webserver would be a better suited given the experience of the threads author... And you see now we have Filetransfer ;) @Naterlarsen Stick with what you have and count bytes instead of linebreaks.

Only one line will load. Need all lines in directory to load.

Since i am very new to nim, i took this for my own education ;) So here is my approach... Protokoll says * A Server response can have multiple lines * An empty line terminates the response This still has flaws... 1. Files and Pathes cannot have whitespaces. 2. Client does not recogniz

Only one line will load. Need all lines in directory to load.

Sorry i have misguided you with using the : as delimeter which feels natural for me since im on linux. so it splits the c: On windows i guess it should be ; For the resources you are right raw sockets binary is smaller ~250k vs ~1mb But i think this optimisation is maybe not worth the effort unl

Only one line will load. Need all lines in directory to load.

For join and split skip the count server something like var resp = newSeq[string]() for entry in walkDir(my_path,checkDir=true): resp.add(entry.path) client.send(join(resp,":") & "\n") Run client for x in message.split(":"): stdout.wri

Only one line will load. Need all lines in directory to load.

You are on a good way, but I see some trouble ahead. As @jyapayne said invent a Protokoll and write it down. I think that’s a good idea even in simple cases. Given your first implementation your protocol is like * Client initialises a communication with sending a request. * A Request is

Background tasks in jester

Hm it's a bit hard to tell what you've tried, but i guess you could try to create that thread with the rdb. Third parameter on the createThread. This should avoid the gc-safe error. Than use a channel to pass the messages to the the thread.

Newbie needs help with locks and gcsafe and segfaults

Thanks again for the explanation. I am not entirely convinced, because i assume that there are no writes to that global... But there is an other library used inside of that ulid so i have to dig deeper... And in the end i am sure that you are right! in the meanwhile i have found that if i

Newbie needs help with locks and gcsafe and segfaults

Thank you very much... Now i am feeling a bit dump... I have the lock for the db but the compiler surely does not know that :) It protects the ulid global as well... But does this mean that this global inside the ulid package gets allocated everytime i call the ulid function and deallocated whe

Newbie needs help with locks and gcsafe and segfaults

this proc writeToDB(prefix, msg: string) = var uid = fmt“{prefix}-{ulid()}" withLock(lmdb_lock): db.put(uid,msg) Run I get an error after some requests `/Users/gs/.asdf/installs/nim/1.6.10/nimble/pkgs/mummy-0.2.11/mummy/internal.nim(76) enc