| 00:00:22 | derka | Hi guys |
| 00:00:33 | filwit | hello |
| 00:00:36 | derka | idlework what kind of game are you working on? |
| 00:01:13 | ldlework | I just described it :P |
| 00:01:44 | filwit | derka: top-down, open-world, turn-based, explore + build + hunt, etc |
| 00:01:52 | ldlework | yup |
| 00:01:59 | derka | cool |
| 00:02:07 | derka | open source |
| 00:02:08 | derka | ? |
| 00:02:29 | derka | isometric 3d ? |
| 00:02:50 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:03:00 | ldlework | not isometric for now |
| 00:03:08 | ldlework | can always add isometric rendering later |
| 00:03:16 | derka | ok cool |
| 00:03:26 | derka | so like a gauntlet |
| 00:03:38 | derka | early days gauntlet |
| 00:04:15 | ldlework | derka: I posted some screenshots above |
| 00:04:25 | ldlework | of the look I'm going for |
| 00:04:38 | derka | cool |
| 00:05:23 | derka | nice |
| 00:05:28 | derka | how long have you been working on it |
| 00:07:20 | * | vendethiel joined #nim |
| 00:12:38 | ldlework | derka: two months or so in my freetime |
| 00:13:48 | derka | nice |
| 00:19:40 | * | Demon_Fox quit (Ping timeout: 245 seconds) |
| 00:23:01 | gokr | Araq: Perhaps you told me... but dynlib directive - what about a static library? |
| 00:23:28 | filwit | gokr: use --passL:<lib> |
| 00:23:56 | filwit | + {.importC.} |
| 00:24:10 | gokr | Sure, for the linking phase... but... don't I need something more than ... ok, so how do I get that one? |
| 00:24:17 | gokr | I use c2nim. |
| 00:24:20 | * | Demon_Fox joined #nim |
| 00:24:22 | gokr | It only puts in cdecl. |
| 00:24:43 | filwit | oh, sorry. I've never used c2nim and know nothing about it :\ |
| 00:25:07 | gokr | It has the dynlib directive, but... that's for .so/dll etc. Not .a |
| 00:25:35 | Araq | might indeed need a c2nim patch I'm afraid |
| 00:27:30 | gokr | Hard? |
| 00:27:35 | Araq | nah |
| 00:28:06 | gokr | My eyes are blurry anyway, so... something you might help within a day or two? |
| 00:28:07 | Araq | just create a #staticlib that produces .importc and not the .dynlib |
| 00:28:14 | gokr | Ok, I can try. |
| 00:28:16 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 00:36:07 | ldlework | If you have a concept which takes a generic param. |
| 00:36:10 | * | jaco60 quit (Ping timeout: 260 seconds) |
| 00:36:16 | ldlework | How do you actually use that concept as a generic param |
| 00:36:22 | ldlework | nested generic params don't seem to work |
| 00:36:29 | ldlework | Tilemap*[Tile, GeneratorType[Tile]] = ref object |
| 00:36:53 | ldlework | GeneratorType is a concept |
| 00:36:58 | ldlework | GeneratorType[Tile] = concept cg |
| 00:39:22 | ldlework | Lets say you have `proc foo[A, B]`, if B has a generic parameter, how do you specify it? |
| 00:39:37 | ldlework | What if you want B's generic parameter to be the same type as A? |
| 00:41:31 | Araq | simple: If they have to be the same only use [A] |
| 00:41:49 | ldlework | B is not the same type as A |
| 00:41:56 | ldlework | B is a generic concept |
| 00:42:10 | ldlework | I want to do `proc foo[A, B[A]]` but can't |
| 00:42:27 | ldlework | So if you pass an int as the first parameter, you have to pass in a B[int] |
| 00:42:35 | ldlework | as the second parameter |
| 00:43:11 | gokr | Araq: Testing it out. |
| 00:44:52 | * | schmebulock joined #nim |
| 00:44:58 | * | filwit quit (Quit: Leaving) |
| 00:45:04 | * | schmebulock left #nim (#nim) |
| 00:45:09 | Araq | ldlework: since we don't have "higher kinded types" (template template params or whatever) the solution is to underspecify the generics |
| 00:45:22 | ldlework | I was just realizing that... |
| 00:45:38 | ldlework | Only specify A, and then in the field definition just use blah: B[A] outright |
| 00:45:40 | ldlework | interesting. |
| 00:46:00 | ldlework | is that what you meant? |
| 00:46:01 | gokr | Araq: Think it worked. |
| 00:46:17 | * | desophos joined #nim |
| 00:46:28 | Araq | gokr: create a PR and I will review it |
| 00:46:32 | gokr | sure |
| 00:47:30 | ldlework | heh |
| 00:47:32 | ldlework | sigmatch.nim(691) typeRel |
| 00:47:34 | ldlework | sigmatch.nim(691) typeRel |
| 00:47:37 | ldlework | sigmatch.nim(626) typeRel |
| 00:47:39 | ldlework | ast.nim skipTypes |
| 00:47:41 | ldlework | Stack overflow |
| 00:48:24 | Araq | ldlework: ouch |
| 00:49:33 | ldlework | https://gist.github.com/dustinlacewell/92136d2ce1461d9641ac |
| 00:53:15 | ldlework | bleh back to invalid type: 'GeneratorType' in this context: 'proc (app: App): GameScene' |
| 00:55:59 | * | darkf quit (Quit: Leaving) |
| 01:04:41 | ldlework | I think I'm just gonna use methods for this. |
| 01:07:38 | ldlework | If anyone can get this to work, that'd be pretty cool: https://gist.github.com/dustinlacewell/4b0a85e3b477a2687d9c |
| 01:07:52 | ldlework | but I guess I don't understand concepts well enough to wield them yet |
| 01:08:55 | ldlework | The idea is that you have your own Tile type and your own Generator type. You create a Tilemap with them and the Tilemap will return Chunks of your Tile object as returned from the Generator object you pass to it. |
| 01:09:04 | * | francisl joined #nim |
| 01:09:15 | ldlework | The idea is that the Tilemap doesn't know ahead of time what Tile and Generator objects will be used so it can be used as library code |
| 01:24:04 | * | sheerun quit () |
| 01:30:50 | ldlework | Araq: with your "structural delegate" method replacement idea, if moduleA exports typeA and procA which takes typeA, and I consume typeA to create typeB as a delegate can I pass my typeB into the procA that takes typeA ? |
| 01:31:15 | ldlework | Also, how can I override specific procs and fields that should not be delegated? |
| 01:31:28 | ldlework | How to deal with collisions between delegate targets? |
| 01:32:33 | Araq | ldlework: yes |
| 01:32:44 | Araq | and I dunno I think you can't |
| 01:32:52 | ldlework | That doesn't seem super useful then? |
| 01:33:11 | Araq | collisions are handled by using the declaration order of the fields |
| 01:33:13 | ldlework | Anywhere I could pass Parent I could just pass Parent.Child |
| 01:33:28 | ldlework | If Parent can't alter the behavior the Child I don't see the utility |
| 01:34:00 | ldlework | Araq: something like, delegates defined earlier, or last, are chosen, etc? |
| 01:35:22 | ldlework | Like if I call a proc `foo` why not just do overload resolution by trying to find a `foo(typeB)` before calling a `foo(typeA)` ? |
| 01:35:32 | ldlework | If B is delegating to A |
| 01:36:03 | ldlework | If there is no implementation for the aggregating type, then you start checking delegates in order, or reverse order or whatever. |
| 01:36:12 | Araq | yeah. |
| 01:36:25 | Araq | I guess I don't understand your questions |
| 01:36:41 | Araq | it just works (tm) like you think it would work |
| 01:36:45 | ldlework | lol |
| 01:37:24 | Araq | we get multiple inheritance and dynamic binding with a single simple to implement mechanism that is also useful for wrappers |
| 01:37:35 | ldlework | I was asking, if typeB is delegating to typeA and there is a proc foo implemented for typeA, and I call foo on typeB, it'll work. But what if I want to provide a typeB specific impmlementation. |
| 01:37:51 | Araq | it uses a V-table |
| 01:37:55 | Araq | like C++. |
| 01:38:10 | Araq | it works like C++ in this respect I guess |
| 01:38:28 | ldlework | Araq: I thought this is what I was getting in Go |
| 01:38:36 | ldlework | But they go half-way |
| 01:39:24 | ldlework | Or was it Rust, I forget. |
| 01:40:14 | ldlework | using 'of RootObj' and the 'method' keyword is really easy. I hope this could be made as nice to use. |
| 01:45:15 | * | ThePythonicCow quit (Quit: ChatZilla 0.9.92 [Firefox 44.0/20160123151951]) |
| 01:48:39 | * | yglukhov joined #nim |
| 01:53:30 | * | yglukhov quit (Ping timeout: 256 seconds) |
| 02:00:05 | * | derka quit (Ping timeout: 276 seconds) |
| 02:00:36 | * | derka joined #nim |
| 02:05:40 | * | derka quit (Quit: derka) |
| 02:05:57 | * | Varriount joined #nim |
| 02:07:52 | * | Varriount_ quit (Ping timeout: 250 seconds) |
| 02:13:53 | * | brson quit (Quit: leaving) |
| 02:17:16 | ldlework | gar I just ran into the thing where |
| 02:18:30 | * | vendethiel joined #nim |
| 02:18:44 | ldlework | if you have library module which exports a base type L and you create a subtype L' and implement a method for it, when the library module calls the method on the L' instance you pass to it, it will not call your overloaded method. |
| 02:18:51 | ldlework | Since the library module never imports your module. |
| 02:18:54 | ldlework | Damn that's frustrating. |
| 02:20:03 | ldlework | Anyone have any advice related to that? |
| 02:21:52 | ldlework | I don't wanna pass around procvars |
| 02:23:14 | ldlework | I suppose that's the only way |
| 02:23:26 | ldlework | to get a library module to execute methods on a subtype |
| 02:23:38 | ldlework | because otherwise how would the library module ever know about thoe methods |
| 02:23:43 | ldlework | oh god method keyword |
| 02:23:58 | ldlework | eh I'm using method keyword |
| 02:26:14 | ldlework | yay |
| 02:40:40 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 02:53:40 | * | ryu0 joined #nim |
| 02:59:31 | * | quark1 quit (Ping timeout: 245 seconds) |
| 03:03:39 | * | ryu0 left #nim ("WeeChat 1.0.1") |
| 03:27:26 | * | gokr quit (Quit: Leaving.) |
| 03:30:23 | * | dashed quit (Quit: Connection closed for inactivity) |
| 03:34:32 | * | pregressive joined #nim |
| 03:43:36 | * | ephja quit (Ping timeout: 250 seconds) |
| 03:50:13 | * | yglukhov joined #nim |
| 03:54:09 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 03:56:40 | * | endragor joined #nim |
| 04:02:26 | ics | So constructors and UFCS -> undeclared routine |
| 04:08:43 | Varriount | ics: ? |
| 04:19:29 | * | ThePythonicCow joined #nim |
| 04:23:12 | ics | Varriount: I was following along with the "object variants" part of the manual, with an enum type and another to wrap it with extra fields |
| 04:23:52 | * | ThePythonicCow_ joined #nim |
| 04:23:57 | ics | It uses a case statement to look at kind (first parameter) and do something based on that |
| 04:25:53 | ics | I just wanted to see if I could call kindThing.Constructor(field2, field3) instead of Constructor(kind: kindThing, x: field1, y: field2) |
| 04:26:36 | ics | But it turns out they all need to be named anyway, so Constructor(kindThing, field1, field2) doesn't work either |
| 04:28:55 | * | Demon_Fox quit (Read error: Connection reset by peer) |
| 04:29:16 | * | Demon_Fox joined #nim |
| 04:36:58 | * | vendethiel joined #nim |
| 04:45:23 | * | ThePythonicCow_ left #nim (#nim) |
| 04:50:58 | * | yglukhov joined #nim |
| 04:51:47 | * | ThePythonicCow_ joined #nim |
| 04:52:19 | * | ThePythonicCow_ left #nim (#nim) |
| 04:54:21 | * | francisl quit (Quit: francisl) |
| 04:54:46 | * | ThePythonicCow_ joined #nim |
| 04:55:03 | * | ThePythonicCow_ left #nim (#nim) |
| 04:55:21 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 05:00:06 | Varriount | ics: Ah. |
| 05:00:20 | * | vendethiel quit (Ping timeout: 248 seconds) |
| 05:12:52 | * | endragor quit (Remote host closed the connection) |
| 05:14:38 | * | endragor joined #nim |
| 05:14:49 | * | gour joined #nim |
| 05:28:06 | * | pregressive quit (Remote host closed the connection) |
| 05:34:04 | * | s4 joined #nim |
| 05:52:06 | * | lompik quit (Ping timeout: 240 seconds) |
| 05:57:26 | ldlework | def-: is there anyway to deserialize reference types with the json module? |
| 05:57:45 | ldlework | or rather with the marshal lib |
| 06:26:10 | * | s4 quit (Quit: Konversation terminated!) |
| 06:39:02 | * | vendethiel joined #nim |
| 06:52:28 | * | yglukhov joined #nim |
| 06:53:41 | * | derka joined #nim |
| 06:56:45 | * | yglukhov quit (Ping timeout: 245 seconds) |
| 07:01:32 | * | derka quit (Quit: derka) |
| 07:04:46 | * | ThePythonicCow left #nim (#nim) |
| 07:20:16 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 07:32:56 | * | ThePythonicCow joined #nim |
| 07:34:47 | * | filcuc joined #nim |
| 07:42:41 | * | vendethiel joined #nim |
| 07:44:06 | * | toaoMgeorge quit (Ping timeout: 250 seconds) |
| 07:57:08 | * | endragor quit (Remote host closed the connection) |
| 08:04:21 | * | Trustable joined #nim |
| 08:15:45 | * | endragor joined #nim |
| 08:31:41 | * | yglukhov joined #nim |
| 08:45:25 | * | gokr joined #nim |
| 08:52:59 | * | sjums left #nim ("Leaving") |
| 08:58:21 | * | Demon_Fox quit (Quit: Leaving) |
| 09:12:36 | * | apotheon quit (Ping timeout: 248 seconds) |
| 09:23:38 | * | coffeepot joined #nim |
| 09:23:41 | * | Arrrr joined #nim |
| 09:25:22 | * | toaoMgeorge joined #nim |
| 09:26:13 | * | coffeepot quit (Client Quit) |
| 09:27:22 | * | coffeepot joined #nim |
| 09:27:22 | * | coffeepot quit (Client Quit) |
| 09:27:38 | * | coffeepot joined #nim |
| 09:44:27 | * | sheerun joined #nim |
| 09:44:41 | * | jaco60 joined #nim |
| 09:48:14 | * | derka joined #nim |
| 10:12:43 | * | apotheon joined #nim |
| 10:19:25 | * | desophos quit (Read error: Connection reset by peer) |
| 10:42:42 | * | endragor quit (Remote host closed the connection) |
| 10:43:43 | * | filcuc quit (Read error: Connection reset by peer) |
| 10:44:01 | * | filcuc joined #nim |
| 10:51:13 | * | darkf joined #nim |
| 10:57:10 | filcuc | are there updated on the channel module..i heard some time ago that it wasn't in a good shape |
| 10:57:54 | filcuc | and that it was slow..is it still true? is planned something, maybe a new module to replace it? |
| 10:58:38 | Araq | I have a patch to improve its performance and interface quite a bit |
| 10:59:21 | filcuc | Araq: nice to know that ;) |
| 10:59:34 | Araq | and it was on par with spawn anyway, so it's not that slow |
| 10:59:57 | Araq | "slow" mostly means that it doesn't use lockfree stuff |
| 11:02:41 | filcuc | Araq: ok |
| 11:11:23 | coffeepot | So... is Nim getting a PHP backend target? |
| 11:13:40 | * | endragor joined #nim |
| 11:14:22 | * | derka quit (Quit: derka) |
| 11:23:15 | Arrrr | Yes, and yet you have to forward declare types. |
| 11:24:13 | Araq | Arrrr: maybe I get paid for the PHP backend and not for the removal of forward decls? |
| 11:24:39 | Araq | did it ever occur to you what it implies to have to live from the software you write? |
| 11:25:48 | Arrrr | OK, i didnt know you were paid for that, sorry. |
| 11:26:00 | gour | Araq: that's so obvious for PHP backend and i'm glad you can pay (some) bills with Nim ;) |
| 11:29:25 | * | iamd3vil joined #nim |
| 11:29:55 | coffeepot | Well this is great news. Never coded a line of PHP in my life but it makes me more certain that Nim is shaping up to be a fantastic 'master' language with all these backends. It's also great news that people are willing to pay to get Nim to expand into other areas. |
| 11:30:54 | coffeepot | c, c++, javascript, llvm(?), PHP, quite a nice selection |
| 11:33:43 | filcuc | Araq: has it been announced somewhere? glad to hear that |
| 11:38:39 | filcuc | even if i hardly understand the need for a "server side" language given that you can do the same directly with nim |
| 11:41:21 | Araq | 1. the PHP backend is a "mod" of the JS backend. It was cheap to develop and it means bugfixes already affect both the PHP and the JS target |
| 11:41:38 | Araq | IMO a brilliant hack. |
| 11:41:38 | wuehlmaus | ... the more i think about it the more i like that the re module is still with nim btw. |
| 11:42:06 | wuehlmaus | for me it feels easier than the nre module even if it is not that capable |
| 11:42:09 | Araq | 2. the PHP is not officially supported, I don't plan to document it, nor do I accept bug reports for it |
| 11:42:41 | Araq | except of course if they come from my coworkers ;-) |
| 11:43:42 | Araq | so ... I didn't see to announce if officially. and fyi I get paid for lots of other things as well many of which are really useful for the Nim community. The rewrite of the LL comes to mind. |
| 11:44:08 | Araq | relax, be happy, Nim is only getting better. |
| 11:48:20 | * | derka joined #nim |
| 11:55:24 | * | regtools quit (Quit: leaving) |
| 11:57:53 | * | filcuc_ joined #nim |
| 11:59:10 | * | filcuc|2 joined #nim |
| 12:00:33 | * | filcuc quit (Ping timeout: 240 seconds) |
| 12:02:37 | * | filcuc_ quit (Ping timeout: 276 seconds) |
| 12:04:15 | * | jaco60 quit (Ping timeout: 240 seconds) |
| 12:04:25 | * | iamd3vil left #nim ("Leaving") |
| 12:49:53 | * | BitPuffin joined #nim |
| 13:01:55 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 13:13:45 | * | filwit joined #nim |
| 13:17:21 | * | Ven joined #nim |
| 13:28:02 | * | derka_ joined #nim |
| 13:30:05 | * | derka quit (Ping timeout: 245 seconds) |
| 13:30:06 | * | derka_ is now known as derka |
| 13:32:12 | * | vangroan joined #nim |
| 13:32:56 | * | Arrrrr joined #nim |
| 13:35:10 | * | Arrrr quit (Ping timeout: 252 seconds) |
| 13:35:49 | filwit | Araq: quick questions. When overloading `=` we cannot make the RHS mutable. Is that for some security reason? |
| 13:36:02 | filwit | er.. 'safety' reason |
| 13:36:41 | Araq | it's an oversight |
| 13:36:42 | Araq | bbl |
| 13:37:01 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 13:38:34 | * | junw joined #nim |
| 13:39:48 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:40:06 | * | Ven joined #nim |
| 13:41:21 | * | Ven quit (Client Quit) |
| 13:49:46 | * | Sembei joined #nim |
| 13:52:19 | * | Ven joined #nim |
| 13:54:05 | * | Ven quit (Client Quit) |
| 13:56:52 | * | ephja joined #nim |
| 13:57:40 | * | Ardethian joined #nim |
| 13:57:44 | * | Ardethian left #nim (#nim) |
| 14:01:20 | * | yglukhov joined #nim |
| 14:03:29 | * | lg_ joined #nim |
| 14:04:49 | * | TheManiac quit (Remote host closed the connection) |
| 14:09:25 | filwit | crap.. it's really hard to avoid undesired recursive maco calls when overloading `.` .. is there some way to enforce that the macro wont be called again on the AST it outputs? |
| 14:10:08 | * | M-max joined #nim |
| 14:11:32 | * | NoOova joined #nim |
| 14:12:20 | filwit | eg, i'm playing with overloading `.` via macro which will delegate field/call access to an object's select members.. but the problem is it often needs to output a newDotExpr() itself.. which in turn calls the macro again, forever, until the compiler complains |
| 14:12:21 | NoOova | Eugene Zaitsev? |
| 14:20:10 | filwit | hmm... nevermind I was doing something wrong.. |
| 14:22:19 | filwit | hmm... nevermind I was doing something wrong.. |
| 14:22:25 | filwit | damn alt-tab... |
| 14:24:35 | * | zaquest quit (Quit: Leaving) |
| 14:26:46 | * | zaquest joined #nim |
| 14:39:32 | * | lompik joined #nim |
| 14:41:25 | wuehlmaus | has somebody considered the possibility of a "nim playgruond" as a webpage or is it available already? a friend of mine just said that he does not understand that even when nim has everything that it needs for this case there is no single playground available |
| 14:46:22 | lg_ | NoOova: I'm Evgeny Zaitsev, but how do you get to know? |
| 14:47:30 | * | M-Quora joined #nim |
| 14:50:28 | * | gokr quit (Quit: Leaving.) |
| 14:53:20 | coffeepot | wuehlmaus there was a nim playground type website around before, but I think there was a problem with it. |
| 14:59:35 | * | lompik quit (Ping timeout: 240 seconds) |
| 15:02:04 | * | endragor quit (Remote host closed the connection) |
| 15:12:33 | * | vangroan quit (Ping timeout: 240 seconds) |
| 15:15:42 | * | vendethiel joined #nim |
| 15:15:58 | * | silven quit (Remote host closed the connection) |
| 15:16:26 | * | Dildosan joined #nim |
| 15:17:12 | * | silven joined #nim |
| 15:20:02 | * | zaquest quit (Read error: Connection reset by peer) |
| 15:20:33 | * | zaquest joined #nim |
| 15:22:53 | * | jaco60 joined #nim |
| 15:23:49 | * | Ven joined #nim |
| 15:23:54 | * | Ven quit (Client Quit) |
| 15:25:49 | filwit | cool, just made an auto-dispatch macro for object composition as an alternative to multi-inheritance |
| 15:25:51 | filwit | https://gist.github.com/PhilipWitte/ff8cc26d76e962591a48 |
| 15:26:29 | * | Dildosan quit (Quit: Leaving) |
| 15:27:05 | filwit | macros.getType() is awesome, love that ability of Nim's macros.. makes doing odd magic stuff like this really easy |
| 15:28:18 | * | Ven joined #nim |
| 15:28:23 | * | silven quit (Remote host closed the connection) |
| 15:29:40 | * | silven joined #nim |
| 15:31:03 | * | saml joined #nim |
| 15:36:33 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 15:41:35 | * | vendethiel joined #nim |
| 15:41:37 | coffeepot | filwit: that's pretty interesting |
| 15:42:16 | coffeepot | and neat example |
| 15:43:41 | * | endragor joined #nim |
| 15:44:19 | filwit | coffeepot: yeah it's an examples I've seen before on why multi-inheritance is good (you can't make a KillerRobotDog easily without it), so that's why I tried this... although I did this because of the VTable example Araq posted last night, and this technique could easily be applied there too as an alternative to Nim methods |
| 15:51:32 | Araq | coffeepot: I asked you to review the odbc PRs, right? |
| 15:55:08 | * | pregressive joined #nim |
| 15:56:29 | coffeepot | yeah you did, on the assumption that I wrote odbc_db, which I didn't. As I said before I can have a look but I'm unfamiliar with the module |
| 15:57:34 | coffeepot | Araq: Can you send me a link to the PR? |
| 16:00:38 | coffeepot | filwit: I used to be a huge OO fan and shrugged off architecture complexities that came with it. I pined for something like multiple inheritance, but after coming to Nim realised how much easier composition is in a language that allows metaprogramming. Gamedev in particular I've found is not OO friendly, where items often need to share information |
| 16:00:38 | coffeepot | not from a common route. |
| 16:03:20 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 16:03:24 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:04:34 | filwit | meh, I still think multi-inheritance is often a better design that composition, but not always.. i mean, it IS composition, just done for you. And object inheritance/composition still work well with game dev stuff.. it's just you can't paint your entire picture with one brush and expect the best results.. but that doesn't mean you don't want multiple brushes at your disposal. |
| 16:07:31 | coffeepot | that's true, I guess it's just that in the past I've designed an object hierarchy then at some point realised that it just didn't work and had to start again. As you say you can use multiple roots but usually I don't actually care about what came from what, I just want to know if it supports an operation or a bit of data. I agree though, multiple i |
| 16:07:31 | coffeepot | nheritance is an easy way of doing composition, assuming nothing clashes ofc! |
| 16:07:52 | filwit | components "should" not rely on inheritance in game-dev mostly for efficiency reasons. Eg, divide your entity data up for more efficient processing.. so yeah I completely agree you OOP (eg, ref-objects with overloadable dynamic dispatch) is not the best design for a lot of game code... but there are a lot of systems in the engine that don't need to follow that design, and can still use OOP patterns just fine |
| 16:08:25 | coffeepot | i think from what I've seen, we'll end up with some macro 'standard' to do composition as you've demoed above |
| 16:08:59 | coffeepot | it was a while before Nim had a way to access the super class in OOP |
| 16:09:46 | filwit | yeah, maybe. though personally I would argue to just put these types of libs in Nimble instead.. cause often you'll have multiple ones with slightly different design goals, and that's a good thing |
| 16:10:19 | filwit | but i agree, a robust lib like that would be handy for everyone to have easy access too |
| 16:10:48 | coffeepot | dividing your entity up is great, but aside from cache hits with pointers that ref stuff far away in memory, I don't think it's a HUGE hit. I mean, I'm writing an ECS atm where all the components are loaded from hashtables! How slow is that by comparison! Still works well enough at the moment though |
| 16:11:15 | coffeepot | definitely agree to put them into nimble |
| 16:11:48 | coffeepot | I've been turned by the slim std-lib philosophy, since nimble is so accessible |
| 16:12:20 | * | pregressive quit (Remote host closed the connection) |
| 16:12:49 | * | pregressive joined #nim |
| 16:13:42 | coffeepot | there's often people asking about OOP and functional approaches, be great if they could just be pointed to an OOP module to use |
| 16:14:50 | filwit | about OOP limitations (because I used to be all OOP gung-ho too), I think often people use languages like Java/C# (with single inheritance) that heavily promote using inheritance (ie, virtual functions = overloading) to accomplish everything.. that's where people's confusion and problems stem from with OOP |
| 16:15:25 | coffeepot | by the way, how is your ECS coming along? Do you have a benchmark of number of entities to be processed that you're aiming for? |
| 16:15:51 | coffeepot | filwit: definitely, and I think I was one of those too |
| 16:16:06 | coffeepot | I think that's partly because there's no other way to do it in those langauges |
| 16:16:40 | coffeepot | it helps if your language has a good ability for compiletime evaluation too |
| 16:16:58 | filwit | it's coming along, and I've only done preliminary benchmarks (since my entire concept about ECS changed not long ago). I'm have a few goals that are somewhat difficult to explain in full over chat.. |
| 16:17:55 | coffeepot | I'm aiming for about a hundred thousand entities at a time. I don't think I'll get there with my current approach. At around 10,000 comfortably IIRC |
| 16:19:22 | coffeepot | I really need to sit down and work out how to leverage shaders to do some work for me though, I think you could probably get millions of entities running, depending on what they're doing of course |
| 16:19:25 | filwit | yeah I don't fully understand how your system is working... but doing a hash-table looking per-component doesn't sound fast :\ |
| 16:19:35 | coffeepot | it's not it's well slow! :D |
| 16:19:43 | coffeepot | it was more of an experiement really |
| 16:19:50 | Arrrrr | What are those 10k entities? |
| 16:20:02 | filwit | wait, how would you use shaders to do work for a ECS? |
| 16:20:13 | Araq | well it simulates how Python does it |
| 16:20:17 | coffeepot | also I was reading about how the ashley ECS works and thought I'd try it out. I should go back and read it again though |
| 16:20:51 | filwit | you can do skeletal animation via texture+shaders, but only because all data for that can exist on the GPU.. but and ECS needs to exist in system memory |
| 16:22:08 | coffeepot | Arrrrr: most of the 10k are particles, so no collision and only simple physics |
| 16:22:21 | filwit | Araq: who where you responding too? |
| 16:22:36 | Araq | coffeepot's hash tables |
| 16:22:43 | filwit | kk |
| 16:23:08 | coffeepot | filwit: well from what I've read you can do broadphase on the gpu, and simple physics stuff |
| 16:23:30 | Arrrrr | Do you need those particles to be entities? |
| 16:23:44 | coffeepot | nope :) |
| 16:23:53 | coffeepot | but hey it's a good performance test! |
| 16:24:16 | Arrrrr | mm |
| 16:24:19 | * | filcuc|2 quit (Read error: Connection reset by peer) |
| 16:24:36 | * | filcuc|2 joined #nim |
| 16:25:20 | filwit | coffeepot: either way, I don't think that's a good trade. [1] you'll use up very critical CPU->GPU bandwidth that [2] is going to be maxed out with new DX12/Vulkan APIs which will easily allow apps to be GPU bound, so keeping all ECS processing on the CPU is probably much easier and a net-gain in performance when all is said in done (depending on the application of course) |
| 16:25:31 | coffeepot | ideally I think particles should be on the gpu as they're not really interactive and simple physics in my case. However I've never written a shader so big learning curve |
| 16:26:01 | filwit | oh i see, you're talking about particles.. |
| 16:26:40 | coffeepot | filwit: I do agree with that, but hey why not both? :D |
| 16:27:03 | coffeepot | if the system can offload to a shader for particles yet you can code it as if it were an entity |
| 16:27:24 | filwit | yes, with particles and animation, since all data for those can exist in GPU mem with only higher level booking required for those systems (eg, this is is "playing this animation" or this particle spawner is "emiting since..", etc) then you can get a lot of gains doing it all on the GPU (so I've read) |
| 16:28:16 | filwit | I just saw an 8-mil OpenGL particle system posted the other day.. or was taht 8-bil... |
| 16:28:25 | filwit | (using GPU only processing) |
| 16:28:46 | coffeepot | nice :) |
| 16:28:55 | * | Arrrrr quit (Ping timeout: 240 seconds) |
| 16:29:01 | coffeepot | stuff like this: http://nullprogram.com/blog/2014/06/29/ |
| 16:29:06 | coffeepot | physics on the gpu |
| 16:29:26 | coffeepot | imo, having millions of particles in itself can lend itself to some awesome game ideas |
| 16:29:39 | filwit | nah, had to be million.. billion is insane.. |
| 16:30:01 | coffeepot | yeah don't think we'd reach a billion if only for memory! |
| 16:31:11 | filwit | coffeepot: you just reminded me of this: https://www.youtube.com/watch?v=ffgRC3kvA_k |
| 16:31:25 | filwit | pretty sure that's all GPU processing too |
| 16:31:37 | coffeepot | I'm thinking if I use actual composition instead of loading data components from a hash lookup (for EVERY entity operation) I could probably reach 100k no probs |
| 16:32:09 | coffeepot | oh wow, that's some tasty physics on that vid :) |
| 16:32:36 | coffeepot | nice. |
| 16:32:42 | filwit | coffeepot: yeah I was going to say before that I think just putting your components into objects would be faster than splitting them up and using a hash-table to access each one |
| 16:33:08 | coffeepot | holy crap yes |
| 16:33:13 | coffeepot | loads faster |
| 16:33:44 | coffeepot | there are some advantages with using an id system to look stuff up, but not really in nim where we have access to low level optimisations anyway |
| 16:35:04 | coffeepot | having said that, intsets are very fast |
| 16:35:53 | filwit | yeah the only reason to split things up is if you want the performance gains of placing things in continuous memory blocks.. and if you don't do that right it's probably slower and harder to work with overall... but again, I really don't know how your system works, so I'm not sure that's good advice :P |
| 16:36:26 | * | Arrrrr joined #nim |
| 16:36:44 | coffeepot | I use intsets for task/job lists for entities and hashtables for data, where the Data type in inherited. |
| 16:37:14 | coffeepot | yeah it started as an experiment and I just kinda had to finish it off as a matter of principle :) |
| 16:38:14 | coffeepot | in terms of optimisation it's the worst. Every entity operation needs to perform multiple hash lookups and then fetch data from all over the place. Often this happens repeatedly in the same entity operation (eg getting multiple components) |
| 16:38:20 | coffeepot | there is one advantage though... |
| 16:38:28 | coffeepot | I can add/remove data and tasks at runtime :) |
| 16:40:04 | coffeepot | it's still somehow fast enough to handle thousands of entities though! |
| 16:40:34 | filwit | yeah, power to native code on moder hardware :) |
| 16:40:42 | filwit | power *of* |
| 16:40:49 | coffeepot | yeah, quite! |
| 16:41:01 | coffeepot | and of choosing the right implementation, mind |
| 16:41:21 | filwit | btw, yu can add/remove components with continuous arrays too.. it's just how you do that is more complicated.. |
| 16:41:33 | coffeepot | when i was using hashtables to store the list of entities that needed updating for a task, it was REALLY slow. Intsets basically made it workable |
| 16:42:13 | coffeepot | continuous array? Of component objects? |
| 16:42:32 | filwit | I still don't know what you mean by using intsets for tasks/jobs, but I'm going to start working on other things now |
| 16:42:40 | filwit | yes, of component objects |
| 16:43:22 | filwit | i'd love to talk about this kind of thing all day, but I should do something more practical now |
| 16:46:15 | coffeepot | lol okay yeah I need to go soon anyway. What I meant was for each 'task' (collision detection, rendering, physics, etc), I make a list of all the entities that are registered. This was stored in a Table[EntityID, seq[Entity]]. Later I used a Table instead of the seq as I needed to quickly delete entities from the task list when they were killed. Th |
| 16:46:15 | coffeepot | is was really slow and adding/deleting entities became a huge bottleneck. So, I replaced the seq[Entity] with an IntSet, as the entity ID *is* the entity, and gained an order of magnitude speed up. |
| 16:46:39 | coffeepot | Yeah love talking about this too, catch you another, less practical, time :) |
| 16:47:38 | coffeepot | might try a seq[Data] though, could probably get another huge speedup from that rather than retrieving it from tables |
| 16:48:22 | filwit | sorry, brb |
| 16:48:34 | * | Arrrrrr joined #nim |
| 16:49:42 | * | Arrrrr quit (Ping timeout: 250 seconds) |
| 16:51:04 | filwit | coffeepot: i see. okay, ttyl |
| 16:53:25 | coffeepot | l8rs :) |
| 16:55:00 | * | avsej quit (Quit: Quit) |
| 16:57:26 | * | avsej joined #nim |
| 16:57:26 | * | avsej quit (Changing host) |
| 16:57:26 | * | avsej joined #nim |
| 17:04:46 | * | M-max quit (Quit: node-irc says goodbye) |
| 17:04:51 | * | xiaojun joined #nim |
| 17:06:19 | xiaojun | suggest:keyword let change to val, like scala |
| 17:07:33 | ephja | why? |
| 17:11:24 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 17:12:29 | * | xiaojun quit (Quit: Page closed) |
| 17:14:02 | * | gokr joined #nim |
| 17:20:55 | Arrrrrr | And how would be call val then? |
| 17:20:56 | * | filcuc|2 quit (Read error: Connection reset by peer) |
| 17:22:09 | Xe | what are the `->` and `=>` macros? |
| 17:22:52 | Arrrrrr | look into the future module, sugar for anon procs |
| 17:25:06 | Xe | mm |
| 17:25:09 | Xe | cool |
| 17:39:04 | ics | Is it possible to "rename" the fields in a tuple? sequtils.zip produces a tuple[a, b] I just can't find the right place to do a type conversion. let vs = (seq[tuple[x, y: float]])(zip(fooList, barList)) is invalid |
| 17:41:31 | Arrrrrr | mm, try 'let seq[tuple[x, y: float]] = zip(fooList, barList)' |
| 17:42:24 | ldlework | what |
| 17:43:35 | ics | Araq: type mismatch |
| 17:44:39 | ics | Error: type mismatch: got (seq[tuple[a: float, b: float]]) but expected 'seq[tuple[x: float, y: float]]' |
| 17:45:33 | Arrrrrr | it works with casting ... http://ideone.com/Twjew8 |
| 17:45:40 | Arrrrrr | I wouldn't recommend that anyway |
| 17:45:41 | ldlework | Of course it does |
| 17:45:58 | ldlework | tuple[x,y: int] and tuple[a,b: int] are two different types |
| 17:49:39 | Araq | use tuples without field names to gain compatibility |
| 17:52:59 | * | yglukhov quit (Ping timeout: 264 seconds) |
| 17:57:17 | * | ics mixed up names above |
| 17:57:52 | * | derka quit (Quit: derka) |
| 17:58:04 | ics | Hmm |
| 18:01:57 | ics | Araq: where do you mean? |
| 18:02:38 | ics | I'm not accessing the values directly |
| 18:03:06 | ics | Rather, I have a type alias like `type Coord = tuple[x, y: float]` |
| 18:05:46 | * | sjums joined #nim |
| 18:06:14 | ics | and the output type of my function is seq[Coord] which doesn't work because it returns the output of a zip |
| 18:06:29 | * | ics is thinking out loud |
| 18:06:37 | ldlework | Araq: maybe tuples would be a good place to start with regards to structural equivalancy or whatever you were talking about a couple days ago. |
| 18:08:09 | ics | I would expect the order of tuple values to matter (obviously) but the field names... well something nicer than cast |
| 18:10:08 | ics | (Until I read the part of the manual which says "The names of the fields also have to be identical.") :) |
| 18:10:53 | ldlework | hehe |
| 18:11:14 | * | hh_ joined #nim |
| 18:11:52 | * | hh_ quit (Client Quit) |
| 18:11:52 | * | sjums left #nim ("Leaving") |
| 18:12:57 | * | derka joined #nim |
| 18:15:42 | * | brson joined #nim |
| 18:15:44 | ics | proc zipFooey*[F,T](seq1: seq[T], seq2: seq[T]): F |
| 18:16:10 | ics | works with zipFooey[seq[Coord], float](listA, listB) |
| 18:17:08 | ics | I haven't really gone through the syntax for generics so maybe there's a better way to do or wrap that |
| 18:18:31 | ics | But hey, it compiles... |
| 18:18:31 | * | endragor quit (Remote host closed the connection) |
| 18:21:10 | * | endragor joined #nim |
| 18:32:06 | * | yglukhov joined #nim |
| 18:32:54 | * | yglukhov quit (Remote host closed the connection) |
| 18:34:59 | * | vendethiel joined #nim |
| 18:37:53 | * | endragor quit (Remote host closed the connection) |
| 18:41:01 | * | Matthias247 joined #nim |
| 18:41:21 | Araq | type Coord = (float, float) |
| 18:41:42 | Araq | if you don't give a fuck about tuple field names, don't use tuple field names |
| 18:42:16 | Araq | ldlework: that's already done. |
| 18:42:50 | Araq | and we used to ignore field names completely. the results were horrible |
| 18:43:19 | Araq | so now tuples without field names are compatible to tuples with names |
| 18:43:36 | Araq | but if both tuples have names, these need to be identical. |
| 18:46:11 | Araq | oh and sequtils.zip shouldn't return fields ... we need to change that |
| 18:46:39 | ics | That's what made me curious |
| 18:47:03 | ics | zip returning fields |
| 18:47:33 | * | endragor joined #nim |
| 18:53:16 | avsej | I'm doing 'nim c -r src/nimble install' and getting error "nimblepkg/nimscriptsupport.nim(8, 11) Error: cannot open 'compiler/ast'". What I did wrong? |
| 18:53:37 | ics | Oh, what went wrong with ignoring tuple field names? Seems bad for the general case but somewhat useful as a separate type... but I don't really know what I'm doing so... |
| 18:54:03 | ldlework | ics: `cast[]()` is how you explicitly ignore field names :) |
| 19:01:00 | ics | Idlework: Something between flipping off the compiler completely and ignoring field names could be nice though, esp. in the case of library functions like zip returning "plain" types |
| 19:01:20 | ics | maybe `sprinkleGlitter[tuple[x, y: float]]()` |
| 19:03:45 | * | yglukhov joined #nim |
| 19:06:14 | Araq | zip should just be fixed. |
| 19:06:27 | Araq | avsej: I wish I knew |
| 19:07:28 | avsej | Araq, nevermind, seems like my rpm does not install compiler/*.nim stuff. I have to upgrade specfile |
| 19:17:59 | * | Arrrrrr quit (Quit: WeeChat 1.2) |
| 19:18:26 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 19:18:27 | ics | Araq: Nice, so guessing `var namedTup: tuple[x, y: float] = zipReturn()` would work after? |
| 19:18:47 | Araq | yeah |
| 19:23:11 | * | ics Day 5 or so trying Nim; {.deprecated.} all my dumb wrapper functions today. |
| 19:27:52 | * | Varriount_ joined #nim |
| 19:27:52 | * | Varriount quit (Disconnected by services) |
| 19:28:19 | * | avsej quit (Quit: Quit) |
| 19:28:32 | * | yglukhov quit (Ping timeout: 276 seconds) |
| 19:31:50 | * | avsej joined #nim |
| 19:32:12 | * | avsej is now known as Guest48990 |
| 19:37:51 | * | endragor quit (Remote host closed the connection) |
| 19:38:28 | * | yglukhov joined #nim |
| 19:50:32 | Araq | lol, why? |
| 19:54:49 | * | g_ joined #nim |
| 19:55:12 | * | g_ is now known as Guest16325 |
| 19:57:06 | * | derka quit (Ping timeout: 240 seconds) |
| 19:58:50 | * | derka joined #nim |
| 20:02:50 | * | yglukhov quit (Read error: Connection reset by peer) |
| 20:05:47 | * | yglukhov joined #nim |
| 20:12:24 | ics | Araq: me? Most of them were for library stuff I didn't understand yet (like named tuples). |
| 20:13:23 | * | silven quit (Ping timeout: 264 seconds) |
| 20:13:58 | * | silven joined #nim |
| 20:16:03 | * | sheerun quit () |
| 20:16:45 | ics | Really liking Nim though... am not a developer, but the libraries are pretty easy to read, syntax is good, and the speed is great even with a very naive idea of what I want to accomplish. |
| 20:25:04 | * | sheerun joined #nim |
| 20:39:51 | * | Guest16325 quit (Quit: Page closed) |
| 20:41:50 | * | lqdc joined #nim |
| 20:53:04 | * | yglukhov quit (Remote host closed the connection) |
| 20:59:05 | Xe | is there a way to turn off the GC for a specific variable? |
| 21:00:23 | ephja | how is that different from manual memory management? |
| 21:03:14 | Xe | basically i have a pointer to memory from another garbage collected environment (Go) and I am getting a bus error sometimes when the Nim GC decides to free the Go allocated memory |
| 21:07:24 | ephja | by pointer you mean reference? |
| 21:08:04 | ephja | probably somewhere in the chain |
| 21:08:14 | ephja | you probably want to modify the reference count then instead |
| 21:08:35 | ephja | with GC_ref and GC_unref http://nim-lang.org/docs/system.html#GC_ref,ref.T |
| 21:18:04 | Xe | ephja: https://git.xeserv.us/xena/twtxtlist/src/master/src/time/gotime.nim#L3 |
| 21:19:55 | Xe | which is this function in Go |
| 21:19:58 | Xe | https://git.xeserv.us/xena/twtxtlist/src/master/src/time/time.go |
| 21:27:12 | * | gour quit (Quit: WeeChat 1.4) |
| 21:30:36 | * | Dildosan joined #nim |
| 21:39:03 | * | Dildosan quit (Remote host closed the connection) |
| 21:41:38 | * | Dildosan joined #nim |
| 21:44:20 | * | filcuc joined #nim |
| 21:44:56 | filcuc | is there a way for making an object from the GC not movable? |
| 21:46:12 | * | sheerun quit (Ping timeout: 272 seconds) |
| 21:47:08 | filcuc | if not, how can i safely pass a pointer to a nim object to C and be sure that the object is not moved from nim GC? |
| 22:07:34 | Varriount_ | filcuc: Uh, the GC doesn't move objects. |
| 22:08:05 | Varriount_ | filcuc: Or at least, the default GC doesn't. |
| 22:09:41 | ephja | Xe: you call GC_ref before passing in the pointer, so that the reference count doesn't reach 0, and then optionally call GC_unref when the pointer isn't used anymore |
| 22:10:12 | ephja | filcuc: I think that might be relevant to you. it was the last thing we discussed before you joined :p |
| 22:11:51 | * | desophos joined #nim |
| 22:12:22 | ephja | Xe: wait a second |
| 22:12:54 | ephja | I'm pretty sure that strings are copied before converted to cstring |
| 22:17:11 | Araq | 1. conversion to cstring doesn't copy. |
| 22:17:22 | Araq | 2. omg, use 'ptr' to interface with Go's memory. |
| 22:17:24 | Varriount_ | Strings and sequences are copied on assignment. cstring conversion isn't. |
| 22:17:45 | Xe | Araq: how would I use `ptr` here? |
| 22:17:46 | ephja | I just noticed that |
| 22:17:49 | * | Varriount_ is now known as Varriount |
| 22:18:07 | ephja | why not? wouldn't it be better to have to use cast? |
| 22:18:09 | filcuc | ephja: if still relevant it's a little different story |
| 22:18:28 | Varriount | ephja: What would your cast be? |
| 22:18:32 | filcuc | in my case i must ensure that object is not relocated by the GC |
| 22:18:46 | Varriount | filcuc: The GC doesn't relocate anything. |
| 22:18:49 | filcuc | this depends on the GC internals |
| 22:18:55 | ephja | cast[cstring](str[0].addr)? |
| 22:19:41 | Varriount | filcuc: The GC is a reference counting, *non-compacting* GC. |
| 22:19:50 | filcuc | Varriount: nice to know that, but it was not predictable |
| 22:19:51 | Araq | ephja: maybe, but the conversion is even implicit for convenience. |
| 22:20:15 | Varriount | filcuc: What do you mean by 'not predictable'? |
| 22:21:48 | ephja | and in case of compacting GC's? would you control that with a flag? |
| 22:22:14 | filcuc | Varriount: i mean that it's a detail on the GC. For example the D GC has a flag for marking a node not movable |
| 22:22:21 | filcuc | the same applies for C# |
| 22:22:39 | Varriount | ephja: As far as I know, there aren't any compacting GC's for Nim, mainly because the entire standard library relies on objects not being moved. |
| 22:22:48 | filcuc | basically i didn't how the nim GC works :P |
| 22:22:49 | ephja | filcuc: I assume it wouldn't become the default without warning |
| 22:22:57 | filcuc | know |
| 22:22:58 | ephja | and the GC can be chosen |
| 22:23:40 | ephja | Varriount: I was just thinking about potential implementations |
| 22:23:44 | Araq | Xe: *int64 becomes ptr int64 |
| 22:24:54 | ephja | I suppose it would add some overhead, but the solution in cases like this might be to simply wrap the pointer in a reference counted type |
| 22:25:05 | Varriount | ephja: Well, there aren't any current mechanisms for making an object pinned. Any GC that wants to be able to move objects around is going to have to do static analysis to determine which types are safe to move. |
| 22:25:22 | filcuc | in reality the D GC doesn't implement compacting yet :) but their API has already a function for the future :) |
| 22:25:43 | Varriount | Araq: What are your thoughts on this? |
| 22:26:11 | Araq | pinning a ref is the same as GC_ref/GC_unref |
| 22:26:31 | ephja | Varriount: yeah, that would be more convenient. unmovable whenever a pointer is passed to a foreign function then |
| 22:27:24 | filcuc | ephja: pinning can degrade GC performance (obviously depends on the implementation of the GC) |
| 22:28:05 | Araq | "As far as I know, there aren't any compacting GC's for Nim, mainly because the entire standard library relies on objects not being moved." |
| 22:28:45 | Araq | er no... there aren't any compacting GC's for Nim because these are hard to do when you want to generate C code |
| 22:28:55 | Araq | that also interfaces easily with C code. |
| 22:29:25 | ephja | reminds me of this argument "why not just use C then if it compiles to C" ;) |
| 22:29:45 | Araq | because C cannot even distinguish a pointer from an array? |
| 22:30:00 | Varriount | ephja: That's like saying "why not use assembly if that's what C compiles down to?" |
| 22:30:10 | ephja | Varriount: yeah |
| 22:30:43 | Varriount | Reasonable abstractions that simplify the mental model of programming is the main reason. |
| 22:32:08 | Araq | why not write LLVM bitcode if Nim compiles to LLVM. |
| 22:33:02 | ephja | I know, right? |
| 22:33:32 | Araq | why not write x86 instructions instead of Haskell. |
| 22:35:23 | filcuc | Araq: however adding a "manual" reference to an object it's different of saying "don't move it" |
| 22:35:37 | filcuc | [23:24] <Araq> pinning a ref is the same as GC_ref/GC_unref |
| 22:35:58 | Araq | I fail to see the difference. |
| 22:36:01 | ephja | gotta have monads |
| 22:41:35 | * | filcuc quit (Ping timeout: 264 seconds) |
| 22:49:46 | * | brson quit (Ping timeout: 250 seconds) |
| 22:54:06 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 22:55:16 | * | brson joined #nim |
| 22:56:30 | * | junw quit (Ping timeout: 272 seconds) |
| 23:03:40 | * | derka quit (Ping timeout: 260 seconds) |
| 23:03:57 | * | derka joined #nim |
| 23:05:26 | * | filcuc joined #nim |
| 23:06:48 | gokr | Araq: Hum, so c2nim turns "#define VM_THREAD_HANDLE VMUINT32" to "const VM_THREAD_HANDLE * VMUINT32" for some reason. And that fails later when used as a proc param type. |
| 23:07:10 | Araq | not for some reason. |
| 23:07:16 | Araq | it was designed to do that. |
| 23:07:45 | Araq | what do you think it should do? guess VUINT32 is a type? |
| 23:08:08 | Araq | replace the #define with typedesc to tell c2nim what it is |
| 23:08:16 | Araq | er *typedef |
| 23:09:04 | gokr | I presume it can't do anything else. |
| 23:10:33 | * | filcuc quit (Ping timeout: 240 seconds) |
| 23:14:18 | * | pregressive quit () |
| 23:14:20 | * | lankanmon_ joined #nim |
| 23:18:32 | * | junw joined #nim |
| 23:18:35 | * | lankanmon_ quit (Read error: Connection reset by peer) |
| 23:19:15 | Araq | gokr: didn't get any PR from you :-) |
| 23:19:29 | gokr | I know, I will. :) |
| 23:19:58 | gokr | I did do the same as dynlib - passing a name of the lib, although we are not using that. |
| 23:20:54 | * | junw_ joined #nim |
| 23:24:31 | * | junw quit (Ping timeout: 245 seconds) |
| 23:29:17 | gokr | Araq: done |
| 23:29:54 | * | Dildosan left #nim ("Leaving") |
| 23:36:38 | * | Trustable quit (Quit: Leaving) |
| 23:56:40 | * | francisl joined #nim |
| 23:59:31 | * | apotheon quit (Ping timeout: 245 seconds) |