<< 08-03-2016 >>
00:36:01*jaco60 quit (Ping timeout: 240 seconds)
00:36:16*ddmgy joined #nim
00:41:45*jaco60 joined #nim
00:51:00*desophos quit ()
00:53:48*zepolen quit (Remote host closed the connection)
00:54:27*yglukhov joined #nim
00:55:27ddmgyI've noticed that the irc logs fail sometimes, between midnight and the first logged activity in the channel.
00:55:44ddmgyHere is the error: https://gist.github.com/ddmgy/1bfb548c6c356f3b42ef
00:56:48ddmgyI know that it happens because there is no log available, because it's a new day and nothing has happened in the channel, but I'd like to fix it, so it just displays a blank log with a link to the previous day.
00:57:23ddmgyHowever, I cannot run a local copy of nimbot, which is what renders the irclogs.
00:57:41ddmgyTrying fails with "could not import: SSLv3_method".
00:59:15*yglukhov quit (Ping timeout: 268 seconds)
01:02:00ddmgySSLv3_method is defined by openssl, which I have installed (defined in /usr/lib/include/openssl/ssl.h).
01:04:10ddmgyI see it's also defined in Nim's openssl module (
01:04:21ddmgyhttp://nim-lang.org/docs/openssl.html#SSLv3_method, )
01:05:03ddmgyAnyone have any idea how I might fix this? The error returned by nimbot is rather unhelpful.
01:22:46def-ddmgy: hm, that sounds like your openssl library does not export that function or it has been renamed
01:23:30ddmgydef-: Yeah, that's what I'm thinking. I have the latest openssl package on Arch Linux, but I'll see it I can find a different version somewhere.
01:24:22ddmgyI can't find the symbol in /usr/lib/libssl.so, so that's probably the case.
01:28:28*desophos joined #nim
01:29:29ddmgyAlright, so it looks like Arch Linux builds the package with "no-ssl3-method", which prevents that symbol from being exported.
01:30:18ddmgyI'll build a new package and see if that fixes things.
01:37:40*jaco60 quit (Ping timeout: 250 seconds)
01:39:20*jaco60 joined #nim
01:54:27*zepolen joined #nim
01:58:48*zepolen quit (Ping timeout: 246 seconds)
02:00:55*jaco60 quit (Ping timeout: 268 seconds)
02:04:34*jaco60 joined #nim
02:12:31ddmgymkdir bin
02:12:39ddmgyOops, ignore that.
02:14:15ddmgyOkay, got a working version of openssl, so I can run nimbot now. However, it fails with "Error: unhandled exception: open(result.logFile, log, fmAppend, -1) [AssertionError]"
02:14:21*jaco60 quit (Ping timeout: 248 seconds)
02:14:50*jaco60 joined #nim
02:14:58ddmgyI have a copy of the current irclogs in the same directory as the nimbot binary, and I run it with "./nimbot --il:08-03-2016.html".
02:18:34*Ferbal joined #nim
02:23:27*Demos joined #nim
02:26:10ddmgyOkay, recompiled nimbot with --assertions:on and I can see what the problem is.
02:27:11Ferbalhi all, i was recently trying to complete the recent reddit /r/dailyprogrammer post which focuses on iterating through a csv string/file, calculating US president birth and death dates (when they're alive, really). Since I'm new to Nim, I focused on separating the string, first by new line, then splitting by comma. The loop errors out that at one o
02:27:11Ferbalf the lines with an "index out of bounds" error, the last call being system.nim(2527) sysFatal - anyone know why this might be happening? Maybe it's the input string? my code is here: http://pastebin.com/yFNLfrxV
02:36:45*sorakun quit (Ping timeout: 248 seconds)
02:38:43*brson quit (Ping timeout: 252 seconds)
02:55:59*yglukhov joined #nim
03:00:32*yglukhov quit (Ping timeout: 244 seconds)
03:04:51*kulelu88 quit (Quit: Leaving)
03:18:34*SianaGearz quit (Remote host closed the connection)
03:18:41*SianaGearz joined #nim
03:26:27def-Ferbal: you're putting multiple values with the same key into your presidents table, that's not supported
03:26:41def-at one most value for each key
03:27:37def-(the tables module might be able to handle that more nicely I guess)
03:28:08Ferbalhmm
03:28:47Ferbali think i'm assuming that i'm adding a new element to the presidents table with the key:values
03:29:08Ferbalso basically i'm thinking it was an array of tables? i think?
03:29:49def-yeah, you could do that with a seq of tables
03:30:18def-even easier, a seq of tuple[name, birthDate, birthPlace, deathDate, deathPlace: string]
03:31:16Ferbalwould tuple and table be providing the same thing then?
03:31:45def-a table is more powerful, you could have a variable number of keys and different ones for each table
03:32:02def-but in your case you know that you always store the same keys, so a tuple is sufficient
03:33:40Ferbalokay, interesting. I'll have to look that up (i'm still new to Nim). I was looking for javascript style objects and ended up seeing this: https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers and immediately went to looking up tables
03:34:30Ferbalspecifically, i glanced over the Dictionaries section
03:37:57Ferbalthanks for the info def :)
03:38:51ddmgydom96: Whenever you have a moment and don't mind looking at this, I would appreciate it: https://github.com/nim-lang/nimbot/issues/5
03:39:35ddmgyI'll be sure to read the logs in case there is a response (unless it's just after midnight :p)
03:39:46*ddmgy quit (Quit: Quit)
03:49:31*sarlalian joined #nim
03:57:42*yglukhov joined #nim
04:01:58*yglukhov quit (Ping timeout: 250 seconds)
04:02:57*desophos quit (Read error: Connection reset by peer)
04:16:58*sdw joined #nim
04:17:09*Demos quit (Read error: Connection reset by peer)
04:32:01*Ferbal quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
04:32:34*sarlalian quit (Quit: ZNC 1.6.1 - http://znc.in)
04:39:06*sarlalian joined #nim
04:40:22*Demon_Fox joined #nim
04:42:29*sarlalian quit (Client Quit)
04:42:39*vendethiel joined #nim
04:42:42*sarlalian joined #nim
04:50:33*francisl joined #nim
04:51:14*mrfun joined #nim
04:51:19mrfunhi! would anyone happend to know how to compose iterators?
04:53:56mrfunhere's what i'm trying to do
04:53:57mrfunhttps://gist.github.com/anonymous/040c636a9e416ffff90b
04:59:15*yglukhov joined #nim
05:01:53mrfunActually I just want a recursive iterator
05:03:01mrfunhttps://gist.github.com/anonymous/a00dcf4da3e7a2a69a28
05:03:31*yglukhov quit (Ping timeout: 248 seconds)
05:05:35*vendethiel quit (Ping timeout: 244 seconds)
05:09:01sdwCan you not rewrite it as a proc?
05:10:39mrfunI can. Just found recursive iterators haven't been implemented yet ah
05:11:01mrfunproc just means you have to pass a seq and add elements to it as you go
05:21:32*francisl quit (Quit: francisl)
05:38:58*sarlalian quit (Quit: ZNC 1.6.1 - http://znc.in)
05:46:24*bjz joined #nim
05:49:08*bjz quit (Client Quit)
05:50:44*mrfun quit (Quit: Page closed)
05:56:53*bjz joined #nim
06:02:02*bjz quit (Ping timeout: 268 seconds)
06:06:39*sarlalian joined #nim
06:13:28*sarlalian quit (Quit: ZNC 1.6.1 - http://znc.in)
06:13:41*sarlalian joined #nim
06:24:10*bjz joined #nim
06:46:38*bjz quit (Ping timeout: 250 seconds)
06:46:52*bjz joined #nim
07:00:32*yglukhov joined #nim
07:05:07*yglukhov quit (Ping timeout: 248 seconds)
07:45:23*arnetheduck joined #nim
08:04:37*BitPuffin|osx joined #nim
08:15:51*jaco60 quit (Ping timeout: 268 seconds)
08:17:31*matkuki joined #nim
08:24:17*Arrrr joined #nim
08:24:17*Arrrr quit (Changing host)
08:24:17*Arrrr joined #nim
08:28:03matkukiHi guys, I have a missaligned struct ported from C, can anyone help? https://bpaste.net/show/09e5e041e716
08:28:05matkukiWhen I print the 'm_doc' PyModuleDef field in C, it shows the 'm_name' field
08:31:40matkukia few typo's in the example, but you get the idea
08:32:53*Arrrrr joined #nim
08:33:32flyxmatkuki: I don't think you should use cstring as value type, as cstring are GC'd
08:34:17flyxhmm, or is it?
08:34:21*flyx consults the manual
08:34:27*Arrrrr quit (Client Quit)
08:34:28matkukiflyx: it hasn't caused a problem so far
08:34:50*Arrrr quit (Ping timeout: 244 seconds)
08:37:24flyxhmm, manual says that they're not, but the string values you assign to them might be
08:38:14matkukiit's not that they are nil, they are missaligned
08:38:44flyxhave you checked the C code generated from your Nim code?
08:39:01flyxthe error should be obvious there
08:39:08matkukilet me see...
08:39:17matkukigood idea
08:40:20*Arrrr joined #nim
08:40:20*Arrrr quit (Changing host)
08:40:20*Arrrr joined #nim
08:40:49matkukiflyx: generated structs: https://bpaste.net/show/1cb386ab824e
08:44:58flyxhmm, since NCSTRING is defined as char*, this should work. the problem is probably the size of Pymoduledefbase153541
08:45:17matkukiprobably
08:46:00flyxcan you compare the size of the Nim structure with the original C structure?
08:48:24matkukiyou mean PyModuleDefBase?
08:48:29matkukilet me see...
08:48:31flyxyeah
08:51:25matkukiNim sizeof(PymoduleDefBase) == 24, C sizeof(PyModuleDef_Base) == 20
08:51:41*PMunch joined #nim
08:52:18matkukiwhat is happening here?
08:53:01ArrrrA magic trick
08:53:35matkukiArrrr: any ideas?
08:54:43ArrrrI have exactly 0. But i'm certain some people use python bindings, so maybe you could post your problem on the forum
08:54:49Arrrror maybe stackoverflow
08:56:34flyxcheck sizes of PyObject in Nim vs C
08:56:45matkukiArrrr: will do, but I feel we're so close to the problem
08:56:51matkukiflyx: a sec...
08:57:44flyxalso, m_init should probably have a {.cdecl.}
08:58:16matkukiNim sizeof(PyObject) == 8, C sizeof(PyObject) == 8
08:58:28flyxthen I'm guessing it's m_init
08:58:32ArrrrHow is defined pyobject in nim?
08:59:51matkukiArrrr: https://bpaste.net/show/4b4e5e92fd68
08:59:58flyxcan you find m_init's typedef in the generated sources (TY153547)?
09:00:13matkukiflyx: lets see...
09:01:52matkukiN_NIMCALL_PTR(Pyobject150322*, ClPrc) (void* ClEnv);
09:01:53matkukivoid* ClEnv;
09:01:55matkuki} TY153547;
09:02:01*yglukhov joined #nim
09:04:40flyxhmm, try to do a sizeof on the proc type
09:05:41flyxsince PyObject's size matches, it must be either one of the three other fields in PyModuleDef_Base which doesn't match, or the compiler really does funny things
09:06:12matkukiflyx: in Nim sizeof(proc(): PyObjectPtr) == 8
09:06:18*yglukhov quit (Ping timeout: 244 seconds)
09:07:41flyxI assume you are compiling for 64 bit?
09:08:46matkukino 32
09:09:05matkukimingw on windows
09:09:08flyxthen there's your culprit
09:09:20flyxhave you tried adding {.cdecl.} to the proc type?
09:09:22*Trustable joined #nim
09:09:24*irrequietus joined #nim
09:10:20matkukiflyx: which proc?
09:10:24flyxm_init
09:10:35flyxtry: m_init*: proc (): PyObjectPtr {.cdecl.}
09:11:06matkukigood catch, lets try...
09:11:53matkukiflyx: i love you, that's it!!!!
09:12:05flyx\o/
09:12:18matkukihurray indeed!
09:12:53ArrrrHeh, congratz
09:13:02*BitPuffin|osx quit (Ping timeout: 244 seconds)
09:15:34matkukiflyx, Arrr:that's really a huge relief! i was already compiling python from source in visual studio and copying the dll into the Nim dir, thank god we found it before i had to go debugging in visual studio
09:15:37Varriountflyx: cstrings aren't garbage collected, but the strings they point to might be.
09:15:40*PMunch quit (Ping timeout: 268 seconds)
09:16:14VarriountA cstring is essentially a ptr char (or a ptr array[char, 9999])
09:17:04flyxmatkuki: debugging is not really a feasible option for finding this kind of errror
09:17:34*sarlalia1 joined #nim
09:17:44matkukiyes i know, but i thought maybe it would give me some more info on the problem. THANKS GOODNESS!
09:18:18*sarlalia1 quit (Client Quit)
09:19:26*zepolen joined #nim
09:19:29ArrrrSilly cdecl, i had a similar problem in the past too.
09:21:06Varriountmatkuki: So what was the root of the problem?
09:21:27matkukiVarriount: missing {.cdecl.}
09:21:58matkuki'm_init*: proc(): PyObjectPtr' should have been 'm_init*: proc(): PyObjectPtr {.cdecl.}'
09:22:23VarriountHuh. How did that affect structure layout though?
09:22:52VarriountUnless you were calling the proc, and that was where the problem was?
09:24:03matkukiVarriount: Yes, the proc is called in python's C code for initialization.
09:24:14Varriountmatkuki: Ah.
09:24:43VarriountIt would be nice if we could get the C compiler to throw errors about the invalid casts. Ah well.
09:25:38*irrequietus quit ()
09:27:30*yglukhov joined #nim
09:28:09*PMunch joined #nim
09:31:30ArrrrNow, could anyone run this file and test if the error persists or it is just me? http://pastebin.com/y7tLrGyd
09:33:25matkukiArrrr: I get:
09:33:27matkukiINSERT MANY
09:33:28matkukiThis would not happen generating garbage inside this iterator, Try appending 'let rrr = $regionIndex'
09:34:01VarriountI get INSERT MANY both before and after the modification
09:34:06VarriountNothing else.
09:34:11Arrrrwut
09:34:27ArrrrIm on windows xp
09:34:38matkukiI'm on windows vista
09:34:41matkuki64
09:34:47VarriountWindows 10, x64
09:34:49matkukimingw gcc
09:34:54VarriountMingw-w64
09:35:07Arrrri also use mingw-w64
09:35:20VarriountLet me update my Nim compiler
09:35:25*PMunch quit (Ping timeout: 248 seconds)
09:35:35ArrrrDo you get any error with the modification matkuki ?
09:35:56matkukiArrrr: What modification?
09:36:30ArrrrAdding let rrr = $regionIndex inside the iterator where the exception occurs
09:37:31matkukiArrrr: Yes, the exception goes away.
09:38:04ArrrrI was mad, trying to debug with echo when suddenly the error was displaced to other proc
09:40:21*irrequietus joined #nim
09:40:41VarriountArrrr: I get 'INSERT MANY' for both variations, neither produces an error.
09:41:15VarriountLatest Nim compiler, produced with standard -d:release flags and -flto flags to gcc
09:41:55ArrrrDont use release
09:42:11VarriountNo, I mean, the compiler was produced under release mode, not the test executable.
09:42:16ArrrrI have tried it now and i have 0 problem
09:42:31*vendethiel joined #nim
09:42:39ArrrrAh, ok ok. I tried compiling the test with release a there were no issues
09:43:07ArrrrWell, i dont know why is the problem. But the test is there for everyone.
09:43:10ArrrrIm not using unsafe stuff
09:43:46VarriountPerhaps we should compare executables?
09:44:00VarriountI can send you the objdump -d output
09:45:37matkukiArrrr: I'm on a windows vista 64-bit, but using mingw 32-bit, if that helps?
09:45:55ArrrrI won't get anything out of it. If you are interested in debugging my executable, i have no problems with that.
09:46:03ArrrrMaybe, i use 32-bit too
09:46:13VarriountLet me try with 32 bit then
09:46:13*M-max joined #nim
09:46:21Varriount(I have both on my system)
09:47:35matkukiBtw, anyone using the current official python wrapper? It has the old T and P type declarations, would anyone be inconvenienced if I updated this to the Type and TypePtr declarations?
09:48:01Varriountmatkuki: The only major package I can think of that uses the Python wrapper is NimBorg
09:48:11matkukiwho made it?
09:48:23VarriountCan't remember offhand. It's on Github
09:49:41matkukiGot it. It would probably be better to post the suggested change on the forum and let people chime in.
09:52:40*PMunch joined #nim
09:53:03Varriountmatkuki: You know that there's the `deprecated` pragma, right?
09:53:42matkukiVarriount: Right, thanks for reminding me! That solves it then.
09:54:38matkukiNim has a lot of features, I only remember the ones I use daily.
09:55:00*zepolen quit (Remote host closed the connection)
09:56:16VarriountThe Nim compiler is one of the few applications on my system with only one thread. :|
09:56:52VarriountNot that I think there would be much improvement over using more than one thread. Compilation is mostly a serial process.
10:01:07*bozaloshtsh quit (Ping timeout: 248 seconds)
10:02:47VarriountArrrr: I see that you're using the 'math' module.
10:02:58ArrrrYes
10:03:20VarriountArrrr: That module is pretty much a thin wrapper around the standard C math functions. Could one of them be improperly wrapped?
10:03:20ArrrrBut only for random, i think
10:04:25Arrrrmmm, i dont know why but i feel it is more related to iterators. For some reason it is telling me the seq is of len 0 when actually it is not
10:04:59ArrrrLike, suddenly, is empty.
10:05:25VarriountArrrr: Ok, so it happens on 32 bit, not 64 bit
10:05:43ArrrrDoes it happened to your 32b too ?
10:05:44*vendethiel quit (Ping timeout: 244 seconds)
10:05:49VarriountYes.
10:06:19VarriountArrrr: I use 64-bit Nim & GCC by default.
10:06:21ArrrrFine, then im not crazy
10:06:25*bozaloshtsh joined #nim
10:06:34VarriountWhen I switched to my 32-bit setup, I got the error.
10:06:46VarriountI'll compare the binaries and do some digging.
10:07:20ArrrrGreat, thank you for your time. Probably it would affect others aswell
10:07:50VarriountArrrr: I've only recently learned the joys of objdump. It's fun poking into binaries
10:08:31ArrrrWell ... the fun is in the eyes of the beholder i guess
10:11:49*gokr joined #nim
10:19:16*yglukhov quit (Remote host closed the connection)
10:23:11VarriountArrrr: Well, there's no big difference in the generated C code.
10:23:29*zepolen joined #nim
10:23:56VarriountAs for the generated assembly... well, lets just say that GCC takes full advantage of the extended x64 instruction set
10:24:54*M-max quit (Quit: node-irc says goodbye)
10:25:03ArrrrMaybe is a bug in mingw gcc 32b
10:25:43VarriountPossibly...
10:26:15VarriountArrrr: What exactly causes the exception? Have you gone through the program with GDB to see when the exceptional condition happens?
10:27:49ArrrrNop, the only error i got was from nim: Error: unhandled exception: index out of bounds [IndexError]
10:29:26*M-Quora joined #nim
10:30:06*M-Quora quit (Quit: node-irc says goodbye)
10:39:42*BitPuffin joined #nim
10:40:47*zepolen quit (Remote host closed the connection)
10:42:24*vendethiel joined #nim
10:46:58*irrequietus quit ()
10:47:00*zepolen joined #nim
10:47:10*irrequietus joined #nim
10:48:18*darkf quit (Quit: Leaving)
10:56:36*Demon_Fox quit (Quit: Leaving)
10:58:24*zepolen quit (Remote host closed the connection)
10:59:29*zepolen joined #nim
11:02:42*PMunch quit (Ping timeout: 246 seconds)
11:05:08*vendethiel quit (Ping timeout: 244 seconds)
11:19:43*yglukhov joined #nim
11:22:20*irrequietus quit (Read error: Connection reset by peer)
11:23:58*silven quit (Ping timeout: 250 seconds)
11:24:19*yglukhov quit (Ping timeout: 248 seconds)
11:34:13*irrequietus joined #nim
11:37:34*bjz_ joined #nim
11:38:14*bjz quit (Ping timeout: 244 seconds)
11:43:09*bjz_ quit (Ping timeout: 276 seconds)
11:50:01matkukisee ya, guys
11:50:03matkukithanks again flyx!
11:50:11*matkuki quit (Quit: ChatZilla 0.9.92 [Firefox 44.0.2/20160210153822])
12:14:34arnetheduckthe posix module in nim, does it target any specific posix release?
12:21:15federico3no arnetheduck
12:21:32arnetheduckok. I
12:22:22arnetheduck'm looking at stat, which on most systems provides nanosecond timestamps (since posix 2008 afair)
12:22:36*yglukhov joined #nim
12:23:35arnetheduckposix.nim however uses the old names and sizes for those.. in C this is solved by a macro trick, so the old names continue to work
12:24:41arnetheduckwhat would a good way for nim be? In c, it changed from a time_t field to a struct timespec, which starts with a time_t.. then the old name is #defined to access the struct field
12:26:11*endragor joined #nim
12:28:06federico3arnetheduck: unfortunately the module is unaware of the kernel type and version it's building against in order to enable features accordingly
12:29:38cheatfatearnetheduck, what are you talking about?
12:30:45arnetheduckcheatfate, st_{a,c,m}time which nowadays are called st_Xtim (or st_Xtimespec on osx, I think)
12:31:26cheatfateand i see in posix.nim its defined like Time object
12:32:27arnetheduckcheatfate, yeah, that's what they used to be, in posix versions < 2008
12:33:32arnetheduckso posix.nim defines an old name and offers second granularity, while posix has evolved to use ns granularity..
12:34:28arnetheduckTime = time_t in c, which is arch dependent but typically 64 bits these days
12:36:24arnetheduckthis spills over to os.nim, where getLastModificationTime and friends are limited to seconds as well
12:39:36*irrequietus quit ()
12:41:06cheatfatehmm looks like a serious bug, but i dont know mechanism of include pragmas, so if they using real defined c structures not this one than it maybe only value bug, but if nim redefines structures which are describer in posix.nim than it can be stack/heap overflow
12:42:11cheatfateand yeah all posix/ staff and winlean.nim needs to be replaced they are very inaccurate
12:48:20arnetheduckcheatfate, well, it's not a bug (it works, because of said #define trick in sys/stat.h), but it's.. incomplete
12:49:14arnetheduckand it causes issues for nlvm becuase the offsets of the struct members are wrong, and nlvm cannot parse c headers to get it right, but that's less relevant for upstream
12:52:06reactormonkcheatfate, feel free to hack
12:53:40*yglukhov quit (Ping timeout: 244 seconds)
12:53:58arnetheduckone way would be to use the new name, and provide a getter with the old name.. dunno how well nim handles function-calls-without-params though
12:54:30arnetheduckbut that would break on old systems, of course
13:10:25cheatfatereactormonk, yeah i know, but there problems... its like cint|SocketHandle|AsyncFD|AsyncFd
13:11:06cheatfatesome of maintainers must take a decision how it must be done
13:12:06reactormonkcheatfate, maybe forum post on your opinion?
13:12:10cheatfatebecasue epoll.nim staff is made to work only with asyncdispatch.nim... if you want to use it in other way you need to make your own epoll.nim
13:13:38cheatfatemaybe not me, i'm just starting with Nim and trying to adopt it for my reasons, there many things which i dont like, but much more things that i like... But if i put something like that on forum it takes maintainer's time to do something with this
13:14:33cheatfateand i think they have something else to do... so i think they must move forward and dont watch on old mistakes...
13:18:40cheatfatebut yeah standart library needs some standartization imho :)
13:19:03*zepolen quit (Remote host closed the connection)
13:19:28*exebook quit (Ping timeout: 252 seconds)
13:20:29*zepolen joined #nim
13:28:02*yglukhov joined #nim
13:31:16*yglukhov quit (Remote host closed the connection)
13:32:10reactormonkcheatfate, sure, but that's gonna be some serious work. Feel free to ask on the forum what's been done in that direction. Or wait for Araq.
13:32:24*zepolen quit (Remote host closed the connection)
13:32:36reactormonkAlthough dom96 has done a lot of work on the stdlib lately.
13:33:11*yglukhov joined #nim
13:33:51*exebook joined #nim
13:37:16cheatfatereactormonk, i like dom96's work, he made incredible work on standart library, but everybody pursue different goals... i think dom96 wanted to make standart library as rich as possible. and he made it
13:37:17*zepolen joined #nim
13:37:29*zepolen quit (Remote host closed the connection)
13:38:47cheatfatebut my goal is to have reliable, secure and of course fast library
13:39:39cheatfatemaybe "fast" is not enough, i want "the fastest"
13:40:42cheatfateyou know async technology is what made web faster and with nim we can make it "the fastest"
13:41:05cheatfatebut currently async staff is slow and not reliable for production use
13:41:13cheatfateso i'm working on it right now
13:41:23federico3async does not make code "faster", it makes it async ;)
13:41:50cheatfatei dont say any words about "code"
13:43:14cheatfateasync staff made possible to solve c10k problem
13:45:21*yglukhov quit (Read error: Connection reset by peer)
13:45:37*yglukhov joined #nim
13:51:02*yglukhov quit (Ping timeout: 244 seconds)
13:53:33*beatmox quit (Quit: ...)
13:54:05*zepolen joined #nim
14:06:47*yglukhov joined #nim
14:07:16*zepolen quit (Remote host closed the connection)
14:21:02*yglukhov quit (Remote host closed the connection)
14:53:11*exebook quit (Read error: Connection reset by peer)
15:02:11*zepolen joined #nim
15:14:35*exebook joined #nim
15:39:57*pregressive joined #nim
15:50:53*Jesin quit (Quit: Leaving)
15:53:13*Jesin joined #nim
15:59:01*pregressive quit (Remote host closed the connection)
16:09:00*arnetheduck quit (Ping timeout: 276 seconds)
16:12:33*samdoran joined #nim
16:15:31*yglukhov joined #nim
16:20:56*pregressive joined #nim
16:21:01*yglukhov quit (Remote host closed the connection)
16:23:55*arnetheduck joined #nim
16:29:38*arnetheduck quit (Ping timeout: 244 seconds)
16:31:22*sorakun joined #nim
16:40:20*yglukhov joined #nim
16:41:53*yglukhov quit (Remote host closed the connection)
16:54:15*darkf joined #nim
16:56:35*yglukhov joined #nim
17:02:29*yglukhov quit (Remote host closed the connection)
17:16:03*exebook quit (Quit: Leaving)
17:16:15*exebook joined #nim
17:22:27*PMunch joined #nim
17:34:03*jaco60 joined #nim
17:44:47*endragor quit (Remote host closed the connection)
17:53:49*brson joined #nim
17:59:41*yglukhov joined #nim
18:03:02*samdoran quit (Ping timeout: 260 seconds)
18:22:32*endragor joined #nim
18:33:33*vendethiel joined #nim
18:37:00*sora joined #nim
18:37:15*sorakun quit (Ping timeout: 244 seconds)
18:44:33*aziz joined #nim
18:51:07*PMunch quit (Ping timeout: 252 seconds)
19:00:41*endragor quit (Remote host closed the connection)
19:20:33*BitPuffin quit (Read error: Connection reset by peer)
19:28:09*boopsiesisaway is now known as boopsies
19:28:17*boopsies is now known as boopsiesisaway
19:28:24*boopsiesisaway is now known as boopsies
19:28:27*boopsies is now known as boopsiesisaway
19:28:39*boopsiesisaway is now known as boopsies
19:29:31*alexsystemf joined #nim
19:45:03*brson quit (Ping timeout: 240 seconds)
19:47:12*brson joined #nim
19:50:58cheatfateAraq, so i couldn't use {.packed.} objects to store in GC memory?
19:51:13Araqpity.
19:53:13cheatfateso i need to make workaround or it will be resolved in near future?
19:58:05AraqI wouldn't use .packed to begin with. I usually group object fields by hand to minimize memory requirements
19:58:34Araqadvantage: It can never fuck up alignments.
19:59:18Araqyou can use .packed for objects that don't contain GC'ed pointers though.
19:59:36Araqand you can also split your object into 2 parts, one packed, the other not.
20:01:25*yglukhov_ joined #nim
20:01:25*yglukhov quit (Read error: Connection reset by peer)
20:01:34cheatfatewait a moment i will create gist
20:03:03*nkr left #nim ("Leaving...")
20:03:03*yglukhov_ quit (Read error: Connection reset by peer)
20:04:18cheatfatehttps://gist.github.com/cheatfate/d1b9325ba7229d1bb4c3
20:04:40cheatfatei want to use uint64_t union type
20:05:02cheatfatebut in c sizeof(struct epoll_event) = 12 because of packing
20:05:30cheatfateand i want to use uint64_t to store pointer to GC'ed memory :)
20:06:36*yglukhov joined #nim
20:07:04cheatfateso events:uint32_t member of struct epoll_event is only 4 bytes...
20:07:57Araqsounds like epoll is garbage.
20:08:16cheatfateour nim's epoll or linux's epoll?
20:09:38cheatfateepoll.nim is working now in nim only because dom96 is using it to store 32bits descriptors...
20:10:36Araqlinux's epoll.
20:10:59Araqif you have an array of packed objects like that, your pointers are not aligned.
20:11:15Araqthat's bullshit design right here.
20:12:21Araqyou can store the pointer anyway and do GC_ref / GC_unref pairs
20:12:33Araqwhich is what you likely need to do anyway, I think.
20:12:38cheatfateyep
20:12:42cheatfatei will do it
20:22:08*yglukhov quit (Remote host closed the connection)
20:25:09*brson quit (Ping timeout: 246 seconds)
20:28:38*yglukhov joined #nim
20:42:26*Arrrr quit (Quit: WeeChat 1.4)
20:43:14*brson joined #nim
20:57:31*Jesin quit (Quit: Leaving)
21:01:32*irrequietus joined #nim
21:08:16*PMunch joined #nim
21:12:26*yglukhov_ joined #nim
21:12:26*yglukhov quit (Read error: Connection reset by peer)
21:14:43*yglukhov_ quit (Read error: Connection reset by peer)
21:17:38*yglukhov joined #nim
21:20:25*yglukhov quit (Read error: Connection reset by peer)
21:24:34*sora quit (Remote host closed the connection)
21:27:39*PMunch quit (Ping timeout: 268 seconds)
21:27:40*yglukhov joined #nim
21:34:25*irrequietus quit (Read error: Connection reset by peer)
21:34:39*irrequietus joined #nim
21:38:39*samdoran joined #nim
21:42:29*yglukhov_ joined #nim
21:42:29*yglukhov quit (Read error: Connection reset by peer)
21:44:27*samdoran quit (Quit: Leaving)
21:44:27*yglukhov_ quit (Read error: Connection reset by peer)
21:47:31*yglukhov joined #nim
21:51:48*zepolen quit (Remote host closed the connection)
21:52:56*zepolen joined #nim
21:55:15*toaoMgeorge joined #nim
22:01:38*yglukhov_ joined #nim
22:01:39*yglukhov quit (Read error: Connection reset by peer)
22:11:14*cheatfate_ joined #nim
22:11:14*cheatfate quit (Read error: Connection reset by peer)
22:12:56*cheatfate__ joined #nim
22:12:56*cheatfate_ quit (Read error: Connection reset by peer)
22:14:40*cheatfate__ is now known as cheatfate
22:15:04*Matthias247 joined #nim
22:16:53*pregressive quit ()
22:36:51*yglukhov_ quit (Read error: Connection reset by peer)
22:37:25*yglukhov joined #nim
22:46:45*lcm337 joined #nim
23:00:15*vendethiel quit (Ping timeout: 244 seconds)
23:09:10*irrequietus quit ()
23:10:36*toaoMgeorge quit (Quit: Bye)
23:14:07*jaco60 quit (Read error: Connection reset by peer)
23:14:35*jaco60 joined #nim
23:15:57*vendethiel joined #nim
23:19:14*aziz quit (Remote host closed the connection)
23:22:09*yglukhov quit (Remote host closed the connection)
23:31:37*mahasamoot quit (Ping timeout: 240 seconds)
23:37:13*Demon_Fox joined #nim
23:37:39*vendethiel quit (Ping timeout: 264 seconds)
23:46:47*Matthias247 quit (Read error: Connection reset by peer)
23:55:08*vendethiel joined #nim
23:58:15*jaco60 quit (Quit: Leaving)
23:58:38*jaco60 joined #nim