| 00:00:28 | Araq | skyfex: make a PR. I don't plan to deprecate the gtk2 wrapper |
| 00:00:39 | * | Mimbus quit (Remote host closed the connection) |
| 00:00:40 | * | flaviu quit (Remote host closed the connection) |
| 00:00:40 | dom96 | onionhammer: try now |
| 00:01:03 | Araq | we need the commit messages .... :-( |
| 00:01:08 | skyfex | Yeah, you never know.. I think the Linux workstations at work supports Gtk2.. they use *ancient* versions of Red Hat >_< |
| 00:01:14 | skyfex | *Gtk3 i mean |
| 00:01:34 | dom96 | Araq: Don't worry. It will happen soon. |
| 00:02:33 | Araq | skyfex: gkt3 is like python 3. has no reason for its existance, version 2 was good enough and 3 doesn't change too much for it to justify its existance |
| 00:02:41 | onionhammer | dom96 i think its fixed |
| 00:02:46 | onionhammer | i'll check my other app |
| 00:03:48 | Araq | dom96: great work! I would have searched in a completely different direction |
| 00:04:11 | dom96 | Araq: thank you :) |
| 00:04:28 | onionhammer | so what was the issue? |
| 00:04:30 | onionhammer | result = result? |
| 00:04:34 | dom96 | yeah lol |
| 00:04:39 | onionhammer | oops ;) |
| 00:04:44 | dom96 | indeed |
| 00:04:48 | * | flaviu joined #nim |
| 00:06:18 | Araq | the compiler doesn't complain about that? |
| 00:06:30 | Araq | cause it should, make a feature request PR |
| 00:06:39 | dom96 | You mean issue? |
| 00:07:07 | Araq | we do the data flow analysis anyway |
| 00:07:22 | Araq | well calling this "data flow analysis" is a stretch |
| 00:07:31 | dom96 | yeah. It doesn;t. |
| 00:07:34 | dom96 | Not even a warning. |
| 00:07:34 | Araq | yes, create an issue |
| 00:07:58 | * | Trustable quit (Quit: Leaving) |
| 00:08:02 | onionhammer | dom96 okay great, my stuff is back up and running |
| 00:08:04 | onionhammer | thanks |
| 00:08:08 | Araq | it should error, can't see why it should only be a warning |
| 00:08:13 | dom96 | Sure. |
| 00:08:18 | dom96 | onionhammer: np |
| 00:12:13 | Araq | dom96: does Nimble still use .nimble on windows? |
| 00:12:28 | Araq | or did you change it to "nimble" without the dot? |
| 00:13:35 | * | z1y joined #nim |
| 00:16:13 | dom96 | it still uses .nimble |
| 00:16:26 | Araq | meh ok |
| 00:17:50 | skyfex | Hm, how did the T/P thing and case sensitivity thing end up? |
| 00:18:18 | Araq | we removed them and picked a compromise |
| 00:18:41 | Araq | the compromise is that the first letter is sensitive so Foo and foo are distinct. |
| 00:19:42 | Araq | And it's a good compromise since it seems to have pissed off both camps equally ;-) |
| 00:20:40 | skyfex | Hah, well, I like it :) It's sort of hardwired in my brain that the first letter is significant when it comes to case in programming languages, even though they're sometimes not, since most use it to signify something.. even if it's just by convention |
| 00:21:18 | skyfex | But if case is different further out, it's usually insignificant and/or a mistake |
| 00:21:52 | * | z1y quit (Ping timeout: 240 seconds) |
| 00:21:59 | Araq | I like it because it continues to allow people to use under_scores and I'm allowed to not type them ;-) |
| 00:23:08 | skyfex | Hah, yeah I'm just in a super messed up state there.. been programming so much ruby and c recently I've started using underscores.. but before that I was all about camel case |
| 00:23:25 | skyfex | Still prefer it actually |
| 00:25:11 | Araq | I think I might start to prefer _ if only the fonts weren't as radical with its position |
| 00:25:36 | Araq | so that it reads-more-like-this-but-without-looking-like-a-substraction |
| 00:25:50 | Araq | but I don't know if that's even possible ;-) |
| 00:27:20 | skyfex | yeah, I think I'd like that too |
| 00:27:52 | flaviu | how about decreasing the weight of the underscore so it's less visible? |
| 00:28:57 | Demos | M-x variable-pitch-mode in emacs to turn on flexible width font |
| 00:29:03 | Demos | no way to do it in vim apperently |
| 00:29:24 | Araq | I don't mind it's weight, I mind that it's almost on the line below |
| 00:29:58 | Demos | well you can put em dashes in variables I think (U+2014) |
| 00:29:58 | Araq | and then_you start to play_spot the space_vs underscore |
| 00:30:19 | flaviu | Demos: do you mean gvim, or vim? |
| 00:30:27 | Demos | flaviu, both |
| 00:30:41 | Demos | some terminals (terminator) support flexi width font |
| 00:31:14 | flaviu | also, are you by any chance insane? Non-fixed-width fonts sound like a nightmare. ;) |
| 00:31:15 | notfowl | terminator uses opengl iirc |
| 00:33:14 | Demos | flaviu, not as bad as you think |
| 00:44:56 | ldlework | In my opinon that the underscore serves as a single token but parses like a space is precisely its advantage. |
| 00:45:43 | ldlework | The programmer generally doesn't need to distinguish between _ and " " because spaces are usually illegal in a place where a single name is expected |
| 00:46:04 | ldlework | But that the eye parses it as easily is a space is a signal to why underscores are better than camelCase and TitleCase |
| 00:46:28 | ldlework | (dashes are also good, but more semantically confusing (there is no _ operator) |
| 00:50:50 | Araq | some_longish_type_t my_variable_also_long; |
| 00:51:43 | Araq | reads like crap to me. I want to tokenize programming code in my head. |
| 00:52:14 | Araq | not confuse spaces with underscores for convenience |
| 00:55:06 | * | jux joined #nim |
| 01:01:49 | * | Sembei joined #nim |
| 01:04:46 | * | bjz quit (Ping timeout: 264 seconds) |
| 01:06:44 | * | bjz joined #nim |
| 01:11:32 | * | bjz quit (Ping timeout: 245 seconds) |
| 01:16:11 | * | bjz joined #nim |
| 01:26:19 | * | rpag joined #nim |
| 01:26:34 | * | bjz quit (Ping timeout: 250 seconds) |
| 01:51:17 | * | bjz joined #nim |
| 02:23:06 | * | starless joined #nim |
| 02:27:44 | * | bjz quit (Ping timeout: 245 seconds) |
| 02:30:42 | * | bjz joined #nim |
| 02:39:24 | * | z1y joined #nim |
| 02:41:37 | * | dyu joined #nim |
| 02:48:34 | * | z1y quit (Ping timeout: 245 seconds) |
| 03:00:18 | * | kapil__ joined #nim |
| 03:02:12 | * | ARCADIVS joined #nim |
| 03:08:01 | * | Mimbus joined #nim |
| 03:08:12 | * | darkf joined #nim |
| 03:16:49 | ldlework | Araq: any update on type forward declarations? |
| 03:17:02 | ldlework | Or rather a way to do recursive types across modules? |
| 03:18:58 | * | Mimbus quit (Remote host closed the connection) |
| 03:19:05 | * | Mimbus joined #nim |
| 03:20:25 | * | saml_ joined #nim |
| 03:22:34 | * | Mimbus quit (Read error: Connection reset by peer) |
| 03:22:41 | * | Mimbus joined #nim |
| 03:26:31 | * | milosn quit (Read error: Connection reset by peer) |
| 03:30:52 | * | Mimbus quit (Read error: Connection reset by peer) |
| 03:32:44 | * | Mimbus joined #nim |
| 03:33:23 | * | Mimbus quit (Remote host closed the connection) |
| 03:33:35 | * | Mimbus joined #nim |
| 03:35:47 | * | milosn joined #nim |
| 03:42:52 | * | quasinoxen quit (Quit: No Ping reply in 180 seconds.) |
| 03:44:23 | * | quasinoxen joined #nim |
| 03:55:30 | * | flaviu quit (Remote host closed the connection) |
| 03:56:10 | * | flaviu joined #nim |
| 04:01:01 | * | bjz quit (Ping timeout: 265 seconds) |
| 04:17:13 | * | z1y joined #nim |
| 04:25:49 | * | z1y quit (Remote host closed the connection) |
| 04:26:13 | * | z1y joined #nim |
| 04:32:55 | * | BitPuffin quit (Ping timeout: 265 seconds) |
| 04:37:21 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 04:38:43 | gmpreussner | github down? |
| 04:38:57 | rpag | nope |
| 04:39:16 | * | vendethiel joined #nim |
| 04:40:27 | gmpreussner | odd... maybe just on my route. i'm getting connection timeouts. |
| 04:40:56 | gmpreussner | now it's back |
| 04:58:33 | * | gmpreussner quit (Quit: Konversation terminated!) |
| 05:07:02 | * | bjz joined #nim |
| 05:12:34 | * | gsingh93 joined #nim |
| 05:21:53 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 05:22:29 | * | vendethiel joined #nim |
| 05:58:44 | * | Hakaslak joined #nim |
| 06:08:52 | * | Hakaslak quit (Read error: Connection reset by peer) |
| 06:09:43 | * | Hakaslak joined #nim |
| 06:09:52 | * | bjz quit (Ping timeout: 256 seconds) |
| 06:14:35 | * | gmpreussner joined #nim |
| 06:15:23 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 06:16:54 | * | gmpreussner quit (Client Quit) |
| 06:17:10 | * | gmpreussner joined #nim |
| 06:17:40 | * | vendethiel joined #nim |
| 06:19:57 | * | gmpreussner quit (Client Quit) |
| 06:20:13 | * | gmpreussner joined #nim |
| 06:21:19 | * | saml_ quit (Quit: Leaving) |
| 06:36:26 | * | Hakaslak quit (Quit: TODO: Generate 'Computer Sleep Quit Message') |
| 06:38:01 | * | Hakaslak joined #nim |
| 06:38:37 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 06:44:20 | * | Hakaslak quit (Read error: Connection reset by peer) |
| 06:45:01 | * | Hakaslak joined #nim |
| 07:06:45 | ldlework | on https://gist.github.com/anonymous/d8d8622604e5a712c2b6, why am I getting foo.nim(7, 9) Error: type mismatch: got (int literal(49)) |
| 07:07:00 | ldlework | it doesn't like the <50 |
| 07:11:33 | notfowl | ldlework, what is <50? it isnt an iterator |
| 07:24:48 | * | vendethiel joined #nim |
| 07:27:55 | * | gour joined #nim |
| 07:29:30 | * | BitPuffin joined #nim |
| 07:33:47 | * | BitPuffin quit (Ping timeout: 244 seconds) |
| 07:37:55 | * | dts|pokeball quit (Ping timeout: 244 seconds) |
| 07:38:19 | gmpreussner | let |
| 07:38:33 | gmpreussner | oops wrong window |
| 07:42:20 | * | milosn quit (Read error: Connection reset by peer) |
| 07:43:13 | * | milosn joined #nim |
| 07:46:01 | * | dts|pokeball joined #nim |
| 07:48:46 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 07:53:48 | * | dyu quit (Quit: Leaving) |
| 08:04:29 | * | gmpreussner quit (Remote host closed the connection) |
| 08:04:52 | * | gmpreussner joined #nim |
| 08:05:38 | * | milosn quit (Read error: Connection reset by peer) |
| 08:11:11 | * | milosn joined #nim |
| 08:24:00 | * | Hakaslak quit (Quit: TODO: Generate 'Computer Sleep Quit Message') |
| 08:24:45 | * | Hakaslak joined #nim |
| 08:26:11 | gmpreussner | Demos: you around? |
| 08:27:17 | gmpreussner | please ping me when you get this thx! |
| 08:28:46 | * | vendethiel joined #nim |
| 08:29:22 | * | Hakaslak quit (Ping timeout: 264 seconds) |
| 08:34:16 | Demos | gmpreussner, yup |
| 08:40:58 | * | BlaXpirit joined #nim |
| 08:42:37 | * | dts|pokeball quit (Ping timeout: 240 seconds) |
| 08:48:04 | * | dts|pokeball joined #nim |
| 08:48:20 | * | gour quit (Remote host closed the connection) |
| 08:55:22 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 08:57:59 | * | gour joined #nim |
| 09:01:31 | * | vendethiel joined #nim |
| 09:10:51 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
| 09:29:29 | * | Demos quit (Ping timeout: 272 seconds) |
| 09:30:10 | * | gour_ joined #nim |
| 09:34:10 | * | gour quit (Ping timeout: 264 seconds) |
| 09:37:18 | * | gour_ is now known as gour |
| 09:49:45 | * | z1y quit (Ping timeout: 272 seconds) |
| 09:57:59 | * | gour quit (Remote host closed the connection) |
| 10:00:47 | * | gour joined #nim |
| 10:06:07 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 10:08:25 | * | vendethiel joined #nim |
| 10:39:21 | * | vendethiel- joined #nim |
| 10:39:49 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 10:56:03 | * | z1y joined #nim |
| 10:56:37 | * | starless quit (Quit: WeeChat 0.4.2) |
| 10:57:32 | * | bjz joined #nim |
| 11:10:07 | * | vendethiel joined #nim |
| 11:10:39 | * | vendethiel- quit (Ping timeout: 245 seconds) |
| 11:11:23 | * | yglukhov_ joined #nim |
| 11:13:37 | * | yglukhov_ quit (Client Quit) |
| 11:18:58 | * | bjz_ joined #nim |
| 11:21:32 | * | bjz quit (Ping timeout: 256 seconds) |
| 11:22:10 | * | jux quit (Ping timeout: 264 seconds) |
| 11:31:31 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 11:43:37 | * | bjz_ quit (Read error: Connection reset by peer) |
| 11:43:45 | * | bjz joined #nim |
| 11:57:00 | * | dyu joined #nim |
| 12:01:39 | dv- | can i somehow say a proc parameter is var without specifying its type? |
| 12:05:14 | Araq | dv-: I don't think so |
| 12:07:52 | Araq | ldlework: well you haven't shown us how the syntax should look like |
| 12:16:51 | * | yglukhov_ joined #nim |
| 12:22:43 | * | kapil__ joined #nim |
| 12:24:06 | dyu | Araq: about that generics proc dot notation, it can't be fixed to have same behavior as the normal call syntax? |
| 12:24:37 | Araq | f.x[i](a) |
| 12:24:44 | Araq | is |
| 12:24:53 | dyu | x[i](f,a) |
| 12:24:57 | Araq | ((f.x)[i])(a) |
| 12:25:20 | dyu | hmm |
| 12:26:34 | dyu | Araq: ((f.x)[i]) <-- so its an array call? rather than generics |
| 12:28:01 | Araq | well originally I wanted to use [. .] for generics for this reason |
| 12:28:13 | Araq | but I feared the complaints :P |
| 12:28:26 | dyu | well, yea .. expected |
| 12:28:50 | dyu | can it be checked semantically that the [i] would be a type rather than an expression/literal? |
| 12:29:15 | Araq | can be done but I don't like it |
| 12:29:48 | dyu | ok |
| 12:30:41 | * | BitPuffin joined #nim |
| 12:31:36 | dyu | the more I get used to coding nim, the more I appreciate the language design |
| 12:32:33 | Araq | dyu: for non-optional type parameters you should use 'typeDesc' instead |
| 12:32:50 | Araq | then you can simply use f.x(typeHere, a) |
| 12:34:54 | dyu | Araq: so proc f* [T](T: typedesc, a:bool) ? |
| 12:35:00 | dyu | err |
| 12:35:05 | dyu | typedesc:T |
| 12:35:06 | Araq | without the [T] |
| 12:35:53 | Araq | proc f(T: typedesc, a: bool): T |
| 12:36:09 | dyu | oh yea |
| 12:36:22 | dyu | lol, got confused |
| 12:36:53 | ekarlso- | Araq: i've started looking at a small packages.nim-lang.org program |
| 12:42:58 | dyu | Araq: doesn't work |
| 12:43:15 | Araq | dyu: it should ... can you gist it? |
| 12:44:48 | dyu | Araq: http://pastebin.com/8QADqyUM |
| 12:48:51 | Araq | dyu: told you to invoke it like so: |
| 12:48:58 | Araq | fbb.ca(bool, 2) |
| 12:49:06 | dyu | argh |
| 12:50:38 | dyu | Araq: Error: type mismatch: got (ptr FlatBufferBuilder, typedesc[bool], int literal(2)) |
| 12:50:45 | dyu | common.ca(T: typedesc, fbb: ptr FlatBufferBuilder, len: int): Array[None] |
| 12:50:57 | dyu | 2nd line = expected |
| 12:51:19 | dyu | fbb.ca(bool, 2) <-- with this call |
| 12:53:58 | Araq | well. maybe you should take a nap and then look at the error message |
| 12:54:25 | Araq | it's obvious. |
| 12:55:23 | Araq | proc ca(fbb: ptr Flatbufferbuilder, T: typeDesc, len: int): Array[T] |
| 12:55:49 | Araq | if bool is the 2nd argument, the T should be the 2nd parameter. makes sense right? |
| 12:55:56 | dyu | yep |
| 12:57:07 | dyu | Araq: now changed to proc ca* (fbb: ptr FlatBufferBuilder, T: typedesc, len: int): Array[T] {.noinit.} = |
| 12:57:14 | dyu | Error: internal error: (filename: compiler/sigmatch.nim, line: 1024) |
| 12:58:50 | Araq | interesting. report it :P |
| 12:59:08 | dom96 | ekarlso-: written in Nim? |
| 13:01:13 | dyu | Araq: same error even with let boolarray = ca(fbb, bool, 2) ... will open a new issue |
| 13:16:04 | ekarlso- | dom96: YA |
| 13:17:00 | * | Trustable joined #nim |
| 13:20:55 | dom96 | ekarlso-: good. |
| 13:21:01 | dom96 | ekarlso-: What's your plan? |
| 13:33:40 | * | vendethiel- joined #nim |
| 13:34:20 | * | vendethiel quit (Ping timeout: 258 seconds) |
| 13:39:48 | * | nimnoob joined #nim |
| 13:48:43 | milosn | dom96: is there anywhere a howto on writing wrappers for C libs? |
| 13:49:45 | milosn | it should be easy, as much as i understand ... was reading about it previously |
| 13:49:46 | milosn | :) |
| 13:55:54 | * | loz joined #nim |
| 13:56:24 | milosn | i wanna play around and generate a wrapper for http://orclib.sourceforge.net/ |
| 13:56:30 | milosn | see how far i get |
| 13:56:55 | milosn | something to do so i dont get rusty |
| 13:57:14 | milosn | and expand my skills |
| 13:57:20 | * | milosn dont wanna forget Nim |
| 13:57:23 | milosn | ;) |
| 13:59:42 | dyu | milosn: eww oracle |
| 13:59:50 | dyu | :-) |
| 14:00:11 | milosn | yeah i know, "evil" oracle ... :) |
| 14:18:50 | * | Banjomaster joined #nim |
| 14:29:50 | milosn | guess ill have to find that howto on my own |
| 14:29:57 | milosn | you aint very helpfull you know |
| 14:29:58 | milosn | :D |
| 14:30:58 | flaviu | milosn: http://goran.krampe.se/2014/10/16/nim-wrapping-c/ |
| 14:32:00 | milosn | hmm cool |
| 14:32:02 | milosn | thanks |
| 14:32:03 | milosn | :) |
| 14:32:07 | * | ARCADIVS quit (Quit: ARCADIVS) |
| 14:32:15 | * | gmpreussner_ joined #nim |
| 14:33:04 | * | gmpreussner quit (Ping timeout: 250 seconds) |
| 14:36:23 | * | milosn quit (Read error: Connection reset by peer) |
| 14:41:56 | * | milosn joined #nim |
| 14:42:05 | milosn | ops |
| 14:42:22 | milosn | chopy internet from tel-aviv |
| 14:42:27 | milosn | :) |
| 14:42:35 | milosn | it comes and goes ocasionaly |
| 14:54:24 | Araq | milosn: please also provide db_oracle modelled after db_postgre on top of the low level C wrapper |
| 14:54:51 | * | Banjomaster quit (Ping timeout: 256 seconds) |
| 14:55:05 | milosn | i havent started anything, there is loads of time to make it |
| 14:55:10 | milosn | i am just investigating |
| 14:55:24 | milosn | :) |
| 14:57:18 | Araq | ping zahary |
| 15:01:05 | * | AMorpork is now known as AFKMorpork |
| 15:09:25 | loz | is there any info about history of nim? even wiki has no article about nim |
| 15:09:36 | * | bjz_ joined #nim |
| 15:10:41 | * | bjz quit (Read error: Connection reset by peer) |
| 15:11:36 | * | darkf quit (Quit: Leaving) |
| 15:13:29 | gmpreussner_ | loz: And god said "Let there be nim", and there was nim. |
| 15:14:58 | Araq | loz: wikipedia doesn't like Nim. |
| 15:15:36 | loz | it was always interesting for me to learn about people, companies behind a technology, their ideas and goals, their failures and successes and so on |
| 15:15:48 | loz | Araq: why?) |
| 15:17:10 | loz | and i'm still surprised i haven't heard anything about nim all these years |
| 15:18:28 | EXetoC | got to have external sources apparently |
| 15:18:47 | * | z1y quit (Ping timeout: 244 seconds) |
| 15:23:25 | * | nimnoob quit (Ping timeout: 252 seconds) |
| 15:26:24 | flaviu | loz: best not to mention wikipedia unless you want a long rant |
| 15:27:51 | loz | no problems, this is just a place where i usually read some language overview |
| 15:33:11 | * | jefus joined #nim |
| 15:34:56 | * | vendethiel- quit (Quit: q+) |
| 15:39:00 | ekarlso- | dom96: currently mimic the packages.json format that's in use |
| 15:39:25 | ekarlso- | dom96: but unsure of how to do the stuff with storage |
| 15:39:31 | ekarlso- | store it on local disk, ref repos or ? |
| 15:51:31 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 16:02:06 | * | Banjomaster joined #nim |
| 16:08:28 | ekarlso- | what editor do you use for nim ? |
| 16:09:26 | * | AFKMorpork is now known as AMorpork |
| 16:12:44 | milosn | vim? |
| 16:15:55 | gmpreussner_ | i use Kate |
| 16:16:23 | milosn | i never could get used to emacs ... to complicated for me |
| 16:16:28 | milosn | vim just does it |
| 16:16:30 | milosn | :D |
| 16:18:03 | dts|pokeball | i use nano |
| 16:18:21 | * | dts|pokeball ducks from the hail of fire from the vi users |
| 16:18:54 | * | gour quit (Remote host closed the connection) |
| 16:21:11 | loz | emacs ftw |
| 16:21:41 | * | gour joined #nim |
| 16:32:06 | * | AMorpork is now known as AFKMorpork |
| 16:36:12 | * | gmpreussner__ joined #nim |
| 16:36:17 | * | gmpreussner_ quit (Ping timeout: 256 seconds) |
| 16:41:52 | dom96 | loz: What might help is if you email the moderators of the computing section of wikipedia and tell them that you are annoyed that Nim is not mentioned. |
| 16:42:06 | dom96 | if enough of us do it then it surely will work right? |
| 16:42:52 | dom96 | ekarlso-: I think it's something we'll have to have a serious think about. |
| 16:43:05 | dom96 | Do we want a centralised repo where people upload their packages? |
| 16:43:09 | loz | dom96: i'm not sure, i though language official person should write an article |
| 16:43:18 | dom96 | or do we just want a little tracker which tracks people's packages? |
| 16:43:35 | dom96 | loz: That's definitely not the case. |
| 16:46:57 | flaviu | dom96: That won't be productive. |
| 16:47:16 | dom96 | flaviu: what do you suggest then? |
| 16:47:40 | flaviu | To wait until nim meets the standards of notability. |
| 16:47:42 | ekarlso- | what should it be then ?= |
| 16:47:57 | ekarlso- | just a small registry ? |
| 16:48:20 | flaviu | Personal appeals don't really work against bureaucracy |
| 16:48:44 | * | NimBot joined #nim |
| 16:49:04 | ekarlso- | a'la pypi or ? |
| 16:52:37 | dom96 | ekarlso-: I'm not sure. It's something to discuss with the rest of the community. |
| 16:52:39 | EXetoC | ekarlso-: that seems like a good idea. just add proper authentication and set a size quota |
| 16:52:53 | dom96 | ekarlso-: Create a thread on the forum about it. |
| 16:53:27 | * | Banjomaster quit (Ping timeout: 272 seconds) |
| 16:54:47 | * | flaviu quit (Remote host closed the connection) |
| 16:55:02 | * | flaviu joined #nim |
| 16:55:21 | EXetoC | the registry could point to the actual repository, but the server could download the packages so as to be able to extract some metadata to be presented in the registry |
| 17:08:46 | ekarlso- | meh, I was thinking of something like rusts crates.io just wihtout the hosting bit |
| 17:08:51 | ekarlso- | or pypi |
| 17:09:03 | ekarlso- | where it's a index and packages are hosted externally |
| 17:12:23 | * | dyu quit (Quit: Leaving) |
| 17:14:23 | * | suvdeep joined #nim |
| 17:14:58 | * | suvdeep left #nim ("http://quassel-irc.org - Chat comfortably. Anywhere.") |
| 17:15:45 | EXetoC | ekarlso-: so what I said, minus the metadata extraction? |
| 17:17:50 | EXetoC | which would incur some storage overhead, but no bandwidth overhead (well, very little) |
| 17:32:15 | ekarlso- | EXetoC: :) |
| 17:34:48 | ekarlso- | hmmm |
| 17:35:25 | ekarlso- | with nimble can one provide something like requirements.txt for pip in python ? |
| 17:35:26 | * | gour quit (Remote host closed the connection) |
| 17:36:17 | * | Araq_ joined #nim |
| 17:36:20 | * | gour joined #nim |
| 17:37:06 | * | Araq quit (Ping timeout: 240 seconds) |
| 17:39:13 | * | gour quit (Remote host closed the connection) |
| 17:50:06 | ekarlso- | Araq_: so when one does say import jester in nim it will import all methods? |
| 17:50:56 | EXetoC | all exported symbols (foo*) |
| 17:51:15 | ekarlso- | kk |
| 17:51:29 | ekarlso- | looking at jester is there a way to make the port configurable ? :/ |
| 17:53:53 | EXetoC | ekarlso-: newSettings? |
| 17:54:07 | dom96 | var settings = newSettings(port = Port(1234)) |
| 17:54:19 | dom96 | I will make that nicer. |
| 17:54:38 | ekarlso- | k |
| 17:54:41 | dom96 | But that syntax will continue to work. |
| 18:03:39 | * | gour joined #nim |
| 18:18:14 | * | nimnoob joined #nim |
| 19:02:47 | * | profan joined #nim |
| 19:20:17 | * | Araq_ is now known as araq |
| 19:22:44 | * | araq is now known as Araq |
| 19:27:35 | loz | hm, can't i compile windows binary on linux machine? |
| 19:28:33 | Araq | you can cross-compile any way you want if you setup your gcc properly |
| 19:30:47 | loz | looks like nim wants some windows headers |
| 19:32:22 | Araq | yeah. maybe you should have these when compiling for windows |
| 19:36:54 | * | starless joined #nim |
| 19:43:12 | * | starless quit (Quit: WeeChat 0.4.2) |
| 19:48:08 | loz | looks like i need all windows headers |
| 19:50:23 | Araq | no. you need a windows machine. |
| 19:50:33 | loz | damn( |
| 19:50:59 | loz | what kind of cross-compilation is this?) |
| 19:51:22 | Araq | how do you think it works? you build a binary for windows, it doesn't work on some machine and then ...? how do you debug the problem? |
| 19:52:36 | Araq | compiling a windows binary on a linux machine sounds completely out of touch with reality with me unless you setup some form of build server |
| 19:53:45 | loz | i'm sure i saw a language which could make native windows binaries on linux |
| 19:55:01 | Araq | you can do it. but it's stupid. |
| 19:57:18 | loz | Araq: >how do you debug the problem? |
| 19:57:18 | loz | but you still have a debugger, and supported binary format, no? |
| 19:58:19 | Araq | how does that help you when you cannot even run the .exe on linux in the first place? |
| 19:58:37 | profan | mono/wine? |
| 19:59:08 | Araq | if you use wine already, why not use wine for compilation? |
| 19:59:41 | loz | no, you debug windows binary on windows.. |
| 20:00:20 | loz | you dont run exe on linux, you just make it and give away to windows guys) |
| 20:02:03 | Araq | so in other words you give them untested software. ;-) |
| 20:02:18 | loz | well, you tested it on linux |
| 20:02:53 | loz | of course you didn't test windows-specific things |
| 20:03:12 | * | Araq tries to imagine a QA that accepts this procedure ... |
| 20:03:30 | loz | btw i found it, red guys have some advanced cross compilation https://github.com/red/red |
| 20:05:21 | * | BlaXpirit-UA joined #nim |
| 20:06:01 | flaviu | loz: maybe you can use the wine headers? |
| 20:06:23 | loz | hm, i can try that |
| 20:06:47 | Araq | mingw also comes with them, it's not hard to find them. |
| 20:07:48 | loz | Araq: how did you start nim project? |
| 20:07:55 | * | BlaXpirit quit (Ping timeout: 255 seconds) |
| 20:08:11 | Araq | but again, this works until you hit the first problem. |
| 20:08:13 | * | nimnoob quit (Ping timeout: 256 seconds) |
| 20:08:50 | Araq | and afaict 'red' abstracts from the underlying platform much more than Nim does |
| 20:09:03 | Araq | so it might work out for them |
| 20:11:34 | Araq | loz: long story short: I searched for an "acceptable" programming language and found none. |
| 20:12:41 | loz | did you have a specific task? or did you search for some kind of everyday universal joyful language? |
| 20:12:51 | Araq | where "acceptable" means: static typing with a concise syntax that produces native code |
| 20:12:56 | * | Epic|gmpreussner joined #nim |
| 20:12:58 | * | gmpreussner__ quit (Ping timeout: 244 seconds) |
| 20:13:11 | loz | sounds like ocaml |
| 20:14:12 | Araq | I looked at it but didn't like it's overly functional style plus its syntax plus the fact that they had to special case 'array of float' for performance |
| 20:15:02 | loz | i see. do you use nim at work now? |
| 20:15:37 | loz | or do you have a chance to use it |
| 20:18:13 | Araq | yes |
| 20:18:50 | loz | Araq: at what kind of field? |
| 20:19:44 | Araq | let's say "game like" project |
| 20:20:26 | * | jefus_ joined #nim |
| 20:21:32 | loz | and how did your colleges react on nim? |
| 20:22:03 | * | irrequietus joined #nim |
| 20:24:07 | * | jefus quit (Ping timeout: 258 seconds) |
| 20:24:10 | Araq | dunno. most of my former colleagues lack the vision to see what's wrong with existing mainstream languages ;-) |
| 20:24:59 | loz | former?) |
| 20:25:24 | loz | are you the only one who uses nim at your work now?) |
| 20:25:27 | * | nimnoob joined #nim |
| 20:27:16 | Araq | no, but I changed jobs for Nim |
| 20:27:35 | Araq | and now enough of this. I usually don't answer personal questions at all. |
| 20:29:07 | loz | ah, sorry, thanks for answers |
| 20:30:19 | gour | Araq: are you still alive and well ready for Nim release this yaer? |
| 20:30:23 | gour | *year |
| 20:34:30 | * | jefus_ is now known as jefus |
| 20:35:18 | ekarlso- | what the frap is the diff between proc and a method ? |
| 20:36:36 | def- | ekarlso-: methods use dynamic dispatch, see http://nim-lang.org/tut2.html#dynamic-dispatch |
| 20:44:06 | * | gour quit (Remote host closed the connection) |
| 20:44:23 | ekarlso- | so using methods is bad ? ^ |
| 20:45:17 | flaviu | ekarlso-: no |
| 20:45:53 | flaviu | If you don't need dynamic dispatch (you're not using inheritance), then use proc |
| 20:46:07 | flaviu | but methods are certainly not bad. They have their place |
| 20:49:57 | ekarlso- | gokr: ping |
| 20:50:06 | ekarlso- | flaviu: what company are you with ? |
| 20:50:35 | flaviu | ekarlso-: I'm a student at the moment. |
| 21:02:16 | ldlework | What would be novel is if our package manager had strong identity verification built in |
| 21:02:23 | ldlework | with signing and such |
| 21:02:31 | ldlework | no idea further than that, carry on |
| 21:03:43 | dom96 | ldlework: I don't think we need to worry about that just yet. |
| 21:04:34 | ldlework | dom96: I still haven't written the thing up about prelude |
| 21:05:47 | dom96 | ldlework: There is still time. |
| 21:07:04 | ekarlso- | dom96: u then a student too ? :p |
| 21:08:00 | dom96 | ekarlso-: yep |
| 21:10:07 | ekarlso- | Araq: how old is nimrod ? |
| 21:10:12 | ekarlso- | eh, nim |
| 21:10:27 | * | Varriount|Busy joined #nim |
| 21:10:32 | Varriount|Busy | Meep |
| 21:10:46 | Araq | Varriount|Busy: ready for release? |
| 21:11:05 | Varriount|Busy | Araq: Is the documentation online so I can properly test the installer? |
| 21:11:06 | flaviu | ekarlso-: clone the git repo and check git log |
| 21:11:23 | Araq | ekarlso-: first successful bootstrap in 2008 iirc |
| 21:14:57 | * | nimnoob quit (Ping timeout: 240 seconds) |
| 21:15:52 | Araq | Varriount|Busy: no... |
| 21:17:41 | * | nimnoob joined #nim |
| 21:20:21 | * | Varriount_ joined #nim |
| 21:21:55 | * | Varriount|Busy quit (Ping timeout: 246 seconds) |
| 21:21:57 | * | nimnoob quit (Ping timeout: 245 seconds) |
| 21:28:16 | Varriount_ | Araq: What is the revision that will be used for the release? |
| 21:28:34 | Araq | Varriount_: there is no 0.10.2 commit yet |
| 21:29:49 | * | Varriount_ is now known as Varriount|Busy |
| 21:33:25 | ldlework | can we have pop take an index? |
| 21:33:59 | Varriount|Busy | Araq: So... I'm ready to prepare the release, however I need a revision to use and generated documentation to use. |
| 21:34:16 | * | rpag quit (Ping timeout: 250 seconds) |
| 21:34:38 | Araq | integrated Nimble in the installer? |
| 21:35:03 | Araq | ldlework: what kind of "pop" is that? |
| 21:35:20 | ldlework | one that pops out the specified element |
| 21:35:51 | ldlework | please don't make the argument from the position of the metaphor of the word over whether it would be of general utility to take an element out of a sequence by index |
| 21:35:54 | Varriount|Busy | Araq: What revision of nimble should I use? |
| 21:38:36 | Araq | Varriount|Busy: dom96 released a stable version just a few days ago |
| 21:38:48 | Araq | should have a git tag |
| 21:39:20 | Araq | ldlework: meh ... is that really necessary? if so, move pop to sequtils |
| 21:40:06 | ldlework | Araq: https://gist.github.com/dustinlacewell/c8d1186a935836915999 |
| 21:41:03 | ldlework | ignore the clone |
| 21:42:06 | ldlework | Araq: so you know how if pop is moved to sequtils then the whole stdlib has to be updated? |
| 21:42:52 | ldlework | Araq: and you know how there is a concern that system.nim is too bloated and so on |
| 21:42:56 | * | nimnoob joined #nim |
| 21:43:11 | Araq | I recognize the words but your grammar escapes me |
| 21:44:44 | * | BlaXpirit-UA quit (Quit: Quit Konversation) |
| 21:46:27 | ldlework | k |
| 21:48:25 | Araq | ldlework: as I said, move pop to sequtils and add a version which takes an index |
| 21:48:34 | Araq | this PR will be accepted |
| 21:48:46 | ldlework | Araq: it will require updating the entire stdlib |
| 21:49:24 | Araq | most of the stdlib doesn't use 'pop' |
| 21:49:38 | ldlework | That's fair, but consider this |
| 21:50:06 | ldlework | What if we made prelude.nim the module that currently system.nim occupies |
| 21:50:19 | ldlework | allowing us to refactor out all the stuff like 'pop' into other modules |
| 21:50:31 | ldlework | but have modules like sequtils and strutils always available |
| 21:51:07 | ldlework | you'd want to remove things like parseutils from prelude, but I think having /prelude/ be the core module, and having a core set of submodules which we make by default something to consider |
| 21:51:20 | ldlework | having to import basic functionality of the language in every file is very unfriendly |
| 21:51:48 | flaviu | Nim is targeting a lot of areas |
| 21:52:02 | flaviu | what is friendly for one area is unfriendly for another. |
| 21:52:20 | ldlework | Having methods available for basic types is unfriendly to what exactly? |
| 21:53:32 | ldlework | It would let us remove things from system nim |
| 21:53:50 | ldlework | and come up with more competent 'sequtils' module, that actually includes all the stuff related to sequences in the language |
| 21:54:43 | ldlework | you'd only need just a few modules, but strutils and sequtils seem obvious |
| 21:55:36 | flaviu | I'm not looking to argue right now, but you should keep in mind the audiences that nim targets. I'm not necessarily saying that pop(seq[T], int) is a bad idea |
| 21:55:50 | ldlework | flaviu: sure I'm just asking for you to tell me who exactly you're alluding to |
| 21:56:18 | ldlework | I'm open to your reason, but do have any specific usecase for nim that would be damaged by having sequtils and strutils part of the 'core' ? |
| 21:56:48 | * | rpag joined #nim |
| 21:56:54 | flaviu | scripting languages want everything to be included by default, other kinds of languages might not. |
| 21:57:03 | ldlework | I'm not saying everything. |
| 21:57:10 | ldlework | that's characterizing what I'm saying as an extreme |
| 21:57:14 | flaviu | There's lots of stuff in strutils that doesn't need to be imported by default. |
| 21:58:08 | flaviu | I'm not trying to attack you, sorry if it came across that way. I used everything for dramatic effect. |
| 21:58:13 | ldlework | I don't really see anything in strutils that doesn't smack of an operation on a basi type |
| 21:58:33 | ldlework | you have strings, and you want to be able to do things with them |
| 21:59:02 | Araq | toUpper doesn't even support unicode, you have to use the unicode module for that |
| 21:59:08 | ldlework | its like saying, well we should split up strutils into different modules, because when I want to have $ I don't really need all the other stuff in that module |
| 21:59:19 | Araq | there are of course good reasons for this |
| 22:00:04 | Araq | but I think some people will rage when the "core" toUpper is hostile to unicode |
| 22:00:31 | Varriount|Busy | *hiss* |
| 22:00:48 | ldlework | I think its easy to explain that the core itself is 'hostile' (really?) to unicode |
| 22:00:57 | ldlework | In that you have to use the unicode module for that |
| 22:01:39 | flaviu | capitalize, normalize, cmpIgnoreStyle, wordWrap, addSep, abbrev, quoteIfContainsWhite, replaceWord, escape, unescape, validIdentifier, |
| 22:02:00 | flaviu | I'd say that most if not all of those are too specialized |
| 22:02:11 | Araq | not to mention that strutils itself will be the primary target of "mimic types" |
| 22:02:20 | ldlework | Let's clean up strutils! |
| 22:02:22 | Araq | and TR macros |
| 22:02:37 | flaviu | ldlework: I'd have no problem with that. |
| 22:02:39 | Araq | and moving that to the core is not wise at all |
| 22:02:43 | ldlework | or even just create a new module called "strings" |
| 22:02:50 | ldlework | which has basic core functionality for strings |
| 22:02:54 | ldlework | that is the thing we include in the new prelude |
| 22:03:03 | ldlework | and take the stuff from strutils that makes sense to be there |
| 22:03:08 | ldlework | and same from system.nim |
| 22:03:15 | ldlework | leave actual obscure utils to strutils |
| 22:03:44 | ldlework | but strings should be Pretty Usable by default without an import in every single file |
| 22:03:49 | ldlework | same with sequences |
| 22:04:01 | ldlework | I don't think we should massively expand core |
| 22:04:13 | ldlework | I think we should make the basic types, basically usable by default |
| 22:04:22 | ldlework | and do that without simply inflating system.nim |
| 22:04:24 | Araq | they are pretty usable for me the way they are. I don't import sequtils fwiw |
| 22:04:30 | ldlework | instead make a way we can remove things from system.nim |
| 22:04:36 | * | loz quit (Ping timeout: 250 seconds) |
| 22:04:43 | ldlework | okay, lucky you |
| 22:04:48 | ldlework | I import these all over the place |
| 22:05:03 | Araq | well for you we have: |
| 22:05:07 | Araq | include prelude |
| 22:05:11 | ldlework | all over the place |
| 22:05:18 | ldlework | "import basic_language_features" |
| 22:05:26 | flaviu | ldlework: not a big deal |
| 22:05:30 | flaviu | see perl, javascript |
| 22:05:35 | ldlework | yes |
| 22:05:41 | ldlework | aspiring to the greats |
| 22:06:04 | ldlework | says the guy who doesn't think strutils and sequtils are all that important to the apparent second hand citizen |
| 22:06:07 | Varriount|Busy | You know, we could split up system.nim into more implicitly imported modules. |
| 22:06:11 | ldlework | how's that for dramatic effect |
| 22:06:20 | ldlework | :) |
| 22:06:29 | flaviu | I think that the stdlib needs a complete overhaul |
| 22:06:58 | flaviu | I won't elaborate more on that though, I need to get work done. |
| 22:07:29 | ldlework | I wonder if it could be made so that you could tell the compiler any file to use as the 'core' |
| 22:07:42 | ldlework | then people could make competing stdlibs ;{ |
| 22:08:04 | Araq | that worked very well for D ... |
| 22:09:25 | Araq | btw that feature already exists |
| 22:09:39 | Araq | but it's not well documented |
| 22:10:19 | Araq | --import:PATH add an automatically imported module |
| 22:10:21 | Araq | --include:PATH add an automatically included module |
| 22:11:11 | Araq | but then you have to add this single line to the config file of every of your projects... that's 10 lines for 10 projects. pure madness! ;-) |
| 22:11:41 | flaviu | Araq: Fork Nim with a one line diff! |
| 22:13:05 | ldlework | Araq: I was just kiddin :) |
| 22:14:49 | ldlework | Araq: if you import sequtils and strutils and then don't use anything from them, does dead code elimination work over them? |
| 22:14:53 | Varriount|Busy | flaviu: While the stdlib may need some reviewing and revising, the unfortunate truth is that we lack the resources required for such a project. |
| 22:15:12 | ldlework | Varriount|Busy: I am totally down and capable of moving stuff around |
| 22:15:32 | flaviu | Varriount|Busy: It'd be much easier if writing everything in Nim wasn't a core criterea |
| 22:16:04 | Araq | flaviu: lol. yeah the stdlib should have written in Python |
| 22:16:11 | Araq | *have been |
| 22:16:17 | ldlework | Araq: is that a dig against Monte? |
| 22:16:33 | Araq | no. |
| 22:16:51 | Araq | I don't even know what Monte is |
| 22:17:18 | ldlework | Araq: remember the language based on E that dash and simpson are writing |
| 22:17:20 | flaviu | Araq: You keep saying that, yet I've probably used less python than you have. |
| 22:17:24 | ldlework | I invited you to talk with them for a little bit |
| 22:17:38 | ldlework | Araq: no worries |
| 22:17:58 | ldlework | I do think that Nim should take various queues from Python |
| 22:18:06 | Araq | flaviu: the build bot is now python based. I still have no 'diff' feature |
| 22:18:20 | ldlework | ques* |
| 22:18:23 | ldlework | cues* |
| 22:18:26 | ldlework | heh |
| 22:18:38 | flaviu | I was going to make a joke about that, but i can't spell queues |
| 22:19:04 | flaviu | Araq: That has nothing to do with python. I never said python was ideal. |
| 22:19:38 | flaviu | All I said is that python has a lot more experience, and that having similar interfaces would not be a bad thing. |
| 22:19:59 | ldlework | I want to say something about this |
| 22:20:39 | ldlework | I come to Nim from a long time writing Python and I originally picked Python long ago because of the productivity it gave me |
| 22:21:12 | ldlework | And I come to Nim having yearned for something more strongly typed to benefit from compiler technology to be even more productive |
| 22:21:20 | ldlework | And I was told that I was supposed to like Golang |
| 22:21:40 | ldlework | And I've said stuff about this before regarding how its unfortunate that Golang lacks this or that and in my opinon for the wrong reasons |
| 22:21:53 | ldlework | But Nim is instantly attractive because it serves the programmer in all the right places |
| 22:21:59 | gokr | Araq: Regarding hos useful the basic types are - with a different point of view (like say a Smalltalker's view) they are very anemic. |
| 22:22:10 | ldlework | it uses 'nicest' implementation of things like generics and templates and macros and so on |
| 22:22:16 | gokr | (I think that's the right word) |
| 22:22:17 | ldlework | it feels modern in those respects |
| 22:22:40 | ldlework | the language is very clean overall and gives you that same comfortable productivity feeling that python does |
| 22:23:03 | ldlework | and all I want to put forth is that we should really strive to take the "modern excellecence" path when we can for any aspect of the project |
| 22:23:06 | EXetoC | the dynamic typing bugs me |
| 22:23:23 | ldlework | from the package manager, to the module system, to our language features, to our documentation |
| 22:23:47 | ldlework | EXetoC: same here, its very nice for most things but you eventually get tired of the runtime rain dance |
| 22:23:57 | ldlework | Like |
| 22:24:09 | ldlework | I understand flaviu's point that some people will want to use Nim for like embedded systems and so on |
| 22:24:20 | flaviu | when did I say that? |
| 22:24:28 | ldlework | flaviu: you said 'other usecases' |
| 22:24:35 | ldlework | and then you constrasted against 'scripting languages' |
| 22:24:38 | ldlework | so I thought of a lean usecase |
| 22:24:44 | ldlework | I didn't mean to put words in your mouth |
| 22:24:51 | ldlework | but in anycase |
| 22:24:55 | ldlework | don't embedded systems programmers wants a really really nice language for doing that? |
| 22:24:57 | flaviu | I suppose that's another usecase, I was thinking more of bigger projects. |
| 22:24:59 | EXetoC | people say there's no silver bullet, but you can achieve so much with modern languages |
| 22:25:13 | ldlework | I want to be able to teach my girlfriend Nim |
| 22:25:21 | ldlework | in the same hope that I could probably get away with teaching her Python |
| 22:25:34 | ldlework | but I also want Nim to underly the important systems in the next 30 years |
| 22:25:37 | ldlework | so all I'm saying is |
| 22:26:02 | ldlework | lets not decide on how a feature looks for feels based on anything than trying to achieve what many languages do in many things |
| 22:26:08 | ldlework | but none get all of them right |
| 22:26:22 | ldlework | (we wont either, but we should establish a community standard and heading) |
| 22:26:47 | Araq | ldlework: we're stablizing (is that even a word?) the language and the stdlib for version 1.0 |
| 22:26:58 | ldlework | I know |
| 22:27:14 | Araq | that is our priority. usually versio n 1.0 of anything is crap anyway |
| 22:27:17 | ldlework | But we have a long future and I think its perfectly pertinent timing |
| 22:27:25 | ldlework | to make this call |
| 22:27:32 | gokr | IMHO the important thing is to make Nim "non hostile" to organic growth of libs. In other words, if someone wants to extend say string with a bunch of stuff, it should be easy for them to do so - and easy for others to use that "extension module" - even though its non standard - without things falling apart. Perhaps all is dandy on that front? |
| 22:27:53 | ldlework | I'm thinking more like |
| 22:27:59 | ldlework | think of a programming convention fair |
| 22:28:03 | ldlework | and people are walking by |
| 22:28:41 | ldlework | I'm talking about how Nim doesn't have glaring clunkyness that has been solved in the past by previous languages |
| 22:28:50 | ldlework | When you sit down at the Go booth you're "Ooh this is nice" |
| 22:29:07 | ldlework | but it takes like 5 minutes to find the glaring idosyncacies built into Golang |
| 22:29:29 | * | nimnoob quit (Ping timeout: 252 seconds) |
| 22:29:29 | ldlework | and your immediate thought is, why did they step backwards when this very thing has been implemented fantastically here and here |
| 22:29:46 | EXetoC | gokr: falling apart how? |
| 22:30:31 | ldlework | If you're having a hard time knowing what I mean |
| 22:30:36 | ldlework | and it sounds too subjective |
| 22:30:38 | gokr | EXetoC: It was more like a question. Some language are very hard to "grow" like that (stdlibs) and others are very easy. |
| 22:30:38 | ldlework | just think |
| 22:30:44 | ldlework | Nim has gotten many things exactly right to this point |
| 22:31:01 | EXetoC | gokr: import the new module, and then just pretend that the new procs are members |
| 22:31:02 | ldlework | Many of Nim's features feel modern and highly usable which call in its strong productivity |
| 22:31:03 | gokr | EXetoC: AFAICT its fairly easy in Nim, but I am unsure of shadowing etc. |
| 22:31:28 | EXetoC | unless you then run into a collision |
| 22:31:40 | ldlework | Nim has gotten the hardest things right on this front that we should just strive to get all the rest of the no-brainer parts of the language and project to a level of modern excellence in a similar way |
| 22:31:44 | gokr | EXetoC: Yes, I know, just wondering if there are any "traps" I should be aware of. Like for example, the fact that == can't be overridden by an "abstract class". |
| 22:32:29 | gokr | EXetoC: And collisions, is there an easy way to "remap" things in order to use two conflicting modules? |
| 22:32:44 | * | gokr looking up lang manual... |
| 22:32:47 | Triplefox | I need to find time to actually use Nim more so that i can usefully contribute |
| 22:33:12 | ldlework | I call on us to bear the pain it takes to arrive at a hopefully slicker implementation of whatever doesn't already seem impressively modern and usable |
| 22:33:59 | EXetoC | gokr: I don't think so. it seems reasonable to have to resolve the conflict at the call site if necessary |
| 22:34:05 | EXetoC | gokr: well, you can exclude symbols upon importing |
| 22:34:10 | gokr | EXetoC: Well, you do have the "as" also. |
| 22:34:19 | * | tomasi joined #nim |
| 22:34:47 | gokr | Rigth, so those facilities are probably enough. |
| 22:35:31 | gokr | EXetoC: Regarding == - that was due to the fact that == is defined for "ref T" in system.nim (IIRC) and that will trumph a subtype relationship - so it can only be overridden in leaf types. |
| 22:35:47 | gokr | I just mentioned it as an example. |
| 22:38:10 | gokr | ldlework: Sorry to ask, but can you reiterate (or point) to the "question at hand"? |
| 22:38:18 | gokr | Been busy with christmas. |
| 22:38:51 | gokr | Is it about some mechanism - or about the slightly oddish current stdlib modules? |
| 22:40:04 | ldlework | gokr: Basically what I kind of dream of is a project where we all use our hard-headed sharp stubborness to lead the project unequivocally and uncomprimisingly to the 'obvious' best implementation or interface for any given aspect of the Nim project |
| 22:40:27 | gokr | hehe |
| 22:40:45 | gokr | And how many years have you been part of a programming language community? |
| 22:40:46 | ldlework | That we don't make any excuses for this or that hasn't been made to the ideal, using where that has been implemented incredibly "nicely" before |
| 22:41:14 | gokr | Perhaps I should add a smiley to that last question :) |
| 22:41:16 | ldlework | gokr: you mean the maintainence of the language itself? |
| 22:41:24 | gokr | Language and libs. |
| 22:41:37 | ldlework | Python for 15 years or so |
| 22:41:57 | ldlework | But that isn't really the point |
| 22:42:01 | gokr | And that didn't make you realize that what you dream of is ... quite hard to do ? |
| 22:42:07 | ldlework | Not at all |
| 22:42:21 | ldlework | Nim has gotten the hardest things already correct in the sense that I'm urging us to strive for |
| 22:42:29 | ldlework | Think of how awesome Nim's macros and generics already are |
| 22:42:32 | gokr | In your POV that is. |
| 22:42:38 | gokr | Perhaps not mine? |
| 22:42:44 | ldlework | In anyone here who loves Nim as much as I do |
| 22:42:50 | ldlework | as in, the Nim we have |
| 22:43:13 | gokr | I just mean that... "obvious best" is not that obvious. |
| 22:43:24 | ldlework | gokr: of course I understand that |
| 22:43:46 | gokr | Especially when you consider them "together" and just not one by one. |
| 22:43:58 | gokr | For example, macros... |
| 22:44:01 | ldlework | But this is the easiest way to forgive us for not arriving at a great solution |
| 22:44:06 | gokr | Seem fantastic, right? |
| 22:44:53 | gokr | And still, I cringed last night when I glanced at the quite long session hunting "bad gateway" and (I may be wrong) people were indeed wondering what code was actually running. |
| 22:44:58 | ekarlso- | no amqp lib for nim ? :'( |
| 22:45:13 | ldlework | gokr: I don't understand what you just said |
| 22:45:25 | gokr | So ok, macros in my mind is not 100% "good" |
| 22:45:41 | ldlework | That's fine, I'm not saying Nim's macros are ideal |
| 22:45:47 | Araq | gokr: I fail to see how macros have anything to do with this issue really |
| 22:45:48 | gokr | They are an example of an abstraction that increases the "gap" between what I write and what is running. |
| 22:45:55 | ldlework | I'm saying, compared to all the options available in the space that Nim occupies |
| 22:46:05 | Araq | it's not hard to output what they produce |
| 22:46:08 | ldlework | Nim's macros are *clearly* far and above in terms of being useful for doing things and getting word done |
| 22:46:13 | gokr | This "gap" can be amazingly powerful, but also cause hard debugging etc. |
| 22:46:30 | Araq | gokr: no. it's not. you output the generated code. |
| 22:46:41 | Araq | the tooling is already there but surely can get better |
| 22:46:45 | gokr | Ok, let me reformulate what I mean. |
| 22:46:50 | gokr | Take C++ for example. |
| 22:46:56 | ldlework | I would be very sad if I could get no one to agree with me that we should strive to make Nim exemplary in what it means for excellence in usability in modern programming design |
| 22:47:06 | gokr | You can probably argue that each and every single feature in that language is "good" |
| 22:47:12 | ldlework | and we got bogged down in relativism and specific issues |
| 22:47:18 | gokr | But the sum of it is a huge freaking mess. |
| 22:47:31 | Araq | gokr: no. you can't. and that is what makes all the difference. |
| 22:47:51 | gokr | Araq: Can you please just skip the details and understand my point instead? |
| 22:47:59 | ldlework | gokr: I would ask the same from you :/ |
| 22:48:01 | Araq | C++ wants to get rid of its C base but couldn't for politicial reasons |
| 22:48:13 | Araq | Nim has no such flawed base |
| 22:49:07 | gokr | ldlework: I do understand your point, at least I thought I did. |
| 22:49:07 | Araq | as a result C++ is full of features that not even Stroustrup defends |
| 22:49:10 | ldlework | I will just reiterate this sentiment from time to time and hope it has the change I intend |
| 22:49:26 | ldlework | and try the places I can best contribute |
| 22:49:32 | ldlework | try to find that is |
| 22:49:43 | gokr | ldlework: So you feel there is resistence? |
| 22:49:49 | gokr | (since you hope for some change) |
| 22:50:02 | ldlework | I feel like we make wierd forgivings for certain things |
| 22:50:23 | ldlework | And when I consider the resulting language as a whole it hurts me that such simple things are clunky when so much is right |
| 22:50:24 | gokr | ldlework: I was just trying to make the point that things that are "obvious good" to some people - are not to others. |
| 22:50:29 | Varriount|Busy | Like? |
| 22:50:48 | Varriount|Busy | ldlework: What things are clunky? |
| 22:50:55 | ldlework | Varriount|Busy: my actual concerns are very minor since I are overwhelmed by the goodness overall |
| 22:51:06 | ldlework | and I always mention the things I find are not smooth |
| 22:51:14 | ldlework | one thing is having to import basic features |
| 22:51:32 | gokr | Araq: I agree with that. But I still would argue that languages of such complexity - have an inherent problem in "complexity". |
| 22:51:37 | ldlework | I think our basic types should have their most generally useful methods available by default |
| 22:51:59 | ldlework | but I don't have any concerns that would make me stop using Nim overall |
| 22:52:03 | * | skyfex quit (Quit: (null)) |
| 22:52:11 | ldlework | but there are definitely things that will make me embarassed at the Nim booth at the language fair |
| 22:53:24 | gokr | I share your view that our basic types are anemic. Which is why I hope someone (like myself for example) will make newer libs that make them less so - and eventually such libs can trickle into stdlibs. |
| 22:53:25 | ldlework | its hard to both give a strong call to modern excellence without giving up how strongly I do already like 90% of Nim in a way where I wouldn't change anything about it |
| 22:53:46 | ldlework | "don't get me wrong" |
| 22:53:48 | ldlework | :) |
| 22:53:52 | ldlework | gotta go! |
| 22:54:09 | Araq | gokr: I argue that "complexity" doesn't mean much if anything. Algol was so complex people struggled to implement it. |
| 22:54:18 | Varriount|Busy | ldlework: I agree with you on that. The problem is that it's hard to quantify 'basic features' |
| 22:54:30 | Araq | whereas nowadays it would seem like a basic language, really. |
| 22:55:12 | Araq | function calls/if/for/while are a lot of features for what used to be 'goto' |
| 22:55:51 | Araq | Windows XP is bloated for its time, now it's pretty barebones |
| 22:55:56 | Araq | *was |
| 22:56:08 | gokr | Araq: Let's just agree then that you and a big part of the programming world differ :). The question of C++ and complexity is quite obvious IMHO. |
| 22:56:11 | ldlework | Varriount|Busy: join, split, intToStr, parseInt, startsWith, endsWith, find, count, % and a few others all *really nice things* to have at hand |
| 22:56:37 | Araq | gokr: C++'s biggest problem is not the complexity, whatever that means. it's its unsafety. |
| 22:56:41 | ldlework | I just feel like, we have a fundamental problem with system.nim |
| 22:56:45 | gokr | Araq: I beg to differ. |
| 22:56:53 | * | Demos joined #nim |
| 22:57:05 | Araq | yeah but I see no arguments, sorry. all I see is "everybody agrees with me" |
| 22:57:24 | Araq | well I don't and I have given lots of good examples at least. |
| 22:57:29 | * | Ven joined #nim |
| 22:57:37 | Varriount|Busy | ldlework: Perhaps we could use other languages as a 'guide' to what should be in system.nim? |
| 22:57:37 | gokr | I have seen so many big projects struggle with that complexity and just ending up burning money. Complexity is key. |
| 22:57:40 | ldlework | that if we didn't have to rely on system.nim, and the 'core' language could be built from refactored seprate modules we wouldn't have a hard time saying, "okay fine lets put the things that most other languages agree are the core methods on these basic types and put them in a string.nim module and put the other funky stuff in a non core strutils module" |
| 22:57:55 | ldlework | Varriount|Busy: definitely |
| 22:58:07 | ldlework | Varriount|Busy: this is a core strategy in how I think we will find that 'modern excellence' |
| 22:58:28 | ldlework | Varriount|Busy: taking the average of the best prior art, and then seeing if we can improve anywhere and if not taking the average |
| 22:59:04 | ldlework | hoping that Araq's taste gives good direction on the 'improve anywhere' step |
| 22:59:14 | Epic|gmpreussner | Varriount|Busy: can you hook me up with an account for the build farm? i set up an armv6 build slave and will add an armv7 as well, possibly also an armv6-bigendian, but that may take a while |
| 22:59:41 | * | Epic|gmpreussner is now known as gmpreussner |
| 23:00:06 | Varriount|Busy | Epic|gmpreussner: Sure, will do. Give me a bit. I have to update a couple files. |
| 23:00:29 | gokr | ldlework: Smalltalk is an interesting "counter point". There the base libraries have grown over time - and are vastly richer than those in most other languages. So rich in fact that the other end of the spectrum starts being a problem too. |
| 23:01:41 | Araq | gokr: and yet these projects are all in C or C++ or Java or C#. Some languages you would consider "simple", I think. software architects can overengineer anything |
| 23:02:02 | gokr | Actually, I don't consider Java or C# "simple". |
| 23:02:10 | * | skyfex joined #nim |
| 23:02:11 | Araq | but perhaps C? |
| 23:02:43 | gokr | C is not really "simple" as in "programmer Joe makes productive stuff" - the correct word would be "primitive". |
| 23:03:57 | gokr | I have programmed in very big Java projects (aargh!) and a fairly big C# product (very similar but slightly better than Java). And seen several big C++ projects. |
| 23:04:05 | ekarlso- | Araq: does nim have a amqp lib ? can't seem to find any :/ |
| 23:04:06 | gokr | And lots and lots of these stagger under complexity. |
| 23:04:24 | gokr | Thing is - you will probably say "A good programmer can use any language". |
| 23:04:40 | gokr | Because you remind me of a friend of mine - that is a brilliant coder. |
| 23:04:46 | EXetoC | must be fun to debug complex class hierarchies |
| 23:04:55 | ldlework | I must be a horrible programmer |
| 23:04:59 | gokr | Problem is - the real world doesn't consist of "good programmers". |
| 23:05:07 | ldlework | Because I hate when a programming language makes me do stupid shit orthogonal to my goal |
| 23:05:13 | ldlework | and many languages do that |
| 23:05:27 | gokr | The real world has the whole freaking spectrum of idiots to geniuses. But idiots are clearly in numerous advantage. |
| 23:05:32 | * | irrequietus quit () |
| 23:05:53 | Araq | gokr: Java was designed for the average developer though. |
| 23:06:18 | Araq | really, it was. and yet it solved nothing for you |
| 23:06:18 | gokr | Now... given 10 programmers "at random". And you pick C++ or say Smalltalk or Python. Then in C++, 2 will make good code - 3 will make fair code - and the other 5 will sink the project. |
| 23:06:36 | def- | ekarlso-: there is https://github.com/def-/nim-nanomsg in that direction |
| 23:06:54 | gokr | In Python, the numbers are better - and thus makes the chance of success much higher. |
| 23:07:05 | ekarlso- | def-: booo :( |
| 23:07:10 | gokr | Araq: I know the history of Java very well. |
| 23:07:22 | gokr | And yes, it was pruely silly to begin with. |
| 23:07:27 | gokr | purely. |
| 23:07:43 | gokr | And at that point in time - the "applet" time - it was quite simple. |
| 23:07:56 | gokr | But hehe, that soon changed :) |
| 23:08:41 | gokr | It was actually designed for embedded use, applets was just a ... "hey, at least we can use it for this". |
| 23:10:36 | Araq | I cannot see how a language which embraces reference types (class) everywhere can count for "embedded use", especially at that time |
| 23:11:10 | Araq | it's so obviously a misdesign for that niche that it hurts my brain |
| 23:14:44 | gokr | Well, it was "embedded" as in ... tv set top boxes etc. |
| 23:14:55 | gokr | Home electronics. |
| 23:15:13 | gokr | Not "miniscule realtime in your shaver" stuff. |
| 23:15:23 | * | Demos quit (Read error: Connection reset by peer) |
| 23:15:44 | * | Demos joined #nim |
| 23:17:26 | gokr | Araq: Well, its all about how small you go on the embedded scale. |
| 23:18:10 | gokr | OOVM for example, by Lars Bak, was built primarily for embedded use, and in fact, Smalltalk has been used by Tektronics in their oscilloscopes back in the REALLY early days. |
| 23:18:21 | gokr | So sorry, that argument of yours is really wrong too. |
| 23:18:29 | gokr | ;) |
| 23:18:58 | Araq | I don't see how "stupid people pay for stupid things and make less money than they could" invalidates my argument |
| 23:19:34 | gokr | Its not stupid just because you don't know about it, you know. |
| 23:19:56 | * | Demos quit (Read error: Connection reset by peer) |
| 23:20:05 | gokr | Smalltalk and Lisp are quite suitable for some specific kinds of embedded systems. |
| 23:20:16 | * | Demos joined #nim |
| 23:20:18 | gokr | Since its easy (like Forth) to make them really small. |
| 23:20:42 | gokr | And debug live, hot load code etc etc. |
| 23:21:52 | Araq | they are less suitable than any language with more control over memory layout would have been. |
| 23:22:32 | Araq | they are however suitable when you only look at the sizes of your (byte) codes |
| 23:23:17 | Araq | and when you ignore your runtime data. and since that's an easy mistake to make, it is exactly what happened |
| 23:23:43 | Araq | since you can easily measure code size, but "used memory when the program runs" is harder to measure |
| 23:25:42 | ekarlso- | Araq: i hope to see nim penetrate network services too |
| 23:25:46 | ekarlso- | a'la go style |
| 23:26:08 | gokr | Tektronix 11xxx series of sampling oscilloscopes used a 68000 CPU and was built with embedded Smalltalk. They used Smalltalk for several of their oscilloscope products during many years. |
| 23:26:29 | Triplefox | I think i have a nim project i might try...voxel renderer, make a game multicart that exercises it in various ways |
| 23:27:10 | gokr | And just claiming they are "less suitable" than "any language blabla" - you can't make that claim, because you don't know the prerequisites of those projects. |
| 23:27:55 | gokr | I would ask for some humblepie here. |
| 23:30:18 | * | kayph joined #nim |
| 23:30:18 | Araq | I'm not claiming that Tektronix did a mistake with choosing Smalltalk. |
| 23:30:43 | Araq | I'm claiming that Java's design is obviously wrong. |
| 23:30:58 | Araq | and I still got not a single argument against that. |
| 23:31:04 | gokr | Well, I claimed that it wasn't "obvious" and I gave prior art too. |
| 23:31:16 | gokr | Smalltalk is also fully ref based. |
| 23:31:18 | Araq | it's "Java as is" vs "Java as it could have been" |
| 23:31:31 | gokr | And it was obviously used successfully in embedded use. |
| 23:32:15 | gokr | There was a Smalltalk for the Palm Pilot too in fact. IIRC the interpreter was 19kb or so. |
| 23:32:46 | Araq | so again you bring up *code* sizes |
| 23:32:51 | gokr | Anyway, I gotta hop to bed. It seems all I did here was claiming things aren't "obvious" :) |
| 23:32:59 | Triplefox | There are lots of examples of high level interpreters on tiny devices |
| 23:33:15 | Triplefox | But most engineers decide to go with extra headroom |
| 23:33:34 | Araq | hi kayph welcome |
| 23:33:41 | Triplefox | You never know if the specs will change and make you redline the hardware |
| 23:33:54 | ekarlso- | whaaat, another swede! |
| 23:34:03 | EXetoC | awesome |
| 23:35:30 | gokr | Araq claims a fully ref based language (like Java) was "so obviously a misdesign for that niche that it hurts my brain". Then I explained that Smalltalk has been successfully used in several embedded use cases - like Tektronix oscilloscopes. In 1980s. |
| 23:35:55 | gokr | ekarlso-: Another? |
| 23:36:17 | ekarlso- | kayph: host bredband2.com |
| 23:36:19 | gokr | So anyway, I just don't think the world is "black and white". |
| 23:36:22 | Araq | gokr: Java is not even fully ref based |
| 23:36:23 | ekarlso- | :o |
| 23:36:46 | gokr | Araq: Sure. |
| 23:37:23 | Araq | it gave up the simplicity of "only ref based typing" without gaining all its benefits |
| 23:37:42 | Araq | so yes, it was obviously wrong. |
| 23:38:07 | gokr | Oh, the design of Java being bad? Sure. |
| 23:38:26 | gokr | But you didn't write that. |
| 23:38:41 | gokr | Anyway, not very productive discussions :) |
| 23:38:51 | Araq | indeed |
| 23:39:27 | skyfex | Can't we all just agree that we don't like Java? :P |
| 23:39:36 | gokr | And given that I know you have borrowed good stuff from all over the place - I think you can appreciate "good stuff" even if its from a place like Smalltalk. |
| 23:39:50 | EXetoC | skyfex: yes! |
| 23:39:51 | gokr | skyfex: Hehe, that was never up for debate. |
| 23:40:24 | ekarlso- | yet so many people love java :P |
| 23:40:32 | gokr | I hated it when it came because it was braindead, and then I hated it when it turned into an inexplicable beast worshipping the church of complexity. |
| 23:40:41 | EXetoC | skyfex: I don't have to use it before hating it, right? same for php, yeah? |
| 23:41:45 | Varriount|Busy | ekarlso-: I think lots of beginner programmers love java, because they don't know anything else. |
| 23:42:22 | Varriount|Busy | It's still the first language usually taught in beginner comp. sci courses |
| 23:42:37 | ekarlso- | Varriount|Busy: i love python ;) |
| 23:43:04 | ekarlso- | and now starting to like nim since it feels alike |
| 23:43:13 | gokr | Its also ... a community in which people gain "respect" etc by making stuff overly complicated. They worship it. Because it makes them local "Gods". Factory Factories producing abstract little factories injected with some dependency crap. |
| 23:43:15 | Varriount|Busy | ekarlso-: As do I. Was python taught in your first computer science class? |
| 23:43:35 | ekarlso- | Varriount|Busy: never been to a computer science clas ;) |
| 23:43:40 | gokr | gnite folks |
| 23:43:42 | ekarlso- | I got no degree nor will I ever : ) |
| 23:43:52 | * | yglukhov_ quit (Quit: Be back later ...) |
| 23:43:55 | tomasi | Sorry guys, I'm looking for some information in the documentation regarding the C FFI but am not able to find it. |
| 23:43:59 | Triplefox | When i took cs they started in java but i was learning python at the same time |
| 23:44:06 | ekarlso- | self-taught Varriount|Busy |
| 23:44:07 | Triplefox | I did assignments twice |
| 23:44:08 | tomasi | I am writing bindings to "libtermkey" (http://www.leonerd.org.uk/code/libtermkey/), which has this complex "TermKeyKey" struct. Such struct is meant to be statically allocated, and initialized by functions which accept a "TermKeyKey *" argument. |
| 23:44:37 | tomasi | Fields of such structure are meant to be accessed directly. |
| 23:44:56 | ekarlso- | how the crap can I install aporia on osx.. |
| 23:45:02 | Triplefox | At the end they switched to c and made you redo an assignment there |
| 23:45:22 | tomasi | I think I need to make the "struct" fields visible from Nimrod, but I have no idea if there is a pragma for this |
| 23:45:41 | Araq | tomasi: how do you wrap it? 'dynlib' or 'header'? |
| 23:46:16 | tomasi | "header". It's a small C library, and I'm including the C sources in the same dir as the Nim sources, as it is not available under Ubuntu |
| 23:46:27 | tomasi | (via apt-get, I mean) |
| 23:46:53 | Araq | look at posix.nim of how to importc such objects/structs then |
| 23:47:01 | tomasi | Thanks a lot |
| 23:48:43 | ekarlso- | Araq: seen this before? http://pastebin.com/xZTXPLJ2 |
| 23:48:46 | ekarlso- | yosemite |
| 23:49:02 | * | gmpreussner_ joined #nim |
| 23:49:13 | * | gmpreussner quit (Ping timeout: 256 seconds) |
| 23:49:18 | Araq | ekarlso-: yes. |
| 23:49:27 | Araq | it means something is out of date |
| 23:50:26 | Varriount|Busy | gmpreussner_: What is the command that invokes the python 2.7 binary on your armv6 system? |
| 23:51:14 | ekarlso- | meh, now "aporia" cannot open display :/ |
| 23:51:47 | * | kayph quit (Remote host closed the connection) |
| 23:55:09 | ekarlso- | has anyone used aporia on osx ? |
| 23:55:44 | Araq | ekarlso-: yes |
| 23:56:17 | Araq | but maybe nodoby in #nim did :P |
| 23:56:21 | ekarlso- | Araq: it's failing here atm :/ |
| 23:56:24 | Araq | *nobody |
| 23:56:44 | ekarlso- | cannot open display :( |
| 23:56:46 | ekarlso- | booo |
| 23:58:08 | ekarlso- | Araq: clues ? |
| 23:58:47 | EXetoC | running it as root? |
| 23:58:57 | ekarlso- | EXetoC: no, should I + |
| 23:59:18 | tomasi | Goodnight to everybody |
| 23:59:36 | * | yglukhov_ joined #nim |
| 23:59:41 | * | tomasi quit (Quit: ERC Version 5.3 (IRC client for Emacs)) |
| 23:59:53 | Araq | ekarlso-: no. |