00:14:42 | * | fredik92 quit (Quit: Shutting down...) |
00:15:58 | ftsf | rtr_, a seq? var foo = newSeq[uint8]() foo.add(1) |
00:16:57 | rtr_ | ftsf: Also how do I pop elements? |
00:17:02 | * | castlelore quit (Quit: WeeChat 1.5) |
00:17:17 | * | nsf quit (Quit: WeeChat 1.5) |
00:17:52 | ftsf | foo.delete(indexToRemove) |
00:18:03 | ftsf | or foo.del(indexToRemove) |
00:18:40 | ftsf | del moves the highest entry to the spot to be removed and then cuts off the highest entry. delete moves everything down. |
00:18:48 | * | PMunch quit (Quit: leaving) |
00:18:51 | ftsf | so del is faster, delete is better if you need to keep the order |
00:21:58 | * | castlelore joined #nim |
00:24:31 | rtr_ | ftsf: Thanks. I thought there would be something similar to 'delete' which removes and returns the index value |
00:24:47 | rtr_ | *value at an index |
00:25:06 | ftsf | ahh |
00:25:19 | ftsf | pop |
00:25:35 | ftsf | foo.pop() will remove the last value and return it |
00:25:40 | ftsf | but doesn't let you specify the index |
00:26:25 | * | libman quit (Read error: Connection reset by peer) |
00:27:35 | rtr_ | ftsf: Thanks. But I couldn't find this in docs easily. Is there something wrong with the docs? |
00:28:54 | ftsf | the docs are not easily searchable afaik |
00:28:57 | ftsf | http://nim-lang.org/docs/system.html#pop,seq[T] |
00:29:26 | rtr_ | Oh. Thanks |
00:34:02 | * | bogen1 quit (Ping timeout: 264 seconds) |
00:35:15 | rtr_ | How do I reverse a sequence? |
00:35:52 | ftsf | http://nim-lang.org/docs/algorithm.html#reverse,openArray[T],Natural,Natural |
00:44:00 | * | nairobi joined #nim |
00:44:52 | * | kingofoz quit (Ping timeout: 255 seconds) |
00:45:29 | * | nairobi_ joined #nim |
00:45:33 | * | libman joined #nim |
00:45:40 | * | kingofoz joined #nim |
00:46:45 | * | fastrom quit (Quit: Leaving.) |
00:48:12 | * | nairobi quit (Ping timeout: 240 seconds) |
00:49:54 | * | nairobi_ quit (Ping timeout: 260 seconds) |
00:54:01 | * | brson quit (Ping timeout: 258 seconds) |
00:55:53 | * | libman quit (Remote host closed the connection) |
01:10:10 | rtr_ | Are if/for expressions? I mean can I use the conditional output to assign to a variable directly? |
01:14:45 | ftsf | let foo = if x: 1 else: 0 |
01:14:45 | ftsf | yes |
01:21:50 | rtr_ | Oh. Nice |
01:26:58 | * | chemist69 quit (Disconnected by services) |
01:27:03 | * | chemist69_ joined #nim |
01:40:35 | * | brson joined #nim |
01:46:46 | * | rtr_ quit (Remote host closed the connection) |
01:54:53 | * | rtr_ joined #nim |
02:07:37 | * | Jesin quit (Quit: Leaving) |
02:27:49 | * | kingofoz quit (Quit: Leaving) |
02:29:56 | * | dddddd_ quit (Ping timeout: 244 seconds) |
02:30:21 | * | desophos joined #nim |
02:47:30 | * | rtr_ quit (Remote host closed the connection) |
02:58:27 | * | endragor joined #nim |
02:59:27 | * | endragor quit (Client Quit) |
03:11:21 | * | Demon_Fox quit (Quit: Leaving) |
03:12:17 | * | pie_ quit (Ping timeout: 250 seconds) |
03:17:41 | * | brson quit (Read error: Connection reset by peer) |
03:17:56 | * | brson joined #nim |
03:21:38 | * | brson quit (Read error: Connection reset by peer) |
03:27:58 | * | brson joined #nim |
03:30:25 | * | kunev quit (Ping timeout: 244 seconds) |
03:31:31 | * | kunev joined #nim |
03:36:02 | * | brson quit (Ping timeout: 265 seconds) |
04:48:11 | * | rtr_ joined #nim |
04:53:22 | * | chemist69_ quit (Ping timeout: 265 seconds) |
04:54:27 | * | rtr_ quit (Ping timeout: 244 seconds) |
05:00:43 | * | space-wizard quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
05:07:29 | * | rtr_ joined #nim |
05:20:16 | * | chemist69 joined #nim |
05:28:47 | * | castlelore quit (Quit: WeeChat 1.5) |
05:32:27 | * | space-wizard joined #nim |
05:45:04 | * | nairobi joined #nim |
06:12:44 | * | space-wizard quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
06:26:30 | * | pafmaf joined #nim |
06:30:24 | * | Arrrr joined #nim |
06:55:17 | * | yglukhov joined #nim |
06:59:47 | * | yglukhov quit (Ping timeout: 250 seconds) |
07:00:22 | * | Trustable joined #nim |
07:02:38 | * | fastrom joined #nim |
07:07:24 | * | nairobi quit (Remote host closed the connection) |
07:13:58 | * | GustavoLapasta joined #nim |
07:21:59 | * | gokr joined #nim |
07:23:55 | * | GangstaCat quit (Quit: Leaving) |
07:25:36 | * | yglukhov joined #nim |
07:28:56 | * | fastrom quit (Quit: Leaving.) |
07:30:02 | * | nsf joined #nim |
07:30:23 | * | yglukhov quit (Remote host closed the connection) |
07:33:12 | * | brechtm joined #nim |
07:34:37 | * | GustavoLapasta quit (Quit: Leaving) |
07:41:19 | * | nairobi joined #nim |
07:42:25 | * | yglukhov joined #nim |
07:46:15 | * | nairobi quit (Ping timeout: 276 seconds) |
07:46:33 | * | yglukhov quit (Ping timeout: 240 seconds) |
08:06:43 | * | brechtm quit (Read error: Connection reset by peer) |
08:06:49 | * | brechtm_ joined #nim |
08:08:27 | * | retropikzel joined #nim |
08:21:40 | * | mjl joined #nim |
08:23:49 | euantor | `This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Open Hub` |
08:23:56 | euantor | Pretty cool :) |
08:24:27 | * | bjz joined #nim |
08:26:38 | FromGitter | <endragor> @dom96 @Araq What’s the current plan for upcoming/asyncdispatch? |
08:38:03 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
08:39:00 | euantor | That new terminal.terminalWidth is pretty handy, will be updating my progress bar library to make use of that to calculate width automatically. |
08:43:28 | * | Matthias247 joined #nim |
08:44:23 | FromGitter | <dom96> @endragor figure out the best way to replace asyncdispatch with it, with as little breakage as possible. |
08:44:39 | FromGitter | <dom96> But first, I need to properly review it. |
08:45:05 | FromGitter | <dom96> @endragor are you using it? Does it work well? |
08:47:06 | * | yglukhov joined #nim |
08:48:04 | FromGitter | <endragor> @dom96 I found flaws in both current and upcoming asyncdispatch event loop (`poll()`) and was wondering if I should fix both or just upcoming. It’s more serious in upcoming. ⏎ I’ve started using upcoming/asyncdispatch, yes, mainly because it supports user-defined events. I'll be using/testing it extensively in the nearest couple of weeks. |
08:49:07 | Arrrr | huh? i'm hearing voices |
08:54:53 | * | bjz joined #nim |
08:55:34 | * | gokr quit (Ping timeout: 240 seconds) |
08:59:11 | * | bjz_ joined #nim |
08:59:54 | * | chemist69 quit (Ping timeout: 260 seconds) |
09:00:24 | FromGitter | <dom96> @endragor what are the flaws? |
09:00:37 | FromGitter | <vegansk> @dom96, hi. Please review the comments from https://github.com/nim-lang/Nim/pull/4683 again. |
09:01:39 | * | bjz quit (Ping timeout: 276 seconds) |
09:02:29 | FromGitter | <dom96> @vegansk remind me after around 5pm :) |
09:05:44 | FromGitter | <endragor> @dom96 current asyncdispatch processes ALL registered callbacks, even if the first one in the queue asked to call it again. This breaks ordering when sending/receiving data. For example: ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=57c940e86bf4c26505c593c8] |
09:06:33 | FromGitter | <vegansk> @dom96. 12am for me :-) I'll try |
09:07:42 | FromGitter | <endragor> @dom96 those are only for *nix systems, I haven’t looked into Windows async at all |
09:13:08 | FromGitter | <qqtop> good to have terminalwidth in the stdlib , I usually use this ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=57c942a36bf4c26505c59ad9] |
09:24:08 | * | veganskaway is now known as vegansk |
09:26:48 | * | chemist69 joined #nim |
09:30:03 | * | nairobi joined #nim |
09:35:52 | * | nairobi quit (Ping timeout: 264 seconds) |
09:41:00 | * | gokr joined #nim |
09:51:50 | * | Sembei joined #nim |
09:59:05 | FromGitter | <endragor> @dom96, hmm, actually according to the doc recv should receive *up to* the specified size, so there is no problem with recv. but the same example applies to `send` which is supposed to fully send data |
10:12:35 | FromGitter | <endragor> @dom96 I think something like `recvFully` should be a part of asyncdispatch. there is no way to reliably retrieve a chunk of binary data at the moment without having interference from subsequent `recv` operations. `recvLine` also has the problem: ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=57c950926efec7117c9fefd1] |
10:14:03 | FromGitter | <dom96> huh |
10:14:12 | FromGitter | <dom96> if you use ``await`` then it should be fine |
10:14:26 | FromGitter | <endragor> yes, but it should not be mandatory |
10:14:28 | FromGitter | <dom96> obviously if you execute them at the same time then bad things will happen |
10:14:30 | FromGitter | <dom96> why? |
10:15:06 | * | huonw quit (Ping timeout: 276 seconds) |
10:15:22 | FromGitter | <dom96> This is definitely by design |
10:16:00 | FromGitter | <vegansk> @endragor, I think that it's the same if you will read from ``s`` in many threads. |
10:16:42 | FromGitter | <endragor> ok, here is perhaps a bit more realistic sample. Say, my protocol expects two lines sent from the server: ⏎ ```waitFor(all(s.recvLine(), ⏎ s.recvLine())) ⏎ poll()``` ⏎ Do you say it’s fine that the result of this will be a mess? If it’s by design then at least throw an exception in the second queued recv. [https://gitter.im/nim-lang/Nim?at=57c9518a29ee4a6705872d08] |
10:17:25 | FromGitter | <endragor> @vegansk not exactly, that is the same thread. I find it perfectly intuitive as a user to expect sequential execution of read/write operations that I make before I invoke `poll()` |
10:18:15 | FromGitter | <dom96> It is the same thread, but it's asynchronous |
10:18:23 | FromGitter | <dom96> You are running them at the same time |
10:18:35 | FromGitter | <dom96> ``await`` is what gives you sequential execution |
10:18:56 | FromGitter | <vegansk> @endragor, I know that it's the same thread. But what if Nim 1.0 will have multithreaded async? :-) |
10:19:12 | FromGitter | <dom96> Using ``all`` doesn't change a thing |
10:19:55 | FromGitter | <dom96> What are you actually trying to do? |
10:19:56 | * | retropikzel_ joined #nim |
10:20:05 | * | huonw joined #nim |
10:20:34 | * | retropikzel_ quit (Client Quit) |
10:20:35 | FromGitter | <euantorano> `all` is really meant to be used for doing things like multiple HTTP requests |
10:20:58 | FromGitter | <euantorano> My understanding is that it's not rally meant to be used on the same handle for multiple of the same operations (eg `read`) |
10:21:13 | FromGitter | <dom96> yes, if you use it for HTTP requests it should work fine. |
10:21:49 | FromGitter | <dom96> well, as long as you have two different sockets. |
10:21:56 | FromGitter | <dom96> i.e. two different connections |
10:22:03 | FromGitter | <euantorano> Yeah, different HTTP clients for each request |
10:29:41 | * | PMunch joined #nim |
10:33:31 | * | hendi joined #nim |
10:35:16 | ftsf | FromGitter, what's going on? o_O |
10:35:17 | FromGitter | ftsf, I'm a bot, *bleep, bloop*. I relay messages between here and https://gitter.im/nim-lang/Nim |
10:38:16 | retropikzel | I'm trying to put function into table and compiler says "Error: 'functinname' cannot be passed to a procvar" what that usually means? have some links relating to this? |
10:39:33 | ftsf | retropikzel, show us your code? |
10:39:42 | FromGitter | <vegansk> <retropikzel>, mark your function as {.procvar.}. |
10:42:33 | FromGitter | <endragor> @dom96 why does the current asyncdispatch queue up callbacks at all then? the upcoming asyncdispatch design makes more sense in this regard (having only 1 callback at the same time). and, as I said, if it’s always wrong to queue up same type of requests on the same handle, an exception should be thrown on subsequent attempts. In my case it’s easily possible that the second message is sent to the same destination before the previous |
10:42:33 | FromGitter | ... message is fully sent, so I guess I’ll have to implement queueing on application level. But it’s fairly easy to support that on `asyncdispatch` level. ⏎ `await` doesn’t really help when requests are queued from different places |
10:42:53 | retropikzel | ftsf, http://pastebin.com/4n8UWNPk |
10:44:27 | retropikzel | vegansk, thank you that worked |
10:57:15 | FromGitter | <dom96> @endragor that might just be an oversight on my part. I doubt that you need to implement queuing yourself, keep in mind that you can also use callbacks. |
10:57:31 | FromGitter | <dom96> Please describe exactly what you are doing, maybe I can help better then. |
10:58:17 | * | GangstaCat joined #nim |
11:05:43 | FromGitter | <endragor> @dom96 I use callbacks a lot. ⏎ I’m working on distributed computing framework. Say, there are 2 nodes (A and B) in the cluster, connected to each other via TCP. Node A has two external clients connected via TCP. Those two clients simultaneously send requests that require that node B is involved. `poll()` on node A invokes recv() callbacks for two clients, each callback then calls `nodeB.send(payload)` with two different payloads. |
11:06:12 | * | chemist69 quit (Ping timeout: 258 seconds) |
11:06:29 | FromGitter | <endragor> I need those payloads to be properly sent and received, without any interference |
11:07:31 | * | Trustable quit (*.net *.split) |
11:07:32 | * | mtj_ quit (*.net *.split) |
11:07:32 | * | beatmox quit (*.net *.split) |
11:07:32 | * | Satyajit quit (*.net *.split) |
11:07:32 | * | lenstr quit (*.net *.split) |
11:07:41 | * | vegansk quit (Quit: Ухожу я от вас (xchat 2.4.5 или старше)) |
11:09:23 | FromGitter | <dom96> Hrm, I think ``await`` will in fact help you in this case. |
11:09:59 | * | mtj_ joined #nim |
11:09:59 | * | beatmox joined #nim |
11:09:59 | * | Satyajit joined #nim |
11:09:59 | * | lenstr joined #nim |
11:10:00 | FromGitter | <dom96> It depends how you've set up these nodes. |
11:10:09 | FromGitter | <dom96> Any chance I could look at your source code? |
11:10:26 | * | mtj__ joined #nim |
11:10:27 | * | chemist69 joined #nim |
11:10:27 | * | mtj__ quit (Remote host closed the connection) |
11:10:42 | * | mtj_ quit (Write error: Broken pipe) |
11:11:33 | * | mtj_ joined #nim |
11:15:08 | FromGitter | <endragor> not yet, unfortunately. How exactly will `await` help given that `send` gets invoked from different stacks? `await` guarantees ordering within the same `{.async.}` procedure invocation. |
11:19:02 | * | brechtm_ quit (Remote host closed the connection) |
11:29:56 | chemist69 | I have to say, all these `FromGitter` messages do not look nice in my terminal irc client. All the nick highlights are gone, because all messages come from the same nick. |
11:31:01 | BlaXpirit | chemist69, you think highlights are gone? you wouldn't see those messages at all otherwise |
11:31:21 | * | fredrik92 joined #nim |
11:32:28 | chemist69 | No, what I mean is, I get messages from dom96, endragor et al., but all from the same nick `FromGitter`. So all these users get the same highlight and I can not easily distinguish between them anymore. |
11:32:55 | BlaXpirit | chemist69, OK. to restore previous behavior: /ignore FromGitter |
11:33:35 | chemist69 | But then I wouldn't get their messages at all, would I? |
11:33:38 | flyx | BlaXpirit: that is dangerous since people who previously posted via IRC are now posting on Gitter (e.g. dom96) |
11:33:47 | chemist69 | exactly |
11:34:00 | BlaXpirit | i thought dom96 said he would leave gitter, not the other way around |
11:35:02 | flyx | endragor was also previously active here. now I cannot even see whether he's online, and nick autocomplete does not work anymore. |
11:35:30 | chemist69 | flyx: also a good point, +1 |
11:35:34 | BlaXpirit | yup, that sucks |
11:35:48 | flyx | I appreciate the effort, but as things are, this is clearly a drop in communication quality |
11:35:54 | BlaXpirit | the choice is up to the community |
11:36:20 | BlaXpirit | either you do it right by killing off gitter, or you split the community in half, or you stitch the halfs in a bad way |
11:38:40 | FromGitter | <dom96> The reason I'm chatting via Gitter is because I'm at work and I'm too lazy to install an IRC client here. |
11:39:29 | FromGitter | <dom96> So if it wasn't for this bridge I wouldn't be talking at all. |
11:39:47 | FromGitter | <dom96> @endragor It depends how you invoke the async procedure that contains your ``await``. |
11:40:02 | FromGitter | <dom96> If you also invoke it with an ``await`` then things will be fine |
11:40:54 | * | retropikzel quit (Ping timeout: 260 seconds) |
11:45:55 | FromGitter | <endragor> @FromIRC shows up in Gitter quite nicely btw. but yeah the same issue with nick autocomplete. People could give Gitter’s IRC gateway a try, there would not be the problem with nicks. But BlaXpirit mentioned that it is worse than the bot. ⏎ ⏎ @dom96 I don’t yet see how that would be structured for my case, even if it was singlethreaded. Just to clarify, clients are processed independently and the connection to them is persistent, |
11:45:55 | FromGitter | ... I can’t process them one by one or something like that. But I guess it’s not an option for me anyway because send requests independently come from worker threads to the main IO thread that holds socket handles, that’s something I didn’t mention. |
11:54:13 | * | Arrrr quit (Quit: WeeChat 1.5) |
12:10:36 | fredrik92 | hmm... what if the gitter bot just logged into freenode with the specific nicks? |
12:12:15 | flyx | then every gitter user would need to tell the gitter bot their freenode password? |
12:12:33 | flyx | given that they even have the same nick on freenode |
12:13:06 | BlaXpirit | nicks may not be a problem, could be AnyNick|g |
12:13:24 | BlaXpirit | but the other part of the idea... yeah.... |
12:14:33 | * | dddddd joined #nim |
12:15:21 | * | brechtm joined #nim |
12:17:10 | fredrik92 | No, as BlaXpirit pointed out, since #nim doesn't require freenode registration, we would just all be non-registered joins |
12:24:24 | * | desophos quit (Read error: Connection reset by peer) |
12:24:48 | * | couven92 joined #nim |
12:26:24 | * | xet7_ quit (Ping timeout: 276 seconds) |
12:29:37 | kier | true, but what happens if someone is logged into IRC and Gitter at the same time? |
12:30:05 | couven92 | then you'd run into the same (irrelevant) problem I have now |
12:30:11 | FromGitter | <reactormonk> sup |
12:30:22 | couven92 | you'd have to choose a different nick |
12:31:02 | couven92 | like HexChat did with me... since I'm logged in on both my local machine and the remote server i needed to stuff in right now |
12:31:08 | * | couven92 winks at fredrik92 |
12:31:32 | reactormonk | works pretty nicely for me, but a gitter|<nick> stuff wouldn't be too bad. |
12:32:13 | flyx | that would be pretty complex to implement as soon as it is used by multiple channels |
12:32:34 | reactormonk | Why? you'd just have a few nicks logged in. |
12:32:35 | BlaXpirit | well it is used by 3 channels |
12:33:30 | BlaXpirit | do you think freenode will like 50 different connections from one location with ever changing nicks? |
12:34:00 | flyx | you'd basically need to manage the channel joins and parts for each user instead of just posting everything to the linked channel via the same nick |
12:34:32 | BlaXpirit | implementation is not what i'm afraid of |
12:34:47 | reactormonk | BlaXpirit, ask in #freenode ? |
12:35:19 | flyx | and when someone else has the same idea and implements an own service doing the same, there will be name clashes |
12:36:43 | flyx | it also does not solve the problem in the other direction |
12:44:16 | * | Sembei quit (Ping timeout: 244 seconds) |
12:44:23 | * | MyMind joined #nim |
12:45:45 | * | pie_ joined #nim |
12:45:49 | * | pie_ quit (Changing host) |
12:45:49 | * | pie_ joined #nim |
12:46:38 | * | brechtm quit (Read error: Connection reset by peer) |
12:47:05 | * | brechtm joined #nim |
12:48:49 | flyx | private packages always bug me. the problem is that they do not have visibility of things declared in the „public“ package. so I can usually only include them, not import them |
12:51:12 | * | brechtm quit (Ping timeout: 240 seconds) |
12:53:27 | * | brechtm joined #nim |
12:57:22 | * | Senketsu quit (Read error: Connection reset by peer) |
12:57:32 | * | brechtm quit (Ping timeout: 240 seconds) |
12:59:08 | * | GustavoLapasta joined #nim |
12:59:24 | * | Senketsu joined #nim |
12:59:43 | GustavoLapasta | trying pdcurses just for the fun of it, win7 computer: |
12:59:45 | GustavoLapasta | e:\nim\lib\wrappers\pdcurses.nim(43, 10) Error: cannot open 'windows' |
13:00:34 | GustavoLapasta | and why doesn't the pdcurses module appear in the list of the wrappers in the documentation? |
13:00:38 | * | brechtm joined #nim |
13:00:42 | * | kulelu88 joined #nim |
13:05:07 | * | brechtm quit (Ping timeout: 255 seconds) |
13:11:12 | * | couven92 quit (Quit: Shutting down...) |
13:15:38 | * | brechtm joined #nim |
13:19:53 | * | brechtm quit (Ping timeout: 240 seconds) |
13:28:00 | * | brechtm joined #nim |
13:32:23 | * | brechtm quit (Ping timeout: 265 seconds) |
13:42:01 | * | arnetheduck joined #nim |
13:48:42 | * | GangstaCat quit (Quit: Leaving) |
13:53:01 | * | fredrik92 quit (Quit: Leaving.) |
13:53:47 | * | bjz_ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
13:58:19 | * | kulelu88 quit (Ping timeout: 252 seconds) |
14:19:44 | * | Calinou quit (Quit: No Ping reply in 180 seconds.) |
14:25:50 | * | Calinou joined #nim |
14:30:48 | * | brechtm joined #nim |
14:34:02 | * | brechtm_ joined #nim |
14:35:22 | * | brechtm quit (Ping timeout: 244 seconds) |
14:35:23 | * | libman joined #nim |
14:37:04 | * | ldlework quit (Ping timeout: 260 seconds) |
14:38:37 | * | ldlework joined #nim |
14:38:55 | * | ldlework quit (Changing host) |
14:38:55 | * | ldlework joined #nim |
14:48:35 | * | brechtm joined #nim |
14:51:12 | * | brechtm_ quit (Ping timeout: 244 seconds) |
14:52:08 | * | fredrik92 joined #nim |
14:53:06 | * | brechtm quit (Ping timeout: 265 seconds) |
15:06:34 | * | Sergio965 quit (Ping timeout: 240 seconds) |
15:07:35 | * | Sergio965 joined #nim |
15:16:41 | * | Demon_Fox joined #nim |
15:29:16 | * | retropikzel joined #nim |
15:31:59 | * | GustavoLapasta quit (Quit: Leaving) |
15:32:50 | * | Jesin joined #nim |
15:34:13 | * | planhths joined #nim |
15:38:31 | planhths | hello, what that does: "beggh" > "bo" |
15:50:41 | kier | planhths: compares two strings? |
15:51:18 | kier | I guess it would be looking at lexicographic order (does the first string come after the second in the dictionary) but I'm not sure |
15:54:41 | * | bjz joined #nim |
15:56:29 | * | themagician joined #nim |
15:58:13 | * | gokr quit (Read error: Connection reset by peer) |
16:00:37 | * | libman quit (Read error: Connection reset by peer) |
16:04:38 | * | Trustable joined #nim |
16:08:49 | * | MyMind quit (Quit: WeeChat 1.5-dev) |
16:09:31 | * | simplyianm_ quit (Quit: Connection closed for inactivity) |
16:11:14 | planhths | I am asking bc this gives garbage: max(["beggh", "bo", "az", "asdfch"]) |
16:11:44 | planhths | Am I doing something wrong? |
16:14:02 | * | brson joined #nim |
16:16:36 | dom96 | planhths: what do you mean it gives garbage? |
16:18:06 | * | libman joined #nim |
16:22:19 | planhths | it outputs "bo" |
16:22:40 | planhths | sry I am learning |
16:23:29 | dom96 | Alphabetically "bo" is the maximum |
16:24:28 | * | yglukhov quit (Ping timeout: 264 seconds) |
16:25:19 | planhths | hows that really? |
16:26:11 | BlaXpirit | planhths, ever look in the dictionary? |
16:26:31 | * | space-wizard joined #nim |
16:26:34 | planhths | oh thanks I got it |
16:28:37 | planhths | I rewrote max procedure so it compares len(s) |
16:29:22 | BlaXpirit | planhths, check this out http://blaxpirit.com/blog/9/sort-by-min-by-max-by-in-nim.html |
16:29:42 | BlaXpirit | funny how my only article about nim happens to be relevant |
16:29:42 | * | libman quit (Read error: Connection reset by peer) |
16:31:17 | planhths | nice, I will try to understand it |
16:31:55 | dom96 | BlaXpirit: That can't be a coincidence, it must be a sign, you need to write more articles about Nim ;) |
16:34:11 | planhths | BlaXpirit: so you redifine the proc '<', which is used by min and max? |
16:34:16 | BlaXpirit | yes |
16:34:30 | BlaXpirit | planhths, and by using the block, the redefined proc is limited to that scope |
16:41:51 | planhths | I love nim so far cause I can look at the source and learn more stuff, while I can't do that in python! |
16:47:54 | * | fastrom joined #nim |
16:48:21 | * | libman joined #nim |
16:48:43 | FreezerburnV | planhths, You can definitely read Python's source code. Both the modules implemented in Python and the interpreter implemented in C (though understanding the interpreter is a much more difficult task). I guess it's just not as convenient since you can go directly to Nim source from the docs |
16:49:04 | FreezerburnV | (which is super nice, I love being able to do that and I wish more docs had that feature) |
16:50:26 | planhths | yes and it doesn't offer much for me, that I want to learn python not c for example |
16:55:11 | * | fredrik92 quit (Ping timeout: 250 seconds) |
16:58:52 | * | brechtm joined #nim |
17:05:52 | * | hendi quit (Ping timeout: 252 seconds) |
17:12:50 | * | PMunch quit (Quit: leaving) |
17:20:05 | * | Trustable quit (Remote host closed the connection) |
17:28:59 | * | fredrik92 joined #nim |
17:31:11 | * | brechtm quit (Remote host closed the connection) |
17:31:23 | * | yglukhov joined #nim |
17:35:40 | * | yglukhov quit (Ping timeout: 244 seconds) |
17:43:28 | * | shodan45 joined #nim |
17:49:31 | * | GustavoLapasta joined #nim |
17:51:42 | GustavoLapasta | Hello gentlemen, sorry to reiterate this but in all the windows machines I tried when I import pdcurses I obtain the error: |
17:51:45 | GustavoLapasta | e:\nim\lib\wrappers\pdcurses.nim(43, 10) Error: cannot open 'windows' |
17:51:55 | GustavoLapasta | bug or feature? |
17:53:26 | * | nsf quit (Quit: WeeChat 1.5) |
17:55:10 | FreezerburnV | GustavoLapasta, Looks like a bug? Nim standard library has a "winlean" module now, whereas it seems it previously had a "windows" module. That code should probably have been updated to import winlean |
17:55:23 | FreezerburnV | You can probably modify the code locally, see if it works, and then open a pull request |
17:55:53 | FreezerburnV | It's in: $NIMGITREPO/lib/wrappers/pdcurses.nim |
17:56:06 | GustavoLapasta | yeah I did substitute windows with winlean, and I obtain different errors |
17:56:18 | FreezerburnV | Like what? |
17:56:56 | GustavoLapasta | e:\nim\lib\wrappers\pdcurses.nim(565, 66) Error: undeclared identifier: 'MOUSE_STATUS' |
17:57:46 | GustavoLapasta | plus, the fact that the pdcurses module is not listed in the official documentation makes me wonder if it's even usable. |
17:59:47 | FreezerburnV | Good question |
18:00:48 | FreezerburnV | It's not a pure nim lib anyway. You might consider using the terminal module, or not attempting to control a windows terminal in such a way (I'm not sure if you can even control a windows terminal in a similar way to unix...) |
18:01:09 | FreezerburnV | (I can't think of anything that does do that) |
18:02:15 | FreezerburnV | What's your use case? Trying to build a terminal application that's cross platform and acts like a standard curses application? |
18:05:53 | GustavoLapasta | I was just studying the nim sources and found this curses module. I just wanted to try it for the fun of it. |
18:06:26 | FreezerburnV | Aaah, cool :) |
18:07:25 | FreezerburnV | Well you can always attempt to fix up the module so that it works |
18:07:27 | dom96 | GustavoLapasta: nimble install windows |
18:07:34 | * | yglukhov joined #nim |
18:07:44 | dom96 | that wrapper should be removed from the stdlib and put into a nimble package |
18:08:23 | GustavoLapasta | I see |
18:08:40 | FreezerburnV | Even more ambitious: convert the PDCurses code to Nim so that it can be marked as a pure lib :D |
18:10:05 | GustavoLapasta | that'd be a good exercise |
18:11:05 | FreezerburnV | dom96, Why is winlean part of the stdlib but windows not? Shouldn't there be a single module, and if it should be in nimble, then put into the official packages section or something? |
18:11:50 | FromGitter | <cheatfate> @endragor please explain more, because now it looks like your trying to adopt asyncdispatch in wrong way |
18:11:54 | dom96 | FreezerburnV: because windows is a huge module and so it take a long time to process by the compiler. |
18:12:10 | dom96 | Even though only like 5% of it is used |
18:12:19 | FreezerburnV | dom96, Gotcha |
18:12:21 | dom96 | so winlean holds this 5% instead |
18:12:27 | dom96 | and windows was no longer needed in the stdlib |
18:14:10 | * | yglukhov quit (Ping timeout: 265 seconds) |
18:15:28 | * | chemist69 quit (Ping timeout: 264 seconds) |
18:16:13 | FromGitter | <cheatfate> @endragor @endragor ⏎ > not yet, unfortunately. How exactly will `await` help given that `send` gets invoked from different stacks? `await` guarantees ordering within the same `{.async.}` procedure invocation. |
18:16:23 | FromGitter | <cheatfate> oops sorry |
18:17:12 | FromGitter | <cheatfate> until you are single threaded, `await` will guarantee ordering not only withing same {.async.} |
18:19:38 | * | chemist69 joined #nim |
18:34:56 | * | retropikzel quit (Quit: Leaving) |
18:48:15 | * | Matthias247 quit (Read error: Connection reset by peer) |
18:49:06 | * | yglukhov joined #nim |
18:58:31 | FromGitter | <endragor> @cheatfate thanks for joining! I've added queueing on app level, it's few lines of code and works perfectly. Having explicit queue actually provides few benefits anyway. I've also opened 3 PRs with fixes to *nix part of upcoming/asyncdispatch, please take a look. ⏎ as I mentioned, I don't need ordering in how independent connections are processed - they are persistent and messages may come at any time. but separate clients may cause |
18:58:31 | FromGitter | ... messages to be sent to the same destination at the same time. if you want, you could show pseudocode of how you see that working with `await`, but I don't see it at the moment. |
19:00:00 | FromGitter | <cheatfate> currently i'm looking at https://github.com/nim-lang/Nim/pull/4697/commits/668987bcae86254f7d89065ac667e6a7e11dddeb |
19:00:24 | FromGitter | <cheatfate> and looks like you trying to add more bugs |
19:01:12 | FromGitter | <endragor> well, that was a bug that exists in upcoming/asyncdispatch but doesn't exist in the current asyncdispatch. why do you think the fix is wrong? |
19:01:33 | FromGitter | <cheatfate> i dont understand where is bug |
19:01:54 | FromGitter | <cheatfate> now i see only new bug which cause deadlock on BSD and Windows |
19:02:50 | FromGitter | <cheatfate> Please make more detailed explanation |
19:04:03 | FromGitter | <endragor> that code is not invoked on Windows (or is it?). user-defined callback may close socket by calling `closeSocket`. in that case `updateHandle` will raise AssertionError. Simple way to reproduce is sth like: ⏎ ```let sock = await server.accept() ⏎ server.closeSocket() ⏎ asyncCheck sock.send("foo")``` [https://gitter.im/nim-lang/Nim?at=57c9cd2329ee4a670588cf3b] |
19:04:03 | * | libman quit (Read error: Connection reset by peer) |
19:06:03 | FromGitter | <cheatfate> And `updateHandle` is right! |
19:06:10 | * | yglukhov_ joined #nim |
19:06:31 | FromGitter | <cheatfate> you closed socket and trying to do send operation after it, this is programmer's mistake |
19:06:47 | FromGitter | <cheatfate> So `AssertionError` is raised |
19:06:48 | * | yglukhov quit (Ping timeout: 276 seconds) |
19:07:07 | FromGitter | <endragor> I'm sending to another socket |
19:07:34 | FromGitter | <endragor> you could do any other async operation there, it doesn't matter. what matters is that the callback of `accept` closed the server socket. |
19:08:39 | FromGitter | <endragor> that could happen with any other socket - callback of send/recv may close the socket, and the same error will occur. |
19:08:51 | FromGitter | <cheatfate> but sock.send("foo") will never be called, because it was called via asyncCheck |
19:08:59 | ldlework | Wow this gitter thing isn't obnoxious at all. |
19:09:53 | FreezerburnV | ldlework, Seems fine to me. The user is clearly stated in <...>. And all we're doing is seeing the actual activity of people discussing stuff |
19:10:18 | dom96 | I wonder if we could write a script for our IRC clients to detect bots such as FromGitter |
19:10:34 | dom96 | and transform their messages into something more friendly |
19:10:36 | ldlework | Except my client doesn't colorize interloctors in a quote |
19:11:00 | dom96 | interloctors? |
19:11:35 | ldlework | people in a conversation |
19:11:52 | dom96 | oh |
19:11:53 | FromGitter | <endragor> @cheatfate why? asynccheck simply adds callback that throws. the last line doesn't really matter much in that sample, I think the bug will occur with just the first two lines. I'll build a sample in a moment if you'd like |
19:12:12 | * | space-wizard quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
19:12:27 | FromGitter | <cheatfate> ok i have found error, but your patch is wrong, need to do this in another way |
19:12:56 | FromGitter | <cheatfate> asynccheck not call poll() so send() operation will never become ready... so it never send... |
19:13:06 | FreezerburnV | ldlework, I recommend modifying how things get displayed so that <username> is shown bold. Mine is doing that by default and it helps distinguish who the user is that typed the message |
19:13:19 | ldlework | But not from each other |
19:13:32 | FromGitter | <endragor> @cheatfate yeah, poll is missing in that sample. I wasn't sure about the fix, too, so please make another PR if you think it's wrong. |
19:13:41 | ldlework | Which is the pain. And yeah, I'm going to spend time customizing my client for that.. |
19:13:47 | dom96 | ldlework: maybe you could ask BlaXpirit nicely to add colors to the nicknames |
19:14:02 | BlaXpirit | dom96, the irc colors are ugly and limited, people won't like it |
19:14:27 | dom96 | Pretty sure that most IRC clients use the IRC colors to color nicks |
19:14:49 | BlaXpirit | do they? i have nice shades of blue, anyway |
19:14:52 | FromGitter | <cheatfate> i need to go, will come later |
19:14:56 | dom96 | I think so |
19:15:03 | BlaXpirit | maybe you're right |
19:15:12 | ldlework | My IRC client is 256 color capable |
19:15:38 | dom96 | ldlework: what IRC client are you using? |
19:15:49 | ldlework | weechat |
19:15:58 | FreezerburnV | Wait so colorizing the usernames differently is normal? Mine just uses one color for other people and another color for myself. I think I saw an IRC client that changed the username colors and it felt hard to read |
19:16:15 | FreezerburnV | (that might have been a fault of the colors chosen for usernames) |
19:16:24 | dom96 | FreezerburnV: Well, it's subjective :) |
19:16:32 | flyx | mine (Textual) has a different color for each user |
19:16:32 | ldlework | Everyone gets a different color here. It makes understanding the progression of discourse a lot easier. |
19:16:40 | FreezerburnV | dom96, Yep, which is why I didn't say my way was better |
19:16:57 | ldlework | "it felt hard to read" is an evaluation |
19:17:09 | FreezerburnV | From my perspective, not yours |
19:17:22 | FreezerburnV | Clarified with bad color choice |
19:17:24 | ldlework | "its better" would be too. what distinction are you drawing? |
19:17:29 | flyx | hmm, these discussions about the Gitter bridge do quite pollute the channel |
19:17:54 | dom96 | flyx: true, but it's not like this channel would be busy otherwise... |
19:18:04 | ldlework | haha |
19:18:10 | flyx | feels like bikeshedding |
19:18:28 | flyx | more on topic: shouldn't newStringStream be supported for JS? |
19:18:35 | FreezerburnV | Honestly, i don't really care what gets done. I prefer having the bridge, even if it looks bad to some people, than not, so that we can always see all discussion |
19:18:39 | dom96 | flyx: yes, it should |
19:18:42 | flyx | I get a compilation error that says it is not known |
19:19:20 | flyx | ah well. I pulled the latest devel, not I get a SIGSEGV |
19:19:20 | dom96 | flyx: by that I don't necessarily mean that I expect it to work, just that it should be fixed to work if it doesn't |
19:19:21 | * | hendi joined #nim |
19:19:30 | ldlework | FreezerburnV: you could log in to gitter |
19:20:11 | dom96 | we can always have the bridge somewhere else, like #nim-gitter or something |
19:20:22 | * | krux02 joined #nim |
19:20:22 | FreezerburnV | ldlework, I like using the IRC client, and the current way gitter messages get shown is perfectly fine to me. Also gitter spams emails when you don't read messages, which is annoying |
19:20:46 | dom96 | if people really get that annoyed by it, but for now I'm sure you can survive :P |
19:20:55 | ldlework | FreezerburnV: just explaining how we don't need to suffer for your desires |
19:21:24 | BlaXpirit | FreezerburnV, emails can be disables |
19:21:38 | flyx | um, current devel seems to be completely broken |
19:21:46 | FromGitter | <endragor> FreezerburnV: it hasn't ever spammed anything to my email. perhaps it sends private messages when you're offline? but I'd find that useful. |
19:21:49 | flyx | I'll better create an issue |
19:21:59 | BlaXpirit | dom96, having the bridge somewhere else? you'll end up with people who just stay in that channel |
19:22:15 | * | libman joined #nim |
19:22:21 | FreezerburnV | BlaXpirit, I'll have to log in temporarily to do that |
19:22:21 | dom96 | flyx: hrm, how so? |
19:22:37 | * | yglukhov_ quit (Ping timeout: 258 seconds) |
19:22:39 | FreezerburnV | @endragor: It emails me every day that I have 99 unread message in a channel I was in for a couple days. it's annoying |
19:22:41 | flyx | dom96: I get a SIGSEGV from the compiler whenever I try to run the NimYAML tests |
19:22:55 | dom96 | flyx: does it compile hello world? |
19:23:05 | dom96 | if yes then it's not "completely broken" :) |
19:23:18 | flyx | well |
19:23:22 | FromGitter | <endragor> FreezerburnV: hmm, not sure. as I said, I've never got such emails. perhaps there is a setting. |
19:23:28 | flyx | it is completely broken for NimYAML |
19:23:29 | flyx | :) |
19:23:52 | flyx | I meant „completely broken“ to distinguish from „only JS backend fails“ |
19:24:23 | dom96 | I see |
19:24:30 | FreezerburnV | @endragor: Might have defaulted to on with a newer account, and having an older account defaulted it to off because it wasn't implemented when your account was created? Dunno. Or maybe I hit a toggle somewhere when signing up. Either way it seems silly to keep pestering me when I obviously havent' kept up with that channel for a while |
19:24:41 | dom96 | BlaXpirit: Yeah, the bridge is here to stay. |
19:24:55 | dom96 | Unless there is push back from enough users (sorry ldlework) |
19:26:04 | flyx | I'll bisect it |
19:27:26 | dom96 | TIL when you press Shift + Volume Up/Down on a MBP it makes a noise to tell you how loud the volume is now. |
19:34:58 | flyx | dom96: and option+shift increases by smaller intervals ;) |
19:35:55 | dom96 | :o |
19:35:59 | flyx | here's my issue: https://github.com/nim-lang/Nim/issues/4699 |
19:36:42 | dom96 | Poor Araq won't be happy to hear that he introduced a regression. |
19:37:56 | flyx | at least it won't make its way into 0.15.0 |
19:38:19 | * | yglukhov joined #nim |
19:40:42 | * | space-wizard joined #nim |
19:45:57 | flyx | it seems like newStringStream was defined for JS in master, but moved into a `when not defined(js)` on devel |
19:46:16 | * | FreezerburnV quit (Quit: Leaving) |
19:48:01 | flyx | well, this one removed it: https://github.com/nim-lang/Nim/commit/0d45c1738807f585ffa4004800fba1328f8bddd8 |
19:48:36 | flyx | couldn't copyMem simply be replace by a more mundane copy procedure in JS? |
19:50:41 | flyx | or is `pointer` itself not supported by JS? |
19:52:36 | * | stisa joined #nim |
19:53:36 | * | Sergio965 quit (Ping timeout: 276 seconds) |
19:56:24 | flyx | hmm, it seems to work |
19:56:41 | flyx | can I create a cstring given a char pointer and a length? |
20:01:08 | dom96 | cstring is just a pointer to a null-terminated array of chars |
20:02:11 | flyx | I am wondering how one could implement StringStream for JS without copyMem |
20:02:26 | flyx | I'd need some way of transforming a pointer to a character and a length to a string |
20:03:30 | * | libman quit (Read error: Connection reset by peer) |
20:06:08 | * | golak joined #nim |
20:06:12 | * | golak quit (Client Quit) |
20:17:44 | * | yglukhov quit (Ping timeout: 260 seconds) |
20:21:04 | * | libman joined #nim |
20:26:21 | * | Sergio965 joined #nim |
20:33:30 | * | yglukhov joined #nim |
20:35:52 | * | Sergio965 quit (Ping timeout: 240 seconds) |
20:39:24 | * | yglukhov_ joined #nim |
20:39:39 | * | yglukhov quit (Ping timeout: 250 seconds) |
20:46:02 | * | Sergio965 joined #nim |
20:51:27 | * | dddddd quit (Read error: Connection reset by peer) |
20:52:15 | * | dddddd joined #nim |
20:52:15 | * | libman quit (Remote host closed the connection) |
20:57:41 | krux02 | can I concatenate an identifier with another one in a template, like I can concatenate identifiers in C macros? |
20:57:51 | krux02 | I know I can do it in macros |
20:59:17 | krux02 | @flyx you can not use a sized string in a context where a null terminated string is expected |
20:59:23 | krux02 | it's just a different type |
20:59:27 | BlaXpirit | krux02, http://nim-lang.org/docs/manual.html#templates-identifier-construction |
21:00:02 | BlaXpirit | welp, it hasnt improved a bit since i last complained about it |
21:00:40 | krux02 | is it broken? |
21:00:50 | BlaXpirit | krux02, depending on your perspective... |
21:01:17 | krux02 | I don't want trouble in the future |
21:01:20 | BlaXpirit | same thing can mean either bare text or a variable depending on whether the variable has been defined or not |
21:01:30 | * | pafmaf quit (Quit: Leaving) |
21:01:37 | BlaXpirit | you're fine, it's isolated to your own template, just unpleasant |
21:01:46 | krux02 | ah yea that stuff, it not nice |
21:02:31 | krux02 | when I use quote do: I always `backtick` my identifiers that are from an outer scope |
21:02:42 | krux02 | but sometimes nim is weird |
21:02:58 | krux02 | I have to be sure not to have clashing identifiers in my macros |
21:03:07 | krux02 | a lot of posfix and suffix does the job |
21:04:12 | dom96 | krux02: what macros are you creating? |
21:04:33 | dom96 | it sounds to me like you maybe should be using genSym |
21:05:54 | krux02 | dom96: no, I am costructing explicitly visible Identifiers |
21:06:15 | krux02 | I wanted to port the OpenMesh datastructure to Nim |
21:06:33 | krux02 | it is a datastructure used at my university, and it is highly generic |
21:07:05 | dom96 | hrm, why do you need so many identifiers? Can't you let the user specify the names to ensure they don't clash? |
21:07:06 | krux02 | but I am not 100% happy how it is implemented in c++, so I am not wrapping, I am writing a macro that does everything |
21:07:38 | krux02 | The User defines One Identifier, and all other identifiers are inferred from that |
21:07:50 | krux02 | I have a macro to create a 3D mesh type |
21:08:28 | krux02 | I tried to do it with generics and other things, but in the end I realized it is best, when the mesh type is entirely created in a macro |
21:09:09 | krux02 | here is an example: |
21:09:12 | krux02 | createMeshType(MyMeshType): |
21:09:12 | krux02 | type |
21:09:12 | krux02 | VertexData = object |
21:09:12 | krux02 | point : Vec4f |
21:09:12 | krux02 | normal : Vec4f |
21:09:12 | krux02 | color : Vec4f |
21:09:14 | krux02 | texCoord : Vec2f |
21:09:18 | krux02 | FaceData = object |
21:09:20 | krux02 | normal : Vec3f |
21:09:22 | krux02 | color : Vec3f |
21:09:23 | BlaXpirit | oh boy |
21:09:26 | krux02 | HalfedgeData = object |
21:09:28 | krux02 | someValue : int32 |
21:09:52 | krux02 | yea I am a bit amazed by what I can do with nim macros |
21:10:13 | krux02 | in the past there was so much limitation and frustration, because I could not abstract the things I wanted to abstract |
21:10:24 | krux02 | now it possible and I can go a bit crazy with it |
21:10:53 | krux02 | I would like to have a mesh datastructure to load arbitrary 3D models |
21:11:36 | dom96 | krux02: please use gist next time |
21:11:56 | krux02 | and then I would like to put it in my OpenGL sandbox which wants to be something like Processing/OpenFrameworks/Cinder |
21:12:48 | krux02 | dom96: is posting 12 lines of code too much to post in irc? |
21:12:56 | dom96 | yes |
21:13:01 | krux02 | ok |
21:13:19 | dom96 | 3 is max |
21:13:21 | krux02 | didn't know I thought for small samples of code it is ok |
21:15:21 | * | Trustable joined #nim |
21:15:27 | * | Demon_Fox_ joined #nim |
21:15:41 | * | Demon_Fox quit (Disconnected by services) |
21:15:44 | * | Demon_Fox_ is now known as Demon_Fox |
21:16:23 | krux02 | Is there insterest here in creative coding in Nim? |
21:18:00 | krux02 | or at least what the Processing/Cinder/OpenFrameworks community calls creative coding |
21:20:24 | federico3 | weird |
21:20:48 | krux02 | what is weird? |
21:21:34 | * | hendi quit (Ping timeout: 240 seconds) |
21:41:49 | * | GustavoLapasta quit (Quit: Leaving) |
21:43:25 | * | yglukhov_ quit (Remote host closed the connection) |
21:47:24 | * | themagician quit () |
21:50:55 | * | xet7 quit (Remote host closed the connection) |
21:55:01 | * | irrequietus joined #nim |
21:56:56 | * | Trustable quit (Remote host closed the connection) |
21:58:39 | * | abruanese quit (Quit: ZNC 1.6.3+deb1 - http://znc.in) |
22:00:02 | * | planhths quit (Quit: Konversation terminated!) |
22:06:02 | * | Matthias247 joined #nim |
22:06:49 | * | Jesin quit (Quit: Leaving) |
22:12:16 | * | abruanese joined #nim |
22:28:38 | * | stisa quit (Quit: quitting...) |
22:29:03 | * | PMunch joined #nim |
23:03:21 | * | kulelu88 joined #nim |
23:07:29 | * | kulelu88 quit (Client Quit) |
23:14:34 | * | Kaini quit (Remote host closed the connection) |
23:16:08 | * | Kaini joined #nim |
23:17:15 | * | Satyajit quit (Quit: https://fnordserver.eu) |
23:22:14 | * | rtr_ quit (Remote host closed the connection) |
23:32:34 | * | brson quit (Ping timeout: 240 seconds) |
23:40:05 | * | space-wizard quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
23:50:44 | * | brson joined #nim |
23:52:43 | * | PMunch quit (Quit: leaving) |