| 00:00:17 | ldlework | and all you really want to do is distinguish between the rare (right, this *is* rare?) case when you have two generic procs named the same thing, with the same exact method utilization internally? |
| 00:00:19 | * | francisl joined #nim |
| 00:00:50 | gmpreussner | yeah, maybe. perhaps i am thinking too much static typing. |
| 00:01:01 | ldlework | Well |
| 00:01:15 | ldlework | If Nim did not derrive automatic typeclasses from implementations, you would want concepts |
| 00:01:32 | ldlework | so you could say, "Hey T has a .whatever so compile this function that does t.whatever()" |
| 00:01:41 | ldlework | But it already does all of that automatically.... |
| 00:02:12 | ldlework | But maybe there is some other clever way to lean on the automatic typeclasses while also being able to disambiguate between overloaded procs |
| 00:02:22 | Araq | ldlework: well 'concept' enables us to eventually perform real type checking in the generic, rather than its instantiation. |
| 00:02:50 | ldlework | Hmm, I can't quite fully grasp what that means |
| 00:03:08 | Araq | which would be cool too but is reserved for Nim v2 |
| 00:04:28 | ldlework | this automatic typeclass thing is kind of like "compile-time ducktyping" |
| 00:04:47 | Araq | ldlework: yes. and it has its downsides. |
| 00:05:04 | ldlework | Its like, "sure I'll expand this generic proc out for this type, lets first see if it would work. Oh it would, bam, new impleentation for that type." |
| 00:06:44 | ldlework | Araq: but is disambiguation between similar procs the only thing? |
| 00:07:20 | ldlework | What if there is a silly novel way to specify which one you mean or some other way to disambiguate that no one has ever thought of before because they did not have this feature |
| 00:07:28 | ldlework | Also is Nim the only language with this or is it typical? |
| 00:08:34 | ldlework | That guy who was in here earlier who was working with Irdis and haskel was totally surprised that Nim did this |
| 00:08:52 | Araq | ldlework: it's this way in C++ too |
| 00:09:27 | Araq | and it was chosen for implementation simplicity (misguided) and "duck typing similar to Python" (true) |
| 00:09:30 | * | PMunch quit (Ping timeout: 246 seconds) |
| 00:09:39 | * | mahasamoot quit (Ping timeout: 248 seconds) |
| 00:10:59 | Araq | type theorists see it as a step in the wrong direction though. |
| 00:11:16 | Araq | ;-) |
| 00:12:13 | ldlework | I just wonder if there is a way to disambiguate. It seems like the concept is a round about way of avoiding overloading a process name |
| 00:12:17 | ldlework | Proc |
| 00:12:49 | ldlework | Instead of just renaming the proc you create this whole construct just to differentiate them |
| 00:13:20 | ldlework | But I suppose it's more general than that because it then disambiguate for all such ambiguities |
| 00:13:23 | ldlework | Hmm |
| 00:13:54 | gmpreussner | Araq: lol, i read 'type terrorists' at first |
| 00:14:08 | gmpreussner | and was like 'yep, that's me' |
| 00:14:13 | ldlework | Haha |
| 00:14:50 | ldlework | gmpreussner what do you think about exceptions |
| 00:15:36 | Araq | dom96: speaking of which, can we remove the "exception hierarchy"? |
| 00:15:59 | dom96 | why would we? |
| 00:15:59 | ldlework | Wat |
| 00:16:05 | Araq | throws vs doesn't throw should be good enough for everybody... |
| 00:16:24 | ldlework | It's about capturing classes of exceptions |
| 00:16:28 | dom96 | I disagree |
| 00:16:33 | ldlework | Right? |
| 00:16:46 | dom96 | so, no you can't :P |
| 00:16:52 | dom96 | </discussion> |
| 00:16:56 | ldlework | Lol |
| 00:17:17 | Araq | I can write a guard on the error code if I care somewhat more about the error and re-raise |
| 00:17:35 | Araq | which is what the implementation does under the hood... |
| 00:17:56 | gmpreussner | ldlework: i don't know... that's a complicated topic. some days i think they're useful. other days i think that anything that can't be caught by the compiler should be properly handled in the calling code, i.e. with optional return types, or tuples that can contain errors |
| 00:18:15 | Araq | and then we have a single exception object type and don't need inheritance nor 'ref object' nor the GC :-) |
| 00:19:28 | ldlework | Araq: is this your "control flow typing"? |
| 00:19:33 | * | derka quit (Ping timeout: 276 seconds) |
| 00:19:40 | Araq | ldlework: no, it has nothing to do with it. |
| 00:19:58 | ldlework | I thought that's what you meant by "guard on the error code" |
| 00:20:04 | ldlework | but I just realize you said "error code" |
| 00:20:06 | * | ldlework shudders |
| 00:20:48 | Araq | ldlework: shudder as much as you want but the fact is that OSError contains the errno for further inspection |
| 00:20:57 | * | Trustable quit (Quit: Leaving) |
| 00:21:03 | ldlework | Sure because someone is too lazy to expand that out to types |
| 00:21:03 | * | francisl quit (Quit: francisl) |
| 00:21:26 | ldlework | Also types are allowed to carry data |
| 00:21:51 | Araq | well 'too lazy' here equals 'omg, stop this proliferation of exception types!' |
| 00:22:13 | ldlework | Why? Do they have weight? |
| 00:22:31 | Araq | they cause mental diseases |
| 00:22:56 | ldlework | Dunno why. We use the type system for distinguishing between types of data everywhere else. |
| 00:23:29 | Araq | I never turn an enum into an inheritance tree. |
| 00:23:39 | Araq | so much for "everywhere else" :P |
| 00:23:39 | ldlework | Well I agree with that point |
| 00:23:50 | ldlework | Perhaps an expanded OSError tree would have no fields of their own |
| 00:23:56 | ldlework | Which is why they are an enum |
| 00:24:30 | ldlework | If the difference between one OSError num and another carried disjoint additional data, you'd have no choice. |
| 00:24:43 | ldlework | But there is nothing inherently wrong with using the type system for mere distinguishing causes |
| 00:24:48 | ldlework | That's what distinct types are for. |
| 00:25:25 | ldlework | object variants one step removed from the pure distinguishing case |
| 00:25:55 | Araq | either way. I have to think about 'concept'. |
| 00:26:05 | ldlework | yeah its really fascinating subject :) |
| 00:26:50 | Araq | proc foo[T](x, y: T) = |
| 00:26:51 | Araq | for i in x: |
| 00:26:51 | Araq | echo i |
| 00:26:53 | Araq | echo x+y |
| 00:26:54 | Araq | proc p(x: foo[T]) = |
| 00:26:56 | Araq | foo(x) |
| 00:27:08 | Araq | --> just use the proc as a container type? |
| 00:27:24 | Araq | if it can be instantiated, it type checks. |
| 00:27:37 | Araq | no new syntax. no new surprises. |
| 00:27:46 | Araq | 3 lines of code in the compiler. |
| 00:27:54 | Araq | (*cough*) |
| 00:28:17 | ldlework | this is your idea for predicates? |
| 00:28:22 | Araq | yes. |
| 00:28:26 | ldlework | its really cool |
| 00:28:31 | ldlework | And I think people really eat up the idea |
| 00:28:50 | ldlework | have you noticed that I routinely will omit one word from each sentence I type |
| 00:29:00 | ldlework | its very strange and I only perceive it after the fact |
| 00:30:09 | * | boopsiesisaway quit (Ping timeout: 246 seconds) |
| 00:30:37 | dom96 | you type too fast :) |
| 00:30:45 | gmpreussner | happens to me all the time, too! |
| 00:30:54 | gmpreussner | thank god i'm not alone. i thought i'm getting alzheimer |
| 00:31:03 | ldlework | Araq: heh would this be a "type predicate alias": proc bar[T](x, y: T) = foo(x, y) |
| 00:31:26 | ldlework | a distinct alias I guess |
| 00:33:06 | Araq | this is so beautiful it has to be right. |
| 00:33:35 | Araq | it fits 100% syntactically. |
| 00:35:07 | * | dom96 wonders what that code does |
| 00:36:03 | gmpreussner | the lord's ways are mysterious |
| 00:36:50 | * | pregressive joined #nim |
| 00:38:47 | Araq | dom96: it turns a generic proc into a generic type predicate |
| 00:39:53 | dom96 | Araq: hrm, maybe i'll understand it in the morning. Good night. |
| 00:41:06 | def- | Araq: I still don't understand where the y parameter to foo comes from |
| 00:41:36 | ldlework | def-: good point |
| 00:41:47 | ldlework | I don't think it should change the nature of foo |
| 00:41:56 | ldlework | if its going to be elegant you should just be able to use any ol proc this way |
| 00:42:00 | ldlework | and still call the proc as normal |
| 00:42:20 | ldlework | I don't want to look at a function and not know whether it is a proc or a predicate |
| 00:43:03 | Araq | def-: that's a typo, in the implementation I need to pass two things to foo |
| 00:43:15 | * | boopsiesisaway joined #nim |
| 00:43:52 | ldlework | wait |
| 00:43:58 | ldlework | do you have to call foo in the implementation |
| 00:44:04 | ldlework | or could you call something totally different |
| 00:44:05 | Araq | no. |
| 00:44:08 | Araq | yes. |
| 00:44:29 | ldlework | okay so foo does not appear in the implementation |
| 00:44:33 | Araq | usually you would just have some dummy implementation that checks the constraints you're after |
| 00:44:40 | ldlework | so how does the compiler know that x param of p is the x param of foo |
| 00:45:02 | ldlework | from just p(x: foo[T]) |
| 00:45:13 | Araq | ldlework: it doesn't matter. either [T] suffices to instantiate it or not. |
| 00:45:35 | Araq | and the type T is inferred like it would be for seq[T] |
| 00:45:51 | Araq | which could be a problem ... hmmm |
| 00:46:05 | ldlework | What if it was proc foo[T](x: T, y: int) |
| 00:46:14 | ldlework | or even |
| 00:46:29 | ldlework | well no that's enough |
| 00:46:43 | Araq | why should 'y: int' cause any problems? |
| 00:46:51 | ldlework | because what if I'm passing an int to p? |
| 00:48:09 | ldlework | I think this has the same ambiguity problem, but you moved it. |
| 00:51:07 | * | GangstaCat quit (Read error: Connection reset by peer) |
| 00:51:49 | Araq | hmm I don't understand concepts :-) |
| 00:53:00 | * | GangstaCat joined #nim |
| 00:53:13 | Araq | how does it know that seq[T] is a Container[T]. |
| 00:53:37 | * | mahasamoot joined #nim |
| 00:54:18 | ldlework | Because you pass one to a process expecting a Container and then the compiler checks the type against the concept |
| 00:54:27 | Araq | it doesn't resolve the T properly at all currently, I think |
| 00:54:27 | ldlework | Proc |
| 00:54:56 | Araq | array[I, T] should match Container[T] |
| 00:55:10 | Araq | but here T is the 2nd type parameter of 'array' not the first. |
| 00:55:20 | ldlework | Why should it match |
| 00:55:42 | gmpreussner | doesn't need to be the same T |
| 00:55:54 | gmpreussner | could be array[X, Y] and should still match |
| 00:56:11 | Araq | gmpreussner: nevertheless I need to infer the T in |
| 00:56:21 | gmpreussner | right, locally inside the concept |
| 00:56:21 | Araq | proc foo[T](x: Container[T]) |
| 00:56:29 | gmpreussner | or your proc in this case |
| 00:56:43 | Araq | that's the core of the problem, perhaps. |
| 00:56:47 | gmpreussner | in concepts it works, because T becomes 'match any' in that case |
| 00:56:50 | Araq | that's not implemented at all :P |
| 00:57:08 | gmpreussner | that's what zah said anyway |
| 00:57:21 | Araq | seems like we need him here. |
| 00:57:39 | Araq | but he's offline. |
| 00:57:46 | ldlework | we should like |
| 00:57:47 | gmpreussner | it's in the middle of the night there |
| 00:57:52 | ldlework | create a Nim design lab |
| 00:57:56 | ldlework | and advertise these ideas |
| 00:58:01 | ldlework | in order to attract compiler hackers |
| 00:58:05 | ldlework | so that you can get some help |
| 00:58:08 | ldlework | serious suggestion |
| 00:58:26 | * | derka joined #nim |
| 00:59:30 | ldlework | Nim Enhancement Proposal #1 |
| 00:59:31 | Araq | well either way, my idea seems to have the same problems as 'concept' except it's easier for me to conceptualize (yay, bad puns) |
| 00:59:43 | gmpreussner | haha |
| 00:59:49 | ldlework | well done |
| 01:04:08 | * | darkf joined #nim |
| 01:24:46 | * | derka quit (Ping timeout: 248 seconds) |
| 01:30:31 | gmpreussner | ldlework: on the way home i thought some more about just using generic procs. i think that in principle you're right; we wouldn't need concepts at all. but one problem with that is that the constraints for what types are allowed are implicitly defined in the implementations of the algorithms, and might be spread out over a potentially very large surface of code |
| 01:33:27 | * | francisl joined #nim |
| 01:37:43 | * | brson quit (Ping timeout: 252 seconds) |
| 01:49:46 | * | AnonCat joined #nim |
| 01:50:00 | * | GangstaCat quit (Ping timeout: 250 seconds) |
| 01:50:24 | * | AnonCat is now known as GangstaCat |
| 01:58:07 | * | samdoran joined #nim |
| 02:00:29 | * | mahasamoot quit (Ping timeout: 248 seconds) |
| 02:12:55 | * | sarlalian quit (Ping timeout: 252 seconds) |
| 02:16:16 | * | sarlalian joined #nim |
| 02:24:06 | * | mahasamoot joined #nim |
| 02:51:00 | * | sorakun quit (Ping timeout: 276 seconds) |
| 03:03:15 | * | pregressive quit (Remote host closed the connection) |
| 03:05:02 | * | pregressive joined #nim |
| 03:17:48 | * | filwit quit (Quit: Leaving) |
| 03:38:22 | * | Kingsquee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
| 03:38:26 | * | Kingsqueee joined #nim |
| 03:54:01 | * | girvo joined #nim |
| 04:25:47 | * | endragor joined #nim |
| 04:34:32 | * | Demon_Fox joined #nim |
| 04:50:08 | * | sarlalian quit (Quit: ZNC 1.6.1 - http://znc.in) |
| 04:50:58 | * | pregressive quit (Remote host closed the connection) |
| 04:52:22 | * | sarlalia1 quit (Quit: WeeChat 0.4.2) |
| 04:55:49 | * | sarlalian joined #nim |
| 04:55:50 | * | sarlalia1 joined #nim |
| 04:56:41 | * | sarlalia1 quit (Client Quit) |
| 05:17:54 | * | Varriount joined #nim |
| 05:20:03 | Varriount | Araq: https://github.com/nim-lang/nimsuggest |
| 05:20:14 | Varriount | There's a new pull request |
| 05:20:54 | * | CORDEA joined #nim |
| 05:23:15 | * | gunn joined #nim |
| 05:25:50 | * | gunn_ quit (Ping timeout: 248 seconds) |
| 05:40:47 | * | mwbrown joined #nim |
| 05:56:27 | * | mwbrown quit (Quit: Leaving) |
| 06:07:49 | * | francisl quit (Quit: francisl) |
| 06:15:26 | * | zepolen joined #nim |
| 06:17:05 | * | endragor_ joined #nim |
| 06:19:48 | * | zepolen quit (Ping timeout: 246 seconds) |
| 06:20:22 | * | endragor quit (Ping timeout: 260 seconds) |
| 06:36:27 | * | francisl joined #nim |
| 06:39:40 | * | endragor_ quit (Remote host closed the connection) |
| 06:40:09 | * | endragor joined #nim |
| 06:42:42 | * | francisl quit (Quit: francisl) |
| 06:48:57 | * | bjz joined #nim |
| 06:50:44 | * | samdoran quit (Ping timeout: 252 seconds) |
| 06:54:55 | * | girvo quit (Read error: Connection reset by peer) |
| 06:56:18 | * | girvo joined #nim |
| 06:57:16 | * | toaoMgeorge quit (Ping timeout: 252 seconds) |
| 07:11:11 | * | endragor quit (Remote host closed the connection) |
| 07:24:14 | * | bjz_ joined #nim |
| 07:25:07 | * | bjz quit (Ping timeout: 260 seconds) |
| 07:26:52 | * | Kingsqueee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
| 07:33:15 | cheatfate | what the best way to define() for 64 bit platforms? |
| 07:36:45 | Varriount | cheatfate: I believe that there is a defined symbol for x64 platforms |
| 07:42:39 | cheatfate | only variant i have found is "when sizeof(int) == 8" and even dont know is result is known in compile time |
| 07:42:42 | Varriount | cheatfate: Try "when defined(amd64)" |
| 07:43:19 | * | bjz joined #nim |
| 07:44:12 | * | sarlalia1 joined #nim |
| 07:44:13 | cheatfate | amd64 is only x86, what happens if somebody tries to compile on [arm64], or [powerpc64] |
| 07:44:33 | Varriount | cheatfate: Then you need to add handlers for those cases? |
| 07:44:40 | * | sarlalia1 quit (Client Quit) |
| 07:44:46 | Varriount | cheatfate: What are you trying to do? |
| 07:44:49 | * | bjz_ quit (Read error: Connection reset by peer) |
| 07:45:04 | * | sarlalia1 joined #nim |
| 07:45:11 | * | zepolen joined #nim |
| 07:46:37 | cheatfate | please look lib/sys/kqueue.nim, there is KEvent structure where ident*: cuint and data*: cuint |
| 07:47:22 | Varriount | cheatfate: Are those incorrect? |
| 07:47:23 | cheatfate | but on 64bit systems size of (uintptr_t and intptr_t is 64 bits) |
| 07:47:27 | cheatfate | yep |
| 07:47:31 | cheatfate | its incorrect |
| 07:47:45 | Varriount | cheatfate: Use the int or pointer type then. |
| 07:47:49 | cheatfate | i dont know how sizeof(KEvent) is still 32 bytes may be kind of alignment |
| 07:48:57 | cheatfate | we cant patch kqueue.nim in such way because other code will be broken... i think compile define would be better solution |
| 07:49:45 | Varriount | cheatfate: That's really just plastering over the problem. Besides, the only code that is likely to be using the bare kqueue stuff is the async stuff in the standard library. |
| 07:50:23 | cheatfate | kqueue.nim used by selectors.nim used by async staff |
| 07:50:26 | Varriount | cheatfate: Besides, code that's using the kqueue is currently broken because of this anyway. |
| 07:50:45 | cheatfate | Varriount, its working... for some reason |
| 07:51:02 | cheatfate | i think because of alignment structure members by c compiler |
| 07:51:06 | Varriount | cheatfate: Yes, but only by accident. |
| 07:52:11 | Varriount | Again, I'd change the types to either `int`, `pointer`, `ptr cuint` or `ptr cint` |
| 07:52:52 | Varriount | The last two sound close to the original type definition. |
| 07:53:34 | * | girvo quit (Ping timeout: 250 seconds) |
| 07:53:46 | * | filcuc joined #nim |
| 07:54:34 | * | endragor joined #nim |
| 07:58:28 | * | zepolen quit (Remote host closed the connection) |
| 07:59:06 | cheatfate | in original this types looks like this https://gist.github.com/cheatfate/0c9e421bcd3b882daefb |
| 07:59:21 | * | zepolen joined #nim |
| 08:02:50 | Varriount | cheatfate: __uintfptr_t ? |
| 08:03:01 | Varriount | Is that a typo? |
| 08:04:21 | cheatfate | sorry not __uintfptr_t but __uintptr_t |
| 08:04:50 | * | endragor quit (Remote host closed the connection) |
| 08:06:28 | cheatfate | https://gist.github.com/cheatfate/418d8a21e8f0e653edf6 this is full version no my faulty extraction |
| 08:07:00 | * | CORDEA quit (Ping timeout: 252 seconds) |
| 08:08:00 | Varriount | Based of of that and the original man page, I'd make the ident member a uint, and the data member an int |
| 08:08:43 | Varriount | The data member seems to be used far more as a number than as a pointer to something. |
| 08:09:00 | cheatfate | yeah, looks like the most easy way to patch kqueue.nim |
| 08:11:44 | cheatfate | ouch, Varriount NimLime is your product! I have a small problem |
| 08:12:27 | cheatfate | i have a sublime text2 and when i'm starting new .nim file i have always problems with tabs |
| 08:12:46 | cheatfate | is it sublime text2 problem? or i need to add something to settings? |
| 08:13:46 | cheatfate | my first tabs in this file, become tabs not 2spaces |
| 08:14:16 | * | mahasamoot quit (Ping timeout: 252 seconds) |
| 08:18:22 | * | yglukhov joined #nim |
| 08:23:55 | * | endragor joined #nim |
| 08:27:06 | * | zepolen quit (Remote host closed the connection) |
| 08:33:23 | * | Trustable joined #nim |
| 08:53:38 | * | Demon_Fox quit (Quit: Leaving) |
| 08:53:55 | vegansk | Araq, hi! Please review https://github.com/nim-lang/Nim/pull/3921 |
| 08:54:19 | vegansk | Araq, It's about TLS problems with MinGW |
| 08:56:14 | Araq | Varriount: I don't like it ... I argued in the past this way of extensibility is against the point of Nim's "compiler as an API" idea |
| 08:56:44 | Araq | I will accept it eventually since you are keen on doing it this way. |
| 08:56:59 | Araq | vegansk: I love you :D |
| 08:57:09 | Araq | how did you find this? |
| 09:12:27 | vegansk | Araq, it was cool! First of all, I created similar test that uses threadvar. And stacktrace becomes more clear. And then I examined c sources and then *BINGO*! :-) |
| 09:13:34 | Araq | why does GCC allow __declspec(thread) and miscompiles it? after all these years. pretty sure it affects all GCC versions. |
| 09:16:16 | vegansk | Araq, good question. Need to look deeper |
| 09:21:57 | vegansk | Araq, here is the mention: https://bugs.freedesktop.org/show_bug.cgi?id=57591. "gcc ignores __declspec(thread) but does not throw an error". |
| 09:39:49 | * | endragor quit (Remote host closed the connection) |
| 09:57:51 | * | endragor joined #nim |
| 09:59:21 | * | darkf quit (Ping timeout: 276 seconds) |
| 09:59:26 | * | endragor quit (Read error: Connection reset by peer) |
| 09:59:56 | * | endragor joined #nim |
| 10:02:11 | * | endragor quit (Read error: Connection reset by peer) |
| 10:02:17 | * | endragor_ joined #nim |
| 10:03:14 | * | endragor_ quit (Read error: Connection reset by peer) |
| 10:03:20 | * | endragor joined #nim |
| 10:04:38 | * | darkf joined #nim |
| 10:08:27 | * | endragor quit (Ping timeout: 276 seconds) |
| 10:09:48 | * | endragor joined #nim |
| 10:10:07 | * | endragor quit (Read error: Connection reset by peer) |
| 10:10:19 | * | endragor joined #nim |
| 10:12:14 | cheatfate | how properly define C's "void*" in nim? with "pointer" or "ptr void"? |
| 10:13:22 | Araq | "pointer" |
| 10:13:36 | * | zepolen joined #nim |
| 10:15:31 | cheatfate | thank you |
| 10:15:31 | * | zepolen quit (Read error: Connection reset by peer) |
| 10:16:52 | cheatfate | just found commented "ptr void" in posix/kqueue.nim, enabled it and got an exception when trying to compile |
| 10:18:14 | Araq | cheatfate: c2nim translates void* to pointer |
| 10:19:31 | Araq | and usually c2nim is like GLaDOS |
| 10:21:06 | cheatfate | :) |
| 10:21:11 | * | Salewski joined #nim |
| 10:21:48 | * | darkf_ joined #nim |
| 10:23:48 | * | M-Quora quit (Quit: node-irc says goodbye) |
| 10:24:19 | Salewski | Araq, you just mentioned c2nim. In https://github.com/Araq/wxnim/blob/master/private/spinbutt.nim we have template wxSpinEventHandler and template evt_Spin_Up # why some template names with _ and some without? I think that is nep1 |
| 10:26:00 | * | darkf quit (Ping timeout: 276 seconds) |
| 10:27:41 | Araq | Salewski: good question, maybe https://github.com/Araq/wxnim/blob/master/headers/wx.c2nim contains the answer |
| 10:27:50 | Araq | but it doesn't look like it |
| 10:29:26 | * | girvo joined #nim |
| 10:30:55 | Salewski | c2nim --nep1 gives me currently template names with _, as in template is_Application_Window. Question is if I should delete the _, that is why I looked at your wxWidgets... |
| 10:31:49 | * | darkf_ quit (Remote host closed the connection) |
| 10:32:32 | Araq | usually I'm in favor of this yes. maybe c2nim --nep1 ignores templates. fix it. |
| 10:32:53 | * | darkf_ joined #nim |
| 10:33:06 | Salewski | OK, thanks. |
| 10:33:26 | * | Salewski quit () |
| 10:37:06 | * | darkf_ is now known as darkf |
| 10:38:56 | * | toaoMgeorge joined #nim |
| 10:42:15 | * | darkf quit (Ping timeout: 276 seconds) |
| 10:56:23 | * | darkf joined #nim |
| 11:35:11 | * | filwit joined #nim |
| 11:35:13 | * | PMunch joined #nim |
| 11:36:30 | * | boopsiesisaway quit (Ping timeout: 248 seconds) |
| 11:50:15 | * | boopsiesisaway joined #nim |
| 11:51:35 | vegansk | Hey, http://nim-lang.org/docs/c2nim.html produces error 404! |
| 11:55:55 | * | toaoMgeorge quit (Ping timeout: 252 seconds) |
| 11:56:39 | * | toaoMgeorge joined #nim |
| 11:58:32 | federico3 | and http://nim-lang.org/docs/ looks broken |
| 12:05:53 | * | arnetheduck joined #nim |
| 12:07:00 | * | arnetheduck quit (Remote host closed the connection) |
| 12:09:07 | * | arnetheduck joined #nim |
| 12:23:16 | * | Varriount quit (Read error: Connection reset by peer) |
| 12:23:56 | * | endragor quit (Remote host closed the connection) |
| 12:25:16 | Araq | http://nim-lang.org/documentation.html looks fine |
| 12:30:09 | * | toaoMgeorge quit (Ping timeout: 276 seconds) |
| 12:30:19 | * | toaoMgeorge joined #nim |
| 12:40:11 | * | zepolen joined #nim |
| 12:59:15 | * | endragor joined #nim |
| 13:27:57 | * | toaoMgeorge quit (Ping timeout: 260 seconds) |
| 13:28:24 | * | toaoMgeorge joined #nim |
| 13:47:19 | * | darkf_ joined #nim |
| 13:47:47 | * | lxdong quit (Quit: Page closed) |
| 13:51:24 | * | darkf quit (Ping timeout: 276 seconds) |
| 14:04:10 | yglukhov | question. i've got a proc performOnMainThread*(fun: proc(data: pointer) {.cdecl.}, data: pointer). When i call this proc with a global {.cdecl.} proc which is "not gc-safe", i get a compiler error about gcsafety. is there a common solution to this? |
| 14:04:58 | * | darkf_ is now known as darkf |
| 14:08:36 | yglukhov | can i somehow say that performOnMainThread accepts a not-necessarily gcsafe proc? |
| 14:08:56 | * | cheatfate quit (Read error: Connection reset by peer) |
| 14:13:50 | * | cheatfate_ joined #nim |
| 14:14:36 | * | cheatfate_ is now known as cheatfate |
| 14:32:21 | * | toaoMgeorge quit (Read error: Connection reset by peer) |
| 14:37:42 | Araq | yglukhov: good question. There is ".gcunsafe" as that's the default |
| 14:37:46 | Araq | *there is no |
| 14:38:15 | Araq | so ... I am not sure what the problem is |
| 14:40:23 | yglukhov | ok, my current workaround is to cast global proc to pointer. then cast pointer back to {.cdecl, gcsafe.}. seems to work |
| 14:44:40 | Araq | casting is supported workaround indeed but it doesn't seem to be necessary for the situation you described |
| 15:04:25 | * | pregressive joined #nim |
| 15:05:04 | * | pregressive quit (Remote host closed the connection) |
| 15:06:43 | * | endragor quit (Ping timeout: 248 seconds) |
| 15:22:10 | * | mwbrown joined #nim |
| 15:23:29 | mwbrown | Got a question for you guys (mostly directed at Araq or anyone who has tried to do this): |
| 15:24:04 | mwbrown | Does Nim support interop with C volatile pointers? I saw an issue report on github that said using {. volatile .} just marks the variable itself as volatile and not what it points to (in the pointer case) |
| 15:24:25 | mwbrown | or rather pointers to volatile data |
| 15:25:01 | mwbrown | I'm trying to get back into doing some development on an STMicro ARM Cortex-M3 and I've got the build system up and linking with some supporting C code, but I want to be able to do the actual volatile load/store from Nim |
| 15:31:16 | yglukhov | mwbrown: can't say about volatiles in nim, but you can always use {.emit.} and do whatever you want in C. |
| 15:32:13 | mwbrown | Yeah, I vaguely remember seeing a workaround like that in the github issue |
| 15:32:38 | yglukhov | Araq: i'm playing with pinnedSpawn, and it seems like it's blocking a lot. is there a simple answer? |
| 15:32:58 | mwbrown | yglukhov: oh hey, I just noticed you were the one who posted that workaround, haha |
| 15:33:12 | mwbrown | https://github.com/nim-lang/Nim/issues/3382 |
| 15:34:26 | yglukhov | :) yeah, but then you can go further and implement volatileLoad/Store routines in the same way. maybe even contribute them to stdlib then ;) |
| 15:38:07 | * | filwit quit (Quit: Leaving) |
| 15:49:47 | Araq | yglukhov: depends on what you mean by "blocking" |
| 15:54:03 | yglukhov | well, its almost "synchronized" with tasks i spawn. i spawn a lot of tasks, every one may take around 0.25 seconds. and every pinnedSpawn hangs for about the same time |
| 15:54:36 | * | pregressive joined #nim |
| 15:55:16 | * | mwbrown quit (Remote host closed the connection) |
| 15:55:45 | * | mwbrown joined #nim |
| 15:57:20 | yglukhov | Araq: in threadpool.nim: await(distinguishedData[id].readyForTask). Does it mean that threads do not have a queue? |
| 15:58:28 | yglukhov | and spawn will wait until previous task completes? |
| 15:58:38 | yglukhov | that would explain my observations... |
| 16:11:40 | mwbrown | In a template, is it possible to convert an argument of type 'stmt' to a string? |
| 16:11:53 | mwbrown | Kind of like in C how you can stringify macro arguments |
| 16:13:32 | * | zielmicha_ joined #nim |
| 16:15:33 | * | zielmicha quit (Ping timeout: 264 seconds) |
| 16:15:33 | * | mal`` quit (Ping timeout: 264 seconds) |
| 16:15:36 | * | zielmicha_ is now known as zielmicha |
| 16:16:13 | * | mal`` joined #nim |
| 16:16:22 | yglukhov | mwbrown: astToStr or smth |
| 16:17:41 | yglukhov | Araq: i think syscond is incorrect in windows. because they are not safe in wait. this should be used instead: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682052(v=vs.85).aspx |
| 16:26:30 | * | brson joined #nim |
| 16:29:13 | * | Jesin quit (Remote host closed the connection) |
| 16:43:57 | * | bozaloshtsh quit (Ping timeout: 260 seconds) |
| 16:44:33 | * | vendethiel joined #nim |
| 16:45:36 | * | vendethiel- quit (Ping timeout: 246 seconds) |
| 16:56:30 | * | endragor joined #nim |
| 17:03:06 | * | filcuc quit (Read error: Connection reset by peer) |
| 17:03:10 | * | darkf quit (Quit: Leaving) |
| 17:16:45 | * | yglukhov quit (Ping timeout: 248 seconds) |
| 17:27:27 | * | nero7 joined #nim |
| 17:27:52 | * | nero7 left #nim (#nim) |
| 17:28:13 | * | UberLambda joined #nim |
| 17:31:33 | * | cheatfate quit (Read error: Connection reset by peer) |
| 17:32:10 | * | cheatfate joined #nim |
| 17:36:02 | ldlework | gmpreussner: I agree that it is annoying to have to inspect an implementation to know what a type needs in order to be passed to it |
| 17:36:45 | ldlework | gmpreussner: I wonder if you could generate reports or use an IDE to compile requirement reports for types based on generic implementations |
| 17:41:37 | * | mahasamoot joined #nim |
| 17:57:30 | * | yglukhov joined #nim |
| 17:58:24 | * | yglukhov quit (Remote host closed the connection) |
| 17:58:36 | * | yglukhov joined #nim |
| 18:05:19 | * | sorakun joined #nim |
| 18:07:39 | * | Sys_ joined #nim |
| 18:14:19 | * | bozaloshtsh joined #nim |
| 18:25:02 | * | arnetheduck quit (Remote host closed the connection) |
| 18:26:08 | * | endragor quit (Remote host closed the connection) |
| 18:30:09 | * | mahasamoot quit (Ping timeout: 250 seconds) |
| 18:40:40 | * | zepolen quit (Remote host closed the connection) |
| 18:42:30 | * | yglukhov quit (Remote host closed the connection) |
| 18:43:47 | * | zepolen joined #nim |
| 18:49:16 | * | mahasamoot joined #nim |
| 18:54:49 | gmpreussner | ldlework: and another problem with implicitly defining types via the usages of their interfaces is problematic is that conceptually completely different types may implement procs with the same names and (generic) argument lists, but do completely different things. just because X.foo and Y.foo match it doesn't mean that X and Y are in any way semantically related, or that the foo's do similar things. one would have to have globally unique |
| 18:54:49 | gmpreussner | (and i literally mean 'globally', and therefore quite verbose) proc names for this to work |
| 18:55:14 | gmpreussner | one could argue that if the names and signatures match, then it doesn't matter what the functions do, and they could be assumed to be related |
| 18:55:16 | * | PMunch quit (Ping timeout: 250 seconds) |
| 18:55:21 | gmpreussner | but in practice that is rarely the case |
| 18:55:48 | gmpreussner | it might work for things like len() and max(), but in many other cases it won't |
| 18:56:02 | ldlework | gmpreussner: So in conclusion I think that while Concepts are not technically required, they are an extremely valuable abstraction. |
| 18:56:09 | gmpreussner | so you're right in that concepts are mainly a naming device |
| 18:56:29 | ldlework | And I think that they are even more useful than naked predicates since we disocvered those too lack the named disambiguator |
| 18:56:38 | ldlework | (since the ambiguity is moved to equivalent parameter lists) |
| 18:57:06 | gmpreussner | i'm not sure about that. i'd have to see predicates in action. i'm intruiged by the possibility of composing them. |
| 18:57:13 | gmpreussner | you can't really do that with concepts, i think |
| 18:57:37 | ldlework | They compose nicely, but Araq and I contemplated it yesterday and you can't disambiguate between parameters |
| 18:57:45 | ldlework | imagine a predicate that takes (T, int) |
| 18:58:02 | ldlework | And you want to pass an int to a generic function who's generic parameter is guarded with this predicate |
| 18:58:10 | ldlework | And you want to pass an int /as the generic parameter/ |
| 18:58:20 | ldlework | The same ambiguity exists but is moved to a different place. |
| 18:58:48 | ldlework | It wont conceptualize to you as the same ambiguity since a parameter is so different conceptually but if you contemplate it for a few minutes you will realize. |
| 19:01:04 | gmpreussner | well, Araq messaged me earlier that he found the final solution to the concept question (TM) |
| 19:01:13 | gmpreussner | he didn't say yet what it is, but i'm hopeful :) |
| 19:01:59 | ldlework | gmpreussner: which concept question |
| 19:02:08 | ldlework | oh he didn't say what the question was or the solution? |
| 19:02:22 | gmpreussner | right :) |
| 19:02:22 | * | sarlalia1 quit (Quit: WeeChat 0.4.2) |
| 19:03:27 | * | sarlalia1 joined #nim |
| 19:11:11 | * | pregressive quit (Remote host closed the connection) |
| 19:11:27 | * | pregressive joined #nim |
| 19:14:46 | * | bozaloshtsh quit (Ping timeout: 244 seconds) |
| 19:16:00 | * | Jesin joined #nim |
| 19:18:06 | * | sarlalia1 left #nim ("WeeChat 0.4.2") |
| 19:21:27 | * | samdoran joined #nim |
| 19:22:21 | * | bozaloshtsh joined #nim |
| 19:22:45 | * | zepolen quit (Remote host closed the connection) |
| 19:25:42 | * | samdoran quit (Ping timeout: 252 seconds) |
| 19:26:35 | * | yglukhov joined #nim |
| 19:26:36 | * | yglukhov quit (Remote host closed the connection) |
| 19:29:46 | * | sorakun quit (Remote host closed the connection) |
| 19:32:39 | * | boopsiesisaway is now known as boopsies |
| 19:33:17 | * | mahasamoot_ joined #nim |
| 19:33:31 | * | mahasamoot quit (Ping timeout: 252 seconds) |
| 19:41:05 | * | Gonzih joined #nim |
| 19:42:10 | * | Matthias247 joined #nim |
| 19:48:15 | * | yglukhov joined #nim |
| 19:53:41 | * | yglukhov quit (Remote host closed the connection) |
| 20:13:40 | * | brson quit (Ping timeout: 244 seconds) |
| 20:19:32 | * | mat4 joined #nim |
| 20:19:34 | mat4 | hello |
| 20:19:46 | ldlework | hi mat4 |
| 20:19:59 | mat4 | hi ldlework |
| 20:24:27 | mat4 | I'm surprised to read in the logs that Nim will implement 'duck typing' (or this is discussed) |
| 20:25:05 | * | UberLambda quit (Quit: GTG) |
| 20:25:12 | ldlework | mat4: it already /does/ |
| 20:25:13 | ldlework | :) |
| 20:27:01 | * | PMunch joined #nim |
| 20:27:47 | mat4 | nice, where can I found related documentation about the needed interface concept ? |
| 20:28:20 | ldlework | mat4: "needed interface concept" ? |
| 20:28:34 | ldlework | mat4: but do you understand why Nim is already duck-typed? |
| 20:32:49 | mat4 | I guess because Nim support method overloading in combination with some support for parametric polymorphism ? |
| 20:33:27 | * | sora joined #nim |
| 20:33:27 | ldlework | mat4: no because the typeclass of T in a generic function is automatically derived if none is specified. |
| 20:35:19 | ldlework | mat4: that means, whether or not you can pass a given type to that generic function will depend on whether the passed type adheres to the nonce typeclass derived from the implementation of the generic function |
| 20:35:40 | mat4 | ok, I summary this under parametric polymorphism |
| 20:41:42 | Araq | gmpreussner: if the names are merely accentically the same concepts cannot protect you against that. |
| 20:43:16 | gmpreussner | true, but it can make it less likely |
| 20:43:41 | * | Ven joined #nim |
| 20:43:44 | ldlework | gmpreussner: well your point kind of assumed that names divide the intended semantic space |
| 20:43:57 | ldlework | s/assumed/stood on the idea that |
| 20:44:07 | gmpreussner | if the function uses only one proc of the type's interface instead of enforcing the entire interface (even though it is not used), the chances are higher |
| 20:44:33 | ldlework | oh that's true too |
| 20:44:43 | ldlework | It bundles assumptions |
| 20:44:50 | ldlework | Which makes the disambiguation more aggressive |
| 20:45:23 | mat4 | the problem I see is that duck typing is a dynamic concept determinating type compatibility dependent on the actual invoked parts of a structure (object, Nim terminology). Because invocation can change at runtime static analysis would be limited to the extend of possible type inconsistencies |
| 20:45:54 | ldlework | mat4: eh "duck typed generics" is just a joke really |
| 20:46:00 | ldlework | It isn't anything like "python's duck-typing" |
| 20:46:06 | ldlework | It doesn't have anything to do with the runtime |
| 20:46:28 | ldlework | In fact, by the time you're calling a generic function at runtime, the implementation has already been expanded out to an implementation made just for that type you're passing. |
| 20:46:41 | ldlework | The "duck-typing" happens when trying to resolve generic instantiations |
| 20:47:09 | mat4 | yes, I know this concept as structural typing |
| 20:47:13 | ldlework | Or rather, "should this type A be able to be passed to generic function foo[T]()" |
| 20:47:17 | ldlework | Its not structural typing either. |
| 20:47:41 | mat4 | then it would be better to define a new terminology |
| 20:47:41 | ldlework | Its the way in which Nim determines whether A can be used for T which is "like duck-typing" |
| 20:47:50 | ldlework | In other languages you have to tell the compiler what T is capable of |
| 20:48:07 | ldlework | Only then can you pass something like A as a T assuming A has all the things defined in that extra information about what T can do |
| 20:48:17 | ldlework | But in Nim the "extra bit of information about what T can do" |
| 20:48:36 | ldlework | is *automatically derived* from what you *do* in the generic implementation |
| 20:48:38 | ldlework | If you do |
| 20:48:49 | ldlework | var t: T |
| 20:48:52 | ldlework | t.something() |
| 20:48:58 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 20:49:08 | ldlework | Nim now assumes that all types that will be passed in as a T, like an A, must support .something() |
| 20:49:37 | ldlework | The reason why it is duck typing like, is because the programmer did not have to make a typeclass, specify that the typeclass allows for .something and then specify foo as foo[T: SomeTypeClass] |
| 20:51:27 | ldlework | mat4: hopefully I helped. |
| 20:51:41 | * | toaoMgeorge joined #nim |
| 20:52:45 | * | Ven joined #nim |
| 20:54:02 | mat4 | well put, except my point was confusion about the selected terminology |
| 20:55:04 | ldlework | mat4: I agree. |
| 20:59:24 | mat4 | I hope such appointments find no documentation usage |
| 20:59:27 | gmpreussner | i feel like we need to go back to the drawing board and think about what we really want to achieve. i'm not so sure anymore :) |
| 21:00:18 | * | Varriount joined #nim |
| 21:04:16 | Varriount | Araq: I just think that it makes things easier to read. Using methods means that we aren't manually branching for mode-specific behavior. |
| 21:05:54 | Araq | Varriount: if my IDE cannot reliably "goto definition" (and for methods it will never be able to do that) I don't care if it's "easier to read" |
| 21:06:21 | Varriount | Araq: Huh? How does my change affect that functionality? |
| 21:07:08 | Araq | mymethod(a, b) # goto def 'mymethod' ... er which one? |
| 21:08:13 | Araq | that's why I avoid dynamic binding. |
| 21:10:41 | Varriount | Araq: Do you want me to switch out the methods for case statements? |
| 21:12:52 | Araq | yup. or generate it via a macro. |
| 21:13:26 | Varriount | Araq: But a macro would prevent 'goto definition' too. |
| 21:13:51 | Araq | not necessarily. |
| 21:15:53 | Araq | we should improve idetools so that it can do it ;-) it's possible. and no, you cannot argue the same for 'method', 'method' is impossible. |
| 21:16:46 | Varriount | Araq: Well, I can't say I feel the same way, but I'll do what you feel is right. |
| 21:17:14 | Araq | good, thank you. |
| 21:18:14 | Varriount | Araq: I still think splitting off the various mode functionalities into their own procedures make sense. |
| 21:19:01 | Araq | I'd rather have fewer modes to begin with. |
| 21:19:22 | Araq | in theory every idetools test needs to be run for every mode we support. |
| 21:19:38 | Araq | right now we don't have tests (yay ...) |
| 21:19:56 | dom96 | Araq: Does "Goto definition" support methods at all? Presumably when trying to "Go to definition" on a method call you would get a list of possible methods, right? |
| 21:20:24 | Araq | dom96: right. |
| 21:20:41 | dom96 | Araq: Is that implemented? |
| 21:20:48 | Araq | nope. |
| 21:21:01 | Varriount | Araq: One might wonder how Java programmers get anything done. :3 |
| 21:21:05 | dom96 | Varriount/Araq: What are the different nimsuggest modes? |
| 21:21:21 | dom96 | the modes only change the way the data is transferred right? |
| 21:21:22 | Varriount | Standard Input, Tcp, and Epc mode |
| 21:21:53 | Araq | Varriount: Java programmers don't get anything done. |
| 21:23:04 | Varriount | Araq: How does nimsuggest handle 'goto definition' in generic procedures? |
| 21:23:26 | Varriount | (when using it on a generically typed variable) |
| 21:24:00 | dom96 | Hrm. I would create some sort of API out of nimsuggest, so that nimble packages can reuse it, and provide some limited modes which build on top of that API |
| 21:24:06 | dom96 | that way we can just test the API |
| 21:24:44 | Varriount | dom96: Don't you mean a compiler API? Most of the Nimsuggest API is just a presentation layer. |
| 21:24:55 | Varriount | Er, most of the nimsuggest functionality. |
| 21:26:32 | dom96 | oh. I didn't realise. |
| 21:27:14 | dom96 | I'm sure nimsuggest could provide a thin wrapper on top of the compiler API, making it far nicer to use. |
| 21:27:34 | Araq | Varriount: it works. |
| 21:27:54 | Araq | it uses a "best effort" type checking approach for that. |
| 21:28:17 | Varriount | So... back to presenting multiple choices? |
| 21:29:49 | Araq | if there are multiple choices, yes. |
| 21:30:34 | gmpreussner | that's VAX handles it |
| 21:30:41 | gmpreussner | *that's how |
| 21:30:45 | Araq | it's a valid remark, but I don't use generics everywhere just because I could either. |
| 21:35:40 | Varriount | Araq: Sorry, I'm just trying to figure out how your motivation that 'goto definition should work' fits in with the most elegant approaches. |
| 21:36:11 | Varriount | Generics and methods could both return multiple choices, templates and macros could hide the invokation completely |
| 21:37:27 | * | PMunch quit (Ping timeout: 276 seconds) |
| 21:37:40 | * | Subspice joined #nim |
| 21:38:05 | Araq | Varriount: 'goto definition' is a good example of how good you and your tooling can reason about the code. |
| 21:40:29 | Varriount | Eh. I guess I'm just used to Python, where explanatory comments are used instead. |
| 21:43:31 | * | brson joined #nim |
| 21:55:24 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:00:57 | * | toaoMgeorge quit (Ping timeout: 246 seconds) |
| 22:03:04 | * | toaoMgeorge joined #nim |
| 22:08:05 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:13:33 | * | Subspice quit () |
| 22:16:39 | * | bjz joined #nim |
| 22:17:48 | * | Demon_Fox joined #nim |
| 22:22:36 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:22:47 | * | boopsies is now known as boopsiesisaway |
| 22:23:49 | * | Senketsu quit (Quit: Leaving) |
| 22:24:12 | * | pregressive quit (Remote host closed the connection) |
| 22:24:40 | * | bjz joined #nim |
| 22:26:03 | * | Demon_Fox quit (Ping timeout: 240 seconds) |
| 22:26:07 | * | brson quit (Ping timeout: 268 seconds) |
| 22:26:55 | * | Demon_Fox joined #nim |
| 22:28:56 | * | pregress_ joined #nim |
| 22:31:04 | * | vendethiel quit (Ping timeout: 244 seconds) |
| 22:32:02 | * | brson joined #nim |
| 22:32:48 | * | pregress_ quit (Remote host closed the connection) |
| 22:33:04 | * | pregressive joined #nim |
| 22:34:34 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:39:37 | * | vendethiel joined #nim |
| 22:39:51 | * | toaoMgeorge quit (Ping timeout: 276 seconds) |
| 22:40:11 | * | toaoMgeorge joined #nim |
| 22:51:40 | * | Kingsquee joined #nim |
| 22:54:51 | * | mahasamoot_ quit (Ping timeout: 246 seconds) |
| 23:00:47 | * | vendethiel quit (Ping timeout: 260 seconds) |
| 23:02:46 | * | vendethiel joined #nim |
| 23:09:35 | * | PMunch joined #nim |
| 23:10:25 | * | mat4 quit (Quit: Leaving) |
| 23:18:41 | * | NimBot joined #nim |
| 23:23:54 | * | vendethiel quit (Ping timeout: 246 seconds) |
| 23:30:21 | * | mahasamoot joined #nim |
| 23:42:15 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:50:57 | * | vendethiel joined #nim |
| 23:51:24 | * | pregressive quit (Remote host closed the connection) |
| 23:59:58 | * | bozaloshtsh quit (Ping timeout: 244 seconds) |