| 00:00:15 | * | gokr quit (Quit: Leaving.) |
| 00:00:26 | dom96_ | so like an outer `continue`? |
| 00:01:09 | renesac | kinda, but w/o leaving the current block |
| 00:02:45 | dom96_ | that seems like something way too specialised to be given its own special syntax |
| 00:04:40 | renesac | well, I don't know if I want a new syntax |
| 00:04:55 | renesac | I just want o call ".next" on a iterator |
| 00:05:24 | renesac | I will probably have to re-implement iterators myself for that |
| 00:05:32 | Varriount | renesac: Well, if it's a closure iterator, then you just call it again and discard the result. |
| 00:06:13 | renesac | yeah, maybe the closure iterator may do what I want |
| 00:10:26 | renesac | can I create closure iterators from normal iterators? |
| 00:10:40 | renesac | because it seems I basically need to copy and paste the code of a iterator |
| 00:11:16 | Araq | there was some logic in the compiler for that ... |
| 00:13:24 | renesac | and can I expect GCC to inline a locally used closure iterator? |
| 00:13:42 | Araq | ja klar ... XD |
| 00:13:53 | renesac | I don't speak german? |
| 00:14:04 | Araq | it means "no". |
| 00:14:13 | renesac | :( |
| 00:14:59 | renesac | then the performance would be horrible for something like that split proc |
| 00:18:37 | Araq | perhaps, perhaps not |
| 00:18:41 | Araq | good night |
| 00:18:52 | renesac | good night |
| 00:19:00 | dom96_ | maybe you could write a macro that does it |
| 00:19:06 | dom96_ | i'm heading to bed too |
| 00:19:08 | dom96_ | 'night |
| 00:19:13 | * | dom96_ quit (Quit: Page closed) |
| 00:29:37 | * | xet7_ joined #nim |
| 00:33:07 | * | xet7 quit (Ping timeout: 244 seconds) |
| 00:38:52 | * | Quikli joined #nim |
| 00:41:20 | * | Demon_Fox quit (Quit: Leaving) |
| 00:44:35 | * | Demos_ joined #nim |
| 00:47:35 | * | Demos quit (Ping timeout: 244 seconds) |
| 00:52:14 | Varriount | Araq: If we want complete Windows API wrapper, Nim is going to need a way of handling bit fields |
| 00:55:19 | * | BitPuffin|osx joined #nim |
| 00:58:54 | * | elbow_jason joined #nim |
| 01:03:17 | * | elbow_jason quit (Remote host closed the connection) |
| 01:06:17 | * | Demos_ quit (Read error: Connection reset by peer) |
| 01:18:49 | renesac | this can be done via a macro |
| 01:27:55 | * | brson joined #nim |
| 01:32:11 | * | Demos joined #nim |
| 01:33:49 | Varriount | renesac: You have any experience with importing C procedures via header, instead of via DLL? |
| 01:34:56 | renesac | I didn't saw much difference for what I wanted, and DLL is the recommended way, so no |
| 01:38:05 | Varriount | I'm just wondering if importing via header would 'validate' my wrapper (for example, if I wrapped a parameter type wrong, the C compiler would complain) |
| 01:41:14 | Demos | I don't think it's worth it |
| 01:41:26 | Demos | it'll increase the compile time of your c |
| 01:47:24 | * | strcmp1 quit (Quit: Leaving) |
| 02:06:51 | * | saml_ joined #nim |
| 02:34:32 | * | brson quit (Quit: leaving) |
| 02:51:52 | onionhammer | Varriount whats up |
| 02:55:07 | * | def- quit (Ping timeout: 246 seconds) |
| 03:02:27 | * | darkf joined #nim |
| 03:10:01 | * | elbow joined #nim |
| 03:10:26 | * | Quikli quit (Quit: Page closed) |
| 03:17:28 | * | ChrisMAN quit (Ping timeout: 272 seconds) |
| 03:45:04 | * | saml_ quit (Ping timeout: 246 seconds) |
| 03:57:37 | * | Demos quit (Remote host closed the connection) |
| 03:58:50 | Varriount | onionhammer: Trying to generate a decent Windows API wrapper without going through millions of lines of code. |
| 04:01:09 | * | Demos joined #nim |
| 04:02:06 | * | def- joined #nim |
| 04:09:49 | onionhammer | joy |
| 04:17:16 | * | def- quit (Quit: -) |
| 04:18:06 | * | def- joined #nim |
| 04:26:35 | * | Demos quit (Remote host closed the connection) |
| 04:29:03 | * | Demos joined #nim |
| 04:31:41 | * | Demos quit (Remote host closed the connection) |
| 04:38:01 | * | Demos joined #nim |
| 04:42:58 | * | Demos quit (Remote host closed the connection) |
| 04:45:34 | * | Demos joined #nim |
| 04:47:57 | * | Demos quit (Remote host closed the connection) |
| 04:49:25 | * | Demos joined #nim |
| 05:12:42 | * | BitPuffin|osx quit (Ping timeout: 260 seconds) |
| 05:14:08 | * | FedeOmoto quit (Quit: Leaving) |
| 05:14:53 | * | Demos quit (Remote host closed the connection) |
| 05:33:44 | * | Kingsquee joined #nim |
| 05:48:42 | * | jszymanski joined #nim |
| 05:49:28 | * | yglukhov joined #nim |
| 05:52:11 | * | elbow quit (Remote host closed the connection) |
| 05:53:37 | * | yglukhov quit (Ping timeout: 246 seconds) |
| 05:58:06 | * | vegai joined #nim |
| 05:59:16 | * | vegai left #nim (#nim) |
| 06:11:28 | * | kas joined #nim |
| 06:30:08 | * | skyfex quit (Ping timeout: 244 seconds) |
| 06:33:51 | * | kas quit (Remote host closed the connection) |
| 06:36:48 | * | vendethiel joined #nim |
| 06:59:54 | * | xet7_ quit (Ping timeout: 265 seconds) |
| 07:00:14 | * | xet7_ joined #nim |
| 07:03:42 | * | Kingsquee quit (Read error: Connection reset by peer) |
| 07:03:58 | * | Kingsquee joined #nim |
| 07:28:22 | * | yglukhov joined #nim |
| 07:32:48 | * | yglukhov quit (Ping timeout: 264 seconds) |
| 07:37:22 | baabelfish | how will finalizers/destructors work for references in 1.0? |
| 07:37:25 | * | xet7_ quit (Ping timeout: 256 seconds) |
| 07:38:28 | baabelfish | will it be called immediately when the refcount goes to 0 or when it's being collected? |
| 07:38:56 | baabelfish | I'm too used to smart pointers... |
| 07:52:35 | * | yglukhov joined #nim |
| 07:52:36 | * | yglukhov quit (Remote host closed the connection) |
| 07:53:08 | * | yglukhov joined #nim |
| 07:58:34 | * | dalarmmst quit (Ping timeout: 246 seconds) |
| 07:58:46 | * | coffeepot joined #nim |
| 07:59:05 | * | dalarmmst joined #nim |
| 08:09:51 | * | yglukhov quit (Remote host closed the connection) |
| 08:28:00 | * | gokr joined #nim |
| 08:34:46 | * | Trustable joined #nim |
| 08:54:12 | * | yglukhov joined #nim |
| 08:56:41 | * | Ven joined #nim |
| 09:08:15 | * | zezba9000 joined #nim |
| 09:10:27 | * | yglukhov quit (Remote host closed the connection) |
| 09:13:48 | * | yglukhov joined #nim |
| 09:18:34 | * | Ven quit (Ping timeout: 244 seconds) |
| 09:23:12 | * | xet7_ joined #nim |
| 09:30:04 | * | xcombelle joined #nim |
| 09:32:03 | * | yglukhov quit (Remote host closed the connection) |
| 09:34:21 | * | Ven joined #nim |
| 09:36:12 | Araq | baabelfish: destructors are immediately called at scope exit, finalizers when the gc cleans up |
| 09:36:19 | Araq | just as the names suggest |
| 09:37:50 | baabelfish | Araq: I only got destructors working with objects, not with refs |
| 09:38:18 | Araq | ever got a destructor work with T* in C++? |
| 09:38:51 | baabelfish | Araq: heh, but I was thinking if they worked like unique/shared pointers |
| 09:42:58 | * | yglukhov joined #nim |
| 09:43:13 | * | yglukhov quit (Remote host closed the connection) |
| 09:43:29 | * | yglukhov joined #nim |
| 09:48:37 | * | yglukhov quit (Remote host closed the connection) |
| 09:59:14 | * | yglukhov joined #nim |
| 10:02:14 | * | Ven_ joined #nim |
| 10:04:25 | * | Ven quit (Ping timeout: 240 seconds) |
| 10:23:45 | * | Ven_ quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 10:29:09 | * | zezba9000 left #nim (#nim) |
| 10:52:04 | * | Raimondi quit (Ping timeout: 246 seconds) |
| 11:08:13 | * | vendethiel quit (Quit: q+) |
| 11:24:39 | * | polde quit (Ping timeout: 256 seconds) |
| 11:24:56 | * | Ven joined #nim |
| 11:32:51 | * | polde joined #nim |
| 11:40:42 | * | polde quit (Ping timeout: 258 seconds) |
| 11:49:15 | * | drewsrem joined #nim |
| 11:49:34 | drewsrem | Is there a possibility we'll get object variants that can have the same field-name for different object kinds? |
| 11:50:33 | baabelfish | importing terminal gives me: unsigned.cpp:(.text+0x77): undefined reference to `stackoverflow_19801()' |
| 11:54:05 | def- | drewsrem: in a restricted manner with "of Foo, Bar: x: int" |
| 11:54:25 | def- | baabelfish: tried cleaning nimcache? |
| 11:55:04 | baabelfish | def-: that did the trick |
| 11:55:21 | def- | baabelfish: still a bug though, not sure if it's been reported already |
| 11:55:56 | drewsrem | def-, is there some impossibility to implement the wider case I'm describing? |
| 11:59:27 | def- | drewsrem: offsets and data types can be different and the kind discriminator would have to be checked to access the field. also the type couldn't be known at compile time |
| 12:00:04 | * | xet7_ quit (Ping timeout: 246 seconds) |
| 12:00:09 | drewsrem | hmmmm... I see |
| 12:03:20 | coffeepot | Is anyone on latest devel to check if this still generates codegen issue? https://gist.github.com/coffeepots/2174e0167539f39a4bba |
| 12:04:21 | def- | coffeepot: have to be on windows for that? |
| 12:04:24 | Araq | coffeepot: it should generate a compiler error instead. an array is not a pointer. |
| 12:04:54 | coffeepot | yeah i know i dun fucked up but i thought i'd mention it as should never be codegen issue :) |
| 12:05:13 | coffeepot | def- yes good point |
| 12:06:14 | coffeepot | think i meant to type this echo "ws bytes ", repr(cast[ptr array[0..255, byte]](ws)) |
| 12:06:16 | Araq | def-: actually you can use --os:windows and look at the generated C :P |
| 12:07:11 | def- | coffeepot: then it fails the C compilation: nimcache/x.c:309:118: error: lvalue required as unary ‘&’ operand |
| 12:08:49 | * | xcombelle quit (Remote host closed the connection) |
| 12:13:02 | coffeepot | yeah i guess it's this &(&ws_92003[(((NI) 0))- 0]) |
| 12:14:31 | coffeepot | ref of ref? No idea, been a while since I done any C |
| 12:32:43 | * | Kingsquee is now known as KingslavyTOS |
| 12:32:54 | * | KingslavyTOS is now known as Kingsquee |
| 12:34:16 | * | xet7_ joined #nim |
| 12:48:02 | federico3 | can you guys see an use case where people might want to use nimble as a library? |
| 12:48:38 | Araq | federico3: actually the compiler should use nimble as a library to resolve import statements |
| 12:48:56 | Araq | dom96 disagrees for reasons that escape me |
| 12:49:19 | Araq | he told me to read his upcoming book to be enlightened :P |
| 12:49:21 | federico3 | hm, I expected the compiler to be self sufficient |
| 12:49:32 | federico3 | a book on Nim? |
| 12:49:37 | Araq | yeah |
| 12:49:57 | federico3 | I want it on yesterday. Take my money! |
| 12:51:22 | Araq | actually we're both working on books about Nim but my is becoming a pamphlet about how Unix should have been Lisp instead |
| 12:51:31 | Araq | (nah, just kidding) |
| 12:52:00 | Araq | (but seriously ... Lisp should have killed Unix ...) |
| 12:55:27 | * | federico3 files the book under Humour |
| 13:06:08 | * | polde joined #nim |
| 13:16:46 | * | Raimondi joined #nim |
| 13:34:36 | * | Raimondi quit (Read error: Connection reset by peer) |
| 13:36:37 | * | FedeOmoto joined #nim |
| 13:39:18 | * | Raimondi joined #nim |
| 13:40:36 | * | Ven quit (Ping timeout: 264 seconds) |
| 13:41:41 | r-ku | Error: pragmas are only allowed in the header of a proc |
| 13:41:54 | r-ku | is there any usual mistake that leads to this totally unhelpful error? |
| 13:43:39 | Araq | r-ku: you have a forward declaration and the compiler cannot bother to sync 2 pragma lists |
| 13:43:51 | Araq | *cannot be bothered |
| 13:44:02 | Araq | so instead it complains |
| 13:44:24 | r-ku | okay i could be doing something like this. also error could be more clear.. |
| 13:46:49 | Araq | fix it |
| 13:48:14 | Araq | every error message should have a little star that I can click onto to get a web page describing possible solutions ... oh wait ... there is no ansi escape sequence for "link here" |
| 13:49:23 | * | Raimondi quit (Read error: Connection reset by peer) |
| 13:49:44 | Araq | so sorry ... have to wait for 3 decades until the last unix beard figured out a technology from the 70ies might not be a suitable solution for good |
| 13:50:51 | * | xet7_ quit (Read error: Connection reset by peer) |
| 13:50:58 | * | xet7_ joined #nim |
| 13:53:49 | r-ku | Araq so what should i do here? found forward declaration that causes error. but for example removing pragmas at all doesnt make issue go away |
| 13:53:58 | r-ku | not sure what happens here and why it doesnt work |
| 13:54:41 | Araq | the forward decl gets all the pragmas, the real decl none |
| 13:57:20 | r-ku | weird, thats how i had it to begin with |
| 14:03:20 | * | Demos joined #nim |
| 14:05:34 | * | Raimondi joined #nim |
| 14:09:02 | * | Demon_Fox joined #nim |
| 14:11:28 | r-ku | calling create(Coroutine) i got Error: type mismatch: got (typedesc[Coroutine]) |
| 14:11:32 | r-ku | new regression? |
| 14:22:22 | * | Demos quit (Remote host closed the connection) |
| 14:24:52 | Araq | r-ku: well ... this should have never worked in the first place |
| 14:25:03 | Araq | what does your create look like? |
| 14:25:10 | * | Demos joined #nim |
| 14:28:28 | r-ku | var x = create(Coroutine) |
| 14:29:03 | Araq | proc create( ? ) |
| 14:30:42 | * | darkf quit (Quit: Leaving) |
| 14:34:28 | * | Raimondi quit (Read error: Connection reset by peer) |
| 14:34:36 | r-ku | Araq what i pasted is exactly code i had. it supposed to do sizeof of Coroutine struct and allocate it |
| 14:35:03 | r-ku | sizeof should work on typedesc.. |
| 14:35:19 | r-ku | (Coroutine is a type, sorry should have mentioned before) |
| 14:35:42 | Araq | how does the signature / prototype / header of your create look like? |
| 14:36:06 | Araq | cause typedesc inference for generic T is now verboten, for good reasons |
| 14:36:24 | Araq | that's a breaking change, but not a regression |
| 14:36:41 | Araq | proc cmp[T](a, b: T): int = discard |
| 14:36:50 | Araq | cmp(int, int) # wtf? |
| 14:37:11 | Araq | # T should still be a proper value at least |
| 14:37:56 | * | Demos quit (Remote host closed the connection) |
| 14:39:36 | * | Raimondi joined #nim |
| 14:49:08 | * | boopisaway is now known as boop |
| 14:56:07 | * | Demos joined #nim |
| 14:58:09 | coffeepot | just reading above about the forward decl error and compiler explainations, if there is one error i would like to see an extra message on (I have no idea if this would be easy to do or not) it's type mismatch on proc signatures for var items. When, for example, you loop over items and modify them, or try to modify a non var param it would be amazin |
| 14:58:09 | coffeepot | g if it could tell that the only diff is var and display "Did you mean to pass <param> as var?" |
| 14:59:19 | coffeepot | The thing is atm it doesn't always say that the difference is var, so it'll say "got proc(a: int, b: string) but expected proc(a: int, b: string)" and in some cases not mention the var, can get very confusing |
| 15:00:30 | coffeepot | I've learnt now when it complains the sigs are the same to check var params or seq.mitems, but when the param lists are long it's not obvious what the issue is |
| 15:00:48 | coffeepot | i do love *that* it complains though :) |
| 15:02:09 | r-ku | Araq that was not my create, that was system.create() |
| 15:02:44 | r-ku | and it calls system.sizeof() |
| 15:03:46 | r-ku | anyway i did it better way |
| 15:03:55 | r-ku | also PR you wanted https://github.com/nim-lang/Nim/pull/3160 |
| 15:05:51 | Araq | r-ku: aha, ok, we need to fix system.create |
| 15:06:21 | r-ku | not sure why you also deleted system.free |
| 15:06:42 | Araq | news.txt explains it |
| 15:06:51 | r-ku | kk will read |
| 15:07:19 | r-ku | err where is that? |
| 15:07:46 | r-ku | nvm found |
| 15:09:33 | coffeepot | r-ku you mention you would like feedback on coro names - coroStart, would this be better as coroAdd if it's not starting the coroutine? |
| 15:10:02 | Araq | coffeepot: actually this problem got worse with the "overloading by var-T" feature, the error message used to be better |
| 15:10:13 | r-ku | coffeepot probably so yes |
| 15:10:30 | r-ku | not even sure if prefixing all of them with "coro" was good idea |
| 15:10:38 | r-ku | but well.. good enough for early testing i guess |
| 15:11:19 | Araq | bbl |
| 15:13:29 | coffeepot | r-ku looking forward to your coroutines stuff :) btw can you add coro's in after start has been called? |
| 15:14:40 | r-ku | sure, from within other coroutines too |
| 15:14:50 | coffeepot | :) nice |
| 15:16:04 | coffeepot | how does your coroutines stuff relate to async btw? Isn't async single threaded? Are the coro's single threaded or do they spawn separate threads according to load? Is this something that would be useful for something like jester do you think over async? |
| 15:17:00 | r-ku | point of coroutines is to be single-threaded so you get multithreading-like abilities without complexities of multithreading |
| 15:17:37 | r-ku | should someone want several threads to run coroutines they would have to do it on their own. coroRun() per thread, and coroutines would run on thread they were started on |
| 15:18:08 | r-ku | passing data between such coroutines would be same as passing data between different threads now in nim |
| 15:18:35 | coffeepot | cool, sounds good tbh, so no locking when passing data between coros? |
| 15:19:19 | coffeepot | i suppose you wouldn't need to if they're running on same thread |
| 15:19:19 | r-ku | if they are on same thread then yes |
| 15:20:01 | coffeepot | so what's the main difference between this and async? Or is this a replacement for async? |
| 15:20:30 | r-ku | async is made on top of iterators and you cant yield from within a subcall in iterator |
| 15:20:39 | r-ku | here you can go as many levels deep as you want and still yield |
| 15:20:50 | coffeepot | that sounds really awesome :) |
| 15:21:25 | r-ku | if basic api tapped more into OS we could do awesome things with this |
| 15:21:36 | r-ku | for example windows at least has non-blocking file reading |
| 15:22:02 | r-ku | so if there was means to check if such read call returned we could have read calls that do not block but let other coroutines execute |
| 15:22:19 | r-ku | while coroutine that called read() is actually waiting for os to return data |
| 15:22:50 | * | pregressive joined #nim |
| 15:22:51 | coffeepot | sweet |
| 15:23:11 | coffeepot | if you have time you should definitely mention that in your docu |
| 15:23:30 | coffeepot | pretty big deal really :) |
| 15:24:09 | coffeepot | right i'll let ya get on, thanks for the info :D |
| 15:24:55 | r-ku | pretty sure its obvious for those who would be implementing that kind of functionality ;) |
| 15:26:16 | coffeepot | yeah i don't really know much about coroutines other than their existance, so it's nice to hear the intricacies to know what i might use them for |
| 15:29:56 | coffeepot | btw i meant coroutines being a big deal, very useful functionality |
| 15:33:35 | r-ku | glad people like it. nim got them by accident tbh |
| 15:33:49 | coffeepot | how so? |
| 15:33:59 | r-ku | i only planned on hack for my own needs but.. well Araq knows how to exploit people hehe |
| 15:34:12 | coffeepot | hehe for the greater good lol |
| 15:34:20 | r-ku | totally :) |
| 15:34:38 | coffeepot | same with my edit to times.nim, I wrote some funcs for my own use then suddenly PR... |
| 15:34:53 | coffeepot | can't complain though |
| 15:35:14 | coffeepot | shame this odbc stuff is dragging on, hopefully once that's done people will find it useful |
| 15:35:40 | coffeepot | certainly better than odbc in C/C++ o_O |
| 15:36:20 | * | ChrisMAN joined #nim |
| 15:37:16 | r-ku | i dragged coroutines too |
| 15:37:25 | r-ku | esp now that i no longer need them heh |
| 15:47:15 | * | xet7_ quit (Read error: Connection reset by peer) |
| 15:47:32 | * | xet7_ joined #nim |
| 15:54:24 | * | yglukhov_ joined #nim |
| 15:57:38 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 15:57:59 | federico3 | anybody into DHTs? |
| 15:58:30 | * | yglukhov_ quit (Ping timeout: 250 seconds) |
| 16:01:21 | Demos | Distributed hash tables? |
| 16:01:26 | federico3 | yep |
| 16:01:46 | Demos | I mean I've worked with them, I don't really like dealing with their implementations though |
| 16:05:09 | federico3 | implementations in general? |
| 16:07:06 | Demos | um, we had to implement something like chord in class |
| 16:17:20 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 16:19:22 | * | Demos quit (Remote host closed the connection) |
| 16:21:38 | Demon_Fox | I've been researching DHT's this whole summer |
| 16:21:52 | Demon_Fox | darn. |
| 16:22:00 | Demon_Fox | The one question I could have helped with. |
| 16:23:37 | federico3 | I'm still here |
| 16:24:22 | Demon_Fox | I mixed you up with demos |
| 16:24:23 | federico3 | I've noticed there isn't any basic DHT library implemented in Nim |
| 16:24:35 | Demon_Fox | Nim is still rather new. |
| 16:24:45 | federico3 | yep |
| 16:25:07 | Demon_Fox | This summer, my project was to make an application that used a DHT of its own |
| 16:25:27 | federico3 | a custom protocol? |
| 16:25:44 | Demon_Fox | Not really custom |
| 16:25:55 | Demon_Fox | Well, I suppose so |
| 16:26:16 | Demon_Fox | The only problem is the lack of documented cryptographic libraries in C. |
| 16:26:52 | Demon_Fox | Trying to make a wrapper for my use cases has turned into my project |
| 16:27:03 | Demon_Fox | After I'm doing, I'm switching over to python. |
| 16:27:24 | federico3 | were you using C? |
| 16:27:33 | Demon_Fox | Unfortunately. |
| 16:27:56 | Demon_Fox | After I'm done, I need to write a python wrapper for it |
| 16:28:15 | Demon_Fox | Or use someone elses wrapper. |
| 16:28:23 | Demon_Fox | I'm quite fond of that idea. |
| 16:28:46 | Demon_Fox | Just abandoning my C code, because no one knows how to write proper documentation. |
| 16:30:23 | Demon_Fox | federico3, Are you considering nim for a serious DHT application? |
| 16:31:47 | federico3 | nope, just play |
| 16:33:53 | Demon_Fox | Well... |
| 16:34:24 | Demon_Fox | What exactly do you want to do with it federico3 |
| 16:34:50 | Demon_Fox | If you want to use it over the internet, you might want to consider a different programming language |
| 16:35:04 | federico3 | why? |
| 16:35:24 | Demon_Fox | because you would want the use of several libraries in order to increase your connectivity behind firewalls |
| 16:35:44 | Demon_Fox | ISPs, your router, your computer, and etc. |
| 16:36:12 | federico3 | upnp, regular natting, hole punching, anything else? |
| 16:36:40 | Demon_Fox | Several other reasons. |
| 16:36:44 | federico3 | do dhts do hole punching nowadays? |
| 16:37:06 | Demon_Fox | Have you used a modern torrent client? |
| 16:37:42 | federico3 | deluge? |
| 16:37:48 | federico3 | depending on the definition of modern :D |
| 16:38:10 | * | Demos joined #nim |
| 16:38:20 | Demon_Fox | Have you ever heard of an application called tribler? |
| 16:38:38 | Demon_Fox | They talk about many techniques in their papers and links on solving the connectivity problem. |
| 16:39:18 | Demon_Fox | In one of the good ones, they talk about how as a p2p application, you need to take every advantage you can. |
| 16:40:16 | * | k1i joined #nim |
| 16:42:01 | * | brson joined #nim |
| 16:42:21 | federico3 | wasn't tribler ancient? |
| 16:42:40 | Demon_Fox | It is still around |
| 16:43:17 | Demon_Fox | It really feels more a like a research project, if you ask me. |
| 16:45:54 | Demon_Fox | When I was reading up on the docs, I really felt they wanted to make the project appealing to increase how big their real world tests could be. |
| 16:46:50 | Demon_Fox | Just given how they worded several things, that is what I thought. |
| 16:49:16 | * | xcombelle joined #nim |
| 16:51:43 | Demon_Fox | federico3, Do you already know the common hash techniques to avoid potential address collision on the DHT? |
| 16:54:36 | * | yglukhov joined #nim |
| 16:59:32 | * | yglukhov quit (Ping timeout: 272 seconds) |
| 17:00:48 | * | Demos quit (Remote host closed the connection) |
| 17:01:07 | * | Demos joined #nim |
| 17:05:48 | * | xet7_ quit (Ping timeout: 264 seconds) |
| 17:05:57 | * | xet7_ joined #nim |
| 17:15:10 | * | yglukhov joined #nim |
| 17:19:16 | * | yglukhov quit (Ping timeout: 246 seconds) |
| 17:22:37 | * | elbow joined #nim |
| 17:25:25 | flyx | on the current devel branch, I get a segfault when compiling my code: https://gist.github.com/flyx/d44638440e2c1312e9f2 |
| 17:25:48 | flyx | I can't really figure out which part of my code causes that error, because as soon as I start to insert echo statements, the error goes away |
| 17:26:37 | flyx | only thing I know, it occurs while processing some macro |
| 17:26:38 | Araq | flyx: well you can always patch vmgen.fitsRegister to deal with 'nil' |
| 17:27:06 | Araq | and make it output an error containing the line number |
| 17:27:23 | Araq | well I can do that for you of course |
| 17:27:59 | flyx | I guess I can do it myself. will try |
| 17:28:00 | Araq | but after that I really like a testcase to protect against this regression |
| 17:30:12 | * | xet7_ is now known as xet7 |
| 17:31:04 | * | brson quit (Ping timeout: 246 seconds) |
| 17:32:59 | * | brson joined #nim |
| 17:40:52 | flyx | seems like it crashes at lib/pure/terminal.nim(423,2) |
| 17:40:57 | * | flyx investigates further |
| 17:41:29 | flyx | well that would kind of explain why it goes away when I insert echo lines |
| 17:44:56 | Araq | actually the 'echo' statements usually influence the VM's register allocator and it has nothing to do with terminal.nim that echos make the bug disappear |
| 17:59:43 | * | saml quit (Remote host closed the connection) |
| 18:04:49 | * | saml joined #nim |
| 18:14:54 | flyx | hm okay. I tracked it back to some string literal "content", but I can't find it in my code, and the line info gives "command line(0,0)" |
| 18:22:00 | flyx | okay, it's a constant, apparently with the value "content", and a typ of nil |
| 18:38:21 | Araq | flyx: did you just try devel or do you follow the development of devel? |
| 18:39:07 | flyx | Araq: I just checked out devel and used it. |
| 18:39:32 | flyx | I have now figured out that the error originates on a nil literal in my code |
| 18:41:03 | flyx | I think I don't have enough knowledge to figure out *why* this error occurs |
| 18:41:40 | * | Demos_ joined #nim |
| 18:42:59 | flyx | or how to fix it. if I modify fitsRegister to check for t == nil, the vm just fails later |
| 18:45:10 | flyx | it seems that c.constants.sons[rb].typ just shouldn't be nil, but it is |
| 18:46:01 | Demos_ | :\users\charlie\source\nimrod\nimcache\stdlib_times.c(985): error C2065: 'tzname': undeclared identifier |
| 18:48:20 | Araq | Demo_ I wonder why nobody has fixed that tzname bullshit yet |
| 18:48:36 | Demos_ | how long has it been broke |
| 18:48:44 | Demos_ | I tried all the way back to 0.11.2 |
| 18:48:46 | Araq | flyx: well I need some test program to fix it |
| 18:49:13 | Araq | Demo_ well people here usually think they can just hack anything that "works" in C and it's then "portable" |
| 18:49:33 | Araq | I usually don't use anything from C land if I can avoid it |
| 18:49:38 | Demos_ | I'm compileing using the binary from the 0.11.2 installer package using MSVC 19.00.23026 |
| 18:50:03 | * | elbow quit (Quit: Leaving) |
| 18:50:13 | flyx | Araq: I guess I'm unable to reduce my code to a minimal example, but you can of course check out my source from github, if that's feasible |
| 18:50:37 | Araq | sure, I didn't know it's open source |
| 18:54:59 | flyx | Araq: https://github.com/flyx/emerald branch v2, compile test/inheritance.nim, that should trigger the error. |
| 18:55:36 | * | elbow_jason joined #nim |
| 18:56:45 | Demos_ | libraries in lib/pure should not be using {.header: ..., importc.} right/ |
| 18:57:23 | flyx | um, branch is v0.2, not v2 |
| 19:11:56 | Demos_ | Araq, I fixed the build failure, apperently windows does not expose tzname any more in <times.h> which is pretty strange |
| 19:12:10 | Araq | I get "cannot convert 2147483648 to int" |
| 19:12:42 | Araq | but with --cpu:amd64 I get your crash |
| 19:15:06 | flyx | ah, there may be some issues with the 32bit build, I haven't started to test that yet |
| 19:18:37 | * | Jesin quit (Quit: Leaving) |
| 19:19:39 | Araq | oh ffs, does everybody use unittest.nim? |
| 19:20:23 | flyx | I didn't find anything else to use |
| 19:20:41 | * | Jesin joined #nim |
| 19:20:47 | Araq | when isMainModule: doAssert foo == bar |
| 19:21:11 | renesac | unittest is nicer and should work... |
| 19:21:17 | Demos_ | but people want pretty colors |
| 19:21:22 | Demos_ | :^) |
| 19:21:47 | Araq | I want a HTML based shell. but *shrug* it's widely known that I'm a crank |
| 19:22:22 | * | vendethiel joined #nim |
| 19:22:49 | * | gokr quit (Quit: Leaving.) |
| 19:29:15 | * | gokr joined #nim |
| 19:30:32 | * | pregressive quit (Remote host closed the connection) |
| 19:33:17 | * | yglukhov joined #nim |
| 19:50:04 | * | RobCWD joined #nim |
| 19:50:27 | * | RobCWD left #nim (#nim) |
| 19:54:41 | Araq | flyx: congrats on finding an interesting bug ;-) |
| 19:54:53 | flyx | thanks ^^ |
| 19:59:43 | Araq | hrm case statements just dump whole ASTs into the "const" section in the VM |
| 20:00:31 | * | Demos_ quit (Read error: Connection reset by peer) |
| 20:00:39 | * | Demos quit (Remote host closed the connection) |
| 20:01:03 | Araq | that's crazy |
| 20:06:00 | * | jszymanski quit (Quit: computer sleeps...) |
| 20:10:45 | * | Raimondii joined #nim |
| 20:12:04 | * | Raimondi quit (Ping timeout: 246 seconds) |
| 20:12:57 | Araq | flyx: are you sure this has ever worked? |
| 20:14:06 | * | Raimondi joined #nim |
| 20:14:19 | flyx | Araq: never on stable, but on an earlier version of devel, it worked |
| 20:15:33 | * | Raimondii quit (Ping timeout: 255 seconds) |
| 20:16:59 | * | yglukhov quit (Read error: Connection reset by peer) |
| 20:20:18 | * | yglukhov joined #nim |
| 20:20:57 | * | zahary1 joined #nim |
| 20:22:50 | * | zahary quit (Ping timeout: 250 seconds) |
| 20:31:28 | * | pregressive joined #nim |
| 20:31:57 | * | flyx is away now |
| 20:47:57 | * | xificurC quit (Read error: Connection reset by peer) |
| 20:48:35 | * | elbow joined #nim |
| 20:53:52 | * | yglukhov quit (Remote host closed the connection) |
| 20:54:10 | * | hannes__ joined #nim |
| 20:55:20 | * | Raimondi quit (Ping timeout: 250 seconds) |
| 20:56:05 | hannes__ | thanks |
| 21:00:05 | Araq | hi hannes__ |
| 21:01:32 | * | Demos joined #nim |
| 21:03:53 | * | xcombelle quit (Quit: Leaving) |
| 21:05:58 | * | Demos quit (Ping timeout: 246 seconds) |
| 21:07:54 | hannes__ | Araq: hi - I actually was going to ask a question, but by asking I actually realized what the problem was. Hence, thanks |
| 21:08:04 | * | BitPuffin|osx joined #nim |
| 21:10:03 | Araq | flyx: your code makes my poor vm cry |
| 21:10:32 | Araq | generates thousands of instructions |
| 21:12:12 | * | Raimondi joined #nim |
| 21:19:58 | * | zahary1 quit (Ping timeout: 246 seconds) |
| 21:23:06 | * | Trustable quit (Remote host closed the connection) |
| 21:24:27 | * | FedeOmoto quit (Quit: Leaving) |
| 21:26:38 | * | Raimondi quit (Ping timeout: 260 seconds) |
| 21:28:32 | * | xificurC joined #nim |
| 21:29:41 | * | gokr quit (Quit: Leaving.) |
| 21:32:20 | * | Raimondi joined #nim |
| 21:32:41 | * | saml quit (Quit: Leaving) |
| 21:33:08 | * | pregressive quit (Remote host closed the connection) |
| 21:34:09 | * | pregressive joined #nim |
| 21:35:45 | * | pregressive quit (Remote host closed the connection) |
| 21:39:16 | * | filwit joined #nim |
| 21:41:49 | filwit | hmm.. the sizeof {.pure inheritable.} types is '1'.. pretty sure that's a bug.. |
| 21:43:32 | Araq | no, it is not |
| 21:44:11 | filwit | really? why? the object even has a 'bool' property in it and if I remove the {.pure.} ist's '16' |
| 21:44:27 | filwit | sizeof 16 i mean |
| 21:45:48 | filwit | maybe i'm not thinking about this right... duh.. |
| 21:45:49 | hannes__ | Where would be the best place to go to ask beginner level idiom/code review questions? The nim forums? reddit? |
| 21:46:33 | filwit | for some reason I was thinking 16 was way too high a number for refc/typeinfo but obviously it's not i'm just being thick.. |
| 21:46:37 | filwit | sorry |
| 21:46:41 | Araq | hannes__: forum or here i guess |
| 21:47:00 | * | gokr joined #nim |
| 21:47:00 | filwit | sorry |
| 21:47:07 | filwit | whoops.. damn alt-tab |
| 21:48:31 | Araq | pretty sure flyx's code never worke or he got extremely lucky |
| 21:52:30 | * | brson quit (Remote host closed the connection) |
| 21:53:24 | hannes__ | So, I've been trying to write quicksort in Nim. It works, but only for sequences and not for arrays. Is there a way to make it work for both? https://gist.github.com/hanst99/8f3868f2c2b1cb12d489 |
| 21:54:28 | hannes__ | also, I'm assuming that there's a `<` then operator defined for my `A`s. Is there a way to codify that in the type? |
| 21:56:11 | * | pregressive joined #nim |
| 21:58:05 | Araq | hannes__: openarray |
| 21:59:06 | Araq | you can use concepts to encode that you assume '<' but you should really use 'cmp' instead and usually we don't care about encoding type requirements in generics |
| 22:00:26 | hannes__ | Ah, I see, thanks |
| 22:01:11 | Araq | it's not like the error messages significanly improve or something |
| 22:01:32 | flyx | I guess I got extremely lucky. |
| 22:01:56 | flyx | I have some workarounds in my code for handling shortcomings of the vm working with refs |
| 22:03:59 | * | hannes__ quit (Quit: Lost terminal) |
| 22:04:02 | Araq | meh I hate these things, I can fix it but later on you'll complain about slow compile times |
| 22:04:42 | flyx | would that be the quick fix or the real fix? |
| 22:05:14 | Araq | does it matter? when it worked were compile times acceptable? |
| 22:05:49 | flyx | yes, and actually, fast compiling is not a primary goal for me |
| 22:07:12 | flyx | I'd rather have my code compile slowly than having the risk of running into a vm bug |
| 22:07:53 | Araq | yeah well ... kinda late for that :P |
| 22:08:04 | Araq | now we have a speedy and buggy VM |
| 22:09:22 | * | gokr left #nim (#nim) |
| 22:10:01 | flyx | I admit that I started my project with the thought in mind „let's see how well these macro things work“ |
| 22:10:35 | flyx | but isn't a bug-free vm a long-term goal? |
| 22:11:07 | Araq | sure but that doesn't mean I like it |
| 22:11:26 | Araq | I have 3 fixes for your bug btw |
| 22:11:35 | Araq | but not one that satifies me |
| 22:13:44 | drewsrem | btw. what does the VM actually do? / what it is for? |
| 22:14:32 | Araq | drewsrem: runs Nim code at compile time |
| 22:16:00 | drewsrem | Ah I see |
| 22:20:57 | flyx | well it's your decision if and how to fix it. I'd just say, if the Nim vm should one day be bug-free, the bugs need to be fixed *somewhen*, so why not now |
| 22:26:34 | Araq | yeah yeah yeah |
| 22:28:38 | Araq | don't worry, it's always the same kind of bug in the vm anyway |
| 22:29:38 | * | flyx doesn't worry |
| 22:30:04 | * | flyx goes to sleep instead |
| 23:05:47 | * | yglukhov joined #nim |
| 23:10:06 | * | yglukhov quit (Ping timeout: 250 seconds) |
| 23:15:41 | * | boop is now known as boopisaway |
| 23:25:27 | * | MatrixBridge quit (Ping timeout: 256 seconds) |
| 23:27:09 | * | MatrixBridge joined #nim |
| 23:31:35 | * | filwit quit (Ping timeout: 244 seconds) |
| 23:43:06 | * | filwit joined #nim |