| 00:05:25 | * | Trustable quit (Remote host closed the connection) |
| 00:06:36 | * | Demon_Fox quit (Quit: Leaving) |
| 00:12:39 | * | coopernurse quit () |
| 00:14:23 | Araq | Jehan_: yes except that .immediate is expanded eagerly in a generic too. |
| 00:14:42 | Araq | and an all 'expr' template is not |
| 00:15:06 | Jehan_ | Okay. I think I'm not going to bother the guy with this level of detail, though. |
| 00:15:10 | Araq | the interactions of generics with templates is particularly nasty |
| 00:15:50 | Araq | though arguably the complexity comes from our butchered generics which do not perform a proper type-check |
| 00:16:37 | Araq | something which we should fix for Nim 2.0 once 'concept' is stable |
| 00:16:50 | flaviu | Have people in here looked at the rust stdlib? Seems to be very well designed. |
| 00:17:40 | flaviu | Looks like they have this "trait" thing, which is basically a nim concept. |
| 00:18:54 | Araq | everything in Rust is well designed but at the end of the day I don't want to work in a language that thinks everybody is developing software for a space shuttle. |
| 00:19:02 | Jehan_ | Rust traits are essentially a simplified version of ML signatures. |
| 00:19:53 | fowl | meh |
| 00:20:06 | flaviu | Well, the main point is that traits are used extensively to provide polymorphism. |
| 00:20:36 | reactormonk | would it be possible to replace generics with concepts? |
| 00:20:41 | fowl | this seems extremely weird http://rustbyexample.com/trait.html `let spike: Dog = Animal::new("spike")` |
| 00:21:12 | fowl | animal is the trait here, but it instantiates a Dog? |
| 00:22:28 | flaviu | Seems like some sort of reverse type inference, it is weird. |
| 00:23:38 | reactormonk | maybe it's upcasting? |
| 00:23:43 | fowl | reactormonk, whenever you use a generic parameter as a parameter, like if you check obj.len from map[T](obj: T), then it has requirements you could put into a concept |
| 00:24:02 | reactormonk | fowl, so basically like haskell does it |
| 00:24:05 | flaviu | But my main point here is the stdlib is well designed because of |
| 00:24:05 | flaviu | 1) Extensive use of traits (concepts) to provide polymorphism |
| 00:24:06 | flaviu | 2) Library functionally designed by determine what operations can be logically used on a type rather then adding operations as needed. |
| 00:24:07 | Jehan_ | We're talking essentially about structural subtyping here. |
| 00:24:22 | Jehan_ | Structural typing can be used for both static and dynamic dispatch. |
| 00:24:26 | fowl | reactormonk, but if you dont need to call it or pass it around, if you just needed to store a pointer to it or cast it and return it, it should be `any` |
| 00:24:48 | reactormonk | fowl, sounds nice |
| 00:24:49 | Jehan_ | Static dispatch is how C++ and Nim work, sort of (except that currently neither of them requires you to specify the interface, but it's inferred). |
| 00:25:58 | Jehan_ | Haskell and ML allow you to do it explicitly with type classes/signatures. |
| 00:26:27 | Jehan_ | You can also use the same feature for dynamic dispatch. |
| 00:27:08 | Jehan_ | However, it's much trickier to describe signatures that involve more than one type parameter and use them for dynamic dispatch. |
| 00:27:20 | reactormonk | the question is - can you still get C-like speed with that approach? |
| 00:27:47 | Jehan_ | reactormonk: Any approach that uses dynamic dispatch will do something that C cannot do directly. |
| 00:27:58 | Jehan_ | Since C does not have dynamic dispatch on types. |
| 00:28:20 | Jehan_ | Or static, for that matter (except for the generic stuff in C11). |
| 00:28:48 | reactormonk | Jehan_, you don't need static dispatch in C, because you can determine which proc to invoke in the nim compiler |
| 00:28:48 | fowl | Jehan_, i plan to have a macro pull the statement list from a concept type and build a generic 'interface' type with that |
| 00:29:26 | Jehan_ | reactormonk: If you were to write code in C directly. C as a compiler backend is a more complicated story. |
| 00:29:59 | * | wb quit (Ping timeout: 264 seconds) |
| 00:30:26 | Jehan_ | The thing is that any language that implements dynamic dispatch has to settle for one convention. If you implement it in C in the same way, the speed in C should be exactly the same. |
| 00:31:10 | Jehan_ | Of course, since C is not really bound by that convention, they can situationally use a different (possibly faster) solution at the expense of interoperability with code that uses other conventions. |
| 00:31:24 | reactormonk | Jehan_, function pointers? |
| 00:32:36 | Jehan_ | Function pointers you can do in other languages, too, if they're sufficient for what you need. |
| 00:32:48 | Jehan_ | I'm talking about situations where function pointers don't suffice. |
| 00:32:57 | reactormonk | lambdas? |
| 00:33:22 | Jehan_ | Lambda closures cannot be expressed through function pointers alone, since function pointers lack an environment. |
| 00:33:37 | Araq | flaviu: C++'s STL is also well designed in this respect and so is D's range concept. |
| 00:34:06 | Jehan_ | Which is why callbacks in C usually are a pair (function pointer, void *) to give you a poor man's closure. |
| 00:34:27 | Jehan_ | I'll also note that C is not fast. C *can* be fast given a sufficiently omniscient programmer. |
| 00:34:47 | Jehan_ | It is pretty easy to make C fast for tight inner loops, especially over contiguous blocks of memory. |
| 00:34:47 | reactormonk | I suppose it depends on your definition of fast ;-) |
| 00:34:56 | flaviu | Araq: That's great! Nim's stdlib should take inspiration from them! |
| 00:35:10 | Araq | But I'm still not a huge fan of these things because at the end of the day, my foo::String is not compatible to std::string. |
| 00:35:10 | reactormonk | flaviu, the question is how much can you remash the stdlib |
| 00:35:23 | Jehan_ | If you're dealing with complex data structures, the lack of abstractions that C provides generally means that you'll be writing inefficient code. |
| 00:36:02 | Araq | flaviu: the problem remains that generics are *viral* |
| 00:36:26 | reactormonk | Araq, as in they infect everythin? |
| 00:36:27 | flaviu | Araq: But it is! std::string is just a concept for a indexable char container. |
| 00:36:41 | flaviu | Err, dunno what it is in rust, but it could be so. |
| 00:39:27 | Jehan_ | Something different: I'm sympathetic towards getting a different name for .gensym, but I can't really come up with a good alternative. |
| 00:40:07 | Araq | flaviu: an AST node with a string[T] either is Node[T] or a Node and nails the T in String[T]. |
| 00:40:42 | Araq | For you Node[T] is the hallmark of good generic design. For me it's a tradeoff. |
| 00:41:03 | flaviu | Araq: I can't parse that first sentence, can you rewrite it? |
| 00:42:00 | Araq | type Node = ref object |
| 00:42:04 | Araq | ... stuff ... |
| 00:42:29 | Araq | stringLiteral: string[char] |
| 00:42:49 | Araq | vs |
| 00:42:55 | Araq | type Node[T] = ref object |
| 00:42:58 | Araq | ... stuff ... |
| 00:43:06 | Araq | stringLiteral: string[T] |
| 00:43:38 | flaviu | No, I'd want |
| 00:43:38 | flaviu | type Node[T <: string] = ref object |
| 00:43:38 | flaviu | stringLiteral: T |
| 00:43:47 | Araq | doesn't matter |
| 00:44:45 | flaviu | But what is the tradeoff here? |
| 00:45:08 | fowl | Araq, i want to do this type x[T] = someMacro(T) and have it invoked at instantiation is that possible |
| 00:45:58 | Araq | Node works in a production compiler consisting of thousands of lines of code. Node[T] does not. Do you really want *every single function* to be generic? |
| 00:46:46 | flaviu | But the generic would only be instantiated once or twice. |
| 00:46:47 | * | gsingh93 quit (Ping timeout: 250 seconds) |
| 00:49:37 | Araq | fowl: no but we can support it |
| 00:50:13 | Araq | Jehan_: I cannot think of something better than 'gensym' either. |
| 00:50:28 | Araq | "noinject"? that's backwards |
| 00:50:40 | fowl | how about: type LiteralNode[T] = ref object of Node; value: T; type StringLiteral[T] = ref object of LiteralNode[string[T]] |
| 00:50:47 | Jehan_ | Araq: Heh. {.internal.} was the best I could come up with. |
| 00:51:00 | Jehan_ | I don't like private etc. for the same reasons as you (I think). |
| 00:51:01 | Araq | and it's the default anyway for locals so you don't have to write it often |
| 00:51:17 | fowl | ast with inheritance would be a lot to change though |
| 00:51:42 | Araq | fowl: inheritance is a different topic |
| 00:52:32 | Araq | flaviu: the interop problems with C++'s string types are real and not something I made up to have an argument with you. |
| 00:52:43 | * | gsingh93 joined #nim |
| 00:54:00 | flaviu | Seems as if there's been some miscommunication. I don't see where you've referenced C++'s string types. |
| 01:01:10 | Araq | ok, I need to sleep, we continue this discussion but at the end of the day, every single proc in the stdlib will be generic and depend on some concept anyway. |
| 01:01:16 | Araq | *we can continue |
| 01:01:57 | Araq | that's what happened with Scala, C++, D, Rust and Haskell and is inevitable |
| 01:02:16 | Araq | so I won't fight it |
| 01:03:48 | reactormonk | Araq, what do you dislike about generic/concepts? |
| 01:05:16 | Jehan_ | Heh. :) |
| 01:06:54 | flaviu | reactormonk: I don't want to put words in his mouth, but the problem he sees here looks like code bloat. |
| 01:07:08 | flaviu | Generated code bloat |
| 01:07:43 | renesac | and compile time bloat |
| 01:07:57 | renesac | err, increase in compilation times |
| 01:09:14 | Jehan_ | flaviu: I think it's not just code bloat, but also the fact that code generation for generics is (necessarily) different from code generation for fixed types. |
| 01:11:16 | Jehan_ | renesac: And yeah, type checking is also necessarily more expensive. |
| 01:11:53 | renesac | I still like generics and concepts though |
| 01:12:36 | renesac | is nim type checking paralelizable? |
| 01:12:44 | Jehan_ | renesac: Yeah, and they're part of the core language. I think Araq is more concerned with having generic bloat (in the source, not the generated code). |
| 01:13:28 | Jehan_ | renesac: It doesn't really matter if it is. Parallelizing non-trivial algorithms is something that needs to be approached with care. |
| 01:13:37 | * | TEttinger joined #nim |
| 01:13:59 | Jehan_ | You want type checking to be correct much more than you want it to be fast. |
| 01:14:21 | renesac | right, just thinking on the long term |
| 01:14:38 | Jehan_ | Incremental compilation will do more about compile speed issues than parallel type-checking. |
| 01:15:13 | renesac | yeah, especially regarding imports from stdlib |
| 01:15:16 | Jehan_ | For what it's worth, I did experiment with --symbolfiles when that option still worked and incremental compilation was really, really good back then. |
| 01:15:23 | * | bpr joined #nim |
| 01:15:27 | renesac | they can surelly be made much faster with some smart caching |
| 01:16:03 | Jehan_ | As in: compile time < 1s for 1 million LOC as long as the change was local. |
| 01:16:16 | renesac | :) |
| 01:17:09 | flaviu | Impressive. |
| 01:17:37 | Jehan_ | Well, this was with hot caches and everything. |
| 01:17:39 | flaviu | I wonder how it worked. |
| 01:18:22 | Jehan_ | Well, I've tried to understand how rod files work, but realized soon that that required more time than I had. |
| 01:18:47 | Jehan_ | Mind you, that was generated source code. It may have been that I hit a sweet spot. |
| 01:19:05 | Jehan_ | Still, it seems to indicate that Nim can at least in principle recompile without revalidating everything. |
| 01:20:51 | bpr | Say, I just noticed that the 'normalize' procedure in lib/pure/strutils.nim lowers the first character, which is correct for Nimrod but not Nim (I think). Is that correct? |
| 01:20:57 | Jehan_ | It's not all that surprising, though. Scala is really slow when doing a cold compile, but incremental compilation can be blazingly fast. |
| 01:21:40 | Jehan_ | bpr: Hmm. I'm not sure about that. It may be a backwards compatibility thing. |
| 01:23:35 | bpr | Jehan: I was looking at fixing some Nim bugs and noticed that one, but since it's my first attempt I thought I'd ask... |
| 01:24:28 | Jehan_ | Hmm. |
| 01:24:59 | Jehan_ | I'm wondering if instead you want a new procedure `normalizeNimIdent` or something. |
| 01:25:07 | Jehan_ | Because the semantics are very Nim-specific. |
| 01:25:24 | Jehan_ | Whereas the old `normalize` could potentially make sense for stuff other than Nim identifiers. |
| 01:25:25 | renesac | if it is for backwards compatibility, and intended only on nim identifiers, that proc should be changed or deprecated |
| 01:26:31 | renesac | bugs caused by it surelly would have appeared if the compiler were actually using that, though... |
| 01:26:32 | bpr | Are there spots in the code that need to use the old one? If you just change normalize, koch.nim doesn't quite work, but that's easy to fix I think. |
| 01:27:24 | Jehan_ | renesac: It's used for command line options, I think. |
| 01:28:00 | renesac | humm |
| 01:28:07 | renesac | so it normalizes also things-like-that? |
| 01:28:08 | Jehan_ | Possibly also for generated code. |
| 01:28:21 | Jehan_ | "nim C_C" is the same as "nim cc". |
| 01:28:23 | renesac | then it makes sense to put everything lower case |
| 01:29:08 | bpr | Jehan: I was investigating the bug when there are two variables named p and P and the C compilation fails. |
| 01:29:32 | bpr | because both get mapped to 'p' |
| 01:29:43 | Jehan_ | bpr: Huh. |
| 01:29:52 | Jehan_ | They should still get different suffixes. |
| 01:30:45 | bpr | https://github.com/Araq/Nim/issues/2212 |
| 01:30:58 | Jehan_ | Oh, local variables. Right. |
| 01:31:57 | bpr | Sorry, kids bugging me to get off computer, be back in half an hour... |
| 01:32:03 | * | bpr quit (Quit: Page closed) |
| 01:39:12 | fowl | hmm |
| 01:39:45 | fowl | c2nim chokes on `1e5` |
| 01:43:02 | Jehan_ | Ah, it's in ccgutils.nim::mangle |
| 01:43:25 | Jehan_ | normalize doesn't enter into it. |
| 01:44:19 | Jehan_ | Not entirely sure what the correct solution is, though. |
| 01:45:42 | Jehan_ | Just removing .toLower should fix the issue, but I wonder if that may then generate identifiers that conflict with something else. |
| 01:46:42 | * | pregressive joined #nim |
| 01:46:53 | Jehan_ | Hmm. You'd definitely get a conflict if you have an identifer "N0" and another identifier "0" (not sure how you get that, presumably something internal). |
| 01:48:24 | fowl | you can throw __ on the end |
| 01:48:39 | fowl | lul |
| 01:48:49 | flaviu | But Nim complains if your identifiers contain __ |
| 01:49:03 | fowl | yea so your nim ident couldnt conflict with a c ident |
| 01:49:18 | Jehan_ | flaviu: For the generated C code. |
| 01:49:51 | Jehan_ | fowl: Well, local variables should be relatively unmangled. |
| 01:50:04 | Jehan_ | You could also prefix it with C or something. |
| 01:51:49 | * | brson quit (Quit: leaving) |
| 01:52:08 | * | bpr joined #nim |
| 01:52:11 | Jehan_ | But in short: it's easy to fix, Araq will just have to have to say how he wants these identifiers mangled. |
| 01:55:56 | bpr | Jehan: Great! But normalize should still leave the first char unchanged, right? It's supposed to normalize according to Nim's lexical rules, and those now say that the first char case matters. |
| 01:57:35 | * | pregressive quit () |
| 02:02:26 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 02:03:01 | * | untitaker quit (Ping timeout: 248 seconds) |
| 02:09:27 | * | untitaker joined #nim |
| 02:28:44 | Jehan_ | bpr: Yeah, mangle is not dependent on normalize at all. |
| 02:29:09 | Jehan_ | It's a totally separate implementation. |
| 02:29:34 | * | gsingh93 quit (Ping timeout: 272 seconds) |
| 02:40:17 | * | meeeee3 joined #nim |
| 02:42:01 | meeeee3 | setInt(mlist, "COUNT", 10) in nim? |
| 02:42:35 | * | gsingh93 joined #nim |
| 02:45:08 | * | darkf joined #nim |
| 02:47:18 | reactormonk | meeeee3, whut? |
| 02:51:15 | * | johnsoft quit (Ping timeout: 244 seconds) |
| 02:51:54 | * | johnsoft joined #nim |
| 02:53:42 | meeeee3 | setint is a c func? |
| 02:56:25 | flaviu | meeeee3: You could probably look at a C wrapper and copy it |
| 02:56:32 | flaviu | or perhaps run the header through c2nim |
| 02:56:41 | flaviu | http://goran.krampe.se/2014/10/16/nim-wrapping-c/ |
| 03:04:27 | * | Jehan_ quit (Quit: Leaving) |
| 03:12:02 | * | a5i joined #nim |
| 03:17:01 | * | meeeee3 left #nim (#nim) |
| 03:19:06 | * | gsingh93 quit (Quit: WeeChat 1.1.1) |
| 03:19:42 | * | meeeee3 joined #nim |
| 03:19:51 | meeeee3 | accidently closed chat, did someone answer? |
| 03:20:01 | * | gsingh93 joined #nim |
| 03:23:38 | EXetoC | for logs, see the topic. bye |
| 03:34:13 | * | gsingh93 quit (Ping timeout: 248 seconds) |
| 03:34:40 | * | bpr quit (Ping timeout: 246 seconds) |
| 03:44:16 | * | meeeee3 left #nim (#nim) |
| 03:47:20 | * | gsingh93 joined #nim |
| 04:09:52 | dhasenan | I have a ref Foo that I want to pass to a C function that takes a void*. How do I do this? |
| 04:12:48 | dhasenan | Specifically, I'm using an event system that allows me to pass a data pointer to be supplied to a callback, so I need to feed it something that fits in a void* that I can restore to a ref Foo later. |
| 04:13:55 | * | endragor joined #nim |
| 04:14:16 | renesac | dhasenan: this probably involves addr() |
| 04:14:31 | fowl | dhasenan, cast to pointer |
| 04:14:32 | renesac | but I suggest you to do that question in stackoverflow so more people can see that |
| 04:14:47 | renesac | afterwards |
| 04:15:06 | renesac | is there a tutorial on interfacing with C? besides c2nim? |
| 04:15:12 | fowl | if you need to and you can unref it later, gcref it first |
| 04:15:18 | * | brson joined #nim |
| 04:15:43 | renesac | fowl: if it is a ref Foo from nim it should already be referenced by the GC |
| 04:16:03 | * | endragor quit (Remote host closed the connection) |
| 04:16:06 | renesac | and he shouldn't unref it otherwise the GC could erase it |
| 04:16:16 | fowl | renesac, if you pass a ref to c and dont keep reference to in nim you do need to ref and unref it manually |
| 04:16:50 | flaviu | But only if the C code keeps a reference to it. |
| 04:17:04 | fowl | sure whatever |
| 04:17:22 | flaviu | If you pass it to C but get ownership of the pointer back at the end of the C call, that requires no special precaution. |
| 04:17:25 | fowl | you ought to avoid this though |
| 04:17:55 | renesac | ^ this, what flaviu said is what I was thinking |
| 04:18:18 | dhasenan | I'm not seeing a gcref function in the nim source code or docs. |
| 04:18:35 | * | endragor joined #nim |
| 04:18:35 | fowl | GCref/GCunref |
| 04:18:57 | dhasenan | GC_ref |
| 04:18:58 | fowl | thats right flaviu |
| 04:19:02 | dhasenan | Got it. |
| 04:19:33 | renesac | oh, those functions should be renamed to the new naming convention |
| 04:20:08 | renesac | why they are in system by the way? |
| 04:24:05 | * | endragor quit (Remote host closed the connection) |
| 04:26:54 | * | endragor joined #nim |
| 04:28:40 | * | endragor quit (Remote host closed the connection) |
| 04:28:54 | * | endragor joined #nim |
| 04:31:45 | * | saml_ quit (Quit: Leaving) |
| 04:32:40 | * | endragor quit (Remote host closed the connection) |
| 04:33:26 | * | brson quit (Quit: leaving) |
| 04:33:27 | dhasenan | Turns out I was getting confused by an unrelated segfault and casting to pointer worked pretty trivially. |
| 04:34:35 | * | endragor joined #nim |
| 04:39:46 | * | endragor quit (Remote host closed the connection) |
| 04:40:40 | * | dashed joined #nim |
| 04:42:59 | * | Demon_Fox joined #nim |
| 05:43:14 | * | a5i quit (Quit: Connection closed for inactivity) |
| 06:04:05 | * | gsingh93 quit (Ping timeout: 248 seconds) |
| 06:25:18 | * | Varriount_ joined #nim |
| 06:28:09 | * | Varriount quit (Ping timeout: 245 seconds) |
| 07:01:20 | * | vendethiel quit (Ping timeout: 246 seconds) |
| 07:02:08 | * | vendethiel joined #nim |
| 07:23:31 | * | Sembei quit (Ping timeout: 256 seconds) |
| 07:55:19 | * | Ven joined #nim |
| 07:56:25 | * | Ven quit (Client Quit) |
| 07:58:47 | * | BlaXpirit joined #nim |
| 08:01:46 | * | gmpreussner|work quit (Read error: Connection reset by peer) |
| 08:02:11 | * | Ven joined #nim |
| 08:09:21 | * | MyMind joined #nim |
| 08:21:39 | * | repax joined #nim |
| 08:30:30 | * | wb joined #nim |
| 08:47:04 | * | Demon_Fox quit (Quit: Leaving) |
| 08:56:44 | * | Sembei joined #nim |
| 08:58:59 | reactormonk | Araq, is it possible at all to move unsigned literals to the unsigned module or would that be too nasty? |
| 09:01:28 | * | milosn quit (Ping timeout: 255 seconds) |
| 09:18:28 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 09:38:47 | * | dv- quit (Ping timeout: 276 seconds) |
| 09:39:27 | * | dv- joined #nim |
| 09:41:46 | * | irrequietus joined #nim |
| 09:42:45 | * | Matthias247 joined #nim |
| 09:44:01 | * | Ven joined #nim |
| 10:01:08 | * | dv- quit (Changing host) |
| 10:01:08 | * | dv- joined #nim |
| 10:14:18 | * | dashed quit (Quit: Connection closed for inactivity) |
| 10:18:27 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 10:29:44 | * | milosn joined #nim |
| 10:41:35 | * | Ven joined #nim |
| 10:44:29 | * | HakanD joined #nim |
| 11:07:30 | * | jefus__ joined #nim |
| 11:10:45 | * | jefus_ quit (Ping timeout: 248 seconds) |
| 11:28:59 | * | TEttinger quit (Ping timeout: 250 seconds) |
| 11:30:50 | * | BitPuffin joined #nim |
| 11:45:21 | * | Trustable joined #nim |
| 11:49:51 | * | irrequietus quit () |
| 11:52:28 | * | Senketsu joined #nim |
| 11:57:12 | * | JinShil joined #nim |
| 12:00:49 | * | wtw quit (Read error: Connection reset by peer) |
| 12:01:46 | * | wtw joined #nim |
| 12:04:10 | * | Kingsquee quit (Quit: Konversation terminated!) |
| 12:04:57 | * | endragor joined #nim |
| 12:09:31 | * | endragor quit (Remote host closed the connection) |
| 12:10:33 | * | endragor joined #nim |
| 12:11:38 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 12:15:26 | * | BlaXpirit-UA joined #nim |
| 12:17:40 | * | BlaXpirit quit (Ping timeout: 252 seconds) |
| 12:18:47 | * | JinShil quit (Quit: Konversation terminated!) |
| 12:19:37 | * | Ven joined #nim |
| 12:21:42 | * | endragor quit (Remote host closed the connection) |
| 12:22:59 | * | endragor joined #nim |
| 12:41:02 | * | endragor quit (Remote host closed the connection) |
| 12:41:35 | * | endragor joined #nim |
| 12:42:01 | * | irrequietus joined #nim |
| 12:47:48 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 12:51:45 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 12:56:24 | * | Ven joined #nim |
| 12:59:50 | * | milosn quit (Ping timeout: 252 seconds) |
| 13:11:18 | * | endragor quit (Remote host closed the connection) |
| 13:13:56 | * | fluoride joined #nim |
| 13:15:03 | * | endragor joined #nim |
| 13:17:12 | * | fluoride quit (Client Quit) |
| 13:19:25 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:24:10 | * | Ven joined #nim |
| 13:25:15 | * | Ven quit (Client Quit) |
| 13:25:17 | * | milosn joined #nim |
| 13:27:09 | * | Ven joined #nim |
| 13:28:20 | endragor | var mySeq : seq[int64] = @[1i64, 2i64, 3i64, 4i64, 5i64, 6i64, 7i64, 8i64, 9i64] |
| 13:28:27 | endragor | is there a way to make that look prettier? |
| 13:29:45 | endragor | (not having to append "i64" to each number). Something like "toSeq(countup(1,9))", but countup() returns "int", and I'm not sure how you convert output of an iterator. |
| 13:32:34 | EXetoC | .eval var x=@[0i64, 0, 0, 0] |
| 13:32:36 | Mimbus | EXetoC: eval.nim(3, 8) Error: ':' or '=' expected, but found '[' |
| 13:33:13 | EXetoC | .eval var x = @[0i64, 0, 0, 0] |
| 13:33:17 | Mimbus | EXetoC: <no output> |
| 13:39:13 | dom96 | yeah, you just need to have it on the first element. |
| 13:41:44 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:42:00 | EXetoC | endragor: oh. just pass in 64 bit integers |
| 13:42:30 | EXetoC | iterator countup*[S, T](a: S, b: T, step = 1): T |
| 13:43:13 | endragor | ahh, thanks! |
| 13:46:33 | * | endragor quit (Remote host closed the connection) |
| 13:47:45 | * | endragor joined #nim |
| 13:53:18 | * | Ven joined #nim |
| 13:59:19 | repax | Is anyone using the unittest module? I can't get it to work. |
| 13:59:30 | dhasenan | repax: it's working for me. |
| 13:59:48 | repax | First of all the compiler fails to generate C-code for the terminal module (to give colours) |
| 14:00:13 | dhasenan | Are you on master or devel? |
| 14:00:13 | repax | I'm on osx but it has posix support so that shouldn't be a problem |
| 14:00:17 | repax | devel |
| 14:00:48 | dhasenan | Okay, it's working on devel for me as of ca5c3295. |
| 14:00:54 | dhasenan | With the C++ backend. |
| 14:01:06 | repax | Interesting I'm also using the c++ backend |
| 14:01:14 | dhasenan | I'll update and re-test. |
| 14:02:21 | repax | dhasenan, have you published code (open source) that uses it successfully? Or are you aware of any such code? I could try to compile it |
| 14:03:24 | dom96 | Do you need to use the C++ backend? It's likely the problem |
| 14:03:27 | dhasenan | repax: I have code, but it's on my private gitlab instacne. |
| 14:03:41 | repax | dom96, I see. I'll try without |
| 14:03:51 | dhasenan | Updated and it still seems to work (even after nuking nimcache). I'll gist my unittest. |
| 14:04:30 | dhasenan | https://gist.github.com/anonymous/db05fa6995a9645e276c |
| 14:04:54 | dhasenan | The only interesting import is macros. |
| 14:05:12 | repax | dom96, You're correct. It's the C++ thing that makes it fail |
| 14:05:18 | repax | hm |
| 14:05:26 | dom96 | report it on github |
| 14:05:50 | repax | I'll do |
| 14:06:13 | repax | dhasenan, but you generate C++, you say. |
| 14:07:10 | dhasenan | Hrm, I'm compiling with a few compiler options. Without them, it fails. |
| 14:07:23 | * | endragor quit (Remote host closed the connection) |
| 14:07:33 | dhasenan | Turn on dead code elimination. |
| 14:07:37 | dhasenan | --deadCodeElim:on |
| 14:07:42 | dhasenan | That makes it work for me. |
| 14:07:46 | dhasenan | I'll file a bug report. |
| 14:08:39 | repax | I get other problems then |
| 14:09:33 | * | endragor joined #nim |
| 14:09:36 | repax | undefined symbols (_stackoverflow_19801) from stdlib_unsigned.o, stdlib_termios.o, stdlib_posix.o |
| 14:09:47 | dhasenan | Intriguing. |
| 14:10:49 | repax | --assertions:on --checks:on --hints:on --warnings:on --debuginfo --opt:none --deadCodeElim:on --parallelBuild:1 |
| 14:11:08 | federico3 | (I'd love to have python-like string formatters) |
| 14:12:13 | dom96 | federico3: `%` not good enough? |
| 14:13:16 | EXetoC | it's limited of course |
| 14:13:19 | EXetoC | https://bitbucket.org/lyro/strfmt |
| 14:13:31 | federico3 | something quick and handy like: print "pi %15.2f " % 3.1415 |
| 14:13:42 | * | endragor quit (Remote host closed the connection) |
| 14:14:01 | * | endragor joined #nim |
| 14:15:25 | federico3 | EXetoC: exactly :) |
| 14:15:55 | EXetoC | but it's fine in many cases |
| 14:16:51 | federico3 | alignment, trimming floats, that's what is needed most frequently |
| 14:17:25 | repax | dhasenan, my mistake. I had to clean build caches |
| 14:17:37 | EXetoC | ok well try that lib then |
| 14:17:40 | repax | Thanks, it works now even with C++ backend |
| 14:17:47 | repax | using deadcode elim |
| 14:17:57 | dhasenan | \o/ |
| 14:19:12 | * | HakanD quit (Quit: Be back later ...) |
| 14:23:37 | * | HakanD joined #nim |
| 14:26:07 | * | qwr quit (Ping timeout: 265 seconds) |
| 14:33:40 | * | gmpreussner|work joined #nim |
| 14:34:54 | gmpreussner|work | do we have a package for talking to serial ports? |
| 14:44:25 | * | darkf quit (Quit: Leaving) |
| 14:46:50 | federico3 | EXetoC: aha: http://forum.nim-lang.org/t/1020/2 |
| 14:49:06 | dom96 | gmpreussner|work: don't think so |
| 14:53:43 | dom96 | TIL there is a crown emoji. |
| 14:53:44 | gmpreussner|work | dom96: hmm... ok, i'll see if i can write some bindings then |
| 14:54:47 | federico3 | EXetoC: on second thought, giving that I almost always prefer log.<priority>() over print() in Python, maybe the formatting could be done inside a logging module. |
| 15:15:38 | * | repax quit (Quit: repax) |
| 15:31:44 | * | BitPuffin joined #nim |
| 15:33:45 | endragor | is there a reason for not having `excl` for OrderedSet? |
| 15:36:10 | * | Trustable quit (Remote host closed the connection) |
| 15:38:45 | renesac | endragor: I would guess the reason for that is because that is an O(n) operation in the way they are implemented |
| 15:38:46 | * | endragor quit (Remote host closed the connection) |
| 15:41:08 | renesac | by the way, this ordered hash table implementation is interesting: https://nikic.github.io/2014/12/22/PHPs-new-hashtable-implementation.html |
| 15:41:49 | renesac | it is basically a open addressing hash table that holds a index to an ordered vector with the keys and data. |
| 15:42:28 | * | HakanD quit (Quit: Be back later ...) |
| 15:42:54 | * | endragor joined #nim |
| 15:43:21 | renesac | endragor: look at the log |
| 15:45:51 | endragor | ah, so it's backed with a seq instead of linked list.. |
| 15:46:14 | renesac | endragor: my link is for the php implementation |
| 15:46:18 | endragor | backing it with linked list would make O(1) excl possible |
| 15:46:32 | endragor | I didn't look at PHP implementation |
| 15:46:39 | renesac | yeah, but slower overall |
| 15:46:46 | renesac | right |
| 15:46:56 | endragor | why slower? |
| 15:47:01 | renesac | oh |
| 15:47:13 | * | HakanD joined #nim |
| 15:47:27 | renesac | I may be wrong |
| 15:47:32 | renesac | I must look the code |
| 15:47:54 | renesac | but it would probably consume more memory at least, for the pointers |
| 15:48:54 | renesac | (well, an seq can also waste memory because it has a power of 2 size, but on average is probably less) |
| 15:50:18 | * | BlaXpirit-UA quit (Quit: Quit Konversation) |
| 15:50:38 | endragor | I mean not the hashtable itself, but the seq that is there to maintain order |
| 15:52:21 | * | BlaXpirit joined #nim |
| 15:52:21 | endragor | hmm, no, implementation is different from what I thought |
| 15:54:00 | renesac | indeed |
| 15:54:33 | renesac | it might be a simple overlook then |
| 15:55:22 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:05:03 | * | repax joined #nim |
| 16:06:00 | * | endragor quit (Remote host closed the connection) |
| 16:07:28 | * | endragor joined #nim |
| 16:15:16 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 16:24:29 | * | wan quit (Quit: WeeChat 1.1.1) |
| 16:58:41 | * | irrequietus quit () |
| 17:02:56 | * | Ven joined #nim |
| 17:09:45 | * | irrequietus joined #nim |
| 17:11:16 | * | endragor quit (Remote host closed the connection) |
| 17:13:18 | * | endragor_ joined #nim |
| 17:43:05 | * | endragor_ quit (Remote host closed the connection) |
| 17:46:13 | * | johnsoft quit (Ping timeout: 265 seconds) |
| 17:47:36 | * | johnsoft joined #nim |
| 17:58:19 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:58:20 | * | HakanD quit (Read error: Connection reset by peer) |
| 18:07:32 | * | johnsoft quit (Ping timeout: 272 seconds) |
| 18:12:03 | * | pipeep quit (Ping timeout: 245 seconds) |
| 18:12:03 | * | johnsoft joined #nim |
| 18:14:28 | * | pipeep joined #nim |
| 18:26:06 | * | MyMind quit (Ping timeout: 250 seconds) |
| 18:27:47 | * | johnsoft quit (Ping timeout: 265 seconds) |
| 18:32:04 | * | johnsoft joined #nim |
| 18:47:20 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 18:49:04 | * | Sembei quit (Ping timeout: 250 seconds) |
| 18:52:03 | * | johnsoft joined #nim |
| 19:07:37 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 19:10:29 | repax | How does one build the nim documentation? I've tried ./koch web but nimweb fails: |
| 19:10:54 | repax | "cannot open: web/nim.ini" |
| 19:11:02 | repax | I have no nim.ini |
| 19:11:14 | * | Sembei joined #nim |
| 19:11:30 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 19:12:02 | * | johnsoft joined #nim |
| 19:12:15 | * | vendethiel joined #nim |
| 19:13:49 | * | Menche joined #nim |
| 19:27:19 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 19:32:12 | * | johnsoft joined #nim |
| 19:36:37 | * | Menche quit (Quit: Leaving) |
| 19:38:21 | dom96 | repax: looks like somebody recently renamed nim.ini to installer.ini |
| 19:38:35 | dom96 | seems they forgot to change it in nimweb |
| 19:39:23 | repax | dom96, thanks |
| 19:42:52 | * | milosn quit (Ping timeout: 256 seconds) |
| 19:47:24 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 19:47:29 | * | milosn joined #nim |
| 19:47:57 | BlaXpirit | D: |
| 19:50:26 | * | Menche joined #nim |
| 19:52:13 | * | johnsoft joined #nim |
| 19:55:17 | * | elbow_jason joined #nim |
| 20:03:31 | * | yeye123 joined #nim |
| 20:05:30 | yeye123 | can you code interactively in nim, like in elm for example? |
| 20:07:02 | repax | yeye123: there's an experimental repl for nim. I don't know much about it |
| 20:07:03 | repax | https://github.com/wheineman/nrpl |
| 20:07:37 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 20:08:20 | yeye123 | thanks |
| 20:12:04 | * | johnsoft joined #nim |
| 20:12:27 | reactormonk | yeye123, it's more like a rcepl, it compiles the code ;-) |
| 20:14:52 | BlaXpirit | hm this stuff looks cool, exceeded my expectations |
| 20:25:02 | yeye123 | and can you do hot swapping of code? |
| 20:26:54 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 20:30:17 | flaviu | yeye123: No, but I've heard some talk in that direction. |
| 20:31:48 | repax | yeye123: it depends.. The source is compiled to machine code with no symbol information at runtime. But you can replace a dynamic library at runtime, I would think |
| 20:32:09 | * | johnsoft joined #nim |
| 20:33:02 | repax | The program is not executed in a virtual machine like, say, java or erlang |
| 20:34:10 | flaviu | It can be - see CTFE, but it typically isn't. |
| 20:35:09 | * | gsingh93 joined #nim |
| 20:42:38 | * | repax quit (Quit: repax) |
| 20:44:19 | * | endragor joined #nim |
| 20:47:28 | * | johnsoft quit (Ping timeout: 256 seconds) |
| 20:48:26 | * | endragor quit (Ping timeout: 252 seconds) |
| 20:52:05 | * | johnsoft joined #nim |
| 21:07:46 | * | johnsoft quit (Ping timeout: 265 seconds) |
| 21:09:09 | * | Kingsquee joined #nim |
| 21:10:21 | * | fishbrain joined #nim |
| 21:12:04 | * | johnsoft joined #nim |
| 21:14:32 | * | yeye123 quit (Ping timeout: 265 seconds) |
| 21:24:22 | * | fishbrain quit (Quit: Verlassend) |
| 21:27:19 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 21:32:14 | * | johnsoft joined #nim |
| 21:32:40 | * | BitPuffin joined #nim |
| 21:33:10 | * | BitPuffin quit (Remote host closed the connection) |
| 21:33:22 | * | BitPuffin joined #nim |
| 21:41:39 | * | Trustable joined #nim |
| 21:47:07 | * | johnsoft quit (Ping timeout: 256 seconds) |
| 21:51:24 | * | HakanD joined #nim |
| 21:52:11 | * | johnsoft joined #nim |
| 21:55:46 | * | HakanD quit (Client Quit) |
| 22:01:25 | * | zama quit (Ping timeout: 248 seconds) |
| 22:05:09 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:06:56 | * | johnsoft quit (Ping timeout: 272 seconds) |
| 22:10:26 | * | Trustable quit (Remote host closed the connection) |
| 22:10:51 | * | saml_ joined #nim |
| 22:12:04 | * | johnsoft joined #nim |
| 22:18:10 | * | zama joined #nim |
| 22:20:10 | * | angus quit (Quit: Leaving) |
| 22:27:17 | * | johnsoft quit (Ping timeout: 252 seconds) |
| 22:28:16 | Araq | arnetheduck: I merged your PR. what happened? |
| 22:28:38 | Araq | github failed to do it? |
| 22:31:21 | * | MagusOTB joined #nim |
| 22:32:09 | * | johnsoft joined #nim |
| 22:34:06 | * | MagusOTB quit (Client Quit) |
| 22:46:56 | pigmej | hmm, I feel quite lost for a while |
| 22:47:19 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 22:47:47 | pigmej | how can I correctly define a proc that returns "different" objects that have common parent ( inheritance ) |
| 22:49:06 | Araq | proc foo(): Parent ? |
| 22:49:47 | pigmej | Araq: then nim complains type missmatch: got(Parent) but expected 'child' |
| 22:51:36 | Araq | let c = Child(foo()) |
| 22:51:52 | Araq | in other words use a type conversion |
| 22:51:56 | pigmej | ah, ok |
| 22:52:04 | Araq | will be checked at runtime in debug mode then. |
| 22:52:17 | * | johnsoft joined #nim |
| 22:52:28 | pigmej | oks, that what came to my mind too, though I was hoping that nim has some helper for that ;) |
| 22:52:58 | pigmej | (and yes, I have already read about cast vs conversion) ;-) |
| 22:53:20 | Araq | downcasting is not typesafe so we cannot do it automatically |
| 22:53:30 | Araq | you *could* write a converter for this |
| 22:53:38 | Araq | but you really shouldn't. |
| 22:53:46 | pigmej | ok. |
| 22:53:58 | flaviu | pigmej: You shouldn't do Child(foo()) |
| 22:54:20 | flaviu | What happens if you make foo() return OtherChild? |
| 22:54:34 | pigmej | flaviu: it will not ;-) |
| 22:55:04 | pigmej | (probably...) |
| 22:55:21 | pigmej | flaviu: but if I shouldn't do that, then how Can I do something similar ? |
| 22:55:49 | flaviu | Well, you can make foo() return Child |
| 22:55:55 | flaviu | ie, proc foo(): Child |
| 22:56:04 | pigmej | so function per child type? |
| 22:56:16 | pigmej | (proc) |
| 22:56:50 | flaviu | I'm not sure what you mean. |
| 22:57:52 | pigmej | me also ... I'm still trying to wrap my head around static typing in fact .. |
| 22:58:59 | pigmej | but hmm, let's have something like this |
| 22:59:22 | pigmej | if I have dynamic object comming let's say from some serializer (json, msgpack whatever) |
| 22:59:46 | pigmej | then I want to parse it and return traced reference for my 'child container' |
| 22:59:57 | pigmej | then, how could I do so? |
| 23:00:23 | pigmej | I mean, I probably know how to do so, but I would like hear the recommended way :) |
| 23:00:46 | flaviu | Well, http://nim-lang.org/json.html is an example |
| 23:01:08 | flaviu | It uses object variants, but it's possible to do the same thing with inheritance. |
| 23:01:11 | pigmej | yeah, |
| 23:01:23 | pigmej | but then all fields needs to be different in names |
| 23:01:48 | pigmej | I started from it, then it became hmm, kind of unreadable |
| 23:02:47 | reactormonk | we have a natural number type? |
| 23:07:23 | Araq | reactormonk: sure, since version 0.001 |
| 23:07:41 | * | jefus_ joined #nim |
| 23:07:44 | * | johnsoft quit (Ping timeout: 272 seconds) |
| 23:09:35 | reactormonk | Araq, ok, never seen it |
| 23:10:04 | reactormonk | ah, found it |
| 23:11:06 | * | jefus__ quit (Ping timeout: 244 seconds) |
| 23:11:48 | def- | So Naturals should be used much more? |
| 23:12:08 | * | johnsoft joined #nim |
| 23:13:31 | Araq | def-: yeah pretty much, but you have to be a bit careful: |
| 23:13:49 | Araq | var x = foo.len |
| 23:14:02 | Araq | while x >= 0: dec x |
| 23:14:25 | Araq | # ouch, don't infer 'x' to be Natural here |
| 23:14:42 | * | brson joined #nim |
| 23:14:47 | Araq | so for better or worse 'len' should still return 'int' |
| 23:15:09 | def- | sounds like return types should be ints, parameters Naturals |
| 23:15:17 | Araq | exactly |
| 23:16:52 | Araq | proper "flow typing" would have been better instead of range[T] except that flow typing works much worse for Nim's generics and fixed size arrays |
| 23:19:01 | def- | reactormonk: you want to try making more params Naturals or should I? |
| 23:19:22 | reactormonk | def-, go mess, I'll take a look at the GC pull request again |
| 23:20:13 | reactormonk | fuck, too many branches |
| 23:21:14 | reactormonk | Araq, so it should run multiple threads? |
| 23:21:20 | reactormonk | ... the gc testing stuff |
| 23:22:00 | Araq | reactormonk: sure why not |
| 23:22:11 | reactormonk | Araq, I have no idea how to do it in C |
| 23:22:27 | reactormonk | should be possible in nim, gotta look at the doc |
| 23:22:44 | Araq | reactormonk: just test that DLLs work with multi threading and don't leak |
| 23:22:54 | Araq | don't write C code |
| 23:23:11 | reactormonk | Araq, so you would spawn the threads inside the DLL? |
| 23:23:44 | Araq | in the DLL and in the test program too |
| 23:24:05 | reactormonk | so in both? |
| 23:24:46 | def- | So, should we index seqs with Naturals? insert, delete for example |
| 23:25:01 | reactormonk | def-, I approve |
| 23:25:10 | reactormonk | you can even add Natural to [] if you want to |
| 23:25:23 | reactormonk | or rather Index, because it has to include ^1 too ;-) |
| 23:27:27 | * | johnsoft quit (Ping timeout: 265 seconds) |
| 23:27:38 | Araq | def-: yes |
| 23:28:15 | Araq | btw happy easter! |
| 23:28:28 | cazov | happy easter! |
| 23:28:45 | reactormonk | how do I get hold of the threads used in parallel/spawn to call getOccupiedMem? |
| 23:29:14 | Araq | "get hold"? |
| 23:29:30 | Araq | you call it in the thread |
| 23:29:42 | Araq | there is no other way, currently. |
| 23:30:05 | Araq | you cannot access the thread local storage from a different thread |
| 23:32:13 | * | johnsoft joined #nim |
| 23:33:59 | * | brson quit (Quit: leaving) |
| 23:34:21 | * | TEttinger joined #nim |
| 23:34:33 | reactormonk | the current design of said test runs the allocating proc a few times, then sleeps for a second, then calls occupiedMem. |
| 23:34:47 | reactormonk | Should I move said call into the worker thread? |
| 23:36:04 | Araq | yes |
| 23:38:17 | reactormonk | I would assume the gc test also tests for multiple calls to the dll - I can't really emulate that one |
| 23:39:08 | reactormonk | https://github.com/Araq/Nim/pull/1891/files#diff-2bdfb91f2f92400ba50898d03533d448R51 |
| 23:39:35 | reactormonk | getting that stuff over to threads is rather hairy. |
| 23:43:52 | reactormonk | Araq, so a) use threads in the dll - need to move iteration into dll to generate enough data. status() isn't enough data, so I'll have to delete that b) use threads via threadpool in the main.nim only, not c, to call the DLL with threads. Rather easy, can still do all tests, but no threading from C. |
| 23:44:05 | reactormonk | I'd prefer b), because less work and probably more data |
| 23:44:38 | Araq | hack it, leave it out, do something to stay productive. almost any test is better than no test. |
| 23:45:46 | reactormonk | kk |
| 23:47:38 | * | johnsoft quit (Ping timeout: 272 seconds) |
| 23:48:02 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 23:52:01 | * | johnsoft joined #nim |
| 23:52:40 | * | elbow_jason quit (Remote host closed the connection) |
| 23:55:00 | reactormonk | segfault :-/ |
| 23:56:52 | * | Varriount_ is now known as Varriount |
| 23:58:47 | reactormonk | might just be because the shared lib has shared state, but I don't really care if that's mangled up |
| 23:59:43 | * | wb quit (Ping timeout: 256 seconds) |