00:00:18 | * | space-wizard joined #nim |
00:01:30 | * | space-wizard quit (Read error: Connection reset by peer) |
00:02:37 | federico3 | is 0.16.0 compatible with OpenSSL 1.1? |
00:07:43 | * | pregress_ quit (Remote host closed the connection) |
00:25:03 | * | PMunch joined #nim |
00:31:23 | FromGitter | <zacharycarter> Hi - I'm trying to compile : https://github.com/Halsys/nim-bgfx - I have the C Library this nim library binds to built and I have the dylib on my machine, but I have absolutely no idea how to link to the library with the nim compiler. I tried ./nim c --clib:lib.dylib but that didn't work, could someone give me some tips? |
00:32:56 | ftsf | zacharycarter: https://github.com/Halsys/nim-bgfx/blob/master/bgfx.nim#L14 you can see there it links to the specified library name. Does it exist with that name? |
00:33:43 | FromGitter | <zacharycarter> it does, but not in the directory, let me try copying it to the directory I'm compiling in |
00:34:14 | ftsf | I think you can pass -L/directory/ to specify where to look for libraries |
00:34:31 | FromGitter | <zacharycarter> ah okay thank you good to know |
00:35:56 | FromGitter | <zacharycarter> I always get an error on this line - https://github.com/Halsys/nim-bgfx/blob/master/bgfx.nim#L394 |
00:36:02 | FromGitter | <zacharycarter> bgfx.nim(394, 60) Error: undeclared identifier: 'RendererType_Null' |
00:36:12 | FromGitter | <zacharycarter> nim c --clib:libgfx-shared-libDebug.dylib bgfx |
00:36:14 | FromGitter | <zacharycarter> is the command I"m running |
00:37:10 | ftsf | sorry -passL:"-L /directory" |
00:37:10 | ftsf | --passL: ... |
00:37:10 | ftsf | which will pass whatever you give directly to the linker |
00:37:10 | ftsf | I also get that error when trying to build it |
00:37:11 | ftsf | but that's not a linker error |
00:37:11 | ftsf | it's using an identifier that isn't defined |
00:37:35 | FromGitter | <zacharycarter> ah okay - maybe I'm missing headers then |
00:37:50 | ftsf | nope, line #50 lists the RendererTypes |
00:37:58 | ftsf | Null is not present, maybe it should be Noop |
00:38:16 | ftsf | changing it to noop makes it compile |
00:38:44 | FromGitter | <zacharycarter> thank yo |
00:38:46 | FromGitter | <zacharycarter> you* |
00:40:52 | ftsf | np, looks like a bug in the library |
00:41:10 | FromGitter | <zacharycarter> yeah, I don't have much confidence in these bindings |
00:41:35 | FromGitter | <zacharycarter> especially because of the line - There might be a incompatibility with nims garbage collection system. |
00:41:54 | ftsf | yeah |
00:42:25 | * | devted joined #nim |
00:47:45 | FromGitter | <Varriount> @zacharycarter Which line? |
00:48:03 | FromGitter | <zacharycarter> number 7 in the readme of that repo @Varriount |
00:56:44 | * | dmi0 quit (Ping timeout: 260 seconds) |
01:05:10 | * | aziz quit (Remote host closed the connection) |
01:07:58 | ftsf | hmm I notice nim changes my procs to {.closure.} if i capture a variable, even if i specify another calling convention, it'd be nice to have an error instead of silently ignoring my desired calling convention |
01:14:04 | * | subsetpark joined #nim |
01:19:46 | * | space-wizard joined #nim |
01:47:07 | * | Snircle quit (Ping timeout: 240 seconds) |
01:48:43 | FromGitter | <zacharycarter> finally got the nim-bgfx project running |
01:48:52 | FromGitter | <zacharycarter> window opens, then freezes :D |
01:49:58 | ftsf | =) |
02:12:11 | * | dddddd quit (Quit: Hasta otra..) |
02:15:05 | * | vlad1777d quit (Remote host closed the connection) |
02:19:45 | * | Kingsquee joined #nim |
02:23:40 | * | couven92 quit (Quit: Client disconnecting) |
02:36:25 | * | chemist69 quit (Disconnected by services) |
02:36:30 | * | chemist69_ joined #nim |
03:03:12 | * | Gonzih quit (Ping timeout: 240 seconds) |
03:25:37 | * | brson quit (Quit: leaving) |
03:30:32 | * | Gonzih joined #nim |
03:42:12 | def-pri-pub | HTML5 Canvas for Nim's JS target is about to be ready soon: https://gitlab.com/define-private-public/HTML5-Canvas-Nim |
03:42:27 | def-pri-pub | All I've got to do next is clean a few things up and add the transform functions. |
03:42:42 | def-pri-pub | (And Patterns too) |
03:44:45 | ftsf | def-pri-pub, nice |
03:45:41 | def-pri-pub | It's been more tedious than I thought it would be, and I'm binding way more things that only the Canvas tag and a RenderingContext. I fell bad because there are many other functions I have to ignore because of browser compatiblity |
03:46:10 | def-pri-pub | I plan on writing a light wrapper for XMLHttpRequest next, so Nim+Js can then do AJAX calls. |
03:47:12 | * | Gonzih quit (Ping timeout: 240 seconds) |
03:56:44 | * | Gonzih joined #nim |
03:57:03 | * | PMunch quit (Quit: leaving) |
04:16:14 | * | devted quit (Quit: Sleeping.) |
04:24:07 | * | Gonzih quit (Ping timeout: 240 seconds) |
04:43:18 | * | Gonzih joined #nim |
05:28:46 | * | s4 joined #nim |
05:37:39 | * | chemist69_ quit (Ping timeout: 255 seconds) |
05:38:03 | * | chemist69 joined #nim |
06:06:46 | * | vlad1777d joined #nim |
06:15:44 | * | onionhammer quit (Read error: Connection reset by peer) |
06:16:54 | * | onionhammer joined #nim |
06:29:14 | def-pri-pub | night peeps |
06:29:22 | * | nsf joined #nim |
06:29:25 | * | def-pri-pub quit (Quit: leaving) |
06:29:56 | ftsf | night |
06:41:01 | * | bjz joined #nim |
06:46:30 | * | yglukhov joined #nim |
06:46:31 | * | bjz quit (Read error: Connection reset by peer) |
06:50:02 | * | bjz joined #nim |
06:51:37 | * | yglukhov quit (Ping timeout: 240 seconds) |
06:54:33 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
07:02:33 | * | ftsf quit (Quit: :q!) |
07:26:46 | * | subsetpark quit (Quit: Connection closed for inactivity) |
07:28:09 | * | Ven joined #nim |
07:28:20 | * | fifr quit (Quit: WeeChat 1.1.1) |
07:28:51 | * | fifr joined #nim |
07:31:30 | * | bjz joined #nim |
07:32:11 | * | fifr quit (Client Quit) |
07:32:25 | * | fifr joined #nim |
07:35:26 | * | rokups joined #nim |
07:39:34 | * | fifr quit (Quit: WeeChat 1.1.1) |
07:39:48 | * | fifr joined #nim |
07:40:46 | * | fifr quit (Client Quit) |
07:41:14 | * | fifr joined #nim |
07:50:32 | * | dmi0 joined #nim |
08:08:06 | * | dmi0 quit (Ping timeout: 240 seconds) |
08:32:50 | * | yglukhov joined #nim |
08:37:17 | * | yglukhov quit (Ping timeout: 245 seconds) |
08:42:37 | * | yglukhov joined #nim |
08:46:41 | * | Vladar joined #nim |
09:00:16 | * | yglukhov quit (Read error: Connection reset by peer) |
09:00:36 | * | yglukhov joined #nim |
09:19:33 | * | yglukhov_ joined #nim |
09:20:37 | FromGitter | <andreaferretti> ideally, AsyncHttpClient should work on js, using XMLHttpRequest there |
09:22:42 | * | yglukhov quit (Ping timeout: 245 seconds) |
09:22:46 | Araq | when you have something that works, patch my dochack.nim |
09:22:57 | Araq | it uses the sync API from JS that's deprecated |
09:32:46 | FromGitter | <andreaferretti> Unfortunately the new release broke my linear algebra library :-( |
09:32:53 | FromGitter | <andreaferretti> https://github.com/nim-lang/Nim/commit/bf612a7f19e0e6a112b0169185b0bb3a34b2722d seems to be the root cause |
09:34:49 | Araq | use 0.16.0 then, that lacks this commit |
09:34:59 | Araq | oh wait |
09:35:10 | Araq | you just said it's in 0.16.0. hmmm |
09:35:18 | * | bodie_ quit (*.net *.split) |
09:35:22 | Araq | sneaky zahary commit |
09:36:06 | FromGitter | <andreaferretti> :-D |
09:36:56 | * | bodie_ joined #nim |
09:36:56 | FromGitter | <andreaferretti> well, apart from that I am just trying to ensure that it still will work in the future |
09:37:18 | * | javax quit (*.net *.split) |
09:37:27 | * | javax joined #nim |
09:38:48 | * | flyx quit (*.net *.split) |
09:38:48 | * | pafmaf quit (*.net *.split) |
09:38:48 | * | qwertfisch quit (*.net *.split) |
09:38:48 | * | rektide quit (*.net *.split) |
09:38:48 | * | jackv quit (*.net *.split) |
09:38:48 | * | lenstr quit (*.net *.split) |
09:38:48 | * | ofelas quit (*.net *.split) |
09:38:48 | * | def- quit (*.net *.split) |
09:38:56 | * | LeNsTR joined #nim |
09:39:00 | * | def- joined #nim |
09:39:01 | * | rektide joined #nim |
09:39:07 | * | athie quit (*.net *.split) |
09:39:07 | * | pleiosaur quit (*.net *.split) |
09:39:07 | * | MonsterAbyss quit (*.net *.split) |
09:39:20 | * | ofelas joined #nim |
09:39:22 | * | flyx joined #nim |
09:39:24 | * | qwertfisch joined #nim |
09:40:02 | Araq | commit bf612a7f19e0e6a112b0169185b0bb3a34b2722d |
09:40:02 | Araq | Author: Zahary Karadjov <[email protected]> |
09:40:03 | Araq | Date: Wed Nov 30 23:00:44 2016 +0200 |
09:40:04 | Araq | fix #4884 |
09:40:06 | Araq | commit 5947403e84ba44397b35f93f9d327c76e794210f |
09:40:08 | Araq | Author: Dominik Picheta <[email protected]> |
09:40:10 | Araq | Date: Sun Jan 8 21:23:15 2017 +0100 |
09:40:12 | Araq | Small fixes in readme. |
09:40:13 | * | athie joined #nim |
09:40:14 | Araq | commit b040f74356748653dab491e0c2796549c1db4ac3 (tag: v0.16.0) |
09:40:16 | Araq | Author: Dominik Picheta <[email protected]> |
09:40:18 | Araq | Date: Sun Jan 8 20:52:53 2017 +0100 |
09:40:20 | Araq | Fix C source gen. |
09:40:22 | Araq | so that commit is not in 0.16.0. |
09:40:23 | * | MonsterAbyss joined #nim |
09:40:24 | Araq | does your library work with 0.16.0? |
09:41:07 | * | jackv joined #nim |
09:42:00 | FromGitter | <andreaferretti> You're right, it does |
09:42:06 | FromGitter | <andreaferretti> 1) 16.0 is fine |
09:42:24 | FromGitter | <andreaferretti> for some reason, I was convinced that 0.16 was released later |
09:44:09 | Araq | ok, no worries then, zahary is aware and working on this problem |
09:44:14 | * | pleiosaur joined #nim |
09:44:23 | FromGitter | <andreaferretti> great! :-) |
09:57:00 | * | maxgonzih joined #nim |
09:57:00 | * | GustavoLapasta joined #nim |
09:59:36 | * | Gonzih quit (Ping timeout: 240 seconds) |
10:03:07 | * | maxgonzih quit (Ping timeout: 245 seconds) |
10:03:13 | * | Gonzih joined #nim |
10:07:15 | * | Salewski joined #nim |
10:10:09 | * | kulelu88 joined #nim |
10:11:43 | Salewski | Araq, it seems that some docs are pointing to old source code. For example shuffle is mentioned in new 0.16 docs, but when I go to source file from docs link there is no shuffle() |
10:11:47 | Salewski | https://github.com/nim-lang/Nim/blob/master/lib/pure/random.nim |
10:12:23 | Araq | Salewski: somebody needs to merge 0.16.0 into master :-) |
10:13:02 | Salewski | And for procs like shuffle(), openarray parameter would be finer :-) |
10:13:14 | Salewski | OK, bye... |
10:13:29 | Araq | it's an openarray? |
10:13:36 | * | Gonzih quit (Ping timeout: 252 seconds) |
10:14:03 | Salewski | Currently it is a seq, like in Rosetta example. |
10:14:43 | * | Gonzih joined #nim |
10:14:45 | Araq | sorry, yeah, this needs to be fixed then |
10:14:47 | Salewski | proc shuffle*[T](x: var seq[T]) = |
10:15:19 | Salewski | No problem, I know PR's are welcome. |
10:15:43 | * | dmi0 joined #nim |
10:16:33 | * | Salewski left #nim (#nim) |
10:21:00 | * | yglukhov joined #nim |
10:21:11 | * | yglukhov quit (Remote host closed the connection) |
10:22:11 | * | yglukhov joined #nim |
10:24:05 | * | yglukhov_ quit (Ping timeout: 256 seconds) |
10:28:43 | * | maxgonzih joined #nim |
10:30:39 | * | Gonzih quit (Ping timeout: 252 seconds) |
10:35:50 | * | maxgonzih quit (Quit: WeeChat 1.6) |
10:38:34 | * | Gonzih joined #nim |
10:38:52 | Araq | can you explain to me again why xxHash is such an important thing? |
10:38:56 | Araq | looks like Nim's hashes.nim |
10:39:02 | Araq | doesn't even look faster but I didn't benchmark it |
10:52:13 | * | Salewski joined #nim |
10:53:14 | Salewski | Araq, xxHash and clHash are very fast and give very good hashes! |
10:53:29 | Salewski | They have best score in SMHasher test. |
10:53:59 | Salewski | So they have very good distribution of keys. |
10:54:43 | Salewski | For very small data other plain hash procs are indeed a bit faster. |
10:55:40 | Salewski | I was playing with a Robin Hood Hash table implementation, which should work fine with 90% fill. |
10:56:12 | Salewski | But that is true only if there are not too many collisions. |
10:57:06 | Salewski | But indeed, xxHash and clHash both are not very important for Nim. |
10:59:06 | Salewski | Indeed I once read a paper from 2008 about a Hopscotch Hash table and started implementing it, but |
10:59:58 | Salewski | then I came to the conclusions that it is just similar to Robin HoodHash, and Robin Hood hash is simpler and maybe even faster. |
11:00:56 | Salewski | Robin Hood idea is from 1986, it is about reordering position of entries, which is very cache friendly. |
11:02:01 | Salewski | I was not very happy with plain textbook hashes, which work fine, but waste much memory, due to max 50% fill. |
11:02:50 | Salewski | But of course, our computers have enough RAM, so that it not really important. |
11:04:07 | cheatfate | Salewski, RAM is important |
11:04:08 | Salewski | Another point is, the Nim Hash-Table module is a good plce to learn advanced Nim design -- still have to look at it more deeply. |
11:04:29 | cheatfate | currently json file of size (20mb) can use 2gb of ram in nim |
11:05:12 | cheatfate | and i dont like such situation, and make some research in robin hood hashing too |
11:06:30 | Salewski | Cheatfate: Yes, it depends. I have a Notebook with only 2 GB Ram, my chess game currently uses Tables module. |
11:07:48 | cheatfate | i dont think its a tables.nim problem, tables is good enough it has only 20-30% overhead in ram usage comparing to my robin hood tables.nim |
11:07:57 | Salewski | That tables module allows max 50% fill, when it increases it allocates a buller of double size, so it consumes 6 times the space of the entries. |
11:08:55 | cheatfate | why only 50%? |
11:10:15 | Salewski | With a bad hashing function, we get too many collisions when more than 50% of entries are occupied. |
11:10:45 | Salewski | And without robin hood strategy, that gives many cache misses. |
11:11:29 | cheatfate | my benchmarks on integers shows that current tables.nim is good enough |
11:11:41 | Salewski | I think the Nim tables module is very similar to general textbook code, and that works fine, but not for high fill rates. |
11:12:42 | Salewski | Hash for integers is generally fast, a better test is strings. See |
11:13:05 | Salewski | https://tessil.github.io//2016/08/29/benchmark-hopscotch-map.html |
11:18:26 | Salewski | That is a nice comparison, but he used only hopscotch with bitset, while original paper uses linked lists, and he unfortunately did not compare to robin hood at all. |
11:30:23 | * | ritualtears quit (Read error: Connection reset by peer) |
11:42:20 | * | Arrrr joined #nim |
11:46:22 | Araq | cheatfate: actually nim's json used to use seqs, not OrderedHashTables for better memory usage |
11:46:39 | Araq | but somebody complained about field access being O(n) |
11:47:03 | Araq | probably we need to use both and switch to OrderedHashTable for when there are lots of keys |
11:48:52 | cheatfate | i dont think its a good idea to use hash table to store json keys, maybe tree or something like that but not hash table... |
11:54:41 | Araq | it's an ordered hash table, the order is kept |
11:54:54 | Araq | apart from the memory usage it's fine |
11:59:28 | * | bjz quit (Ping timeout: 258 seconds) |
12:03:08 | cheatfate | Araq, for what reason json needs an order of keys? i think only order of items in array must be kept |
12:03:53 | cheatfate | the only thing i can say about our current json implementation - its unusable in production |
12:04:06 | cheatfate | just because it eating memory like a monster |
12:04:21 | * | Snircle joined #nim |
12:06:55 | * | bjz joined #nim |
12:07:29 | Araq | others argued the previous impl was unusable in production -.- |
12:08:21 | * | ritualtears joined #nim |
12:08:34 | Araq | json needs order of keys because we use json in Nimble and adding a Nimble package should not produce a tremendous diff |
12:10:09 | Araq | it's what happens when you don't use a database. :P |
12:11:19 | * | yeeve quit (Quit: Leaving) |
12:11:32 | Arrrr | Table concept when |
12:11:45 | zevlg | cheatfate: there is jsmn-like parser in pure nim exists, that could save some memory - https://github.com/OpenSystemsLab/jsmn.nim/ |
12:11:58 | * | GustavoLapasta quit (Quit: Leaving) |
12:26:18 | cheatfate | Araq, maybe nimble needs some kind of package cryptographic signature to maintain order of packages... |
12:26:27 | cheatfate | like other package managers doo |
12:30:09 | Araq | no, it needs to use a database |
12:44:46 | FromGitter | <dom96> @Araq https://news.ycombinator.com/item?id=13360730 |
12:48:09 | FromGitter | <dom96> or maybe we should have introduced a ``sort`` param to the ``json.pretty`` procedure... |
12:48:25 | FromGitter | <dom96> which IIRC was my original suggestion |
12:51:06 | federico3 | dom96: are you talking about #4607 ? |
12:51:43 | Araq | you cannot "pretty" over missing order information, example: user writes json config, json config gets modified, gets outputted again, user expects the order to be the way he left it |
12:52:31 | Araq | that's all besides the point really since an ordinary table is almost as bad when it comes to memory usage |
12:52:59 | Araq | maybe a hash table with robin hood hashing is the way to go |
12:54:10 | * | bjz quit (Ping timeout: 248 seconds) |
12:55:52 | yglukhov | await takes 0.5 seconds to complete. does that sound familiar to anyone? |
12:56:26 | * | bjz joined #nim |
13:00:21 | cheatfate | yglukhov, nimongo? |
13:01:13 | cheatfate | Araq, as i said before robin hood gives you like 15-25% of ram economy |
13:03:05 | yglukhov | cheatfate: found it here: https://github.com/nim-lang/Nim/issues/4262 but its closed. and i can't reproduce it with the given example :( |
13:03:19 | yglukhov | cheatfate: it might be related to nimongo =) |
13:03:43 | FromGitter | <dom96> @federico3: yep |
13:04:12 | cheatfate | yglukhov, i thought we already patched it |
13:04:40 | FromGitter | <dom96> yglukhov: I guess it's a similar but different issue |
13:20:29 | yglukhov | dom96: yep, most likely |
13:22:35 | cheatfate | yglukhov, in most cases this happens because of hacks :) |
13:26:52 | * | Gonzih quit (Ping timeout: 245 seconds) |
13:28:07 | * | Gonzih joined #nim |
13:33:20 | yglukhov | cheatfate: there were no hacks in #4262. |
13:33:38 | yglukhov | so statistically, i can't agree with you ;) |
13:35:09 | * | Kingsquee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
13:39:28 | * | s4 quit (Quit: Konversation terminated!) |
13:41:42 | cheatfate | yglukhov, #4262 is a different thing... it will not cause you 500ms timeouts on await, its an issue about sleepAsync |
13:41:48 | cheatfate | granularity |
13:45:04 | * | Andris_zbx joined #nim |
13:48:53 | * | Sentreen quit (Quit: WeeChat 1.4) |
13:51:46 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
14:06:23 | FromGitter | <martinium> @dom96 I ran a few benchmarks testing a static page using wrk and jester. Requests per second were very impressive |
14:07:22 | * | Sentreen joined #nim |
14:10:13 | federico3 | martinium: wkr? |
14:17:10 | * | fifr quit (Quit: WeeChat 1.1.1) |
14:17:35 | * | fifr joined #nim |
14:27:39 | * | fifr quit (Quit: WeeChat 1.1.1) |
14:27:48 | * | fifr joined #nim |
14:28:40 | * | fifr quit (Client Quit) |
14:28:55 | * | fifr joined #nim |
14:30:05 | euantor | https://github.com/wg/wrk |
14:32:35 | * | fifr quit (Client Quit) |
14:33:31 | * | fifr joined #nim |
14:49:48 | federico3 | thanks |
14:51:10 | * | yglukhov quit () |
14:53:17 | * | yeeve joined #nim |
14:56:58 | * | yglukhov joined #nim |
15:10:06 | * | devted joined #nim |
15:13:10 | * | couven92 joined #nim |
15:42:51 | * | def-pri-pub joined #nim |
15:56:00 | * | couven92 quit (Quit: Client disconnecting) |
16:03:32 | * | kulelu88 quit (Ping timeout: 256 seconds) |
16:05:10 | * | [ui] joined #nim |
16:07:37 | * | nsf quit (Quit: WeeChat 1.6) |
16:08:39 | * | Arrrr left #nim ("WeeChat 1.5") |
16:13:40 | * | rupil joined #nim |
16:14:47 | * | confundus joined #nim |
16:18:20 | * | yglukhov quit (Remote host closed the connection) |
16:19:42 | * | Trustable joined #nim |
16:33:11 | * | kulelu88 joined #nim |
16:40:52 | * | Andris_zbx quit (Remote host closed the connection) |
16:47:22 | chemist69 | abs(0.0) returns -0.0 That's a bit .... unfortunate. |
16:47:33 | chemist69 | python3 |
16:48:24 | chemist69 | sh.. the python3 was pasted into the wrong terminal. I wanted to test the python3 behaviour. Sorry. |
16:58:23 | def-pri-pub | I had a very fun discussion with my Comp. Arch. professor about negative zero a long time ago. |
17:04:57 | Araq | if you confuse 0 with an infinitesimal it all makes sense |
17:08:10 | * | PMunch joined #nim |
17:11:39 | * | pregressive joined #nim |
17:13:45 | chemist69 | yeah, but when you use abs(), you don't expect to get a number returned with a negative sign in front of it. |
17:13:48 | * | kulelu88 quit (Ping timeout: 252 seconds) |
17:14:17 | chemist69 | Araq: would you mind a PR "fixing" this? |
17:16:29 | PMunch | Hmm, that is unfortunate :S |
17:16:45 | PMunch | What is -0.0 anyways? A floating point error? |
17:16:46 | FromGitter | <andreaferretti> I agree |
17:17:04 | FromGitter | <andreaferretti> the floating point standard actually includes -0.0 |
17:17:13 | FromGitter | <andreaferretti> but abs(0.0) should definitely by 0.0 |
17:20:39 | Araq | chemist69: no no, I agree, it should return +0.0 |
17:21:21 | chemist69 | the effect seems to come from the "AbsF64" magic used in the definition, if you remove it, abs(0.0) returns 0.0 |
17:23:03 | PMunch | Yeah |
17:23:16 | PMunch | I was just about to say that abs(0.0) returns positive 0.0 :S |
17:23:49 | Araq | "($1 > 0? ($1) : -($1))", # AbsF64; BUGFIX: fabs() makes problems |
17:23:49 | Araq | # for Tiny C, so we don't use it |
17:24:04 | Araq | yay bugs because of insufficient C compilers |
17:24:26 | Araq | can we generate fabs() now? was Tiny C updated? |
17:24:44 | chemist69 | indeed I am running this on Tiny C |
17:26:11 | * | kulelu88 joined #nim |
17:26:12 | FromGitter | <andreaferretti> it looks like the issue is > instead of >= |
17:27:00 | Araq | chemist69: really? o.O |
17:27:23 | chemist69 | yes, but I just tested with gcc and got also -0.0 |
17:27:30 | FromGitter | <andreaferretti> or alternatively |
17:27:33 | Araq | yes the logic is wrong :P |
17:27:39 | FromGitter | <andreaferretti> ($1 < 0? -($1) : ($1)) |
17:29:09 | chemist69 | bbl |
17:29:47 | Araq | ok, fixed |
17:30:48 | dom96 | hey guys |
17:32:06 | * | kulelu88 quit (Ping timeout: 240 seconds) |
17:39:18 | * | irrequietus quit (Ping timeout: 256 seconds) |
17:41:06 | * | MonsterAbyss quit (Ping timeout: 248 seconds) |
17:41:52 | * | irrequietus joined #nim |
17:43:56 | * | kulelu88 joined #nim |
17:46:38 | * | MonsterAbyss joined #nim |
17:51:27 | * | bodie_ quit (Ping timeout: 245 seconds) |
17:51:35 | * | zxtx quit (Ping timeout: 255 seconds) |
17:54:23 | * | d10n quit (Ping timeout: 245 seconds) |
17:55:15 | * | zxtx joined #nim |
18:00:45 | * | bodie_ joined #nim |
18:01:55 | * | d10n joined #nim |
18:01:55 | * | d10n quit (Changing host) |
18:01:55 | * | d10n joined #nim |
18:08:54 | * | nsf joined #nim |
18:10:26 | * | yglukhov joined #nim |
18:12:19 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
18:15:19 | * | Salewski quit (Quit: Salewski) |
18:15:24 | * | irrequietus quit (Ping timeout: 252 seconds) |
18:15:28 | * | irrequietus_ joined #nim |
18:15:29 | * | Salewski joined #nim |
18:15:35 | * | irrequietus_ quit (Client Quit) |
18:21:33 | FromGitter | <Varriount> @Araq Are you sure you couldn't have been a bit more tactful in that forum post regarding the installer. >_< |
18:22:23 | FromGitter | <tekjar> @dom96 Hi dom. Do you have any plans for adding a `new` command to nimble for creating a new package? |
18:22:30 | FromGitter | <tekjar> https://github.com/nim-lang/nimble |
18:22:52 | dom96 | tekjar: this already exists as `init`, unless you're thinking of something else. |
18:23:03 | FromGitter | <tekjar> The code there is seggregated into `src` and `tests` and nimble.nimble |
18:23:19 | FromGitter | <tekjar> Why not enforce it with `nimble init` or `nimble new` |
18:23:55 | Araq | Varriount: certainly I could have been. but it was a misunderstanding. |
18:24:45 | FromGitter | <tekjar> while https://github.com/dom96/jester |
18:24:59 | FromGitter | <tekjar> sources are arranged differently here |
18:25:10 | FromGitter | <tekjar> Is there any standard? |
18:25:11 | Araq | from my perspective it was like "I can unzip and finish.exe but other programmers cannot be bothered with this." |
18:25:29 | Araq | which I have heard before from dom96. |
18:25:52 | Araq | yet I never met somebody who cannot be bothered with it. |
18:26:14 | Araq | ok, unzip and finish.exe better work out of the box. |
18:26:31 | * | [ui] quit (Quit: Connection closed for inactivity) |
18:26:45 | Araq | but finish was a new development and it always takes a few iterations to get these things right. |
18:29:12 | dom96 | tekjar: sure, we can do that. It's documented in Nimble's readme. |
18:29:22 | dom96 | But you can put the source wherever you want |
18:30:02 | dom96 | It would be good to set up a default though |
18:30:50 | FromGitter | <tekjar> @dom96 which file does `nimble build` start with? |
18:31:42 | FromGitter | <tekjar> > **<dom96>** It would be good to set up a default though |
18:31:49 | FromGitter | <tekjar> Can I raise an issue for that? |
18:33:31 | Araq | varriount: regarding the installers, the easiest option is to fix https://github.com/nim-lang/Nim/issues/4657 |
18:33:32 | dom96 | tekjar: yeah, please do |
18:33:56 | dom96 | `nimble build` compiles the files specified via `bin` in your .nimble file: `bin = @["foobar"]`. |
18:34:12 | Araq | we moved from Inno to NSIS because Inno doesn't have the "optional downloads" feature we need |
18:34:12 | dom96 | This is all documented in the readme, if not then that's a bug ;) |
18:34:40 | Araq | and it's not that much work to maintain when it works, but right now it doesn't. |
18:35:25 | Araq | I stumpled upon issue #4657 again when testing the installers |
18:35:38 | dom96 | Me and Araq have had this idea to create a Nim-based installer generator. |
18:35:45 | dom96 | I think that's the way to go in the long-term |
18:35:52 | dom96 | In fact, this may become a killer feature for Nim |
18:36:09 | dom96 | Because NSIS and Inno are both crap as far as I'm concerned and there are no alternatives. |
18:38:34 | chemist69 | "Araq | ok, fixed": great, thanks. These lightning-fast bug fix cycles are another major selling point of Nim to me. |
18:39:10 | euantor | Thee's Wix, which seems fairly popular |
18:39:32 | * | Salewski left #nim (#nim) |
18:39:57 | * | brson joined #nim |
18:40:00 | dom96 | euantor: while i've got you, any progress on federico3's site? |
18:40:13 | euantor | Some, I'll be opening a PR soon :) |
18:40:25 | euantor | And yes, you were lucky to catch me |
18:40:51 | euantor | I've got the majority of it styled, just some more slight changes I want to make |
18:41:29 | dom96 | "Wix [...] is a free software toolset that builds Windows Installer packages from XML code." |
18:41:36 | dom96 | XML doesn't sound like fun. :) |
18:41:46 | dom96 | euantor: nice |
18:41:52 | euantor | No, it never is. But it does seem popular and probably does what Nim needs |
18:42:14 | euantor | How do Rust and Go build their installers for Windows? |
18:42:41 | dom96 | Rust uses NSIS IIRC |
18:42:56 | Araq | pretty sure Rust uses Wix |
18:43:09 | federico3 | euantor: if you have some half-baked that you can throw in my general direction I can take a look |
18:43:15 | Araq | it provides a ms windows installer, not an exe |
18:43:44 | Araq | XML being fun or not is of little importance, it will be generated anyway. |
18:43:45 | euantor | federico3: Will do, but probably won't get time tonight. Got to take the dogs out in a couple of minutes |
18:43:57 | FromGitter | <Varriount> euantor: Personally, I don't mind WiX too much, but araq is allergic to XML, I think. |
18:44:11 | Araq | that said, I have no idea whether the XML can actually support everything we want to do |
18:45:21 | Araq | btw we use 7z to generate the zips, I think 7z can also generate a "self unzipping zip file" which is closer to a setup.exe |
18:45:23 | dom96 | somebody has to write the XML that will be generated though |
18:45:26 | dom96 | which isn't going to be fun |
18:45:48 | Araq | it's horrible to figure these things out because the docs are hardly existent |
18:46:45 | Araq | but the XML part is only an annoyance. |
18:46:56 | Araq | that wasn't what stopped me from trying it. |
18:47:29 | FromGitter | <Varriount> I think the docs have improved quite a bit - or at least, the website is new |
18:50:07 | FromGitter | <Varriount> http://wixtoolset.org/documentation/manual/v3/bundle/bundle_author_chain.html |
18:50:15 | FromGitter | <Varriount> Looks to support downloadable extras |
18:51:25 | dom96 | if somebody has the time then please attempt to use Wix. |
18:51:43 | dom96 | and create a nicer installer for Nim using it |
18:52:05 | FromGitter | <martinium> I'm actually surprised so many people use windows for non .NET |
18:52:29 | FromGitter | <Varriount> @martinium Someone has to develop applications for Windows |
18:52:43 | FromGitter | <martinium> Yeah it makes sense to do so |
18:52:52 | FromGitter | <martinium> They have largest end-user base |
18:54:06 | euantor | If I get time this weekend I might investigate Wix. Depends how busy I am |
18:54:28 | Araq | good night |
18:54:53 | FromGitter | <tekjar> @dom96 https://github.com/nim-lang/nimble/issues/315 |
18:56:18 | dom96 | thanks |
18:58:02 | def-pri-pub | feeding time! |
18:58:08 | * | def-pri-pub is now known as def-pri-pub|afk |
18:58:13 | FromGitter | <martinium> Food is always good |
18:58:30 | * | subsetpark joined #nim |
18:59:11 | FromGitter | <martinium> @dom96 how hard would it be to create a webserver that is faster than nginx using Nim? Seems like it can be done. An example would be haskell's warp server |
18:59:52 | dom96 | martinium: no idea how fast nginx is |
19:00:05 | dom96 | it's better to compare the speed to other languages |
19:00:12 | dom96 | like Go |
19:00:45 | FromGitter | <martinium> Nginx is c++ and Nim compiles to C so they should be comparable |
19:00:57 | FromGitter | <martinium> Go isn't as fast as Nim for most tasks |
19:01:28 | euantor | federico3: The current code for `nim-package-directory` doesn't seem to compile btw. The `github` module is missing and doesn't seem to be available via nimble |
19:03:02 | FromGitter | <Varriount> @martinium Unfortunately, nginx is quite well-designed and mature. |
19:03:27 | FromGitter | <martinium> It is |
19:03:37 | FromGitter | <martinium> Multiple use cases as well |
19:03:55 | dom96 | martinium: it's not just about how fast the language is, a lot of work is required to create a highly performant socket library, async library, etc. |
19:04:15 | FromGitter | <martinium> Yeah no one wants to do all that hard work over again |
19:04:17 | FromGitter | <martinium> Lol |
19:04:19 | FromGitter | <Varriount> Not to slight @dom96's hard work, but I doubt the builtin async framework is optimized enough at the moment to compete |
19:04:39 | dom96 | I doubt it too. I haven't optimised it at all. |
19:04:46 | FromGitter | <martinium> I wonder if something like haskell's warp server is possible in Nim? |
19:04:57 | FromGitter | <martinium> You guys ever hear of it? |
19:05:09 | FromGitter | <Varriount> The most performant connection model is multi-threaded asynchronous (and possible multi-process too). Current we have single-threaded asynchronous |
19:07:16 | federico3 | tnx euantor, I'll update |
19:08:19 | FromGitter | <martinium> aosabook.org/en/posa/warp.html |
19:08:26 | dom96 | I guess people are still having trouble with finish.exe https://www.reddit.com/r/nim/comments/5mx31i/version_0160_released/dc8aqzo/ |
19:08:39 | dom96 | why does it even verify mingw? just check if it exists in PATH and call it a day |
19:08:40 | federico3 | martinium the world doesn't need yet another fast webserver :) |
19:09:03 | FromGitter | <martinium> Never can have too many :h |
19:09:09 | FromGitter | <martinium> :) |
19:12:26 | * | confundus quit (Quit: confundus) |
19:22:02 | * | rokups quit (Quit: Connection closed for inactivity) |
19:22:47 | * | gangstacat quit (Quit: Ĝis) |
19:34:05 | * | gangstacat joined #nim |
19:39:02 | * | def-pri-pub|afk is now known as def-pri-pub |
19:47:17 | def-pri-pub | Writing an NGINX module in Nim would probably be a cool project. The API doesn't look too difficult: |
19:47:20 | def-pri-pub | http://www.evanmiller.org/nginx-modules-guide.html |
19:52:00 | federico3 | martinium one of the most wanted features is easy integration with Let's Encrypt... |
19:58:15 | cheatfate | martinum: i think asynchttpserver is faster then nginx, but nginx knows http much better then asynchttpserver |
19:58:35 | cheatfate | so this will be not very fair comparison |
20:01:45 | FromGitter | <martinium> Yeah |
20:01:57 | FromGitter | <martinium> Nginx has many years of development behind it also |
20:02:28 | FromGitter | <martinium> Nim has a much larger scope so most modules are more than likely no super optimized |
20:02:48 | * | bjz joined #nim |
20:02:49 | FromGitter | <martinium> When I learn enough I plan to contribute however I can |
20:02:58 | FromGitter | <rivasiv> Are there any option for nim compiler to show final generated gcc command ? |
20:03:05 | FromGitter | <martinium> Reg dayjob prevents learning faster |
20:04:45 | FromGitter | <rivasiv> @Araq , @dom96 Are there any option for nim compiler to show final generated gcc command ? |
20:05:08 | dom96 | rivasiv: remove nimcache and try --verbosity:4 |
20:06:57 | cheatfate | i think --verbosity:3 would be enough |
20:07:02 | FromGitter | <Varriount> @dom96 : Doesn't the output file have the generated command at the top, as a comment? |
20:07:31 | dom96 | yes, that's another option |
20:07:36 | dom96 | but there is also the linker command |
20:09:25 | cheatfate | Varriount: i dont want to create issue, but is it possible to add to NimLime one more category on color syntax: deprecated terms? |
20:09:41 | cheatfate | with `red` color or something |
20:10:10 | cheatfate | i know it will be hard to maintain this list, but it can be user configurable |
20:10:51 | federico3 | if there was to be a configurable color pattern it would be useful for unittest as well: the default color work well only on dark backgrounds |
20:12:21 | cheatfate | federico3, i dont think color is configurable in sublimetext, i think color is depends on color scheme not on plugin |
20:12:33 | FromGitter | <rivasiv> @dom96 works for me thanks, @Varriount your way works too - thanks |
20:12:44 | dom96 | awesome :) |
20:12:52 | FromGitter | <Varriount> cheatfate: Possibly, but it would require a pull request. |
20:12:56 | federico3 | sorry cheatfate I thought you were talking about the compiler output colors |
20:13:24 | FromGitter | <Varriount> I've actually been meaning to make a forum post about that - I need another maintainer, as I don't have any time at present to maintain NimLime |
20:14:04 | FromGitter | <Varriount> I'm working full time + going to university full time, which leaves me with very little free time |
20:15:49 | FromGitter | <Varriount> I can't see being able to maintain any projects until the end of 2018 |
20:18:06 | cheatfate | it is sad |
20:18:32 | * | yglukhov quit () |
20:18:33 | * | yglukhov_ joined #nim |
20:20:00 | federico3 | Varriount: you need 48 hours in your day. Bitshift your clock |
20:27:45 | FromGitter | <Varriount> federico3: I wish! Either that, or being able to do without sleep. |
20:28:54 | FromGitter | <Varriount> cheatfate: Anyway, I'll see about putting a 'help wanted' post on the forum tonight, when I get home. |
20:29:26 | FromGitter | <Varriount> The syntax color itself is controlled by your scheme. The syntax files only 'categorize' sections of the file |
20:45:01 | def-pri-pub | For the JS target, would Nim return a `nil`, where JavaScript would return a `null`? I'm looking at this field: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/canvas |
20:54:32 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
20:54:37 | * | vlad1777d quit (Remote host closed the connection) |
20:56:04 | dom96 | def-pri-pub: I believe it would |
20:57:10 | * | vlad1777d joined #nim |
20:59:05 | * | yglukhov_ quit (Remote host closed the connection) |
21:00:01 | subsetpark | I feel like it should be called, I don't know, SublNime... |
21:02:44 | subsetpark | Though speaking of - dom96 / Araq , is there maintained anywhere a list of opportunities to contribute/maintain packages? Especially for beginner/intermediate users? I'm a good enough programmer, but I don't write C and my Nim experience is still pretty low. But I really want to contribute and build the community if there are opportunities. |
21:03:36 | dom96 | Any of the "official" packages (listed here: https://github.com/nim-lang) are always in need of maintenance. |
21:03:49 | dom96 | More documentation |
21:03:52 | dom96 | More examples |
21:03:54 | dom96 | Testing |
21:03:57 | FromGitter | <Varriount> subsetpark: Do you know any python? |
21:04:05 | dom96 | Even a nice readme in each repo would help |
21:04:57 | * | bjz joined #nim |
21:05:05 | * | Mat4 joined #nim |
21:06:42 | * | yglukhov joined #nim |
21:10:07 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
21:10:34 | subsetpark | Varriount: I know a lot of Python :) Unfortunately I'm not a sublime user |
21:11:03 | subsetpark | dom96: I don't suppose there are tickets anywhere? |
21:11:42 | dom96 | subsetpark: afraid not. Best thing to do is to try using libraries you care about, you will undoubtedly find things that can be improved. |
21:13:41 | * | Mat4 left #nim ("Leaving") |
21:14:43 | * | dddddd joined #nim |
21:16:57 | * | def-pri-pub is now known as def-pri-pub|afk |
21:17:52 | subsetpark | Well... Would you guys be interested in help with that area of things, too? Organizing contribution opportunities, community management, etc? |
21:25:50 | * | bjz joined #nim |
21:29:40 | * | Jesin joined #nim |
21:35:06 | * | bjz quit (Ping timeout: 240 seconds) |
21:41:05 | * | yglukhov quit (Remote host closed the connection) |
21:41:25 | * | couven92 joined #nim |
21:43:11 | * | nsf quit (Quit: WeeChat 1.6) |
21:45:09 | * | space-wizard quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
21:45:43 | * | Matthias247 joined #nim |
21:47:06 | * | space-wizard joined #nim |
21:48:19 | * | yglukhov joined #nim |
21:49:55 | * | yglukhov quit (Remote host closed the connection) |
21:50:32 | * | yglukhov joined #nim |
21:52:37 | * | yglukhov quit (Remote host closed the connection) |
21:53:57 | * | yglukhov joined #nim |
21:54:33 | * | vlad1777d_ joined #nim |
21:57:16 | * | Trustable quit (Remote host closed the connection) |
21:58:11 | * | Jesin quit (Quit: Leaving) |
21:59:40 | FromGitter | <Varriount> subsetpark: Darn |
22:04:07 | * | rupil quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
22:20:31 | * | ritualtears quit (Read error: Connection reset by peer) |
22:43:35 | * | def-pri-pub|afk is now known as def-pri-pub |
22:49:32 | yglukhov | how do i fix Ident not found: foreignDeps. |
22:55:45 | yglukhov | dom96: ping |
22:56:19 | dom96 | yglukhov: need more context, what are you trying to do? |
22:56:29 | dom96 | install some Nimble package? |
22:56:31 | dom96 | upgrade Nimble? |
22:56:33 | yglukhov | just nimble install anything... |
22:56:52 | dom96 | what version of Nimble and Nim do you have? |
22:57:13 | yglukhov | nimble v0.8.3 compiled at 2017-01-11 00:48:01 |
22:57:26 | yglukhov | nim: 5947403e84ba44397b35f93f9d327c76e794210f |
22:57:51 | yglukhov | nimble installed with ./koch nimble |
22:58:12 | dom96 | can you gist the full output? |
22:58:17 | yglukhov | sure |
22:58:58 | yglukhov | https://gist.github.com/yglukhov/8afe9c5a8ca9ca1d40ffb7ef2dc29df4 |
23:02:44 | def-pri-pub | How does one dynamically create a HTML Element for the Nim Js target? |
23:02:51 | def-pri-pub | E.g. for "ImageElement"? |
23:03:03 | dom96 | the nimx dependencies do sure take a while to download |
23:04:48 | def-pri-pub | I tried doing `var img: ImageElement` then `new(img)`, but when I tried passing it into a proc that required an ImageElement, is threw a type error at me. |
23:05:36 | dom96 | def-pri-pub: how do you create HTML elements in JS? |
23:05:54 | yglukhov | dom96: true. maybe could think about some lazy dependency installation. e.g. download some dependencies when compiling to some specific platform. |
23:06:22 | * | vlad1777d_ quit (Quit: Leaving) |
23:06:26 | dom96 | yglukhov: I can't reproduce this :\ |
23:06:29 | dom96 | Installs fine for me |
23:06:56 | dom96 | You can try removing /tmp/nimblepkg |
23:07:17 | dom96 | and another thing to try is `nimble install nimx --nimbleDir:./nimbleDir |
23:07:38 | dom96 | Maybe there is something in your ~/.nimble that's messing it up |
23:07:41 | def-pri-pub | domg96: I don't know either :P |
23:07:56 | yglukhov | dom96: yay! rm -rf /tmp/nimble* helped! |
23:08:02 | yglukhov | thanks! |
23:08:12 | dom96 | interesting. |
23:08:18 | def-pri-pub | Lools like it's `document.createElement("img")` |
23:08:21 | def-pri-pub | looks* |
23:08:28 | dom96 | def-pri-pub: yep, same thing in Nim :) |
23:08:54 | dom96 | yglukhov: I also noticed that nimx installation prompts to overwrite jsbind :\ |
23:08:55 | def-pri-pub | Wouldn't that append it to the DOM? |
23:08:56 | dom96 | That's a bug |
23:09:36 | yglukhov | dom96: i didnt notice that. |
23:10:03 | dom96 | and the fact that it's using an old /tmp/nimble* is a bug too |
23:10:53 | yglukhov | dom96: another thing i suspect is that `nimble path` got really slow with some recent changes |
23:11:05 | yglukhov | but im not sure 100% yet |
23:11:14 | dom96 | that's likely |
23:11:22 | yglukhov | ouch |
23:11:24 | dom96 | Please report anything you find |
23:11:43 | dom96 | `remove` is also slower than it should be |
23:11:52 | dom96 | both must be reading all packages for no reason |
23:12:15 | dom96 | should be an easy fix |
23:12:50 | yglukhov | i can do an official report without some confidence that its nimbles fault =) |
23:12:58 | yglukhov | * can't |
23:13:24 | dom96 | heh, okay |
23:13:26 | * | Vladar quit (Quit: Leaving) |
23:13:53 | dom96 | do let me know about how well/unwell the new management of #head deps works. |
23:14:09 | dom96 | there should be no prompts |
23:14:22 | dom96 | but since I already saw one I should say "there is going to be less prompts" :) |
23:21:06 | yglukhov | dom96: oh btw! regarding #head. again, not 100% sure, but it looks like behavior has changed. if i have package foo that depends on bar#head, cd foo, nimble install -dy, old behavior would be to redownload bar every time |
23:21:38 | yglukhov | new behavior is to be satisfied with currently installed bar#head |
23:21:46 | yglukhov | which looks wrong to me |
23:21:52 | * | NhanH quit (Ping timeout: 240 seconds) |
23:22:07 | dom96 | yeah, I think you're right |
23:22:23 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
23:23:13 | * | subsetpark quit (Ping timeout: 240 seconds) |
23:25:20 | * | subsetpark joined #nim |
23:25:38 | * | NhanH joined #nim |
23:30:56 | * | Kingsquee joined #nim |
23:42:06 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:47:15 | def-pri-pub | HTML5 2D Canvas rendering is functionally complete: https://gitlab.com/define-private-public/HTML5-Canvas-Nim |
23:47:37 | def-pri-pub | (just need to spruce up the README and make it play nice with the `colors` module) |
23:49:21 | def-pri-pub | Is there a way to get mouse/keyboard input from the JS target? Has someone made a package yet or not? |
23:54:13 | * | shodan45 joined #nim |