00:05:34 | * | yingjun_ joined #nim |
00:10:01 | * | yingjun_ quit (Ping timeout: 245 seconds) |
00:14:07 | libman | dom96: is this OK - https://www.reddit.com/r/nim/comments/6ej3yw/nim_superstar_dominik_picheta_dom96_speaking_at/ :P |
00:14:51 | dom96 | Superstar is a bit much lol |
00:15:01 | dom96 | "core dev" would be better |
00:15:25 | libman | Reddit no let edit title |
00:16:04 | dom96 | Resubmit it, I removed it for you :P |
00:16:16 | dom96 | also, oooh, they have the timetable up now |
00:17:06 | dom96 | yay, I'm in the morning, means I can avoid stress when watching the other presentation :) |
00:17:12 | libman | Done. |
00:17:56 | dom96 | 4 different rooms though, that's quite a split. |
00:18:49 | dom96 | libman: gonna fly to Northern Ireland to join the fun? :D |
00:18:54 | * | sz0 quit (Quit: Connection closed for inactivity) |
00:19:33 | libman | Crazy tax resisters don't fly. |
00:25:50 | dom96 | I wonder if I could somehow organise a Nim conference at my University. |
00:26:30 | Araq | I noticed we have superstar now. maybe he could do that. |
00:26:42 | ftsf | \o/ superstar! |
00:29:11 | shmup | man the weirdest stuff happens to me sometimes. i'm 100% sure i am merely spawning a new window with nico, nothing more. i have 3 stubbed out procs for nico.run. i remove the existing exe to be safe. i compile and run, and its the damn helloworld paint demo. its like .. it's.. building from a cached .nim file or something |
00:29:11 | dom96 | lol |
00:29:55 | shmup | i had this happening to me before too. in another scenario but similar outcome. |
00:29:56 | ftsf | shmup, hmm how are you building it? |
00:30:17 | shmup | nim -r --cc:vcc c wpm.nim |
00:30:30 | shmup | vcc is a thing I have defined in my nim.cfg |
00:30:36 | shmup | it's just set to use cl.exe is all |
00:31:28 | ftsf | hmm odd. wpm.nim doesn't import/include the example does it? |
00:32:07 | * | noethics quit (Remote host closed the connection) |
00:32:26 | * | noethics joined #nim |
00:32:52 | * | def-pri-pub joined #nim |
00:33:57 | shmup | ftsf: https://gist.githubusercontent.com/shmup/9388475528be15f1a26be0883c49d1f1/raw/e60930ccbc3dc1f4839b35372cf395e2f020a029/gistfile1.txt |
00:34:05 | shmup | this isn't actually a useful log lol but |
00:34:33 | shmup | that atrocious looking build command is just what's needed to use cl.exe, gotta run some environment stuff with vcvarsall.bat heh |
00:34:45 | ftsf | looks fine |
00:34:47 | shmup | anyways, the result is a wpm.exe and it is just your paint demo and yeah |
00:34:49 | shmup | ¯\_(ツ)_/¯ |
00:34:58 | ftsf | delete all the paintout stuff and nimcache and see what happens? |
00:36:52 | shmup | ah, got it. so here's a fun thing. i can't actually build this with x64. except it appeared to.. it made an exe, but it was using a previous wpm_wpm.obj |
00:37:17 | shmup | because after removing nimcache it yelled about not finding it. had to add --cpu:i386 and now all is well. weird. |
00:37:37 | ftsf | ahh |
00:37:39 | ftsf | awesome |
00:37:41 | shmup | (i can build x64 if i'm not using cmd.exe and cl.exe heh) |
00:37:44 | shmup | whatever, thanks man. |
00:41:21 | libman | "Nim Superstar" ranks below "Founder, King Of Kings, BDFL" of course. Then the rank titles below that are "Brigadier Committer", "Major Nimrod", "Captain Nimble", "Lieutenant Guru", "Sergeant Nim", "Petty Nimian", "Private Repository", "Lurker First Class", and "Forum Troll". |
00:42:53 | FromGitter | <Varriount> libman: And which one are you? |
00:43:19 | libman | I'm Forum Troll, Third Class, Dishonorably Discharged. |
00:43:27 | FromGitter | <Varriount> :3 |
00:55:07 | FromGitter | <Varriount> I think I'm more of a guru |
00:57:23 | libman | Nah. But if I ever get my concentration back and work hard, I hope to advance as high as Corporal Nimious, someday... |
01:03:55 | * | yingjun_ joined #nim |
01:11:14 | * | chemist69 quit (Ping timeout: 255 seconds) |
01:24:42 | * | chemist69 joined #nim |
01:49:24 | * | benny_ quit (Ping timeout: 260 seconds) |
01:50:27 | * | benny_ joined #nim |
02:05:58 | * | faix joined #nim |
02:24:42 | subsetpark | Getting this issue while trying to build my project under a newly installed 0.17 - |
02:24:44 | subsetpark | lib/nim/pure/os.nim(802, 33) Error: cannot evaluate at compile time: environment |
02:24:51 | subsetpark | Have we covered this one before? |
02:25:15 | subsetpark | sorry - build with `nimble build` |
02:30:41 | subsetpark | Ah, it's this one https://github.com/nim-lang/Nim/issues/5867 |
02:31:57 | ftsf | \o/ just recorded a 1:30 video of making a game in nim with nico... now it'll probably take all day to upload |
02:32:27 | * | sz0 joined #nim |
02:52:09 | * | faix quit (Ping timeout: 268 seconds) |
02:58:00 | shmup | ftsf: raddddd |
03:10:25 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
03:19:33 | * | libman quit (Quit: Connection closed for inactivity) |
03:24:59 | * | ftsf quit (Quit: Leaving) |
03:30:52 | * | pilne quit (Quit: Quitting!) |
03:31:12 | * | ftsf joined #nim |
03:38:35 | * | daaf quit (Ping timeout: 260 seconds) |
03:45:06 | ftsf | shmup, got something in mind to make? |
03:56:31 | * | yingjun_ quit (Remote host closed the connection) |
03:56:41 | * | yingjun_ joined #nim |
03:57:39 | * | yingjun_ quit (Remote host closed the connection) |
04:00:44 | * | yingjun_ joined #nim |
04:01:09 | * | king1978 joined #nim |
04:04:19 | * | def-pri-pub quit (Quit: leaving) |
04:16:35 | * | yingjun_ quit (Remote host closed the connection) |
04:16:59 | * | yingjun_ joined #nim |
04:17:43 | * | yingjun_ quit (Remote host closed the connection) |
04:18:02 | * | king1978 left #nim (#nim) |
04:27:15 | * | vlad1777d joined #nim |
04:32:23 | * | Parashurama joined #nim |
04:42:57 | * | benny_ quit (Remote host closed the connection) |
05:08:14 | FromGitter | <zacharycarter> almost done with the first pass of the deferred renderer for frag |
05:11:47 | ftsf | awesome |
05:12:44 | * | yingjun_ joined #nim |
05:25:02 | * | rauss quit (Quit: WeeChat 1.8) |
05:35:03 | * | Vladar joined #nim |
05:42:01 | * | Parashurama quit (Quit: ChatZilla 0.9.93 [Firefox 53.0.2/20170509210144]) |
06:01:07 | * | gokr joined #nim |
06:11:13 | * | nsf joined #nim |
06:28:52 | * | Matthias247 joined #nim |
06:31:03 | * | benny_ joined #nim |
06:35:06 | * | Arrrr joined #nim |
06:44:23 | * | Matthias247 quit (Read error: Connection reset by peer) |
07:14:18 | * | rokups joined #nim |
07:24:23 | * | yglukhov joined #nim |
07:28:25 | * | yglukhov quit (Ping timeout: 246 seconds) |
07:28:28 | * | yglukhov_ joined #nim |
07:50:47 | * | Andris_zbx joined #nim |
08:25:18 | * | yingjun_ quit (Remote host closed the connection) |
08:25:31 | * | yingjun joined #nim |
08:26:12 | * | yglukhov_ quit (Remote host closed the connection) |
08:26:26 | * | yingjun quit (Remote host closed the connection) |
08:32:01 | * | yingjun joined #nim |
08:40:01 | * | yingjun quit (Ping timeout: 245 seconds) |
08:40:40 | * | yingjun joined #nim |
08:43:14 | * | yglukhov joined #nim |
08:43:22 | FromGitter | <coffeepots> hey everyone :) |
08:43:50 | FromGitter | <coffeepots> zachary well done on frag, it's really coming along! Deferred rendering is so useful! |
08:46:38 | FromGitter | <coffeepots> So, I noticed that del from a table is incredibly slow, like, hoo wow that is really, really slow. Is this normal? https://gist.github.com/coffeepots/bc4463afc420f51b975a0efad5bb313a |
08:47:44 | def- | coffepots: compile with -d:release |
08:48:38 | FromGitter | <coffeepots> it does make a huge difference, now add is -2.08e-20 (jesus!) but add is 0.048 |
08:49:00 | FromGitter | <coffeepots> that is hugely faster but wow orders of magnitude slower for del |
08:49:31 | FromGitter | <coffeepots> just wondering if this is normal for hash tables |
08:49:44 | FromGitter | <coffeepots> sorry i meant to say del is 0.048 |
08:50:08 | def- | Implementation here: https://github.com/nim-lang/Nim/blob/devel/lib/pure/collections/tableimpl.nim#L123-L149 |
08:51:10 | FromGitter | <coffeepots> i did take a look at it but wasn't sure what was going on, two while true's and conditional breaking |
08:51:27 | * | yingjun quit (Ping timeout: 240 seconds) |
08:51:29 | FromGitter | <coffeepots> it looks fast but i guess it needs to loop a lot |
08:51:59 | * | yingjun joined #nim |
09:20:55 | FromGitter | <coffeepots> tbh, i expected add to be slower than delete 'cos allocating memory. So, I tried the same test in Delphi and got add: 0.001, del: 0.0007 |
09:21:05 | FromGitter | <coffeepots> so at least for delphi, delete is faster than add |
09:21:21 | FromGitter | <coffeepots> curious as to why the nim del implementation is at such odds to the add performance |
09:23:11 | FromGitter | <coffeepots> i mean, in nim release, for 100,000 keys which is not a huge amount really, add 0.003 delete 4.7s wat |
09:23:43 | * | murych joined #nim |
09:24:05 | FromGitter | <Varriount> We need to copy Python's dictionary implementation |
09:24:08 | FromGitter | <coffeepots> that's 1,566 times as slow! |
09:26:32 | FromGitter | <coffeepots> i only noticed because i'm making an ecs and trying different implementations, used tables for one and it worked fantastically, that is, until i built a few test systems, then the whole thing ground to a halt, profiled it, oh deary me what on earth... |
09:26:48 | FromGitter | <coffeepots> purely because of the deletes |
09:28:18 | FromGitter | <coffeepots> if i constantly added entities, up to 10,000 would run fine (this is with graphics and background shaders), when i deleted them the whole thing locked up every few seconds. I thought it was the GC at first. Nope. Deletes |
09:29:15 | FromGitter | <coffeepots> I wish I understood hash table implementations enough to work out what the issue is, 'cos it doesn't seem normal |
09:29:16 | FromGitter | <Varriount> @coffeepots Any idea why del is so slow? |
09:30:23 | FromGitter | <coffeepots> no idea unfortunately, my guess would be it's looping too much because it's not doing any deallocation |
09:35:42 | * | krux02 joined #nim |
09:39:51 | def- | coffeepots: I'd suggest reading the Knuth algorithm as the next step |
09:41:46 | Araq | coffeepots: OrderedTable or Table? |
09:42:05 | def- | Araq: his example used just Table |
09:42:37 | Araq | hmm never heard this one but we don't shrink tables |
09:43:25 | Araq | we use "tombstones" in the implementation, pretty standard stuff |
09:50:01 | * | murych quit (Ping timeout: 245 seconds) |
09:57:52 | * | roxma joined #nim |
09:59:31 | * | benny_ quit (Remote host closed the connection) |
09:59:46 | * | benny_ joined #nim |
10:06:56 | FromGitter | <coffeepots> def: Was looking for the algorithm actually, to have a look and see ref implementation |
10:07:17 | FromGitter | <coffeepots> araq: yeah just table[a, b], tried tableref too but same perf |
10:07:53 | FromGitter | <coffeepots> as you say, should be fast as no dealloc and all operations in deimpl should be quick, but unfortunately it turns out its incredibly slow :/ |
10:09:00 | FromGitter | <coffeepots> if you try out the code i listed above you can see how slow it is, almost 5 seconds on my machine to delete 100,000 keys! o_O |
10:12:26 | FromGitter | <coffeepots> i wonder if the escape clauses in delimpl are slightly off or something and it's looping way too much, trying to find knuth v3 Algo6.4R to look at |
10:12:29 | Araq | I think the many tombstones make searches O(n) instead of O(1) |
10:12:49 | FromGitter | <coffeepots> oh |
10:12:54 | Araq | and that's obviously a problem ;-) |
10:13:10 | FromGitter | <coffeepots> having said that add is sufficiently fast |
10:13:27 | Araq | add can fill in tombstones |
10:13:35 | Araq | del needs to keep searching |
10:13:38 | Araq | not sure |
10:24:43 | FromGitter | <GULPF> if orderedtable is reimplemented with the algorithm from pypy, can't that implementation replace nims unordered table as well? looking at https://morepypy.blogspot.se/2015/01/faster-more-memory-efficient-and-more.html, it sounds like deletion should always be O(1) for that implementation |
10:29:08 | Araq | GULPF: maybe |
10:31:02 | Arrrr | Coffepots it might be because of the consecutive keys? if you add random keys, it goes faster than that https://glot.io/snippets/eqecq7sdt6 |
10:32:42 | FromGitter | <coffeepots> huh... that is surprising! |
10:34:21 | FromGitter | <coffeepots> even will a 10M keys your code gives me add: 1.8, del 1.6 which makes way more sense |
10:35:07 | FromGitter | <coffeepots> interesting that delphi's implementation handles consecutives better, i should try their impl with random ids |
10:36:02 | Arrrr | I don't know on the other hand how many collisions (if any) produces that random. |
10:36:30 | Arrrr | int size seems to be 64b |
10:39:54 | * | yingjun quit (Remote host closed the connection) |
10:40:04 | * | yingjun joined #nim |
10:41:01 | * | yingjun quit (Remote host closed the connection) |
10:43:28 | * | yingjun joined #nim |
10:45:45 | FromGitter | <coffeepots> translated the code to delphi, ran for 50k keys and got add: 0.01, del: 0.004 |
10:45:52 | FromGitter | <coffeepots> with randomised keys |
10:46:00 | FromGitter | <coffeepots> curious what their implementation is now |
10:46:36 | FromGitter | <coffeepots> (that's debug, release is add: 0.0067, del: 0.003) |
10:46:41 | Araq | consecutive keys should be fine for 'add' dunno about 'del' |
10:47:13 | FromGitter | <coffeepots> yes, add is fine for performance, it's just consecutive keys cause delete to be 1,500 times as slow as add |
10:48:01 | FromGitter | <coffeepots> in nim |
10:48:16 | Arrrr | If you are going to use incremental indexes, what's the problem with seq? |
10:49:13 | FromGitter | <coffeepots> @Arrrr because I need to randomly access entity ids to read and delete them |
10:49:46 | Arrrr | Can't you reuse ids? |
10:51:12 | Arrrr | Also https://bitsquid.blogspot.com.es/2014/08/building-data-oriented-entity-system.html |
10:52:06 | FromGitter | <coffeepots> i am experimenting with a slotmap (http://seanmiddleditch.com/data-structures-for-game-developers-the-slot-map/) which does reuse keys with versioning, but the problem with that is the key is then only unique to that map, you can't have a global entity id for lookup into different maps without a lot of complexity |
10:53:12 | yglukhov | Araq, dom96: https://github.com/nim-lang/sdl2/pull/93 ready to go |
10:54:23 | Araq | great, thanks! |
10:57:57 | * | yingjun quit (Ping timeout: 240 seconds) |
10:58:26 | * | yingjun joined #nim |
10:58:58 | FromGitter | <coffeepots> @Arrrr the article you linked looks pretty the same as the slot map idea, in terms of having an id split into generation an index into an array |
11:00:28 | FromGitter | <coffeepots> it is fast - my implementation actually is not much faster than hash table though, surprisingly, for add. Of course, delete it vastly outperforms hash table! |
11:01:00 | * | yingjun quit (Remote host closed the connection) |
11:01:13 | * | yingjun joined #nim |
11:01:44 | Arrrr | Why do you need accessing entities ouside the main list? |
11:02:41 | * | yingjun quit (Remote host closed the connection) |
11:02:42 | * | Snircle joined #nim |
11:08:25 | FromGitter | <coffeepots> systems have a list of entities to loop through which would be fine as a seq were it not for needing to delete them - did consider ordered seq and binary search but hash should still be faster than that, plus ofc deletion from seq means shifting memory, and there needs to be a way of retrieving the component data via entity too |
11:08:43 | FromGitter | <coffeepots> actually sorry del from seq doesn't shift memory |
11:08:57 | FromGitter | <coffeepots> swaps with the last entry iirc |
11:09:17 | FromGitter | <coffeepots> but then its not ordered, so insert needs to shift mem |
11:09:37 | FromGitter | <coffeepots> so table seems like logical choice for system.entitylist |
11:10:35 | FromGitter | <coffeepots> i am using arranging components by type, where each component type has a lookup of entity id to retrieve component data |
11:11:07 | Arrrr | Why do you need the order? |
11:12:15 | FromGitter | <coffeepots> i dont need order with table, but if i want to find an entity to remove it from a system list then i need to find it's index to remove |
11:12:31 | FromGitter | <coffeepots> the problem is with short lived entities like bullets |
11:12:54 | FromGitter | <coffeepots> ideally i want an ecs that doesnt need a separate system to do short lived entities |
11:14:30 | FromGitter | <coffeepots> also, i could have a list of entity id -> list of components but then i have to loop through all the entity's components to find the type i want, for every single query of hasComponent or getComponent |
11:15:02 | Arrrr | you could store the index inside the entity/component |
11:15:26 | FromGitter | <coffeepots> i do, but how do you find it without a hash table? |
11:15:36 | Arrrr | With the index |
11:16:53 | FromGitter | <coffeepots> so how do you manage that when component data is in separate arrays, and systems also have lists of entities? You need a lookup table of entity->component index and entity -> system index, which is what i'm trying atm |
11:17:47 | FromGitter | <coffeepots> if table.del was as fast as add, i could keep with the much simpler design (literally 100 lines of code) and get the performance too |
11:18:14 | * | couven92 quit (Read error: Connection reset by peer) |
11:18:16 | * | yingjun joined #nim |
11:19:28 | FromGitter | <coffeepots> ofc my ecs design might be total crud but most of the ones i've been looking at use hash tables to get components via entity ids, and those that don't, afaict, use sets to filter a giant list of entities against systems, which seems even worse (tho cant be that bad, think this is how ashley works) |
11:21:56 | Araq | coffeepots: versionized incremental IDs are state of the art and everything else is inferior ;-) |
11:22:13 | Araq | and they imply you can use 'seq's not tables |
11:27:03 | FromGitter | <coffeepots> state of the art lol well, perhaps. Certainly they are fast, and my intention was to be as cache friendly as possible. With the slot map it's seq of array chunks and has a seq with the next free id on |
11:30:35 | FromGitter | <coffeepots> i think i have figured out a way to do this minimally with "slotmaps" inside the entity |
11:32:16 | FromGitter | <coffeepots> entity contains: an id that is versioned idx into array for quick access, and also another array for each component type, that way i have two index lookups, one for entity id and one for component *type* into an array. It means entities are 'fatter' but hey ho, as long as its fast |
11:40:48 | * | yingjun_ joined #nim |
11:40:51 | * | yingjun quit (Ping timeout: 245 seconds) |
12:11:23 | * | PMunch joined #nim |
12:40:39 | * | yingjun_ quit (Remote host closed the connection) |
12:42:18 | * | pilne joined #nim |
13:01:53 | FromGitter | <cooldome> Hi Araq, Iwanted to debug typerel function to figure out, why |
13:03:06 | FromGitter | <cooldome> why type StringArray[N] = array[N, string] |
13:03:59 | FromGitter | <cooldome> StringArray is array returns false, but it is simply too much goes through typerel function |
13:04:30 | FromGitter | <cooldome> Not clear how to filter on types, on Nodes it is easy |
13:06:18 | * | benny_ quit (Remote host closed the connection) |
13:06:26 | FromGitter | <cooldome> Apologies for bad typing, I am forced to use the phone |
13:07:39 | FromGitter | <krux02> @cooldome it's easier if you put your observations in a file that can be executed |
13:07:51 | FromGitter | <krux02> then we all can verify your results |
13:09:04 | FromGitter | <krux02> @cooldome neither StringArray nor array is a complete type |
13:11:43 | FromGitter | <cooldome> Sorry, because I work in env where github and gitter are prohibited, I can't do that. I am chatting from the phone. Types are not complete it is true, do you expect typerel to work only when one type is complete? |
13:12:20 | * | benny_ joined #nim |
13:13:16 | FromGitter | <krux02> cooldome: you are obviously already breaking the rules |
13:13:23 | FromGitter | <krux02> you are on gitter |
13:13:49 | FromGitter | <krux02> honestly I don't know typerel and how it works |
13:14:14 | FromGitter | <krux02> it's hard to reason about something that is not complete |
13:15:33 | * | krux02 quit (Remote host closed the connection) |
13:20:07 | FromGitter | <cooldome> Hmmm, I am tried couple more incomplete examples, looks like the problem is not array specific as I originally thought |
13:25:11 | FromGitter | <krux02> @cooldome whatever your question are, share your examples, otherwise it's hard to reason about them. When your work environment does not allow you to use tools to get your job done, quit your job, will only make you happier. Or you send your examples when you are home |
13:41:23 | * | yingjun joined #nim |
13:45:53 | * | yingjun quit (Ping timeout: 240 seconds) |
14:02:43 | * | xet7 quit (Remote host closed the connection) |
14:09:21 | * | xet7 joined #nim |
14:15:13 | * | gokr quit (Ping timeout: 255 seconds) |
14:18:58 | * | rauss joined #nim |
14:28:08 | * | gokr joined #nim |
14:30:56 | * | benny_ quit (Remote host closed the connection) |
14:36:17 | FromGitter | <krux02> It it normal that the nimsuggest creates a log file of several gigabytes? |
14:37:02 | * | krux02 joined #nim |
14:46:59 | Araq | no. |
14:53:30 | FromGitter | <andreaferretti> @Araq is my PR for c2nim ok? |
14:53:34 | FromGitter | <andreaferretti> I think I fixed everything |
14:53:40 | FromGitter | <andreaferretti> but travis cannot complete in time |
14:53:49 | FromGitter | <andreaferretti> because installing Nim takes time |
14:57:13 | FromGitter | <ephja> great PR |
15:02:37 | * | demi- quit (Quit: Server shutdown in 3... 2... 1...) |
15:05:43 | * | demi- joined #nim |
15:18:05 | FromGitter | <gogolxdong> ···type Matrix[M,N: static[int]] = array[M, array[N, float]] ⏎ ⏎ let x = [[1.0, 1.0, 1.0, 1.0], ⏎ ⏎ ```code paste, see link``` ... [https://gitter.im/nim-lang/Nim?at=5930302d5e34568d5eb22941] |
15:18:37 | FromGitter | <gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5930304df3001cd3427e5102] |
15:18:59 | FromGitter | <gogolxdong> why can't a * b |
15:19:11 | * | smt_ quit (Ping timeout: 245 seconds) |
15:23:15 | * | arnetheduck quit (Ping timeout: 268 seconds) |
15:25:01 | FromGitter | <gogolxdong> Is there any black magic in there? :) |
15:26:14 | FromGitter | <krux02> because a and b are of type int and `*` expects arrays of type float |
15:27:39 | FromGitter | <gogolxdong> yeah, I'm blind,thanks |
15:36:12 | shmup | not really ftsf. i kinda wanna make a cute sprite set of playing cards and do some nico card games. haggis would be one. i also kinda wanna make the tile game hive. i have an idea for a shmup sorta. a real simple one. i like those, like `Warning Forever`. |
15:36:52 | ftsf | cool =) |
15:36:59 | ftsf | i just did a youtube tutorial on making a shmup with nico |
15:37:22 | ftsf | https://www.youtube.com/watch?v=EwM1Z3WdqjM |
15:39:06 | * | Trustable joined #nim |
15:39:06 | shmup | hah, how utterly appropriate then. excited to watch. |
15:39:20 | ftsf | not sure how a good it is, but let me know what you think |
15:39:22 | shmup | the video is still unavailable however |
15:39:28 | ftsf | trying to get the hang of streaming |
15:39:28 | shmup | i was looking on your page earlier to see if it was up :P |
15:39:31 | ftsf | oh really |
15:39:41 | shmup | https://www.youtube.com/user/ftsf/videos |
15:39:43 | shmup | do you see it on your list? |
15:39:59 | ftsf | i do |
15:40:12 | ftsf | maybe only i can see it |
15:40:18 | ftsf | aha, draft |
15:40:19 | ftsf | fixed =) |
15:41:26 | * | shmup starts his lunch at works and Clicks Play |
15:41:55 | shmup | huh wasnt familiar with cga jam. nice. |
15:43:25 | shmup | i'm gonna shift the speed up and make it a 45 minute video and i'll let ya know how well it works :P |
15:43:32 | ftsf | cheers |
15:45:32 | shmup | my initial reaction is you just need to pick up your voice better, I think. work on clarity of speech maybe |
15:46:02 | ftsf | yeah, i get that a lot, not very good at the public speaking thing. |
15:46:07 | ftsf | need to practice |
15:46:24 | shmup | :) this seems like a pr nice way to practice |
15:49:54 | * | pilne quit (Read error: Connection reset by peer) |
15:50:25 | FromGitter | <ephja> do we have a thousand linear algebra implementations yet? :-) |
15:50:40 | * | pilne joined #nim |
15:53:41 | * | chemist69 quit (Ping timeout: 255 seconds) |
15:53:54 | shmup | as yes the famous missing fonts.png problem lol |
15:54:03 | shmup | is that a pico convention, ftsf? that it just looks for that file name |
15:54:04 | shmup | implicitely |
15:54:23 | * | Neomex joined #nim |
15:54:32 | ftsf | no, ideally i would encode the system font into the binary |
15:54:44 | ftsf | but i haven't figured out a nice way to do that yet |
15:59:21 | shmup | do you know about vim's ci, di, etc syntax? |
15:59:23 | shmup | like ci( |
15:59:29 | shmup | @ ftsf |
16:00:07 | * | chemist69 joined #nim |
16:02:47 | ftsf | shmup, i don't |
16:04:07 | shmup | useful for changing text inside of "" or () or <> or anything. ci( will clear it and put you in insert mode. :) |
16:04:22 | shmup | di( will not put you in insert mode. ok that's my vim lesson |
16:04:33 | ftsf | oh i see |
16:04:34 | ftsf | cool |
16:04:46 | ftsf | handy |
16:05:04 | ftsf | bedtime for me! ttyl o/ |
16:10:43 | * | joshbapt1 quit (Quit: WeeChat 1.6) |
16:10:54 | * | joshbaptiste joined #nim |
16:15:56 | * | Andris_zbx quit (Remote host closed the connection) |
16:16:47 | * | benny_ joined #nim |
16:17:46 | shmup | ttyl ftsf |
16:32:49 | * | yglukhov quit (Remote host closed the connection) |
16:33:10 | * | nsf quit (Quit: WeeChat 1.7.1) |
16:39:00 | * | rokups quit (Quit: Connection closed for inactivity) |
16:40:35 | * | krux02 quit (Remote host closed the connection) |
16:43:26 | * | yglukhov joined #nim |
16:47:27 | * | yglukhov quit (Ping timeout: 240 seconds) |
16:53:38 | * | faix joined #nim |
17:05:41 | * | smt joined #nim |
17:06:09 | * | smt_ joined #nim |
17:10:45 | * | smt quit (Ping timeout: 272 seconds) |
17:13:18 | * | faix quit (Ping timeout: 260 seconds) |
17:15:10 | * | libman joined #nim |
17:17:26 | * | benny__ joined #nim |
17:17:26 | * | benny_ quit (Read error: Connection reset by peer) |
17:42:42 | * | ofelas quit (Quit: shutdown -h now) |
17:44:22 | * | yglukhov joined #nim |
18:00:13 | * | yingjun joined #nim |
18:02:11 | FromGitter | <ephja> um. does nimble install every file in the directory? |
18:05:40 | * | yingjun quit (Ping timeout: 260 seconds) |
18:07:48 | FromGitter | <Varriount> @ephja What do you mean? |
18:08:07 | * | freevryheid joined #nim |
18:08:16 | * | freevryheid is now known as fvs |
18:10:43 | FromGitter | <ephja> nevermind |
18:17:43 | * | Matthias247 joined #nim |
18:28:25 | * | benny__ quit (Remote host closed the connection) |
18:29:29 | * | benny_ joined #nim |
18:39:39 | yglukhov | Araq: hi, does this crash log tell you anything? Can't reproduce it with a small sample. https://gist.github.com/yglukhov/de431ac6a1e1f4f309740b8b7abbe849 |
18:40:35 | * | benny_ quit (Remote host closed the connection) |
18:44:07 | PMunch | Any word on this: https://github.com/dom96/jester/issues/114 + |
18:46:27 | dom96 | Didn't get a chance to look at it yet I'm afraid |
18:50:46 | PMunch | Hmm, what does resp actually do under the hood? |
18:53:27 | * | yglukhov quit (Remote host closed the connection) |
18:53:33 | bozaloshtsh | https://github.com/dom96/jester/blob/master/jester.nim#L336 |
18:53:47 | bozaloshtsh | it doesn't return |
18:54:57 | PMunch | bozaloshtsh, last line # The ``route`` macro will add a 'return' after the invokation of this template. |
18:55:07 | dom96 | https://github.com/dom96/jester/blob/master/jester.nim#L613 |
18:55:31 | PMunch | By the way dom96 invocation is spelled with a C |
18:56:49 | dom96 | and yet it's 'invoke', silly English. But yes, I know. |
18:57:12 | FromGitter | <ephja> embrace lojban |
18:57:28 | PMunch | I'm guessing the route macro looks at the AST before the template is expanded? |
18:57:41 | PMunch | ephja, I actually looked at Lojban some years back |
18:57:47 | PMunch | Taught myself the basics |
18:57:50 | PMunch | Interesting language |
18:57:54 | dom96 | yep, that's precisely what happens |
18:58:02 | dom96 | There is no easy solution to your issue I'm afraid |
18:58:15 | dom96 | Jester's macro cannot see into the template |
18:58:47 | PMunch | But why is transformRouteBody the procedure adding the return? |
19:04:04 | PMunch | If that was moved to the resp template it would work right? |
19:08:46 | * | Neomex quit (Ping timeout: 245 seconds) |
19:10:10 | * | yglukhov joined #nim |
19:10:48 | * | Neomex joined #nim |
19:13:52 | dom96 | feel free to try it, but I'm certain I had a reason for doing it this way. I can't remember what that reason is though :) |
19:14:17 | * | yglukhov quit (Remote host closed the connection) |
19:16:36 | * | faix joined #nim |
19:16:43 | PMunch | I'm guessing it was to avoid code repetition |
19:16:55 | PMunch | return true for all redirect, halt, and resp templates? |
19:21:17 | * | Neomex_ joined #nim |
19:22:31 | * | Neomex quit (Ping timeout: 268 seconds) |
19:24:52 | PMunch | I'm guessing there's no way in Nim to check if it is a template symbol and then expand it manually in a macro? |
19:27:29 | FromGitter | <Varriount> PMunch: You might be able to use something with type and/or gensym |
19:27:50 | FromGitter | <Varriount> Or just use `try` and getAst |
19:31:58 | PMunch | getAst throws something? |
19:32:18 | PMunch | dom96, could this work? |
19:35:04 | PMunch | Oh and by the way: https://github.com/nim-lang/Nim/pull/5778 |
19:36:34 | * | yglukhov joined #nim |
19:37:08 | * | faix quit (Ping timeout: 260 seconds) |
19:43:23 | * | benny_ joined #nim |
19:48:12 | * | mcc quit (Quit: Connection closed for inactivity) |
19:51:10 | * | Arrrr quit (Read error: Connection reset by peer) |
19:55:55 | * | yglukhov quit (Remote host closed the connection) |
20:01:23 | libman | Lojban: a more boring version of Esperanto that doesn't help you get laid. |
20:01:33 | * | Trustable quit (Remote host closed the connection) |
20:07:36 | PMunch | Well, Lojban might be more boring but it has a lot of things going for it |
20:11:08 | * | yglukhov joined #nim |
20:13:34 | * | smt__ joined #nim |
20:15:21 | libman | PMunch: trying to design a logical language on the basis of verbal communication is a mistake. Interactive visual communication lets you add a lot more grammatical concepts. |
20:16:09 | dom96 | I just found out the reason and it's not to do with repetition. |
20:16:20 | dom96 | The body of a route gets put into an async proc |
20:16:33 | * | nsf joined #nim |
20:16:33 | libman | "Nim support added to Genode OS Framework (a toolkit for building highly secure special-purpose operating systems)" - https://genode.org/news/genode-os-framework-release-17.05 - Is this r/Nim news-worthy? |
20:16:35 | * | smt_ quit (Ping timeout: 240 seconds) |
20:16:40 | * | fvs left #nim ("leaving") |
20:16:47 | dom96 | So if the 'return' is inside the template then the 'async' macro cannot transform this 'return' so we're back to the same issue :) |
20:16:56 | dom96 | libman: of course |
20:17:02 | PMunch | libman, sure, why not? |
20:17:31 | FromGitter | <zacharycarter> deferred renderer coming along http://imgur.com/a/tHfV4 |
20:18:09 | * | faix joined #nim |
20:19:04 | PMunch | dom96, so templates are broken in async macros as well? |
20:19:15 | dom96 | yep |
20:19:19 | dom96 | you can't have 'await' in a template |
20:20:17 | PMunch | Hmm, that's not good |
20:20:33 | dom96 | This is more of a general Nim issue |
20:20:38 | PMunch | Yeah |
20:20:51 | PMunch | Shouldn't templates be expanded before macros are parsed? |
20:21:35 | * | Neomex_ quit (Quit: Leaving) |
20:22:58 | * | Neomex joined #nim |
20:23:14 | * | Vladar quit (Quit: Leaving) |
20:24:07 | dom96 | I doubt it's that simple |
20:25:35 | PMunch | Hmm, maybe not |
20:26:11 | PMunch | I can definitely see cases both for and against.. |
20:26:42 | PMunch | But mostly for tbh |
20:35:22 | * | faix quit (Ping timeout: 240 seconds) |
20:44:16 | FromGitter | <philip-wernersbach> What is the preferred way of using Nim's locks with its compile time deadlock prevention features? |
20:44:40 | FromGitter | <philip-wernersbach> From the docs, it looks like the Nim's locks are just runtime, and then the compile time features have to be added one top of that |
20:48:21 | Araq | yglukhov: nope, that's a new one |
20:48:54 | Araq | philip: the locks at runtime are posix/winAPI locks, the deadlock safety is all done at compiletime |
20:51:57 | yglukhov | Araq: ok, filed the issue, please tell me if you need any more info. |
20:52:33 | * | PMunch quit (Quit: leaving) |
20:56:34 | * | Sentreen quit (Ping timeout: 246 seconds) |
20:59:41 | FromGitter | <philip-wernersbach> @Araq Yes, but how do I bridge the two, so to speak |
20:59:57 | FromGitter | <philip-wernersbach> Use the runtime locks with the compiletime deadlock safety |
21:01:33 | Araq | the manual tells you this iirc, what's unclear about it? |
21:01:36 | * | rauss quit (Quit: WeeChat 1.8) |
21:03:38 | dom96 | Araq: What should we do about the problem that async macro cannot "look into" template invocations? |
21:03:41 | * | yingjun joined #nim |
21:04:23 | Araq | 'await' can be lowered to the 'yield' independently of .aysnc |
21:04:51 | Araq | it's a template iirc and then .async doesn't need to look into the template invocations |
21:05:02 | Araq | *it can be a template iirc |
21:05:56 | Araq | in general you cannot expand templates before macros because macros can become before the type checking phase and templates are expanded after overloading resolution etc etc |
21:06:20 | Araq | it's all intertwined |
21:06:28 | Araq | there are no simple solutions here. |
21:07:09 | FromGitter | <philip-wernersbach> @Araq Actually, I think you answered my question. So what you're saying is that the locks module does not implicitly use any of the compiletime deadlock features, so we have to add those on top of it? |
21:08:08 | * | yingjun quit (Ping timeout: 260 seconds) |
21:08:16 | FromGitter | <philip-wernersbach> ex. Lock the Lock object and then use the locks pragma, vs having the lock module use the pragma for us |
21:09:15 | Araq | https://nim-lang.org/docs/manual.html#guards-and-locks-lock-levels what it doesn't mention is, yeah you wrap the runtime lock in a dummy generic type with a static[int] parameter |
21:10:13 | * | Sentreen joined #nim |
21:10:42 | euantor | Looks like D does end up faster than Nim for parsing CSVs: https://github.com/euantorano/faster-command-line-tools-in-nim/issues/1#issuecomment-305621336 |
21:11:26 | euantor | Not by much though. I don't think I can optimise the Nim code much, but I haven't tried it parsing manually without using `parsecsv` |
21:13:18 | dom96 | euantor: You can always optimise further, same goes for the D version. I would just call it a tie at this point. |
21:13:34 | euantor | Yeah, that's my plan |
21:13:42 | FromGitter | <philip-wernersbach> @Araq Awesome, thanks for the clarification, makes sense |
21:13:45 | euantor | I've not got time to devote to beating this contrived benchmark |
21:14:03 | euantor | And we can always truthfully say that the Nim code is far more readable and easy to reason about |
21:14:25 | euantor | I'll be updating my blog post on Saturday, and will update the one on the website at the same time |
21:14:52 | Araq | also you use Nim's stdlib that can deal with escaped values ... |
21:15:02 | Araq | split for CSV is like using regexes for HTML really |
21:15:40 | Araq | ";";33;";;";44 |
21:15:57 | Araq | is a valid CSV though it doesn't really have a stanard |
21:16:07 | Araq | *standard |
21:16:43 | Araq | philip-wernersbach, it pains me to see 0.17 cannot compile your project. any ideas how to prevent such a pita in the future? |
21:17:18 | euantor | Yeah, the original benchmark actually notes that inside its GitHub repository |
21:17:33 | euantor | I'll also note that in the blog post |
21:20:46 | Araq | also try --gc:markAndSweep |
21:20:56 | Araq | can be faster and use more memory ;-) |
21:21:54 | FromGitter | <zacharycarter> http://imgur.com/a/tHfV4 not sure why everything is green but I think other than that the deferred renderer is working |
21:22:00 | FromGitter | <zacharycarter> wrong ss |
21:22:31 | FromGitter | <zacharycarter> (https://files.gitter.im/nim-lang/Nim/2dkc/Screen-Shot-2017-06-01-at-5.16.43-PM.png) |
21:26:43 | libman | I'll never understand why CSV became more popular than TSV (tab separated values). The latter avoids most escaping issues. |
21:27:21 | euantor | TSV is what I'm benchmarking, but using the parsecsv module |
21:28:19 | Araq | libman: because tabs and spaces look the same and people already mess up CSVs *everywhere* |
21:28:35 | Araq | in fact, I never got a correct CSV on the first attempt |
21:29:11 | Araq | users can be really dumb. |
21:31:17 | euantor | Mark & sweep is actually slower in this case - 1.3s for standard, 1.54s for mark & sweep. Same amount of memory (1.9Mb) |
21:32:14 | FromGitter | <ephja> is an object type with a tuple field always binary compatible with another object type that has separate fields for those in the tuple? |
21:33:52 | * | benny_ quit (Remote host closed the connection) |
21:34:05 | FromGitter | <ephja> tuple[w, h, r, g, b, refreshRate: int32] -> tuple[tuple[w, h: int32], tuple[r, g, b: int32], refreshRate: int32] |
21:35:04 | Araq | ephja. no, it is not but for your example the alignments match |
21:41:12 | FromGitter | <zacharycarter> WEWT |
21:41:27 | FromGitter | <zacharycarter> (https://files.gitter.im/nim-lang/Nim/pNZI/Screen-Shot-2017-06-01-at-5.41.01-PM.png) |
21:41:52 | FromGitter | <zacharycarter> 128 lights |
21:47:25 | FromGitter | <Varriount> @zacharycarter 128 lights, 7 cameras, all action |
21:47:50 | FromGitter | <zacharycarter> :P |
21:48:11 | FromGitter | <zacharycarter> I'm just happy to have finally properly implemented deferred shading |
21:48:13 | FromGitter | <zacharycarter> what a bitch |
21:48:44 | Araq | zacharycarter: what do you use for rendering? |
21:49:04 | Araq | new engine on top of OpenGL? |
21:49:21 | FromGitter | <zacharycarter> https://github.com/bkaradzic/bgfx |
21:51:24 | FromGitter | <zacharycarter> Araq: hopefully when GL is replaced by Vulkan / Metal I won't have to do anything crazy |
21:51:44 | FromGitter | <zacharycarter> just compile shaders for whatever render backend |
21:52:33 | * | Neomex quit (Quit: Leaving) |
21:55:59 | Araq | ah ok |
22:00:28 | * | PMunch joined #nim |
22:03:57 | FromGitter | <ephja> Araq: but not if the second tuple field had been the first field? |
22:04:38 | Araq | hmm? they all use int32 |
22:04:42 | * | lenstr joined #nim |
22:08:26 | * | yglukhov quit (Remote host closed the connection) |
22:11:58 | FromGitter | <ephja> you're right. I haven't dealt with these issues in a while |
22:17:43 | libman | Aesthetic question regarding the Nim style guide: is it a good idea to use camelCase names for exe names, like `nimup` vs `nimUp` (if one was to make an equivalent to `rustup` / binary alternative to choosenim) ? |
22:18:08 | * | chemist69 quit (Ping timeout: 240 seconds) |
22:18:31 | * | chemist69 joined #nim |
22:23:41 | Araq | exe names should always be alllowercase on Unix |
22:24:03 | PMunch | And no symbols |
22:24:16 | Araq | and no vowels |
22:24:20 | PMunch | Less of a rule and more of a bad-style kind of thing |
22:24:21 | PMunch | :P |
22:24:40 | PMunch | I meant hello_world would be a bad name |
22:25:44 | Araq | yeah, also watch out for vowels. all the good commands are without them; gcc llvm cp rm lk |
22:25:46 | * | libman aborts his camelcase exe name rebellion. |
22:26:04 | Araq | grep # bad |
22:26:07 | Araq | find # bad |
22:26:09 | Araq | nim # bad |
22:26:11 | PMunch | Ey, grep is nice |
22:26:20 | PMunch | Well, the other two as well :P |
22:26:31 | PMunch | And then you've got man |
22:26:48 | PMunch | Or sudo :) |
22:26:49 | Araq | make # bad, should have been mk |
22:27:00 | Araq | I think LSD fixes that though |
22:27:08 | Araq | and uses 'mk' |
22:27:16 | libman | If writing a shell script, can I use nimStyle instead of YE_OLDE_ENVIRONMENTAL_VARIABLES_ALWAYS_VERY_LOUD |
22:27:42 | Araq | I don't write shell scripts, I write Nim programs |
22:28:18 | PMunch | I'd stick with YE_OLDE_STYLE |
22:28:21 | libman | You could still need a shell script to install a Nim program in one curl|sh. |
22:28:31 | Araq | of course I'm kidding, the vowel thing is mostly for historic reasons. Unix predates the invention of vowels. |
22:28:43 | FromGitter | <zacharycarter> lol |
22:29:01 | FromGitter | <zacharycarter> name three things you hate more than unix Araq |
22:29:36 | Araq | oooh that's a tough one. |
22:29:39 | FromGitter | <zacharycarter> :P |
22:30:11 | Araq | Eclipse and Java come to mind. |
22:30:20 | FromGitter | <zacharycarter> yessss |
22:30:26 | PMunch | I was actually positively surprised to see how well everything works with UNIX considering your cold feelings for us :) |
22:30:45 | FromGitter | <zacharycarter> Java and Eclipse are both pretty terrible |
22:30:50 | PMunch | And I realise I'm in the wrong chat, Eclipse and Java are my friends |
22:31:04 | PMunch | They have their benefits |
22:31:06 | libman | I've been phasing out my scriptie degeneracy. No more Python, no JS, etc. Korn shell is the only thing I'm still allowed to use. One more step to plain sh. |
22:31:08 | FromGitter | <ephja> there are a couple of warts though, but some aspects are neat |
22:31:14 | PMunch | But I'm growing apart from Java |
22:31:25 | FromGitter | <zacharycarter> Java is horrible, if you're stuck on the JVM at least move to Kotlin |
22:31:27 | FromGitter | <ephja> (unix) |
22:31:28 | PMunch | Korn shell? |
22:31:56 | PMunch | zacharycarter, yeah it's a bit of a pain sometimes.. |
22:31:58 | FromGitter | <ephja> yeah. ksh |
22:31:59 | libman | mksh is the one true shell. |
22:32:15 | PMunch | Some really odd design choices in Java... |
22:32:28 | FromGitter | <ephja> libman: is it strongly typed? :-) |
22:32:48 | FromGitter | <ephja> I meant statically typed |
22:32:52 | libman | Yes, everything is a very strong string. |
22:33:00 | FromGitter | <ephja> wow |
22:33:24 | FromGitter | <ephja> radical |
22:34:48 | Araq | stringly typed code is only bad when it's PHP, when it's Unix it's holy |
22:34:53 | * | benny_ joined #nim |
22:35:33 | PMunch | https://github.com/nim-lang/Nim/pull/5885 did you see that Araq? |
22:35:41 | libman | The next step is to write a Nim static code generator that creates a macro for every exe in your $PATH, so you can execute them without any boilerplate, like in shell... O.O |
22:36:12 | Araq | because then you can pipeline programs that do not work together that then work even worse |
22:36:31 | libman | Tcl also did stringly code pretty well. |
22:36:38 | Araq | ^ yup. |
22:37:17 | * | yglukhov joined #nim |
22:37:20 | FromGitter | <zacharycarter> I'm not sure how much of an issue this is vs just not doing things correctly on my part but : https://github.com/nim-lang/Nim/issues/5878 has been around for a week or so now and hasn't been triaged |
22:38:02 | FromGitter | <zacharycarter> it's the most minimal example I could come up with to reproduce the *issue* |
22:38:05 | FromGitter | <ephja> just produce some kind of result, regardless of whether or not the strings are formatted correctly :-) |
22:39:13 | * | benny_ quit (Ping timeout: 255 seconds) |
22:40:11 | Araq | PMunch: how about this? I move the db_ modules to a new nim-lang/db_support Nimble package and you create a PR patching all modules at the same time to ensure consistency? |
22:40:19 | * | vlad1777d quit (Remote host closed the connection) |
22:40:36 | Araq | and then db_* modules in the stdlib get .deprecated |
22:40:58 | Araq | and we add big fat notes to not ever use them for new code |
22:41:34 | * | yglukhov quit (Ping timeout: 246 seconds) |
22:41:40 | * | Nobabs27 joined #nim |
22:42:07 | FromGitter | <philip-wernersbach> @Araq In regards to preventing such a pita as not being able to compile my project, I'm actually going to propose a new initiative on the Nim forum. That we select real world projects from the community, and set something up that recompiles those for every commit in the Nim repository |
22:42:16 | Araq | in fact, some common database meta-scheme has been designed and implemented for db_mysql |
22:42:28 | Araq | philip: I have heard that before :-) |
22:42:37 | FromGitter | <philip-wernersbach> Did it go anywhere? |
22:42:39 | FromGitter | <ephja> so.. did you relax on the beach, reading fowl's beautiful code on your vacation? |
22:43:00 | Araq | I know others are keen on doing that too, but nobody makes the first move |
22:43:31 | FromGitter | <philip-wernersbach> I think the biggest issue is that Nim has unit tests, but no real world test suite. So there are real world cases that the unit tests don't cover, and we only discover them through breaking them |
22:43:37 | FromGitter | <philip-wernersbach> Well I'll do it |
22:43:46 | FromGitter | <philip-wernersbach> The community will just have to decide what's included |
22:43:57 | Araq | setup some CI server and tell others to submit things= |
22:43:59 | Araq | ? |
22:44:13 | FromGitter | <philip-wernersbach> Exactly |
22:44:26 | Araq | ok, cool |
22:44:38 | FromGitter | <philip-wernersbach> I'll post about it tomorrow when I get time |
22:45:18 | * | smt_ joined #nim |
22:45:40 | FromGitter | <philip-wernersbach> Another idea I had is just deciding that to be more careful about changing things in the core compiler. But that's probably not realistic |
22:47:06 | Araq | I have a "real world test suite" but I missed your project and it's mostly for our closed source projects, so I cannot open source it |
22:48:48 | Araq | "more careful", well yeah, we are careful but unit tests always lack some crucial feature interaction and last time I checked most quality compilers are tested against real world projects |
22:48:55 | * | smt__ quit (Ping timeout: 260 seconds) |
22:49:10 | Araq | I know Scala's is. |
22:51:23 | gokr | Araq: Do you really need to "submit things" - why not just compile your way through nimble packages? :) |
22:52:03 | * | nsf quit (Quit: WeeChat 1.7.1) |
22:52:06 | FromGitter | <zacharycarter> there's no standardization for nimble packages |
22:52:19 | FromGitter | <zacharycarter> besides saying hey this is a package and it should be added to nimble |
22:52:24 | Araq | nimble is full of semi-dead, really dead, Linux specific packages |
22:52:28 | FromGitter | <philip-wernersbach> @Araq Ah I see. Is there anything from that, that you can open source? I could use it as a jumping off point |
22:53:17 | FromGitter | <philip-wernersbach> And for instance on being more careful. The sighashes thing. That's a good to have, but not required. So under the being more careful rule, it wouldn't have gone into release for a couple releases |
22:54:04 | Araq | I personally wouldn't have done it at all but I was payed ... -.- |
22:54:09 | PMunch | Araq, that would work. But I don't have time to do it now |
22:54:15 | FromGitter | <zacharycarter> I don't think changes should stagnate based on their usefulness |
22:54:19 | PMunch | Working on my masters until the summer. |
22:55:03 | FromGitter | <zacharycarter> I think the be more careful rule = set up what you consider careful and run tests against it |
22:55:11 | FromGitter | <zacharycarter> like you've both described |
22:55:23 | FromGitter | <philip-wernersbach> Well, changes equal regression. You can't regress what you don't change. But I agree there's a balancing act |
22:55:32 | FromGitter | <zacharycarter> truth |
22:55:42 | FromGitter | <zacharycarter> this is why things have |
22:55:47 | FromGitter | <zacharycarter> supported release |
22:55:51 | FromGitter | <zacharycarter> experimental release |
22:56:00 | Araq | PMunch: I replied. |
22:56:34 | FromGitter | <zacharycarter> I think nightly nim releases would go a long way |
22:56:55 | Araq | how so? git pull && koch boot -d:release |
22:57:02 | Araq | there is your nightly Nim. |
22:57:24 | FromGitter | <zacharycarter> point taken |
22:58:01 | Araq | btw there is a standard but it's well hidden. it's always 'nimble tests' |
22:58:27 | FromGitter | <zacharycarter> ah good to know |
22:59:06 | FromGitter | <philip-wernersbach> I would prefer to see all of the non-essential core compiler changes go into a "next" branch, and sit there for a couple releases. That way high impact changes could get more testing |
22:59:19 | FromGitter | <philip-wernersbach> What does nimble tests do? |
22:59:35 | Araq | it runs your nimscript 'tests' task |
23:00:12 | FromGitter | <philip-wernersbach> Also, these are just my thoughts, I don't spend time developing the Nim compiler, so I can go kick rocks ha |
23:00:14 | FromGitter | <zacharycarter> oh you were being sarcastic haha |
23:00:34 | Araq | no I was serious |
23:01:02 | Araq | the command line standard is 'nimble tests' to run the tests |
23:01:07 | FromGitter | <zacharycarter> well what I meant was there's no way of vetting nimble packages right? like submit a PR and if it builds it builds and then a few weeks later when someone stops updating it |
23:01:43 | FromGitter | <zacharycarter> this is all to @gokr 's point earlier about letting nimble itself be the test |
23:03:36 | gokr | What does it really matter about quality of the packages themselves? Just build and see if they build. Record which ones built. Set alarm if someone suddenly does NOT build. |
23:04:24 | gokr | AFAICT the interesting bit is the change from "builds fine with nim 0.8" -> "breaks with nim 0.9". |
23:04:33 | gokr | Or vice versa :) |
23:04:47 | Araq | gokr: the problem is the "just build" part. |
23:05:11 | gokr | Quality of code doesn't matter - in fact - bad quality code is probably very interesting too - since it can catch corner cases. |
23:11:05 | Araq | ephja: actually I came up with a new way to build sandcastles |
23:11:11 | Araq | :-) |
23:11:30 | dom96 | it's actually "nimble test" |
23:11:33 | dom96 | not the plural :P |
23:12:07 | Araq | dom96: not what our docs say |
23:12:14 | FromGitter | <ephja> Araq: I see *lol* |
23:12:28 | Araq | https://nim-lang.org/docs/nims.html |
23:12:35 | Araq | tests Runs the tests belonging to the project. |
23:13:33 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:14:03 | dom96 | That should just be removed, it's not convention to specify tasks like this in .nims files |
23:18:33 | Araq | meh |
23:19:03 | Araq | ok |
23:19:29 | FromGitter | <philip-wernersbach> Bye everyone, quitting time for me |
23:19:41 | FromGitter | <zacharycarter> o/ |
23:34:47 | * | PMunch quit (Quit: leaving) |
23:38:01 | * | daaf joined #nim |
23:45:26 | * | benny_ joined #nim |
23:51:08 | * | benny_ quit (Ping timeout: 260 seconds) |