| 00:03:37 | ldlework | Why can't I do "echo $j["key"]", I get type mismatch: got (proc (x: varargs[typed]){.gcsafe, locks: 0.}, JsonNode) |
| 00:04:14 | ldlework | If I use, "echo($settings["tileset"])" it works fine |
| 00:04:24 | ldlework | this is with the json module |
| 00:05:20 | * | M-Quora joined #nim |
| 00:09:00 | desophos | ldlework, the repl is `nim secret` |
| 00:09:21 | ldlework | ... why? |
| 00:09:29 | ldlework | heh |
| 00:11:08 | def- | ldlework: It's The Secret of NIM: http://www.imdb.com/title/tt0084649/ |
| 00:11:24 | ldlework | I see |
| 00:11:37 | ldlework | Does anyone knwo why I can't use the spaced call syntax with echo and the json macro? |
| 00:12:10 | def- | It gets parsed as `$`(echo, j["key"]) or something like that |
| 00:12:44 | def- | there's no need to use $ with echo anyway |
| 00:12:50 | def- | echo stringifies everything |
| 00:13:09 | ldlework | I changed over to the marhsal module anyhow |
| 00:13:29 | ldlework | def-: when unmarshalling a json object that has an attribute who's value is another json object |
| 00:13:38 | ldlework | is there some kind of generic type I can throw json objects into? |
| 00:13:40 | ldlework | like a Table? |
| 00:14:00 | def- | sure you can |
| 00:14:04 | ldlework | Or do I need to create types for everything? |
| 00:14:19 | def- | Json objects are a type already, so you can store them in a table or any other datastructure |
| 00:15:04 | ldlework | def-: when I specify my actual surface Nim type to have an attribute as Table[string, int] and I load a json object who's same attribute has an object like {"width": 20, "height": 20}, I get: unhandled exception: invalid field name: width [ValueError] |
| 00:15:54 | def- | I'm afraid I don't understand |
| 00:15:55 | ldlework | def-: I don't want to store it in a table |
| 00:16:04 | ldlework | I want to unmarshal a nested json object |
| 00:16:13 | ldlework | let me gist |
| 00:16:44 | ldlework | def-: https://gist.github.com/dustinlacewell/b244d818e22ef7053df9 |
| 00:17:42 | ldlework | raises a runtime exception because the Table[string, int] has no member "width" |
| 00:17:45 | ldlework | which makes sense to me |
| 00:18:08 | ldlework | but that also seems to indicate that I need to completely unmarshal this object into individual types and can't rely on a table or anything |
| 00:18:19 | def- | i see. so you want an automatic implementation of "to"? |
| 00:18:33 | ldlework | afterall, I guess a json object might have one string map to an int, and one string map to a string |
| 00:18:42 | ldlework | then what do? you can't have a table that does that. |
| 00:19:00 | def- | I don't think anything like that exists. you could do it manually or write a macro to automate it |
| 00:19:10 | ldlework | Well I don't think its possible |
| 00:19:17 | ldlework | You can't store an arbitrary json object into a table |
| 00:19:26 | ldlework | since table key-value types have to be homogenous |
| 00:19:41 | ldlework | but json objects don't have that restraint |
| 00:19:50 | ldlework | so I guess it was silly of me to ask |
| 00:24:04 | ldlework | aw |
| 00:24:08 | ldlework | I thought maybe a tuple would work |
| 00:24:27 | ldlework | since it has field names in its type description |
| 00:25:46 | ldlework | it really seems like a tuple ought to work |
| 00:27:59 | ldlework | yeah a full type works |
| 00:36:14 | * | yglukhov quit (Remote host closed the connection) |
| 00:43:40 | ldlework | def-: know what I mean |
| 00:45:28 | def- | nope |
| 00:45:46 | * | jaco60 quit (Ping timeout: 250 seconds) |
| 00:49:13 | ldlework | well okay I guess |
| 00:52:05 | dom96 | The marshal module generates some special JSON I think |
| 00:52:22 | dom96 | You can't just give it a JSON that you think matches your object definition and have it unmarshal it |
| 00:52:29 | dom96 | To parse json use the json module |
| 00:52:34 | ldlework | what |
| 00:52:40 | ldlework | I have a specific json structure |
| 00:52:50 | ldlework | if I create types that represent that json structure, marshal works fine |
| 00:53:06 | ldlework | my point was that you should be able to unmarshal to specific tuple types that also match your json structure |
| 00:53:29 | dom96 | The marshal module wasn't designed for that. |
| 00:53:35 | ldlework | IE, if I have a json structure {"width": 5, "height": 5}, I have to make a named type from object that has two int fields with those names |
| 00:53:39 | dom96 | The fact that it uses json is just an implementation detail |
| 00:53:49 | dom96 | You shouldn't rely on it |
| 00:53:51 | ldlework | Im not talking about json whatsoever |
| 00:53:55 | ldlework | I'm talking about the fact that |
| 00:54:05 | ldlework | a tuple can support exactly the same members as a named type |
| 00:54:50 | ldlework | and that if I unmarshal to a `type Rect = object width, height: int` it works, but not if I unmarshal to a `tuple[width, height: int]` |
| 00:55:23 | dom96 | What I am saying is that you shouldn't parse arbitrary JSON this way |
| 00:55:30 | ldlework | Its not arbitrary json whatsoever |
| 00:55:52 | ldlework | its static, structured known-ahead of time, designed exactly at the same time as this unmarshalling and the associated nim types |
| 00:56:41 | dom96 | hrm okay |
| 00:57:05 | dom96 | In any case, I need to head to sleep. Bye! |
| 00:59:30 | ldlework | I think it would have to do with the fact that tuples do not know their type at runtime |
| 00:59:54 | ldlework | But maybe I'm just crazy because no one seems to understand what I'm talking about :) |
| 01:34:23 | * | EastByte quit (Ping timeout: 250 seconds) |
| 01:36:00 | * | EastByte joined #nim |
| 01:56:11 | ldlework | Can someone remind me how to take a ref |
| 02:00:16 | ldlework | if I have a raw object type instance |
| 02:00:26 | ldlework | and I want to get a reference how can I do that? |
| 02:05:29 | ldlework | ah I see |
| 02:45:07 | * | pregressive joined #nim |
| 03:11:50 | * | brson joined #nim |
| 03:13:01 | * | ^aurora^ quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 03:43:33 | ldlework | BlaXpirit: any chance you've seen a csfml nim tilemap floating around? |
| 03:52:19 | * | darkf joined #nim |
| 03:53:53 | * | secretlives joined #nim |
| 03:55:13 | * | secretlives quit (Client Quit) |
| 04:47:55 | * | gsingh93 quit (Quit: ZNC - http://znc.in) |
| 04:48:35 | * | gsingh93 joined #nim |
| 05:02:01 | * | doxavore quit (Quit: I said good day, sir.) |
| 05:05:06 | * | vikaton joined #nim |
| 05:07:28 | * | secretlives joined #nim |
| 05:08:36 | * | secretlives quit (Client Quit) |
| 05:09:00 | * | joshuaturner joined #nim |
| 05:11:13 | ldlework | I have this file: https://gist.github.com/dustinlacewell/02ff87b43527de4a262c and I'm getting: app.nim(14, 9) Error: attempting to call undeclared routine: 't=' |
| 05:11:19 | ldlework | I don't understand how this is possible |
| 05:11:33 | ldlework | I have a member t on the type... |
| 05:15:19 | ldlework | oh 'ref object' |
| 05:15:20 | ldlework | :( |
| 05:19:18 | ldlework | How do you define a -> proc type that has no return value? |
| 05:20:23 | * | joshuaturner quit (Quit: Textual IRC Client: www.textualapp.com) |
| 05:22:30 | * | joshuaturner joined #nim |
| 05:24:24 | * | joshuaturner quit (Client Quit) |
| 05:30:11 | * | brson quit (Ping timeout: 264 seconds) |
| 05:39:02 | * | vendethiel joined #nim |
| 06:01:46 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 06:14:11 | * | desophos_ joined #nim |
| 06:18:43 | * | desophos_ quit (Ping timeout: 276 seconds) |
| 06:19:10 | * | nsf joined #nim |
| 06:35:43 | * | vendethiel joined #nim |
| 06:41:12 | * | Heartmender quit (Remote host closed the connection) |
| 06:42:00 | ldlework | this channel is so dead |
| 06:44:07 | reactormonk | You killed it. |
| 06:44:44 | ldlework | why?! |
| 06:45:24 | ldlework | reactormonk: nim frustrates me sometimes, like why does `run[GameState](app, state, handleFrame, handleEvents)` compile, but not `app.run[GameState](state, handleFrame, handleEvents)` ? |
| 06:48:04 | ldlework | is it the generics? |
| 06:48:36 | reactormonk | ldlework, what's theerror? |
| 06:48:55 | ldlework | type mismatch: got (App) |
| 06:48:58 | ldlework | but expected one of: |
| 06:49:00 | ldlework | application.run(app: App, state: T, frame_handler: proc (app: App, state: T){.closure.}, event_handler: proc (app: App, state: T, event: Event){.closure.}) |
| 06:49:07 | ldlework | No idea how `run` only got (App) |
| 06:49:29 | * | Heartmender joined #nim |
| 06:49:51 | * | Heartmender is now known as Guest34835 |
| 06:58:35 | ldlework | reactormonk: see what I mean? |
| 06:58:38 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 07:00:21 | reactormonk | yup |
| 07:06:16 | * | pregressive quit (Remote host closed the connection) |
| 07:10:04 | * | ludocode joined #nim |
| 07:32:20 | ldlework | reactormonk: any idea? |
| 07:38:07 | * | vikaton quit (Quit: Connection closed for inactivity) |
| 08:01:52 | * | vendethiel joined #nim |
| 08:10:09 | ldlework | BlaXpirit: is nim-csfml abandoned? |
| 08:12:24 | * | krux02 quit (Quit: Verlassend) |
| 08:15:14 | * | yglukhov joined #nim |
| 08:19:51 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 08:23:35 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 09:07:13 | BlaXpirit | ldlework, no tilemap |
| 09:07:31 | BlaXpirit | ldlework, my projects are never really abandoned, but this one is one of the closest to being abandoned |
| 09:07:46 | ldlework | BlaXpirit: because of the lack of cdata finalizer support? |
| 09:07:51 | BlaXpirit | i mean i'm gonna re-generate it for sfml 2.x |
| 09:07:55 | BlaXpirit | ldlework, yeah pretty much |
| 09:13:33 | * | coffeepot joined #nim |
| 09:18:39 | * | ^aurora^ joined #nim |
| 09:20:08 | * | BlaXpirit left #nim ("Bye") |
| 09:20:11 | * | BlaXpirit joined #nim |
| 09:24:38 | * | yglukhov joined #nim |
| 09:36:26 | * | Trustable joined #nim |
| 09:51:00 | * | jaco60 joined #nim |
| 10:06:17 | dom96 | ldlework> [05:19:18] How do you define a -> proc type that has no return value? |
| 10:06:19 | dom96 | use 'void' |
| 10:06:51 | dom96 | As for your other issue, that's a common gotcha. |
| 10:09:42 | ldlework | dom96: thanks |
| 10:09:56 | ldlework | dom96: so that syntax thing is just a bug in nim? |
| 10:10:15 | dom96 | Not sure if it's a bug. |
| 10:10:35 | dom96 | I have a feeling it might not be, but can't remember the reason for it. |
| 10:10:40 | ldlework | dom96: I go around telling people about how Nim has nice features, but how its like C# and "they all work together too" |
| 10:10:43 | ldlework | lol |
| 10:13:09 | dom96 | https://github.com/nim-lang/Nim/issues/1782 |
| 10:13:42 | ldlework | O_O |
| 10:13:57 | dom96 | and documentation https://github.com/nim-lang/Nim/commit/bbe4afc49bcab87cf6abda4fedb49e1010e29b12 |
| 10:14:49 | dom96 | Hopefully p[.T.] won't be the syntax though. |
| 10:15:04 | ldlework | seriously |
| 10:15:06 | ldlework | lol |
| 10:15:12 | ldlework | ugh that sucks |
| 10:15:43 | dom96 | It's not so bad. |
| 10:19:54 | * | zepolen joined #nim |
| 10:20:02 | * | desophos quit (Read error: Connection reset by peer) |
| 10:22:08 | ldlework | dom96: its just nice when things fall together, not apart is all |
| 10:23:30 | dom96 | ldlework: I understand. But keep in mind that Nim is still pre-1.0, some things are not necessarily 100% polished (yet). |
| 10:23:54 | ldlework | dom96: sure but that doesn't seem like the kind of thing that gets smoothed out right? |
| 10:24:16 | ldlework | like that gotcha is always gonna be there, or the syntax for generics will be made more ugly all around |
| 10:24:50 | ldlework | there's no result where dot call syntax just works for the standard for generics type passing |
| 10:24:57 | ldlework | syntax |
| 10:26:16 | federico3 | a lot of code listed in packages.json is rotting. Given that there are frequent changes to the compiler that break backward compatibility maybe packages should be required to run travisCI |
| 10:27:32 | ldlework | or the compiler should be versioned, packages checked against versions of the compiler they are known good for, and maintainers must update their compatibility status as the language makes releases? |
| 10:28:46 | dom96 | ldlework: Unfortunately it's looking that way. I am hoping that whatever Araq decides will be nicer than [.T.] though. Maybe he will even figure out a way to keep the current syntax, which I am fighting for in https://github.com/nim-lang/Nim/issues/3502 |
| 10:29:20 | dom96 | federico3: that sounds like a lot to put on package creators. |
| 10:30:03 | federico3 | dumping a standard .travis.yml template in the project dir? |
| 10:30:42 | ldlework | people have insane syntax intuitions I swear |
| 10:30:46 | dom96 | What we need is a central repository of packages which tests each package against any new version of Nim. It can then report each package's compatibility. |
| 10:31:20 | ldlework | that requires authors to maintain tests for packages |
| 10:31:36 | dom96 | and travis doesn't? |
| 10:31:44 | ldlework | it seems far more relevant to tie packages to known compatible versions of the compiler, and to break those compatibilites when it changes |
| 10:32:00 | ldlework | any method which requires authors to write and maintain tests is going to be useless |
| 10:32:02 | dom96 | federico3: It's not that simple. |
| 10:32:14 | dom96 | ldlework: Agreed. |
| 10:33:17 | dom96 | But in reality package creators will not test their packages after every version of Nim is released, and change the version requirements appropriately. |
| 10:34:55 | federico3 | it would be nice to automatically build when a new version is released - however, new versions are not released every month so updating is not a big effort |
| 10:35:13 | ldlework | no |
| 10:35:18 | ldlework | they wont |
| 10:35:40 | ldlework | but that is what you want |
| 10:35:50 | ldlework | the fact is, the author isn't updating broken software |
| 10:35:59 | ldlework | so the best thing to do is say "this shit isn't compatible sorry" |
| 10:35:59 | federico3 | if the upstream doesn't bother updating - that's ok, and the package can be simply removed from packages.json or flagged as broken |
| 10:36:11 | ldlework | and then users track down packagae maintainers or fork the package |
| 10:36:15 | ldlework | this is healthy |
| 10:36:35 | ldlework | federico3: agreed |
| 10:36:43 | federico3 | anything better than having an amount of unusable packages in nimble |
| 10:37:06 | ldlework | right, its the burn when you think a package is available but it isn't |
| 10:37:16 | ldlework | I'd rather too many packages deemed unsuable and hidden from me |
| 10:37:28 | ldlework | than too many presented to me and then don't work at all |
| 10:37:36 | federico3 | ldlework: the burn, and the fact that the percentage of broken packages can only increase over time without a cleanup mechanism |
| 10:37:38 | dom96 | What would be nice is something similar to AUR's flagging. |
| 10:37:47 | dom96 | But for that we need a central package website. |
| 10:37:52 | ldlework | Sure, a social system would be best |
| 10:38:07 | ldlework | But I think the one I described is that one |
| 10:38:21 | ldlework | (tracking down maintainers, or forking by new maintainers) |
| 10:38:28 | * | Demon_Fox quit (Quit: Leaving) |
| 10:38:48 | ldlework | Also you could do a thing where |
| 10:38:56 | ldlework | packages get three strikes |
| 10:39:08 | Araq_ | IMO we should use [.T.] and make editors render these as nice Unicode brackets |
| 10:39:29 | Araq_ | I'm tired of living with ascii. |
| 10:39:31 | ldlework | I hate when my editor does stupid things |
| 10:39:44 | ldlework | especially finicky things when I'm typing |
| 10:39:46 | Araq_ | sexy is not stupid. |
| 10:39:53 | federico3 | ldlework: what would count as one strike? |
| 10:40:08 | ldlework | federico3: I mean, how many versions you can go before not even being included anymore |
| 10:40:17 | ldlework | before that the compiler would go "hey this package may or may not work!" |
| 10:40:20 | * | ^aurora^ quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 10:40:20 | ldlework | and try to use it |
| 10:40:25 | ldlework | and maybe work or maybe fail |
| 10:40:41 | ldlework | but after 3 or so versions, its automatically culled |
| 10:41:07 | Araq_ | before a new release we simply have to test every nimble package |
| 10:41:15 | ldlework | that's just not gonna happen |
| 10:41:23 | ldlework | and certainly not scalable |
| 10:41:31 | Araq_ | and once there are too many of them, mark important ones to test |
| 10:41:31 | federico3 | ldlework: adding a "broken" tag might be done if the last Nim release is broken (it's what matters after all). Later on, maybe, pkgs can be completely removed if they are broker for N months |
| 10:42:22 | dom96 | federico3: ldlework: the beauty of Nimble's package lists is that you guys are more than welcome to create your own and federate them as you wish :) |
| 10:42:41 | dom96 | In fact that would be pretty cool. A package list of known working packages. |
| 10:42:56 | federico3 | I'm not sure a travisCI test can run one big job to build many packages - it might time out maybe? |
| 10:44:18 | federico3 | ldlework: the number of packages is still small and the build is quick - a big "build-everything" job could be doable |
| 10:44:45 | ldlework | that's basically the wrong attitude to have though |
| 10:44:53 | federico3 | why? |
| 10:44:58 | ldlework | its like saying |
| 10:45:19 | ldlework | "oh well, we should design for 200 users because we have 100 now and that'll last us" |
| 10:45:27 | ldlework | is basically assuming your own lack of success |
| 10:45:29 | dom96 | Araq_: I still dislike the [.T.] idea. That said, I know why you want it, it's consistent with pragma syntax which is nice. |
| 10:45:45 | ldlework | but isn't nearly as rare as pragma |
| 10:45:53 | ldlework | if anything drop set constructors |
| 10:46:01 | ldlework | I mean really |
| 10:46:35 | dom96 | federico3: Something is better than nothing, if you want to create a travis build which tests all packages then go for it! |
| 10:46:51 | ldlework | true |
| 10:46:54 | federico3 | ldlework: pretty much yes. There will be time to stop doing build-everything when the number of pkgs will reach big numbers |
| 10:48:17 | federico3 | or it could be the other way around: *if* the upstream bothers to create a Travis test and keep it up to date and the build is successful the package will get a special tag "ready" |
| 10:48:40 | ldlework | here you go |
| 10:48:51 | ldlework | that's how it is generally done actually come to think of it |
| 10:48:52 | ldlework | good job |
| 10:49:04 | dom96 | maybe you could even grab a free heroku instance and use it |
| 10:49:06 | federico3 | sorry, generally done... where? :) |
| 10:49:18 | Araq_ | ldlework: set constructors do not even bite with Foo{T} |
| 10:49:25 | Araq_ | only {} accessors do. |
| 10:49:42 | ldlework | I have no idea what {} accessors are |
| 10:50:00 | ldlework | but damn, we should pretty much prioriztize generics |
| 10:50:02 | dom96 | jsonNode{"foo"} doesn't crash if "foo" doesn't exist |
| 10:50:06 | ldlework | since they are one of the more important features |
| 10:50:07 | dom96 | jsonNode["foo"] does |
| 10:50:09 | dom96 | or something like that |
| 10:50:25 | ldlework | I use generics all throughout my Nim code |
| 10:50:27 | ldlework | its everywhere |
| 10:50:31 | dom96 | In this case I agree. Drop {} accessors and use {T} for generics. |
| 10:50:36 | ldlework | I would be sad if there were 80% more periods in my code |
| 10:51:04 | Araq_ | well I don't feel like repeating the discussion again. it's all on github for you to read. |
| 10:51:09 | ldlework | I read it |
| 10:51:19 | Araq_ | ok then again |
| 10:51:20 | dom96 | That discussion isn't resolved :) |
| 10:51:23 | ldlework | I did minutes ago |
| 10:51:33 | Araq_ | generics are very common. |
| 10:51:40 | ldlework | agreed |
| 10:52:03 | Araq_ | but the problem is rare because TypeFoo[T] always works |
| 10:52:12 | Araq_ | and f(x, y) infers the T |
| 10:52:15 | * | dom96 thinks that NimBot should post links to IRC logs in Github issues when it detects that a Github issue is mentioned in this channel. |
| 10:52:26 | Araq_ | so f[T](x, y) is not common. |
| 10:52:38 | Araq_ | and if inference doesn't work you're free to use typedesc instead |
| 10:52:44 | ldlework | its x.f[T](y) that is the problem |
| 10:52:56 | Araq_ | yeah, I know, I simplified the examples |
| 10:53:03 | ldlework | its a syntax that works everywhere, but there |
| 10:53:12 | ldlework | whatever the reasoning or justifications, its a wart |
| 10:53:14 | ldlework | that's all |
| 10:53:21 | ldlework | doesn't stop anyone from writing good software |
| 10:53:37 | Araq_ | it's a gotcha, no doubt. |
| 10:54:07 | ldlework | if syntax and grammar should be anything, its regular |
| 10:54:20 | Araq_ | the problem is that it IS regular. |
| 10:54:24 | Araq_ | too regular. |
| 10:54:41 | Araq_ | [] is always parsed as array indexing here |
| 10:54:59 | dom96 | Araq_: In the issue you imply that you want [.T.], is this still your plan? As in you have already decided that you will implement it this way? |
| 10:54:59 | Araq_ | and x.a[i](x, y) works |
| 10:55:05 | ldlework | you would characterize it as regular if it wasn't self-contradictory |
| 10:55:27 | Araq_ | ldlework: it's regular since there is no special casing for it in the parser. |
| 10:55:57 | Araq_ | and let's not fight over words here. that's unproductive. |
| 10:56:12 | ldlework | Its that parts of the grammar overlap in form |
| 10:56:27 | Araq_ | it's a gotcha that arouse naturally, we didn't dream up the feature to annoy you. |
| 10:56:34 | ldlework | of course not |
| 10:56:43 | Araq_ | ok |
| 10:56:43 | ldlework | I don't feel that wa |
| 10:57:47 | Araq_ | dom96: no, my current plan is to disambiguate better in the semcheck |
| 10:57:56 | Araq_ | so it will just work (tm) for end users. |
| 10:58:01 | dom96 | Araq_: great |
| 10:58:05 | Araq_ | but it's the wrong fix. |
| 10:58:12 | dom96 | Araq_: That makes me happy |
| 10:58:19 | Araq_ | and only done for "political" reasons :P |
| 10:58:25 | dom96 | Good. |
| 10:58:29 | ldlework | amazing |
| 10:58:40 | dom96 | That's how you design for popularity anyway :P |
| 10:58:45 | Araq_ | and it might not work at all, haven't looked at what it will take in the compiler |
| 10:59:59 | dom96 | it's easy: if isType(node): generic else: array ;) |
| 11:00:24 | Araq_ | maybe. |
| 11:01:59 | dom96 | Araq_: bit.ly/1tcPwvt ;) |
| 11:02:42 | Araq_ | sometimes you need to consider that I'm not as much of a nerd as you may think. |
| 11:03:05 | Araq_ | in other words, I have no clue what that means. |
| 11:03:21 | dom96 | hah |
| 11:03:26 | dom96 | You need to look at more memes. |
| 11:06:13 | dom96 | federico3: Any ideas about making this compatible with all Linux's? https://github.com/nim-lang/Nim/pull/3648 |
| 11:10:55 | federico3 | dom96: you mean kernels before 3.9? The feature is simply not implemented there, we can only detect the version at compile time and enable the option accordingly |
| 11:11:37 | dom96 | federico3: yes, so compilation will fail on kernels before 3.9 won't it? |
| 11:12:02 | dom96 | So a define which enables SO_REUSEPORT is the only option? |
| 11:12:35 | federico3 | (this wouldn't be the only option that depends on a given kernel version I suppose) |
| 11:13:28 | federico3 | well, I can tell that SO_REUSEPORT would not be defined in an older kernel, what would Nim do? fail to compile or something else? |
| 11:15:44 | ldlework | Araq_: in sdl2, what is the base type for events? I can't seem to tell looking at sdl2.nim |
| 11:16:26 | ldlework | is it just EventType? |
| 11:16:52 | ldlework | oh just Event |
| 11:22:02 | niv | hi! is it possible to use asyncnet w/ udp sockets? |
| 11:29:05 | ldlework | why do I get this error? https://gist.github.com/dustinlacewell/1139b8bab5f7835c3d5b |
| 11:29:13 | ldlework | why do I have to manually cast? |
| 11:32:33 | ldlework | dom96: shouldn't literals be one of the main things the compiler can cast for me? |
| 11:33:56 | dom96 | niv: not right now. Should be fairly easy to implement, maybe you'd be interested in implementing it? :) |
| 11:34:18 | dom96 | ldlework: Nim is pretty strict with int casting |
| 11:34:18 | niv | maybe! i was just asking if there's a reason, apart from udp already being async/stateless |
| 11:34:37 | dom96 | niv: Nah, just didn't get a chance to implement it. |
| 11:34:38 | ldlework | dom96: sure but casting literals seems totally superflous? |
| 11:35:21 | dom96 | I'm sure Araq_ has a reason for it |
| 11:36:10 | niv | dom96: thanks! more annoying questions: is system.locals() newer than nim 0.12.0? ("cannot find plugin locals") |
| 11:36:46 | ldlework | dom96: the strange thing, in Araq_'s own example code, he doesn't need to specify the types |
| 11:36:56 | ldlework | https://github.com/nim-lang/sdl2/blob/master/examples/sdl_skeleton.nim#L10 |
| 11:37:18 | dom96 | niv: it's not, sounds like your stdlib and compiler versions don't match. |
| 11:37:32 | niv | odd. |
| 11:37:38 | ldlework | my line is basically the same line |
| 11:37:47 | dom96 | niv: have you got multiple installations of Nim maybe? |
| 11:38:02 | niv | no. just installed 0.12.0 from homebrew. nim -v says so too |
| 11:39:14 | dom96 | niv: hrm, you might want to clone the Nim repo, compile and install it yourself (by adding Nim to your PATH) |
| 11:39:21 | dom96 | I know there are some issues with homebrew |
| 11:39:24 | ldlework | Araq_: why is the compiler forcing me to add type annotations when your example code does not have such annotations? |
| 11:39:40 | niv | will do, i guess. thanks. |
| 11:39:56 | * | octoploid left #nim ("WeeChat 1.3-rc1") |
| 11:40:47 | ldlework | oh well.. |
| 11:40:57 | * | ldlework types cint a bunch of times |
| 11:41:20 | ldlework | like I want to do "while pollEvent(event):" |
| 11:42:03 | ldlework | but I have to do "while bool pollEvent(event):" because pollEvent returns a Bool64 |
| 11:42:05 | ldlework | this just seems wrong |
| 11:44:41 | dom96 | that sounds like the fault of the library, not Nim's |
| 11:45:14 | ldlework | dom96: what do you mean? also why is Araq_'s example code that uses this lib not using type annotations but I'm forced to when using the same lib? |
| 11:45:52 | ldlework | I can compile Araq_'s example code |
| 11:51:05 | ldlework | also, do you understand this error? https://gist.github.com/dustinlacewell/8a5b184f9b08434c6e35 |
| 11:51:40 | ldlework | I don't understand what's wrong with this |
| 11:51:51 | ldlework | It says it expects exactly what it got. |
| 11:52:28 | ldlework | bleh |
| 11:52:30 | coffeepot | is something expecting var? |
| 11:52:43 | ldlework | oh |
| 11:52:52 | ldlework | I see what happened, forgot to change csfml to sdl2 |
| 11:52:56 | ldlework | wrong Event type |
| 11:53:20 | coffeepot | i wish the error messages outputted the var state when they disagree, it's so confusing seeing the same list of parameters being 'incompatible' |
| 11:53:28 | ldlework | nice I'm compiled |
| 11:53:47 | ldlework | still don't know why I have to give so many type annotations |
| 11:56:57 | ldlework | well |
| 11:57:02 | ldlework | writing a converter fixed that |
| 12:12:21 | * | gokr joined #nim |
| 12:17:16 | * | aziz quit (Remote host closed the connection) |
| 12:25:14 | * | zepolen quit (Remote host closed the connection) |
| 12:28:52 | * | zepolen joined #nim |
| 12:41:23 | * | zepolen quit (Remote host closed the connection) |
| 12:42:43 | niv | dom96: installed nim from the official dist, same error when attempting to use locals() |
| 12:51:12 | dom96 | niv: how did you install it? |
| 12:51:22 | dom96 | in any case, please report the issue on github |
| 12:52:14 | niv | download zip, build.sh, install.sh /opt, try to compile "echo locals()" |
| 12:56:59 | niv | completely different question: is there a LRU cache library? |
| 12:58:33 | dom96 | niv: Don't use 'install.sh', add the directory to your PATH. |
| 12:59:17 | dom96 | Nim doesn't like being installed into /opt |
| 12:59:25 | niv | yay |
| 12:59:45 | niv | same issue though |
| 13:00:04 | niv | nim-0.12.0 → pwd |
| 13:00:04 | niv | nim-0.12.0 → ./bin/nim c local.nim |
| 13:00:04 | niv | local.nim(1, 7) Error: cannot find plugin locals |
| 13:00:31 | dom96 | Alright, issue on Github please! |
| 13:00:46 | dom96 | I bet the zip doesn't contain the plugin, or something. |
| 13:01:05 | dom96 | It most definitely should not happen on devel. |
| 13:01:54 | dom96 | It doesn't on my machine at least, but I only copied the example code |
| 13:03:57 | niv | made a cheapskate issue |
| 13:05:59 | dom96 | good enough, thanks. |
| 13:06:20 | niv | no, no, thank YOU ;) |
| 13:21:11 | dom96 | :) |
| 13:26:02 | * | zepolen joined #nim |
| 13:27:12 | dom96 | Interesting. My uni is organising a FOSS event in Belfast. |
| 13:31:37 | * | aziz joined #nim |
| 13:42:52 | federico3 | nice |
| 13:43:18 | coffeepot | dom96, what do you study? |
| 13:58:40 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 14:01:40 | dom96 | coffeepot: computer science |
| 14:13:33 | * | BitPuffin joined #nim |
| 14:14:40 | * | zepolen quit (Remote host closed the connection) |
| 14:45:21 | * | zepolen joined #nim |
| 14:49:55 | * | coffeepot joined #nim |
| 14:57:29 | * | Trustable quit (Read error: Connection reset by peer) |
| 14:57:58 | * | Trustable joined #nim |
| 15:19:02 | niv | whats the canocical way to only include some code when compiling as debug/release? |
| 15:20:10 | niv | found it! |
| 15:20:56 | * | ray- quit (Changing host) |
| 15:20:56 | * | ray- joined #nim |
| 15:20:57 | * | ray- is now known as \u |
| 15:21:36 | * | thotypous quit (Quit: WeeChat 1.3) |
| 15:28:22 | * | asterite left #nim ("Leaving...") |
| 15:30:21 | * | Jesin quit (Quit: Leaving) |
| 15:48:43 | * | pregressive joined #nim |
| 16:01:03 | * | joshuaturner joined #nim |
| 16:10:27 | * | Jesin joined #nim |
| 16:16:02 | * | joshuaturner quit (Quit: Textual IRC Client: www.textualapp.com) |
| 16:20:25 | nsf | may I ask what bindSym exactly does? there is a description, but it uses compiler terms like bound/unbound symbol, which is not documented btw what it means |
| 16:20:38 | nsf | does it use the scope where it was declared and resolves the symbol right away? |
| 16:20:56 | nsf | or since it is used in macros usually, does it happen on macro expansion site? |
| 16:21:46 | nsf | sorry bound/unbound identifier |
| 16:22:11 | nsf | as far as I understand, bound identifier - resolved identifier, unbound identifier - unresolved identifier :) |
| 16:22:18 | nsf | correct? |
| 16:22:44 | Araq_ | correct. |
| 16:22:53 | Araq_ | and it is the manual under lookup rules for templates |
| 16:23:18 | Araq_ | which really should be "general lookup rules" since generics work similarily |
| 16:27:09 | nsf | I see, thanks |
| 16:28:48 | nsf | Araq_: what do you think about C++'s argument dependent lookup rules? do you know what it is? |
| 16:29:06 | nsf | rule* |
| 16:30:14 | nsf | I was just thinking if I expand a function by fancy AST preprocessing macro and I want to substitute certain actions with functions possibly user-defined |
| 16:30:27 | nsf | in C++ there is a cool feature that is used often for that purpose |
| 16:30:45 | nsf | in nim I guess I'll have to ask users to import relevant symbols into the scope |
| 16:30:54 | nsf | maybe that's even a better approach, that's why I'm asking |
| 16:31:38 | nsf | the idea is when you call a function with an argument, the function is looked up in the scope where the type of an argument was defined |
| 16:32:01 | nsf | also since nim uses method calls form as a syntax feature, could be useful there too |
| 16:32:37 | nsf | i.e. exporting a type implicitly exports its methods |
| 16:32:45 | nsf | hm, oh, yes, I guess it's a bad idea here |
| 16:32:54 | nsf | what to do with private methods |
| 16:32:57 | nsf | never mind |
| 16:32:59 | nsf | won't work in nim |
| 16:36:38 | Araq_ | I know about C++'s ADL |
| 16:36:44 | Araq_ | and compared it against Nim's. |
| 16:36:57 | Araq_ | and the conclusion was: Sometimes C++'s way is better, sometimes Nim's. |
| 16:37:18 | Araq_ | and afaik Nim offers a lot more control over what happens. |
| 16:37:45 | Araq_ | plus of course Nim's way works better with AST macros |
| 16:37:55 | Araq_ | I think. Interesting topic. |
| 16:38:28 | nsf | Ok, I see |
| 16:47:00 | * | ^aurora^ joined #nim |
| 17:08:42 | * | mat4 joined #nim |
| 17:22:14 | * | joshuaturner joined #nim |
| 17:24:02 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 17:31:29 | * | yglukhov quit (Ping timeout: 276 seconds) |
| 17:43:13 | nsf | you know what would be cool, a printer which prints AST into function calls which do build the same AST |
| 17:43:48 | nsf | or maybe there is such thing? I am aware only about AST printer and the one which prints it to actual syntax |
| 17:43:58 | * | Jesin quit (Quit: Leaving) |
| 17:45:22 | nsf | http://pastie.org/10678098 |
| 17:45:25 | nsf | something like that :) |
| 17:45:34 | nsf | will help writing code definitely |
| 17:45:54 | nsf | or perhaps we should be able to just write nim code and parse it at compile time into nodes |
| 17:45:56 | nsf | hm |
| 17:46:05 | nsf | which we can do via macros I guess |
| 17:46:11 | nsf | uh, meta is so meta |
| 17:49:07 | nsf | also may I ask what the second parameter to newNimNode? I tried looking deep into the code, seems like it's used for text position reporting, is it correct? is there a guideline how it should be used? |
| 17:49:24 | nsf | https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncdispatch.nim#L1337-L1349 |
| 17:49:39 | nsf | for example in a code chunk like this, the "node" is used in newNimNode sometimes, and sometimes it doesn't |
| 17:49:48 | nsf | sorry, isn't |
| 17:50:40 | nsf | my brain fails to recognize a pattern, is it arbitrary? |
| 17:52:16 | dom96 | nsf: I believe that's the "original node", i.e. the AST node which you are transforming |
| 17:52:21 | dom96 | It's used for error messages |
| 17:52:49 | dom96 | And yeah, you should just use parseStmt or quote or a template + getAst |
| 17:52:54 | dom96 | gotta go bbl |
| 17:53:26 | nsf | yeah, okay, I understand that it is used for error reporting, but where should I use it is the question |
| 17:53:42 | nsf | for example I convert "return X" to a bunch of statements, should I use that node in all of them? |
| 17:53:45 | nsf | or maybe the top one |
| 17:54:00 | nsf | is it fair to say that it acts similar to #line? |
| 17:54:11 | nsf | (i.e. preprocessor directive in C) |
| 17:54:40 | nsf | or will the child node use the location of a parent node? |
| 17:54:52 | nsf | (in case if it doesn't have its own) |
| 17:55:45 | * | brson joined #nim |
| 18:00:29 | nsf | now if you apply that node to all for error reporting purposes, would be cool if parseStmt and parseExpr had an additional NimNode argument |
| 18:00:34 | nsf | for that same purpose |
| 18:04:00 | nsf | the printer I was describing would be useful anyway though in case if you want to replace a node or two |
| 18:04:04 | nsf | with maybe bound symbols or what not |
| 18:04:38 | * | aziz quit (Ping timeout: 255 seconds) |
| 18:05:05 | * | zepolen quit (Remote host closed the connection) |
| 18:06:37 | mat4 | I'm thinking at moment about a language environment based upon the identity between code and data (like Lisp's S-expressions) and a syntax and semantic like Nim |
| 18:06:58 | mat4 | something like a Nim interpreter without the compiler |
| 18:07:47 | * | yglukhov joined #nim |
| 18:09:50 | reactormonk | mat4, like nims? ^^ |
| 18:12:17 | * | yglukhov quit (Ping timeout: 255 seconds) |
| 18:12:33 | mat4 | yes. However simplifying self-modificating code, dynamic source-code rewriting (or creation) and other Lisp like standards |
| 18:13:51 | mat4 | .. even optional JIT compilation if I think about it |
| 18:14:14 | * | vendethiel joined #nim |
| 18:14:54 | * | brson_ joined #nim |
| 18:16:26 | * | brson quit (Ping timeout: 240 seconds) |
| 18:17:23 | * | desophos joined #nim |
| 18:18:34 | mat4 | as there is always a drawback (or more than one): I think that's not efficient implementable with a strict type system |
| 18:18:58 | mat4 | also an effect system would be near impossible to implement |
| 18:31:00 | reactormonk | mat4, to different from the way nim works atm. |
| 18:39:52 | mat4 | agree |
| 18:47:43 | * | yglukhov joined #nim |
| 18:58:38 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 19:11:20 | * | Skyforce77 joined #nim |
| 19:11:32 | Skyforce77 | Hi! |
| 19:11:41 | * | darkf quit (Quit: Leaving) |
| 19:11:48 | mat4 | hello |
| 19:13:58 | Skyforce77 | Is --os:standalone officially supported? I have some diffuculties using it (Segmentation fault). I tried removing garbage collector without success |
| 19:14:55 | Araq_ | Skyforce77: we have it in our test suite |
| 19:15:05 | Araq_ | but you need to use --os:standalone --gc:none |
| 19:15:17 | Araq_ | otherwise the GC uses a never tested "no OS" mode |
| 19:17:53 | mat4 | does this mean that the garbage collecting routine implement its own memory manager or how is memory access managed ? |
| 19:20:32 | Skyforce77 | "Error: system module needs 'newSeq'" So, newSeq can't be used without garbage collector? |
| 19:29:41 | * | ^aurora^ quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 19:33:28 | mat4 | I remember that --os:standalone depend on a minimal base library which must be implemented to be usable. Maybe 'newSeq' is part of that necessary |
| 19:35:43 | mat4 | take a look at the Nim kernel example (from dom96?) for example code |
| 19:39:02 | Skyforce77 | I have to create a Nintendo 3ds compatibility for my virtual machine written in nim. I made a ctrulib wrapper, but I think it will be really long to update my vm to remove seq :/ |
| 19:40:30 | Araq_ | Skyforce77: no, you can re-implement newSeq for your code |
| 19:40:39 | Araq_ | but it's a bit tricky to do that |
| 19:41:05 | Araq_ | however |
| 19:41:27 | Araq_ | --os:standalone with --gc:refc is supported for exactly this reason |
| 19:41:43 | Araq_ | so you only need to implement a memory manager and not a GC. |
| 19:41:54 | Araq_ | well "supported" in quotes because nobody did that yet. |
| 19:41:58 | Araq_ | but that's the idea. |
| 19:42:53 | Skyforce77 | Okay, I will try to find what are the functions to implement x') |
| 19:43:05 | Araq_ | so what are you programming? |
| 19:43:25 | Araq_ | one problem is that --os:standalone is highly ambiguous |
| 19:43:44 | Araq_ | what's the target CPU? The amount of memory? |
| 19:46:13 | mat4 | reads like a firmware or emulator for the Nintendo 3ds |
| 19:47:23 | Skyforce77 | Hardware used (arm9 processor): https://3dbrew.org/wiki/Hardware |
| 19:48:25 | Skyforce77 | I want to compile nim to c then compile to 3ds application |
| 19:52:10 | * | Demon_Fox joined #nim |
| 19:59:20 | Araq_ | so how much RAM? |
| 20:00:04 | Araq_ | and what kind of OS? none? |
| 20:00:53 | nsf | so, guys, about second nimNewNode parameter, will compiler use the parent node's location info for error messages if the node lacks it? |
| 20:01:02 | nsf | oops, newNimNode* |
| 20:01:30 | * | pregressive quit (Remote host closed the connection) |
| 20:02:20 | Skyforce77 | 512mb ram (custom nintendo OS) |
| 20:02:27 | * | pregressive joined #nim |
| 20:02:27 | Araq_ | nsf: exactly |
| 20:02:42 | Araq_ | Skyforce77: so you don't need --os:standalone at all then, afaict |
| 20:02:44 | nsf | Araq_: so, yes? thanks |
| 20:03:14 | Araq_ | you only need to port the memory manager to use nintendo's allocation primitives |
| 20:03:21 | Araq_ | which are with a bit of luck just posix |
| 20:05:01 | mat4 | Araq_: The 3DS like other devices from Nintendo execute normally only protected (read encrypted) applications. That implies that Skyforce77 code either runs on a modificated 3DS or a jailbreaked one. In this case I doubt that firmware or OS dependent functions are accessible without problems, hence his experimentation with --os:standalone. I can be wrong of course |
| 20:05:53 | Araq_ | well I have no idea of what I'm talking about. but 512MB of RAM can definitely host a GC. |
| 20:06:24 | Araq_ | he can also use malloc/free as the underlying primitives but needs to align the resulting pointers |
| 20:06:28 | Skyforce77 | My 3ds is modified yes. |
| 20:06:49 | Skyforce77 | are* x') |
| 20:06:55 | mat4 | can you access the firmware functions (memory managment for example) ? |
| 20:07:43 | Skyforce77 | Yes I can |
| 20:08:17 | Skyforce77 | Humm I think x') |
| 20:08:42 | * | desophos_ joined #nim |
| 20:10:26 | * | desophos quit (Ping timeout: 240 seconds) |
| 20:10:40 | * | desophos_ is now known as desophos |
| 20:11:48 | mat4 | then you should either relate on reference counting or implement your own memory managment functions |
| 20:12:36 | mat4 | to replace sequences |
| 20:13:47 | mat4 | (with memory managment functions I mean a thin layer as sequence replacement) |
| 20:15:05 | mat4 | that should not be difficult |
| 20:15:33 | mat4 | if you can use two firmware functions for allocating and deallocating memory |
| 20:22:27 | * | Demon_Fox quit (Quit: Leaving) |
| 20:27:35 | nsf | https://gist.github.com/nsf/466640dd541ed71f5479 - my coroutines next iteration, scroll to the bottom to see usage |
| 20:27:57 | nsf | now with macro proc preprocessor similar to what nim's async/await does |
| 20:28:25 | nsf | compiles and runs with: nim c --gc:boehm --threads:on main.nim |
| 20:28:34 | nsf | with ref counting it will crash from time to time |
| 20:29:54 | Araq_ | nsf: yeah but we did talk about this, right? |
| 20:30:08 | nsf | yes, I still want to try ref counting.. erm.. maybe |
| 20:30:23 | nsf | I'm not familiar with nim, so first want to get something working and then see if it can be done |
| 20:31:02 | Araq_ | it's not that hard to make the GC use pure Refcounting and multi threading ready |
| 20:31:11 | Araq_ | but I don't have the time for it. |
| 20:31:19 | nsf | atomics are slow :) |
| 20:31:24 | nsf | well... |
| 20:31:26 | Araq_ | yeah I know. |
| 20:31:31 | nsf | maybe it's okay, depends |
| 20:31:37 | nsf | but at least it's predictable right |
| 20:31:55 | Araq_ | dunno, people say it is. |
| 20:32:19 | nsf | well, atomic increment/decrement is roughly 5-10 times slower than non-atomic one |
| 20:32:27 | nsf | on i5/i7 like processors |
| 20:32:43 | Araq_ | true but it's a start |
| 20:33:06 | Araq_ | and the current write barrier is already slow |
| 20:33:21 | Araq_ | however, for *pure* RC'ing you always pay the price for it |
| 20:33:29 | Araq_ | with the current scheme it's rarely executed |
| 20:34:01 | Araq_ | but if you don't use a pure RC, you have to "stop the world" somehow which also has lots of costs associated with it |
| 20:34:15 | nsf | yes, I understand |
| 20:34:52 | Araq_ | you could also use compute the roots at compile time |
| 20:34:56 | Araq_ | and optimize RC ops away |
| 20:35:11 | Araq_ | I implemented "write tracking" for this and it produced nice results |
| 20:35:22 | Araq_ | but again, I don't have the time to finish it. |
| 20:36:05 | Araq_ | in theory it computes what Rust makes you annotate manually, well sort of. |
| 20:36:20 | Araq_ | it's pretty cool but for Nim v2. |
| 20:36:39 | nsf | well, I wish I could help you, but I have even less time for my side projects :) |
| 20:36:53 | nsf | most of the time I'm busy writing web backends in Go |
| 20:41:49 | * | brson joined #nim |
| 20:45:32 | * | brson_ quit (Ping timeout: 272 seconds) |
| 20:50:30 | * | BitPuffin quit (Ping timeout: 256 seconds) |
| 21:00:04 | Araq_ | yay ... |
| 21:02:32 | mat4 | nsf: I found your code an interesting example for cooperative multitasking |
| 21:03:23 | nsf | sure it is |
| 21:30:10 | * | pregressive quit (Remote host closed the connection) |
| 21:31:18 | ldlework | Araq_: I created #nim-gamedev |
| 21:31:23 | ldlework | just fyi |
| 21:32:08 | dom96 | awesome |
| 21:39:45 | * | vendethiel joined #nim |
| 21:40:40 | * | pregressive joined #nim |
| 21:45:43 | * | Jesin joined #nim |
| 21:57:20 | * | joshuaturner quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 21:57:52 | Skyforce77 | I'm back |
| 21:58:12 | * | mat4 quit (Quit: Verlassend) |
| 21:59:49 | Skyforce77 | So, the better in my case is rewriting seq using my os functions? |
| 22:14:37 | Araq_ | no, just patch the runtime to use the nintendo stuff |
| 22:16:28 | Araq_ | look at lib/system/alloc.nim |
| 22:16:33 | Araq_ | "platform specific chunk allocation code" |
| 22:17:02 | Araq_ | you need to port this piece of code and nothing else really |
| 22:17:32 | Skyforce77 | Oh ok! |
| 22:18:02 | Araq_ | you can make osAllocPages and osDeallocPages use C's malloc if that's what Nintendo OS wants you to use |
| 22:18:54 | Araq_ | and while we don't have --os:nintendo if it's posix'ish you should start with --os:linux I guess |
| 22:20:43 | Skyforce77 | it isn't :/ |
| 22:22:21 | Skyforce77 | this system is very restrictive due to its sensivity |
| 22:23:37 | Skyforce77 | so, all the essential libraries are custom ones |
| 22:31:50 | Araq_ | Skyforce77: I don't think it matters that much |
| 22:32:14 | Araq_ | system.nim uses mostly Ansi C and then the stuff in alloc.nim that you need to start with |
| 22:34:52 | * | Jesin quit (Quit: Leaving) |
| 22:47:17 | * | joshuaturner joined #nim |
| 22:48:07 | * | thotypous joined #nim |
| 22:55:34 | * | saml quit (Quit: Leaving) |
| 23:06:59 | * | nsf quit (Quit: WeeChat 1.3) |
| 23:19:04 | * | Trustable quit (Remote host closed the connection) |
| 23:27:17 | * | Skyforce77 quit (Quit: Page closed) |
| 23:28:49 | * | joshuaturner left #nim ("Textual IRC Client: www.textualapp.com") |
| 23:39:38 | * | BlaXpirit quit (Quit: Bye) |
| 23:40:17 | * | BlaXpirit joined #nim |