00:43:00 | * | disruptek quit (Ping timeout: 265 seconds) |
01:03:18 | * | lritter quit (Ping timeout: 265 seconds) |
01:05:07 | * | disruptek joined #nim |
01:20:18 | * | exelotl quit (Ping timeout: 245 seconds) |
01:46:02 | * | endragor joined #nim |
02:15:57 | * | cgfuh quit (Quit: WeeChat 2.5) |
03:13:51 | * | snooptek joined #nim |
03:22:23 | * | chemist69 quit (Ping timeout: 245 seconds) |
03:24:36 | * | chemist69 joined #nim |
03:39:17 | * | gangstacat quit (Quit: Ĝis!) |
03:54:59 | * | gangstacat joined #nim |
03:56:52 | * | dddddd quit (Remote host closed the connection) |
04:03:37 | FromGitter | <gogolxdong> Do we have a opencv works with latest 4.1.1 version? |
04:35:24 | * | Perkol joined #nim |
04:41:17 | * | nsf joined #nim |
04:48:51 | * | Perkol quit (Remote host closed the connection) |
05:08:26 | * | narimiran joined #nim |
05:33:15 | * | laaron quit (Remote host closed the connection) |
05:39:32 | * | fjellfras joined #nim |
06:08:01 | * | absolutejam joined #nim |
06:12:45 | * | Skaruts joined #nim |
06:13:49 | Skaruts | hey guys, I'm having trouble installing choosenim 0.4 |
06:14:16 | * | laaron joined #nim |
06:15:00 | Skaruts | 0.3 installed fine, 0.4 hangs when extracting the latest nim archive |
06:15:58 | Skaruts | also the .exe on the downloads for 0.4 isn't an installer or self extracting archive, like the one from 0.3 |
06:16:33 | Skaruts | when I run it I get a list of commands in the console |
06:16:37 | Skaruts | nothing else |
06:17:40 | * | PMunch joined #nim |
06:18:17 | Skaruts | So for now I'm using choosenim 0.3, but should I worry that it might cause problems? |
06:19:42 | Skaruts | Also I'm having this issue compiling with nim 0.20.2: https://github.com/nim-lang/Nim/issues/11349 |
06:19:58 | Skaruts | (error: size of array ‘Nim_and_C_compiler_disagree_on_target_architecture’ is negative) |
06:20:11 | Skaruts | on a hello world file |
06:24:07 | shashlick | Hello @Skaruts |
06:24:12 | shashlick | Are you on windows |
06:25:06 | shashlick | Probably running into https://github.com/dom96/choosenim/issues/124 |
06:26:27 | Skaruts | yup that's the issue, and yes I'm on windows |
06:27:42 | Skaruts | windows 7 |
06:29:39 | shashlick | Ya I aim to fix that - https://github.com/dom96/choosenim/issues/129#issuecomment-530992405 |
06:29:47 | shashlick | But it is taking time |
06:29:57 | shashlick | Using 0.3 should not cause any issues |
06:30:09 | * | absolutejam quit (Ping timeout: 246 seconds) |
06:30:38 | Skaruts | seems like there's a problem with my nimble though |
06:30:52 | Skaruts | could not load: (libcrypto-1_1-x64|libeay64).dll |
06:31:34 | shashlick | You need to download the dlls zip |
06:31:34 | Skaruts | I'm gonna try an reinstall everything clean from scratch. |
06:31:38 | Skaruts | What's the procedure to uninstall everything? |
06:31:43 | shashlick | And put it in your path |
06:31:48 | Skaruts | to make sure nothing is left |
06:32:12 | shashlick | No need to uninstall |
06:32:39 | shashlick | https://nim-lang.org/install_windows.html for the dll zip |
06:32:57 | shashlick | Put the contents on your nimble bin |
06:35:09 | Skaruts | isn't that for nim, rather than nimble? |
06:35:24 | Skaruts | or it affects nimble too? |
06:35:34 | shashlick | Same thing |
06:36:22 | shashlick | Nimble needs ssl to download |
06:36:34 | Skaruts | ah now it works |
06:37:05 | Skaruts | still getting that compile error with nim though :\ |
06:37:53 | shashlick | Might be fixed in devel |
06:39:17 | Skaruts | hmm, why didn't I think of that.. gonna try the latest |
06:39:46 | Skaruts | thanks a lot btw |
06:40:49 | * | fjellfras quit (Quit: Leaving) |
06:41:58 | * | owl_000 joined #nim |
06:47:42 | Skaruts | getting an error using choosenim now: "couldn't find entry point for procedure __printf__ in DLL libintl-8.dll" |
06:47:52 | Skaruts | (I'm translating that to english from my language) |
06:48:41 | Skaruts | it still tries to install. I'm now trying to install the latest (#head) but it failed installing 0.19.4 |
06:49:12 | Skaruts | specificall, failed building iirc |
06:50:55 | * | solitudesf joined #nim |
06:54:41 | * | krux02 joined #nim |
06:55:09 | * | ng0 joined #nim |
06:56:50 | Skaruts | latest failed too... |
06:59:57 | nc-x[m] | error: size of array ‘Nim_and_C_compiler_disagree_on_target_architecture’ is negative |
07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
07:00:17 | nc-x[m] | this error means u are using 64 bit nim with 32 bit c compiler or vice versa |
07:01:09 | nc-x[m] | apart from that never tried using choosenim so no idea |
07:01:51 | nc-x[m] | installing nim from github or from the downloads page on nim website is pretty easy though |
07:01:59 | nc-x[m] | esp. on windows |
07:02:36 | nc-x[m] | for updating u can simply download latest zip, delete previously extracted files, and use the newer ones instead |
07:04:08 | Skaruts | I've no idea where my C compiler even is at this point lol |
07:04:23 | * | gmpreussner joined #nim |
07:04:59 | Skaruts | that could be the case though |
07:08:42 | * | absolutejam joined #nim |
07:25:39 | FromGitter | <danielecook> @Vindaar wow that worked! Thanks so much! |
07:25:42 | * | actuallybatman quit (Quit: leaving) |
07:26:19 | * | joshbaptiste quit (Ping timeout: 246 seconds) |
07:27:48 | * | chemist69 quit (Ping timeout: 245 seconds) |
07:28:01 | Zevv | Goooood morning #nim |
07:28:40 | PMunch | Haha, good morning Zevv, nice reference |
07:29:19 | Zevv | How is PMunch today? |
07:29:49 | * | chemist69 joined #nim |
07:30:17 | FromGitter | <Vindaar> Good morning :) ⏎ @danielecook Glad to help! I feel like I'm becoming the "help people with the json module" guy :D |
07:30:28 | PMunch | Good good, bit tired after having gone to a quiz yesterday |
07:30:46 | Zevv | I'm severely procrastinating. I have the choice between politics or async networking in C++ today. If my third choice was taking a stapler to my forehead, I knew which one to choose. |
07:30:51 | Zevv | Ah what kind of quiz was that? |
07:31:20 | PMunch | Just a general quiz at the local students house |
07:31:45 | PMunch | We're a group that goes every week, but it's mostly as an excuse to get together and drink beer :P |
07:31:48 | Zevv | ah, the late-night-acohol-infused kind of quiz |
07:31:55 | Zevv | those are the best |
07:31:56 | PMunch | That's the one |
07:32:14 | PMunch | Started at 7PM, think I was home at around 12 |
07:32:21 | PMunch | Or maybe it got closer to 1AM |
07:32:42 | Zevv | pussy |
07:33:13 | Zevv | student, getting home at 1AM and then complaining about being tired. When *I* was young...! |
07:33:39 | PMunch | Haha, I do this every week though, can't be completely broken every wednesday |
07:34:01 | PMunch | Well I'm not actually a student any longer either, haven't been for close to two years now :P |
07:35:04 | Zevv | Same with me with band practice and playing until pretty late; I play under a different name so my customers don't find any news of my gigs and then complain about me sitting behind my screen dazed next morning :) |
07:37:44 | * | chemist69 quit (Ping timeout: 276 seconds) |
07:38:21 | owl_000 | i am doing some image processing work, in my laptop it has 4 core, how to use all core usin nim. what should i read now. |
07:38:49 | Zevv | owl_000: nim doesn't have a good threading story at this time. There is threadpools and channels, start with that |
07:39:14 | narimiran | Zevv: what instrument do you play? |
07:39:32 | Zevv | narimiran: bass guitar/synth |
07:39:37 | narimiran | i knew it!!! |
07:39:50 | narimiran | (about bass guitar, not about synth) |
07:39:58 | Zevv | that's also bass synth :) |
07:40:07 | Zevv | so, do I fit your bass profile? |
07:40:47 | narimiran | i used to play bass when i was in highschool or so, but i stopped after i realized that buying expensive equipment will not solve my tone-deafness :) |
07:41:26 | narimiran | and yes, bass-playing fits my "weirdos use nim" profile |
07:42:12 | Zevv | haha :) |
07:42:35 | FromGitter | <Vindaar> @owl_000 since you're around. You asked me on that nimpy issue about a library for PIL interaction from nim with nimpy. I don't quite understand what you think such a library should do in the first place? |
07:42:49 | Zevv | Yeah, when you realize you're suffering GAS it's better to do some introspection and change your path |
07:43:40 | narimiran | haha, i haven't heard about GAS for a veeery long time :) thanks for reminding me about it, i'll re-start to use it even for some non-music stuff |
07:44:23 | narimiran | but now the obvious - let us hear about your equipment! |
07:46:55 | Zevv | http://zevv.nl/div/bass.jpg :) |
07:47:33 | owl_000 | vindaar < pil support lot of file type. but accessing pixel is too slow. so your library can act as easy way to transfer data to nim. rich filetype handling of PIL and fastest pixel handling in nim. |
07:48:05 | owl_000 | zevv cool |
07:51:02 | * | chemist69 joined #nim |
07:51:57 | narimiran | PJB, noice! are both cabinets the same? what amp do you use? and is that some ibanez or yamaha? (sorry, my eye for bass equipment details is long gone) |
07:52:37 | PMunch | Zevv, haha that is brilliant :P |
07:53:13 | PMunch | owl_000, I'm actually writing an article series on multitasking in Nim as we speak |
07:53:47 | Zevv | narimiran: top is a combo, bottom is a cab. bass is yamaha indeed |
07:53:49 | PMunch | Currently got the introduction article, and I'd say 70-80% of the asynchronous article done. Threading article is next |
07:53:52 | Zevv | PMunch: any drafts on that yet? |
07:53:58 | owl_000 | brilliant guru Pmunch |
07:54:36 | narimiran | i still have my trusty old yamaha trb-4 :) |
07:55:27 | narimiran | it looks like this: https://images.reverb.com/image/upload/s--nNzJtaZi--/f_auto,t_large/v1556503029/vltt7yfekhgnyq2p9ci6.jpg , but it has EMG pickups and electronics |
07:55:39 | * | alexander92 joined #nim |
07:55:55 | PMunch | Zevv, I can share with you what I got currently if you want to give it a read :) But so far it hasn't gone through any revisions, just been written from top to bottom |
07:56:27 | Zevv | PMunch: sure |
07:56:35 | FromGitter | <Vindaar> owl_000: the thing is: if you want fast access to the data with PIL in Python you get the image data in form of a numpy array, do the work on that (which will be fast, if you can express it in a few numpy functions on the array as a whole) and hand the result back to PIL. Basically what I did in the example except calling numpy functinos |
07:58:50 | FromGitter | <Vindaar> it's always fun to write wrappers (and do everything in Nim) etc. but since you have to work on the numpy data in the first place, I'm not sure what the advantage really is here. |
07:59:38 | * | actuallybatman joined #nim |
08:00:38 | * | Vladar joined #nim |
08:00:42 | FromGitter | <Vindaar> If what you want really is a convenient way to do numpy like stuff in Nim on the PIL data, I'd wrap the numpy data buffer in an arraymancer tensor and use that instead of implementing everything again |
08:00:56 | owl_000 | yeah i know, actually whatever i did in python i am doing in nim, in the process i am learning nim. i used nimPng (awsome package) to do all of the stuff. but it is limited to png file. |
08:01:08 | FromGitter | <mratsim> You can't at the moment you have to copy the buffer |
08:01:27 | FromGitter | <Vindaar> ah, ok. I thought there was a way and I simply forgot how to do that :) |
08:01:32 | FromGitter | <mratsim> Use OpenCV, iirc there is a Nim wrapper |
08:01:48 | * | lkw quit (Read error: Connection reset by peer) |
08:01:49 | FromGitter | <Vindaar> What stops us from adding that to arraymancer? |
08:01:54 | FromGitter | <mratsim> Maybe ask @SolitudeSF if image man is ready |
08:02:03 | * | lkw joined #nim |
08:02:13 | FromGitter | <mratsim> It's planned but for the laser refactoring |
08:02:34 | FromGitter | <mratsim> I didn't want to break people's buffer assumption and library use twice |
08:03:09 | FromGitter | <Vindaar> ok, I see |
08:04:53 | FromGitter | <mratsim> https://github.com/SolitudeSF/imageman |
08:05:13 | FromGitter | <mratsim> Using 4 cores on a single image is tricky, it depends on the algorithm |
08:07:42 | owl_000 | extract certain pixel pattern from image. four loop in four core, four region of the image |
08:08:23 | PMunch | What if the pixel pattern overlaps the regions? |
08:09:20 | PMunch | I guess you could scale the regions so that there is some overlap, would lead to a bit more total work, but might still run faster since it's multithreaded |
08:11:04 | owl_000 | let say region is known 20x20, then it can be identified |
08:12:07 | PMunch | dom96, you around? Tried to turn on "futureLogging" from asyncdispatch and it shows a lot of "empty" things in the list, what's up with that? |
08:12:09 | FromGitter | <zacharycarter> PMunch: what do you plan to talk about in your article about threading? |
08:13:55 | FromGitter | <mratsim> I can help analyze the algo complexity @owl_000 but if you want to check if an image contains a pattern you might want to use convolutional neural networks |
08:14:01 | PMunch | Basically what threading is, how it compares to async, how it works in Nim with the GC |
08:14:03 | PMunch | Pretty much |
08:14:43 | PMunch | Then I have one planned for "Communication" as well, which is more about how to communicate between the threads. But I might join those two, depends on how long they become |
08:21:53 | FromGitter | <zacharycarter> excited to read this |
08:22:15 | FromGitter | <Vindaar> @owl_000 do you have some code of what you want to do? I mean the old code that is simply too slow. Maybe we can help you make that fast for a start |
08:33:21 | owl_000 | it is not that important. my problem is, lot of questions appear in my mind, like bubble appear from a cola. i found nimPNG two days ago and find out i can access pixel by pixel. lot of things can be done, then i make a program to redscale or given rgbvalue scale (not grayscale). |
08:34:48 | owl_000 | then i figure out i can extract all the image pixel by group, one file will contain only (0,179,67) pixel, another one other value. |
08:34:54 | owl_000 | unnecessary work. |
08:35:26 | owl_000 | i don't do any work, i have plenty of time for wasting lol |
08:40:18 | * | absolutejam quit (Ping timeout: 268 seconds) |
08:42:12 | owl_000 | and i am sorry for bothering you guys for silly matter. |
08:42:40 | FromGitter | <Vindaar> don't be sorry. It's just not easy to help you if you are vague :) |
08:42:46 | * | actuallybatman quit (Ping timeout: 268 seconds) |
08:45:57 | * | nif quit (Quit: ...) |
08:46:06 | * | nif joined #nim |
08:49:18 | * | nif quit (Client Quit) |
08:49:30 | * | nif_ joined #nim |
09:00:21 | * | absolutejam joined #nim |
09:20:16 | * | okcy joined #nim |
09:21:10 | okcy | I'm downloading nim for windows :-) |
09:21:21 | okcy | Hah |
09:21:24 | Araq | okay |
09:21:45 | okcy | Hi |
09:25:51 | * | absolutejam quit (Ping timeout: 246 seconds) |
09:29:06 | Araq | "lib$1.so" is this correct for iOS? |
09:29:12 | Araq | shouldn't it be dylib? |
09:33:08 | FromGitter | <gogolxdong> I'm afraind opencv dll names have been changed in latest version, don't have a clue of their corresponding relationship. |
09:34:10 | FromGitter | <zacharycarter> Araq: yes I believe so - dylib is osx / iOS so is linux |
09:41:18 | FromGitter | <mratsim> .so is also macOSX |
09:41:32 | FromGitter | <mratsim> you need to check both |
09:44:19 | Araq | what iOS is Linux based? |
09:44:38 | FromGitter | <mratsim> nop. .so is unix |
09:45:26 | Araq | yeah but so is osx and osx uses dylib |
09:45:39 | FromGitter | <mratsim> OSX also uses .so |
09:46:37 | FromGitter | <mratsim> it’s just convention |
09:46:42 | FromGitter | <mratsim> and some don’t respect it |
09:49:06 | Araq | but what does iOS use? |
09:49:14 | Araq | "officially", I mean |
09:50:57 | * | laaron quit (Remote host closed the connection) |
09:51:06 | Calinou | iOS doesn't have dynamic linking |
09:52:26 | * | laaron joined #nim |
09:56:30 | * | absolutejam joined #nim |
10:04:58 | Araq | nice :-) |
10:06:01 | FromGitter | <gogolxdong> Which is better to build a live streaming system, opencv or ffmpeg? |
10:07:09 | * | Skaruts quit (Remote host closed the connection) |
10:07:35 | FromGitter | <gogolxdong> Do we have ffmpeg wrapper? |
10:23:07 | FromGitter | <danielecook> How do you clear out a sequence? |
10:23:18 | FromGitter | <danielecook> `myseq.filterIt(false)`? |
10:23:40 | Araq | myseq.setLen 0 |
10:23:45 | FromGitter | <danielecook> ah ok thanks! |
10:47:29 | lqdev[m] | how hard would it be to build a static analysis tool for Nim, similar to what IntelliJ idea has for Java? |
10:48:27 | lqdev[m] | I'm not talking about all the advanced analysis levels IntelliJ has, just how hard would it be to get started |
10:49:25 | Araq | lqdev[m], not very, I can guide you |
10:52:04 | Araq | of course, "static analysis" can mean many things |
10:52:21 | lqdev[m] | I don't plan on picking up on such a project yet, but it's a good idea nonetheless. this would drastically improve Nim's tooling quality though |
10:53:17 | Araq | lol, how so? |
10:56:06 | FromGitter | <zacharycarter> couldn't you just use an existing static analysis tool for C / C++ ? |
10:56:40 | lqdev[m] | it's annoying to optimize things myself, it would be nice to get tips like "unused variable" but more advanced |
10:56:44 | federico3 | Nim-generated C code is not too friendly |
10:57:21 | Araq | zacharycarter: but what for? |
10:59:04 | lqdev[m] | also, does a linting tool exist for Nim? I know there's nimpretty, what does it *prettify* though? I can't see any changes in my own code when I run it |
10:59:21 | Araq | lqdev[m], then your code is perfect already ;-) |
10:59:31 | lqdev[m] | I guess it makes the code NEP-1 compliant? |
10:59:43 | Araq | nah, it layouts your code |
10:59:58 | lqdev[m] | ah, OK |
11:00:20 | lqdev[m] | guess I'll have to write some terrible code for once to see it in action ;) |
11:00:34 | lqdev[m] | s/terrible/terrible-looking |
11:00:51 | federico3 | lqdev[m]: I'm trying to update my nimfmt tool to do that |
11:01:25 | lqdev[m] | federico3: right, I'll check it out |
11:01:36 | Araq | federico3, your nimfmt tool cannot deal with "a\10b" |
11:01:47 | federico3 | I haven't published the changes |
11:01:57 | federico3 | Araq: I'm rebuilding it on top of nimpretty |
11:02:03 | Araq | yay :D |
11:02:05 | FromGitter | <zacharycarter> Araq: I don't know haha, I just think it's possible ;P |
11:02:24 | federico3 | but the internals of the compiler are quite tricky... |
11:03:16 | lqdev[m] | "sort imports" huh? how would it sort them? alphabetically? |
11:03:45 | lqdev[m] | I sort my imports into 3 sections: stdlib, nimble, and own |
11:03:58 | federico3 | regarding static analysis, being able to generate code that passes coverity and other tools like https://www.absint.com/astree/index.htm could boost the language credibility |
11:04:05 | lqdev[m] | and, alphabetically according to ASCII |
11:04:43 | federico3 | lqdev[m]: that's pretty common. In 3 chunks separated by newlines perhaps? |
11:04:54 | lqdev[m] | yes |
11:05:14 | federico3 | (it's the recommended layout in python) |
11:05:17 | lqdev[m] | iirc that's what python's style guidelines suggest |
11:05:27 | lqdev[m] | that makes sense |
11:06:17 | lqdev[m] | I'm not much of a Python fan, but that rule works pretty well |
11:06:59 | lqdev[m] | anyway, bbl |
11:14:06 | * | okccyy joined #nim |
11:16:29 | alexander92 | lqdev[m] i had some ideas for a nim-linter lib which does stuff like this (similar to rupocop or the pep8 linters) |
11:17:10 | alexander92 | but not really sure how important it is: and i also saw it should be possible to generalize such tech to work on many langs |
11:17:58 | * | okcy quit (Ping timeout: 258 seconds) |
11:18:06 | alexander92 | many of those checks don't really have to do with certain lang specifics if they can just access a (typed?) ast of many langs with unified api |
11:18:16 | alexander92 | but maybe that's what those IDE-s do |
11:26:41 | FromGitter | <mratsim> @gogolxdong it's ffmpeg or OpenCV compiled with ffmpeg support |
11:27:00 | FromGitter | <mratsim> Just be aware of licensing (GPL) |
11:30:27 | * | solitudesf quit (Ping timeout: 240 seconds) |
11:31:30 | * | dddddd joined #nim |
11:32:01 | * | Vladar quit (Remote host closed the connection) |
11:39:30 | * | solitudesf joined #nim |
11:41:27 | * | Vladar joined #nim |
11:43:14 | * | okccyy quit (Quit: Leaving) |
11:44:23 | Calinou | what's the differnce between nimpretty and nimfmt? |
11:50:11 | lqdev[m] | nimpretty is the official tool |
11:50:29 | lqdev[m] | nimfmt is made by federico3 and seems to have a few more features |
11:52:21 | federico3 | it's going to turn into an extension to nimpretty |
11:54:08 | * | endragor quit (Remote host closed the connection) |
11:58:39 | * | nif_ quit (Quit: ...) |
11:58:48 | * | nif joined #nim |
12:06:50 | * | absolutejam quit (Ping timeout: 276 seconds) |
12:08:27 | * | solitudesf quit (Ping timeout: 240 seconds) |
12:11:37 | * | absolutejam joined #nim |
12:18:24 | * | fjellfras joined #nim |
12:40:49 | * | fjellfras quit (Quit: Leaving) |
12:46:37 | * | Vladar quit (Remote host closed the connection) |
12:49:44 | * | Vladar joined #nim |
12:58:32 | * | laaron quit (Remote host closed the connection) |
13:01:18 | * | laaron joined #nim |
13:05:10 | * | hoijui joined #nim |
13:09:25 | * | skelett joined #nim |
13:15:04 | FromGitter | <gogolxdong> What's the reason of being aware of GPL? |
13:16:54 | PMunch | Hmm, I've got some weird behaviour with asyncdispatch: http://ix.io/1VJT |
13:19:31 | PMunch | When delayedEcho runs after it's sleep and then sleeps for 500ms it seems like the sleep is actually 1050ms long, or the same amount of time as the sleepAsync 550 and the sleep 500 |
13:22:09 | PMunch | So it appears only when the sleep is over 50ms which should be the remaining time before the next tick should be executed |
13:22:32 | PMunch | So somehow sleeping past the tick makes it perform the sleepAsync(550) again? That seems strange.. |
13:23:33 | PMunch | Because the ticker should be the only thing running in the dispatcher after delayedEcho is done with the sleep operation |
13:23:50 | alexander92 | this ticker thing is a cool idea |
13:24:18 | disruptek | PMunch: are you on devel? |
13:24:27 | PMunch | Yes |
13:24:49 | PMunch | alexander92, yeah I thought that was a good way to visualise it |
13:25:21 | PMunch | disruptek, same behaviour on 0.20.2 |
13:25:49 | disruptek | i was just reminded of a bug with +500ms delay that was fixed in async pre-0.20. |
13:26:16 | alexander92 | PMunch, i can imagine it with echoing progress bars |
13:27:27 | PMunch | Well then you need to know what the progress is.. |
13:28:37 | PMunch | I wonder if this is only when you actually do a sleep.. |
13:30:17 | PMunch | Hmm, yeah it seems like it gets a 500ms delay |
13:30:27 | PMunch | Do you have an issue for that disruptek` |
13:30:29 | disruptek | why do you have a sync sleep in there? |
13:31:07 | disruptek | it was something i suffered with for a long time, never realizing that it wasn't a known defect. then i brought it up on irc and it got fixed immediately. oops. |
13:31:23 | PMunch | It was meant to illustrate that this is co-operative multitasking which means that if that was a long execution you would starve the other tasks and it would sleep longer than expected |
13:31:41 | disruptek | as simple as your example is, i can't figure it out running it in my head. :-( |
13:33:27 | disruptek | well, your example works to demonstrate that in a single-threaded app, a sync sleep really sleeps...? |
13:34:07 | PMunch | Yeah |
13:34:29 | disruptek | async is just a macro that changes your proc into an iterator; if you keep that in mind, it's much easier to reason about. |
13:35:14 | PMunch | The sleep sleeps the entire thread of execution, meaning that the dispatcher can't switch task to fulfil the asyncSleep in the ticker when maybe expected |
13:35:31 | disruptek | the +500ms delay was due to an i/o select, so it wouldn't come into play here. |
13:35:52 | PMunch | Yeah I know, I mention that in the article as well :) |
13:35:59 | disruptek | right; change it to an asyncSleep and it's fine. |
13:36:00 | PMunch | That it gets turned into an iterator |
13:36:11 | PMunch | Of course, but that isn't really the issue here |
13:36:33 | PMunch | If that was 60ms of actual code executing you would have the same result |
13:37:04 | disruptek | right, but if you want your timer to execute on every 100ms stroke, you're going to have to check the clock. |
13:37:05 | PMunch | (I just tried that by having a busy loop with epochTime) |
13:37:45 | disruptek | what color is your function... |
13:38:21 | PMunch | Yes, and that is what I want to show. That since asyncdispatch relies on the tasks explicitly yielding the execution you can end up waiting longer than you might have expected if another task is doing heavy calculations. |
13:38:35 | * | laaron quit (Remote host closed the connection) |
13:40:26 | PMunch | But a task doing 60ms of execution is now leading to a 500ms delay, which isn't optimal.. |
13:40:34 | * | laaron joined #nim |
13:40:41 | alexander92 | this is cooperative multitasking |
13:40:43 | disruptek | the only mysterious behavior that i've seen is when you have an async iteration that runs some code after the yield, or something. ie. it's not obvious, or it's even surprising, when code before/after the yield runs. |
13:41:03 | PMunch | alexander92, yes, as I said that's what I'm trying to demonstrate here |
13:41:04 | alexander92 | oh yes, this is something i argued about with some people |
13:41:06 | alexander92 | basically |
13:41:19 | alexander92 | the ability to detect "blocking" + "heavy" functions |
13:41:23 | alexander92 | on compile time |
13:41:28 | alexander92 | and auto-move them to a thread |
13:41:29 | alexander92 | if needed |
13:41:35 | alexander92 | (or manually) |
13:41:48 | PMunch | How would you detect that? |
13:41:51 | alexander92 | but for the second part the await a flow var + fixed threadpool should be ready iirc |
13:42:29 | alexander92 | well, the blocking thing , i imagined similar to effects: you annotate some primitives (syscalls etc) as "blocking" |
13:42:45 | alexander92 | and blocking-ness of callee-s is inferred |
13:42:51 | disruptek | i don't see anything taking an extra 500ms; what am i missing? |
13:42:53 | alexander92 | but not sure how practical this would be |
13:43:16 | alexander92 | for heavy code, not sure: i found out go seems to do some preemptive stuff for those |
13:43:22 | alexander92 | e.g. inserting yields in tight loops |
13:43:31 | alexander92 | https://github.com/golang/go/issues/10958 |
13:44:26 | disruptek | isn't that issue suggesting that go isn't yielding in tight loops but only at function call boundaries? |
13:44:46 | PMunch | disruptek: http://ix.io/1VK5 this is what yould normally see |
13:45:17 | alexander92 | yes |
13:45:22 | PMunch | And this is what happens when you sleep 60ms http://ix.io/1VK6 |
13:45:23 | alexander92 | so it seems its not implemented |
13:46:16 | disruptek | ah, so adding the sync sleep for 500ms causes the app to take +1000ms to run. |
13:46:44 | PMunch | As you can see instead of immediately resolving the future of the tick once the sleep is over (since delayedEcho fires at 550ms the 60ms sleep should put it over the 600ms tick) it waits for almost 500ms before it triggers it |
13:47:20 | disruptek | this could well be the async-is-an-iterator-with-weird-semantics thing. |
13:47:29 | PMunch | Adding a 60ms sleep (so that it sleeps over the next tick by 10ms) adds almost 500ms to when the tick actually triggers |
13:47:48 | PMunch | I'm just trying to imagine what the dispatcher is actually doing here.. |
13:49:10 | disruptek | ok, i finally understand what you're on about. |
13:49:59 | PMunch | Huh, interesting: http://ix.io/1VKb |
13:50:59 | PMunch | Adding another future that should trigger right after the sleep (550 + 60 = 610, it triggers at 620) somehow makes the dispatcher trigger both the tick and the other sleep at the 620 mark.. |
13:53:59 | PMunch | I think this might have to do with how sleeping is done.. |
13:54:07 | PMunch | Like the async sleep |
14:00:35 | * | hoijui quit (Ping timeout: 250 seconds) |
14:01:17 | disruptek | this is clearly a bug. |
14:02:22 | disruptek | take your original example and change the async sleep in delayedEcho to sleep for wait*2; the runtime is actually less. |
14:03:32 | PMunch | Yes, because 550*2 = 1100 and the 60ms hard sleep no longer drops it over the next tick |
14:03:46 | PMunch | Well, there aren't any more ticks, but if there were it would still be faster |
14:04:23 | PMunch | But I'm not sure if this is due to timers, or if it would happen if actually awaiting something more productive |
14:05:20 | disruptek | i wonder if the echo is also confusing the issue, because it's i/o. |
14:05:38 | disruptek | need a smaller repro. |
14:06:53 | PMunch | Hmm, I don't think so.. |
14:07:38 | * | nsf quit (Quit: WeeChat 2.5) |
14:09:23 | disruptek | i guess the echo isn't relevant, or needed. best to leave it out. |
14:11:08 | * | alexander92 quit (Ping timeout: 265 seconds) |
14:12:18 | PMunch | Smaller example showing all the different scenarios: http://ix.io/1VKo |
14:13:01 | PMunch | Or if you want to play with it live: https://play.nim-lang.org/#ix=1VKq |
14:13:36 | * | tdc joined #nim |
14:16:00 | PMunch | Or maybe even more interesting: https://play.nim-lang.org/#ix=1VKt |
14:16:06 | PMunch | It has an extra scenario |
14:16:52 | disruptek | right, that's a little better. |
14:18:04 | * | treeform joined #nim |
14:18:28 | disruptek | it's that damned 500ms again, and nothing else. |
14:19:23 | treeform | hmm so discord got disconnected like a week ago form IRC. I guess it's time to connect to IRC directly. Hi everyone, long time no see. |
14:19:38 | disruptek | sup boss |
14:19:56 | disruptek | PMunch: good work finding that. |
14:20:43 | PMunch | Commented on what happens in each example: https://play.nim-lang.org/#ix=1VKv |
14:21:05 | PMunch | treeform, yeah it's a bit unfortunate that no-one has done anything to fix that.. |
14:21:09 | PMunch | Oh well, I'm off |
14:21:16 | treeform | bye |
14:22:02 | PMunch | disruptek, the strange this is that the second one fires at 550 and not 660 like the first, there is definitely something weird going on here.. |
14:22:04 | disruptek | the problem is that we spin an extra time. |
14:22:23 | disruptek | we aren't checking to see if anything is ready, though it is. so 160 + 500ms == 660ms. |
14:22:52 | disruptek | exactly the same as the i/o issue. |
14:23:03 | PMunch | Right, so when it is done sleeping it doesn't check that the timer has expired. So it awaits 500ms before it checks again |
14:23:17 | disruptek | i'm just surprised the previous solution wasn't curative. |
14:23:25 | PMunch | But why is that last example 550ms then.. |
14:23:50 | PMunch | Timers and IO are handled separately in the asyncdispatch module, that's probably why |
14:23:57 | PMunch | But yeah, as I said I have to go now |
14:23:58 | * | PMunch quit (Remote host closed the connection) |
14:25:49 | disruptek | i think in the last case, it's actually the 2nd sleep that finishes first and causes the spin, because doubleSleep hasn't completed (and won't for another 10ms). |
14:30:38 | * | lritter joined #nim |
14:36:00 | disruptek | https://play.nim-lang.org/#ix=1VKD |
14:36:25 | disruptek | proof that it's not the extra futures of and/or. |
14:37:15 | * | owl joined #nim |
14:37:45 | * | alexander92 joined #nim |
14:40:18 | * | owl_000 quit (Ping timeout: 245 seconds) |
14:42:18 | * | alexander92 quit (Ping timeout: 258 seconds) |
14:43:45 | * | alexander92 joined #nim |
14:45:16 | * | uvegbot joined #nim |
14:49:16 | * | zyklon quit (Ping timeout: 264 seconds) |
14:53:57 | * | joshbaptiste joined #nim |
15:01:36 | * | abm joined #nim |
15:04:01 | Araq | disruptek: but why do you use sleep(hard) |
15:11:40 | * | solitudesf joined #nim |
15:13:00 | * | absolutejam quit (Ping timeout: 265 seconds) |
15:29:28 | * | Yardanico joined #nim |
15:29:39 | * | Yardanico quit (Client Quit) |
15:30:10 | * | Yardanico joined #nim |
15:30:15 | * | Yardanico quit (Client Quit) |
15:30:38 | * | Yardanico joined #nim |
15:32:43 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
15:36:51 | * | alexander92 quit (Ping timeout: 240 seconds) |
15:38:53 | * | treeform quit (Remote host closed the connection) |
15:42:48 | * | alexander92 joined #nim |
15:52:45 | * | alexande1 joined #nim |
15:52:45 | * | clyybber joined #nim |
15:54:11 | * | vsantana quit (Quit: leaving) |
15:54:51 | * | alexander92 quit (Ping timeout: 240 seconds) |
15:59:03 | * | alexande1 quit (Ping timeout: 245 seconds) |
15:59:28 | * | absolutejam joined #nim |
16:05:27 | * | absolutejam quit (Ping timeout: 245 seconds) |
16:14:29 | * | abm quit (Quit: Leaving) |
16:45:14 | * | NimBot joined #nim |
16:53:52 | * | solitudesf- joined #nim |
16:55:27 | * | solitudesf quit (Ping timeout: 245 seconds) |
16:55:45 | * | actuallybatman joined #nim |
16:58:19 | * | treeform joined #nim |
16:58:37 | disruptek | Araq: to simulate Real Work™. |
16:59:32 | treeform | Hmm making an iOS app. Running stuff with --noMain:on ... I call NimMain from ios land directly. But for some reason it does not call systemDatInit000 like it should. |
16:59:50 | treeform | Is there more docs on the --noMain:on option? |
17:00:28 | treeform | It looks like I need systemDatInit000 to setup the types. |
17:17:26 | Zevv | treeform: why not just call NimMain() from your own startup code? |
17:20:54 | treeform | @Zevv that is what I do. I call NimMain() after the iOS stuff. after importing it `proc NimMain() {.importc.}` |
17:22:16 | Zevv | did you check the generated c code then? I see heer that NimMain() calls PreMain, which calls systemDatInit000() in turn |
17:23:59 | treeform | Yeah I am putting printfs in there |
17:24:02 | * | solitudesf- quit (Ping timeout: 276 seconds) |
17:24:02 | treeform | ``` printf("calling systemDatInit000\n"); systemDatInit000(); printf("done with systemDatInit000\n");``` |
17:24:21 | treeform | And then I have a printf inside systemDatInit000() |
17:24:27 | treeform | but... it never gets there |
17:24:30 | treeform | it just skips it |
17:27:27 | treeform | its like some one overrides systemDatInit000 and does not let it run |
17:28:52 | treeform | printf debugging is cool, but you know what is better segfault debugging "*(int*)0=0;" here I come. |
17:30:48 | treeform | I can't get it to print or segfault |
17:30:50 | treeform | ```N_LIB_PRIVATE N_NIMCALL(void, systemDatInit000)(void) { *(int*)0=0; printf("inside systemDatInit000\n");``` |
17:34:04 | lqdev[m] | anyone has/knows a single-line text box implementation I could perhaps ~~steal~~ borrow some code from? |
17:36:07 | lqdev[m] | I'm struggling with proper ctrl + delete support |
17:38:49 | lqdev[m] | the code doesn't have to be Nim, just something I can look at as a reference implementation. |
17:43:24 | * | nsf joined #nim |
17:48:26 | treeform | @lqdev[m] I do. |
17:48:58 | treeform | Its part of my typography library: https://github.com/treeform/typography#text-boxes |
17:48:59 | lqdev[m] | treeform: could you perhaps show me the code, please? |
17:49:09 | lqdev[m] | oh, nice. I'll check it out |
17:49:15 | treeform | Its multiline by default, but it has an option to set it to be single line. |
17:49:32 | lqdev[m] | wow that's super cool |
17:50:25 | * | doesntgolf joined #nim |
17:50:56 | treeform | Here is some front end code that uses the backend text box: https://github.com/treeform/fidget/blob/master/src/fidget/openglbackend/base.nim#L203 |
17:51:18 | treeform | what is "ctrl + delete" though? |
17:51:24 | treeform | I might have missed that keyboard combination? |
17:52:02 | treeform | it looks like that deletes everything to the end of line? |
17:52:21 | lqdev[m] | it's the same as ctrl + backspace, but it works with delete's behavior (deleting the word to the right of the cursor) |
17:53:02 | treeform | hmm ctrl + delete works in Chrome but does not work in MacOS's TextEdit |
17:53:17 | treeform | so its not a super common shortcut |
17:53:24 | lqdev[m] | I'll use your library to save myself a bit of hassle, thanks for that |
17:53:45 | lqdev[m] | well, I don't use ctrl + delete very often but I wanted to have it for completeness sake |
17:54:55 | lqdev[m] | had I known about your library I probably wouldn't even use freetype. there's still time to port! |
17:55:01 | treeform | I would implement that by calling `endOfLine(shift=true)` with `delete()` |
17:55:32 | treeform | Well you can't just use freetype, you also need to use pango and harfbazz. |
17:55:56 | treeform | my library tires to do what the 3 libraries do |
17:56:44 | lqdev[m] | I don't use pango and harfbuzz, I have my own simple text renderer using Nim's unicode and OpenGL |
17:57:16 | lqdev[m] | and it works like a charm, maybe apart from a few features like ligatures (which aren't that common in games anyway) |
17:57:19 | treeform | how do you do word wrapping? do you have subpixel rendering? |
17:57:42 | lqdev[m] | I don't do word wrapping yet, I didn't need it so far |
17:58:16 | lqdev[m] | and I don't have subpixel rendering, it would only add more code I don't really need |
17:58:36 | treeform | Ok cool. My lib does all that. |
17:58:48 | lqdev[m] | also I don't have a single clue about how to render the glyphs produced by FT when using subpixel rendering |
17:59:02 | treeform | https://raw.githubusercontent.com/treeform/typography/master/tests/subpixelglyphs.png |
17:59:17 | treeform | I render 10 shifted glyphs per character |
17:59:24 | treeform | then pick the right one when typesetting |
17:59:34 | lqdev[m] | oh that kind of subpixel rendering |
17:59:37 | lqdev[m] | I thought you mean the three color stuff |
17:59:50 | treeform | well that too, although that is going away |
18:00:00 | treeform | you got to do this one first, then do the 3 color stuff |
18:00:19 | treeform | the 3 color stuff is "Subpixel Antialising" |
18:00:26 | treeform | https://github.com/treeform/typography#subpixel-antialising-is-on-its-way-out |
18:00:38 | treeform | I don't think it's useful and is on the way out. |
18:02:08 | * | natrys joined #nim |
18:09:08 | lqdev[m] | grayscale rendering isn't that bad anyways, I don't really need much more than that |
18:09:19 | lqdev[m] | I haven't seen a single game use RGB rendering for text |
18:09:39 | lqdev[m] | s/RGB rendering/subpixel antialiasing |
18:12:01 | treeform | yeah "Subpixel Antialising" is not needed. |
18:12:24 | treeform | But subpixel stuff is needed for letters < 24px. |
18:12:37 | treeform | Other wise it looks bad |
18:13:42 | treeform | Ok so I removed "systemDatInit000" from the code base and it still compiles |
18:13:51 | treeform | If I rename it it works as a regular function |
18:14:00 | treeform | but some thing about systemDatInit000 name is special? |
18:14:03 | * | lqdev[m] uploaded an image: image.png (3KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/xHTXmDfGyERbtyvqOXPPCfdI > |
18:14:13 | lqdev[m] | that's my current implementation |
18:14:25 | * | exelotl joined #nim |
18:16:53 | lqdev[m] | treeform: I don't see ctrl + backspace here? https://github.com/treeform/fidget/blob/master/src/fidget/openglbackend/base.nim#L241 |
18:19:02 | treeform | I don't have ctrl + backspace implemented. |
18:19:22 | treeform | I should add that. That is some thing I don't have. I did not know it was a thing. Looks like its not a thing everywhere. |
18:19:38 | lqdev[m] | well I use it all the time |
18:19:39 | treeform | ctrl + delete as well |
18:20:06 | treeform | You can use `endOfLine(shift=true)` with `delete()` to simulate it. |
18:20:25 | treeform | does it copy the end of line? I don't think so. |
18:20:49 | treeform | Your text image does not look bad. |
18:21:01 | treeform | And for a game that is probably fine. |
18:21:20 | treeform | The kerning has some errors in there though. |
18:21:33 | * | Yardanico quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
18:21:39 | lqdev[m] | I'll switch to your library, FT takes up a big chunk of space in my executables |
18:22:33 | treeform | The spaces here are a bit too wide: |
18:22:34 | treeform | https://dl3.pushbulletusercontent.com/h1itakLb9uoZF5GyqtWEwNGDwnintLfR/image.png |
18:23:01 | lqdev[m] | I see that now |
18:23:02 | treeform | If you bump the font above 24px it becomes hardly noticeable. |
18:23:58 | lqdev[m] | except, I don't bump the font above 24px. it's always 14px |
18:24:26 | treeform | I also don't think a casual player would know. |
18:24:48 | * | Yardanico joined #nim |
18:24:53 | treeform | The text is fine. You can read it. It looks great. |
18:26:05 | lqdev[m] | I don't think it will work well if I mix this with your text editing |
18:26:28 | lqdev[m] | the offsets will probably be all over the place |
18:29:26 | treeform | yeah I round them to nearest 10th |
18:29:36 | treeform | to not make 1000s of glyphs |
18:30:30 | treeform | My layout function provides all the offsets. So if you use that to position the glyphs that would work. |
18:30:56 | treeform | Main I can't solve this issue. I have a function "systemDatInit000" who's body is not called ever. |
18:31:08 | treeform | I can delete systemDatInit000 and I don't get a link error! |
18:31:23 | treeform | But I I rename it to say "systemDatInit0002" |
18:31:29 | treeform | then it all works like a normal function |
18:31:39 | treeform | some thing about systemDatInit000 makes it a ghost/zombie function... |
18:32:40 | treeform | I don't even know what to ask google about this issue... |
18:45:11 | * | alexander92 joined #nim |
18:54:44 | * | clyybber quit (Quit: WeeChat 2.6) |
18:57:51 | treeform | I found my issue. XCode build-clean does not work. It does not fully clean. If you rm files yourself or with a script it works how it should. |
18:57:59 | treeform | Tell your friends to stay a way from XCode. |
19:04:07 | Araq | always good to know :-) |
19:06:26 | Calinou | tell me about it, I'll have to create an iOS app for university this semester :( |
19:06:29 | Calinou | which also means buying a Mac |
19:08:11 | alexander92 | can't you borrow one |
19:09:53 | * | solitudesf joined #nim |
19:12:09 | * | absolutejam joined #nim |
19:19:36 | FromGitter | <moigagoo> Is there a way to get a fully-qualified type name, i.e. with the module it's imported from? `$` gets me only the type name, so `$a.MyType` and `$b.MyType` both give me "MyType". |
19:22:30 | treeform | @Calinou do you want to use nim to make the iOS app? |
19:23:35 | Calinou | no, we have to use Swift anyway |
19:23:46 | Calinou | alexander92: my university has Macs but you can't borrow them |
19:24:07 | Calinou | the Mac room isn't freely usable outside of classes, so you can't use it for your project |
19:24:34 | treeform | Swift is not that bad though. |
19:24:49 | treeform | I bet XCode works well if you stay where Apple wants you to stay. |
19:24:56 | Calinou | indeed |
19:25:27 | treeform | @moigagoo I don't think there is a way. In the generated C code I been staring at there is only names and no module info. |
19:27:47 | FromGitter | <moigagoo> @treeform Thanks! <sigh>, gotta think of ways to work around that :-) |
19:31:52 | lqdev[m] | treeform: no typeset iterator? that sucks |
19:32:22 | lqdev[m] | this means I'll have to allocate a new seq[GlyphPosition] every time I want to draw text :( |
19:33:29 | Zevv | treeform: found your main problem? |
19:36:05 | lqdev[m] | treeform: mind if I submit a pull request that adds a `typeset` iterator? |
19:36:24 | treeform | sure, but typesetting could be slow, you should cache it. |
19:36:31 | treeform | that is what I do. |
19:36:57 | lqdev[m] | hm |
19:37:12 | lqdev[m] | that's not a bad idea |
19:37:17 | treeform | Unless you cache the mesh of the text instead |
19:37:30 | treeform | that you generate |
19:37:33 | lqdev[m] | especially because your typesetting is way more complex than the simple stuff I have |
19:37:42 | treeform | You need the layout for textbox and clicking on text. |
19:37:47 | treeform | So I cache the layout. |
19:38:06 | lqdev[m] | I don't generate a mesh, my engine has an immediate mode-style API |
19:38:12 | lqdev[m] | what about scrolling in textboxes? |
19:38:40 | treeform | Zevv yes I did. XCode was not doing "clean" correctly which caused all sort of confusion. |
19:38:49 | lqdev[m] | guess I need to do it myself? |
19:39:06 | treeform | yes the scrolling is outside the scope of the textbox library |
19:39:15 | treeform | as you need to do openGL masking |
19:39:29 | treeform | You can see me doing that in the fidget library i linked as an example. |
19:39:44 | lqdev[m] | ikr, and some cursor position transformations before passing it to typography |
19:40:02 | treeform | https://github.com/treeform/fidget/blob/master/src/fidget/openglbackend/context.nim#L353 |
19:50:29 | * | Vladar quit (Remote host closed the connection) |
20:07:50 | * | solitudesf quit (Ping timeout: 265 seconds) |
20:09:08 | * | Yardanico quit (Ping timeout: 246 seconds) |
20:13:28 | * | solitudesf joined #nim |
20:13:38 | * | alexander92 quit (Ping timeout: 265 seconds) |
20:15:39 | * | laaron quit (Quit: ZNC 1.7.1 - https://znc.in) |
20:16:03 | * | laaron joined #nim |
20:19:47 | * | nsf quit (Quit: WeeChat 2.5) |
20:25:11 | * | natrys quit (Quit: natrys) |
20:25:34 | * | alexander92 joined #nim |
20:26:31 | * | xet7 quit (Remote host closed the connection) |
20:28:10 | * | xet7 joined #nim |
20:29:03 | * | mwbrown quit (Quit: Exiting) |
20:34:38 | * | jfoutaise quit (Ping timeout: 245 seconds) |
20:36:21 | * | jfoutaise joined #nim |
20:44:55 | * | mwbrown joined #nim |
20:45:23 | * | Ven`` joined #nim |
20:54:43 | * | mwbrown quit (Quit: Exiting) |
20:56:00 | lqdev[m] | treeform: does typography render tabs correctly, and if so, is there a configuration option to change the tab width? |
20:59:14 | * | narimiran quit (Ping timeout: 240 seconds) |
21:01:13 | lqdev[m] | also, is there a fast and easy way of checking the width of some typeset text? |
21:01:36 | lqdev[m] | my only guess is that I have to compute that myself, which isn't a problem really |
21:06:48 | * | mwbrown joined #nim |
21:14:37 | * | solitudesf quit (Ping timeout: 245 seconds) |
21:24:37 | treeform | lqdev, I don't do anything about tabs sorry. Could you add that as an issue. It feels like it would be really easy to add. |
21:25:28 | treeform | I don't have width computation. Again sounds really easy to add. Can you add that as an issue? |
21:25:47 | treeform | I do have typesetting with width though. So it will wrap. |
21:35:38 | lqdev[m] | treeform: done |
21:49:43 | * | capr1 joined #nim |
21:51:29 | * | absolutejam quit (Ping timeout: 268 seconds) |
22:09:59 | * | alexander92 quit (Ping timeout: 268 seconds) |
22:17:51 | * | Ven`` quit (Ping timeout: 265 seconds) |
22:25:35 | * | treeform quit (Remote host closed the connection) |
23:06:31 | * | owl_000 joined #nim |
23:10:52 | * | abm joined #nim |
23:22:38 | * | treeform joined #nim |
23:30:53 | * | krux02_ joined #nim |
23:33:53 | * | krux02 quit (Ping timeout: 250 seconds) |
23:54:26 | * | abm quit (Quit: Leaving) |