| 00:01:23 | reactormonk | IIRC openssl has some american certification such that they can use it in government projects or something |
| 00:02:10 | flaviu | reactormonk: They're free to use the version as of right now, but they'll have bigger problems. |
| 00:02:23 | reactormonk | Yup, pretty much |
| 00:02:23 | flaviu | Like major non-security. |
| 00:02:55 | will | has libressl really changed that much from openssl? |
| 00:03:32 | flaviu | will: nope, but they added a new library for ssl that is practically foolproof. |
| 00:03:33 | flaviu | http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/tls_client.3 |
| 00:04:09 | will | cheers, I'll check it out |
| 00:04:10 | * | Trustable quit (Remote host closed the connection) |
| 00:04:33 | reactormonk | will, they also kicked a lot of stuff |
| 00:04:45 | * | tinAndi quit (Quit: ChatZilla 0.9.91 [Firefox 33.1/20141106120505]) |
| 00:10:57 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 00:15:46 | * | vendethiel joined #nimrod |
| 00:23:16 | flaviu | > ldlework: what do you guys think of supporting multiple methods in a method bloc? like the type syntax. |
| 00:24:15 | ldlework | It seems like they should all work the same way |
| 00:24:47 | flaviu | > Araq: ldlework: has been requested for consistency but I dislike it |
| 00:24:56 | ldlework | lol |
| 00:25:01 | flaviu | > ldlework: Araq: I reformatted some of my code to use it assuming it would work and was shocked that it didn't |
| 00:25:09 | flaviu | > Araq: firstly, the average proc/method whatever should be longer than a type/var/const definition |
| 00:25:15 | flaviu | > ldlework: I assumed for implementation sake they all just did the same thing |
| 00:25:32 | flaviu | > Araq: secondly this is "more than 1 way to do it", so it's considered bad by everybody except the people with a brain |
| 00:25:41 | Araq | hey |
| 00:25:50 | ldlework | Araq: its already more than one way to do it though |
| 00:25:52 | ldlework | In both cases |
| 00:26:00 | flaviu | Araq: Someone will ask you this question again, and you'll have to explain it over again. Better for it to be in the irc logs. |
| 00:26:00 | ldlework | 'proc' and 'var' support single and multi declarations |
| 00:26:10 | ldlework | err s/proc/type |
| 00:26:28 | Araq | ldlework: yeah but 'type' has to because of mutually recursive deps |
| 00:26:44 | ldlework | Araq: sure, so you already have two different ways of doing it |
| 00:26:44 | * | Puffin joined #nimrod |
| 00:26:46 | ldlework | in that sense |
| 00:26:51 | EXetoC | you could forward declare types too though, right? |
| 00:26:53 | Araq | and 'const' has to because I like it too much this way |
| 00:27:03 | Araq | EXetoC: currently you cannot |
| 00:27:21 | Araq | and 'var' and 'let' are for consistency with 'const' ... |
| 00:27:38 | * | Etheco quit (Quit: Leaving) |
| 00:27:48 | ldlework | 1) type/var/let/const already have 2 ways of doing things (single, multi) 2) nim itself already has two ways of doing things (it has two classes of syntax that look exactly the same) |
| 00:27:51 | dts | since the irc module is unstable should i use the socket one instead? |
| 00:28:10 | ldlework | IE, type vs proc |
| 00:28:28 | Araq | dts: the IRC module on devel is stable I think |
| 00:28:36 | dts | ok. cool. ty |
| 00:28:38 | ldlework | organizing a type's methods into a single clause, especially if the methods are short *looks really nice* |
| 00:28:55 | dts | Araq, so is there a more updated page than this then? http://nimrod-lang.org/irc.html |
| 00:29:04 | EXetoC | ldlework: pragma to the rescue :> |
| 00:29:11 | ldlework | EXetoC: huh? |
| 00:29:11 | flaviu | ldlework: Macro! Although it is a questionable use. |
| 00:29:12 | EXetoC | I think |
| 00:29:20 | flaviu | EXetoC: Nope, he wants a macro |
| 00:29:27 | Araq | can't be done with a macro |
| 00:29:27 | EXetoC | that's what I meant |
| 00:29:32 | ldlework | I really don't want to include a macro in all of my projects anyway for this |
| 00:29:38 | EXetoC | flaviu: I blame me keyboard, or something |
| 00:29:39 | ldlework | It just seems natural |
| 00:29:53 | Araq | ldlework: I will consider to add it |
| 00:30:04 | ldlework | Araq: imagine if I had guessed right |
| 00:30:07 | EXetoC | is that worse than using a built in thing? |
| 00:30:12 | EXetoC | it'd be less standard though |
| 00:30:13 | ldlework | that would have been a 'holy shit that's intuitive' |
| 00:30:23 | Araq | yeah, got it |
| 00:30:25 | ldlework | having never had seen any example of it being used (since well it doesn't exist) |
| 00:30:46 | flaviu | Araq: It's almost possible! |
| 00:30:55 | flaviu | you just can't use return statements. |
| 00:31:11 | Araq | flaviu: well it is possible if you put it into """ """ |
| 00:31:48 | EXetoC | what is? |
| 00:32:03 | flaviu | A macro to allow blocking functions |
| 00:32:14 | flaviu | textual block |
| 00:32:31 | flaviu | If you use `:` instead of `=`, everything works. |
| 00:34:27 | Araq | ldlework: however, your methods really should be longer so that "method sections" are not required |
| 00:34:47 | Araq | and don't give me that "clean code" bullshit |
| 00:34:57 | * | Sembei joined #nimrod |
| 00:35:11 | Araq | there is nothing clean about jumping around 20 different modules where every function is only 1 line long |
| 00:35:37 | dts | Araq, is there a more up to date version of the irc module? |
| 00:35:50 | flaviu | Araq: It actually works fairly well with an excellent IDE. |
| 00:36:14 | Araq | flaviu: no, it doesn't. |
| 00:36:37 | Araq | no other form of writing has ever been done this way in human history |
| 00:37:06 | ldlework | Araq: man, I am a DRY nazi and I refactor the shit out of my code |
| 00:37:07 | reactormonk | Araq, coding has no predecessor in human history |
| 00:37:12 | Araq | just imagine a book would have been written in this style |
| 00:37:22 | ldlework | Araq: this is a bad equivalence |
| 00:37:29 | ldlework | err equivocation* |
| 00:38:17 | ldlework | My code should be easily understandable in small chunks as to reduce the cognitive cost and to allow for better unit testing |
| 00:38:38 | Araq | your small chunks are too small to see the bigger picture |
| 00:38:42 | ldlework | If there is a bug in a one line function, I don't need to understand 40 other lines just to satisfy Nim's long-function culture :P |
| 00:38:49 | Araq | instead I only see the irrelevant details |
| 00:38:58 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:38:59 | ldlework | Araq: says you since you're imagining the illogical extreme of someone's position you don't agree with :) |
| 00:39:52 | Araq | and how do you find the bug without the big picture in the first place? ah don't bother, I don't care |
| 00:40:07 | ldlework | Araq: how big should the picture be? Its arbitrary. |
| 00:40:19 | Araq | it should be as big as possible |
| 00:40:29 | ldlework | Araq: come on.. |
| 00:40:37 | ldlework | Anyway, my argument comes from the fact that the two things look the same, they'd work just as well, working the same too |
| 00:40:38 | flaviu | Araq: There's a reason people don't like to mess around in the compiler. |
| 00:41:31 | ldlework | I don't think having them work the same encodes a hidden suggestion to users of Nim how long their functions should be |
| 00:41:48 | ldlework | How it works now, or how I propose it works. It just looks and seems nicer that it is congruent. |
| 00:42:14 | flaviu | https://github.com/Araq/Nimrod/blob/devel/compiler/vm.nim#L375-L1329 is very much on the long side. |
| 00:42:59 | ldlework | If each section was deferred to a function, I could understand the structure of that function without having to see the implementation details of each case.. |
| 00:43:10 | ldlework | But for now I'll just close the tab. :) |
| 00:47:14 | Araq | flaviu: the vm has many instructions. oooohhh big deal. |
| 00:47:59 | ldlework | Araq: if someone offered to refactor that would you turn them down? |
| 00:48:19 | * | hguux_ quit (Ping timeout: 272 seconds) |
| 00:48:46 | flaviu | Araq: I can find more than a few more 100+ line procedures. |
| 00:49:24 | flaviu | s/more 1/1/g |
| 00:49:35 | * | CARAM_ quit (Ping timeout: 272 seconds) |
| 00:49:36 | * | endou_____ quit (Ping timeout: 272 seconds) |
| 00:49:51 | * | hguux_ joined #nimrod |
| 00:50:24 | Araq | python's vm is also quite long |
| 00:50:24 | Araq | Lua's is smaller but uses the same structure |
| 00:50:24 | Araq | depends on the refactoring |
| 00:50:24 | Araq | refactor it with templates and macros and I will accept it |
| 00:50:24 | Araq | refactor it like it's java and I will refuse it |
| 00:50:25 | Araq | you can't find one that's not downright trivial though |
| 00:50:26 | Araq | look at the control flow, dude |
| 00:50:26 | Araq | not at the number of lines |
| 00:51:01 | * | c74d is now known as Guest29672 |
| 00:51:01 | * | Guest29672 quit (Killed (morgan.freenode.net (Nickname regained by services))) |
| 00:51:45 | * | endou_____ joined #nimrod |
| 00:52:17 | ldlework | Araq: if each case called out to a function, I'd be able to understand the control flow -at a glance- |
| 00:52:40 | ldlework | Here, I can't really be sure if this switch breaks in the middle and starts a new switch, or if its just one large one or what |
| 00:52:55 | Araq | oh really? why do you even use 'method' then? |
| 00:53:01 | ldlework | uh? |
| 00:53:04 | ldlework | huh? |
| 00:53:29 | Araq | a method is simply a non-local goto with some parameter passing capabilities |
| 00:53:37 | * | CARAM_ joined #nimrod |
| 00:53:39 | ldlework | sure, so? |
| 00:53:43 | Araq | you cannot understand the control flow at all |
| 00:53:45 | Araq | with these |
| 00:53:49 | ldlework | Sure you can |
| 00:53:59 | wan | I'm with Araq on that one. I hate going full turtles all the way down to understand an implementation |
| 00:53:59 | ldlework | I can understand the structure of -this- function |
| 00:54:08 | ldlework | independently of the structure of individual cases |
| 00:54:17 | Araq | I'm pretty sure you can't since the compiler cannot either |
| 00:54:25 | ldlework | I have no idea what you're talking about |
| 00:54:37 | * | flaviu quit (Read error: Connection reset by peer) |
| 00:54:39 | ldlework | if you stuck a function call inside each of those cases, why would that somehow break the compiler |
| 00:54:53 | Araq | well try it out then |
| 00:55:19 | ldlework | I mean I see functions being called, in the cases |
| 00:56:12 | ldlework | I guess your point is over my head |
| 00:56:41 | * | flaviu joined #nimrod |
| 00:56:47 | flaviu | I'd be very happy with array[Opcode, proc(...): ...] and then just running stuff from the table |
| 00:56:56 | Araq | yeah I bet |
| 00:57:20 | flaviu | That way you make what happens explicit, while you keep that conciseness that you really like. |
| 00:58:48 | * | c74d joined #nimrod |
| 00:58:56 | Araq | there is a trivial bijection between the case statement and your array solution so I don't see how anybody can think it's "better" |
| 00:59:59 | * | vendethiel quit (Ping timeout: 244 seconds) |
| 01:00:01 | Araq | except that of course your proc() solution uses closures everywhere and will be slower |
| 01:00:59 | flaviu | The advantage is that it proves that each case doesn't do anything weird. |
| 01:00:59 | flaviu | re. performance, my benchmarks say that there is a negligible difference between calling a function pointer and a regular function. |
| 01:00:59 | ldlework | Araq: I can also see the requirement of passing all the required locals to my function based case solution being pretty annoying to read too I guess |
| 01:01:53 | ldlework | flaviu: what do you mean 'doesn't do anything wierd' |
| 01:02:35 | flaviu | ldlework: Have things that modify the control flow of the loop. |
| 01:02:49 | ldlework | gotcha |
| 01:03:06 | flaviu | Or accidentally modify the opcodes, I guess. |
| 01:03:21 | * | c74d is now known as Guest2381 |
| 01:03:27 | * | saml_ joined #nimrod |
| 01:04:09 | Araq | ldlework: and now you know why only more macros/templates can improve this code |
| 01:04:24 | ldlework | I do? |
| 01:04:34 | * | Guest2381 quit (Ping timeout: 258 seconds) |
| 01:04:49 | ldlework | flaviu's suggestion seems reasonable, if the perf is negligible like he said |
| 01:04:57 | ldlework | the safety improvement seems nice |
| 01:04:58 | * | Boscop_ is now known as Boscop |
| 01:05:04 | flaviu | Araq: My solution would avoid both. I don't think Nim requires that function pointers be closures, does it? |
| 01:05:04 | Araq | flaviu: of course some opcodes modify the control flow of the loop, that's the very nature of turing completeness |
| 01:05:50 | ldlework | Araq: yeah but with a call-result interaction, that modification is explicit |
| 01:05:56 | flaviu | Modify the program counter, fine. But not the loop. |
| 01:06:16 | wan | flaviu: the problem with your suggestion is that it adds a level of indirection. It's a tradeoff, sometimes it's good for long stuff to have it in it's own function, sometimes it's easier to have it all packed in a switch and see the similarities between opcodes |
| 01:06:16 | * | vendethiel joined #nimrod |
| 01:06:22 | Araq | flaviu: yes you can use .nimcall to ensure it doesn't become a closure |
| 01:07:03 | Araq | but go ahead and try it |
| 01:07:12 | ldlework | Araq: lol stop being mysterious |
| 01:07:15 | * | c74d joined #nimrod |
| 01:07:26 | Araq | I'm tired of telling people they obviously have no idea about anything |
| 01:07:35 | Araq | good night |
| 01:07:38 | ldlework | You don't have to tell me :) |
| 01:08:03 | ldlework | Araq: thanks for letting me pretend I know anything, though, no sarcasm |
| 01:10:39 | NimBot | Araq/Nimrod devel 85d83fd Araq [+0 ±3 -0]: fixes regression due to object assignment fixes |
| 01:25:30 | * | c74d quit (Remote host closed the connection) |
| 01:25:55 | * | Jesin joined #nimrod |
| 01:31:07 | * | Puffin quit (Ping timeout: 245 seconds) |
| 01:33:51 | * | c74d joined #nimrod |
| 01:33:53 | * | bjz quit (Ping timeout: 240 seconds) |
| 01:36:36 | * | c74d quit (Read error: Connection reset by peer) |
| 01:40:55 | * | c74d joined #nimrod |
| 01:41:55 | * | dom96_ joined #nimrod |
| 01:44:08 | dom96_ | dts: https://github.com/nim-lang/ircl |
| 01:48:14 | * | c74d quit (Read error: Connection reset by peer) |
| 01:48:25 | * | dom96_ quit (Ping timeout: 246 seconds) |
| 01:49:48 | * | vendethiel quit (Ping timeout: 258 seconds) |
| 01:50:49 | * | darkf joined #nimrod |
| 01:52:20 | * | c74d joined #nimrod |
| 01:52:29 | * | vendethiel joined #nimrod |
| 01:58:10 | * | c74d is now known as Guest30509 |
| 01:58:10 | * | Guest30509 quit (Killed (wilhelm.freenode.net (Nickname regained by services))) |
| 01:58:45 | * | enquora joined #nimrod |
| 02:02:04 | * | c74d joined #nimrod |
| 02:06:54 | * | Joe_knock quit (Quit: Leaving) |
| 02:13:31 | * | will quit (Read error: Connection reset by peer) |
| 02:25:09 | * | q66 quit (Quit: Leaving) |
| 02:30:14 | * | q66[lap] quit (Ping timeout: 250 seconds) |
| 02:32:49 | * | darkf quit (Read error: Connection reset by peer) |
| 02:33:16 | * | q66[lap] joined #nimrod |
| 02:33:36 | * | darkf joined #nimrod |
| 02:36:36 | * | vendethiel quit (Ping timeout: 244 seconds) |
| 02:36:46 | * | EXetoC quit (Ping timeout: 264 seconds) |
| 02:59:13 | * | enquora quit (Quit: enquora) |
| 03:07:46 | * | johnsoft quit (Ping timeout: 255 seconds) |
| 03:08:06 | * | johnsoft joined #nimrod |
| 03:09:11 | onionhammer | cat |
| 03:09:14 | onionhammer | om |
| 03:17:32 | * | boydgreenfield joined #nimrod |
| 03:29:05 | * | flaviu quit (Ping timeout: 252 seconds) |
| 03:51:10 | * | j3rky quit (Ping timeout: 264 seconds) |
| 04:00:21 | * | Puffin joined #nimrod |
| 04:01:42 | * | darkf_ joined #nimrod |
| 04:03:23 | * | darkf quit (Ping timeout: 272 seconds) |
| 04:04:32 | * | darkf_ is now known as darkf |
| 04:05:30 | * | Puffin quit (Ping timeout: 258 seconds) |
| 04:09:44 | * | kapil__ joined #nimrod |
| 04:14:30 | * | lyro quit (Ping timeout: 256 seconds) |
| 04:17:00 | * | lyro joined #nimrod |
| 04:36:43 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 04:45:18 | * | saml_ quit (Quit: Leaving) |
| 04:48:57 | * | rpag quit (Ping timeout: 240 seconds) |
| 05:49:20 | * | Puffin joined #nimrod |
| 05:53:35 | * | untitaker quit (Ping timeout: 264 seconds) |
| 05:54:11 | * | Puffin quit (Ping timeout: 264 seconds) |
| 05:58:27 | * | untitaker joined #nimrod |
| 06:00:19 | * | BlaXpirit joined #nimrod |
| 06:03:17 | dts | dom96, it says that page doesnt exist |
| 06:10:06 | * | BlaXpirit quit (Ping timeout: 256 seconds) |
| 06:46:03 | * | brson joined #nimrod |
| 07:13:17 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 07:13:34 | * | gokr_ joined #nimrod |
| 07:20:23 | ldlework | Are there iterators for arrays? |
| 07:38:04 | * | Puffin joined #nimrod |
| 07:39:38 | * | gokr_ quit (Ping timeout: 250 seconds) |
| 07:40:39 | * | gokr_ joined #nimrod |
| 07:43:05 | * | Puffin quit (Ping timeout: 264 seconds) |
| 07:43:51 | gokr | Good morning fellas! |
| 07:50:32 | * | gour joined #nimrod |
| 07:52:31 | * | Matthias247 joined #nimrod |
| 07:56:28 | * | brson quit (Quit: leaving) |
| 08:03:58 | ldlework | My libtcod 1D automata explorer is working :P |
| 08:08:00 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 08:08:05 | ldlework | Rule 54 is awesome |
| 08:09:52 | ldlework | 73 is also neat |
| 08:11:03 | ldlework | 120 just looks cool |
| 08:24:38 | * | darkf quit (Ping timeout: 258 seconds) |
| 08:27:01 | * | darkf joined #nimrod |
| 08:28:30 | * | Trustable joined #nimrod |
| 08:28:35 | dts | what does dependent type mean? |
| 08:34:45 | ldlework | Nim: Its C# for Python programmers |
| 08:36:25 | * | khmm joined #nimrod |
| 08:46:37 | * | khmm quit (Ping timeout: 255 seconds) |
| 08:49:35 | * | vendethiel joined #nimrod |
| 08:51:29 | * | khmm joined #nimrod |
| 08:55:42 | ldlework | I wonder how we can get codingground to update their version of nim |
| 08:55:52 | ldlework | I can't even write 0.9.6 Nim |
| 08:57:14 | * | dts quit (Read error: Connection reset by peer) |
| 08:58:34 | * | dts joined #nimrod |
| 09:12:17 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 09:23:53 | * | Puffin joined #nimrod |
| 09:28:55 | * | Puffin quit (Ping timeout: 272 seconds) |
| 09:45:43 | * | vendethiel joined #nimrod |
| 09:55:51 | * | Puffin joined #nimrod |
| 10:08:31 | * | vendethiel quit (Ping timeout: 258 seconds) |
| 10:11:57 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 10:12:33 | * | gokr_ joined #nimrod |
| 10:14:46 | * | gokr_ quit (Read error: Connection reset by peer) |
| 10:15:34 | * | gokr_ joined #nimrod |
| 10:17:30 | * | BitPuffin joined #nimrod |
| 10:17:49 | * | Puffin quit (Read error: Connection reset by peer) |
| 10:21:18 | * | vendethiel joined #nimrod |
| 10:27:06 | * | gour_ joined #nimrod |
| 10:27:07 | * | bjz joined #nimrod |
| 10:30:29 | * | gour quit (Ping timeout: 264 seconds) |
| 10:31:12 | * | gour_ is now known as gour |
| 10:39:07 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 10:43:48 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 10:49:55 | * | wan quit (Ping timeout: 258 seconds) |
| 10:50:18 | * | wan joined #nimrod |
| 10:50:42 | * | wan is now known as Guest66853 |
| 10:56:26 | * | irrequietus joined #nimrod |
| 10:56:27 | * | irrequietus quit (Changing host) |
| 10:56:27 | * | irrequietus joined #nimrod |
| 11:11:56 | * | vendethiel joined #nimrod |
| 11:15:27 | * | EXetoC joined #nimrod |
| 11:34:45 | * | flaviu joined #nimrod |
| 11:34:46 | * | vendethiel quit (Ping timeout: 258 seconds) |
| 11:36:29 | * | flaviu quit (Remote host closed the connection) |
| 11:36:52 | * | flaviu joined #nimrod |
| 11:52:37 | * | flaviu quit (Ping timeout: 240 seconds) |
| 12:11:45 | ekarlso- | does nim have any major users ? |
| 12:47:49 | * | BitPuffin joined #nimrod |
| 12:53:37 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 12:54:05 | * | gokr_ joined #nimrod |
| 12:56:36 | * | gour quit (Quit: Konversation terminated!) |
| 13:00:33 | * | gour joined #nimrod |
| 13:01:01 | * | gokr_ quit (Read error: Connection reset by peer) |
| 13:01:36 | * | gokr_ joined #nimrod |
| 13:04:35 | * | zio_tom78 joined #nimrod |
| 13:05:00 | zio_tom78 | Hi to everybody |
| 13:07:29 | * | Araq0 joined #nimrod |
| 13:09:39 | Araq0 | hi zio_tom78 |
| 13:10:44 | Araq0 | ekarlso-: yes and hopefully I can tell you concrete things next year |
| 13:11:00 | ekarlso- | Araq0: pfft (: |
| 13:11:42 | ekarlso- | Araq0: what are your plans for world domination with nim ? |
| 13:13:12 | Araq0 | all I will say is that next year is Nim's year |
| 13:14:01 | ekarlso- | Araq0: so if I come here 00:01 at jan 1 15 you have the answer ? :P |
| 13:14:41 | Araq0 | with a bit of luck I'll be drunk then |
| 13:14:44 | ekarlso- | ;P |
| 13:15:08 | Araq0 | actually ... thinking about it |
| 13:15:21 | Araq0 | I'll likely be here and give you an answer, yeah ... :-/ |
| 13:15:25 | ekarlso- | haha |
| 13:15:54 | ekarlso- | what company are you with Araq0 ? |
| 13:17:30 | * | untitaker quit (Ping timeout: 258 seconds) |
| 13:18:03 | Araq0 | I don't talk about these things in IRC, sorry |
| 13:19:09 | ekarlso- | ah ok :) |
| 13:22:35 | * | untitaker joined #nimrod |
| 13:26:29 | * | gour quit (Quit: Konversation terminated!) |
| 13:27:26 | zio_tom78 | I have a question about the coding rule of using 2 spaces for indentation. |
| 13:27:41 | * | Guest66853 quit (Quit: WeeChat 1.0.1) |
| 13:27:58 | * | wan joined #nimrod |
| 13:28:09 | zio_tom78 | I prefer wider spacing (4 tabs), as it makes the control flow structures more visible and prevents me from nesting too many loops. |
| 13:28:37 | zio_tom78 | I am not asking to change the coding rules of Nim, but I am curious about what are the advantages of having such a tight indentation |
| 13:29:01 | wan | I'm the same, I usually use 4 spaces in my own code. |
| 13:29:15 | zio_tom78 | Yes, sorry, I meant 4 spaces, not 4 tabs |
| 13:29:30 | * | gour joined #nimrod |
| 13:31:43 | wan | I'm interested in other people's answer, though. Maybe I should change my habits? What are the benefits, from people using 2 instead of 4? |
| 13:32:19 | wan | We probably should have some kind of PEP or something, to define official guidelines |
| 13:32:59 | zio_tom78 | Me too, I would happly use 2 spaces if I understand what are the advantages |
| 13:33:18 | zio_tom78 | wan: You mean something like "go fmt"? |
| 13:34:05 | wan | no, I meant like http://legacy.python.org/dev/peps/pep-0008/ |
| 13:34:19 | Araq0 | the idea that more indentation prevents you from nesting too deeply is all backwards imho |
| 13:35:03 | zio_tom78 | Araq0: I don't understand the meaning of "backwards"... |
| 13:35:29 | * | Puffin joined #nimrod |
| 13:36:00 | Araq0 | I nest as deeply as I want and un-nest when it becomes too hard to follow, I don't need line length limitations for that |
| 13:36:38 | Araq0 | likewise my word processor has no "paragraph too long" feature either and yet my paragraphs do not go on forever |
| 13:38:44 | Araq0 | when iterating over a 4 dimensional space, 4 nested loops are fine, no matter what Linus may think about it |
| 13:39:16 | wan | It's a question of habits then? Eyes that are used to 4 find it too unclear when it's 2 (because they are used to more visual aid). I guess your answer would be "get used to it"? |
| 13:39:19 | zio_tom78 | I must say that my preference to 4 spaces is mainly due to the increased readability. I was curious about other people's preference for 2 spaces |
| 13:39:57 | * | Puffin quit (Ping timeout: 252 seconds) |
| 13:40:51 | Araq0 | 2 vs 4 spaces is just personal preference, I prefer 2 |
| 13:40:59 | Araq0 | but don't mind 4 either |
| 13:41:12 | Araq0 | 8 is too extreme though, IMHO |
| 13:41:19 | wan | agreed |
| 13:41:41 | EXetoC | I have glasses, but text on the screen is a little blurry still, so 4-space indents make a difference |
| 13:41:46 | Araq0 | btw some of the smartest coders I know use *1* space |
| 13:41:47 | wan | I hate when I read code indented with tabs on github, and it displays as 8 |
| 13:42:41 | wan | Some supposedly smart coders use no spaces, and program in J |
| 13:42:44 | EXetoC | and I don't want the font size to be too large, for obvious reasons |
| 13:42:48 | zio_tom78 | Araq0: I bet those smartest coders use butterflies to write programs... |
| 13:42:52 | zio_tom78 | (http://xkcd.com/378/) |
| 13:44:33 | wan | (I didn't mean J, there is a weird cryptic programming language that I saw some code for, and it was unreadable) |
| 13:45:10 | EXetoC | and I only restrict the length of lines because I want to be able to fit as much as possible onto the screen |
| 13:45:18 | Araq0 | what? you *didn't* mean J? |
| 13:45:21 | wan | Ah, I was thinking about the K language |
| 13:45:59 | zio_tom78 | wan: Well, I too thought that J fitted perfectly in your sentence |
| 13:46:18 | Araq0 | dunno if it's still unreadable when you're used to it |
| 13:46:50 | gokr | Its interesting how some developers are very interested in things like this - and some, like myself, hardly care. In Smalltalk I use a tab. In Nim I just use what the "Romans" use. :) |
| 13:48:33 | zio_tom78 | In my experience, using too much spaces or too few increases my troubles in understanding somebody else's code |
| 13:49:28 | gokr | Funky: http://nickgravgaard.com/elastictabstops/ |
| 13:50:05 | Araq0 | zio_tom78: you should tell your editor than to render the text differently for you |
| 13:50:05 | wan | Araq0: I'm not so sure about that http://t.wjt.me.uk/post/100581583087/arthur-whitneys-edit-k-text-editor |
| 13:50:40 | Araq0 | and yes, I'm very well aware that editors suck and it's easier to say that than do it |
| 13:51:12 | Araq0 | but it really *should* be simple and you really should patch your editors |
| 13:52:05 | Araq0 | and not live in the world where the technologies of the 70ies are dominating |
| 13:52:24 | zio_tom78 | Araq0: This would be ok in an utopic world, but in *this* world I barely find time to learn Nim, cannot imagine to learn Elisp to hack Emacs... |
| 13:52:25 | gokr | What is the advantage of 2 spaces instead of tabs? I am a clueless Smalltalker :) |
| 13:53:13 | zio_tom78 | Months ago I spent two hours trying to make Emacs aware of the syntax of Nim's error messages, to no avail. |
| 13:53:24 | Araq0 | tabs do not work, gokr |
| 13:53:51 | Araq0 | for the simple reason that too much code out there mixes tabs and spaces |
| 13:54:03 | Araq0 | and so you're stuck with tab-width = 8 |
| 13:54:30 | EXetoC | a good editor would presumably also make multiline comments unnecessary |
| 13:54:58 | Araq0 | well dom96 is the author of aporia and disagrees, EXetoC ;-) |
| 13:55:41 | wan | Araq0: when vim's ctags implementation (for example) is mostly implemented by two 1000+ lines functions, called do_tag and find_tags, it doesn't feel welcoming to want to modify your editor. It makes you feel like you should throw it far away and never look back. Then you remember all the niceties you like about it. Then you cry. |
| 13:56:39 | Araq0 | wan: so? at least these long functions to not jump into 20 different files/modules :P |
| 13:56:44 | gokr | It would seem to me that tabs would carry more information. As "this is one level indentation, render it the way you like". But again, I am no expert. |
| 13:56:47 | EXetoC | I thought tabs worked, but only in combination with spaces, if done right of course |
| 13:57:08 | Araq0 | gokr: that information is easily re-computed either way |
| 13:58:15 | Araq0 | zio_tom78: do you use the "official" Nim emacs mode? |
| 13:58:22 | Araq0 | (whatever that means ...) |
| 13:58:39 | EXetoC | tabs for indentation and spaces for alignment, though I prefer to use an extra indentation or two, rather than aligning with a '(', because then the indentation doesn't depend on the length of certain keywords |
| 14:02:17 | wan | okay, measured: find_tags: 1968 lines (in nvim), do_tag: 934 lines. It just makes understanding it really hard. These are not "long functions that contain switches" like in nim's compiler. It's just not abstracted at all: impossible to get the global picture. |
| 14:05:05 | zio_tom78 | Araq0: I was going to ask what it means... Anyway, I'm using nimrod-mode 0.1.5, and I have not even tried to hack it :-) |
| 14:05:59 | Araq0 | wan: ok |
| 14:06:17 | Araq0 | wan: the editor in K is most interesting |
| 14:06:41 | Araq0 | I should learn K and then I can tell you if it's readable :P |
| 14:07:31 | wan | Without any syntax highlighting, I doubt we can survive |
| 14:09:24 | EXetoC | viewing 2-space indents as 4-space indents is fine I think, as long as lines don't end up exceeding 100 columns or so, because then you'll be able to view two source files side-by-side with the average monitor, assuming that the font size isn't really big |
| 14:09:46 | EXetoC | except I did forget to take into account these massive side panes that are present in some IDEs |
| 14:12:34 | Araq0 | gokr: tabs are fundamentally broken and were not meant for 'indent' either. "\t " renders as 8 spaces |
| 14:12:36 | EXetoC | The only thing I have on the side now is relative line numbers, and then an additional row in case of errors (nimrod.vim) |
| 14:13:00 | Araq0 | tab-width = 8 is already misleading, it uses fucking "modulo 8" semantics |
| 14:14:33 | * | vendethiel joined #nimrod |
| 14:17:05 | Araq0 | wan: btw looks like this is the original: http://kparc.com/edit.k |
| 14:18:36 | EXetoC | is this sort of like (v)im's normal mode? |
| 14:19:50 | gokr | Araq0: Did you look at that elastictabstops article I linked? That seems kinda neat. |
| 14:22:23 | Araq0 | gokr: already know it ;-) |
| 14:22:26 | Araq0 | it's old |
| 14:22:44 | gokr | And its no good? |
| 14:23:20 | Araq0 | you can implement the same without tabs in the source code |
| 14:23:32 | Araq0 | it's a nice idea, but doesn't require tabs |
| 14:31:34 | wan | the edit.k looks unusual, the lines are short and commented. This looks like regular K to me: http://kparc.com/$/mail.k What's E? What's A? What's w? What's _W? It reads like a write-only language, or at least a write-only programmer. |
| 14:34:03 | * | j3rky joined #nimrod |
| 14:39:37 | Araq0 | yeah but these are not the interesting questions |
| 14:39:44 | Araq0 | the interesting questions are more like: |
| 14:39:56 | Araq0 | * how long does it take me to learn this notation? |
| 14:40:10 | Araq0 | * am I really more effective with it afterwards? |
| 14:40:38 | Araq0 | * can I then easily read other people's code? |
| 14:40:49 | Araq0 | etc etc etc |
| 14:41:27 | * | gokr longs for a Smalltalkish browser with good cross referencing for Nim... |
| 14:59:22 | Araq0 | doesn't "find defintion" for in Aporia for you, gokr ? |
| 14:59:40 | gokr | Yes, it works - most of the time. |
| 14:59:50 | gokr | But I want quite a bit more than that :) |
| 15:00:28 | gokr | Is the idea to let the compiler do incremental compilation? |
| 15:00:32 | gokr | I mean, for larger codebases. |
| 15:00:47 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 15:02:09 | gokr | back later tonight |
| 15:02:19 | Araq0 | yes, it's already implemented for years |
| 15:02:29 | gokr | Incremental? |
| 15:02:34 | Araq0 | yes. but zahary broke it and never fixed it |
| 15:02:38 | gokr | Ah |
| 15:03:05 | Araq0 | I plan to hack some alternative implemenation together for fun |
| 15:03:07 | gokr | So that means we can extend the query part with more things, like "all call sites of" etc? |
| 15:03:33 | Araq0 | well "usages" already should work |
| 15:04:10 | gokr | The basics in Smalltalk are "all senders of", "all implementors of", "all references to class" and... probably "all references to field". |
| 15:04:43 | Araq0 | "goto definition", "find usages" are the primitives idetools supports |
| 15:04:43 | gokr | Now... in Smalltalk that would give me a special kind of browser for these hits etc. |
| 15:04:59 | gokr | right |
| 15:05:29 | Araq0 | though IMO these should be merged at the UI level |
| 15:05:36 | * | j3rky quit (Ping timeout: 256 seconds) |
| 15:05:42 | Araq0 | in my brain it's 1 command -- "navigate" |
| 15:05:42 | gokr | Ok, really got to go... |
| 15:05:46 | Araq0 | ok, bye |
| 15:05:54 | gokr | bye |
| 15:06:08 | * | Araq0 quit (Quit: Page closed) |
| 15:07:05 | * | brson joined #nimrod |
| 15:11:37 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 15:11:54 | zio_tom78 | Thanks a lot for the discussion guys, bye. |
| 15:11:56 | * | zio_tom78 quit (Quit: ERC Version 5.3 (IRC client for Emacs)) |
| 15:12:48 | * | gokr_ joined #nimrod |
| 15:21:08 | * | darkf quit (Quit: Leaving) |
| 15:21:24 | * | brson quit (Quit: leaving) |
| 15:25:45 | EXetoC | if you want to turn x-space indents into y-space indents in vim: ":se ts=x noexpandtab | :retab! | :set ts=y expandtab | :retab" and then you can revert by swapping x and y |
| 15:26:27 | * | saml quit (Quit: Leaving) |
| 15:29:29 | * | dirkk0 joined #nimrod |
| 15:30:03 | * | saml joined #nimrod |
| 15:33:23 | wan | I guess this might help too: https://github.com/Yggdroot/indentLine |
| 15:36:38 | EXetoC | yep. the other plugin I used had more distracting hints |
| 15:37:31 | * | vendethiel joined #nimrod |
| 15:37:41 | * | dirkk0 quit (Quit: Leaving) |
| 15:42:38 | wan | I'm curious though, what is a y-space indent? |
| 15:43:38 | EXetoC | those are just integer placeholders |
| 15:43:44 | * | BlaXpirit joined #nimrod |
| 15:49:18 | * | gokr_ quit (Read error: Connection reset by peer) |
| 15:49:39 | * | gokr_ joined #nimrod |
| 15:49:56 | * | khmm quit (Remote host closed the connection) |
| 15:51:23 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 15:51:28 | * | khmm joined #nimrod |
| 16:04:15 | * | rpag joined #nimrod |
| 16:21:37 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 16:22:10 | * | vendethiel joined #nimrod |
| 16:28:49 | wan | ah, huh, I stupidly thought it had something to do with the horizontal (x) and vertical (y) axis |
| 16:53:16 | * | Joe_knock joined #nimrod |
| 16:56:48 | * | gour quit (Quit: Konversation terminated!) |
| 16:57:12 | * | gour joined #nimrod |
| 17:05:57 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 17:07:19 | * | gokr_ joined #nimrod |
| 17:18:37 | * | gokr_ quit (Ping timeout: 258 seconds) |
| 17:20:10 | * | gokr_ joined #nimrod |
| 17:25:11 | * | willwillson joined #nimrod |
| 17:26:55 | * | johnsoft quit (Ping timeout: 252 seconds) |
| 17:27:31 | * | johnsoft joined #nimrod |
| 17:43:31 | * | enquora joined #nimrod |
| 17:45:14 | * | q66 joined #nimrod |
| 17:45:27 | * | gokr_ quit (Ping timeout: 272 seconds) |
| 17:47:19 | * | gokr_ joined #nimrod |
| 18:07:46 | ldlework | EXetoC: did you move your library or am I crazy |
| 18:09:10 | ldlework | nevermind |
| 18:09:13 | ldlework | that was wierd |
| 18:14:46 | EXetoC | no, but it's src that should be added to the path, not src/libtcod |
| 18:17:37 | * | AMorpork is now known as AFKMorpork |
| 18:21:51 | ldlework | EXetoC: why? |
| 18:23:42 | * | dts is now known as tcs |
| 18:23:45 | * | tcs is now known as dts |
| 18:30:15 | * | ebirul joined #nimrod |
| 18:30:23 | * | ebirul left #nimrod (#nimrod) |
| 18:50:37 | ldlework | does Aporia work again? |
| 18:54:54 | ldlework | nm |
| 19:01:59 | ldlework | hmm |
| 19:02:11 | ldlework | idetools command doesn't seem to do anything for me :( |
| 19:03:13 | Araq | do you use aporia? |
| 19:05:35 | ldlework | Araq: I didn't before because I thought it was broken, but I realized I needed to update its config to point at the newly named nim binary, so I just did that and it still doesn't work, so I just learned about idetools and I've tried everything to get it to give me any sort of output at all |
| 19:05:43 | ldlework | I can't get it to --def anything |
| 19:06:35 | Araq | well don't use the server mode |
| 19:07:07 | ldlework | nim idetools --track:./bots.nim,11,3 --def ./bots.nim |
| 19:10:37 | Araq | doesn't work? |
| 19:11:13 | ldlework | not at all |
| 19:13:46 | * | khmm quit (Ping timeout: 244 seconds) |
| 19:15:52 | Araq | indeed |
| 19:16:15 | ldlework | ah so you confirmed it doesn't work? |
| 19:17:53 | Araq | for my test program it doesn't work either, yes |
| 19:31:48 | ldlework | Araq: any idea who could update the version Nim on codingground.tutorialspoint.com ? |
| 19:32:16 | Araq | no idea |
| 19:37:06 | Joe_knock | ldlework: Just contact the site owners. But you should probably wait until 1.0 |
| 19:37:11 | Joe_knock | cool website though |
| 19:39:32 | Joe_knock | ldlework: it looks like they're updated to stable in any case. 0.9.6 |
| 19:48:06 | ldlework | Joe_knock: I can't write 0.9.6 with its crazy case insensitivity |
| 19:48:44 | Joe_knock | ldlework: There is a guide for case-strategy somewhere in the docs |
| 19:49:03 | ldlework | Joe_knock: what do you mean? |
| 19:49:35 | Joe_knock | ldlework: There is a guide that explains how to deal with the case insensitivity |
| 19:50:05 | ldlework | I don't want to deal with it, :) |
| 19:50:15 | ldlework | Its okay its not important |
| 19:52:38 | * | edayo joined #nimrod |
| 20:02:14 | * | skyfex joined #nimrod |
| 20:06:08 | * | boydgreenfield joined #nimrod |
| 20:12:07 | * | edayo_ joined #nimrod |
| 20:12:57 | * | filcuc joined #nimrod |
| 20:13:20 | filcuc | i |
| 20:13:22 | filcuc | hi |
| 20:13:54 | Joe_knock | Hi |
| 20:14:20 | ldlework | hello |
| 20:14:35 | * | edayo quit (Ping timeout: 264 seconds) |
| 20:14:37 | filcuc | i'm using nimble from my archlinux box however c2nim fails to install with 'cannot open llstream' |
| 20:14:41 | filcuc | any hint? |
| 20:15:11 | filcuc | or is there a correct way to get c2nim and nimrod? |
| 20:15:15 | willwillson | add teh compiler src to nims path |
| 20:15:59 | willwillson | see: http://goran.krampe.se/2014/10/16/nim-wrapping-c/ |
| 20:17:52 | filcuc | mh so i've to find out the correct path for my archlinux |
| 20:18:23 | willwillson | maybe that doesn't explain it, but basically want to add --path:/path/to/nim/compiler (just edit the .nim.cfg file) |
| 20:19:10 | willwillson | you might need to download the source from github, as they strip out the compiler src when they package it |
| 20:19:44 | filcuc | :| |
| 20:19:52 | Araq | ah yeah, thanks for reminding me |
| 20:19:57 | filcuc | but is this correct? |
| 20:19:58 | Araq | I need to fix this |
| 20:20:02 | Araq | hi filcuc welcome |
| 20:20:29 | filcuc | i mean i thinked that a nimble package is a selfcontained "thing" |
| 20:20:42 | filcuc | i mean something that should be compiled by nim |
| 20:20:54 | filcuc | in a "packaged" way |
| 20:20:58 | filcuc | but ok fine |
| 20:21:04 | willwillson | they generally are, but not in the case of c2nim (for the moment) |
| 20:21:22 | filcuc | ah ok :) |
| 20:21:22 | willwillson | i think it needs a compiler src package |
| 20:21:38 | filcuc | basically i'm working on QML bindings |
| 20:21:46 | willwillson | sounds good :D |
| 20:22:00 | filcuc | no Qt bindings only QML |
| 20:22:12 | filcuc | so the bare minimum |
| 20:22:45 | willwillson | don't they create a c wrapper for qml in the haskell bindings? |
| 20:22:52 | filcuc | hi Araq ;) |
| 20:23:11 | filcuc | i know the go-qml |
| 20:23:21 | filcuc | and obviously the python pyqt bindings |
| 20:23:43 | Joe_knock | So we'll have *almost* QT support now :' |
| 20:23:45 | Joe_knock | :'D |
| 20:23:53 | filcuc | lol |
| 20:23:55 | filcuc | ;) maybe |
| 20:24:33 | filcuc | i think Qml is enough |
| 20:24:48 | Araq | somebody should wrap "wxc" from the wxHaskell project |
| 20:25:20 | filcuc | :) GUI framework is a religion thing |
| 20:25:48 | filcuc | everyone has its one faith |
| 20:25:52 | filcuc | have |
| 20:27:13 | Joe_knock | Doesn't QT work across OSes? filcuc |
| 20:27:26 | filcuc | yes |
| 20:27:57 | filcuc | and across architectures |
| 20:28:29 | filcuc | works fine on my raspberry and wandboard |
| 20:32:45 | * | brson joined #nimrod |
| 20:35:32 | * | brson quit (Remote host closed the connection) |
| 20:36:17 | * | brson joined #nimrod |
| 20:37:36 | Joe_knock | now if only QT supported Android, we could be Nimming on droid |
| 20:40:06 | filcuc | support android |
| 20:40:42 | filcuc | Joe_knock: there's already go-qml projects running on android environment |
| 20:41:05 | * | edayo_ quit (Ping timeout: 244 seconds) |
| 20:41:10 | filcuc | and pure qml applications on android |
| 20:41:14 | Joe_knock | filcuc: One does not simply mention languages like Go in the Nim IRC :P |
| 20:41:37 | filcuc | i'm here because i prefear nim to go |
| 20:41:57 | filcuc | i love nim syntax. |
| 20:42:02 | * | flaviu joined #nimrod |
| 20:42:18 | ldlework | \o/ |
| 20:42:54 | EXetoC | but, "syntax doesn't matter" :p |
| 20:44:43 | filcuc | not for everyone :P |
| 20:45:17 | Joe_knock | filcuc: I think some Nim guys downplay the beauty of the syntax, but all it takes to convince them is to spend some time reading PHP code :"D |
| 20:46:26 | ldlework | I'm here because of the syntax too |
| 20:46:30 | ldlework | Well |
| 20:46:40 | filcuc | well i spend most of my time coding in both c++ and C# and i even if those language syntax isn't terrible as the php one i enjoy more nim |
| 20:46:56 | ldlework | filcuc: I see Nim as a sort of C# for Python programmers :) |
| 20:47:04 | filcuc | argh |
| 20:47:19 | EXetoC | ? |
| 20:47:32 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 20:47:36 | filcuc | so a regression? |
| 20:49:35 | Joe_knock | I called Nim a "natural progression from Python" in my presentation. |
| 20:52:44 | filcuc | Joe_knock: i was answering to Idlework. however i find nimrod very close to C. I mean, the syntax is very close to python but the idea is to have a lightweight language. Without object hierarchies very close to bare metal |
| 20:53:01 | filcuc | but i see a common trend in modern languages like nim and go |
| 20:53:31 | filcuc | to go back to C |
| 20:54:51 | * | irrequietus quit () |
| 20:55:24 | * | Varriount|Mobile joined #nimrod |
| 20:56:15 | * | boydgreenfield joined #nimrod |
| 20:56:49 | Varriount|Mobile | Araq: I'm curious as to why you think constructors are a bad idea. I have my own reasons against them, but I'd like to hear yours. |
| 20:57:54 | * | someonenooen joined #nimrod |
| 20:57:57 | someonenooen | idlework |
| 20:57:58 | ldlework | filcuc: dude, C doesn't have generics, typeclasses, inheritance, macros and so on |
| 20:58:24 | ldlework | filcuc: It *looks* a bit like C, but its totally way more C# than it is C in terms of features, as far as I can tell :) |
| 20:58:47 | someonenooen | ldlework: |
| 20:58:47 | someonenooen | yo |
| 20:59:59 | filcuc | Idlework: :D i know...what the hell if not we'll use C instead of Nim. What i'm telling is that there's been a big trend in the previous years in object oriented languages like java, C# and maybe in the beginning also c++ too. |
| 21:00:28 | filcuc | instead modern languages tend to favor composition |
| 21:00:39 | filcuc | a more C like syntax |
| 21:01:20 | filcuc | obviously with modern features like generics and compile time execution |
| 21:03:14 | ldlework | hi someonenooen |
| 21:04:00 | ldlework | filcuc: composition doesn't solve everything but it goes very far. There are somethings implementation inheritance is good for |
| 21:04:20 | ldlework | But I also feel like macros and templates will eventually supplant my use of basic one-step inheritance |
| 21:04:21 | filcuc | i never said that |
| 21:04:25 | ldlework | I just haven't grown there yet |
| 21:04:34 | Araq | Varriount|Mobile: they introduce yet another way of doing things and are semantically questionable |
| 21:05:09 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 21:05:18 | Araq | for instance, parse(x: string): Ast # is that a constructor? |
| 21:05:23 | Araq | if not, why not? |
| 21:05:25 | * | boydgreenfield joined #nimrod |
| 21:05:29 | * | boydgreenfield quit (Client Quit) |
| 21:06:08 | Araq | every non-void function can be seen as a constructor |
| 21:06:33 | Araq | that said, Nim already has a notion of construction so that "not nil" pointers can work |
| 21:06:58 | someonenooen | :) |
| 21:07:21 | Araq | but this notion is not extensible to user defined constructors for now |
| 21:08:35 | Varriount|Mobile | Heh. The bulk of my arguments sum up to "its not nim-like" |
| 21:10:19 | Araq | also note that the requirement for "factories" comes from conventional OO constructors |
| 21:10:26 | ldlework | someonenooen: http://nimrod-lang.org/irc.html |
| 21:11:34 | * | flaviu quit (Ping timeout: 244 seconds) |
| 21:14:38 | someonenooen | ldlework: im installing rust as we speak |
| 21:14:45 | someonenooen | im also going to install nimrod |
| 21:15:42 | * | flaviu joined #nimrod |
| 21:16:36 | ldlework | someonenooen: cool |
| 21:16:48 | Araq | good there is no competition between the languages |
| 21:17:26 | Varriount|Mobile | Araq: Right... |
| 21:17:35 | EXetoC | ldlework: you mean, "static typing for people used to the Python syntax"? :> |
| 21:17:48 | ldlework | EXetoC: nah its more than just static typing though |
| 21:17:52 | ldlework | Golang has static typing |
| 21:17:57 | ldlework | and its not like Golang at all |
| 21:17:59 | someonenooen | Golang is atrocious |
| 21:18:05 | ldlework | I find the featureset between C# and Nim quite similiar |
| 21:18:12 | someonenooen | Getting a IDE and the compiler setup is a hurddle |
| 21:18:14 | ldlework | and the way that the advanced features "Just Work" is also similar |
| 21:18:24 | ldlework | Besides macros, I think the C# comparison is sound and useful |
| 21:18:35 | someonenooen | Is nimrod UTF-8? |
| 21:20:05 | Araq | ldlework: depends. I know lots of c# programmers who wouldn't be happy with Nim |
| 21:20:46 | ldlework | Araq: sure, no metaphor is going to please everyone, but who cares |
| 21:20:56 | Araq | they use c# like a "Java with LINQ" |
| 21:21:14 | ldlework | Man, if Nim has LINQ I might quit my job and figure out how to use Nim to make money |
| 21:21:14 | Varriount|Mobile | someonenooen: In what way? |
| 21:21:29 | someonenooen | Varriount|Mobile: are all strings treated as UTF-8? |
| 21:21:33 | ldlework | LINQ is hahmazing |
| 21:21:38 | someonenooen | The same way Go treats everything as Unicode basically |
| 21:21:59 | Araq | ldlework: LINQ is only a macro away |
| 21:23:19 | Varriount|Mobile | someonenooen: I've no idea how go treats strings. Nim encodes string literals as utf8, however string slicing works on an 8-bit character basis |
| 21:23:32 | ekarlso- | linq what ? |
| 21:23:34 | someonenooen | ok |
| 21:23:37 | * | rpag quit (Ping timeout: 245 seconds) |
| 21:23:50 | Varriount|Mobile | There are facilities for code-point slicing though |
| 21:24:49 | filcuc | i prefear python list comprehension rather than linq |
| 21:25:35 | Araq | filcuc: we have list comprehensions in Nim's future module |
| 21:25:43 | Araq | implemented as a macro |
| 21:25:44 | filcuc | as far as syntax is concerned |
| 21:25:58 | filcuc | Araq: nice i'll check them out |
| 21:26:55 | filcuc | btw i managed to install c2nim thank you willwillson |
| 21:27:33 | filcuc | let's see if i find the correct whay to pass a variadic function in nim to C as a function pointer |
| 21:27:57 | skyfex | hey araq, what are you working on with nim these days? |
| 21:29:22 | Araq | skyfex: I'm fixing bugs and cleaning up things for 1.0 |
| 21:29:31 | skyfex | no major new features before 1.0? |
| 21:29:45 | Araq | hell no |
| 21:30:13 | skyfex | aw, I was hoping for "COMEFROM" |
| 21:30:40 | Araq | in fact, I'm removing features that people don't like too much |
| 21:30:47 | * | boydgreenfield joined #nimrod |
| 21:30:50 | skyfex | like? |
| 21:30:50 | * | flaviu quit (Read error: Connection reset by peer) |
| 21:31:09 | Araq | * standalone except and finally |
| 21:31:18 | Araq | * do notation will be cleaned up |
| 21:31:30 | Araq | * destructors will end in 'experimental' |
| 21:31:53 | Araq | * so will 'generic' |
| 21:32:00 | Araq | and 'using' |
| 21:32:07 | skyfex | hah, yeah i remember the standalone except/finally could be a bit weird |
| 21:33:10 | * | someonenooen quit (Quit: Page closed) |
| 21:34:11 | skyfex | oh, I was kind of hoping generic would've made it in 1.0.. but I suppose it'll take some more work |
| 21:34:17 | filcuc | wait wait what do you mean with standalone except and finally? |
| 21:34:29 | filcuc | i'm using finally for having a sort of RAII |
| 21:34:34 | filcuc | do you mean that? |
| 21:34:51 | filcuc | so i use them like go defear |
| 21:35:00 | Araq | filcuc: yes. instead there will be a builtin called 'defer' |
| 21:35:03 | EXetoC | defer? |
| 21:35:11 | filcuc | sorry *defer* |
| 21:35:17 | ekarlso- | oh, defer is so nice :D |
| 21:35:17 | filcuc | ah ok |
| 21:35:27 | Araq | re-using the Finally keyword turned out to be too error prone |
| 21:35:40 | filcuc | ok perfect |
| 21:35:41 | skyfex | Araq: What about static[T], are those in for 1.0? |
| 21:35:45 | filcuc | i like this change |
| 21:36:26 | Araq | skyfex: well both static[T] and 'generic' will be available when you enable the upcoming "experimental" mode |
| 21:36:34 | * | rpag joined #nimrod |
| 21:36:51 | Araq | so they are "in" for 1.0 in some beta quality status, like now |
| 21:37:12 | skyfex | Ah, alright, I'm fine with experimental, I don't mind swimming in the deep end ;) |
| 21:38:07 | skyfex | I'm hoping I'll have time to do all the stuff I want to do with nimrod soon. I've been too busy the last 6 months, but it's clearing up now |
| 21:38:23 | skyfex | Maybe I'll do some christmas coding ^_^ |
| 21:39:29 | * | flaviu joined #nimrod |
| 21:44:02 | skyfex | Araq: Do you have any issues in the compiler you want me to try and help with? |
| 21:44:29 | Araq | sure. pick any bug you like. |
| 21:44:40 | Araq | we have over 300 of them |
| 21:45:01 | Araq | though many are feature requests |
| 21:46:26 | Araq | high priority bugs should be fixed before 1.0 is ready |
| 21:47:32 | skyfex | Okay, I'll go over the list and find something I think I can handle |
| 21:49:02 | ekarlso- | I was wondering if I should make a dns thing for nim |
| 21:50:28 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 21:50:43 | Araq | skyfex: what you can definitely do is to fix the handling of "unsigned" |
| 21:53:03 | * | Matthias247 joined #nimrod |
| 21:54:55 | * | gour is reading backlog |
| 21:55:22 | gour | by wrapping wx(c), we'd get qt for free considering wxqt project |
| 21:55:40 | Joe_knock | That is 1 thing I dislike about GH, the fact that it says 300 issues when 100 of them could be requests, Q&A and nothing related to the actual code |
| 21:56:33 | Araq | yeah, feature requests should have their own tracking |
| 21:58:05 | * | filcuc quit (Ping timeout: 264 seconds) |
| 22:03:52 | * | gour quit (Quit: Konversation terminated!) |
| 22:04:34 | * | Matthias247_ joined #nimrod |
| 22:04:39 | skyfex | Araq: Will nimrod defer work like Go's defer? (arguments evaluated when defer is used, then the function called in LIFO order when the function returns) |
| 22:04:44 | * | enquora_ joined #nimrod |
| 22:05:00 | ldlework | I do wonder if Nim is going to have some good concurrency |
| 22:05:03 | ldlework | I haven't read much about it |
| 22:05:11 | ldlework | Araq: are you familiar with Twisted at all? |
| 22:06:02 | Araq | skyfex: no, it will work like today's standalone finally |
| 22:06:09 | skyfex | alright |
| 22:06:14 | Araq | we simply rename finally to defer |
| 22:07:16 | * | Matthias247 quit (Ping timeout: 258 seconds) |
| 22:07:39 | * | enquora quit (Ping timeout: 258 seconds) |
| 22:07:39 | * | enquora_ is now known as enquora |
| 22:11:21 | * | dts is now known as dtsbot |
| 22:11:30 | * | dtsbot is now known as dts |
| 22:14:36 | Araq | ldlework: we have async+await and 'spawn' |
| 22:15:16 | Araq | and parallel and lock levels and field guards |
| 22:16:58 | * | filcuc joined #nimrod |
| 22:17:06 | Araq | we prove the absense of deadlocks at compile-time and prevent data races |
| 22:17:32 | Araq | I'd say we're in quite good shape |
| 22:18:27 | filcuc | just a curiosity is there an automatic cast operator? |
| 22:18:34 | EXetoC | automatic? |
| 22:18:42 | filcuc | like the cast operator for c++ |
| 22:19:01 | filcuc | if you declare an implicit cast for you type to another |
| 22:19:01 | EXetoC | there's cast[T](var) |
| 22:19:03 | filcuc | the compiler automatic invoke it |
| 22:19:05 | EXetoC | oh |
| 22:19:08 | EXetoC | yes |
| 22:19:16 | filcuc | without explicit writing it |
| 22:19:37 | filcuc | the idea is to create a variant type |
| 22:19:38 | EXetoC | look for 'converter' in the manual |
| 22:19:45 | filcuc | that has automatic cast to int, bool etc |
| 22:20:41 | EXetoC | I try to use it sparingly, but it comes in handy |
| 22:20:41 | Araq | filcuc: don't use it unless you really need it |
| 22:21:20 | Araq | automatic casting to both int and bool sounds fishy |
| 22:22:29 | ldlework | Araq: I was thinking more about how Twisted isn't thread based but provides async implementations of everything so you can right highly performance single threaded apps |
| 22:22:38 | ldlework | but I guess its a library concern |
| 22:22:55 | ldlework | Maybe I could try to reimplement Twisted's reactor with the selector module |
| 22:23:02 | ldlework | and try to implement a Deferred |
| 22:23:02 | Araq | as I said, we have async+await in the core |
| 22:23:04 | ldlework | for funsies |
| 22:23:13 | ldlework | Araq: okay I'll go read about them |
| 22:23:19 | Araq | and many libs have been ported to use it |
| 22:23:25 | filcuc | Araq: yep from great power comes great responsabilities |
| 22:23:30 | * | Var|Mobile joined #nimrod |
| 22:23:40 | onionhammer | destructors will end in experimental? whats that mean? |
| 22:23:52 | onionhammer | I liked standalone finally :( |
| 22:24:19 | ldlework | onionhammer: standalone finally is just being renamed |
| 22:24:20 | onionhammer | oh i see, experimental mode, nm |
| 22:24:28 | onionhammer | oh? to what? |
| 22:24:33 | onionhammer | oh derer |
| 22:24:33 | ldlework | defer |
| 22:24:38 | onionhammer | got it |
| 22:25:27 | * | Varriount|Mobile quit (Ping timeout: 244 seconds) |
| 22:25:30 | onionhammer | not sure how i feel about new keywords, but hey ;) |
| 22:25:46 | Araq | it's not a keyword |
| 22:25:51 | Araq | it's system.defer |
| 22:26:01 | onionhammer | ah, okay. |
| 22:26:08 | Araq | Nim is slowly getting rid of keywords ... *cough* |
| 22:27:17 | onionhammer | good |
| 22:27:25 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 22:30:51 | * | vendethiel joined #nimrod |
| 22:33:47 | Araq | ldlework: please implement scgi with Nim's async features. dom96 can help you. |
| 22:34:01 | Araq | that's planned for 1.0 but nobody of us can get to it |
| 22:34:04 | ldlework | someone told me they closed the tab on nim's website when they saw that it had a keyword fetish |
| 22:34:11 | ldlework | 'sigils have a reason' |
| 22:34:23 | * | filcuc quit (Quit: Konversation terminated!) |
| 22:34:55 | Araq | LOL |
| 22:35:22 | Araq | and yet it's shorter than Perl |
| 22:36:19 | ldlework | I know so stupid it made me upset for a few minutes |
| 22:36:55 | Araq | not that's hard to be shorter than Perl. Perl is schizo |
| 22:37:45 | Araq | it used to be my favourite language to bash. so little in it makes any sense |
| 22:38:23 | ldlework | I don't think we want me getting anywhere close to things like the standard scgi implementation |
| 22:38:45 | EXetoC | I didn't understand the scoping |
| 22:39:02 | Joe_knock | onionhammer: Do you have any examples of using Jester? |
| 22:39:03 | EXetoC | is it sane once you figure it out? |
| 22:39:42 | Joe_knock | Apparently you need to be enlightened and anointed to get Perl |
| 22:40:19 | EXetoC | the readme contains an example |
| 22:40:32 | flaviu | So looking a bit more at libtls, it's currently not in a usable state |
| 22:41:01 | flaviu | Seems it only compiles on OpenBSD for now. |
| 22:41:05 | flaviu | https://github.com/libressl-portable/portable/issues/44 |
| 22:41:30 | Araq | flaviu: ugh. why not? |
| 22:42:44 | flaviu | It uses some functions that the standard C library doesn't have. I tried compiling it. |
| 22:42:57 | flaviu | Anyway, its obviously not mature enough at this point |
| 22:43:27 | flaviu | It was apparently announced just 25 days ago, and the API isn't stable yet. |
| 22:43:39 | Araq | ok, that sucks |
| 22:43:56 | Araq | let's use google's SSL implementation then |
| 22:44:47 | Joe_knock | Would a Python port of OpenSSL be easier to do than a C port? |
| 22:45:19 | flaviu | Joe_knock: I'm not sure I understand |
| 22:45:27 | flaviu | OpenSSL is already in C |
| 22:46:01 | Joe_knock | aah crap, I kinda lost my train of thought there. |
| 22:46:32 | Joe_knock | Maybe I should switch C-port for Go/D port |
| 22:46:40 | Joe_knock | Go/D/Rust |
| 22:47:41 | Araq | that could be an option, Joe_knock |
| 22:48:01 | Araq | in general Python doesn't port well with its non existing types |
| 22:48:31 | Joe_knock | We could play "dirty" and use that "python within Nim" library someone contributed to make OpenSSL work too. |
| 22:49:16 | Araq | nah, that's not acceptable for the stdlib |
| 22:49:18 | flaviu | BoringSSL development seems quite active, so I'm not sure that it's ready |
| 22:49:41 | flaviu | Joe_knock: If you want to port something, port https://hg.python.org/cpython/file/fd80195b920f/Modules/_ssl.c https://hg.python.org/cpython/file/2.7/Lib/ssl.py to nim |
| 22:50:06 | ldlework | Araq: would you want me to implement an scgi server or client? |
| 22:50:17 | Joe_knock | I figured why I lost my train of thought: Java ... |
| 22:50:38 | flaviu | ldlework: https://github.com/Araq/Nimrod/blob/devel/lib/pure/scgi.nim ? |
| 22:50:52 | Araq | yeah listen to flaviu |
| 22:51:05 | ldlework | ...Araq heh did you forget it was already impelmented? lol |
| 22:51:23 | Araq | it doesn't use the new async+await features |
| 22:51:29 | Joe_knock | flaviu: Do we have something similar to this: "import _ssl" ? |
| 22:51:45 | Joe_knock | oh I see _ssl.c is there |
| 22:51:57 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 22:52:07 | flaviu | Joe_knock: yep. The hard work is porting _ssl.c, ssl.py is really simple |
| 22:52:22 | * | bjz quit (Ping timeout: 245 seconds) |
| 22:52:24 | Joe_knock | flaviu: Why wouldn't c2nim work for it? |
| 22:52:48 | flaviu | Joe_knock: It's not real C code, it's python FFI code. browse through it a bit and you'll see. |
| 22:53:09 | Araq | Joe_knock: we already have an openssl wrapper |
| 22:53:25 | * | vendethiel joined #nimrod |
| 22:53:31 | Araq | we have everything in fact, except that nobody knows how to deal with these bug reports: |
| 22:54:04 | Araq | https://github.com/Araq/Nimrod/issues/782 |
| 22:54:06 | Araq | https://github.com/Araq/Nimrod/issues/784 |
| 22:54:08 | Joe_knock | flaviu: I see it now. |
| 22:54:24 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 22:55:27 | Joe_knock | Araq: Where is the wrapper code? |
| 22:55:55 | flaviu | Joe_knock: Same place as the rest of the wrappers, https://github.com/Araq/Nimrod/blob/devel/lib/wrappers/openssl.nim |
| 22:56:08 | Joe_knock | and has anyone tried speaking to the OpenSSL guys (if they actually exist) ? |
| 22:57:05 | onionhammer | Joe_knock why? |
| 22:57:17 | onionhammer | Joe_knock the new-async stuff? |
| 22:57:55 | Joe_knock | onionhammer: I'm looking for a quick-start && even if it isn't async , I just want to get an idea of how you used POST for multiple purposes |
| 22:58:33 | Araq | flaviu: I cannot see what _ssl.c does except exposing some python FFI stuff |
| 22:59:13 | Joe_knock | I see that we don't like commenting in these wrapper files :P |
| 22:59:30 | Araq | they are generated, dude |
| 22:59:40 | ldlework | lol |
| 23:00:01 | onionhammer | Joe_knock sorry, i dont really have any up-to-date examples. Can you give an example of POST for multiple purposes? |
| 23:00:13 | onionhammer | you could try peeking through this repo https://github.com/onionhammer/ircfamiliar |
| 23:00:22 | onionhammer | but it's old/out of date usage of jester, and pretty crazy usage at that |
| 23:00:45 | onionhammer | https://github.com/onionhammer/ircfamiliar/blob/master/web/homecontroller.nim |
| 23:01:10 | * | Matthias247 joined #nimrod |
| 23:01:30 | Joe_knock | Araq: Perhaps i'm missing something, but when you say generated, from what are they being generated? |
| 23:01:42 | onionhammer | Joe_knock you can try the model/view/controller approach as well; https://github.com/onionhammer/ircfamiliar/blob/master/web/views/templates/master.nim |
| 23:01:58 | flaviu | Joe_knock: The openssl header files |
| 23:02:31 | flaviu | `c2nim libopenssl.h` or similiar, and then edited for syntax errors |
| 23:03:00 | Joe_knock | oh!!! so we did use c2nim for this part of it. |
| 23:03:38 | Araq | iirc for openssl it was pas2nim |
| 23:03:43 | Araq | but I could be wrong |
| 23:04:13 | Araq | however, c2nim surely has been used for lots of other things, Joe_knock |
| 23:05:17 | * | Matthias247_ quit (Ping timeout: 252 seconds) |
| 23:07:17 | Joe_knock | I'm just thinking about it ... How can we classify these OpenSSL errors? Is it an issue of "something wrong in our wrapper-generated code" or a complete code failure? |
| 23:07:43 | Joe_knock | something wrong in our wrapper-generated code = an error |
| 23:07:49 | * | untitaker quit (Ping timeout: 272 seconds) |
| 23:07:56 | flaviu | Those issues aren't in the wrapper, one of them is just that data isn't getting where it needs to be |
| 23:08:05 | flaviu | and the other I don't understand at all. |
| 23:09:46 | * | untitaker joined #nimrod |
| 23:12:42 | Joe_knock | It seems like one of those bugs that won't go away, Dec 2013 |
| 23:13:02 | dts | is there a way to tell nim to use certain tools when it invokkes the c compiler? |
| 23:14:37 | flaviu | What makes openssl even more terrible is that the name "openssl" refers to both a utility and the library, so it's difficult to google. |
| 23:16:01 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 23:16:55 | Joe_knock | flaviu: Lets go to the OpenSSL channel and direct them to our error outputs. If they can explain to us what the error means, we can debug from there. |
| 23:17:15 | Joe_knock | #openssl |
| 23:17:18 | flaviu | huh? I don't have any errors at the moment. |
| 23:17:24 | ldlework | dts: the docs explain it |
| 23:17:34 | Araq | dts: passL, passC compiler switches |
| 23:17:46 | Joe_knock | flaviu: those 2 issues that Araq linked to |
| 23:17:52 | flaviu | I'm just trying to find some documentation. There was a book written on openssl .. in 2002. |
| 23:17:55 | Joe_knock | or was it you |
| 23:18:11 | dts | ldlework, Araq thanks |
| 23:18:28 | flaviu | the problem with those issues isn't that there's an error, its that there's a lack of errors :P |
| 23:19:13 | Joe_knock | :P Let me ask them and see what they reckon the issue/s could be |
| 23:19:24 | Araq | isn't that a feature? too much security and we can't communicate anymore |
| 23:19:32 | flaviu | Joe_knock: sure, sounds good. |
| 23:20:10 | flaviu | Araq: Some malicious actor hacks into your modem and proxies all connections through his server |
| 23:20:26 | flaviu | Poof, you're screwed. |
| 23:21:08 | Araq | *shrug* I never expected this machine to be safe in the first place |
| 23:21:23 | Araq | I know too much about the underlying technology to trust it |
| 23:22:00 | ldlework | We could use a "requests" library like Python Requests |
| 23:22:04 | ldlework | that could be pretty cool |
| 23:22:44 | EXetoC | that has been um, requested, before |
| 23:23:04 | flaviu | Araq: But others expect to that a library that is implied to be secure actually be secure |
| 23:23:52 | ldlework | EXetoC: nice |
| 23:24:04 | ldlework | EXetoC: I'm also thinking of a port of Fabric |
| 23:24:19 | Araq | flaviu: well the issues are open and high priority |
| 23:24:28 | ldlework | It'd be cool if we were able to run Nim as script files |
| 23:24:55 | flaviu | Araq: I'm just saying that "isn't that a feature? too much security and we can't communicate anymore" doesn't make much sense |
| 23:25:04 | ldlework | #!/usr/bin/env nim c -r |
| 23:25:08 | ldlework | ^ would this do the strick? |
| 23:25:11 | ldlework | trick* |
| 23:25:17 | Araq | ok whatever |
| 23:25:50 | flaviu | ldlework: depends on the permissions on the containing directory |
| 23:26:06 | ldlework | flaviu: ah because of nimcache and the need to produce a binary? |
| 23:26:09 | flaviu | yep |
| 23:26:25 | ldlework | flaviu: ah so theroetically you could write a flag on the compiler to not do either of those |
| 23:26:34 | flaviu | Not quite. |
| 23:26:55 | flaviu | You would want a compiler wrapper to set up a temporary directory and get them to go there |
| 23:27:07 | flaviu | You can't just skip outputting the binary |
| 23:27:23 | flaviu | A script doing what I describe should be trivial to write though |
| 23:27:26 | ldlework | Hmm you could just set -o and whatever the cache flag is to ~/tmp |
| 23:27:56 | Joe_knock | going into the openssl room was probably a bad idea. The only guy that actually replied is more likely to slay me through the internet than help me |
| 23:28:12 | flaviu | Joe_knock: Can you gist the logs? |
| 23:28:55 | * | vendethiel joined #nimrod |
| 23:29:57 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 23:30:42 | Joe_knock | I'll start the gist *after* the insult or 2 I got :/ |
| 23:32:17 | ldlework | I may be totally out of my element |
| 23:32:30 | * | AFKMorpork is now known as AMorpork |
| 23:32:33 | ldlework | Bug are these bug reports not simply observing that our http client doesn't actively report when the certificate doesn't match the domain? |
| 23:32:48 | ldlework | As in, "Hey you need to implement certificate checking in your http client" |
| 23:32:56 | flaviu | Yes, I was looking on how to do that. |
| 23:33:03 | ldlework | rather than "There's a bug where the certificate isn't checked even though you implemented that already" |
| 23:33:18 | flaviu | But it looks like a ton of code for something really simple, which I find hard to believe. |
| 23:34:38 | Joe_knock | I'm beginning to think that maybe rewriting those 500 lines of generated code by hand may work better? |
| 23:34:57 | flaviu | Joe_knock: The autogenerated code doesn't actually have any logic, as far as I can tell |
| 23:35:10 | ldlework | I also feel like we should implement some basic protocol abstractions on which we build things like our http client |
| 23:35:17 | ldlework | and server, etc |
| 23:37:07 | ldlework | Like HTTP can be implemented in terms of an generalized lineReciever, http://twistedmatrix.com/documents/8.2.0/api/twisted.protocols.basic.LineReceiver.html |
| 23:37:07 | * | Trustable quit (Quit: Leaving) |
| 23:37:18 | ldlework | http://twistedmatrix.com/documents/8.2.0/api/twisted.web.http.HTTPClient.html |
| 23:37:21 | * | c74d quit (Remote host closed the connection) |
| 23:43:08 | ldlework | I think its pretty neat we have peg support |
| 23:43:26 | * | c74d joined #nimrod |
| 23:47:04 | * | c74d quit (Remote host closed the connection) |
| 23:50:17 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 23:50:40 | ldlework | Hmm, so the asyncdispatch module's futures are single callback, correct? |
| 23:51:16 | flaviu | ldlework: https://gist.github.com/flaviut/27c2dc9cd2d8f5ced4e4 |
| 23:51:32 | flaviu | Seems to work, it runs the script and cleans up after itself. |
| 23:51:33 | ldlework | Oh nice |
| 23:52:18 | ldlework | works :D |
| 23:52:35 | ldlework | well done |
| 23:52:55 | ldlework | We should just vendor this |
| 23:53:09 | * | vendethiel joined #nimrod |
| 23:54:22 | ldlework | Can someone show me some usage of the async macro? |
| 23:56:25 | ldlework | ah there is some on the new page |
| 23:56:26 | ldlework | news* |
| 23:57:54 | * | Boscop_ joined #nimrod |