| 00:09:55 | * | PMunch quit (Quit: leaving) |
| 00:18:09 | * | aziz quit (Quit: Ex-Chat) |
| 00:18:31 | * | themagician quit () |
| 00:25:42 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:30:32 | vktec | What's the easiest way to run and interface with NimScript? I've been poking around in compiler/scriptconfig.nim, etc. but nothing is working |
| 00:32:06 | * | yglukhov joined #nim |
| 00:36:40 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 00:38:12 | Araq | vktec: look at how nimble does it |
| 00:43:17 | * | dmi0 quit (Ping timeout: 248 seconds) |
| 00:50:08 | * | lyro quit (Ping timeout: 252 seconds) |
| 00:50:47 | * | lyro joined #nim |
| 00:58:35 | * | Demos_ joined #nim |
| 01:02:19 | * | Demos quit (Ping timeout: 268 seconds) |
| 01:02:24 | * | Demos__ joined #nim |
| 01:05:24 | * | Demos_ quit (Ping timeout: 268 seconds) |
| 01:09:57 | * | Varriount|Phone quit (Read error: Connection reset by peer) |
| 01:14:19 | * | yglukhov joined #nim |
| 01:18:40 | * | yglukhov quit (Ping timeout: 250 seconds) |
| 01:31:12 | * | Varriount|Phone joined #nim |
| 01:42:24 | * | dmi0 joined #nim |
| 01:54:56 | * | libman quit (Quit: Leaving.) |
| 01:56:43 | * | yglukhov joined #nim |
| 02:01:15 | * | yglukhov quit (Ping timeout: 252 seconds) |
| 02:04:46 | * | krux02 quit (Remote host closed the connection) |
| 02:28:48 | * | xet7 quit (Quit: Leaving) |
| 02:29:04 | * | dmi0 quit (Ping timeout: 260 seconds) |
| 02:29:05 | * | dmi00 joined #nim |
| 02:35:34 | * | xet7 joined #nim |
| 02:38:59 | * | yglukhov joined #nim |
| 02:40:37 | * | dddddd quit (Ping timeout: 240 seconds) |
| 02:41:17 | * | chemist69 quit (Ping timeout: 250 seconds) |
| 02:42:38 | * | vendethiel joined #nim |
| 02:43:34 | * | yglukhov quit (Ping timeout: 256 seconds) |
| 02:49:18 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 02:50:23 | * | dmi00 quit (Ping timeout: 252 seconds) |
| 02:52:42 | * | Demos__ quit (Ping timeout: 268 seconds) |
| 02:53:37 | * | kulelu88 quit (Quit: Leaving) |
| 02:54:48 | * | chemist69 joined #nim |
| 03:06:53 | * | dmi00 joined #nim |
| 03:13:56 | * | Varriount|Phone left #nim ("AndroIRC") |
| 03:18:06 | * | dmi00 quit (Ping timeout: 246 seconds) |
| 03:21:26 | * | yglukhov joined #nim |
| 03:25:54 | * | yglukhov quit (Ping timeout: 250 seconds) |
| 03:26:09 | * | Demos joined #nim |
| 03:27:32 | * | rynsin joined #nim |
| 03:29:06 | * | rynsin quit (Client Quit) |
| 03:30:09 | * | wuehlmaus quit (Ping timeout: 265 seconds) |
| 03:33:09 | * | rynsin joined #nim |
| 03:36:28 | * | cheatfate quit (Ping timeout: 250 seconds) |
| 03:37:54 | * | wuehlmaus joined #nim |
| 03:38:17 | * | wuehlmaus is now known as Guest16254 |
| 03:53:16 | * | Guest16254 quit (Ping timeout: 256 seconds) |
| 04:00:55 | * | rynsin quit (Quit: rynsin) |
| 04:03:20 | * | rynsin joined #nim |
| 04:03:21 | * | rynsin quit (Client Quit) |
| 04:03:48 | * | yglukhov joined #nim |
| 04:04:57 | * | rynsin joined #nim |
| 04:04:57 | * | rynsin quit (Client Quit) |
| 04:05:29 | * | rynsin joined #nim |
| 04:07:23 | * | rynsin quit (Client Quit) |
| 04:09:03 | * | cheatfate joined #nim |
| 04:10:24 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 04:14:40 | * | rynsin joined #nim |
| 04:29:53 | * | wuehlmau1 joined #nim |
| 04:35:46 | * | rynsin quit (Quit: rynsin) |
| 04:37:19 | * | rynsin joined #nim |
| 04:37:19 | * | rynsin quit (Client Quit) |
| 04:37:54 | * | rynsin joined #nim |
| 04:38:07 | * | rynsin quit (Client Quit) |
| 04:38:54 | * | rynsin joined #nim |
| 04:38:55 | * | rynsin quit (Client Quit) |
| 04:39:37 | * | rynsin joined #nim |
| 04:39:43 | * | rynsin quit (Client Quit) |
| 04:42:06 | * | rynsin joined #nim |
| 04:42:07 | * | rynsin quit (Client Quit) |
| 04:42:48 | * | rynsin joined #nim |
| 04:42:55 | * | rynsin quit (Client Quit) |
| 04:46:11 | * | yglukhov joined #nim |
| 04:46:53 | * | brson quit (Quit: leaving) |
| 04:50:32 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 05:28:31 | * | yglukhov joined #nim |
| 05:32:52 | * | yglukhov quit (Ping timeout: 250 seconds) |
| 05:57:08 | * | nsf joined #nim |
| 06:01:02 | * | chemist69 quit (Ping timeout: 250 seconds) |
| 06:01:48 | * | desophos quit (Quit: Leaving) |
| 06:03:17 | * | cheatfate quit (Ping timeout: 240 seconds) |
| 06:03:37 | * | yglukhov joined #nim |
| 06:03:57 | * | cheatfate joined #nim |
| 06:07:58 | * | yglukhov quit (Ping timeout: 250 seconds) |
| 06:20:58 | * | chemist69 joined #nim |
| 06:29:02 | * | djellemah quit (Remote host closed the connection) |
| 06:30:57 | * | djellemah joined #nim |
| 06:49:46 | * | yglukhov joined #nim |
| 07:03:19 | * | yglukhov quit (Remote host closed the connection) |
| 07:20:02 | * | space-wizard quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 07:22:52 | * | space-wizard joined #nim |
| 07:24:09 | * | bjz joined #nim |
| 07:27:28 | * | space-wizard quit (Ping timeout: 265 seconds) |
| 07:30:10 | * | bjz quit (Ping timeout: 252 seconds) |
| 07:32:24 | * | bjz joined #nim |
| 07:36:17 | * | bjz quit (Read error: Connection reset by peer) |
| 07:55:55 | * | bjz joined #nim |
| 07:56:18 | * | vqrs quit (Ping timeout: 250 seconds) |
| 07:59:03 | * | Trustable joined #nim |
| 07:59:15 | * | vqrs joined #nim |
| 08:05:17 | * | yglukhov joined #nim |
| 08:05:32 | * | yglukhov quit (Remote host closed the connection) |
| 08:05:46 | * | yglukhov joined #nim |
| 08:05:48 | * | yglukhov quit (Remote host closed the connection) |
| 08:16:11 | * | Arrrr joined #nim |
| 08:18:09 | Arrrr | I'm used to name modules after a type. For example, the module "Party" would contain an object called "Party". But after some research, it seems like the nim community favors lowercase for module names. |
| 08:18:14 | Arrrr | Am i on the wrong side of history? |
| 08:19:36 | * | dyce[m] joined #nim |
| 08:24:19 | Araq | no, that's correct |
| 08:25:13 | Arrrr | Ok, but then i noticed that, when i import Party, it is actually imported as "party". |
| 08:25:25 | * | Andris_zbx joined #nim |
| 08:25:40 | Arrrr | the full reference to the object would be "party.Party" |
| 08:33:27 | * | couven92 joined #nim |
| 08:35:28 | Araq | actually the convention is plural for module names, so it would be parties.Party |
| 08:37:06 | * | rokups joined #nim |
| 08:40:17 | Arrrr | Are you going to change that in the future? |
| 08:41:09 | * | chemist69 quit (Ping timeout: 246 seconds) |
| 08:44:53 | * | rynsin joined #nim |
| 08:45:12 | * | rynsin quit (Read error: Connection reset by peer) |
| 08:45:27 | Araq | why? |
| 08:47:37 | Araq | tables, lists, strutils, times -- you think we'll change these module names? |
| 08:49:46 | Arrrr | I don't you if you will, but i think you should. Maybe for the first three there is no need. But if i want to name a module, seems way simpler to use the same name as the moduel. Takes less keystrokes and is more consistent which what you will find inside. |
| 08:50:06 | Arrrr | For me this is an issue if you want to program across operating systems |
| 08:50:29 | Araq | filenames all lowercase is pretty standard on Unix... |
| 08:50:53 | Arrrr | Yes, but not on windows. |
| 08:51:43 | Araq | on Windows it doesn't matter |
| 08:54:10 | Arrrr | Because it doesn't matter, i guess there is an inclination to use PascalCase, as it happens in Java or C#. |
| 08:54:35 | Arrrr | Even if you program nim in linux, i don't think it should change. |
| 08:56:04 | Araq | you lost me. What problem do you see? |
| 08:56:30 | Araq | I'm pretty sure I have seen PascalCase.nim on Linux and it worked. |
| 08:58:16 | Arrrr | No, you cannot import PascalCase and then call PascalCase(), it thinks you are referring to the module |
| 08:58:34 | Arrrr | But that actually works on windows |
| 09:01:00 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:01:04 | Araq | well that's a bug then |
| 09:05:32 | * | bjz joined #nim |
| 09:09:04 | * | chemist69 joined #nim |
| 09:20:16 | * | chemist69 quit (Ping timeout: 260 seconds) |
| 09:23:23 | euantor | THings like `tables` and `strutils` make sense as plural to me, because they don't define a singular type or proc |
| 09:26:31 | * | Demos quit (Ping timeout: 258 seconds) |
| 09:28:04 | * | brechtm_ quit (Remote host closed the connection) |
| 09:28:41 | * | brechtm joined #nim |
| 09:32:13 | * | bjz quit (Ping timeout: 260 seconds) |
| 09:38:30 | * | chemist69 joined #nim |
| 09:38:58 | * | bjz joined #nim |
| 09:45:41 | * | rynsin joined #nim |
| 09:50:16 | * | rynsin quit (Ping timeout: 256 seconds) |
| 09:59:27 | cheatfate | Something wrong with windows console after last PR |
| 09:59:43 | cheatfate | all symbols becomes red for me |
| 10:02:19 | FromGitter | <endragor> @cheatfate have you tried to build upcoming asyncdispatch with mingw on Windows? Seems ws2_32.lib couldn't be found out of the box by the linker. Are there additional steps that need to be done? |
| 10:04:27 | cheatfate | endragor: current asyncdispatch also have this problem? |
| 10:07:03 | cheatfate | endragor: latest devel version was built |
| 10:07:08 | cheatfate | without problems |
| 10:07:41 | cheatfate | also i dont know any part of nim code which depends on ws2_32.lib because all functions are loaded via LoadLibrary |
| 10:08:42 | FromGitter | <endragor> yes, seeing this latest devel on Windows 10. There is `{.passL: "-lws2_32".}` in ioselectors_select.nim, but it seems mingw doesn't have the library included. It exists in Visual Studio folders |
| 10:11:11 | cheatfate | . |
| 10:11:40 | cheatfate | endragor: oh i see |
| 10:12:01 | cheatfate | but asyncdispatch must not use ioselectors on windows |
| 10:12:31 | cheatfate | how did you enabled it? :) |
| 10:13:18 | cheatfate | this part of ioselectors.nim if just for ioselectors.nim |
| 10:13:54 | cheatfate | upcoming asyncdispatch do not include ioselectors on windows because it uses IOCP not `select()`. |
| 10:15:37 | FromGitter | <endragor> hmm, let me see. btw there is this weird part: ⏎ ⏎ ```else: ⏎ import ioselectors ⏎ when defined(windows):``` ⏎ ⏎ defined(windows) will never yield `true` in that branch [https://gitter.im/nim-lang/Nim?at=583d554973abd79c55ad98dd] |
| 10:17:31 | cheatfate | ok my mingw works fine with tioselectors test so it find ws2_32.lib |
| 10:17:52 | FromGitter | <endragor> perhaps you added it manually or smth? it's not there in default installation |
| 10:18:08 | FromGitter | <endragor> and yeah, my project had direct import of `ioselectors` which caused that |
| 10:21:11 | * | arnetheduck joined #nim |
| 10:22:39 | euantor | Looks like Fedora 25 ships with a fixed version of libzip at last, so `zipfiles` now works for me rather than creating multi-volume archives all the time |
| 10:24:42 | * | space-wizard joined #nim |
| 10:27:52 | cheatfate | endragor: this is bug `import ioselectors` must be only in posix branch |
| 10:28:14 | cheatfate | endragor: could you please search for file in your mingw repo libws2_32.a |
| 10:29:23 | * | space-wizard quit (Ping timeout: 258 seconds) |
| 10:30:53 | FromGitter | <endragor> @cheatfate it's in posix branch, but that branch also checks for defined(windows) for some reason |
| 10:31:38 | cheatfate | endragor: my mingw gcc 4.8.3 and i have libws2_32.a by default |
| 10:33:11 | cheatfate | endragor: ahh i see, this is artifacts from current version of asyncdispatch |
| 10:34:13 | cheatfate | this constants needed by isDisconnectionError |
| 10:35:19 | cheatfate | this lines must be removed |
| 10:35:33 | cheatfate | but how your code imports ioselectors i dont understand |
| 10:40:41 | FromGitter | <endragor> as I said, I had a direct import in the project (removed now) |
| 10:41:29 | cheatfate | currently i can't make PR because my main PC is broken |
| 10:57:40 | * | themagician joined #nim |
| 11:04:17 | * | cheatfate quit (Ping timeout: 240 seconds) |
| 11:10:11 | * | byte512 joined #nim |
| 11:20:40 | * | Sentreen quit (Quit: WeeChat 1.4) |
| 11:20:59 | * | krux02 joined #nim |
| 11:21:18 | * | Sentreen joined #nim |
| 11:21:38 | * | dmi00 joined #nim |
| 11:26:11 | * | zevlg joined #nim |
| 11:36:07 | * | elrood joined #nim |
| 11:38:57 | * | Skydogg joined #nim |
| 11:45:10 | * | bjz_ joined #nim |
| 11:45:52 | * | bjz quit (Ping timeout: 260 seconds) |
| 11:48:16 | * | xet7 quit (Quit: Leaving) |
| 11:51:51 | * | Skydogg quit (Quit: Leaving) |
| 11:53:00 | * | xet7 joined #nim |
| 11:59:56 | * | brechtm_ joined #nim |
| 12:02:52 | * | brechtm quit (Ping timeout: 250 seconds) |
| 12:03:57 | * | shubhaml joined #nim |
| 12:06:32 | * | PMunch joined #nim |
| 12:12:02 | * | wuehlmau1 is now known as wuehlmaus |
| 12:12:12 | * | byte512 quit (Ping timeout: 246 seconds) |
| 12:17:23 | * | byte512 joined #nim |
| 12:27:15 | * | vlad1777d joined #nim |
| 12:33:00 | * | brechtm_ quit (Remote host closed the connection) |
| 12:33:35 | * | brechtm joined #nim |
| 12:35:39 | federico3 | any Nim at FOSDEM this time? |
| 12:37:38 | * | brechtm quit (Read error: Connection reset by peer) |
| 12:37:44 | * | brechtm_ joined #nim |
| 12:43:09 | * | yglukhov joined #nim |
| 12:46:53 | vktec | I've noticed that Nim rebuilds everything each time I run `nim c foo`. Is there a way to get it to only recompile stuff that's changed, like make does? |
| 12:47:37 | def- | vktec: it should do that, but Araq wanted to improve it, he posted on forum recently about it |
| 12:47:53 | vktec | I see |
| 12:48:18 | def- | http://forum.nim-lang.org/t/2624#16236 |
| 13:14:54 | * | Arrrr quit (Quit: WeeChat 1.5) |
| 13:22:15 | * | bjz_ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 13:24:48 | Sentreen | Is it normal that I cannot use imported functions in nimscript? |
| 13:25:15 | Sentreen | I got file a.nims and b.nim, when I try to use a as my build script, it complains about any value or proc I use that is defined in b. |
| 13:25:23 | Sentreen | The import itself does not trigger any error though. |
| 13:27:38 | * | chemist69 quit (Ping timeout: 258 seconds) |
| 13:28:33 | * | chemist69 joined #nim |
| 13:29:49 | Sentreen | Disregard the previous, turns out that I'm just retarded. |
| 13:33:32 | * | vlad1777d quit (Remote host closed the connection) |
| 13:40:49 | * | shubhaml quit (Ping timeout: 268 seconds) |
| 13:48:18 | * | vlad1777d joined #nim |
| 13:55:42 | * | Amun_Ra quit (Ping timeout: 250 seconds) |
| 13:57:54 | * | Amun_Ra joined #nim |
| 14:00:19 | * | nicanaca0 quit (Remote host closed the connection) |
| 14:00:55 | * | nicanaca0 joined #nim |
| 14:07:18 | * | vlad1777d quit (Remote host closed the connection) |
| 14:34:47 | * | Sembei joined #nim |
| 14:56:20 | FromGitter | <tekjar> Wow. Building nim compiler on target architecture directly is so straight forward. arm-gnu-eabihf in my case. Super impressed |
| 14:56:31 | FromGitter | <tekjar> Is that the case with other archs as well? Like mips |
| 15:23:37 | * | derlafff quit (Ping timeout: 260 seconds) |
| 15:35:22 | * | arnetheduck quit (Ping timeout: 250 seconds) |
| 15:40:05 | * | derlafff joined #nim |
| 15:45:52 | wuehlmaus | i was impressed building nim myself 2 days ago. It IS fast. Compare this to the building of rust e.g. :) |
| 15:47:27 | wuehlmaus | go builds fast, too. I think this is an improved way to quite some programming languages. |
| 15:48:38 | * | cheatfate joined #nim |
| 15:54:35 | * | derlafff quit (Remote host closed the connection) |
| 15:56:05 | * | derlafff joined #nim |
| 15:56:09 | FromGitter | <tekjar> Advantage of having a c backend maybe |
| 15:58:57 | elrood | actually that is what's really impressive about nim's building speed, considering that it's not only the nim compiler being invoked but also another completely independent c compiler toolchain with its own lexing and parsing and optimizing stages, and it still compiles pretty quickly |
| 16:03:16 | elrood | eg. go and d, at least in their reference implementations, aren't actually slow either, but then they don't have that extra overhead, and their optimizers aren't as mature as what the common choices of c compilers provide |
| 16:05:16 | elrood | if someone's searching for a blog topic, is into benchmarking and not averse to promoting nim.. |
| 16:10:56 | flyx | elrood: isn't the Go compiler just a GCC frontend? |
| 16:12:26 | flyx | elrood: ah well, one of the implementations is. D also has a GCC frontend. so they basically use the same optimization backend as C with GCC |
| 16:12:29 | elrood | iirc there are (at least) two implementations, one building upon gcc and a reference one independent from it |
| 16:13:11 | flyx | but what Nim outputs may be more suited for further optimization than some manually written C code is |
| 16:13:29 | elrood | for d there are (again, at least) 3, the reference builing on digitalmars' c compiler backend, a llvm-based one, and one using gcc's infrastructure |
| 16:16:31 | flyx | yeah. I'd just point out, it is possible with Go and D to use the same optimizer as C gets in GCC |
| 16:19:25 | elrood | yep, at the cost of compilation speed though, gdc and gccgo aren't quite as fast as the reference implementations |
| 16:22:34 | elrood | i don't recall having seen any profound benchmarks on compilation speed, but i'd bet nim would compare quite favourably despite having the extra (and somewhat superfluous) overhead and utilizing the same optimizer |
| 16:22:49 | flyx | yes, probably. it is really fast |
| 16:35:28 | * | chemist69 quit (Ping timeout: 245 seconds) |
| 16:38:21 | * | chemist69 joined #nim |
| 16:46:09 | krux02 | is there a macro or template that expands to the current file/module name? |
| 16:51:26 | elrood | def- recently proposed template filename: string = instantiationInfo().filename |
| 16:52:59 | Araq | elrood: I think Nim's secret is that it uses all CPU cores in the C step ;-) |
| 16:53:28 | Araq | with a traditional compiler architecture it's harder to get parallelism out of the design |
| 16:53:32 | elrood | don't spoil the magic ;) |
| 16:55:06 | Araq | I would even credit the Unix design for this, multiple programs that work together via primitive one-way IO mechanisms are easy to parallelize |
| 16:56:04 | Araq | yes, I said something positive about Unix, can you believe that. :-) |
| 16:57:21 | elrood | stack up on supplies, guys, hell's about to freeze over *g otoh, it'd be somewhat disappointing if other moderately recent compiler implementations didn't do the same at least as soon as multiple compilation units come into play. do you mean to imply they don't? |
| 17:00:36 | krux02 | elrood: thanks for the hint. |
| 17:00:49 | krux02 | it works |
| 17:01:56 | krux02 | I am not a compiler guru, but I guess resolving circular dependencies in modules is not somthing that can be parallelized very easy |
| 17:03:04 | krux02 | the reason c and c++ compilation can be parallelized so good, is because every module can be compiled completely independently. That's not possible in other programming languages. |
| 17:04:27 | krux02 | The problem in c++ is just, that the habit of including dependent libraries results in compilation units with 1000000 lines included from headers per line in the cpp file |
| 17:05:13 | * | yglukhov_ joined #nim |
| 17:08:37 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 17:09:52 | * | yglukhov_ quit (Ping timeout: 268 seconds) |
| 17:14:53 | * | yglukhov joined #nim |
| 17:18:06 | FromGitter | <ephja> this should compile, right? ⏎ ⏎ ```proc p(t: typedesc): int {.compileTime.} = 1``` [https://gitter.im/nim-lang/Nim?at=583db84d444b3778766f6f60] |
| 17:19:02 | * | brechtm joined #nim |
| 17:19:11 | FromGitter | <ephja> I know I can use templates instead |
| 17:19:13 | * | yglukhov quit (Ping timeout: 245 seconds) |
| 17:20:47 | * | brson joined #nim |
| 17:20:52 | * | Andris_zbx quit (Remote host closed the connection) |
| 17:22:15 | * | brechtm_ quit (Ping timeout: 250 seconds) |
| 17:23:15 | * | rokups quit (Quit: Connection closed for inactivity) |
| 17:23:30 | * | [ui] joined #nim |
| 17:30:35 | * | brson_ joined #nim |
| 17:32:41 | * | brson quit (Ping timeout: 268 seconds) |
| 17:43:12 | * | brson_ quit (Quit: leaving) |
| 17:43:27 | * | brson joined #nim |
| 17:49:53 | * | vlad1777d joined #nim |
| 17:53:26 | * | Sembei quit (Ping timeout: 250 seconds) |
| 17:56:58 | Araq | elrood: I don't know how much these compilers are parallelized, I'm pretty sure D doesn't use multi threading and since the backend step is not a separate process it doesn't use multi processing either |
| 17:58:23 | * | space-wizard joined #nim |
| 17:59:33 | * | Mat4 joined #nim |
| 18:03:17 | * | yglukhov joined #nim |
| 18:04:08 | FromGitter | <ephja> is it possible to parallelize more granularly than per-module? |
| 18:05:11 | elrood | Araq, with you on d, after all its technical core originates from way before the multicore evolution, both software- and developer-wise. but i'd be mildly surprised if rustc or especially go's compiler weren't parallelized. might be worth a little deeper investigation |
| 18:07:17 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 18:07:56 | krux02 | elrood: Go's architecture strictly forbids circular dependencies. so after dependency resolution independent modules could be compiled in parallel. I never teseted it it is actually done, but it just makes senso to do that. |
| 18:08:43 | krux02 | s/it it/if it/ |
| 18:10:50 | FromGitter | <ephja> seems like a fair trade-off |
| 18:11:50 | * | libman joined #nim |
| 18:17:02 | * | nsf quit (Quit: WeeChat 1.6) |
| 18:25:11 | * | rynsin joined #nim |
| 18:34:50 | * | irrequietus joined #nim |
| 18:36:44 | * | shodan45 joined #nim |
| 18:37:57 | * | rynsin quit (Quit: rynsin) |
| 18:39:24 | * | brechtm_ joined #nim |
| 18:42:59 | * | brechtm quit (Ping timeout: 268 seconds) |
| 18:47:19 | krux02 | I have a Heisenbug |
| 18:48:51 | * | yglukhov joined #nim |
| 18:51:12 | * | Mat4 quit (Quit: Leaving) |
| 18:58:52 | krux02 | as soon as I put a print statement in my code, the bug disappears. I remove the print, the bug comes back |
| 18:58:56 | krux02 | not very nice |
| 18:59:13 | * | yglukhov quit (Remote host closed the connection) |
| 18:59:57 | * | yglukhov joined #nim |
| 19:04:24 | * | brson quit (Read error: Connection reset by peer) |
| 19:04:52 | federico3 | that's bad |
| 19:05:02 | * | brson joined #nim |
| 19:07:18 | vktec | krux02: Nasty |
| 19:08:59 | * | pregressive joined #nim |
| 19:10:45 | Araq | krux02: if you are on devel, you can compile with --memtracker:on and put this into your main module |
| 19:10:54 | Araq | when defined(memtracker): import nimtracker |
| 19:11:35 | Araq | then when the program crashes, ask about who overwrote the offending address |
| 19:11:41 | cheatfate | krux02, i know such kind of bugs... something smashing your stack |
| 19:12:31 | cheatfate | it can be caused if you pass lower/bigger count of arguments to function |
| 19:13:47 | cheatfate | like some library exports function with 5 arguments, and nim declaration of this function has only 4, so you are using 4 and got stack smash |
| 19:14:10 | cheatfate | or you overplayed with ref/ptr |
| 19:14:57 | * | yglukhov quit (Remote host closed the connection) |
| 19:16:00 | * | qwertunflauschig is now known as qwertfisch |
| 19:19:26 | * | yglukhov joined #nim |
| 19:20:08 | * | kulelu88 joined #nim |
| 19:31:30 | krux02 | Araq, cheatfate: It happens at my most "intense" part of the code. The crosspoint of two level macro expansion and code generation with {.global.} variables |
| 19:32:05 | Araq | krux02: is it a compiletime bug? |
| 19:32:53 | krux02 | I don't know yet exactly, but the compilation does not crash, the program neither, but it is not working correctly |
| 19:33:03 | krux02 | my rendering became black |
| 19:33:50 | krux02 | as soon as I put print statements to check weather all my shader-programs are valid ids, the program became normal again |
| 19:34:00 | * | vendethiel joined #nim |
| 19:34:35 | krux02 | I reversed my changes so that I do not collide with the bug anymore |
| 19:34:53 | * | brson quit (Read error: Connection reset by peer) |
| 19:35:07 | krux02 | the working version has three global variables, one of them is an array |
| 19:35:37 | krux02 | the broken version has those three {.global.} variables joined into one global variable of an object type |
| 19:35:47 | * | brson joined #nim |
| 19:36:32 | * | brson quit (Read error: Connection reset by peer) |
| 19:37:17 | krux02 | so instead of var anInt, anInt, anIntArray I now have var anObject : object(anInt, antInt, anIntArray) |
| 19:38:23 | * | brson joined #nim |
| 19:38:46 | Araq | does this object use inheritance? |
| 19:39:02 | krux02 | no inheritance, no ref types |
| 19:39:23 | Araq | too bad, else it might be https://github.com/nim-lang/Nim/issues/5055 |
| 19:39:49 | krux02 | type |
| 19:39:49 | krux02 | RenderObject*[N: static[int]] = object |
| 19:39:49 | krux02 | vao*: VertexArrayObject |
| 19:39:49 | krux02 | program*: Program |
| 19:39:49 | krux02 | locations*: array[N, Location] |
| 19:40:25 | vktec | krux02: Try to use a pastebin, such as bpaste.net or gist.github.com when pasting blocks of text |
| 19:41:30 | krux02 | vktec, I am sorry I broke the rule knowing that the maximum number of lines allowed to paste in chat is 2 |
| 19:41:40 | vktec | :) |
| 19:43:28 | libman | Interesting: https://codegolf.stackexchange.com/questions/101179/tips-for-golfing-in-nim/101182 |
| 19:44:57 | * | dmi00 quit (Ping timeout: 240 seconds) |
| 19:47:09 | * | brson quit (Read error: Connection reset by peer) |
| 19:47:40 | * | couven92 quit (Read error: Connection reset by peer) |
| 19:51:29 | cheatfate | Araq, i've got compiler failure, is it possible to know what line causes problems? |
| 19:51:39 | * | brson joined #nim |
| 19:52:06 | cheatfate | i mean source line not compiler's line |
| 19:55:11 | * | pregressive quit (Read error: Connection reset by peer) |
| 19:56:02 | elrood | a pity --debugger:native and some gdb/windbg-fu aren't more appreciated and prevalent |
| 19:56:30 | * | pregressive joined #nim |
| 20:00:17 | libman | Too bad Nim json improvements didn't make it into http://libman.org/img/bak/20161129-kostya-benchmarks-copyfree.png |
| 20:00:58 | libman | (It's made from https://github.com/kostya/benchmarks .) |
| 20:01:35 | * | rynsin joined #nim |
| 20:02:25 | libman | Anyone know Julia's secret for matrix manipulations? ;) |
| 20:03:55 | * | pregressive quit (Remote host closed the connection) |
| 20:04:37 | * | PMunch quit (Quit: leaving) |
| 20:07:44 | elrood | libman, BLAS, basically |
| 20:09:47 | libman | Like a Nim wrapper around https://github.com/Reference-LAPACK/lapack would do it? |
| 20:10:44 | libman | (Just curious. I figure targeting superlative benchmark results would be good for Nim marketing / advocacy.) |
| 20:11:29 | * | Sembei joined #nim |
| 20:11:45 | elrood | not really. more like, a wrapper around BLAS, LAPACK and being designed from the ground up for this sort of computations would do it |
| 20:14:43 | * | nsf joined #nim |
| 20:15:46 | libman | If there was a betting market on Nim vs Rust benchmarks for a year from now, how would you bet? :P |
| 20:17:59 | krux02 | libman: I would bet on Rust. Not that I like it more, but it has the stronger marketing arguments: eleminating classes of errors. Development performance and flexibility is a bit hard to measure comparibly |
| 20:19:47 | cheatfate | libman, stop comparing languages backed by multimillion corporations with Nim |
| 20:19:50 | elrood | rust will obviously fail because there's too much money, development time and corporate backing being thrown at it, it can only go down under the burden.. plus, being dependent on llvm's behemoth of a toolchain doesn't help it at all ;P |
| 20:20:40 | libman | What if the comparison is favorable for Nim? ;) |
| 20:21:38 | elrood | do you have the idiom of eating a broomstick in english? |
| 20:23:07 | vktec | elrood: Not... as far as I'm aware |
| 20:23:33 | cheatfate | libman, to make something perfect to win all of benchmarks you mentioned, we need more people and much more time |
| 20:24:45 | yglukhov | hey guys, suddenly newly built nimble stopped working inside my docker image. could not import: SSL_library_init. Does anyone know the reason? |
| 20:27:03 | cheatfate | libman, and i think if some corp invest $200k to make webserver in nim, like mozilla made with rust, i think we will have much faster web server then our current version |
| 20:27:42 | libman | I'm justa tryin' to help with da marketing. |
| 20:29:20 | * | irrequietus quit (Ping timeout: 252 seconds) |
| 20:30:21 | krux02 | how many people are actually developing with nim? |
| 20:31:37 | euantor | Depends on what you mean - deploying it in critical situations? Or writing productivity tools for ourselves/our teams |
| 20:31:51 | * | bjz joined #nim |
| 20:32:30 | euantor | I'm in the latter camp at the minute, using Nom where I would have used Python or C#. Our code that we actually ship is still .NET for now though |
| 20:34:54 | elrood | as much as we probably all root for nim, deploying it in critical situations quite likely means the count is prone to dropping by at least one sometime soon |
| 20:36:24 | * | rynsin quit (Quit: rynsin) |
| 20:36:40 | euantor | Also, I hate autocomplete - it seems determined to replace "nim" with "him" or "nom" every single time I write it even though I've added it to the dictionary |
| 20:39:32 | * | Trustable quit (Remote host closed the connection) |
| 20:41:16 | * | rynsin joined #nim |
| 20:41:33 | * | couven92 joined #nim |
| 20:42:10 | * | handicraftsman joined #nim |
| 20:42:13 | handicraftsman | Boo |
| 20:42:38 | vktec | Hi handicraftsman |
| 20:42:51 | handicraftsman | Hi |
| 20:45:39 | * | rynsin quit (Client Quit) |
| 20:48:31 | * | rynsin joined #nim |
| 20:49:00 | * | rynsin quit (Client Quit) |
| 20:49:16 | * | brson quit (Read error: Connection reset by peer) |
| 20:53:29 | * | Varriount|Mobile joined #nim |
| 20:53:44 | krux02 | euantor: it really depends on the autocompletion engine. I stupid word based autocompletion, or semantic autocompletion is very different |
| 20:54:44 | * | brson joined #nim |
| 20:55:47 | euantor | It's whatever Apple put in their systems. It often gets in the way, but I couldn't live with it turned off either |
| 20:56:02 | * | rynsin joined #nim |
| 20:56:52 | handicraftsman | I am getting next message: irc.nim(1, 8) Warning: sockets is deprecated [Deprecated] |
| 20:56:55 | Varriount|Mobile | euantor: I want to Nom a programming language. :3 |
| 20:56:58 | handicraftsman | What should i use instead? |
| 20:57:36 | euantor | Varriount|Mobile: Oh yeah, I do too even though I just ate dinner :) |
| 20:57:58 | * | rynsin quit (Max SendQ exceeded) |
| 20:58:49 | * | rynsin joined #nim |
| 20:59:06 | euantor | handicraftsman: The net module, but the IRC package seems to use that already: https://github.com/nim-lang/irc/blob/master/src/irc.nim |
| 20:59:07 | krux02 | euantor: Ah I get it, you mean autocorrect, not autocomplete. I disabled it on my phone. And whenever I can I jon't use my phone. |
| 20:59:50 | euantor | krux02: Yeah, that's the one - I get confused. I'm on a Mac at the minute, but it affects me on the phone too |
| 20:59:52 | handicraftsman | euantor, i am gonna implement IRC on my own |
| 21:00:13 | euantor | handicraftsman: Use the net module and asyncnet then, like the package does :) |
| 21:00:19 | euantor | http://nim-lang.org/docs/net.html |
| 21:00:59 | * | rynsin quit (Max SendQ exceeded) |
| 21:01:30 | krux02 | handicraftsman: I think implementing irc is even possible. It's not like those modern day protocols that are impossible to implement without myriads of layers of hullabaloo |
| 21:01:32 | handicraftsman | euantor, tried to find docs. Got 404 after following a link. |
| 21:01:39 | * | rynsin joined #nim |
| 21:01:44 | krux02 | I just looked "hullabaloo" up. Not sure if I used it right |
| 21:01:46 | dom96 | handicraftsman: why not use the IRC package? |
| 21:02:19 | handicraftsman | @dom96, just because :D |
| 21:02:39 | dom96 | lol alright |
| 21:03:09 | elrood | "The good thing about reinventing the wheel is that you can get a round one." << ? ;) |
| 21:03:28 | handicraftsman | http://nim-lang.org/docs/docs/theindex.html |
| 21:03:30 | handicraftsman | 404 |
| 21:03:52 | * | rynsin quit (Max SendQ exceeded) |
| 21:03:55 | dom96 | http://nim-lang.org/docs/theindex.html |
| 21:03:58 | handicraftsman | Also. Site says that it's powered by jester, but i see nginx/ubuntu there |
| 21:04:17 | dom96 | nim-lang.org is static |
| 21:04:34 | * | rynsin joined #nim |
| 21:04:37 | dom96 | forum.nim-lang.org is powered by jester, but behind a reverse proxy (nginx) |
| 21:06:44 | * | rynsin quit (Max SendQ exceeded) |
| 21:07:09 | yglukhov | dom96: hey |
| 21:07:16 | * | rynsin joined #nim |
| 21:07:17 | dom96 | yglukhov: hi |
| 21:08:01 | Varriount|Mobile | dom96: You should make it an https reverse proxy |
| 21:08:13 | yglukhov | there's some unexpected problem with opensll and latest debian stretch. specifically: SSL_library_init is not a function anymore but a compatibility macro. |
| 21:08:17 | dom96 | Varriount|Mobile: I will |
| 21:08:25 | yglukhov | as a result we cant link to it dynamically. |
| 21:08:44 | Varriount|Mobile | yglukhov: O_o |
| 21:08:51 | dom96 | yglukhov: fun. Guess you need to wrap whatever functions the macro calls then |
| 21:08:57 | dom96 | and then call them in the same way |
| 21:11:48 | yglukhov | well, its not really clear from the first glance which is the most portable way of doing this. openssl docs recommend using OPENSSL_init_ssl instead, but its not clear which version it was introduced in. so i wonder. is there a way to tell nim there are more than one symbol name function can be tried to link to before failing? |
| 21:11:56 | yglukhov | like we can do that for library names. |
| 21:12:06 | yglukhov | but not for function names i guess? |
| 21:13:19 | * | brson quit (Read error: Connection reset by peer) |
| 21:13:23 | * | byte512 quit (Ping timeout: 258 seconds) |
| 21:13:36 | * | PMunch joined #nim |
| 21:16:24 | yglukhov | dom96: As of version 1.1.0 OpenSSL will automatically allocate all resources that it needs so no explicit initialisation is required. Similarly it will also automatically deinitialise as required. |
| 21:17:21 | dom96 | yglukhov: Take a look at the opengl wrapper, I think there is some dynamic loading magic there |
| 21:17:47 | dom96 | Otherwise I guess what we need is a new -d[efine] :\ |
| 21:18:34 | yglukhov | dom96: or better weak dynlinking |
| 21:18:51 | * | brson joined #nim |
| 21:18:51 | * | brson quit (Client Quit) |
| 21:19:01 | cheatfate | yglukhov, weak dynlinking? |
| 21:19:07 | * | brson joined #nim |
| 21:19:09 | dom96 | In fact, I have been asking for something similar for openssl |
| 21:19:29 | dom96 | So that Nimble doesn't crash when openssl.dll isn't around |
| 21:19:49 | yglukhov | cheatfate: sure, dynlinker tries to dynlink, but doesn't crash if fails. just sets func pointer to nil so it can be checked in the higher-level logic |
| 21:20:17 | dom96 | But Araq has his reasons for opposing this |
| 21:20:45 | cheatfate | yglukhov, import dynlib? |
| 21:20:59 | cheatfate | yglukhov, and make openssl wraper great again? :) |
| 21:21:57 | yglukhov | also i think that all this magic around dynlink can be done completely without compiler support in library code. and weakness could be an option right there. |
| 21:22:32 | * | rynsin quit (Quit: rynsin) |
| 21:23:00 | dom96 | I think that there should be a mode where instead of the application crashing, an exception is raised. |
| 21:24:04 | cheatfate | dynlink is made in stub so we can't catch exception in code... |
| 21:24:50 | yglukhov | exception could be thrown upon trying to use the function |
| 21:25:12 | yglukhov | but that sounds harder to implement and not as efficient |
| 21:25:28 | * | rynsin joined #nim |
| 21:25:58 | dom96 | or the dynamic loader could expose a function that we can call to load all the dynlibs |
| 21:26:21 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:26:29 | yglukhov | but then how can you be precise about which function to load |
| 21:26:58 | cheatfate | yglukhov, https://github.com/nim-lang/Nim/blob/devel/lib/windows/winlean.nim#L859 |
| 21:26:59 | dom96 | if you want to be precise about loading functions then you can already use the dynlib module |
| 21:27:45 | yglukhov | thats just unwieldy |
| 21:27:58 | euantor | LibreSSL's libtls looks more and more appealing every time I look at it... http://man.openbsd.org/OpenBSD-current/man3/tls_init.3 |
| 21:29:18 | yglukhov | yes, libretls is nice. but can it be nicely wrapped into nim so that it is as portable as nim code is? |
| 21:29:25 | yglukhov | *libressl |
| 21:29:34 | dom96 | you could probably write a pragma macro to make the job easier |
| 21:29:46 | dom96 | or hack the compiler and introduce a new importc-esque pragma |
| 21:30:30 | FromGitter | <ephja> how about function pointers and then a convenient interface generated by a macro by the library author |
| 21:30:36 | yglukhov | dom96: exactly. i like the macro idea. and then all the compiler dlimport functionality becomes pretty much obsolete |
| 21:30:47 | euantor | It looks fairly easy if all you want is libtls. The libssl library is a little more involved |
| 21:31:20 | * | Sembei quit (Ping timeout: 268 seconds) |
| 21:31:28 | dom96 | yglukhov: Yes, the more things we can implement as macros the better. |
| 21:31:55 | FromGitter | <ephja> but it's not possible right now to use a variable at both compile time and run time IIRC |
| 21:32:12 | Araq | I thought about adding nimscript support to the codegen |
| 21:32:32 | FromGitter | <ephja> that would allow for a lot of neat things. the simplest workaround would be to read and write files for now |
| 21:32:35 | Araq | this way you could implement on your own what 'importc' means/does |
| 21:33:12 | yglukhov | Araq: can't we do that already? =) |
| 21:33:39 | Araq | yeah we can. |
| 21:34:10 | cheatfate | Araq, generic procs could not be forward declared? |
| 21:34:23 | Araq | open issue |
| 21:34:43 | Araq | the code has been written to support that, but doesn't work yet. |
| 21:35:03 | dom96 | Araq: A compiler plugin API might be nice |
| 21:35:26 | yglukhov | but thats not the real question actually. a nice and smart library-resident dynlinker surely seems possible, but the reality is that i need that issue fixed kinda asap. so the best bet is manual dlopen+dlsym? |
| 21:35:55 | dom96 | yglukhov: indeed |
| 21:37:06 | Araq | yglukhov: what's the problem? SSL binding? |
| 21:37:13 | yglukhov | yup |
| 21:37:41 | yglukhov | latest debian |
| 21:39:12 | * | brson quit (Read error: Connection reset by peer) |
| 21:40:34 | * | dmi00 joined #nim |
| 21:41:32 | * | [ui] quit (Quit: Connection closed for inactivity) |
| 21:41:51 | Araq | if it became a macro, how does it help to use an alternative import name? |
| 21:43:22 | yglukhov | Araq: this function does not need to be called anymore since 1.1.0. |
| 21:43:33 | Araq | yes, got it. |
| 21:43:47 | Araq | so the alternative name would be empty and this means "do not call anything"? what? |
| 21:44:06 | Araq | I think you propose something like |
| 21:44:24 | * | brson joined #nim |
| 21:44:24 | Araq | proc foo() {.dynlib: whatever, importc: "foo|bar".} |
| 21:44:38 | Araq | but I fail to see how it helps for your case |
| 21:45:12 | yglukhov | no, "alternative name" was my idea about OPENSSL_init_ssl, which is a kinda replacement of the old function which is now a macro. |
| 21:45:34 | yglukhov | but thats only my assumption that OPENSSL_init_ssl is actually a function and not another macro |
| 21:45:56 | yglukhov | openssl is messy... |
| 21:46:16 | Varriount|Mobile | Araq: Also, macros can't operate on types via pragma syntax. :( |
| 21:46:38 | FromGitter | <ephja> any plans regarding a sandboxed VM that can generate native code? :p |
| 21:47:04 | Varriount|Mobile | ephja: Isn't that what the compiler already is? |
| 21:47:06 | yglukhov | oh, if we're speaking about macro limitations, macros can't be pushed/popped like pragmas can. just 2 cents =) |
| 21:48:51 | Araq | push/pop have more serious problems than that :P |
| 21:49:43 | yglukhov | ok |
| 21:50:06 | * | handicraftsman left #nim ("Leaving") |
| 21:50:50 | yglukhov | Araq: is there some "public" way to dlopen a lib with all the patterns that we normally provide to dlimport prgama? |
| 21:51:31 | Araq | no, the pattern is in fact compiled into a series of 'or' expressions |
| 21:52:06 | yglukhov | ok |
| 21:52:09 | FromGitter | <ephja> Varriount|Mobile: in the case of runtime plugin loading too? |
| 21:52:39 | Varriount|Mobile | ephja: Ah, |
| 21:53:12 | Araq | yglukhov: I think best way is to update the compiler |
| 21:53:31 | Araq | or system lib, have a look at lib/system/dyncalls.nim |
| 21:53:49 | Araq | the first problem is that 'procAddrError' is called |
| 21:54:18 | Varriount|Mobile | ephja: My only problem with that would be code size. Even taking out all the code generation stuff, semantic analysis and compile-time code would still increase executable size would significantly increase. |
| 21:54:48 | yglukhov | Araq: yeah, i've studied that file a couple of weeks ago, when we had problems on android and no way to see the error logs =) |
| 21:54:50 | Araq | the 2nd problem is how to make nim understand that an imported proc can be compared to 'nil' and this check should not be optimized out |
| 21:58:07 | * | shubhaml joined #nim |
| 21:58:24 | Araq | or we expose the generated LibHandle |
| 21:58:33 | yglukhov | Araq: tbh, i dont think this needs fixing in the compiler, because like i said that functionality needs a library reimplementation, dont you think? |
| 21:58:50 | FromGitter | <ephja> Varriount|Mobile: conditional inclusion to the rescue? |
| 22:00:32 | Araq | yglukhov: but your manual dlsym should use the same DLL handle (or whatever Unix calls it) |
| 22:00:41 | yglukhov | Araq: meanwhile... how about reproducing what nim does by manually oring a bunch of dlopens? don't kick me too hard. |
| 22:01:23 | yglukhov | Araq: so for that we'll keep some table of names-to-handles or smth... |
| 22:01:39 | Varriount|Mobile | Ephja: I think a subset of Nim would be better, at least as a start |
| 22:01:53 | yglukhov | Araq: sorry, disregard my last message |
| 22:02:13 | yglukhov | Araq: and reconsider this one: meanwhile... how about reproducing what nim does by manually oring a bunch of dlopens? don't kick me too hard. |
| 22:03:16 | Araq | not sure I understand, compiler/options.nim |
| 22:03:19 | yglukhov | so basically the idea is to use a separate handle for this init func. and let it leak till the end of process |
| 22:03:27 | Araq | proc libCandidates |
| 22:03:37 | Araq | contains the algorithm for the pattern compiler |
| 22:04:42 | yglukhov | Araq: harcode the libs in case of openssl. |
| 22:04:56 | yglukhov | well thats what my idea is |
| 22:05:22 | * | desophos joined #nim |
| 22:05:34 | yglukhov | manually write the code which in normal case is generated by libCandidates |
| 22:05:59 | Araq | no need, add the algorithm to dynlibs |
| 22:06:44 | Araq | *dynlib.nim |
| 22:06:45 | yglukhov | oh |
| 22:07:03 | Araq | proc loadLibPattern*(...) |
| 22:07:44 | Araq | you can even be fancy and import dynlib into the compiler for the algorithm and avoid the code duplication |
| 22:07:53 | * | Matthias247 joined #nim |
| 22:07:58 | * | nsf quit (Quit: WeeChat 1.6) |
| 22:08:02 | yglukhov | aye just wanted to ask about that |
| 22:08:26 | yglukhov | ok, going for it then. |
| 22:08:56 | Araq | add a disclaimer that this uses the GC and so cannot be used to load the GC ... |
| 22:08:59 | * | desophos left #nim (#nim) |
| 22:10:16 | yglukhov | ok |
| 22:10:29 | * | bjz joined #nim |
| 22:15:24 | Araq | hmm dynlib supports proc calls rather than string literals to determine what to load |
| 22:15:47 | Araq | proc foo() {.dynlib: pickName(), importc.} |
| 22:16:28 | Araq | which is then used for nimLoadLibrary(...). Kinda stupid. |
| 22:16:43 | Araq | would be more useful if pickName() would return the DLL handle |
| 22:17:04 | Araq | but I can see why this is hard to support |
| 22:18:49 | Araq | still ... too much magic, somebody should redesign .dynlib |
| 22:19:49 | yglukhov | Araq: can i import strutils in dynlib.nim? |
| 22:20:16 | Varriount|Mobile | Araq: Too many magicians added to the mix? :3 |
| 22:20:35 | Araq | yglukhov: yes, it's not part of system.nim, relax |
| 22:20:52 | Araq | system uses dyncalls.nim |
| 22:21:25 | * | brson quit (Ping timeout: 248 seconds) |
| 22:21:35 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:22:28 | Araq | Varriount|Mobile: no, it's just that I'm a better designer now. |
| 22:23:31 | * | brson joined #nim |
| 22:26:13 | * | brson quit (Read error: Connection reset by peer) |
| 22:28:29 | * | brson joined #nim |
| 22:34:53 | * | brson quit (Read error: Connection reset by peer) |
| 22:40:19 | * | brson joined #nim |
| 22:54:46 | cheatfate | yglukhov, you can't import strutils |
| 22:54:51 | cheatfate | there was a problem |
| 22:55:09 | yglukhov | which one? |
| 22:55:52 | cheatfate | yglukhov, never mind |
| 22:55:56 | cheatfate | i was wrong |
| 23:00:08 | * | elrood quit (Quit: Leaving) |
| 23:00:31 | * | couven92 quit (Quit: Client disconnecting) |
| 23:03:56 | * | vlad1777d quit (Remote host closed the connection) |
| 23:19:56 | * | rynsin quit (Quit: rynsin) |
| 23:22:13 | * | brson quit (Quit: leaving) |
| 23:47:56 | * | krux02 quit (Quit: Leaving) |
| 23:57:57 | * | yglukhov quit (Remote host closed the connection) |
