00:00:55 | * | strcmp2 quit (Ping timeout: 240 seconds) |
00:04:02 | desophos | i suspect that any port of a large project is very difficult to maintain |
00:05:59 | BlueProtoman | ECSes don't have to be large |
00:06:01 | desophos | because in addition to writing the port, you have to keep up with development on the original project |
00:06:12 | desophos | and that includes maintaining all dependencies |
00:06:47 | desophos | i was under the impression that you wanted to port a large one |
00:08:06 | BlueProtoman | Artemis and Ash (two most likely candidates) aren't all that large |
00:10:21 | desophos | Ash is in AS3??? lol |
00:11:05 | BlueProtoman | Of course, a port would be mindful of AS3/Java/something else tricks that aren't relevant to Nim |
00:11:31 | desophos | is Artemis abandoned? looks like artemis-odb is the actively maintained fork? |
00:11:44 | desophos | pseudo-fork |
00:12:12 | BlueProtoman | Raw artemis is abandoned, yes, but the design is still solid. artemis-odb is massive, and a lot of it seems to be Java-specific optimizations |
00:13:04 | desophos | the site is gone |
00:13:12 | desophos | the artemis site |
00:14:06 | BlueProtoman | There's a fork here https://github.com/tescott/artemis |
00:17:51 | desophos | it would be interesting to "port" a java framework |
00:18:20 | desophos | because java's very strong opinions conflict with nim's |
00:18:32 | desophos | i mean java's concept of OOP |
00:18:47 | BlueProtoman | And a port to Nim would pay close attention to those opinions so they don't accidentally pollute it |
00:18:53 | desophos | yes |
00:18:59 | * | pregressive joined #nim |
00:20:20 | * | applejugz joined #nim |
00:20:26 | desophos | do you know AS3 or java/ |
00:20:27 | desophos | *? |
00:20:35 | applejugz | how can I make an executable in nim? |
00:20:37 | desophos | or both, i suppose? |
00:20:52 | BlueProtoman | Java, yes. AS3 is easy to read |
00:20:58 | desophos | applejugz: something wrong with `nim c myfile.nim`? |
00:21:26 | applejugz | oh, that can be ran across platforms, desophos ? |
00:21:55 | desophos | applejugz: are you asking about cross-compilation? |
00:22:06 | desophos | because the compiler can compile for any platform |
00:22:47 | applejugz | Yeah, that's what I meant. That's awesome though! I thougt i needed to do something fancy to get it to work on Windows or Mac |
00:23:20 | desophos | nope, `nim c myfile.nim` will produce myfile.exe on windows and a myfile binary on mac |
00:23:44 | * | pregressive quit (Ping timeout: 244 seconds) |
00:23:48 | desophos | to produce myfile.exe on mac (cross-compilation) you'd have to do something a little more specific, i haven't looked into it |
00:23:58 | desophos | applejugz: http://nim-lang.org/docs/nimc.html might help |
00:24:14 | desophos | applejugz: specifically http://nim-lang.org/docs/nimc.html#cross-compilation |
00:26:02 | desophos | BlueProtoman: is java not easy to read? |
00:26:06 | desophos | i thought it was |
00:26:10 | desophos | but i haven't used it in years |
00:26:26 | BlueProtoman | desophos: No, it is. I'm saying I *do* know Java, and while I *don't* know AS3 I know that it's easy to read so I can figure it out |
00:26:33 | desophos | ah okay i see |
00:27:12 | desophos | well i might be biased but i am suspicious of anything written in AS3 |
00:27:21 | desophos | although i don't know the language |
00:27:35 | desophos | so probably just a fear of the unknown :) |
00:28:28 | desophos | but i imagine it would be easier to port something written in a language you know |
00:28:42 | BlueProtoman | If it were some schmuck in a basement doing it, sure. But Richard Lord is a professional. http://www.richardlord.net/ |
00:29:17 | * | BitPuffin|osx joined #nim |
00:30:32 | BlueProtoman | True, but there's another thing; Nim's implementation details would likely be *very* different than those of the original language. So while the interface would be the same, the implementation would be Nim-tailored |
00:31:18 | * | applejugz quit (Ping timeout: 246 seconds) |
00:31:37 | desophos | likely indeed |
00:32:26 | desophos | but i think re-implementing would be easier depending on the ease of understanding the original implementation |
00:33:12 | BlueProtoman | Honestly, I think a Nim port would turn out as a reimplementation anyway. I'm just describing it as a port so that my intentions are better understood. |
00:37:41 | desophos | well, is there really such a thing as a port? unless it's java <-> C# or other very similar languages, i imagine most ports require reimplementation |
00:37:44 | desophos | most decent ports anyway |
00:38:23 | BlueProtoman | You're right. Again, I'm just calling it a port to make it not seem as daunting. |
00:38:31 | desophos | haha sure |
01:04:51 | * | thotypous quit (Ping timeout: 252 seconds) |
01:07:37 | * | thotypous joined #nim |
01:11:18 | * | desophos quit (Ping timeout: 260 seconds) |
01:18:18 | * | desophos joined #nim |
01:22:59 | * | desophos quit (Ping timeout: 264 seconds) |
01:29:39 | * | ephja quit (Ping timeout: 255 seconds) |
01:30:18 | * | perturbation joined #nim |
01:52:02 | * | strcmp2 joined #nim |
01:52:02 | * | kniteli joined #nim |
01:58:33 | * | BlueProtoman quit (Quit: Leaving) |
02:00:18 | * | johnsoft quit (Quit: Leaving) |
02:05:15 | * | jaco60 quit (Ping timeout: 240 seconds) |
02:05:44 | * | perturbation quit () |
02:09:30 | * | johnsoft joined #nim |
02:37:28 | * | distortedsignal joined #nim |
02:44:56 | * | desophos joined #nim |
02:48:57 | * | brson quit (Quit: leaving) |
02:51:00 | * | BitPuffin|osx quit (Ping timeout: 244 seconds) |
03:18:46 | * | strcmp2 quit (Read error: Connection reset by peer) |
03:20:57 | * | julian37 quit (Ping timeout: 250 seconds) |
03:46:07 | * | vendethiel joined #nim |
04:17:17 | * | julian37 joined #nim |
04:17:18 | * | xtagon joined #nim |
04:22:30 | * | julian37 quit (Ping timeout: 260 seconds) |
04:33:41 | * | darkf joined #nim |
04:42:21 | * | gunn joined #nim |
04:47:30 | * | thotypous quit (Ping timeout: 240 seconds) |
04:47:39 | * | zaquest quit (Ping timeout: 255 seconds) |
04:48:38 | * | zaquest joined #nim |
04:50:37 | * | thotypous joined #nim |
04:50:42 | gunn | Hi |
04:50:59 | gunn | I'm trying to get nim to do some maths in parallel, but getting an error - cannot create a flowVar of type: BigInt |
04:51:02 | gunn | https://gist.github.com/gunn/9269eaf7ff001485ce5e |
05:18:35 | * | vendethiel quit (Ping timeout: 252 seconds) |
05:30:49 | * | zaquest_ joined #nim |
05:31:08 | * | zaquest quit (Ping timeout: 246 seconds) |
06:00:36 | vegansk | @gunn, the documentation says: Due to technical limitations not every type T is possible in a data flow variable: T has to be of the type ref, string, seq or of a type that doesn't contain a type that is garbage collected. This restriction is not hard to work-around in practice. |
06:03:11 | gunn | vegansk: yep, do have any ideas how to work around it? |
06:05:32 | vegansk | Serialize to string in ``segment``, then deserialize to BigInt? |
06:06:29 | vegansk | Or return ref BigInt? |
06:14:01 | * | Demon_Fox quit (Quit: Leaving) |
06:15:54 | * | cyraxjoe quit (Remote host closed the connection) |
06:16:10 | * | cyraxjoe joined #nim |
06:18:24 | * | julian37 joined #nim |
06:19:14 | * | cyraxjoe quit (Read error: Connection reset by peer) |
06:19:37 | * | cyraxjoe joined #nim |
06:19:43 | gunn | vegansk: ah, good ideas thanks |
06:20:03 | gunn | serializing to string and back works |
06:20:18 | gunn | I don't know enough nim yet to do it with refs |
06:23:07 | * | julian37 quit (Ping timeout: 252 seconds) |
06:25:45 | * | nande quit (Ping timeout: 255 seconds) |
06:28:26 | * | nande joined #nim |
06:37:15 | * | gour joined #nim |
06:39:56 | * | gour_ joined #nim |
06:42:46 | * | gour quit (Ping timeout: 250 seconds) |
06:50:48 | * | gour_ quit (Quit: WeeChat 1.3) |
06:51:05 | * | gour joined #nim |
06:58:44 | * | gour quit (Quit: WeeChat 1.3) |
06:59:06 | * | gour joined #nim |
07:02:50 | * | xtagon quit () |
07:02:51 | * | gour quit (Client Quit) |
07:04:57 | * | gour joined #nim |
07:06:23 | * | gour quit (Client Quit) |
07:07:19 | * | gour joined #nim |
07:11:23 | * | gour quit (Client Quit) |
07:12:54 | * | gour joined #nim |
07:23:02 | * | desophos quit (Read error: Connection reset by peer) |
07:23:09 | * | nande quit (Remote host closed the connection) |
07:23:47 | vegansk | @gunn, like this: https://gist.github.com/vegansk/c5bfab052f3fe127ff73 |
07:25:09 | gunn | vegansk: thanks! |
07:25:30 | gunn | I've been making slow trial and error progress |
07:26:21 | gunn | result[] = sum sure beats what I'd been doing: |
07:26:37 | gunn | result.limbs = sum.limbs; result.flags = sum.flags |
07:46:35 | * | yglukhov quit (Ping timeout: 240 seconds) |
07:49:27 | * | julian37 joined #nim |
07:50:05 | * | vqrs quit (Ping timeout: 246 seconds) |
07:53:30 | * | julian37 quit (Ping timeout: 240 seconds) |
07:53:44 | * | vqrs joined #nim |
08:02:03 | * | zaquest_ is now known as zaquest |
08:05:17 | * | distortedsignal left #nim (#nim) |
08:11:16 | * | strcmp1 joined #nim |
08:22:54 | * | gokr joined #nim |
08:29:30 | * | strcmp2 joined #nim |
08:31:11 | * | strcmp3 joined #nim |
08:31:24 | * | gokr1 joined #nim |
08:32:46 | * | strcmp1 quit (Ping timeout: 260 seconds) |
08:33:45 | * | strcmp2 quit (Ping timeout: 240 seconds) |
08:35:03 | * | gokr quit (Ping timeout: 265 seconds) |
08:35:30 | gunn | I think I've finished my parallel factorial program: https://gist.github.com/gunn/9269eaf7ff001485ce5e |
08:35:42 | gunn | The number of threads can easily be scaled |
08:37:15 | gunn | I was hoping it would use multiple cpu cores but it seems to be just maxing out 100% of one |
08:38:22 | Araq | gunn: when this happens you're not giving each 'spawn' enough to work with |
08:39:01 | Araq | or the folding step takes all the time |
08:39:10 | Araq | benchmark it |
08:39:28 | gunn | Araq: do you mean not enough work? |
08:39:44 | gunn | the fold step is tiny |
08:40:44 | Araq | hrm |
08:42:29 | * | strcmp1 joined #nim |
08:43:02 | Araq | well it should use 8 cores |
08:43:09 | gunn | Araq: the idea is each spawn processes 1/8th of the factorial each, the fold step multiplies the resulting 8 figures |
08:43:18 | Araq | I know |
08:43:22 | gunn | using 50,000 as an input it takes 4 seconds |
08:43:25 | strcmp1 | Araq: why is that? does spawn manage its own thread pool that distributes work according to load? |
08:43:49 | Araq | strcmp1: yeah exactly but the code doesn't even rely on this fact |
08:45:42 | * | strcmp3 quit (Ping timeout: 255 seconds) |
08:45:55 | Araq | gunn: what if you use 100_000 as an input? |
08:46:49 | * | gour just watched first 30mins of Araq's video (to be continued...) |
08:48:35 | gunn | Araq: takes 0m18.108s, constant 99.9% |
08:51:58 | Araq | well hrm. just time it against a non-parallel implementation |
08:52:12 | * | ziggypup joined #nim |
08:52:13 | Araq | and compute the speedup |
08:52:14 | * | ziggypup left #nim (#nim) |
08:52:27 | Araq | (which might even be a slowdown...) |
08:53:03 | * | Trustable joined #nim |
08:53:37 | niv | hello! i'm seeing some clang errors when compiling a specific piece of code that uses the sequtils.mapIt template. i'm new to nim so maybe im doing something wrong but this looks like a bug to me. https://gist.github.com/niv/67d0675d59ea0be77b50 can anyone confirm, and should i create a new issue? |
08:55:06 | Araq | niv: pretty sure this bug has been reported already |
08:55:14 | Araq | but it cannot hurt to report it |
08:55:23 | * | strcmp1 quit (Ping timeout: 264 seconds) |
08:55:25 | niv | alright |
08:55:40 | gunn | Araq: updated https://gist.github.com/gunn/9269eaf7ff001485ce5e with the linear version. Almost identical times |
08:56:08 | niv | seems to be related to the object that is passed in as an arg and somehow mapIt. if i rewrite it to use map(), it compiles, even though neither of them ever references the struct |
08:57:32 | * | julian37 joined #nim |
09:09:15 | * | coffeepot joined #nim |
09:10:50 | Araq | gunn: is parallel slower or faster? |
09:12:00 | gunn | Araq: parallel is faster by about 1% |
09:12:22 | Araq | lol that's pretty bad, do you use -d:release ? |
09:12:26 | gunn | yep |
09:13:07 | gunn | I would guess it's because of the order of the numbers being multiplied rather than any parallel effect |
09:13:54 | Araq | well instead of 1.. N/8 you can increment the step count by 8 |
09:14:44 | Araq | so the first thread does 1*9*17*25 ... , the second 2*10*18*26 |
09:14:54 | Araq | etc |
09:15:26 | Araq | so every thread handles equally large numbers |
09:16:10 | gunn | that would be smarter |
09:23:53 | * | darkf quit (Ping timeout: 246 seconds) |
09:24:01 | * | s4 joined #nim |
09:24:11 | * | darkf joined #nim |
09:33:07 | * | wan quit (Quit: WeeChat 1.3) |
09:40:36 | * | yglukhov joined #nim |
09:41:10 | gour | Araq: what does it mean "Install wxnim next to a directory wxWidgets-3.0.2", iow. is it possible to install wxnim via nimble? |
09:45:06 | gour | Araq: otoh, if i try to compile example1, i get the following: https://bpaste.net/show/b351be26615d |
09:47:20 | Araq | gour: it means to have the following dir structure foobar/wxWidgets-3.0.2 |
09:47:24 | Araq | foobar/wxnim |
09:47:32 | gour | that i have |
09:47:43 | gour | how to invoke build? |
09:48:04 | Araq | and you need to build wxWidgets-3.0.2 via its autoconf abomination or something |
09:48:17 | Araq | so that it generates wx/setup.h |
09:48:33 | gour | ahh, ok. |
09:49:07 | * | ziggypup joined #nim |
09:49:10 | * | ziggypup left #nim (#nim) |
09:49:44 | Araq | and yeah you should write a wx.nims script file to automate this process, when I wrote wxnim there was no nims |
09:59:31 | niv | I have a design question. why is nim using signed integers (int) for values that are clearly unsigned - for example, stream positions, or array offsets? |
10:01:55 | Araq | because there is no such thing as a "clearly unsigned integer" |
10:02:18 | Araq | you're confusing natural numbers which cannot be zero with unsigned wrap around arithmetics |
10:02:39 | Araq | for i in 0 .. length - 4: echo i |
10:02:53 | Araq | should run 0 times when length == 0 |
10:02:59 | Araq | not ~4 billion times |
10:03:17 | niv | yeah, maybe so. i was thinking about stream.setPosition, for example. on 32bit, you're limited to 2GB of stream size, and it accepts negative positions too |
10:04:01 | Araq | maybe it should indeed take int64 |
10:04:22 | niv | thats all im asking, if there was a design decision why using int was the better choice that im missing |
10:04:57 | * | makoLine quit (Ping timeout: 252 seconds) |
10:05:14 | Araq | we usually use 'int' as the default type |
10:06:06 | niv | i agree it doesn't matter in 99% of cases, and makes for simpler&prettier reading :) but w.r.t. file streams, or similar procs that use offsets, it might run into issues |
10:07:03 | Araq | pretty sure I used streams for files bigger than 4 GB |
10:07:35 | Araq | setPosition is a weird operation for streams to begin with |
10:07:40 | niv | i havent tried it, just thinking academically here. int is sizeof(pointer) on 32bit, which would limit it to that for the given procs at least |
10:08:01 | Araq | setPosition is limited to this, streams are not |
10:08:32 | niv | i using stream.setPos to parse a binary file format, like zip - where it reads a header and then just gives you an offset where the actual data is |
10:09:34 | niv | its not going to run into the 32bit wall anytime soon :) but i just noticed it while browsing the api docs |
10:10:27 | niv | anyways, alright, thanks :) |
10:10:41 | Araq | yeah we should change it to int64 |
10:12:03 | Araq | yglukhov: your bug is dead simple to reproduce ;-) |
10:12:53 | yglukhov | Araq: and dead simple to fix i suppose? ;) |
10:14:55 | Araq | yup |
10:20:13 | gunn | Araq: I think the behaviour we're seeing is simply due to multiplying two massive BigInts taking a long time - i.e. the last 8 multiplications in the foldl actually is the bulk of execution time. |
10:20:21 | gunn | whoops |
10:20:26 | gunn | I rewrote as you suggested, same performance. |
10:21:06 | Araq | benchmark it to be sure |
10:21:18 | Araq | but if so that's a really nasty problem :-/ |
10:21:38 | Araq | because then you need to parallelize bignum multiplications |
10:22:12 | gunn | well the figures we're talking about are very big |
10:22:43 | gunn | e.g. 9e89000 * 3e110000 |
10:24:17 | gunn | figures on that scale take about 2 seconds to multiply |
10:25:21 | * | jaco60 joined #nim |
10:25:43 | Araq | well you should see a speedup of 8 for smaller numbers then? |
10:26:03 | Araq | with the increment by 8 version |
10:26:51 | Araq | and for tiny numbers a slowdown because of threading overhead -.- |
10:27:43 | gunn | Araq: very close for every input |
10:28:15 | gunn | I suspect this is just the nature of factorials scaling quickly |
10:28:48 | Araq | perhaps but also try multiprocessing |
10:29:30 | gunn | what do you mean? |
10:29:30 | Araq | maybe there is also some serious serialization bug in the threadpool preventing it from scaling |
10:29:35 | dom96 | LibMan has a good eye for videos. |
10:38:11 | * | mindriot101 joined #nim |
10:53:02 | * | Varriount-Laptop joined #nim |
10:57:45 | * | theduke quit (Ping timeout: 252 seconds) |
11:09:54 | * | theduke joined #nim |
11:13:55 | niv | is there a (high-level) evented networking library native to nim i'm overlooking? something like ruby's eventmachine |
11:14:26 | Araq | asyncdispatch ? |
11:14:53 | niv | apparently :) thanks. |
11:14:58 | gour | nimqml looks interesting... |
11:15:52 | gunn | Araq: some benchmarking shows performance scales predictably, so I don't think what we |
11:16:01 | gunn | we've seen is a problem |
11:17:47 | gunn | BigInt performance could be improved though, nim consistently takes 70% longer than ruby with a simple script: (1..n).inject(:*) |
11:19:17 | gunn | also there seems to be a bug - have a look at the output here: https://gist.github.com/gunn/9269eaf7ff001485ce5e#file-parallel_factorial-log |
11:19:34 | gunn | 824199001261152424427520000 * 6059466975437025204783660349002445834010410572229490978416137871632000000000000 = 0 |
11:20:17 | gunn | unless I've missed something simple... |
11:22:05 | * | andrewvos joined #nim |
11:23:11 | andrewvos | why do I get this error? https://gist.github.com/AndrewVos/092acfb2e8e1826cebf4 |
11:23:52 | Araq | because it's a tuple, not an object |
11:24:32 | Araq | actions.add((topath, frompath)) |
11:25:17 | andrewvos | ohhhh |
11:25:26 | andrewvos | thanks |
11:25:33 | Araq | arguably the compiler/language could allow this form of construction for tuples, but named tuples are kinda bad style |
11:26:12 | andrewvos | but I need to name the tuple to have it in a seq right? |
11:26:30 | andrewvos | type mismatch: got (seq[SymlinkAction], (string, string)) |
11:26:40 | andrewvos | I still get that error with `actions.add((toPath, fromPath)) |
11:26:43 | andrewvos | ` |
11:27:17 | Araq | seq[(string, string)] |
11:27:25 | Araq | is a perfectly acceptable type |
11:27:41 | andrewvos | I see, so I should change the type of my seq |
11:35:14 | NimBot | nim-lang/Nim devel edb495a Araq [+0 ±1 -0]: fixes a critical error handling bug for nimsuggest |
11:35:14 | NimBot | nim-lang/Nim devel aad4ed7 Araq [+0 ±1 -0]: allows macros to access documentation comments |
11:35:14 | NimBot | nim-lang/Nim devel 698b1fc Araq [+0 ±2 -0]: fixes #3550 |
11:39:11 | * | dngad joined #nim |
11:39:42 | dngad | Hello everyone :) |
11:39:51 | * | Varriount-Laptop quit (Ping timeout: 255 seconds) |
11:45:51 | * | elrood joined #nim |
11:51:20 | federico3 | hi dngad |
11:52:23 | * | julian37 quit (Ping timeout: 252 seconds) |
11:53:42 | niv | whats the best way to split up a seq of length X*N into sub-seqs (tuples) of size N with X elements each? i've found distribute(), but that doesn't seem to be the best usecase for it. is there something like the ruby-eqv of Array#each_slice? |
11:57:51 | * | Varriount-Laptop joined #nim |
12:02:49 | niv | nvm :) |
12:05:10 | * | yglukhov quit (Ping timeout: 250 seconds) |
12:18:21 | * | julian37 joined #nim |
12:22:29 | * | strcmp1 joined #nim |
12:25:23 | * | theduke quit (Ping timeout: 252 seconds) |
12:39:22 | NimBot | nim-lang/Nim devel 528cf3e Araq [+0 ±1 -0]: better error handling for bug #3550 |
12:39:22 | NimBot | nim-lang/Nim devel 2f07ac7 Araq [+0 ±2 -0]: website updated |
12:41:54 | * | BitPuffin joined #nim |
12:47:11 | * | Varriount-Laptop quit (Ping timeout: 276 seconds) |
13:24:41 | * | Demon_Fox joined #nim |
13:25:25 | * | s4 quit () |
13:37:22 | * | ephja joined #nim |
13:40:31 | * | yglukhov joined #nim |
13:45:34 | * | yglukhov quit (Ping timeout: 272 seconds) |
13:48:14 | * | Sembei quit (Ping timeout: 260 seconds) |
13:51:56 | * | gokr1 quit (Quit: Leaving.) |
13:52:22 | * | yglukhov joined #nim |
14:08:36 | * | mindriot101 quit (Remote host closed the connection) |
14:11:54 | * | Varriount-Laptop joined #nim |
14:12:25 | Araq | hrm what's our policy for bugfixes which break code? |
14:12:46 | Araq | albeit for the bettter. what used to produce 0/1 now produces false/true |
14:12:58 | Araq | too dangerous for 0.12.2 right? |
14:13:36 | yglukhov | imo, lets break the code! :D |
14:14:29 | nchambers | Araq, the benefit of not having a v1.0 is this is the time to break code |
14:14:54 | nchambers | I mean, I don't think you've done it more than rust has, so you're probably entitled to it a bit |
14:15:11 | nchambers | the other solution is to go the python route or the c++ route |
14:15:18 | coffeepot | +1 for breaking if it makes more sense/more elegant |
14:15:24 | Araq | the benefit of having a 0.12.2 is that it is "everything works as 0.12 but sometimes better" |
14:15:43 | Araq | there is no doubt we can have the fix in 0.13 |
14:17:27 | Araq | so ... I shall releave 0.12.2 without the fix and then work continues to produce 0.13. IMHO that's how semantic versioning is supposed to work |
14:26:21 | * | Varriount-Laptop quit (Ping timeout: 255 seconds) |
14:31:24 | * | Jehan_ joined #nim |
14:34:07 | dom96 | Araq: According to http://semver.org/: "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable." |
14:34:19 | dom96 | i.e. you shouldn't care right now |
14:36:03 | dom96 | Devel already contains some changes which break backwards compat |
14:39:13 | * | julian37 quit (Ping timeout: 252 seconds) |
14:39:40 | Araq | yay -.- |
14:39:46 | Araq | ok, then |
14:40:13 | * | strcmp1 quit (Quit: return 0;) |
14:45:58 | dom96 | we can probably easily revert them if you really want |
14:48:43 | Araq | meh I guess bugfixes which break weird code are fine |
14:49:00 | Araq | I doubt it will affect any code out there |
14:49:09 | Araq | except our own tests of course |
14:50:59 | * | gokr joined #nim |
14:51:00 | * | gokr quit (Read error: Connection reset by peer) |
14:51:13 | * | gokr joined #nim |
14:52:55 | * | yglukhov_ joined #nim |
14:52:55 | * | yglukhov quit (Read error: Connection reset by peer) |
14:57:24 | * | yglukhov_ quit (Ping timeout: 255 seconds) |
15:04:11 | * | kniteli quit (Remote host closed the connection) |
15:08:28 | NimBot | nim-lang/Nim devel 1757b84 Araq [+0 ±1 -0]: fixes #3546 |
15:08:28 | NimBot | nim-lang/Nim devel ba6d0eb Araq [+0 ±4 -0]: fixes #3541 |
15:09:17 | * | mindriot101 joined #nim |
15:10:34 | * | gokr quit (Quit: Leaving.) |
15:11:58 | * | askatasuna joined #nim |
15:12:44 | * | mindriot101 quit (Remote host closed the connection) |
15:13:03 | * | mindriot101 joined #nim |
15:13:39 | * | strcmp1 joined #nim |
15:14:34 | strcmp1 | yeah i don't think semver really kicks in until 1.0 and after. and if you make a breaking change the next release must be v2.0, kind of annoying i guess |
15:16:19 | * | cryzed quit (Ping timeout: 240 seconds) |
15:16:39 | * | mal`` quit (Ping timeout: 240 seconds) |
15:16:44 | * | cryzed joined #nim |
15:17:19 | * | n1ftyn8_ quit (Ping timeout: 240 seconds) |
15:17:39 | * | Xe quit (Ping timeout: 240 seconds) |
15:18:28 | * | n1ftyn8_ joined #nim |
15:18:36 | * | dngad_ joined #nim |
15:19:38 | * | mal`` joined #nim |
15:20:08 | * | Xe joined #nim |
15:21:53 | * | dngad quit (Ping timeout: 276 seconds) |
15:26:46 | * | Guest48911isaway is now known as Guest48911 |
15:36:21 | * | enamex joined #nim |
15:54:46 | * | yglukhov joined #nim |
15:56:48 | * | pregressive joined #nim |
15:57:15 | * | Jesin quit (Quit: Leaving) |
15:59:10 | * | Jesin joined #nim |
16:03:32 | * | yglukhov quit (Remote host closed the connection) |
16:03:46 | * | yglukhov joined #nim |
16:03:53 | * | gokr joined #nim |
16:07:34 | * | askatasuna quit (Read error: Connection reset by peer) |
16:11:36 | * | kniteli joined #nim |
16:19:50 | * | strcmp1 quit (Ping timeout: 240 seconds) |
16:25:40 | * | strcmp1 joined #nim |
16:28:11 | * | ochkoffein joined #nim |
16:33:22 | * | strcmp2 joined #nim |
16:36:00 | * | strcmp1 quit (Ping timeout: 250 seconds) |
16:40:43 | * | desophos joined #nim |
16:52:09 | * | enamex quit (Ping timeout: 255 seconds) |
17:03:12 | * | enamex joined #nim |
17:06:22 | * | Demon_Fox quit (Quit: Leaving) |
17:07:09 | * | Demon_Fox joined #nim |
17:09:42 | * | andrewvos quit (Ping timeout: 260 seconds) |
17:15:47 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
17:20:38 | * | strcmp1 joined #nim |
17:20:55 | * | strcmp1 quit (Client Quit) |
17:22:26 | * | strcmp1 joined #nim |
17:24:38 | * | strcmp2 quit (Ping timeout: 260 seconds) |
17:28:40 | * | mindriot_ joined #nim |
17:31:45 | * | mindriot101 quit (Ping timeout: 255 seconds) |
17:33:02 | * | kniteli quit (Ping timeout: 260 seconds) |
17:33:10 | * | mindriot_ quit (Ping timeout: 260 seconds) |
17:36:33 | * | gokr quit (Quit: Leaving.) |
17:42:44 | * | brson joined #nim |
17:58:16 | * | cyraxjoe quit (Ping timeout: 272 seconds) |
18:03:53 | * | yglukhov quit (Remote host closed the connection) |
18:20:26 | * | mindriot101 joined #nim |
18:22:55 | * | Gonzih joined #nim |
18:25:21 | * | mindriot101 quit (Remote host closed the connection) |
18:30:07 | * | julian37 joined #nim |
18:36:05 | * | makoLine joined #nim |
18:44:27 | * | cyraxjoe joined #nim |
18:58:00 | * | mindriot101 joined #nim |
19:11:28 | * | yglukhov joined #nim |
19:13:03 | onionhammer | ok guys, someone needs to write a VS Code Nim extension |
19:13:13 | * | darkf quit (Quit: Leaving) |
19:13:18 | * | Gonzih quit (Ping timeout: 250 seconds) |
19:15:35 | * | yglukhov quit (Ping timeout: 240 seconds) |
19:17:50 | * | julian37 quit (Remote host closed the connection) |
19:18:05 | * | julian37 joined #nim |
19:25:06 | federico3 | VS Code? |
19:25:10 | onionhammer | visual studio code |
19:25:13 | onionhammer | just got open sourced |
19:25:51 | onionhammer | https://code.visualstudio.com/Updates |
19:27:21 | onionhammer | https://marketplace.visualstudio.com/#VSCode |
19:33:57 | * | exebook quit (Remote host closed the connection) |
19:39:22 | * | Matthias247 joined #nim |
19:43:38 | * | vendethiel joined #nim |
19:47:51 | * | BitPuffin quit (Ping timeout: 265 seconds) |
20:07:19 | * | vendethiel- joined #nim |
20:08:46 | * | vendethiel quit (Ping timeout: 240 seconds) |
20:11:26 | * | Sornaensis quit (Excess Flood) |
20:11:51 | * | Sornaensis joined #nim |
20:12:32 | * | str joined #nim |
20:16:11 | gmpreussner|work | onionhammer: i'm trying to understand what VS Code is |
20:16:19 | gmpreussner|work | is this some scaled down version of VS? |
20:16:29 | gmpreussner|work | i.e. just the text editor part? |
20:16:56 | * | Tahr-user quit (Quit: Leaving) |
20:20:10 | str | an atom "replacement" |
20:20:22 | str | BUT, has Go IDE support |
20:20:39 | str | iirc |
20:22:09 | gmpreussner|work | so this is meant for apps that run in a web browser, yes? |
20:22:38 | str | web/cloud apps |
20:22:46 | str | not specifically front-end |
20:26:25 | * | mat4 joined #nim |
20:26:27 | mat4 | hello |
20:26:38 | str | personally keeping sublime test around for a bit |
20:26:45 | str | *text even |
20:26:57 | dngad_ | Personally looking forward to IntelliJ support. |
20:29:58 | * | mindriot101 quit () |
20:31:21 | Matthias247 | it's an extensible text editor, just like vi, emacs, sublime text, atom, bracket, etc. |
20:32:16 | Matthias247 | but with the added debugger support for some languages it a little bit ahead of the competition in the IDE department |
20:32:26 | * | str quit (Quit: leaving) |
20:32:36 | * | dngad_ quit (Quit: Leaving) |
20:32:42 | desophos | yeah i would use it for languages it's intended to support |
20:32:49 | Matthias247 | and not, it's not only suitable for web apps. In our company a lot of people use it for C |
20:33:05 | desophos | you use VSC for C? |
20:33:06 | desophos | already? |
20:33:17 | desophos | wasn't it just released? |
20:33:21 | desophos | or just open sourced i guess |
20:33:36 | Matthias247 | it was open sourced today, it was released half a year ago |
20:33:46 | desophos | ah okay |
20:33:59 | desophos | i've been thinking about moving to Atom |
20:34:12 | desophos | it has a Nim plugin but so does Sublime, which i'm currently using |
20:34:23 | Matthias247 | I currently use them both, since I currently working on some typescript stuff |
20:34:27 | desophos | hm |
20:34:41 | Matthias247 | Atom has currently much more plugins, but is also a lot slower |
20:35:03 | desophos | does it have multiple selection? cmd-D is the best |
20:35:07 | Matthias247 | yes |
20:35:17 | desophos | good |
20:35:34 | Matthias247 | I think if it improves just a little bit I don't see any need for Atom anymore |
20:35:55 | desophos | wait you mean Atom is slower than VSC? |
20:35:58 | desophos | or than Sublime? |
20:36:02 | Matthias247 | than VSC |
20:36:05 | desophos | ah okay |
20:36:15 | Matthias247 | sublime is faster then both. But barely maintained |
20:36:17 | desophos | i'd try VSC if it had a Nim plugin :p |
20:36:30 | desophos | i assume it has a python plugin |
20:36:35 | Matthias247 | It would be possible since today |
20:36:45 | desophos | i pretty much only write python and nim now |
20:37:16 | desophos | and robot... sigh |
20:38:20 | desophos | the sublime robot plugin is terrible |
20:38:20 | Matthias247 | for VSC extensions you need javascript. I'm not the biggest fan of it, but with typescript it's a really good experience |
20:40:12 | mat4 | Matthias247: Do you mean lexical debugging, tracer or a binary debugger? |
20:40:34 | desophos | i assumed tracing |
20:41:09 | Matthias247 | mat4: not familiar with the terms, but it looks like how a debugger in an IDE looks ;) |
20:41:46 | Matthias247 | but I only used it for node.js until now. There you can simply start your app with debugger attached or attach later, set breakpoints, inspect variables, ... |
20:41:51 | * | yglukhov joined #nim |
20:42:15 | Matthias247 | and you can debug either js or with sourcemaps also typescript |
20:42:47 | Matthias247 | debugging is also supported for C#, but I haven't used it yet |
20:43:42 | Matthias247 | since today there is this: https://code.visualstudio.com/docs/extensionAPI/api-debugging |
20:44:05 | Matthias247 | that means you could add debugger support for other languages with plugins |
20:44:13 | Matthias247 | golang was already added |
20:45:12 | mat4 | nice interface abstraction! |
20:46:20 | * | Demon_Fox quit (Remote host closed the connection) |
20:48:42 | * | mat4 probably VLC runs with Wine |
20:49:08 | desophos | VLC is cross-platform... |
20:49:10 | desophos | so is VSC |
20:51:27 | mat4 | sorry, I mean Visual Studio (the IDE from Microsoft) |
20:55:19 | mat4 | for Nim development I use Joe at moment (because it is a Wordstar clone, is a console application and I have added syntax highlighting) |
20:56:41 | mat4 | also I like ease editing though regular expressions |
20:58:35 | Matthias247 | you can create VSC syntax highlighting packages out of textmate highlighting schemes (which is what sublime uses). So that means adding NIM highlighting support to VSC should be a matter of 20 minutes |
21:00:46 | * | kulelu88 joined #nim |
21:05:22 | * | enquora joined #nim |
21:09:42 | * | enquora quit (Client Quit) |
21:12:45 | dom96 | Atom is way too slow in my experience, VSC way too immature. |
21:13:07 | dom96 | The googleability of VSC is particularly annoying |
21:14:24 | mat4 | hmm, what's the URL for VSC by the way ? |
21:18:45 | Matthias247 | https://code.visualstudio.com/ |
21:21:41 | kulelu88 | if you're looking for an alternate, support lime text |
21:24:49 | mat4 | Matthias247: thanks |
21:25:33 | mat4 | kulelu88: what's special about lime text ? |
21:25:35 | nchambers | <mat4> for Nim development I use Joe at moment (because it is a Wordstar clone, is a console application and I have added syntax highlighting) ← heh... wordstar |
21:26:57 | kulelu88 | mat4: its the open-source version of sublime |
21:27:13 | mat4 | thanks, I take a look |
21:27:22 | kulelu88 | I don't advocate it for having advanced text-editor qualities |
21:27:44 | kulelu88 | but among all the noise, I'm glad an indie project like it exists |
21:41:43 | mat4 | it's written in Go as I see |
21:45:36 | kulelu88 | sadly yeah |
21:48:41 | * | strcmp1 quit (Ping timeout: 246 seconds) |
21:51:04 | * | pregressive quit (Remote host closed the connection) |
21:51:21 | * | pregressive joined #nim |
21:52:55 | * | andrewvos joined #nim |
22:01:22 | * | desophos_ joined #nim |
22:01:28 | * | desophos quit (Ping timeout: 272 seconds) |
22:04:56 | * | gour quit (Quit: WeeChat 1.3) |
22:07:31 | * | tinAndi joined #nim |
22:09:21 | * | desophos_ quit (Remote host closed the connection) |
22:15:43 | * | mat4 quit (Quit: leaving) |
22:22:55 | * | heinrich5991 quit (Quit: quit.) |
22:24:02 | * | vendethiel- quit (Ping timeout: 246 seconds) |
22:28:45 | * | Guest22572 quit (Ping timeout: 255 seconds) |
22:30:35 | * | desophos joined #nim |
22:31:32 | * | elrood quit (Quit: Leaving) |
22:37:27 | * | pregressive quit (Remote host closed the connection) |
22:37:44 | * | pregressive joined #nim |
22:39:27 | * | pregressive quit (Read error: Connection reset by peer) |
22:39:37 | * | pregressive joined #nim |
22:45:24 | * | strcmp1 joined #nim |
22:49:58 | * | strcmp1 quit (Ping timeout: 250 seconds) |
22:50:32 | * | BlueProtoman joined #nim |
22:52:40 | BlueProtoman | Anyone know if it's possible to use a built-in type to represent an external type? (In this case, a basic2d.Vector2d being treated as a Box2D b2Vec2) http://stackoverflow.com/q/33789764/1089957 |
22:56:37 | * | desophos quit (Remote host closed the connection) |
22:59:43 | * | desophos joined #nim |
23:02:17 | * | Trustable quit (Remote host closed the connection) |
23:04:43 | * | tinAndi quit (Quit: ChatZilla 0.9.92 [Firefox 42.0/20151029151421]) |
23:05:45 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:09:10 | * | desophos quit (Remote host closed the connection) |
23:17:16 | * | desophos joined #nim |
23:18:19 | * | buMPnet joined #nim |
23:20:32 | * | enamex quit (Quit: Leaving) |
23:21:10 | * | heinrich5991 joined #nim |
23:21:27 | * | heinrich5991 quit (Remote host closed the connection) |
23:25:24 | * | strcmp1 joined #nim |
23:27:18 | * | heinrich5991 joined #nim |
23:32:24 | * | Guest48911 is now known as Guest48911isaway |
23:34:10 | * | kulelu88 left #nim ("Leaving") |
23:38:05 | desophos | BlueProtoman: did you get an answer? |
23:38:12 | desophos | also hi |
23:46:03 | BlueProtoman | desophos: Hello. Yeah, Araq posted one, but at the same time I figured out that I can't do that with Vector2d <-> b2Vec2 because they're actually of different size (floats in Nim are 64-bit, floats in C++ are usually 32) |
23:46:28 | BlueProtoman | So I'll just have to make a private b2Vec2 wrapper and use it under the hood |
23:48:21 | desophos | porting box2d to nim? |
23:48:46 | BlueProtoman | Well, wrapping it, but yes. |
23:48:52 | desophos | awesome |
23:49:10 | BlueProtoman | Don't wanna do a full-fleged port because Erin Catto is a lot better at manual memory management optimizations than I am. |
23:49:32 | desophos | yeah no need to port a physics engine i think |
23:52:30 | * | nande joined #nim |