| 00:09:24 | NimBot | Araq/Nimrod 74059cc Grzegorz Adam Hankiewicz [+0 ±1 -0]: Hyperlinks each proc and explains it is like map. |
| 00:09:24 | NimBot | Araq/Nimrod b1e5203 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds each's map alias to index. |
| 00:09:24 | NimBot | Araq/Nimrod 6b011e5 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds documentation examples to sequtils. |
| 00:09:24 | NimBot | Araq/Nimrod bcd7eae Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds note about distnct being misspelled on purpose. |
| 00:09:24 | NimBot | Araq/Nimrod 0558023 Araq [+0 ±2 -0]: Merge pull request #300 from gradha/pr_improves_sequtils_docs... 3 more lines |
| 00:10:24 | NimBot | Araq/Nimrod 0611440 Araq [+0 ±2 -0]: 'importcpp' for the JS target to generate an infix call |
| 00:10:24 | NimBot | Araq/Nimrod 8f6b1dd Araq [+0 ±2 -0]: Merge branch 'master' of github.com:Araq/Nimrod |
| 00:10:41 | Araq | reactormonk: here you go, 'importcpp' for JS ;-) |
| 00:10:44 | Araq | good night |
| 00:13:18 | * | q66 quit (Quit: Quit) |
| 00:13:18 | reactormonk | Araq, cool shit |
| 01:47:54 | AlexLibman | re "<eactormonk> AlexLibman, what about adding a [software license] clause that military usage is forbidden to BSD/GPL?" - an incredibly stupid idea. What about it? |
| 01:49:30 | AlexLibman | (1) If someone is willing to initiate military aggression, don't you think they would be willing to violate a software license?! |
| 01:51:01 | AlexLibman | (2) What about defensive military actions? Are you going to crawl in under fire to decide which side is at fault or not, so you could ask them to please not use your software? |
| 01:52:13 | AlexLibman | The Non-Aggression Principle is Natural Law, you don't need to add a readme file to your software package to make it enforcable. |
| 01:55:35 | * | fowl quit (Quit: Leaving) |
| 01:56:26 | * | fowl joined #nimrod |
| 01:58:09 | AlexLibman | A good reason not to use GPL is that by v4 or v99 they might start adding clauses like that. They probably also won't like gun owners. Or religious nuts. Or non-vegans... |
| 02:08:11 | fowl | AlexLibman: do you code or just think about licenses all day |
| 02:08:27 | reactormonk | fowl, ;> |
| 02:09:22 | AlexLibman | fowl: I used to code. Now talking about licenses all day is more important. |
| 04:01:37 | * | XAMPP joined #nimrod |
| 05:23:44 | * | XAMPP quit (Ping timeout: 252 seconds) |
| 06:13:58 | * | Trix[a]r_za is now known as Trixar_za |
| 06:14:50 | Trixar_za | Oh God |
| 06:15:14 | Trixar_za | Why must every programmer I know talk about Licenses 90% of the time? :/ |
| 07:11:48 | * | Trixar_za is now known as Trix[a]r_za |
| 07:27:10 | reactormonk | Trix[a]r_za, I don't fucking care ;-) |
| 07:31:41 | reactormonk | Can I just write workspace.func and importc it? Shouldn't matter too much for global functions |
| 08:26:57 | * | Araq_ joined #nimrod |
| 08:28:31 | * | Araq_ quit (Client Quit) |
| 11:19:27 | AlexLibman | Trix[a]r_za: once everything is copyfree, no one will talk about licenses anymore. |
| 11:47:37 | * | zahary quit () |
| 11:48:32 | * | zahary joined #nimrod |
| 14:14:21 | * | q66 joined #nimrod |
| 15:26:22 | * | zahary quit (Remote host closed the connection) |
| 15:30:28 | * | zahary joined #nimrod |
| 16:08:20 | * | zahary quit (Quit: ZNC - http://znc.in) |
| 17:35:49 | apotheon | Are there syntax and indentation files for Vim out there somewhere for use with Nimrod? |
| 17:36:32 | dom96 | https://github.com/Araq/Nimrod/wiki/Editor-Support |
| 17:36:34 | dom96 | yep |
| 17:38:18 | apotheon | thanks |
| 17:39:00 | apotheon | This might usefully be mentioned early in the tutorials. |
| 17:39:22 | dom96 | I agree |
| 18:12:39 | NimBot | nimrod-code/Aporia f30b3bb Dominik Picheta [+0 ±3 -0]: Fixed a segfault when selecting some languages as syntax highlighting. |
| 19:02:10 | apotheon | By the way . . . I don't get what the tutorial is saying about prefix operator use at all. Can the standard integer operators (mod, for instance) be used as prefix operators or not? How, if so? |
| 19:03:42 | apotheon | I think maybe the tutorial is trying to say that prefix operators can be *defined*, not that existing operators have optional prefix syntax or something like that, but it's hard to tell from the phrasing. |
| 19:04:41 | dom96 | You can do this: `mod`(x,y) |
| 19:04:42 | apotheon | On one hand, this seems to suggest that standard operators normally used infix can be used prefix: "The parser lets you use operators in infix notation (a + b) or prefix notation (+ a)." |
| 19:04:46 | apotheon | Oh. |
| 19:04:49 | apotheon | Okay, thanks. |
| 19:04:55 | apotheon | Wow, that's not obvious at all. |
| 19:05:04 | dom96 | what section of the tutorial is this? |
| 19:05:39 | apotheon | Operators, Tutorial I |
| 19:06:15 | apotheon | I can see now where there's an example of that in the Operators section, but there's no clear explanation of what's going on. |
| 19:06:48 | dom96 | I see what you mean. There should be a comparison between infix and prefix notation (using Nimrod syntax) |
| 19:08:08 | Araq | apotheon: it's really quite simple so if you misunderstand it, the tutorial should be improved ;-) |
| 19:08:22 | Araq | a + b # infix syntax |
| 19:08:38 | Araq | `+`(a, b) # ordinary function call syntax |
| 19:08:54 | Araq | +a # prefix syntax for unary operators |
| 19:09:06 | Araq | `+`(a) # ordinary function call syntax |
| 19:09:29 | Araq | however the parser does not know about unary and binary operators ;-) |
| 19:09:35 | apotheon | Araq: Believe it or not, just including those four lines *verbatim* would be a *huge* improvement. |
| 19:09:55 | Araq | so you can also do this: |
| 19:10:18 | Araq | proc `+` (a: string, b: string = "xyz"): string = a & b |
| 19:10:46 | Araq | +"abc" # new operator used as prefix operator |
| 19:10:57 | reactormonk | Araq, pull request ftw! |
| 19:11:01 | Araq | "abc" + "def" # new operator used as infix operator |
| 19:11:01 | reactormonk | err @ apotheon |
| 19:11:19 | reactormonk | Araq, Can I just write workspace.func and importc it? Shouldn't matter too much for global functions |
| 19:11:35 | reactormonk | And how do I import enums in JS? |
| 19:11:46 | Araq | reactormonk: proc workspaceFunc() {.importc: "workspace.func".} |
| 19:11:54 | Araq | do it this way |
| 19:12:04 | reactormonk | Araq, or rather proc func() {.importc: "workspace.func".} :> |
| 19:12:14 | Araq | sure |
| 19:12:55 | reactormonk | About enums? |
| 19:13:07 | Araq | so the newly defined `+` can act both as unary and binary operator, apotheon |
| 19:13:22 | apotheon | I prefer the prefix form, except for the backticks -- but I won't question the use of backticks given I don't know enough about the language or its implementation. |
| 19:13:34 | Araq | that's what I mean by "the parser does not know" |
| 19:13:36 | apotheon | Araq: cool beans |
| 19:14:02 | apotheon | Thanks. |
| 19:20:25 | Araq | reactormonk: dunno what you mean, there are no enums in JS |
| 19:20:37 | Araq | so Nimrod maps them to integer literals |
| 19:20:39 | reactormonk | http://techbase.kde.org/Development/Tutorials/KWin/Scripting/API_4.9#Enums |
| 19:20:50 | reactormonk | There are enums here... |
| 19:22:11 | Araq | wild guess: do it this way: |
| 19:22:24 | Araq | type TClientAreaOption = distinct int |
| 19:22:36 | Araq | var |
| 19:22:38 | Araq | PlacementArea {.importc.}: TClientAreaOption |
| 19:22:56 | Araq | MovementArea {.importc.}: .... |
| 19:23:59 | Araq | reactormonk: this way the codegen produces a verbatim 'PlacementArea' in the JS output |
| 19:24:56 | Araq | which could be just what you need |
| 19:25:53 | Araq | brb |
| 19:30:07 | * | AlexLibman is now known as libMAN |
| 19:53:08 | dom96 | Araq: ping |
| 19:53:12 | reactormonk | Araq, var PlacementArea {.importc: "KWin.PlacementArea".}: TClientAreaOption will work as well? |
| 19:55:46 | Araq | reactormonk: sure |
| 19:55:48 | Araq | dom96: pong |
| 19:57:45 | dom96 | Araq: Is there a way to guarantee that an object will not be freed from memory? |
| 19:58:07 | Araq | GC_ref(x) and when you're done GC_unref(x) |
| 19:58:25 | Araq | you can also keep it in a global obviously |
| 20:00:45 | dom96 | oh, thanks. |
| 20:16:49 | reactormonk | Araq, vars are exported when postfixed by stars? |
| 20:17:38 | dom96 | reactormonk: yes |
| 20:39:15 | * | libMAN^irssi joined #nimrod |
| 20:46:11 | * | libMAN left #nimrod (#nimrod) |
| 20:46:21 | * | libMAN^irssi is now known as libMAN |
| 21:40:39 | Araq | reactormonk: I hope you test parts of the wrapper before wrapping the whole thing ... |
| 21:41:11 | Araq | to ensure we don't misread the docs ... |
| 21:42:49 | reactormonk | Araq, sure :-) |
| 21:43:05 | reactormonk | Araq, well, I'm autogenerating most of it, so |
| 21:43:22 | Araq | yeah I know but still ... ;-) |
| 21:47:56 | reactormonk | looks like in the end, I got to write some stuff manually :-/ |
| 21:49:02 | Araq | why? |
| 21:49:32 | Araq | you can try to use c2nim to generate the wrapper :P |
| 21:54:26 | reactormonk | not gonna work |
| 21:54:36 | reactormonk | There's a shitload more out there |
| 21:56:03 | Araq | well the docs use a C-like syntax ... |
| 21:58:50 | reactormonk | yep, but the header-file is full of other stuff |
| 21:59:24 | Araq | you need to tweak it for c2nim, as always |
| 21:59:45 | Araq | but it's still much less work than doing it by hand or with Ruby scripts |
| 22:00:34 | reactormonk | the XML helps a lot |
| 22:00:53 | apotheon | Ruby scripts . . . ? |
| 22:00:54 | reactormonk | And I have to do all the hacky shit with enums |
| 22:01:14 | reactormonk | apotheon, I use some ruby to convert the XML from doxygen to nimrod |
| 22:01:17 | apotheon | ah |
| 22:01:56 | reactormonk | Araq, I'm not even sure it's an int - let's check |
| 22:16:08 | reactormonk | "TypeError: Requested keys of a value that is not an object." |
| 22:16:10 | reactormonk | whut. |
| 22:17:37 | reactormonk | oh, duh. |
| 23:14:47 | reactormonk | Now a template to convert signal activityAdded*(workspace: TWorkspace, callback: proc(id: string)) to proc activityAdded*(workspace: TWorkspace, callback: proc(id: string)) which generates <workspace>.<signal name>.connect(<proc>) in JS |
| 23:15:48 | Araq | I think you may need a macro for that |
| 23:16:07 | Araq | as there is no way to turn an identifier into a string literal in a template |
| 23:16:15 | fowl | what is `signal` |
| 23:16:24 | fowl | is that new |
| 23:18:14 | reactormonk | fowl, it's a signal in qt |
| 23:19:05 | reactormonk | Araq, or maybe define the signal as proc activitiyAdded*(workspace: TWorkspace, callback: proc(id: string)) {.importcpp: "activityAdded.connect"} ? |
| 23:19:39 | Araq | sounds good, yeah |
| 23:22:51 | reactormonk | http://sprunge.us/IPHJ that's just one of the five files |
| 23:23:40 | Araq | get rid of the ': void' please |
| 23:25:44 | reactormonk | http://sprunge.us/cagE |
| 23:25:51 | reactormonk | ... nope |
| 23:26:31 | reactormonk | http://sprunge.us/HeWD now. |
| 23:26:57 | Araq | looks good to me |
| 23:27:26 | reactormonk | Next file... |
| 23:30:57 | Araq | dom96: nimbuild shows "C sources" to be orange |
| 23:32:19 | dom96 | hrm, that's weird |
| 23:34:18 | * | XAMPP joined #nimrod |
| 23:34:18 | * | XAMPP quit (Changing host) |
| 23:34:18 | * | XAMPP joined #nimrod |
| 23:34:58 | dom96 | Looks like a bug with queues |
| 23:37:19 | Araq | -.- |
| 23:37:47 | dom96 | The sources were built successfully however |
| 23:37:54 | Araq | yeah |