00:02:08 | Trustable | goodnight all |
00:02:11 | * | Trustable quit (Quit: Leaving) |
00:09:37 | * | EXetoC quit (Quit: WeeChat 1.0) |
00:09:56 | * | bjz_ quit (Read error: Connection reset by peer) |
00:10:11 | * | bjz joined #nimrod |
00:14:16 | onionhammer | dom96 ok i got my blog updated (not deployed yet tho) |
00:14:35 | onionhammer | dom96 I'll wait for a real release of jester w/ the async stuff before i update it |
00:42:42 | * | bjz quit (Ping timeout: 245 seconds) |
01:02:20 | * | brson quit (Quit: leaving) |
01:04:42 | * | bogen joined #nimrod |
01:13:35 | * | q66 quit (Quit: Leaving) |
01:19:07 | * | jpoirier quit (Quit: Leaving) |
01:24:01 | onionhammer | teest ;) |
01:27:33 | * | darkf quit (Ping timeout: 240 seconds) |
01:29:19 | * | darkf joined #nimrod |
01:35:23 | * | fowl quit (Ping timeout: 255 seconds) |
01:37:10 | * | fowl joined #nimrod |
01:37:10 | * | fowl quit (Changing host) |
01:37:10 | * | fowl joined #nimrod |
01:52:18 | * | darkf_ joined #nimrod |
01:55:09 | * | darkf quit (Ping timeout: 268 seconds) |
01:55:14 | * | darkf__ joined #nimrod |
01:57:00 | * | BlameStross joined #nimrod |
01:57:03 | * | BlameStross left #nimrod (#nimrod) |
01:57:33 | * | darkf_ quit (Ping timeout: 240 seconds) |
01:58:44 | * | darkf__ is now known as darkf |
02:02:53 | * | Jesin joined #nimrod |
02:26:42 | * | fowl quit (Ping timeout: 255 seconds) |
02:47:50 | * | fowl joined #nimrod |
02:47:50 | * | fowl quit (Changing host) |
02:47:50 | * | fowl joined #nimrod |
04:02:25 | * | kshlm joined #nimrod |
04:06:35 | * | nande quit (Remote host closed the connection) |
04:25:23 | * | Demos quit (Read error: Connection reset by peer) |
04:44:45 | * | fowl quit (Ping timeout: 240 seconds) |
05:05:05 | * | Jesin quit (Excess Flood) |
05:05:57 | * | Jesin joined #nimrod |
05:06:52 | * | gkoller joined #nimrod |
05:45:24 | * | BlaXpirit joined #nimrod |
06:29:04 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
06:42:36 | * | Jesin quit (Ping timeout: 252 seconds) |
06:45:00 | * | Jesin joined #nimrod |
07:14:55 | * | kunev joined #nimrod |
07:15:12 | Araq | bogen: found the bug :-) fix might take a day though |
07:16:36 | * | io2 joined #nimrod |
07:22:45 | * | Jesin quit (Ping timeout: 240 seconds) |
07:31:44 | * | Jesin joined #nimrod |
07:37:07 | * | Jesin quit (Max SendQ exceeded) |
07:40:40 | * | Jesin joined #nimrod |
07:45:31 | * | kunev quit (Quit: Lost terminal) |
07:52:14 | dom96 | onionhammer: cool |
07:53:52 | * | kunev joined #nimrod |
07:58:17 | bogen | Araq: cool! I'm currently doing my complex macros with staticExec though, and using importc in the now compiled "compile time procedures", so this bug is not a showstopper for me |
07:59:33 | Araq | ok ... well I fixed it but the bug still exists for more complex pieces |
07:59:53 | Araq | the way opcAddrNode works is fundamentally flawed, I think |
08:02:12 | Araq | bbl |
08:03:12 | bogen | ok, so this is unrelated to lamba lifting |
08:04:36 | bogen | well, I have preexisting c/c++ libaries I'm using that I've not rewritten in nim (which is why I'm using importc procs) |
08:36:47 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
08:45:04 | * | Jesin quit (Ping timeout: 252 seconds) |
08:46:37 | * | Jesin joined #nimrod |
08:48:41 | * | Jesin quit (Max SendQ exceeded) |
09:38:49 | * | kshlm quit (Quit: Konversation terminated!) |
09:39:09 | * | kshlm joined #nimrod |
10:38:32 | * | bjz joined #nimrod |
10:51:14 | * | EXetoC joined #nimrod |
11:02:24 | * | endou__ quit (Ping timeout: 272 seconds) |
11:03:40 | * | darkfusi1n quit (Ping timeout: 272 seconds) |
11:04:21 | * | endou__ joined #nimrod |
11:05:00 | * | darkfusion joined #nimrod |
11:44:21 | * | kshlm quit (Ping timeout: 246 seconds) |
11:44:51 | * | kshlm joined #nimrod |
12:11:54 | * | xenagi joined #nimrod |
12:33:44 | * | xenagi quit (Read error: Connection reset by peer) |
12:34:28 | * | Trustable joined #nimrod |
13:06:33 | * | kshlm quit (Ping timeout: 264 seconds) |
13:16:29 | * | Sht0 joined #nimrod |
13:29:23 | * | darkf quit (Quit: Leaving) |
14:12:06 | * | kshlm joined #nimrod |
14:36:37 | * | bogen quit (Quit: Leaving.) |
14:45:11 | * | Shoozza joined #nimrod |
14:47:17 | NimBot | nimrod-code/packages master 79da9ca achesak [+0 ±1 -0]: Added robotparser. |
14:47:17 | NimBot | nimrod-code/packages master a1e051c Dominik Picheta [+0 ±1 -0]: Merge pull request #87 from achesak/master... 2 more lines |
15:13:24 | * | Jesin joined #nimrod |
15:37:07 | * | Matthias247 joined #nimrod |
15:50:17 | * | kshlm quit (Ping timeout: 245 seconds) |
16:03:09 | * | endou___ joined #nimrod |
16:04:23 | * | clone1018_ joined #nimrod |
16:05:24 | * | BlaXpirit-UA joined #nimrod |
16:06:33 | * | wan1 joined #nimrod |
16:06:47 | * | TylerE_ joined #nimrod |
16:07:56 | * | Jesin quit (Ping timeout: 255 seconds) |
16:08:30 | * | endou__ quit (Ping timeout: 260 seconds) |
16:08:33 | * | Araq quit (Ping timeout: 260 seconds) |
16:08:35 | * | clone1018 quit (Ping timeout: 260 seconds) |
16:08:36 | * | CARAM quit (Ping timeout: 260 seconds) |
16:08:40 | * | BlaXpirit quit (Ping timeout: 260 seconds) |
16:08:40 | * | wan quit (Ping timeout: 260 seconds) |
16:08:41 | * | oddmunds quit (Ping timeout: 260 seconds) |
16:08:41 | * | JStoker quit (Ping timeout: 260 seconds) |
16:08:43 | * | Roin quit (Ping timeout: 260 seconds) |
16:08:47 | * | lyro quit (Ping timeout: 260 seconds) |
16:08:47 | * | TylerE quit (Ping timeout: 260 seconds) |
16:08:48 | * | endou___ is now known as endou__ |
16:08:50 | * | Araq_bnc joined #nimrod |
16:09:05 | * | JStoker joined #nimrod |
16:09:37 | * | lyro joined #nimrod |
16:09:56 | * | Roin joined #nimrod |
16:09:59 | * | CARAM joined #nimrod |
16:10:00 | * | oddmunds joined #nimrod |
16:10:21 | * | clone1018_ is now known as clone1018 |
16:12:03 | * | shodan45 quit (Remote host closed the connection) |
16:12:24 | * | shodan45 joined #nimrod |
16:14:14 | * | shodan45 quit (Client Quit) |
16:15:03 | * | io2 joined #nimrod |
16:15:22 | * | TylerE_ is now known as TylerE |
16:36:12 | * | brson joined #nimrod |
16:42:29 | * | kunev quit (Quit: leaving) |
16:59:33 | * | Triplefox quit (Ping timeout: 240 seconds) |
16:59:47 | Trustable | Does anyone know the compiler error "Error: internal error: GetUniqueType"? |
17:01:26 | dom96 | Trustable: https://github.com/Araq/Nimrod/search?q=internal+error%3A+GetUniqueType&type=Issues&utf8=%E2%9C%93 |
17:03:28 | Trustable | dom96, do you know how to call proc set_string*(value: PGValue, v_string: cstring) from glib2 without getting this errr? |
17:03:34 | * | Triplefox joined #nimrod |
17:04:17 | dom96 | Trustable: how are you trying to call it? |
17:05:39 | Trustable | I tried everything I can think of: e.g.: var v = TGValue; v.setString("a"); glib2.setString(addr(v), cstring("a")) |
17:09:12 | * | nande joined #nimrod |
17:09:28 | Trustable | dom96: I found my mistake. |
17:09:57 | dom96 | yes, s/=/:/ |
17:10:23 | Trustable | yes |
17:14:14 | * | bjz quit (Read error: Connection reset by peer) |
17:14:29 | * | bjz joined #nimrod |
17:14:56 | * | q66 joined #nimrod |
17:17:19 | * | Matthias247 quit (Read error: Connection reset by peer) |
17:21:35 | * | gkoller joined #nimrod |
17:36:36 | * | Araq_bnc is now known as Araq |
17:48:21 | * | Trustable quit (Quit: Leaving) |
17:59:41 | Varriount | Meep |
18:13:26 | NimBot | Araq/Nimrod bigbreak 201a08e Araq [+1 ±9 -0]: fixes #903, fixes #1513 |
18:13:26 | NimBot | Araq/Nimrod bigbreak e093f45 Araq [+0 ±1 -0]: fixes #1511 |
18:13:26 | NimBot | Araq/Nimrod bigbreak c7116cc Araq [+0 ±2 -0]: Merge branch 'bigbreak' of https://github.com/Araq/Nimrod into bigbreak... 3 more lines |
18:24:57 | * | shodan45 joined #nimrod |
18:25:56 | reactormonk | nimfix is for introducing cs:partial? |
18:27:54 | Araq | yes |
18:42:59 | * | filwit joined #nimrod |
18:43:24 | * | Jesin joined #nimrod |
18:48:10 | filwit | hey guys, I'm trying to figure out how to make a generic "overload" based on a unique string name. Is that possible? |
18:48:21 | filwit | here's some code i'm working with: https://gist.github.com/PhilipWitte/0e9d9a990f295a9415c4 |
18:50:18 | filwit | I'm trying to wrap up the 'updateXXX' stuff into a generic system of some sort, so I can just say "items[Foo, update]().blah.." & "event[update].add(invoke[Foo, update])" type of thing |
18:50:58 | filwit | btw Araq, love the {.global.} pragma design, really nice. |
18:52:22 | * | Jehan_ joined #nimrod |
18:53:15 | filwit | hi Jehan_, maybe you would know about my question (it's about generics). Got a moment? |
18:53:27 | Jehan_ | What question? |
18:53:34 | filwit | let me quote... |
18:53:42 | filwit | hey guys, I'm trying to figure out how to make a generic "overload" based on a unique string name. Is that possible? |
18:53:46 | filwit | here's some code i'm working with: https://gist.github.com/PhilipWitte/0e9d9a990f295a9415c4 |
18:53:53 | filwit | I'm trying to wrap up the 'updateXXX' stuff into a generic system of some sort, so I can just say "items[Foo, update]().blah.." & "event[update].add(invoke[Foo, update])" type of thing |
18:54:49 | Jehan_ | Yes? |
18:55:58 | filwit | any idea on how to make a generic which 'overloads' based on a specific name? Should i just make a type with the name for each event? eg, `type update = {.distinct.} object` ? |
18:56:22 | filwit | I can do that, I'm just wondering if there's a better way |
18:56:33 | Jehan_ | What do you mean by "overloads based on aq specific name". |
18:56:37 | Jehan_ | ? |
18:57:54 | Araq | you can overload by types or by AST constraints, there is no 'verbatim' AST constraint, so I think you can't do it, filwit |
18:58:13 | filwit | well i'm trying to make the event invokation code work for multiple events, not just "update"... i could rewrite the update stuff for each event I want (mouse click, key press, render, collide, etc) but I would like to create a generic system which does that for me... based on some event name. |
18:58:46 | Araq | sounds to me like you want an enum? |
18:58:58 | Jehan_ | If it's the same code for everything, why not index by a constant? |
18:59:13 | Jehan_ | I.e. what Araq said. |
18:59:39 | filwit | Jehan_, it's not entirely the same behavior.. for instance the mouse event will need position parameters, etc |
19:00:11 | EXetoC | variant? |
19:00:12 | Jehan_ | Then I'm really not sure that generics could help you either, since you'd need a specific implementation for each? |
19:00:38 | Jehan_ | Or am I misunderstanding something? |
19:01:20 | filwit | Jehan_: well the idea was to pass the parameter list in through a generic varargs type of system (i know you can do that in D, though i've never really tried in Nim). |
19:02:05 | filwit | so like "items[Foo, mouseClick, int, int])" |
19:02:06 | Jehan_ | filwit: My problem is that I still have no clue what you're trying to do. :( |
19:02:54 | Jehan_ | What would "Foo" be in this example? |
19:02:59 | filwit | Jehan_: i'm trying to make a event system, for a game/ui engine. |
19:03:10 | Jehan_ | filwit: I've got that much. |
19:03:28 | filwit | Jehan_: Foo would be anything subscibing to an event.. so like a button subscribing to a mouse event. |
19:03:35 | Jehan_ | But your description is still too vague for me to understand what you are trying to achieve. |
19:04:11 | EXetoC | "generic varargs" haven't been implemented |
19:04:13 | Jehan_ | Okay. I think I may be beginning to understand. |
19:04:18 | EXetoC | maybe there's some hacky workaround |
19:04:33 | filwit | EXetoC: it could be done with macros then |
19:05:14 | filwit | EXetoC, Jehan_, Araq: I guess macros is the option, since what EXetoC said basically forces my hand there, I'll just use those |
19:05:25 | filwit | thanks for the help |
19:05:42 | Jehan_ | Well, you could always pack parameters in a tuple. |
19:05:58 | filwit | true... |
19:07:01 | filwit | hmm... so i guess i could just define the events by objects, eg `type mouseClick = {.distinct.}object`, and then do overloads based on that & a tuple for parameters |
19:07:38 | filwit | the reason i need an "overload" is because the {.global.} works for each unique call of the generic proc |
19:09:27 | filwit | basically the system builds out a list of update items that need to be updates (which will eventually become more complicated than my example, but the idea's the same), then the only think i need to have dynamic-dispatch on is calling events which run through those lists and inoke a specific function (through static dispatch) all the items in it's list. |
19:11:07 | filwit | i need unique global lists for each event tho, which I was originally planning on making my class macro export, but thought that I could just use the {.global.} pragma instead |
19:11:21 | Araq | you can use a list of closures and hide the parameter list differences via currying |
19:11:58 | filwit | let me google what 'currying' is... |
19:12:19 | Araq | you can get varargs[expr] perfect forwarding via macros but this usually doesn't help much |
19:12:53 | Araq | because as you said, you end up wanting to add this to some list |
19:13:55 | filwit | Araq: well basically I think parameter handling can be done with generics and a tuple (and 'void' in case of empty params) |
19:14:47 | filwit | Araq: my main concern was getting the 'updateItems' to invoke multiple times (and therefor create more {.global.} lists) based on the event name. |
19:15:00 | filwit | not just the type (foo or bar) |
19:15:31 | Araq | for me event == closure |
19:15:42 | Araq | everything else is just too complex / weird |
19:17:06 | filwit | okay, well i was using 'event' in a general sense... like mouseClicked is an event, so is keyPress, update, render, collide, etc... those are all "events" (unique triggers which an applications invokes at specific points) |
19:18:54 | filwit | i need a generic which not only generates a {.global.} list of items based on the types (Foo, Bar, etc..), but also the specific event (update, collide, etc..) because each object will have multiple events it can subscribe too, so there needs to be multiple lists with their own lists of items for each "event" |
19:19:32 | filwit | errr.. i'm writing very confusingly right now... sorry |
19:20:44 | filwit | anyways, everyone basically answered my question... i can only overload based on a Type, so i'll have to define each event as such.. and I can probably do parameters as a tuple... either that, or i can always fallback to macros if i need to. |
19:24:51 | filwit | err... maybe not actually.. since i'll need to "inject" the "event name" into the code, which may require macros one way or the other... oh well. |
19:24:52 | EXetoC | ECS? observer? |
19:25:37 | filwit | EXetoC: sortof, but a more efficient version (or at least, that's the goal). It's an observer model which eliminates most dynamic dispatch. |
19:27:16 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
19:31:20 | filwit | EXetoC: the idea is to only use dynamic dispatch to invoke a type-specific event call (which handles the events for each instances or it's type through static dispatch), instead of a dynamic dispatch call for each instance subscribed to an event. So if an instance of Foo says "subscribe to mouseClick" then it adds itself to it's Type's 'mouseClick' {.global.} list, and ensures it's Type's "mouseClick loop" proc is on the roster of dy |
19:31:49 | filwit | of** it's type... |
19:34:00 | filwit | it's sorta like C#'s event/delegate builtin, though I believe those are still being invoke through dynamic dispatch per-instance (unless the compiler is doing something special for those, which is possible I imagine). |
19:36:28 | filwit | either way, C#'s event/delegate system has not possibility of being inlined, so technically this wins in performance regardless (unless there's some odd cache issue i'm unaware of). |
19:37:10 | filwit | depending on workload of course... |
19:38:40 | Araq | meh, I'm still a fan of immediate mode UIs |
19:39:10 | Araq | no callbacks, no events, just brutal procedural code |
19:40:31 | Araq | which is a joy to debug ;-) |
19:40:43 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
19:41:08 | filwit | Araq: it's not just for UI's though, and one part of this I haven't mentioned is the interplay between the event systems, and how my class-macro provides and easy way to bind to each event... which should require some amount of "event name" system. |
19:41:45 | Araq | filwit: I know I won't convince you and that's fine. I'm not writing games. |
19:42:11 | * | bogen joined #nimrod |
19:42:58 | Araq | however, it's wise to optimize for debugging effort since that's what takes the vast amount of time whenever you program something |
19:43:25 | Araq | or maybe I'm simply a bad programmer ... spending all my time debugging ;-) |
19:44:07 | filwit | Araq: well i'm all ears for better designs, I'm just not sure of a better (faster & robust) approach than what I'm talking about. At some point, you need dynamic-dispatch because you can have 50 different kinds of objects for each event... so you either need to dynamically invoke instance procedures, or you need to dynamically invoke type procedures which statically invoke instance procs. |
19:45:00 | Araq | see? this is already where we disagree |
19:45:18 | Araq | I don't have 50 different kind of objects |
19:45:46 | filwit | then you aren't writing a game or ui... |
19:46:21 | Araq | you have something like Unit <: Flyer <: EnemyFlyingMonster |
19:46:45 | Araq | I simply have Unit and some flags in it that further specialize the behaviour |
19:47:42 | EXetoC | ECS :> |
19:47:47 | filwit | actually, my structure doesn't work like that (although it can inherit behavior, it usually does so through components) |
19:48:13 | * | BlaXpirit-UA quit (Quit: Quit Konversation) |
19:48:20 | filwit | EXetoC: exactly |
19:49:51 | * | BlaXpirit joined #nimrod |
19:50:33 | filwit | Araq: the problem with flags and doing specialized systems is that it's not easily expandible... you can't have a user supply a "what happens when GreenLaser collides with XWing" overload without having them add in a new case..of condition, right? That's not going to work well for a simple-to-use engine system. |
19:51:06 | filwit | I guess you could do that with a macro system... |
19:51:21 | Jehan_ | Araq: Speaking of which, there is actually one annoyance with Nim's variant records in this case: Not being able to have the same field for more than one case. |
19:51:40 | Araq | you're damn right. I usually don't care about "extensible". |
19:53:03 | Araq | and also I'd write the game directly and not an engine |
19:53:15 | onionhammer | so when are we all moving to #nim ? |
19:53:53 | Araq | but yes, I'm not saying that this is feasible for the Unreal 4 guys |
19:54:24 | Araq | Jehan_: I guess you're right but ML doesn't support that either |
19:55:10 | Araq | onionhammer: I'm working on "nimfix" and then Varriount or others should try to use it on a couple of babel packages |
19:55:12 | Jehan_ | Araq: Well, ML sidesteps it by generally not naming the components of variants. |
19:55:53 | Araq | Foo int | Bar int * int ## can you use x[0] ? |
19:55:56 | * | Matthias247 joined #nimrod |
19:56:00 | Araq | I don't think so |
19:57:20 | Jehan_ | Araq: No, but you use match to deconstruct the instance. |
19:57:55 | Araq | yes but you cannot conflate Foo|Bar in one handler |
19:58:26 | Jehan_ | Araq: That's not what I'm talking about. |
19:59:01 | Araq | well indeed I don't get your point |
19:59:20 | Varriount | Meep |
19:59:50 | * | Trustable joined #nimrod |
19:59:53 | Jehan_ | Here's an example: |
20:00:35 | Jehan_ | type Expr = ref object |
20:00:35 | Jehan_ | case variant: ExprType |
20:00:35 | Jehan_ | of UnaryOp: |
20:00:35 | Jehan_ | op: OpCode |
20:00:35 | Jehan_ | arg: Expr |
20:00:36 | Jehan_ | of BinaryOp: |
20:00:37 | Jehan_ | op: OpCode |
20:00:37 | Jehan_ | arg1, arg2: Expr |
20:00:51 | Jehan_ | This blows up because it has `op` defined twice. |
20:01:19 | Jehan_ | Not an issue in ML because stuff is anonymous. |
20:02:20 | * | darkfusion quit (Ping timeout: 268 seconds) |
20:02:36 | Jehan_ | E.g.: type expr = UnaryOp of opcode * expr | BinaryOp of opcode * expr * expr |
20:03:16 | Araq | so? but you cannot access 'opcode' unconditionally |
20:03:22 | Jehan_ | Araq: I don't want to. |
20:03:35 | Jehan_ | In either case, I want to access it within a case/match statement. |
20:03:36 | onionhammer | Araq I meant the irc channel:) |
20:03:50 | Jehan_ | In Nim, I cannot even define the type. |
20:04:35 | Araq | well you have to name it op1 and op2, yes |
20:04:43 | Jehan_ | The workaround is to rename it for each variant. Yes, can do it, not perfect. |
20:04:57 | Araq | however IF we allow that, there is actually a new form of polymorphism involved |
20:05:04 | Araq | which ML lacks |
20:05:21 | Araq | so it's quite some effort to implement this feature properly |
20:05:27 | Jehan_ | Araq: Huh? |
20:06:05 | Araq | Jehan_: opcode needs to get the same offset, no matter which branch we're in |
20:06:09 | Jehan_ | Oh, you mean the obvious translation to C. |
20:06:31 | Araq | so that obj.opcode doesn't have to involve dispatching |
20:06:32 | Jehan_ | Yes, I know. I know it's not easy. It's still annoying. |
20:07:11 | Jehan_ | The underlying problem is that case statements don't constrain access to the parts of an object like `match … with` in ML does. |
20:07:51 | Araq | you can get that with warning[ObjVariant]:on iirc btw |
20:07:59 | Varriount | What exactly is the problem here? Even scrolling through the logs, it's unclear. |
20:08:26 | Jehan_ | Varriount: The problem is that one can't reuse field names for different variants. |
20:08:29 | Araq | "cannot prove safe access of field opcode" |
20:08:37 | Araq | or something like that |
20:08:57 | Varriount | Hm.. Would casting provide an (unsafe) way around this limitation? |
20:09:12 | Jehan_ | Varriount: Can't even define the type in the first place. |
20:09:34 | Araq | Jehan_: you can however move opcode out of the case easily |
20:09:51 | Jehan_ | Araq: But then every variant gets it. |
20:09:56 | Araq | yes |
20:09:59 | Jehan_ | Which won't work if I have others that don't. |
20:10:05 | Araq | usually that's acceptable though |
20:10:30 | Jehan_ | Araq: Not really for the use case I'm dealing with (ASTs). |
20:10:41 | Jehan_ | My workaround has been to rename it for each variant. |
20:11:03 | Jehan_ | Which is doable, and I'm not complaining. I think, however, that it indicates a weak spot in the language design. |
20:11:30 | Araq | case objects ARE a weak design in the language |
20:11:51 | Jehan_ | Heh. :) |
20:12:07 | Araq | I had good reasons for doing them this way but later I figured out the reasons are mostly wrong ... |
20:12:21 | Jehan_ | Well, they're also very convenient for a lot of cases. |
20:13:32 | Varriount | So... is it possible to improve/fix things? |
20:14:01 | Araq | yeah, my favourite example is for i in 0 .. < safeLen(n): n.children[i] |
20:14:15 | Jehan_ | Varriount: Yes. Of course, there are always tradeoffs. |
20:14:19 | Araq | where safeLen checks that n even has the children field |
20:14:43 | Araq | you can't do that in ML |
20:17:45 | Jehan_ | Araq: My personal preference is Scala's case classes, not ML variants, anyway. |
20:18:44 | Jehan_ | ML's variants have a lot of annoyances in practice. |
20:19:56 | reactormonk | Jehan_, scala case classes? I think you mean something else, because a case class is just a class without logic and a few data fields. |
20:20:25 | Jehan_ | reactormonk: case classes are Scala's solution to variant types. |
20:20:56 | Jehan_ | When extending a common abstract class. |
20:21:29 | * | fowl joined #nimrod |
20:21:29 | * | fowl quit (Changing host) |
20:21:29 | * | fowl joined #nimrod |
20:21:34 | reactormonk | Jehan_, sealed? |
20:21:48 | Jehan_ | reactormonk: Optionally sealed. |
20:21:59 | Jehan_ | Variant types need not be closed. |
20:22:08 | reactormonk | If they're sealed, that's basically a co-product? |
20:22:09 | Jehan_ | See, e.g., OCaml's polymorphic variants. |
20:24:27 | Jehan_ | abstract class Expr |
20:24:27 | Jehan_ | case class UnaryOp(op: OpCode, arg: Expr) extends Expr |
20:24:27 | Jehan_ | case class BinaryOp(op: OpCode, arg1: Expr, arg2: Expr) extends Expr |
20:29:23 | * | pepsipilot joined #nimrod |
20:30:43 | Araq | hi pepsipilot welcome |
20:30:54 | pepsipilot | Hi Araq |
20:31:24 | pepsipilot | good evening all I need some assistance with creating a simple webcam application |
20:33:05 | pepsipilot | 1 that will allow me to choose a directory and save that info and than take a snap shot and save it to that directory and overlay a simple text |
20:34:55 | Varriount | pepsipilot: What library do you plan to use in order to get images from the webcam? |
20:35:19 | dom96 | pepsipilot: You can use opencv to grab images from the webcam, here is a wrapper: https://github.com/dom96/nim-opencv |
20:35:24 | Araq | onionhammer: there is already #nimlang |
20:35:31 | Varriount | Also, do you plan to use library for image manipulation? |
20:35:53 | pepsipilot | what do u mean by Library |
20:36:12 | pepsipilot | sorry i have very little knowledge in programing |
20:36:21 | pepsipilot | i need it to be very simple |
20:38:15 | Varriount | dom96: How complete is that wrapper? |
20:38:32 | pepsipilot | Varriount is it possible to PVT msg u for more info |
20:38:37 | dom96 | Varriount: It's good enough to get webcam output. |
20:38:44 | dom96 | Varriount: I use it for that very purpose. |
20:39:04 | * | askatasuna joined #nimrod |
20:39:30 | Varriount | pepsipilot: You can. |
20:39:32 | Araq | pepsipilot: in tests/camera.nim there is a useful program that does what you need |
20:39:55 | dom96 | Araq: hah, I forgot I even had that. |
20:40:02 | dom96 | But yeah, there you go. |
20:40:19 | pepsipilot | i will look into it |
20:40:44 | Varriount | pepsipilot: It doesn't do the textual overlay, and doesn't save the image to disk, but yes, that grabs the image from the camera. |
20:41:07 | pepsipilot | So i am just downloading Nimrod |
20:41:12 | pepsipilot | and going to install it |
20:47:26 | * | Ven joined #nimrod |
20:56:30 | * | W1z0rd joined #nimrod |
20:56:39 | Araq | hi W1z0rd welcome |
20:56:47 | W1z0rd | Hi |
20:57:02 | W1z0rd | Thank you |
20:57:19 | Araq | nah, don't thank me, I'm a bot |
20:58:36 | Varriount | Araq: If you're a bot, what have you done with the real Araq?! |
20:59:03 | Ven | Varriount: well, why'd you need a *real* Araq when the bot one even greets newcomers?! |
20:59:26 | Ven | (though he *did* greet me as well, whereas I've been on this channel for several months now :-).) |
21:00:23 | Araq | Varriount: the real araq is working hard to get nimfix out so that you finally have something to do |
21:00:36 | W1z0rd | Well what's this channel all about then |
21:00:48 | Ven | W1z0rd: geeting greeted :p? |
21:00:50 | EXetoC | bots |
21:01:09 | EXetoC | written in nimrod. got 70 of them in here |
21:01:12 | W1z0rd | Ha well that's nice I like both |
21:01:23 | Araq | hrm and I thought we have a topic |
21:02:32 | * | BlameStross joined #nimrod |
21:04:53 | EXetoC | where? |
21:04:57 | EXetoC | oh there it is |
21:05:52 | * | jasondotstar joined #nimrod |
21:06:04 | EXetoC | put a code in the topic, and kick whoever is not sending it when joining! |
21:06:46 | Varriount | 2 more people and we break the record high for users |
21:06:52 | Varriount | Hi jasondotstar |
21:08:45 | reactormonk | Varriount, lemme create a few bots... |
21:10:33 | Araq | really the record is 78? |
21:12:43 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
21:12:47 | dom96 | 77 |
21:13:05 | Araq | well endou is listed twice |
21:13:14 | dom96 | *shrug* |
21:13:16 | Araq | and Ven just left ... |
21:13:58 | dom96 | The amount of users in this channel is definitely increasing as of late |
21:14:03 | dom96 | I really need to get NimBot to log this |
21:14:07 | dom96 | so that we get a nice graph |
21:25:37 | * | Matthias247 quit (Read error: Connection reset by peer) |
21:27:44 | jasondotstar | Hi Varriount |
21:30:10 | * | jpoirier joined #nimrod |
21:30:13 | * | flaviu joined #nimrod |
21:32:13 | * | Varriount|Mobile joined #nimrod |
21:33:02 | Varriount|Mobile | pepsipilot: ping |
21:36:29 | W1z0rd | Pong |
21:41:18 | * | untitaker quit (Ping timeout: 252 seconds) |
21:43:33 | * | BlaXpirit quit (Ping timeout: 272 seconds) |
21:43:36 | * | Varriount|Mobile hits W1z0rd upside the head with the paddle |
21:44:23 | * | W1z0rd takes it like a man |
21:46:32 | * | untitaker joined #nimrod |
21:47:23 | * | Jehan_ quit (Quit: Leaving) |
22:00:59 | dom96 | Even Go has builder issues it seems: https://docs.google.com/document/d/1RxukaAI4gBJfpaZ1_eE3EWMzFrsbMwWM_9AEFqKa0ZA/preview?sle=true#heading=h.lmzw773738pa |
22:01:36 | Varriount|Mobile | dom96: Doesn't mean our builder shouldn't be better. |
22:01:52 | dom96 | yes |
22:01:59 | Araq | no idea what you mean. Our builder has no issues. |
22:02:36 | dom96 | If the BDFL says it then it must be true :P |
22:03:04 | Varriount|Mobile | Araq: Half-True . The main issue I see at the moment is that it doesn't test pull requests automatically |
22:03:46 | Araq | the bigger issue is that it triggers too early |
22:04:21 | Araq | when I'm in my "apply PRs mood" it tests way too often |
22:04:41 | dom96 | Nah. |
22:04:46 | dom96 | We simply need better output. |
22:05:07 | dom96 | Waiting for a build to complete shouldn't be a problem. |
22:05:26 | dom96 | As long as you can easily be able to tell what commit broke what later. |
22:12:29 | * | pepsipilot quit () |
22:13:19 | Varriount|Mobile | Aww, pepsipilot left... |
22:21:44 | * | nande quit (Remote host closed the connection) |
22:27:39 | * | nande joined #nimrod |
22:28:39 | * | Varriount quit (Ping timeout: 255 seconds) |
22:31:48 | * | Varriount|Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
22:32:48 | * | nande quit (Remote host closed the connection) |
22:34:06 | * | nande joined #nimrod |
22:41:08 | * | nande quit (Remote host closed the connection) |
22:41:19 | * | askatasuna quit (Quit: WeeChat 1.0) |
22:42:15 | * | nande joined #nimrod |
22:43:31 | * | nande quit (Remote host closed the connection) |
22:58:01 | * | fowlmouth joined #nimrod |
22:59:24 | Trustable | Aporia is getting better and better.. :) |
23:00:04 | dom96 | :D |
23:03:00 | * | onionhammer left #nimrod ("WeeChat 0.4.3") |
23:03:50 | * | brson quit (Quit: leaving) |
23:06:05 | * | mynick joined #nimrod |
23:07:37 | * | mynick is now known as onionhammer |
23:07:42 | * | onionhammer is now known as Onionhammer |
23:07:44 | Onionhammer | hm |
23:08:23 | * | bogen quit (Quit: Leaving.) |
23:10:28 | Onionhammer | well that works i guess |
23:12:34 | NimBot | nimrod-code/babel master d5d28c8 singularperturbation [+0 ±1 -0]: 'Init' feature initial implementation... 6 more lines |
23:12:34 | NimBot | nimrod-code/babel master 9a67b08 singularperturbation [+0 ±1 -0]: Style changes, fix some bugs, raise exceptions... 7 more lines |
23:12:34 | NimBot | nimrod-code/babel master 0e24809 Dominik Picheta [+0 ±1 -0]: Merge pull request #58 from singularperturbation/master... 2 more lines |
23:13:55 | NimBot | nimrod-code/babel master 64f0554 Dominik Picheta [+0 ±1 -0]: Remove spaces inside parens. |
23:15:36 | dom96 | Trustable: How's the PR fixing going? |
23:15:58 | Trustable | dom96: I'm making good progress |
23:16:32 | dom96 | that's good |
23:17:13 | Trustable | I will re-add your feature compileUnsavedSave. But can you please explain me what is the purpose of it? |
23:17:46 | reactormonk | Trustable, I think that's for asking the compiler for checks. |
23:18:45 | Trustable | dom96, I don't think so. It just removed the "*" to show that the file is saved, when the file is saved only in a temporary directory. |
23:28:43 | * | dom96 quit (Excess Flood) |
23:29:20 | Trustable | dom96: preview: http://imgur.com/tzf0RRQ |
23:29:46 | * | dom96 joined #nimrod |
23:29:54 | * | darkf joined #nimrod |
23:30:41 | dom96 | Trustable: Ctrl + N, type in some code, F5 |
23:30:57 | dom96 | Trustable: This feature means that the tab will be automatically saved in /tmp |
23:31:03 | dom96 | instead of asking you where to save it |
23:31:11 | dom96 | in short: it saves time |
23:33:19 | dom96 | Trustable: ooh nice |
23:34:32 | Trustable | dom96: Now I got the purpose of compileUnsavedSave. What should be the title in the settings window for this? |
23:35:36 | EXetoC | (unsaved)? |
23:35:40 | dom96 | hm, perhaps "Implicit save to Temporary Files on compilation of unsaved file" |
23:36:25 | * | nande joined #nimrod |
23:41:01 | Trustable | dom96, ok, I think it should be disabled by default. |
23:41:25 | dom96 | why? |
23:42:01 | Trustable | dom96: when it's saved in Temporary Files it's not really saved for me |
23:42:22 | dom96 | Yeah, it's the same to Aporia. |
23:42:33 | dom96 | That's why you get a red * |
23:42:44 | dom96 | and it also asks you if you wanna save it somewhere else if you close the window |
23:46:05 | Trustable | dom96: I don't undestand the feature now. |
23:46:14 | * | Sht0 quit (Ping timeout: 276 seconds) |
23:46:50 | dom96 | Trustable: Aporia detects files which have been saved in /tmp |
23:47:03 | dom96 | Unsaved files get a black * beside their name |
23:47:09 | dom96 | Files saved to /tmp get a red * |
23:47:34 | dom96 | This means that they are treated almost the same as unsaved files. |
23:48:02 | dom96 | But you get the convenience of not having to choose a location to save a file somewhere which you don't really need. |
23:48:11 | Trustable | dom96: Ok, I have tested it. Now I understand it. |
23:48:15 | dom96 | I use this feature to try out code. |
23:48:42 | dom96 | Like say I want to check if echo(56) works (silly example I know), I just open a new tab, type that in and press F5 |
23:48:52 | dom96 | Then I can simply close the tab. |
23:48:58 | Trustable | dom96: What about having this behaviour always, without settings entry? |
23:49:30 | dom96 | I think we can leave it out of the settings dialog. |
23:49:40 | dom96 | keep the settings in the cfg file though |
23:49:45 | Trustable | ok |
23:49:48 | dom96 | If someone wants to change it badly they can edit it |
23:50:22 | Trustable | What I insert a section for the keyboard shortcuts in the ini file? |
23:52:06 | Trustable | I think I will commit now, then you can test it. |
23:53:40 | filwit | i need to port my Kate colors to Aporia... i made (copied) a few more recently which i really like. |
23:54:01 | Onionhammer | are there updates to aporia? |
23:54:08 | dom96 | Trustable: [KeyShortcuts]? |
23:55:01 | dom96 | Trustable: I'll test it tomorrow, need to head to sleep soon. |
23:55:18 | dom96 | Onionhammer: There are PRs :) |
23:55:29 | Trustable | dom96: alright, no hurry |
23:55:45 | Trustable | The PR is updated: https://github.com/nimrod-code/Aporia/pull/54 |
23:57:17 | dom96 | Trustable: thanks |
23:57:57 | Trustable | dom96: I will see if you like my changes or not :D |
23:59:28 | Trustable | Some new changes: Re-order the columns in the Error List; Show Errors in the Error List in red; Focus Error List and scroll to bottom when entries are inserted |
23:59:56 | dom96 | cool |