| 00:03:16 | * | nara joined #nim |
| 00:03:21 | * | nara left #nim (#nim) |
| 00:03:25 | * | nara joined #nim |
| 00:11:32 | * | nara left #nim (#nim) |
| 00:28:27 | * | rnrwashere quit (Remote host closed the connection) |
| 01:15:58 | * | sealmove joined #nim |
| 01:26:22 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 01:43:55 | * | rnrwashere joined #nim |
| 02:05:58 | * | leorize joined #nim |
| 02:15:32 | * | abm quit (Ping timeout: 250 seconds) |
| 02:28:17 | * | rnrwashere quit (Remote host closed the connection) |
| 02:31:15 | * | rnrwashere joined #nim |
| 02:34:35 | * | tiorock joined #nim |
| 02:34:35 | * | tiorock quit (Changing host) |
| 02:34:35 | * | tiorock joined #nim |
| 02:34:35 | * | rockcavera quit (Killed (rajaniemi.freenode.net (Nickname regained by services))) |
| 02:34:35 | * | tiorock is now known as rockcavera |
| 02:35:51 | * | rnrwashere quit (Ping timeout: 252 seconds) |
| 02:46:38 | * | Senketsu_ quit (Ping timeout: 268 seconds) |
| 02:59:13 | * | sealmove quit (Quit: WeeChat 2.4) |
| 03:02:37 | * | banc quit (Quit: Bye) |
| 03:18:47 | * | Senketsu_ joined #nim |
| 03:23:51 | * | banc joined #nim |
| 03:26:31 | * | rnrwashere joined #nim |
| 03:37:24 | * | rnrwashere quit (Remote host closed the connection) |
| 03:47:45 | * | rnrwashere joined #nim |
| 03:49:00 | * | vlad1777d quit (Ping timeout: 252 seconds) |
| 04:20:03 | * | nsf joined #nim |
| 04:24:26 | * | kapil____ joined #nim |
| 04:35:36 | * | chemist69 quit (Ping timeout: 252 seconds) |
| 04:37:22 | * | chemist69 joined #nim |
| 04:43:19 | * | noonien quit (Quit: Connection closed for inactivity) |
| 05:02:07 | * | narimiran joined #nim |
| 05:09:14 | * | noeontheend joined #nim |
| 05:12:31 | * | leorize quit (Remote host closed the connection) |
| 06:42:15 | * | noeontheend quit (Ping timeout: 252 seconds) |
| 07:06:55 | * | jjido_ joined #nim |
| 07:20:53 | * | krux02 joined #nim |
| 07:40:09 | * | rnrwashere quit (Remote host closed the connection) |
| 07:43:20 | * | rnrwashere joined #nim |
| 07:45:06 | * | ng0 joined #nim |
| 07:55:06 | Araq | https://www.gcc.tu-darmstadt.de/media/gcc/papers/Widmer_2013_FDM.pdf I still want to run all of Nim on the GPU |
| 07:57:56 | Araq | with the quirky exceptions and a GC-free runtime the full Nim language would work on GPUs |
| 08:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 08:04:37 | * | gmpreussner joined #nim |
| 08:08:30 | * | lritter joined #nim |
| 08:10:36 | * | Vladar joined #nim |
| 08:20:37 | * | couven92 joined #nim |
| 08:23:11 | * | jjido_ quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 08:27:49 | * | PMunch joined #nim |
| 08:29:13 | * | Cthalupa quit (Ping timeout: 245 seconds) |
| 08:29:54 | * | Cthalupa joined #nim |
| 08:31:06 | * | rnrwashere quit (Remote host closed the connection) |
| 08:31:32 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 08:38:19 | * | dddddd joined #nim |
| 08:38:55 | * | krux02 quit (Remote host closed the connection) |
| 08:56:56 | * | abm joined #nim |
| 09:03:24 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 09:06:06 | * | floppydh joined #nim |
| 09:36:00 | * | dddddd_ joined #nim |
| 09:36:36 | * | dddddd quit (Ping timeout: 252 seconds) |
| 09:37:01 | * | dddddd_ is now known as dddddd |
| 09:45:09 | * | krux02 joined #nim |
| 10:20:38 | * | kapil____ joined #nim |
| 10:41:01 | FromGitter | <liquid600pgm> wow, running nim on the GPU is an interesting idea |
| 10:49:08 | * | luis_ joined #nim |
| 10:57:59 | * | Vladar quit (Remote host closed the connection) |
| 11:01:11 | * | Perkol joined #nim |
| 11:06:08 | krux02 | @liquid600pgm: it is not just an idea, it is possible |
| 11:06:36 | krux02 | I have a working project |
| 11:08:43 | krux02 | here is a minimal hello triangle project https://github.com/krux02/opengl-sandbox/blob/master/experiment/hello_triangle.nim |
| 11:12:46 | FromGitter | <yglukhov> @liquid600pgm also https://github.com/yglukhov/nimsl :) |
| 11:22:05 | FromGitter | <yglukhov> @iffy yep, commented. |
| 11:22:13 | Zevv | How come #nim is so quiet over the last few weeks; have people taken the discussions elswhere? |
| 11:23:27 | narimiran | Zevv: i noticed that too. everybody is waiting for somebody else to start a discussion? |
| 11:27:39 | FromGitter | <yglukhov> Ok, i'll try to start one :). Any v8 gurus around? Want to run wasm with exceptions on node/chrome/firefox/whatever. Yet no luck. |
| 11:30:37 | krux02 | sorry but I only know how to run Nim on the GPU, not on wasm |
| 11:30:50 | krux02 | but you do know that already |
| 11:33:40 | FromGitter | <yglukhov> I know how to make wasm from nim, now I'm trying to make exceptions work :) |
| 11:34:08 | krux02 | that is cool |
| 11:34:35 | krux02 | does it go through llvm, or through C then wasm? |
| 11:34:35 | * | Vladar joined #nim |
| 11:35:59 | FromGitter | <yglukhov> c/c++ -> wasm |
| 11:36:04 | krux02 | ok |
| 11:36:21 | krux02 | so then I guess that my importc hacks might survive? |
| 11:36:46 | FromGitter | <yglukhov> to support exceptions only c++ can be used so far. at least that's what I've managed to do :). |
| 11:37:12 | FromGitter | <yglukhov> what are your hacks about? |
| 11:37:42 | krux02 | just some C wrapper code |
| 11:37:53 | krux02 | don't care for exceptions though, I don't use them |
| 11:38:57 | krux02 | but that would be just me |
| 11:41:09 | FromGitter | <yglukhov> btw, is there any work ongoing regarding exception_handling-to-branching lowering? |
| 11:52:01 | Araq | yglukhov: there is -d:nimQuirky fwiw |
| 11:52:19 | * | Perkol quit (Remote host closed the connection) |
| 11:53:07 | * | noonien joined #nim |
| 11:53:30 | Araq | all that is left to do is to emit 'if (error) goto returnStmt' in the C backend |
| 11:54:51 | Araq | though I personally would just patch the IO procs with this 'if' and live with the quirky semantics |
| 12:01:59 | FromGitter | <yglukhov> 'if (error) goto return' is not accurate enough I assume. Should be `goto nearestFinally or return`, or smth like that. |
| 12:02:42 | FromGitter | <yglukhov> somewhat similar to yield-in-try transformation.. |
| 12:03:31 | Araq | true but in the C backend we know the target label |
| 12:03:52 | FromGitter | <yglukhov> is current `nimQuirky` done in sem? |
| 12:04:28 | Araq | no, it's done in the C backend |
| 12:04:35 | Araq | plus a minor system.nim patch |
| 12:05:23 | luis_ | Hi all, is Nim a good language to interface with c++ code? |
| 12:06:04 | Araq | luis_: it's getting there |
| 12:06:55 | luis_ | Araq: thanks... any instructions at the documentation? |
| 12:09:15 | Araq | https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-importcpp-pragma |
| 12:12:42 | luis_ | Araq: thank you |
| 12:17:46 | FromGitter | <yglukhov> Araq: hm. i imagine doing a separate optional transformation before codegen would be better. E.g. nlvm could then reuse it. |
| 12:23:22 | narimiran | @yglukhov i'm trying to run tests for nimx and i get "nimx/pasteboard/pasteboard_x11.nim(5, 8) Error: cannot open file: xlib" |
| 12:23:52 | narimiran | (and it is broken on the latest devel because of https://github.com/nim-lang/Nim/commit/c86b1fbcac11520380ad15e103a8ec429228d735, but that's another thing) |
| 12:24:20 | FromGitter | <yglukhov> iirc xlib used to be in stdlib. is it not the case now? |
| 12:25:03 | * | lritter quit (Ping timeout: 245 seconds) |
| 12:27:26 | * | stefanos82 joined #nim |
| 12:27:30 | narimiran | hmmm, 3 days ago it passed our test. let me investigate some more |
| 12:27:50 | Araq | yglukhov: we don't have an IR with 'goto' :P |
| 12:28:39 | Araq | so if we don't do it in the C backend it becomes messy really quickly |
| 12:29:40 | * | lritter joined #nim |
| 12:35:04 | narimiran | hmm, i guess those xlib problems are only happening to me locally (they happen for older nim devel versions for which the tests were green) |
| 12:35:58 | narimiran | the latest nim devel throws here https://github.com/yglukhov/nimx/blob/master/nimx/private/worker_queue.nim#L36 "Error: 'threadWorker' is not GC-safe as it performs an indirect call here" |
| 12:39:22 | * | planetis[m] quit (Quit: OFTC spam preventative kick) |
| 12:42:08 | FromGitter | <yglukhov> Ok, ill fix that |
| 12:47:45 | Araq | yay, a good error message |
| 12:49:01 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 12:50:41 | FromGitter | <yglukhov> meh, not sure :) |
| 13:12:38 | * | Snircle joined #nim |
| 13:14:13 | * | luis_ quit (Ping timeout: 246 seconds) |
| 13:36:23 | * | cgfuh joined #nim |
| 13:44:22 | ldlework | Question: Does Nim support type pattern matching when compiling to Javascript? In the Typescript world there is some debate over type erasure I don't completely understand so just curious how it works in other languages. |
| 13:47:09 | Araq | Nim emits its own RTTI for JS and so it works like it works for the native targets |
| 13:47:28 | Araq | though I wouldn't call the 'of' operator "pattern matching" :-) |
| 13:47:43 | * | solitudesf quit (Quit: ZNC - https://znc.in) |
| 13:48:52 | * | solitudesf joined #nim |
| 13:49:00 | ldlework | Araq: ah okay |
| 13:50:40 | Araq | there are also pattern matching packages that compile your code into 'case' or 'if' which are then compiled to JS, nothing interesting happening |
| 13:55:33 | * | PMunch_ joined #nim |
| 13:55:47 | * | PMunch quit (Remote host closed the connection) |
| 13:56:06 | * | PMunch_ is now known as PMunch |
| 13:59:55 | FromGitter | <gogolxdong> Anyone know the FOSDOM link of PMunch "Meta programming"? |
| 14:00:28 | FromGitter | <gogolxdong> knows FOSDEM |
| 14:00:43 | narimiran | https://peterme.net/meta-programming-in-nim-fosdem-talk-companion-post.html |
| 14:01:22 | FromGitter | <gogolxdong> Great, thanks！ |
| 14:01:40 | PMunch | :) |
| 14:04:40 | * | vlad1777d joined #nim |
| 14:20:56 | * | Cthalupa quit (Ping timeout: 250 seconds) |
| 14:23:02 | * | Cthalupa joined #nim |
| 14:35:25 | FromGitter | <Clyybber> How can I import something in `nim e` |
| 14:35:32 | FromGitter | <Clyybber> , the repl? |
| 14:50:29 | PMunch | import? |
| 14:52:16 | PMunch | Hmm, the fact that choosenim stores the devel toolchain as nim-#devel seems to mess up the Vim LSP plug-in.. |
| 14:52:43 | PMunch | Somewhere along the line it drops the #devel part and I get errors saying it can't find stuff in the folder nim- |
| 14:53:06 | PMunch | TBH the .choosenim/current should just be a symlink to the folder, and not just a file with a name in it.. |
| 14:58:59 | * | nsf quit (Quit: WeeChat 2.4) |
| 14:59:08 | * | noeontheend joined #nim |
| 15:15:37 | * | nsf joined #nim |
| 15:19:33 | Araq | PMunch: symlinks don't work on windows so choosenim chose to not use them |
| 15:20:18 | PMunch | Isn't there an equivalent at all for Windows? |
| 15:23:50 | FromDiscord | <PusiteGA> does nim have like c# events? |
| 15:24:13 | FromGitter | <yglukhov> Araq: `goto` might not be needed. `return` should be enough. But I didn't think a lot about it. |
| 15:24:57 | shashlick | PMunch - you need admin rights for symlinks |
| 15:24:57 | FromGitter | <yglukhov> `return` gets codegened to `goto return` after all. |
| 15:25:59 | PMunch | Couldn't it at least offer it as an option on *nixes? |
| 15:31:20 | * | PMunch quit (Remote host closed the connection) |
| 15:35:27 | xace | Windows does have symlinks, but iirc they are limited to only point to objects in the same partition, and maybe only windows Pro and greater had that feature.... but I left windows in the WinXP days so things may have changed... |
| 15:36:29 | xace | oh sry, seems like it was mentioned (i didn't finish reading the chat before i wrote that) |
| 15:47:34 | * | floppydh quit (Quit: WeeChat 2.3) |
| 16:05:40 | * | ng0 joined #nim |
| 16:27:09 | * | abm quit (Ping timeout: 244 seconds) |
| 16:33:27 | Araq | PusiteGA: you're either looking for "proc types" which allow you to implement arbitrary callbacks. Or you're looking for 'async' |
| 16:34:03 | * | Snircle quit (Read error: Connection reset by peer) |
| 16:34:38 | * | Snircle joined #nim |
| 16:45:21 | * | Yardanico quit (Quit: No Ping reply in 180 seconds.) |
| 16:46:43 | * | Yardanico joined #nim |
| 16:59:25 | * | rnrwashere joined #nim |
| 17:03:32 | * | nsf quit (Quit: WeeChat 2.4) |
| 17:03:42 | * | rnrwashere quit (Remote host closed the connection) |
| 17:19:14 | * | avanderneut quit (Ping timeout: 268 seconds) |
| 17:24:40 | * | xet7 quit (Ping timeout: 264 seconds) |
| 17:26:29 | FromDiscord | <demotomohiro> you can create symbolic link with ``mklink`` |
| 17:26:31 | FromGitter | <Clyybber> PMunch That doesn't work, because `nim e` expects an expression to evaluate |
| 17:26:34 | FromDiscord | <demotomohiro> on windows |
| 17:26:43 | FromGitter | <liquid600pgm> just want to ask, because it's not an issue on Nim's GitHub: has anyone spotted that `if` is turned to `iff` in certain Nim docs? |
| 17:26:54 | FromGitter | <Clyybber> It means "if and only if" |
| 17:26:56 | shashlick | demotomohiro - that needs admin rights |
| 17:27:38 | * | narimiran_ joined #nim |
| 17:28:44 | FromDiscord | <demotomohiro> shashlick i know that require admin right, but I dont know why |
| 17:29:28 | FromGitter | <liquid600pgm> @Clyybber oh really, isn't this a bug? I remember this being a thing in docs for the `tables` module (in the source code it was spelled `if`) |
| 17:29:53 | * | narimiran quit (Ping timeout: 255 seconds) |
| 17:29:59 | FromGitter | <liquid600pgm> and I was confused as to why is the extra `f` there |
| 17:31:50 | FromGitter | <Clyybber> @lqdev Yeah it's not a bug/typo. |
| 17:32:03 | shashlick | demotomohiro - probably because it is a kludge - https://security.stackexchange.com/questions/10194/why-do-you-have-to-be-an-admin-to-create-a-symlink-in-windows |
| 17:32:14 | FromGitter | <liquid600pgm> thanks for the explanation |
| 17:32:14 | FromGitter | <Clyybber> @lqdev Its some weird english idiom |
| 17:32:23 | FromGitter | <Clyybber> @lqdev No problem |
| 17:32:40 | FromGitter | <liquid600pgm> that's the first time I seen `iff` being used, so I just had to ask |
| 17:33:04 | FromGitter | <Clyybber> @shashlick We are talking about symlinking a folder right? |
| 17:33:14 | FromGitter | <Clyybber> That works without admin rights |
| 17:33:26 | FromGitter | <Clyybber> With a so called "Junction" |
| 17:35:16 | FromGitter | <Clyybber> https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753194(v=ws.10)#parameters |
| 17:35:23 | FromGitter | <Clyybber> It only works for directories |
| 17:35:55 | * | seerix quit (Remote host closed the connection) |
| 17:37:01 | * | xet7 joined #nim |
| 17:37:03 | narimiran_ | @Clyybber is right, it means "if and only if" and it is sprinkled in lots of docs. but it only causes confusion and questions, so in the docs that i touch i remove the second 'f' |
| 17:37:09 | shashlick | Clyybber: the context is choosenim using symlinks for exe files |
| 17:37:26 | shashlick | it uses shims today since symlinks don't work for regular user |
| 17:38:33 | FromGitter | <Clyybber> @shashlick PMunch wrote ".choosenim/current should just be a symlink to the folder" so I assume he meant linking to a folder? |
| 17:38:47 | FromGitter | <Clyybber> Because this can be done without admin rights afaik |
| 17:39:12 | FromGitter | <Clyybber> with `mklink /j` instead of `mklink` |
| 17:42:04 | shashlick | well I don't understand that part of choosenim too well |
| 17:42:08 | FromGitter | <Clyybber> It also can link across hard drives, heres a rough overview: https://ss64.com/nt/mklink.html |
| 17:42:14 | shashlick | but it actually creates symlinks in ~/.nimble/bin |
| 17:42:24 | shashlick | current is only for internal tracking I think |
| 17:46:57 | FromGitter | <Clyybber> Has anybody implemented an rectangle packing algorithm in nim yet? |
| 17:54:10 | * | Jesin quit (Quit: Leaving) |
| 17:58:31 | * | Jesin joined #nim |
| 18:00:01 | * | nsf joined #nim |
| 18:02:09 | * | rnrwashere joined #nim |
| 18:04:45 | * | Jesin quit (Remote host closed the connection) |
| 18:06:31 | * | rnrwashere quit (Remote host closed the connection) |
| 18:07:25 | * | rnrwashere joined #nim |
| 18:09:22 | * | rnrwashere quit (Remote host closed the connection) |
| 18:13:13 | * | Jesin joined #nim |
| 18:18:49 | * | luis_ joined #nim |
| 18:28:03 | * | Jesin quit (Quit: Leaving) |
| 18:32:02 | * | Jesin joined #nim |
| 18:51:00 | * | noeontheend quit (Ping timeout: 252 seconds) |
| 18:53:41 | * | rnrwashere joined #nim |
| 19:11:40 | FromGitter | <Varriount> @Clyybber Not that I know of. |
| 19:24:15 | FromGitter | <iffy> @Varriount Here's an even better answer. I'm trying to achieve with Nim what this package lets you do with Rust: https://github.com/neon-bindings/neon |
| 19:25:11 | FromGitter | <Varriount> @iffy Cool! |
| 19:25:28 | FromGitter | <Varriount> @iffy Right now, that might be a bit tricky, due to Nim's GC |
| 19:25:33 | FromGitter | <iffy> Well... it would be cool if it worked :) |
| 19:25:48 | FromGitter | <Varriount> If you compile a library with Nim, you also need to bundle the Nim runtime DLL |
| 19:25:51 | FromGitter | <iffy> I've had GC problems, yes, but using `--gc:regions` seems to do much better |
| 19:26:11 | FromGitter | <iffy> there's a runtime DLL? |
| 19:26:19 | FromGitter | <iffy> beyond calling `NimMain` you mean? |
| 19:26:23 | FromGitter | <Varriount> Well, it's the DLL that contains the garbage collector |
| 19:27:10 | FromGitter | <Varriount> @iffy If a single program loads multiple Nim libraries, there needs to be a central DLL that does the garbage collection. If each library had its own garbage collector, they might step on each other's toes. |
| 19:27:24 | FromGitter | <iffy> Is `nim cpp --app:staticlib ...` not sufficient? |
| 19:27:37 | FromGitter | <Varriount> That will work |
| 19:28:16 | FromGitter | <Varriount> It's if you're using a dynamic library, where things will get complicated. |
| 19:29:09 | FromGitter | <Varriount> @iffy https://nim-lang.org/docs/nimc.html#dll-generation |
| 19:29:56 | FromGitter | <iffy> Hmm... I may be running in to that on Windows. I do `nim cpp --app:staticlib --nimcache:mysrc ...` and then let node-gyp compile the stuff in `mysrc` because I could never get node-gyp and the staticlib produced by nim to work together |
| 19:30:05 | FromGitter | <iffy> (node-gyp's fault) |
| 19:30:34 | FromGitter | <liquid600pgm> may I ask, what are the main differences between the available GCs? |
| 19:31:27 | FromGitter | <liquid600pgm> I'm mainly asking for some manual entry/reference page where I can read more about them |
| 19:31:41 | FromGitter | <Varriount> Well, the default GC is entirely automatic, as are markandsweep, boehm, and go GCs. The `region` GC isn't really a GC, just a memory management method |
| 19:32:13 | FromGitter | <Varriount> There really isn't that much documentation on them, unfortunately. |
| 19:34:26 | FromGitter | <Varriount> markandsweep GC uses the mark and sweep collection algorithm, boehm uses the boehm garbage collector library, and go uses the go garbage collector |
| 19:35:50 | FromGitter | <Varriount> https://en.wikipedia.org/wiki/Tracing_garbage_collection#Tri-color_marking |
| 19:36:11 | FromGitter | <Varriount> https://en.wikipedia.org/wiki/Boehm_garbage_collector |
| 19:36:58 | FromGitter | <Varriount> I can't find the link for the Go GC, but it's somewhere on Github |
| 19:39:48 | * | nsf quit (Quit: WeeChat 2.4) |
| 19:42:03 | Araq | varriount: what you said is correct but more precisely, every heap management has the DLL problem |
| 19:42:33 | Araq | you cannot free() stuff that was malloc()ed by a different allocator, that's just the nature of these things |
| 19:46:10 | FromGitter | <Varriount> Araq: Windows somewhat side-steps that problem by providing VirtualAlloc as part of the (DLL-based) standard library API, doesn't it? |
| 19:47:32 | FromGitter | <Varriount> (standard library api/Windows APIs) |
| 19:47:48 | Araq | you can't use VirtualAlloc for tiny allocs, it's too slow and uses too much memory |
| 19:48:15 | Araq | so you build your own allocator on top of VirtualAlloc and tada, a new incompatible allocator is born |
| 19:48:25 | Araq | same story on Unix with mmap() |
| 19:48:41 | FromGitter | <Varriount> :< |
| 19:49:12 | FromGitter | <Varriount> Araq: Ah, that's right. Because VirtualAlloc only allocates on a page-size granularity |
| 19:51:17 | Araq | it's also a context switch |
| 19:51:24 | Araq | slow. |
| 19:51:47 | FromGitter | <Varriount> Araq: What about the other allocators, like HeapAlloc? |
| 19:54:02 | * | abm joined #nim |
| 19:54:15 | Araq | I don't know, I only know VirtualAlloc |
| 19:54:41 | Araq | the other stuff always looked outdated to me :P |
| 19:54:46 | FromGitter | <Varriount> https://docs.microsoft.com/en-us/windows/desktop/api/heapapi/nf-heapapi-getprocessheap |
| 19:54:53 | FromGitter | <Varriount> https://docs.microsoft.com/en-us/windows/desktop/api/HeapApi/nf-heapapi-heapalloc |
| 19:57:06 | FromGitter | <Varriount> Araq: So, if I'm reading the MSDN documentation right, a DLL could call GetProcessHeap, then use that handle to allocate and deallocate things. |
| 19:58:21 | Araq | probably but then you have a heap that is not thread local nor supports a "heap walk" that the GC requires |
| 19:58:46 | Araq | I suppose then Nim's specific design choices start to become an issue |
| 19:59:04 | Araq | s/an issue/relevant |
| 19:59:06 | FromGitter | <Varriount> Araq: You can also create a non-default heap... but then you're back to square one. |
| 19:59:10 | FromGitter | <Varriount> Also: heapapi |
| 19:59:17 | FromGitter | <Varriount> https://docs.microsoft.com/en-us/windows/desktop/api/heapapi/nf-heapapi-heapwalk |
| 19:59:24 | * | tiorock joined #nim |
| 19:59:24 | * | tiorock quit (Changing host) |
| 19:59:24 | * | tiorock joined #nim |
| 19:59:24 | * | rockcavera is now known as Guest79120 |
| 19:59:24 | * | tiorock is now known as rockcavera |
| 20:01:00 | Araq | interesting but now it's too late, already wrote the GCs and the memory management |
| 20:01:10 | Araq | and it works on Unix too, yay |
| 20:02:07 | * | Guest79120 quit (Ping timeout: 240 seconds) |
| 20:02:56 | FromGitter | <Varriount> Araq: Meh, we could just have all Nim programs run via Wine |
| 20:02:57 | FromGitter | <Varriount> :P |
| 20:04:50 | FromGitter | <Clyybber> Stop right there |
| 20:06:31 | * | seerix joined #nim |
| 20:19:03 | Araq | it's also an awesome O(1) allocator which the Windows API doesn't offer |
| 20:26:51 | * | ng0 quit (Remote host closed the connection) |
| 20:42:20 | * | ng0 joined #nim |
| 20:44:05 | * | rockcavera quit (Remote host closed the connection) |
| 20:45:11 | * | cgfuh quit (Ping timeout: 255 seconds) |
| 20:50:17 | * | cgfuh joined #nim |
| 20:55:41 | shashlick | 34 seconds to compile nim compiler - is that good? |
| 20:57:49 | FromGitter | <Clyybber> Thats fast |
| 20:58:04 | FromGitter | <liquid600pgm> ^ |
| 20:58:16 | FromGitter | <liquid600pgm> it took me about 1 minute on my PC |
| 21:03:29 | FromDiscord | <demotomohiro> 95 seconds to ``koch boot -d:release`` on my old PC |
| 21:07:15 | FromGitter | <Varriount> demotomohiro: What OS? |
| 21:08:53 | FromDiscord | <demotomohiro> Windows8.1 |
| 21:09:19 | shashlick | i'm on Rhel 7.5 |
| 21:09:43 | livcd | and now i am interested what is the nim program that takes the longest to compile |
| 21:09:51 | FromDiscord | <demotomohiro> I executed that after git pull |
| 21:10:40 | livcd | i think people complained about wNim that it takes too long |
| 21:11:26 | dom96 | Do you guys agree with this change? https://github.com/nim-lang/Nim/pull/10797 |
| 21:11:55 | dom96 | I *really* think it's a pointless exercise in moving functions/modules around for no reason |
| 21:12:03 | FromGitter | <liquid600pgm> :thinking: |
| 21:12:49 | FromGitter | <liquid600pgm> I do agree, it does feel pretty unnecessary |
| 21:13:14 | * | narimiran_ quit (Remote host closed the connection) |
| 21:13:54 | Araq | for me the split makes sense, somebody will add more stuff to options.nim until I don't want to use it anymore, like it happened with strutils |
| 21:14:24 | dom96 | Why does strutils having lots of procs mean that you don't want to use it anymore? |
| 21:15:05 | dom96 | Are you concerned about compile-times? |
| 21:15:40 | Araq | as long as IC is not ready, yes, but it also means the useful bits in there are harder to find for newcomers |
| 21:16:00 | FromGitter | <liquid600pgm> on the other hand, looking at the module I see many procs which seem to break the idea behind options (which, for me at least, should be a safe alternative to null pointers, having procs like `map`, `flatten`, etc kind of breaks the purpose) |
| 21:16:17 | FromGitter | <liquid600pgm> so maybe an `optutils` module could be necessary? |
| 21:16:29 | FromGitter | <Clyybber> I also don't understand the purpose of map and filter in the context of options. |
| 21:17:00 | FromGitter | <Clyybber> And I feel like renaming them to optionals is kinda unneccessary |
| 21:17:08 | FromGitter | <liquid600pgm> ^ |
| 21:17:18 | Araq | the rename makes it 100% backwards compatible |
| 21:17:51 | FromGitter | <Clyybber> Ah, I see. |
| 21:17:53 | Araq | we don't have to deprecate options.nim either, it can stay as the combined module it is in the PR |
| 21:17:54 | dom96 | Araq: Yes, the documentation is a problem, but that's a docgen problem. Don't modify perfectly good modules to work around deficiencies in the doc gen. In fact, I suggested we fix this in a recent issue. |
| 21:18:04 | * | rnrwashere quit (Remote host closed the connection) |
| 21:18:28 | dom96 | The rename is what bothers me the most. There is no reason for it at all |
| 21:18:40 | Araq | your "fix" is debatable too. system.nim aside, if modules are so big that they have different sections, maybe they should be split up further |
| 21:18:41 | dom96 | You'll just have people using `options` and `optionals` and getting confused |
| 21:18:49 | FromGitter | <Clyybber> Regarding docgen; it seems that the HCR documentation somehow spilled into system |
| 21:19:41 | dom96 | Araq: The amount of modules I need to import already is kinda ridiculous |
| 21:19:49 | dom96 | We split modules up too much |
| 21:20:10 | Araq | totally disagree and there is always 'include prelude' |
| 21:21:42 | * | ng0 quit (Remote host closed the connection) |
| 21:22:03 | dom96 | There is definitely a balance. Options is very small as it is, splitting it up isn't worthwhile. |
| 21:22:09 | dom96 | Focus on splitting the system behemoth |
| 21:22:41 | * | ng0 joined #nim |
| 21:23:49 | FromGitter | <arnetheduck> what are the first principles that drive nim std library design? |
| 21:25:12 | Araq | one principle is that the stdlib needs to cover what otherwise causes interop problems |
| 21:25:30 | Araq | this means we strive to have one std Option[T] type instead of people rolling their own |
| 21:25:37 | FromGitter | <kaushalmodi> options and optionals is too confusing .. nothing about its naming tells what is superset of what |
| 21:25:52 | FromGitter | <kaushalmodi> if you really do want to rename, options_core makes more sense |
| 21:26:00 | FromGitter | <kaushalmodi> options_core and options_extra |
| 21:26:03 | shashlick | not bad, ran all tests in 4:04 |
| 21:26:24 | FromGitter | <liquid600pgm> looking through the `system` module, I already see some weirdness (why is `addEscapedChar` and `addQuoted` in `system` and not `strutils`?) |
| 21:27:01 | dom96 | liquid600pgm: indeed, this is what we should be fixing. |
| 21:27:06 | Araq | arnetheduck: and that's the thing, for interop usually one the type is required, most "utils" on top of the type are not required |
| 21:27:18 | dom96 | There is absolutely no problem caused by these extra options features |
| 21:27:37 | Araq | dom96: we're working on cleaning up system.nim, yes |
| 21:27:38 | FromGitter | <Clyybber> I also vote for removing/deprecating `flatMap` as it seems not really useful, compared to just writing `map(something, someproc).flatten` |
| 21:27:59 | dom96 | but yes, even I can accept removing flatten and filter. |
| 21:28:16 | dom96 | Clyybber: flatMap looks useful to me, as it says in the docs: chaining |
| 21:28:20 | FromGitter | <arnetheduck> re map/filter etc, it's actually very convenient to be able to treat options as collections of 0 or 1 items |
| 21:28:54 | FromGitter | <Clyybber> @dom96 But isn't it just syntactic sugar for `something.map(someproc).flatten? |
| 21:28:58 | * | Vladar quit (Remote host closed the connection) |
| 21:28:59 | dom96 | yeah, it is when you're thinking in the FP mindset, and there is absolutely nothing wrong with that. |
| 21:29:02 | FromGitter | <alehander42> so the only explanation i see is that `options <core>` might be useful even for limited-resource targets |
| 21:29:04 | FromGitter | <arnetheduck> one way to view them is a special case of a seq - once you start doing that, you realize that there's a whole class of algorithms that apply to them |
| 21:29:12 | FromGitter | <alehander42> but then you can just have `when` inside options for the utils |
| 21:29:26 | FromGitter | <alehander42> i also think having several option-related modules is just annoying |
| 21:29:53 | FromGitter | <Clyybber> @dom96 So is there any advantage over using flatMap instead of chaining map and flatten? |
| 21:29:57 | dom96 | Clyybber: I don't think so. |
| 21:30:08 | FromGitter | <Clyybber> Then I would remove it |
| 21:30:13 | FromGitter | <Clyybber> or deprecate it |
| 21:30:20 | dom96 | Clyybber: Maybe I'm missing something but `flatten` doesn't work there |
| 21:30:35 | FromGitter | <Clyybber> flatMap is using it itself though |
| 21:31:05 | dom96 | oh huh |
| 21:32:27 | FromGitter | <Clyybber> Also there isn't any flatMap for seqs or other collections |
| 21:32:59 | dom96 | yeah, meh, I wouldn't mind it being removed |
| 21:33:13 | dom96 | just like I wouldn't mind the others being removed either because I don't use them |
| 21:33:24 | dom96 | flatMap has a good argument for removal |
| 21:33:39 | dom96 | but moving it to another module and renaming `options` doesn't have a good argument |
| 21:34:13 | Araq | but somebody fought for getting it in, because Haskel and Scala |
| 21:34:30 | Araq | and it's just a single proc among other crap I never use |
| 21:35:09 | Araq | so we might as well do nothing whatsoever then |
| 21:35:21 | FromGitter | <arnetheduck> a set of first principles would help inform a lot of decisions regarding the std lib.. it has grown organically over 10 years and sprouts in call kinds of directions and levels of quality ⏎ I'd also claim that small or large module doesn't matter that much as long as there exists a systematic way of discovering what's were - a red line that allows one to internalize a mental map of the library such that it becomes |
| 21:35:21 | FromGitter | ... natural where to find things.. this goes for naming, module size, how the cake is sliced, folders (pure/std/core/wtf?).. in that quest, I'd ruthlessly rename and minimize, using the 10 years of nim experience to whittle it down to its essence, then build from there and let the sprawl and experimentation happen in ... [https://gitter.im/nim-lang/Nim?at=5c803d19d1e7281f09e7fa90] |
| 21:37:03 | dom96 | arnetheduck: Are you volunteering to do this job? ;) |
| 21:37:44 | FromGitter | <arnetheduck> there tends to be resistance from people saying that things shouldn't be renamed or removed.. |
| 21:38:28 | shashlick | how does it really matter - unused stuff gets dumped at compile time anyway |
| 21:38:44 | shashlick | and as a user, i have to search the whole stdlib for pros anyway |
| 21:39:15 | FromGitter | <arnetheduck> even for those that prefer stability, libraries offer the better tradeoff because they can lock their version and only upgrade when necessary.. std lib is much harder, it's an all-or-nothing proposition |
| 21:39:17 | dom96 | If someone comes up with a cohesive vision and makes good arguments for why renames need to happen then there won't be resistance |
| 21:39:22 | dom96 | at least from me |
| 21:39:56 | FromGitter | <Clyybber> Options without any documentation or runnable examples sits at about 100 loc, which speaks for not splitting it IMO |
| 21:40:19 | dom96 | yep, it's a tiny module |
| 21:40:44 | Araq | at least we all agree that system.nim must be trimmed and we're working on it |
| 21:40:47 | shashlick | well it annoys me that i have to include strutils and strformat when both are arguably utils, but ya |
| 21:42:29 | shashlick | modules should be logically grouped |
| 21:42:43 | shashlick | if files are large, split them but keep them in the same namespace using include or something |
| 21:43:03 | shashlick | don't make a user import 20 things just cause you want the stdlib to be organized |
| 21:43:24 | Araq | 'include prelude' |
| 21:43:33 | FromGitter | <Clyybber> @dom96 Would I have to deprecate flatMap first? I don't think anyone uses it, so should I just remove it? |
| 21:43:35 | Araq | it isn't well known |
| 21:43:40 | dom96 | Funny, that would be one advantage of a hierarchy: import str/* |
| 21:43:43 | FromGitter | <arnetheduck> boost tends to offer both worlds with a hierarchy.. of course, c++ has a richer namespace system as well |
| 21:43:46 | Araq | but it's a nice solution IMO |
| 21:44:23 | shashlick | saving user time and confusion is #1 priority |
| 21:45:00 | shashlick | in fact, it will be nice if nim could tell me I imported a module from which I didn't use anything |
| 21:45:13 | shashlick | to get rid of cruft, but going off topic now |
| 21:45:21 | FromGitter | <Clyybber> Thats a good idea |
| 21:45:23 | Araq | "confusion" is a red herring, everybody is always confused by everything, it's convenient to blame Nim for one's own shortcomings |
| 21:46:06 | * | rockcavera joined #nim |
| 21:46:43 | FromDiscord | <exelotl> uh |
| 21:46:48 | FromGitter | <liquid600pgm> offtopic: whoever implemented that feature where when you press shift + enter when editing a nim source file in vscode, the terminal gets focused and `nim secret` is executed, should be punished for making such an annoyance |
| 21:47:14 | dom96 | liquid600pgm: :/ |
| 21:47:22 | FromGitter | <liquid600pgm> was it you? |
| 21:47:30 | dom96 | No, I'm just sharing in your pain :( |
| 21:47:36 | FromGitter | <liquid600pgm> aah |
| 21:47:54 | dom96 | I guess I have an old version so I don't have this "feature" |
| 21:48:08 | Araq | I never press shift+enter |
| 21:48:13 | FromGitter | <arnetheduck> not really a red herring imo.. the langauge can gently guide people to do the right thing while at the same time allowing power use.. blame the user seems like a shitty excuse for not improving ergonomics |
| 21:49:00 | FromDiscord | <exelotl> yeah that ^ |
| 21:49:04 | Araq | it's not an excuse, it's my experience. |
| 21:49:22 | FromGitter | <liquid600pgm> Araq: sometimes I accidentally press shift+enter sometimes when I type a character with shift pressed and want to make a line break |
| 21:49:37 | shashlick | vote is to split large files but keep import and docgen together - like system |
| 21:49:45 | FromGitter | <liquid600pgm> (oops, typed "sometimes" twice) |
| 21:50:08 | shashlick | i'm also good for consolidating two modules that are related into one namespace |
| 21:51:35 | FromDiscord | <exelotl> sure confusion is inevitable but that doesn't mean we shouldn't strive to reduce it |
| 21:56:36 | * | jjido joined #nim |
| 21:58:23 | dom96 | liquid600pgm: there is probably some way to disable it |
| 21:59:49 | Araq | flatMap is confusing, every rename like options->optionals is confusing, preventing deadlocks at compiletime via an effect system is confusing, ... everything is confusing. |
| 22:01:12 | Araq | I personally find Python's 'def' (verb?) vs 'class' (noun) confusing. |
| 22:01:16 | FromGitter | <Clyybber> flatMap isn't confusing it's just unneccessary. |
| 22:01:39 | FromGitter | <Clyybber> But it doesn't hurt to keep it either |
| 22:01:52 | FromGitter | <Clyybber> especially since apparently many other functional languages have it |
| 22:02:11 | FromGitter | <liquid600pgm> wait a second |
| 22:02:22 | FromGitter | <liquid600pgm> so nim's a functional language? |
| 22:03:31 | FromGitter | <liquid600pgm> i thought it's imperative with functional bits and pieces (like python or javascript) |
| 22:03:39 | FromGitter | <Clyybber> Can also be functional |
| 22:04:00 | FromGitter | <Clyybber> But it doesn't compile down to lambda calculus as its IR like ghc does |
| 22:04:08 | dom96 | liquid600pgm: that is precisely the right description |
| 22:04:50 | FromGitter | <liquid600pgm> gosh i forgot about the existence of `func` since I only use the imperative parts |
| 22:05:01 | dom96 | what happens is we get people who love FP who create a PR and it gets accepted and we get more FP features in the stdlib |
| 22:05:08 | dom96 | Which is cool, but can become too much |
| 22:06:44 | FromGitter | <liquid600pgm> just as a side note, i remember being annoyed by the sheer amount of reserved keywords nim had when i discovered it. i couldn't stand the fact that `type` was reserved, but learned to use `kind` instead and i like it a lot more |
| 22:07:34 | FromGitter | <alehander42> btw renderer.nim can I easily generate newlines |
| 22:07:40 | FromGitter | <alehander42> i think there was a way but i forgot |
| 22:08:12 | FromGitter | <alehander42> nkEmpty? |
| 22:08:14 | Araq | it's not even about FP, we have times.nim (growing), os.nim (growing), strutils.nim (growing) and options.nim (PRs in the queue to grow it) |
| 22:08:52 | Araq | growing isn't bad, but I like to split up modules to fight it |
| 22:09:20 | Araq | apparently I'm in the minority here, that's ok, I can work on more important things |
| 22:10:20 | shashlick | Araq - what is your rationale to split? |
| 22:10:35 | shashlick | affects compile time? |
| 22:11:05 | Araq | as I said, compiletimes and doc navigation |
| 22:12:25 | shashlick | keeping compile times aside for a sec, as a user who doesn't know what to look for, you search the whole index. if you know what to look for, it makes no diff - if you load the module page, there's an index up top |
| 22:13:20 | shashlick | trying to understand your concern, and perhaps if there's a doc solution for it |
| 22:13:22 | * | theelous3_ joined #nim |
| 22:16:34 | Araq | I don't think there are good solutions. Small core lib that has the *type* (required for interop) plus utils in a nimble package, for example, doesn't work for people who cannot use Nimble because they are behind some firewall |
| 22:17:45 | Araq | I'm biased against package management though, it's not a secret. |
| 22:19:05 | shashlick | that distributes the docs even further away from each other |
| 22:19:29 | Araq | well it's not what I'm proposing, but sure |
| 22:21:05 | shashlick | is it possible at compile time to skip complete processing of code chunks that you know aren't referenced in the caller |
| 22:23:07 | Araq | sure but incremental-compilation is the more complete answer |
| 22:23:33 | shashlick | that's why I was wondering why compile time matters, cause that's already being worked in a larger scope |
| 22:23:51 | * | theelous3_ quit (Ping timeout: 252 seconds) |
| 22:23:52 | shashlick | docs could be organized with sections or soemthing |
| 22:24:06 | shashlick | split code into multiple files then each file is a section in that module, stuff grouped together |
| 22:25:22 | Araq | well then we have cruft that doesn't affect compile-times and isn't in the final binary either. Then we only hide it in the docs and tada, cruft can remain forever |
| 22:26:11 | dom96 | IMO this is a purely nim doc gen issue |
| 22:27:05 | shashlick | well it isn't cruft if someone uses it |
| 22:27:34 | shashlick | otherwise it is arguable to keep it in the stdlib in the first place |
| 22:27:51 | Araq | right, so person A uses it, person B reads A's code and needs to understand it and person C finds a bug in it. |
| 22:27:56 | * | sealmove joined #nim |
| 22:28:26 | Araq | we're getting closer now, it's not a tooling problem. |
| 22:29:26 | FromGitter | <alehander42> can i see types inheriting other on CT |
| 22:30:16 | shashlick | so are you concerned about code sitting in the stdlib that is orphaned and unmaintained? |
| 22:30:31 | FromGitter | <alehander42> actually, can I iterate through all functions with the same name on CT ? |
| 22:30:45 | FromGitter | <alehander42> and access their first arg? |
| 22:33:37 | Araq | shashlick: no, I'm telling you there is no free lunch in complex systems and complexity is better avoided than patched over |
| 22:35:30 | FromGitter | <alehander42> maybe i can just have an init macro |
| 22:39:39 | shashlick | Araq: understood, but I still don't get your concern and why splitting modules will help |
| 22:40:22 | Araq | it helps a little, at least it doesn't require yet another docgen feature :P |
| 22:41:26 | Araq | it also means I can import the essentials of Option[T] without the cruft so I'm less likely to roll my own Option type |
| 22:42:27 | * | Jesin quit (Ping timeout: 240 seconds) |
| 22:44:13 | * | lritter quit (Ping timeout: 245 seconds) |
| 22:44:48 | Araq | that's a psychological thing. I'm of course a superhuman rational being and don't roll my own Option type, but others can be confused (:P) and don't realize it's optimized away |
| 22:46:08 | FromGitter | <alehander42> but why would i import the option type and then need to import a whole new module for operating with it |
| 22:46:34 | FromGitter | <alehander42> i mean, i understand your viewpoint, but i think 80% of the normal users will be just annoyed at having to do that |
| 22:48:08 | Araq | well I can flip the argument around and say "the import list is just something the IDE fills out for you, like C# and Java IDEs do it" |
| 22:51:43 | shashlick | Araq, I think you are not accounting for the fact that you aren't an ordinary user |
| 22:52:06 | shashlick | ordinary users glaze over things they don't understand, they only see what they want and everything else is invisible |
| 22:56:24 | FromGitter | <Clyybber> @Araq `str = newString(somelen)` shouldn't be different to `str.setLen(somelen)`, right? |
| 22:56:42 | FromGitter | <Clyybber> I mean functionally, because I have a function where the latter is crashing |
| 22:56:55 | FromGitter | <Clyybber> but the former isn't |
| 22:57:18 | Araq | they are different |
| 22:57:33 | FromGitter | <Clyybber> As in performance? |
| 22:57:39 | Araq | one creates a new buffer, the other resets its internal length field |
| 22:58:18 | Araq | the contents remain up to the length you provided |
| 22:59:29 | * | rnrwashere joined #nim |
| 22:59:43 | FromGitter | <Clyybber> Ok, so that isn't the culprit |
| 23:00:09 | Araq | shashlick: maybe |
| 23:03:19 | * | rnrwashere quit (Remote host closed the connection) |
| 23:04:00 | * | rnrwashere joined #nim |
| 23:04:19 | FromGitter | <Clyybber> I have a proc that returns string ⏎ If I use the implicit result variable I get this error: ⏎ ⏎ ```code paste, see link``` ⏎ ... [https://gitter.im/nim-lang/Nim?at=5c8051f33162ec7bc72da788] |
| 23:05:12 | FromGitter | <Clyybber> For reference this is the proc: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c80522886e34a126f9b6c31] |
| 23:07:21 | FromDiscord | <citycide> Splitting a small module like options doesn't make a lot of sense IMO. alehander42 has it right that nobody wants to import multiple modules to work with a type |
| 23:08:22 | FromDiscord | <citycide> I've started to use F# pretty heavily and I'm a huge fan of it in almost every way, but .NET's module system is very good |
| 23:09:06 | FromDiscord | <citycide> And I think Nim would benefit from more hierarchy in it's module system |
| 23:09:33 | Araq | heresy |
| 23:09:50 | FromDiscord | <citycide> :) |
| 23:10:17 | Araq | and how do we get more hierarchy without module splits anyway :P |
| 23:11:14 | Araq | Clyybber: seems to me to be a different problem, are you sure unzip_size_guess has reasonable values? |
| 23:13:33 | FromGitter | <Clyybber> It gets very big indeed, in my use case in the range from 100000 to 3000000 |
| 23:13:42 | FromDiscord | <citycide> They need to be split logically is all. I don't like the idea of options + optionsutils because if you need one you'll probably need the other |
| 23:14:42 | Araq | the original point was that most/some people don't need optionutils |
| 23:15:05 | FromDiscord | <citycide> But splitting system makes sense, most Lang's have separate modules for file IO and things |
| 23:15:14 | FromGitter | <Clyybber> @Araq But whats weird is that it works when I write `var result = newString(int(unzip_size_guess))` instead of `result = newString(int(unzip_size_guess))` |
| 23:15:37 | Araq | yup, totally |
| 23:15:54 | FromDiscord | <citycide> Araq: that's surprising |
| 23:16:21 | Araq | 3000000 is still less than 3MB, right? |
| 23:17:15 | FromGitter | <Clyybber> Yeah, I think so. |
| 23:20:05 | FromGitter | <Clyybber> It only crashes on specific inputs too. |
| 23:21:06 | Araq | run it with valgrind and call GC_disable() on startup |
| 23:21:16 | Araq | if you can. |
| 23:21:20 | Araq | good night. |
| 23:22:41 | FromGitter | <Clyybber> Good night |
| 23:35:12 | luis_ | Hi all, does Nim implements anything similar to Swift extensions? |
| 23:36:04 | dom96 | Nim doesn't need 'extensions' |
| 23:36:16 | dom96 | The double example from https://docs.swift.org/swift-book/LanguageGuide/Extensions.html |
| 23:36:42 | dom96 | You can just write: proc km(self: Double): Double = self * 1_000.0 |
| 23:36:44 | dom96 | etc. |
| 23:36:56 | dom96 | and Double(25.0).km will work |
| 23:37:41 | dom96 | well, better example would be: proc km(self: float): float = self * 1_000.0; 25.4.km |
| 23:38:56 | luis_ | Thank you, this is great... will check it out... I spent the day getting to know the language, it is impressive how far it got. How many core developers are working in it today? |
| 23:39:31 | dom96 | You'll have to ask Araq that :) |
| 23:39:49 | Araq | 3 |
| 23:40:03 | dom96 | Also depends how you define "working", if you mean full-time then probably that number ^ |
| 23:42:33 | krux02 | luis_, the github project alse lists a lot of other contributers thet should not be missed out |
| 23:42:55 | Araq | krux02: shouldn't you be sleeping? |
| 23:43:52 | krux02 | yes |
| 23:44:22 | Araq | I know I should, bye |
| 23:45:43 | krux02 | bye |
| 23:53:30 | * | couven92 quit (Ping timeout: 252 seconds) |
| 23:58:18 | * | krux02 quit (Remote host closed the connection) |