| 00:03:49 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 00:05:35 | * | noam joined #nimrod |
| 00:16:00 | * | ics joined #nimrod |
| 00:17:57 | NimBot | Varriount/NimLime master bbea65d Erik O'Leary [+0 ±2 -0]: Added 'auto' keyword |
| 00:32:05 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 00:42:06 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:50:28 | * | nande quit (Remote host closed the connection) |
| 00:56:28 | def- | Hm, it's a bit unexpected that random for TSlices excludes the last element |
| 01:06:37 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 01:08:11 | * | saml_ joined #nimrod |
| 01:11:54 | OrionPK | whats up kids |
| 01:12:03 | * | lorxu quit (Ping timeout: 240 seconds) |
| 01:28:46 | * | Varriount|Mobile quit (Remote host closed the connection) |
| 01:32:22 | OrionPK | is there any way to say in-code to use the CPP compiler |
| 01:32:23 | OrionPK | instead of C |
| 01:38:25 | * | brson quit (Quit: leaving) |
| 01:38:37 | * | brson joined #nimrod |
| 01:42:20 | * | q66 quit (Quit: Leaving) |
| 01:47:45 | * | ics joined #nimrod |
| 02:36:11 | * | bjz joined #nimrod |
| 02:38:18 | * | Varriount|Mobile joined #nimrod |
| 03:01:10 | * | Demos_ quit (Ping timeout: 264 seconds) |
| 03:01:34 | * | Demos joined #nimrod |
| 03:01:57 | * | Demos is now known as Guest39981 |
| 03:53:50 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 04:02:21 | * | lorxu joined #nimrod |
| 04:20:54 | * | bjz joined #nimrod |
| 04:43:50 | * | brson quit (Ping timeout: 240 seconds) |
| 04:58:53 | * | saml_ quit (Quit: Leaving) |
| 05:42:06 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 05:42:23 | * | vendethiel joined #nimrod |
| 06:05:51 | * | vendethiel quit (Quit: q+) |
| 06:12:47 | * | Guest39981 quit (Read error: Connection reset by peer) |
| 06:33:18 | * | bjz quit (Ping timeout: 240 seconds) |
| 06:35:39 | * | bjz joined #nimrod |
| 06:35:39 | fowl | OrionPK, no, but you have defined(CPP) |
| 07:30:56 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 07:49:34 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
| 08:03:50 | * | kunev joined #nimrod |
| 08:07:25 | * | Varriount_ joined #nimrod |
| 08:10:51 | * | Varriount quit (Ping timeout: 240 seconds) |
| 08:25:43 | * | bjz joined #nimrod |
| 08:48:35 | * | flaviu quit (Ping timeout: 264 seconds) |
| 09:12:11 | * | kemet joined #nimrod |
| 09:18:09 | * | kemet quit (Read error: Connection reset by peer) |
| 09:18:14 | * | kemet1 joined #nimrod |
| 09:18:33 | * | kemet1 quit (Client Quit) |
| 09:26:33 | * | Matthias247 joined #nimrod |
| 09:37:01 | * | Trustable joined #nimrod |
| 10:09:35 | * | io2 joined #nimrod |
| 10:43:19 | * | BitPuffin joined #nimrod |
| 10:50:06 | * | MayurYa joined #nimrod |
| 10:50:07 | * | MayurYa quit (Changing host) |
| 10:50:07 | * | MayurYa joined #nimrod |
| 10:55:20 | * | q66 joined #nimrod |
| 11:07:38 | dom96 | hallo |
| 11:07:46 | def- | hi |
| 11:07:59 | dom96 | hey def-, how are you? |
| 11:08:34 | def- | Fine, thanks. And yourself, dom96? |
| 11:08:49 | dom96 | good. |
| 11:09:28 | dom96 | Up to much? |
| 11:09:44 | def- | Trying to figure out why foldl/foldr only work outside of procs |
| 11:10:33 | dom96 | interesting. Maybe I can help? |
| 11:12:13 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 11:13:44 | def- | i don't know, it's kind of weird |
| 11:14:16 | * | dom96 is fighting async |
| 11:21:16 | * | PsyMinerva joined #nimrod |
| 11:22:33 | * | PsyMinerva left #nimrod ("Salir") |
| 11:23:22 | def- | ok, it's another issue with inference of parameter types |
| 11:24:54 | def- | and additionally you need a "result = x" instead of x |
| 11:27:47 | dom96 | can you show me the issue? |
| 11:27:58 | def- | sure, wait 1 moment |
| 11:28:43 | * | Matthias247 joined #nimrod |
| 11:29:12 | def- | dom96: https://gist.github.com/def-/2578abe885f99670e35e |
| 11:29:22 | def- | it's not with foldr/foldl right now, but they have the same problem |
| 11:29:29 | def- | prime works, but i wanted prime2 |
| 11:32:05 | dom96 | ahh |
| 11:32:48 | dom96 | Does primer2[T](a: T): bool work? |
| 11:33:38 | dom96 | Also, "toSeq 2 .. int sqrt float a" is that correct? |
| 11:34:09 | def- | apparently yes |
| 11:35:44 | dom96 | I'm having a hard time parsing that in my head lol |
| 11:37:04 | Araq | int(sqrt(float(a))) |
| 11:37:22 | dom96 | i see |
| 11:41:03 | * | MayurYa quit (Ping timeout: 240 seconds) |
| 11:41:29 | Araq | and before you complain about it |
| 11:41:42 | Araq | this feature enables your 'await' syntax |
| 11:41:52 | Araq | :P |
| 11:44:31 | dom96 | yes, i'm aware. |
| 11:45:01 | dom96 | So I have to blame def- for overusing it :P |
| 11:45:34 | def- | I just didn't like all the brackets! |
| 11:46:07 | Araq | and rightly so. I always blame Einstein for his use of integrals |
| 11:46:08 | def- | my compromise for now is sqrt(a.float).int, so that the important stuff is at the start, and the type stuff at the end |
| 11:47:21 | Araq | def-: the point of a syntax is to avoid brackets |
| 11:47:41 | Araq | so you're doing just fine ;-) |
| 11:52:58 | * | io2 quit (Ping timeout: 240 seconds) |
| 11:59:06 | * | io2 joined #nimrod |
| 11:59:08 | * | io2 quit (Changing host) |
| 11:59:08 | * | io2 joined #nimrod |
| 12:06:32 | * | Varriount_ quit (*.net *.split) |
| 12:06:32 | * | BlameStross quit (*.net *.split) |
| 12:06:32 | * | Francisco quit (*.net *.split) |
| 12:06:32 | * | Jesin quit (*.net *.split) |
| 12:06:33 | * | Skrylar quit (*.net *.split) |
| 12:06:33 | * | betawaffle quit (*.net *.split) |
| 12:06:34 | * | noam quit (*.net *.split) |
| 12:06:34 | * | rektide quit (*.net *.split) |
| 12:06:34 | * | mko quit (*.net *.split) |
| 12:06:34 | * | clone1018 quit (*.net *.split) |
| 12:06:35 | * | flyx quit (*.net *.split) |
| 12:06:35 | * | kunev quit (*.net *.split) |
| 12:06:35 | * | lorxu quit (*.net *.split) |
| 12:06:36 | * | fowl quit (*.net *.split) |
| 12:06:36 | * | btiffin quit (*.net *.split) |
| 12:06:36 | * | CARAM_ quit (*.net *.split) |
| 12:06:36 | * | Zuchto quit (*.net *.split) |
| 12:06:37 | * | dom96 quit (*.net *.split) |
| 12:06:37 | * | rixx quit (*.net *.split) |
| 12:06:38 | * | Raynes quit (*.net *.split) |
| 12:06:38 | * | silven quit (*.net *.split) |
| 12:06:38 | * | Matthias247 quit (*.net *.split) |
| 12:06:39 | * | Roin quit (*.net *.split) |
| 12:06:39 | * | Amrykid quit (*.net *.split) |
| 12:06:39 | * | Araq quit (*.net *.split) |
| 12:06:40 | * | darkfusi1n quit (*.net *.split) |
| 12:06:40 | * | TylerE quit (*.net *.split) |
| 12:06:41 | * | mal`` quit (*.net *.split) |
| 12:06:41 | * | milosn_ quit (*.net *.split) |
| 12:06:41 | * | untitaker quit (*.net *.split) |
| 12:06:42 | * | phI||Ip quit (*.net *.split) |
| 12:06:42 | * | mmatalka quit (*.net *.split) |
| 12:06:42 | * | reloc0 quit (*.net *.split) |
| 12:06:42 | * | comex quit (*.net *.split) |
| 12:06:42 | * | jez0990_ quit (*.net *.split) |
| 12:06:43 | * | oddmunds quit (*.net *.split) |
| 12:06:43 | * | bstrie quit (*.net *.split) |
| 12:06:43 | * | def- quit (*.net *.split) |
| 12:07:24 | * | Matthias247 joined #nimrod |
| 12:07:24 | * | Varriount_ joined #nimrod |
| 12:07:24 | * | kunev joined #nimrod |
| 12:07:24 | * | lorxu joined #nimrod |
| 12:07:24 | * | noam joined #nimrod |
| 12:07:24 | * | BlameStross joined #nimrod |
| 12:07:24 | * | Francisco joined #nimrod |
| 12:07:24 | * | rektide joined #nimrod |
| 12:07:24 | * | milosn_ joined #nimrod |
| 12:07:24 | * | Jesin joined #nimrod |
| 12:07:24 | * | mko joined #nimrod |
| 12:07:24 | * | btiffin joined #nimrod |
| 12:07:24 | * | untitaker joined #nimrod |
| 12:07:24 | * | clone1018 joined #nimrod |
| 12:07:24 | * | Skrylar joined #nimrod |
| 12:07:24 | * | flyx joined #nimrod |
| 12:07:24 | * | def- joined #nimrod |
| 12:07:24 | * | oddmunds joined #nimrod |
| 12:07:24 | * | jez0990_ joined #nimrod |
| 12:07:24 | * | comex joined #nimrod |
| 12:07:24 | * | bstrie joined #nimrod |
| 12:07:24 | * | betawaffle joined #nimrod |
| 12:07:24 | * | reloc0 joined #nimrod |
| 12:07:24 | * | mmatalka joined #nimrod |
| 12:07:24 | * | phI||Ip joined #nimrod |
| 12:07:24 | * | Roin joined #nimrod |
| 12:07:24 | * | Amrykid joined #nimrod |
| 12:07:24 | * | Araq joined #nimrod |
| 12:07:24 | * | darkfusi1n joined #nimrod |
| 12:07:24 | * | TylerE joined #nimrod |
| 12:07:24 | * | mal`` joined #nimrod |
| 12:07:24 | * | CARAM_ joined #nimrod |
| 12:07:24 | * | Zuchto joined #nimrod |
| 12:07:24 | * | dom96 joined #nimrod |
| 12:07:24 | * | rixx joined #nimrod |
| 12:07:24 | * | Raynes joined #nimrod |
| 12:07:24 | * | silven joined #nimrod |
| 12:07:24 | * | fowl joined #nimrod |
| 12:10:03 | * | X-Scale quit (Ping timeout: 249 seconds) |
| 12:15:32 | * | Jesin quit (Excess Flood) |
| 12:16:25 | * | Jesin joined #nimrod |
| 12:17:02 | * | t0d0r joined #nimrod |
| 12:17:44 | Araq | hi t0d0r welcome |
| 12:18:24 | * | X-Scale joined #nimrod |
| 12:30:51 | * | untitaker quit (Ping timeout: 240 seconds) |
| 12:35:24 | * | t0d0r quit (Quit: t0d0r) |
| 12:36:33 | * | untitaker joined #nimrod |
| 12:37:33 | * | t0d0r joined #nimrod |
| 12:40:40 | * | saml_ joined #nimrod |
| 12:50:46 | * | t0d0r quit (Quit: t0d0r) |
| 12:54:05 | * | kunev quit (Quit: е те) |
| 12:58:02 | * | darkf quit (Quit: Leaving) |
| 13:12:09 | * | t0d0r joined #nimrod |
| 13:12:10 | * | t0d0r quit (Client Quit) |
| 13:24:02 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 13:24:20 | * | io2 joined #nimrod |
| 13:25:51 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
| 13:35:03 | * | BitPuffin quit (Ping timeout: 256 seconds) |
| 14:01:52 | * | EXetoC joined #nimrod |
| 14:04:03 | * | q66 quit (Quit: Leaving) |
| 14:04:24 | * | q66 joined #nimrod |
| 14:12:58 | * | milosn_ quit (Read error: No route to host) |
| 14:13:15 | * | milosn joined #nimrod |
| 14:45:24 | OrionPK | fowl doesnt work |
| 14:45:34 | OrionPK | CPP isnt defined w/ cpp compiler chosen |
| 14:45:58 | Araq | but it should be |
| 14:46:35 | OrionPK | sec |
| 14:47:19 | OrionPK | oops |
| 14:47:22 | OrionPK | I used if instead of when |
| 14:47:26 | OrionPK | my bad, it totally works |
| 14:47:32 | Araq | what do you guys think of foo.bar(.int, string, int.) as a syntax to refer to a particular overload |
| 14:48:19 | OrionPK | you mean to pass it? |
| 14:48:31 | Araq | I mean the (. .) brackets |
| 14:48:52 | * | flaviu joined #nimrod |
| 14:49:07 | OrionPK | well, I dislike the {. .} brackets, so u know my opinion probably :P |
| 14:49:22 | Araq | I see |
| 14:49:49 | Araq | well do you have an alternative that works with nimrod's syntax? |
| 14:52:54 | OrionPK | (int, string => int)foo.bar |
| 14:52:55 | OrionPK | idk |
| 14:53:04 | OrionPK | thats like a cast |
| 14:53:09 | OrionPK | if it fulfills the cast it compiles |
| 14:53:40 | dom96 | That would be inconsistent with the stuff in the future module I think |
| 14:54:04 | OrionPK | ((int, string) => int)foo.bar probably |
| 14:55:08 | dom96 | Yeah, that could work. Maybe. |
| 14:55:18 | dom96 | Araq: How is it done in other languages? |
| 14:58:33 | Araq | dom96: it isn't done |
| 15:01:03 | OrionPK | is my syntax even feasible? |
| 15:01:53 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 15:02:11 | OrionPK | because I think cast syntax is a lot more familiar |
| 15:33:49 | * | BitPuffin joined #nimrod |
| 15:54:18 | * | ics quit (Ping timeout: 240 seconds) |
| 15:55:53 | flaviu | What use would refering to a specific overload be? |
| 15:56:59 | flaviu | If its unclear what the types are, foo.bar(a.int, b.string, c.int) is fine |
| 15:57:12 | * | saml_ quit (Quit: Leaving) |
| 15:57:26 | * | ics joined #nimrod |
| 16:15:04 | def- | Oh, I can't use any character as an operator =/ |
| 16:18:42 | * | vendethiel joined #nimrod |
| 16:33:01 | * | Puffin joined #nimrod |
| 16:33:08 | * | Puffin quit (Client Quit) |
| 16:33:17 | * | Puffin joined #nimrod |
| 16:33:28 | * | Puffin quit (Client Quit) |
| 16:35:58 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 16:51:54 | * | Jehan_ joined #nimrod |
| 16:52:36 | * | BitPuffin joined #nimrod |
| 17:03:44 | dom96 | yay, async works. |
| 17:04:29 | Araq | :O |
| 17:04:33 | Araq | release tomorrow! |
| 17:04:41 | dom96 | lol |
| 17:04:45 | Araq | well |
| 17:04:55 | dom96 | still slower than Go on linux though |
| 17:04:58 | Araq | you now have to test it with the new_spawn branch |
| 17:05:02 | dom96 | doesn't seem to scale as well |
| 17:06:38 | * | xenagi joined #nimrod |
| 17:07:13 | Araq | hmmm "Would you buy nimrod.org at $499? " |
| 17:07:15 | EXetoC | I mentioned nimrod in a lua channel, and of course case sensitivity came up in addition to "too pythony" :> |
| 17:07:48 | Araq | I mentioned Lua in the #nimrod channel and ofc "dynamic typing" came up |
| 17:07:55 | EXetoC | ^_^ |
| 17:08:25 | dom96 | Araq: I wouldn't, have you decided not to rename? |
| 17:09:19 | Araq | I haven't decided anything |
| 17:09:34 | Araq | but no, I'm not buying nimrod.org for 500 dollars |
| 17:10:01 | Jehan_ | I still think that researching the applicability of the Sapir-Whorf hypothesis to programming languages could be a fruitful exercise. |
| 17:10:13 | EXetoC | nimlang |
| 17:11:23 | Jehan_ | Just call it the N programming language. :) |
| 17:12:02 | flaviu | Huh. That actually hasn't been taken |
| 17:12:19 | EXetoC | nevermind searchability |
| 17:12:22 | Araq | I still don't know how anybody with half a brain can think case sensitivity to be a useful feature ... |
| 17:12:25 | flaviu | EXetoC: NLang |
| 17:12:59 | Araq | on many Linux machines foo<tab> doesn't work when the directory is called Foobar |
| 17:13:02 | Jehan_ | Araq: I think that both case sensitivity and case insensitivity can be useful and have their advantages and disadvantages. |
| 17:13:47 | Jehan_ | None of which are (IMO) strong enough to stress out over. |
| 17:14:48 | Araq | what's the advantage? |
| 17:16:09 | flaviu | Araq: For case sensitivity? You can't access foo as FoO, the compiler enforces that your naming is consistant |
| 17:17:07 | Araq | flaviu: you should use the machine for what it's good for: automating stuff |
| 17:17:42 | Araq | with insensitivity you can make your tools ensure it's displayed consistently |
| 17:18:18 | fowl | Araq, i was just thinking about specific overloads outside |
| 17:18:29 | flaviu | Make code linters part of the compile process basicly? |
| 17:19:33 | Araq | bbl |
| 17:19:48 | Araq | use case: |
| 17:20:35 | Araq | vm.registerProc("stdlib.system.open(.TFile, OpenFlags.)", openWrapper) |
| 17:24:10 | fowl | i think it can be done with a macro like specificf(open, TFile, OpenFlags) |
| 17:26:22 | Jehan_ | W.r.t case sensitivity: the most common use case is disambiguation, where you want to use both "foo" and "Foo" (because the domain demands it), but can't. |
| 17:26:43 | Jehan_ | As I said, this is a minor thing. It's not like case-insensitivity has compelling advantages, either. |
| 17:30:16 | * | enurlyx joined #nimrod |
| 17:35:08 | fowl | Araq, https://gist.github.com/fowlmouth/609a8057fc473f9e2519 |
| 17:38:11 | fowl | works better as a template |
| 17:39:06 | Araq | fowl: impressive :-) |
| 17:40:45 | Araq | but it doesn't solve the problem |
| 17:40:53 | * | Demos joined #nimrod |
| 17:41:15 | Araq | I need this syntax to be encoded in string literals, see my example |
| 17:41:53 | Araq | I thought it would be nice to come up with a syntax that will also be valid nimrod syntax for that |
| 17:42:31 | Jehan_ | You're trying to disambiguate overloaded functions from what I can see in the log? |
| 17:43:03 | fowl | Araq, oh |
| 17:43:41 | Araq | Jehan_: yes |
| 17:44:36 | Jehan_ | In Talis, I'm using :: as an "interpret as type of" operator to resolve ambiguities in type inference (of which ambiguous overloading is just a special case). |
| 17:44:45 | fowl | Araq, you need a custom thing your vm, so you want to encode the function type to a string, and get the right function pointer, (as a void pointer i assume), right? |
| 17:45:00 | Jehan_ | C++ allows you to resolve it in two ways: |
| 17:45:28 | Jehan_ | (1) a static_cast to the desired type and (2) assignment to a variable of the desired type. |
| 17:45:29 | Araq | fowl: yes |
| 17:46:19 | Araq | Jehan_: I know and nimrod allows the same |
| 17:46:21 | Jehan_ | Generally, function overloading is equivalent to generics with invisible type parameters, so this would be another way to resolve it. |
| 17:46:29 | fowl | Araq, i would just make it parse a string like "(a,b)c" for proc(:a, :b): c |
| 17:46:57 | Araq | fowl: that's too ugly |
| 17:47:17 | Araq | but lol |
| 17:47:24 | Jehan_ | You already need to handle generics, right? |
| 17:47:26 | fowl | it'd be super simple, left to right |
| 17:47:48 | Araq | well your subconcious suggestion is excellent |
| 17:47:50 | fowl | now araq cares about code beauty in the compiler |
| 17:48:03 | Araq | fowl: no, it's an exposed API |
| 17:48:22 | Araq | stdlib.system.open(:TFile, :TFileMode) |
| 17:48:43 | Araq | your way with the ':' prefix is cool |
| 17:49:00 | fowl | Araq, can you pass a str literal and call parseexpr on it? if so you can just use "proc(f:TFile, mode:TFileMode)" :) |
| 17:49:26 | fowl | Araq, i was just using that to demonstrate the result type (a proc with arg names that dont matter) |
| 17:49:58 | Araq | fowl: yes, I know, but I really like it |
| 17:51:31 | Araq | well if it'd be valid nimrod syntax, I could indeed parseExpr it |
| 17:53:47 | Jehan_ | For your specific example, why can't you just use a proc prototype for the string? |
| 17:54:18 | fowl | Jehan_, i just try it and parseexpr wont take "proc(a,b:int):int" |
| 17:54:35 | Jehan_ | E.g.L vm.registerProc("stdlib.system.open(x: TFile, y: OpenFlags)", openWrapper) |
| 17:54:51 | Araq | and more importantly: proc stlib.system.open ... is not valid syntax |
| 17:55:16 | Jehan_ | fowl: Yeah, but any new syntax would need new parser support, anyway? |
| 17:55:28 | fowl | thats not new syntax, its a proc type |
| 17:55:31 | Araq | I could however do it like this: |
| 17:55:48 | Araq | vm.registerProc("stdlib", "system", "proc open ...") |
| 17:55:49 | Jehan_ | fowl: Yes. I mean, if Araq were to use a new syntax for this. |
| 17:56:13 | fowl | i'm trying to do it without new syntax because you guys dont see it but every time new syntax is added i throw my arms up in outrage and sometimes it comes out of my shoulder |
| 17:56:51 | fowl | lol |
| 17:57:02 | Araq | fowl: can't tell if you're serious |
| 17:57:06 | fowl | "(proc(a,b:int):int)" parseexprs, but not without the parens |
| 17:57:59 | Jehan_ | Perhaps we need a parseType primitive, too? Or is there one already? |
| 17:58:55 | Araq | yeah well |
| 17:59:13 | Araq | "parseExpr" wasn't really planned either |
| 17:59:21 | Araq | it grew into existance |
| 18:00:48 | Araq | how do I tell parseExpr to use #! strongSpaces? |
| 18:01:08 | Araq | see? - no planning involved |
| 18:02:44 | Jehan_ | Heh. :) |
| 18:03:54 | * | gsingh93_ joined #nimrod |
| 18:04:19 | Araq | the types API however has been designed |
| 18:04:25 | fowl | Araq, so, looks like you can do it right away with something like specificf(system.open, "(proc(f:TFile; flags:OpenFlags))") i'd make it return a literal tuple with all that info ("system.open","proc(..)",functionpointer) |
| 18:04:42 | Araq | took me years to come up with its design |
| 18:04:58 | Araq | and it's superb |
| 18:05:18 | Araq | the only problem is that it hasn't been implemented ... ;-) |
| 18:06:20 | Araq | fowl: are you really that concerned about syntax additions? |
| 18:06:53 | Araq | if so, I can make the syntax in the string literals a special case that has nothing to do with proper nimrod syntax |
| 18:06:59 | fowl | is it planned for some kind of halfway type alias? like type intptr_t{.importc:"intptr_t",header:"stdint.h".} = int # <- uses int instead of intptr_t |
| 18:07:13 | fowl | currently^ |
| 18:07:26 | Araq | hmm that should alredy work |
| 18:08:43 | fowl | Araq, i dont think any new syntax would be clearer than proc(...), we have a new syntax for declaring proc types though, in future.nim, it looks like (int,int)->int |
| 18:09:19 | Araq | fowl: no we don't |
| 18:09:26 | Araq | technically it's not new syntax at all |
| 18:09:30 | Araq | but you know that |
| 18:09:50 | fowl | http://build.nimrod-lang.org/docs/future.html#-%3E.m,expr,expr |
| 18:10:03 | fowl | it matches do syntax, and thats newish |
| 18:10:28 | Araq | well I didn't change the parser for the feature, so it's not new syntax |
| 18:10:49 | Araq | in fact, that's exactly what caused some problems already |
| 18:11:36 | Araq | (x, y) => x + y # was always valid nimrod code |
| 18:11:50 | * | Jesin quit (Quit: Leaving) |
| 18:14:19 | * | Jesin joined #nimrod |
| 18:14:25 | fowl | i dont think (int) -> (int) -> int works either |
| 18:16:28 | fowl | i can fix that though |
| 18:16:47 | Araq | go for it please |
| 18:17:30 | Araq | argh |
| 18:18:06 | Araq | all I wanted to do is to give the VM stuff from os and math.nim |
| 18:18:22 | Araq | now I'm writing some generic proc signature matcher |
| 18:18:49 | fowl | my way doesnt work? |
| 18:19:27 | Araq | your way is too ugly for an API that the VM exposes |
| 18:20:14 | * | Matthias247 joined #nimrod |
| 18:29:10 | Jehan_ | Araq: If the use is limited, why not write wrapper functions without overloading and pass them around? |
| 18:40:04 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 18:41:52 | Araq | well system.open exists and is overloaded |
| 18:42:30 | Araq | and I dont want to make people use staticOpen for cte |
| 18:44:48 | Araq | but pckg.module.ident is good enough for a start anyway |
| 18:48:33 | * | bjz quit (Ping timeout: 240 seconds) |
| 18:48:37 | Araq | fowl: what about my operator lifting syntax? you dislike that idea as well? |
| 18:51:14 | * | bjz joined #nimrod |
| 18:56:37 | * | ics joined #nimrod |
| 19:03:14 | fowl | Araq, "open(:tfile, :filemode):void" ? |
| 19:07:16 | fowl | looks fine |
| 19:07:32 | Araq | yes indeed |
| 19:08:20 | fowl | will i be able to use wrappers on the vm them? |
| 19:08:22 | fowl | then* |
| 19:08:55 | Araq | no, only what has been registered to the VM |
| 19:09:08 | fowl | is the VM in the RTL |
| 19:10:28 | Araq | soon |
| 19:11:01 | fowl | should be possible when it is |
| 19:11:59 | Araq | well I made libFFI work with it onc |
| 19:12:00 | Araq | *once |
| 19:12:04 | Araq | I won't do it again |
| 19:12:15 | Araq | it's full of subtle edge cases |
| 19:12:17 | dom96 | The 'do' notation caused more problems than it solved IMO. |
| 19:13:10 | dom96 | Araq: What will registerProc do? |
| 19:13:11 | Araq | dom96: yes, but it's also quite sucessful |
| 19:16:47 | fowl | dom96, it resolves the function to the right type and returns it, with information on the type, to the vm, to be exposed as a compile-time function |
| 19:17:50 | fowl | resolving overloads and such |
| 19:18:05 | dom96 | oh, so this is a part of the infamous type API? |
| 19:18:16 | Araq | no, it's not |
| 19:18:51 | * | kunev joined #nimrod |
| 19:18:57 | dom96 | ahh, so it doesn't return info about the type to the user, just to the VM? |
| 19:19:12 | Araq | it tells the VM what to do with system.open |
| 19:19:20 | Araq | how it should be executed |
| 19:19:51 | dom96 | I still don't get it. |
| 19:20:07 | dom96 | What is there to tell the VM? |
| 19:22:21 | Araq | well look at how 'echo' is implemented |
| 19:22:31 | Araq | it's got its own opcode, opcEcho |
| 19:22:39 | Araq | we already have hundreds of opcodes |
| 19:22:46 | Araq | and the limit is 256 |
| 19:23:17 | Araq | this doesn't work for everything we like the VM to do |
| 19:23:29 | Araq | so we need a mechanism to extend the VM |
| 19:23:42 | Araq | which is what registerProc provides |
| 19:24:31 | * | Demos_ joined #nimrod |
| 19:26:03 | * | Demos quit (Ping timeout: 240 seconds) |
| 19:29:10 | dom96 | ok so this is a workaround to you not allowing FFI in the VM? |
| 19:31:09 | Araq | exactly |
| 19:36:43 | dom96 | Araq: C#'s Task.Run works together with async await. |
| 19:38:17 | * | kunev quit (Ping timeout: 256 seconds) |
| 19:40:37 | * | io2 quit (Ping timeout: 240 seconds) |
| 19:41:16 | * | q66_ joined #nimrod |
| 19:42:58 | * | q66 quit (Ping timeout: 240 seconds) |
| 19:43:13 | Araq | dom96: so? |
| 19:43:17 | fowl | how can i make this use dot syntax (x.foo instead of x<<foo) https://gist.github.com/fowlmouth/ab9100de8c57c30d7c3e |
| 19:43:39 | dom96 | Araq: It's nice. Thought you might be interested. |
| 19:44:32 | Araq | ah ok |
| 19:44:48 | Araq | fowl: dunno if its possible |
| 19:45:08 | Araq | maybe you shouldn't use a maybe if the maybe gets annoying |
| 19:45:52 | Araq | even Haskell has exceptions and even Haskell doesn't wrap OOM in a maybe |
| 19:46:03 | fowl | you're right, .? is a better operator anyways, thanks araq (: |
| 19:46:19 | * | io2 joined #nimrod |
| 19:46:20 | * | Araq is tired of FP propaganda |
| 19:48:26 | fowl | template `.?` [T] (a:TMaybe[T]; b): expr = |
| 19:48:26 | fowl | (if a.has: just(a.val.b) else: nothing[type(a.val.b)]()) |
| 19:48:43 | fowl | allows field access too |
| 19:50:36 | dom96 | Anybody got a link to that Nimrod VS plugin handy? |
| 19:52:38 | Araq | fowl: what about having a @`+` b as a shortcut for: `@`(`+`, a, b) |
| 19:52:56 | Araq | would be nice for some general lifting operator |
| 19:53:46 | fowl | what is that lifting exactly? |
| 19:53:54 | fowl | i would just type @(a + b) |
| 19:55:30 | dom96 | The fact that Futures capture exceptions is slightly problematic. |
| 19:55:39 | dom96 | It appears that C# does exactly the same. |
| 19:56:45 | dom96 | The problem is that the exceptions disappear once they reach the global scope instead of being thrown. |
| 19:57:00 | dom96 | hrm, I just got an idea how to solve that. |
| 19:57:39 | Araq | fowl: for instance going from T to seq[T] |
| 19:57:51 | Araq | a + b # for ints |
| 19:58:00 | dom96 | No, that won't work. |
| 19:58:02 | Araq | a @`+` b # for seqs of ints |
| 19:58:08 | dom96 | Araq: I need your input on this. |
| 19:58:28 | Araq | whats the problem? |
| 19:58:51 | Araq | exceptions already keep the original stack trace for reasons like this |
| 19:58:56 | dom96 | a @`+` b, you're adding two sequences? |
| 19:59:19 | Araq | dom96: element-wise, yes |
| 19:59:58 | Araq | I could overload + for seqs, but that's not the point |
| 20:00:23 | dom96 | So: @[a[0] + b[0], a[1] + b[1], ...] ? |
| 20:00:41 | Araq | yup |
| 20:02:12 | dom96 | I don't like it. |
| 20:02:42 | dom96 | It would be rarely used I think? |
| 20:02:49 | dom96 | So why give it an operator? |
| 20:03:03 | Araq | it's a slightly more general 'map' |
| 20:03:17 | Araq | it's not rare at all |
| 20:05:34 | dom96 | Then there must be a well known name for a function that performs this operation |
| 20:05:50 | Araq | 'lift' ? |
| 20:06:15 | dom96 | I don't think so |
| 20:09:06 | Araq | ok ok, so I'm not gonna add it |
| 20:10:57 | dom96 | good :P |
| 20:10:59 | dom96 | now |
| 20:11:12 | * | Boscop quit (Read error: Connection reset by peer) |
| 20:11:23 | dom96 | proc foo {.async.} = raise newException(EBase, "foo") |
| 20:11:27 | dom96 | foo() |
| 20:11:34 | dom96 | # No exception raised |
| 20:11:39 | dom96 | That is the problem. |
| 20:13:37 | fowl | dom96, does foo keep running after the raise? |
| 20:14:48 | dom96 | no |
| 20:15:03 | * | EXetoC quit (Ping timeout: 240 seconds) |
| 20:15:39 | dom96 | foo will return a Future after the raise. |
| 20:18:23 | Matthias247 | and what's wrong about that? async methods should always return Futures? They do that in C# too |
| 20:18:42 | * | Jesin quit (Quit: Leaving) |
| 20:19:01 | Araq | dom96: when IS the exception raised then? |
| 20:19:14 | dom96 | What is wrong is that the exception is lost. |
| 20:19:36 | dom96 | We can say that it's up to the programmer to make sure that they ensure they are not discarding any futures accidentally. |
| 20:19:46 | dom96 | Especially in the global scope. |
| 20:20:05 | dom96 | Araq: Never, unless you await the future returned by 'foo' or try to read it manually. |
| 20:22:14 | BitPuffin | dom96: you should look at lwt |
| 20:22:34 | * | EXetoC joined #nimrod |
| 20:22:47 | Matthias247 | The exception should get stored in the returned future |
| 20:23:08 | dom96 | Matthias247: That is what happens. |
| 20:23:08 | Matthias247 | and when you await foo it should be rethrown |
| 20:23:37 | Araq | yes what Matthias247 says |
| 20:24:03 | Matthias247 | when you simply discard the future without doing anything with it - yes, it will be lost |
| 20:24:04 | BitPuffin | dom96: http://ocsigen.org/lwt/2.4.3/manual/manual |
| 20:24:13 | Matthias247 | that''s however the same for all Future/Task implementations |
| 20:24:31 | Araq | dom96: you could throw it in a finalizer if it hasn't been thrown already |
| 20:24:33 | dom96 | Matthias247: I see. Doing this feels risky though. |
| 20:24:42 | Araq | but I'm not sure it's a good idea |
| 20:24:43 | * | Jesin joined #nimrod |
| 20:24:46 | dom96 | Araq: Tried that. Finalizer doesn't seem to be called. |
| 20:25:03 | Araq | well it's not deterministic |
| 20:25:10 | dom96 | This means that everyone will need to basically write: |
| 20:25:12 | dom96 | var fut = foo() |
| 20:25:27 | Matthias247 | Araq: I wouldn't do that. I often discard Tasks by intention |
| 20:25:31 | dom96 | fut.callback = proc () = if fut.failed: raise fut.exception |
| 20:25:35 | Matthias247 | when I'm really not itnerested in the return value |
| 20:25:50 | Matthias247 | and it would kill my applications when that throws somewhere |
| 20:25:53 | Araq | Matthias247: yeah I can imagine |
| 20:26:06 | Araq | I don't propose this solution |
| 20:26:18 | Araq | I'm only saying it's possible |
| 20:26:23 | Matthias247 | you would event not know where it throws - because a future has no determined position at which it is fulfilled |
| 20:27:03 | Araq | well it's more like a crash than a throw |
| 20:27:26 | dom96 | yes, that is likely a bad idea. |
| 20:28:11 | dom96 | I fear everyone will forget to check for exceptions though. |
| 20:28:18 | * | io2 quit (Ping timeout: 240 seconds) |
| 20:28:20 | dom96 | And then they will be puzzled about why their stuff doesn't work. |
| 20:28:57 | dom96 | The only thing I can do is to provide a function which will essentially do what I wrote above. |
| 20:29:08 | dom96 | Unless you guys have any other ideas? |
| 20:29:19 | dom96 | If not then ideas for a name for this function would be great. |
| 20:30:17 | Araq | propagateException() |
| 20:30:27 | dom96 | too long |
| 20:30:52 | Araq | propagateError |
| 20:32:08 | dom96 | too long |
| 20:34:09 | Araq | wait a sec |
| 20:34:17 | Araq | when do people have to call it? |
| 20:34:31 | dom96 | Only at the global scope |
| 20:34:45 | dom96 | Which makes me feel like it shouldn't be necessary :\ |
| 20:35:24 | Araq | you mean like in: |
| 20:35:33 | Araq | var globalVar = foo() |
| 20:35:35 | Araq | ? |
| 20:35:50 | Araq | var localVar = foo() # is fine? |
| 20:36:00 | Matthias247 | hmm, either you want the result and then you await the future or make Future.get() or sth. like this and then the exception is thrown |
| 20:36:05 | Matthias247 | or you are not itnerested |
| 20:36:50 | dom96 | actually you're right. |
| 20:36:54 | dom96 | It's not just the global scope. |
| 20:37:25 | dom96 | Matthias247: What is the proc returns void? |
| 20:37:27 | dom96 | *if |
| 20:37:51 | Matthias247 | you mean Future<void>? |
| 20:38:00 | dom96 | yes |
| 20:38:16 | dom96 | you may await it |
| 20:38:23 | Matthias247 | yes |
| 20:38:29 | dom96 | but if you're not, you won't be interested in its result |
| 20:38:38 | dom96 | unless you remember that exceptions can happen heh |
| 20:38:49 | Matthias247 | you wait for it's completion, even if there's no return value |
| 20:39:34 | dom96 | what if you don't want to wait? |
| 20:39:35 | Matthias247 | if you are interested if an error happened you can still either await it or do future.get() |
| 20:40:05 | Matthias247 | in Java you can query Future.isCompletedExceptionally(). I think in other implementations similar |
| 20:40:06 | dom96 | the problem is that you likely are always interested |
| 20:40:07 | Matthias247 | http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html |
| 20:40:17 | dom96 | it's just that programmers will not be used to thinking this way |
| 20:40:39 | dom96 | And it's a PITA to check every async proc for exceptions |
| 20:40:48 | dom96 | (that you do not await) |
| 20:41:15 | Matthias247 | yes, because the majority of programmers are not familar with modern async concepts |
| 20:41:33 | Matthias247 | but you won't make it better if you do it differnt than the other implemntations |
| 20:45:34 | dom96 | perhaps I shouldn't make async procs discardable |
| 20:45:54 | Araq | yes indeed, you shouldn't |
| 20:46:10 | * | Jesin quit (Remote host closed the connection) |
| 20:48:01 | Araq | I always wondered why you did it this way |
| 20:48:11 | Araq | why are they discardable in the first place? |
| 20:49:24 | dom96 | for convenience :P |
| 20:50:38 | Araq | good |
| 20:50:45 | Araq | that means it's easy to change |
| 20:51:01 | Araq | I feared there is some technical reason to do so |
| 20:51:27 | dom96 | well maybe I had a better reason |
| 20:51:31 | dom96 | I can't remember. |
| 20:53:38 | Araq | well soon you will be remembered |
| 20:54:10 | dom96 | yeah, I probably shouldn't be watching The International :P |
| 20:54:11 | * | Johz joined #nimrod |
| 21:08:32 | OrionPK | dom96 any progress on that 64kb SCGI issue? |
| 21:09:25 | dom96 | OrionPK: Try switching to Jester new_async branch and not using scgi. |
| 21:10:07 | * | ARCADIVS joined #nimrod |
| 21:12:16 | dom96 | OrionPK: You may need to change some code for it. |
| 21:12:20 | dom96 | Unfortunately. |
| 21:12:47 | * | vendethiel quit (Remote host closed the connection) |
| 21:13:27 | * | enurlyx left #nimrod (#nimrod) |
| 21:14:46 | OrionPK | :\ |
| 21:14:48 | OrionPK | but im using nginx |
| 21:15:28 | * | vendethiel joined #nimrod |
| 21:15:47 | dom96 | OrionPK: You could probably use nginx as a proxy |
| 21:19:07 | OrionPK | :\ |
| 21:27:28 | dom96 | OrionPK: whysad? |
| 21:38:02 | * | Eurck joined #nimrod |
| 21:39:03 | * | lorxu quit (Ping timeout: 240 seconds) |
| 21:41:04 | * | Eurck_ joined #nimrod |
| 21:42:58 | * | Eurck quit (Ping timeout: 240 seconds) |
| 21:46:15 | * | Eurck_ quit (Quit: Lingo - http://www.lingoirc.com) |
| 21:47:08 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 21:48:46 | * | Utkan joined #nimrod |
| 21:49:28 | * | Utkan quit (Client Quit) |
| 21:52:11 | * | ics quit (Ping timeout: 264 seconds) |
| 21:54:09 | NimBot | Araq/Nimrod devel cf5c8a2 Dominik Picheta [+0 ±4 -0]: Many async optimisations.... 7 more lines |
| 21:54:17 | * | ics joined #nimrod |
| 22:03:53 | * | Utkan joined #nimrod |
| 22:06:36 | * | Utkan quit (Remote host closed the connection) |
| 22:07:03 | * | Utkan joined #nimrod |
| 22:09:51 | * | Johz quit (Quit: Leaving) |
| 22:18:52 | * | Utkan quit () |
| 22:19:19 | * | Utkan joined #nimrod |
| 22:21:02 | * | Utkan quit (Client Quit) |
| 22:33:54 | * | io2 joined #nimrod |
| 22:37:52 | Araq | dom96: forum action |
| 22:40:46 | * | BitPuffin joined #nimrod |
| 22:51:35 | * | saml_ joined #nimrod |
| 22:55:36 | * | q66_ is now known as q66 |
| 22:59:16 | OrionPK | because I want to use scgi dom96 |
| 22:59:23 | dom96 | OrionPK: why? |
| 22:59:35 | OrionPK | because why shoudlnt i |
| 22:59:49 | OrionPK | i've already got it all configured how I want it |
| 23:00:47 | OrionPK | is this new async http server better than the old one? |
| 23:02:31 | dom96 | of course |
| 23:04:07 | dom96 | Araq: I think you should merge new_spawn, I just hit a bug which doesn't happen with new_spawn |
| 23:06:47 | dom96 | Araq: fuck, nvm |
| 23:09:12 | * | darkf joined #nimrod |
| 23:13:02 | NimBot | Araq/Nimrod devel 634a416 Dominik Picheta [+0 ±1 -0]: Async fixes for Linux. |
| 23:21:03 | dom96 | anyway |
| 23:21:11 | dom96 | OrionPK: It'd be nice if you tested it |
| 23:21:24 | OrionPK | dom96 if i find time to.. |
| 23:21:36 | OrionPK | Demos you removed the dependency for libnimrod? there's still a ton of code referencing it |
| 23:21:57 | dom96 | oh yeah |
| 23:22:05 | dom96 | Demos_: where is this plugin of yours for Visual Studio? |
| 23:23:30 | dom96 | It seems the difference between select and IOCP is practically nothing |
| 23:23:41 | dom96 | difference between select and epoll is noticeable though |
| 23:25:38 | Demos_ | https://github.com/barcharcraz/VisualNimrod |
| 23:25:59 | OrionPK | Error 108 Cannot find the interop type that matches the embedded interop type 'Microsoft.VisualStudio.Shell.Interop.IVsToolboxItemProvider'. Are you missing an assembly reference? |
| 23:28:43 | * | Jehan_ quit (Quit: Leaving) |
| 23:28:43 | Demos_ | during build? |
| 23:28:46 | OrionPK | yeah |
| 23:29:00 | Demos_ | do you have the visual studio extensibility SDK |
| 23:29:16 | OrionPK | yeah... I was using the plugin before. did you add another dependency? |
| 23:29:33 | Demos_ | no |
| 23:29:37 | Demos_ | what file is it in? |
| 23:29:44 | OrionPK | NimrodProject |
| 23:29:57 | OrionPK | NimrodProjectFactory |
| 23:30:01 | Demos_ | oh, that is not nessassary yet |
| 23:30:24 | OrionPK | dont i need it to make a nimrod project? |
| 23:31:26 | Demos_ | no. the NimrodProject project is the beginning of working toward a having projects that do not depend on MPFProj or any project file, they would just mirror the filesystem and edit a project.nimrod.cfg file |
| 23:31:39 | OrionPK | ah |
| 23:32:10 | OrionPK | I have syntax highlighting! |
| 23:32:20 | Demos_ | indeed! |
| 23:32:26 | Demos_ | build and run probably won't work |
| 23:32:32 | Demos_ | but they might, you never really know |
| 23:32:33 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 23:32:35 | OrionPK | no, it works |
| 23:32:38 | Demos_ | w00t |
| 23:32:38 | OrionPK | ctrl + f5 launched |
| 23:33:01 | Demos_ | I did not edit the template yet. Just got my project working by editing the XML |
| 23:33:06 | Demos_ | have to get that into vsgen as well |
| 23:33:17 | OrionPK | tabulators not allowed heh |
| 23:33:22 | OrionPK | howd a tab get in there? |
| 23:33:26 | Demos_ | yeah, change the VS editor settings |
| 23:33:32 | OrionPK | I always uses spaces |
| 23:33:43 | Demos_ | I think there are seperate settings for nimrod |
| 23:33:50 | OrionPK | ah, odd... |
| 23:33:50 | Demos_ | I need to figure how to limit them |
| 23:33:55 | Demos_ | if that can even be done |
| 23:34:00 | OrionPK | oh, im sure it can ben |
| 23:34:01 | OrionPK | be* |
| 23:34:16 | Demos_ | but this is a good start already |
| 23:34:26 | OrionPK | yeah |
| 23:34:30 | OrionPK | so far so good man |
| 23:34:52 | Demos_ | completion should work to |
| 23:35:21 | OrionPK | yeah, need to start highlighting proc calls if possible |
| 23:35:50 | Demos_ | it should already do so. although it condiers a proc call anything that ends in a () or * (for definitions you understand) |
| 23:36:01 | Demos_ | but the default color for identifiers is just black |
| 23:36:02 | OrionPK | ah |
| 23:36:04 | OrionPK | doesnt do "echo" |
| 23:36:06 | Demos_ | so they do not show up |
| 23:36:12 | Demos_ | yeah |
| 23:36:23 | Demos_ | I am not sure how perf intensive that would be |
| 23:36:37 | Demos_ | since idetools --serve does not work I need to launch up a whole new process for each query |
| 23:36:47 | OrionPK | yeah |
| 23:36:58 | OrionPK | I know that deal. I worked on the ST plugin |
| 23:37:01 | Demos_ | the compiler is so motherfucking fast that it may not matter |
| 23:37:04 | OrionPK | wish someone would get that working |
| 23:37:12 | OrionPK | I think i just did a special case for echo |
| 23:37:13 | Demos_ | soes the ST plugin use idetools? |
| 23:37:16 | OrionPK | just because it's common |
| 23:37:19 | OrionPK | yeah it uses idetools |
| 23:37:22 | dom96 | it is? Not in my experience. |
| 23:37:34 | dom96 | well, not fast enough for idetools |
| 23:37:34 | Demos_ | yeah, nimrod.vim special cases stuff like add, del, and echo |
| 23:37:42 | OrionPK | Demos_ ahh nice, just hit F12 :) |
| 23:37:47 | OrionPK | on readline |
| 23:37:54 | OrionPK | that works in ST2 as well |
| 23:38:01 | Demos_ | dom96, I use it for ctrl-space suggestions and go to definition |
| 23:38:41 | Demos_ | although come to think of it just builing a list of everything with a * after it would work OK |
| 23:39:54 | OrionPK | yeah this is workin nicely |
| 23:40:12 | OrionPK | it'd be cool if I could just open a folder |
| 23:41:00 | OrionPK | Demos_ you dont have the block keyword |
| 23:41:16 | OrionPK | or static |
| 23:41:22 | dom96 | odd, it doesn't work in Aporia |
| 23:41:31 | * | dom96 assumed it was broken in the compiler |
| 23:41:33 | Demos_ | damn |
| 23:41:46 | OrionPK | what doesnt work in aporia? |
| 23:42:10 | OrionPK | Demos_ also an highlighting characters |
| 23:42:16 | dom96 | Go to definition |
| 23:42:22 | Demos_ | yeah the char thing I need to work on |
| 23:42:28 | Demos_ | but I just added block and static |
| 23:42:38 | OrionPK | take a look at Varriount/NimLime |
| 23:42:39 | dom96 | so how do I install this plugin? |
| 23:42:56 | Demos_ | geesus it is in heavy beta |
| 23:43:37 | OrionPK | Demos_ if you clean up some of the old stuff and help me get F5 to test the plugin I might try helping contribute to the plugin ;P |
| 23:44:06 | dom96 | I may give up on Aporia and contribute too :P |
| 23:44:11 | Demos_ | f5 to test? |
| 23:44:12 | OrionPK | im a lot better at C# than nimrod |
| 23:44:30 | OrionPK | I mean able to build and run the plugin to launch a new instance of visual studio and test the plugin |
| 23:44:44 | OrionPK | instead of having to browse to the vsix and uninstall/reinstall it |
| 23:44:46 | OrionPK | it's a pain |
| 23:45:02 | Demos_ | https://onedrive.live.com/redir?resid=BE38BDD0FF029113!17198&authkey=!AJSbdatljKDgwdc&ithint=file%2c.vsix |
| 23:45:05 | Demos_ | for dom96 |
| 23:45:31 | OrionPK | how do you get the breakpoint stuff going? |
| 23:45:40 | Demos_ | just building it adds the plugin to the experimental instance of VS |
| 23:46:08 | OrionPK | oh really |
| 23:46:22 | OrionPK | whats the experimental instance of VS |
| 23:46:51 | dom96 | yeah, that sounds dangerous lol |
| 23:47:35 | OrionPK | thats what I cant get to launch, I think.. this 'experimental instance' |
| 23:47:36 | Demos_ | it is just a seperate envirenment for VS so that you dont break your tools with your tools |
| 23:48:42 | Demos_ | well I think I just got start to launch it for you |
| 23:48:42 | OrionPK | yeah but how do you launch it |
| 23:50:05 | OrionPK | start just gives me that error about starting a library |
| 23:50:12 | Demos_ | well the VS SDK adds a start menu shortcut to the exp instance |
| 23:50:18 | OrionPK | ahhh |
| 23:50:23 | OrionPK | boom |
| 23:50:25 | OrionPK | that's the ticket |
| 23:50:30 | Demos_ | I got start to work but it wont synch to git because the changes are in the .user file I think |
| 23:50:38 | OrionPK | ahh |
| 23:50:38 | OrionPK | lame |
| 23:50:50 | Demos_ | the VS extensibility API is a total clusterfuck |
| 23:50:56 | dom96 | I guess I need to install VS SDK |
| 23:51:28 | OrionPK | are you going to remove the dependencies on libnimrod |
| 23:51:45 | Demos_ | I mean you dont actually need it right now |
| 23:52:06 | Demos_ | I have just not removed the deps from the project yet. I guess I should do that |
| 23:52:17 | OrionPK | "block:" isn't highlighted |
| 23:52:28 | OrionPK | block name: |
| 23:52:29 | OrionPK | is |
| 23:52:36 | Demos_ | yeah, bug in the tokenizer |
| 23:52:41 | OrionPK | gotcha |
| 23:53:09 | OrionPK | I think there's a list of actual keywords kept in the compiler source |
| 23:53:27 | Demos_ | I got my list from the manual list of reserved words |
| 23:53:40 | OrionPK | https://github.com/Araq/Nimrod/blob/05e89ffceb4a0cb85b59eb1ca34d27b0d5cb63dd/lib/packages/docutils/highlite.nim |
| 23:53:51 | OrionPK | nimrodKeywords = [..] |
| 23:54:19 | Demos_ | yeah, that is not actually the problem atm though |
| 23:54:22 | Demos_ | not with block: |
| 23:54:25 | OrionPK | no, I know |
| 23:54:29 | Demos_ | it is just that I parse block: as one token |
| 23:54:33 | Demos_ | and block: is not a keyword |
| 23:54:35 | Demos_ | block: is |
| 23:54:41 | Demos_ | erm block is |
| 23:54:45 | OrionPK | i got that that wasnt the issue |
| 23:55:08 | * | Trustable quit (Quit: Leaving) |
| 23:55:21 | dom96 | where the hell do I download this SDK? |
| 23:55:35 | dom96 | nvm |
| 23:55:38 | OrionPK | http://msdn.microsoft.com/en-us/vstudio/vextend.aspx |
| 23:55:40 | dom96 | my google-fu failed me momentarily |
| 23:56:00 | Demos_ | as usual you need VS pro or above |
| 23:56:05 | Demos_ | and the project is for VS 2013 |
| 23:56:36 | dom96 | yeah, got that. |
| 23:56:41 | dom96 | Thanks to Dreamspark :D |
| 23:57:02 | OrionPK | will the plugin work in express? |
| 23:57:54 | dom96 | yeah, why does it only work in professional? |
| 23:58:12 | OrionPK | MAKING the plugin only works in professional |
| 23:58:16 | OrionPK | and up |
| 23:58:26 | OrionPK | im wondering about using it |
| 23:58:46 | dom96 | i see |
| 23:58:59 | Demos_ | no. Plugins only work in professional and above |
| 23:59:40 | OrionPK | ahh, that's a shame. |