00:00:11 | gokr1 | "If no exception name is given, the current exception is re-raised." |
00:01:12 | gokr1 | flaviu: So the code works stable for you? |
00:01:12 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
00:01:24 | flaviu | Well, I haven't got a benchmarking setup yet |
00:01:30 | flaviu | I'm trying to figure out gnu parallel |
00:01:37 | gokr1 | I have been hammering - and sure, if I raise concurrent to say 2000 - I do get some failures, but it seems to just "hum on". |
00:01:52 | gokr1 | Now... why am I doing this you may ask? |
00:01:56 | gokr1 | Why not asynch? |
00:02:10 | gokr1 | Well, if you go asynch - then all IO needs to be asynch. |
00:02:31 | gokr1 | So what if you want to build a socket server - that perhaps does some MySQL queries in order to fulfil a request? |
00:02:42 | * | brson joined #nimrod |
00:03:03 | gokr1 | This is seemingly to me a big issue with asynch - all modules doing IO needs to be asynch. |
00:03:44 | gokr1 | But perhaps the listening/spawning part could use async stuff - not sure if that would help any. |
00:03:51 | gokr1 | I don't think so. |
00:04:26 | gokr1 | Also, this utilizes all cores :) |
00:04:34 | gokr1 | We like, yumyum. |
00:04:51 | gokr1 | Gonna hit the bed now. |
00:04:56 | gokr1 | gnite |
00:07:54 | * | gokr1 changed it to just try:finally: - better. |
00:08:40 | * | dapz joined #nimrod |
00:13:49 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
00:15:07 | * | darkf joined #nimrod |
00:22:22 | * | rpag quit (Quit: Leaving) |
00:25:24 | * | ehaliewicz quit (Ping timeout: 255 seconds) |
00:29:40 | flaviu | Wow, the new doesn't even compare in performance impact in comparison to deepcopy |
00:30:07 | * | dapz joined #nimrod |
00:31:21 | * | dapz quit (Client Quit) |
00:33:57 | * | bjz quit (Ping timeout: 255 seconds) |
00:40:30 | * | dapz joined #nimrod |
00:41:45 | * | dapz quit (Client Quit) |
00:41:48 | flaviu | https://gist.github.com/flaviut/78361fdcc8c1e110a26c |
00:42:18 | flaviu | Really nice how the assembler is mixed in with the nim code lines |
00:49:57 | flaviu | gokr1: Similar results as you, but 16259.69rps with -c4 |
00:51:15 | * | dapz joined #nimrod |
01:03:00 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
01:04:42 | * | Joe_knock left #nimrod ("Leaving") |
01:06:18 | * | kingisaac joined #nimrod |
01:09:05 | kingisaac | I'm running the tutorial examples and ran into this error: http://pastebin.com/rQAR01eh |
01:11:57 | will | what code caused that? |
01:13:29 | * | brson quit (Ping timeout: 260 seconds) |
01:13:59 | kingisaac | Sorry. It was the first example in Tutorial 2: http://pastebin.com/e39agFYu |
01:14:11 | will | I also ran gokr1's socket server: 23678.46 [#/sec] (mean) |
01:15:08 | * | brson joined #nimrod |
01:15:28 | will | kingisaac: works for me, what version / OS are you running? |
01:16:07 | kingisaac | 0.9.5, it's the newest in Arch repos. I will install the latest and see if that's the issue |
01:17:29 | * | brson quit (Client Quit) |
01:19:51 | fowl | kingisaac, name the module something other than 'object' |
01:21:43 | will | yeah, just realised that's why it worked for me :D |
01:23:27 | kingisaac | ha! that is the issue |
01:23:44 | kingisaac | now I feel a little dense |
01:24:51 | * | superfunc__ joined #nimrod |
01:28:02 | * | will quit (Ping timeout: 272 seconds) |
01:33:52 | fowl | kingisaac, you shouldn't, it isnt obvious why object cant be used as a module name (where was objectInit defined?) |
01:39:17 | kingisaac | fowl: in system.c and object.c |
01:40:53 | * | saml_ joined #nimrod |
02:02:34 | * | fghj quit (Ping timeout: 246 seconds) |
02:51:50 | * | dapz joined #nimrod |
02:52:16 | * | superfunc__ quit (Ping timeout: 246 seconds) |
02:54:11 | * | Fr4n quit (Remote host closed the connection) |
02:54:42 | * | Fr4n joined #nimrod |
02:56:02 | * | ARCADIVS joined #nimrod |
03:03:53 | * | kingisaac quit (Quit: leaving) |
03:07:52 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
03:20:16 | Onionhammer | hmm, why cant I do a local importc to override a pushed importc araq |
03:22:44 | fowl | Onionhammer, it needs work |
03:27:18 | * | dapz joined #nimrod |
03:27:33 | * | dapz quit (Client Quit) |
03:28:59 | * | noam quit (Ping timeout: 245 seconds) |
03:33:48 | * | jpoirier joined #nimrod |
03:36:04 | * | jpoirier quit (Client Quit) |
03:39:18 | * | superfunc__ joined #nimrod |
03:46:54 | * | superfunc__ quit (Quit: Page closed) |
03:49:12 | * | flaviu quit (Remote host closed the connection) |
03:50:30 | * | enitiz-mobile joined #nimrod |
03:51:44 | * | dapz joined #nimrod |
03:51:48 | * | dapz quit (Client Quit) |
03:52:15 | Varriount | gokr: So, in the end, how well does Nim stack up in requests per second when using threads? |
04:12:34 | * | dapz joined #nimrod |
04:36:38 | * | enitiz-mobile quit (Quit: Bye) |
04:38:31 | * | superfunc__ joined #nimrod |
04:41:53 | * | darkf_ joined #nimrod |
04:43:24 | * | xenagi quit (Read error: Connection reset by peer) |
04:44:48 | * | saml_ quit (Quit: Leaving) |
04:46:03 | * | darkf quit (Ping timeout: 272 seconds) |
04:46:51 | * | darkf_ is now known as darkf |
04:59:14 | * | nande quit (Read error: Connection reset by peer) |
05:00:43 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
05:03:38 | * | dapz joined #nimrod |
05:08:09 | * | dapz quit (Ping timeout: 260 seconds) |
05:12:58 | * | superfunc__ quit (Ping timeout: 246 seconds) |
05:15:05 | * | dapz joined #nimrod |
05:50:59 | gokr1 | Varriount: Well, it seems comparable to me. On a single box with a single ab hammering. I can do some more testing though. |
06:07:22 | * | delian66 quit (Ping timeout: 250 seconds) |
06:07:30 | * | delian66 joined #nimrod |
06:10:30 | * | heinrich5991 quit (Ping timeout: 260 seconds) |
06:10:44 | * | gokr_ joined #nimrod |
06:12:06 | * | gokr quit (Ping timeout: 246 seconds) |
06:13:44 | * | heinrich5991 joined #nimrod |
06:14:44 | * | gokr_ quit (Ping timeout: 260 seconds) |
06:16:32 | reloc0 | moin |
06:35:08 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
06:37:30 | * | gokr_ joined #nimrod |
06:51:02 | * | Hodapp quit (Ping timeout: 272 seconds) |
06:57:41 | * | Hodapp joined #nimrod |
06:59:30 | * | milosn_ joined #nimrod |
07:05:55 | * | milosn quit (*.net *.split) |
07:15:19 | * | bjz joined #nimrod |
07:49:09 | * | Trustable joined #nimrod |
07:55:55 | * | Etheco joined #nimrod |
08:20:40 | * | bjz quit (Ping timeout: 265 seconds) |
08:23:21 | * | bjz joined #nimrod |
08:33:29 | Araq | hi reloc0 |
09:58:20 | * | xcombelle joined #nimrod |
09:59:28 | * | ARCADIVS quit (Quit: ARCADIVS) |
10:09:26 | Etheco | I love reading though the logs from the day in this channel :D |
10:09:33 | Etheco | this channel is like a big howto |
10:15:41 | * | xcombelle quit (Ping timeout: 260 seconds) |
10:32:13 | gokr1 | I am busy writing some new articles, its truly becoming a joy coding in Nim. |
10:32:37 | Etheco | would love to read them, trying to find time to get into my project that i am going ot use Nim for |
10:32:55 | gokr1 | Those I have so far are at http://goran.krampe.se/category/nim |
10:33:19 | gokr1 | Now the articles I am working on are becoming more "hands on". |
10:33:33 | gokr1 | One is about that spawningserver I wrote yesterday. |
10:33:33 | Etheco | i did see you doin the http server stuff last night |
10:33:43 | gokr1 | In fact its not HTTP :) |
10:34:05 | gokr1 | It just echos first line. |
10:34:12 | Etheco | :D |
10:34:41 | gokr1 | But its a clean little example and uses the new stuff (net, selectors, spawn) |
10:35:02 | Etheco | my project is todo with getting backups run and reporting system stats etc |
10:35:15 | gokr1 | And while async is "hip" - a threaded server still has many advantages I think. |
10:35:48 | gokr1 | A todo app? Web based? |
10:35:57 | gokr1 | Oh, no |
10:36:07 | gokr1 | You meant "has to do with" |
10:36:11 | Etheco | nah, its going to be a daemon that runs backups for files/mysql and report cpu/ram usage etc |
10:36:20 | gokr1 | right |
10:37:05 | Etheco | once i figure out how procs work etc |
10:37:07 | gokr1 | There are some nifty "scripts" in Nim you can use as starters. |
10:37:42 | gokr1 | For example, I think "Lapp" has been ported from Lua (just guessing) and one of the scripts I read used it - very neat for making CLI type scripts. |
10:38:11 | Etheco | oh cool, will check it out |
10:38:46 | gokr1 | Lapp in Lua means automatic options parsing based on the "help" text for the script. |
10:39:34 | Etheco | yeh, i am getting a list of made scripts in Nim, i prefer to rip apart someones good code and figure out how it works :) |
10:40:11 | gokr1 | koch.nim uses the older parseopt - but it has a bunch of other stuff in it. |
10:41:34 | gokr1 | Steve Donovan (Lua fame, Penlight library) seems to be using Nim and he has ported Lapp. Perhaps he is even in this channel. |
10:41:40 | gokr1 | https://gist.github.com/stevedonovan/6409900 |
10:42:29 | Etheco | awesome |
10:42:33 | Etheco | added to my list of nim pages :D |
10:43:04 | Etheco | so parseopt is deprecated now then |
10:43:10 | Etheco | in the documents it said to ues that |
10:43:33 | gokr1 | Here he writes about it I think: http://steved-imaginaryreal.blogspot.se/2013/09/nimrod-return-of-pascal.html |
10:44:11 | gokr1 | Just search down for "lapp" |
10:44:48 | gokr1 | think I need to read that article again. |
10:45:55 | Etheco | ah this koch.nim |
10:46:02 | Etheco | has a lot of great examples for me :D thank you! |
10:46:20 | gokr1 | yeah |
10:54:51 | * | noam joined #nimrod |
10:59:37 | * | noam quit (Ping timeout: 265 seconds) |
11:10:25 | * | xcombelle joined #nimrod |
11:44:03 | dom96_ | gokr1: It would be nice to see Async and Spawn working together. |
11:44:27 | dom96_ | I know what you mean when you say that everything will need to support async in order to use async though. |
11:44:44 | gokr1 | Yeah, if you don't use threads. |
11:45:09 | gokr1 | But if we do spawn off the requests in threads - then I am not so sure that async gives us much in the listener part, or? |
11:46:13 | dom96_ | Who knows. |
11:46:25 | gokr1 | As an example of the "everything needs to use it" problem - if you look at Turbolua or Openresty - they need to make special modules for db access etc, in order for that to work with the rest of the framework. |
11:46:44 | wan | Yes, I agree, I think lwan is blocking for the listener and async in the workers |
11:47:28 | gokr1 | So if you have x worker threads, then yes, you could let each thread use async to handle more than 1 request concurrently. |
11:47:35 | wan | gokr1: yep, we would need async wrappers for db stuff |
11:48:45 | gokr1 | Btw, the numbers go a bit up and down depending. I am trying to write an article describing it. |
11:49:18 | * | noam joined #nimrod |
11:49:50 | gokr1 | If you remove the "spawn" word - then it will actually do 22k requests - if you use ab with 50 concurrent clients. But again, don't compare with HTTP servers since they probably use keep alive. |
11:50:36 | gokr1 | But if you raise the amount of data returned to something more reasonable - then data transfer goes up from 200kb/sec to say 12Mb/sec - and requests go down to around 7-10k. |
11:50:53 | gokr1 | This I just played with in order to compare with spawn. |
11:51:05 | gokr1 | Ok, gotta go - later |
11:53:11 | dom96_ | You should write a similar pseudo-http server using async await to make the comparison fair I think :P |
11:53:20 | dom96_ | My intention is to write async db modules. |
11:54:14 | * | noam quit (Ping timeout: 265 seconds) |
11:57:42 | * | khmm joined #nimrod |
12:00:36 | * | noam joined #nimrod |
12:02:41 | gokr1 | dom96_: Then you should take my stab at a wrapper for HyperDex - since it has an API built for async :) |
12:05:09 | * | noam quit (Ping timeout: 255 seconds) |
12:11:53 | * | khmm quit (Ping timeout: 240 seconds) |
12:51:05 | * | gokr joined #nimrod |
12:52:57 | * | gokr_ quit (Ping timeout: 260 seconds) |
12:53:18 | * | BitPuffin joined #nimrod |
12:53:43 | * | noam joined #nimrod |
12:55:00 | Etheco | so my daemon is going to need a config file, what is a good place to have this located? |
12:55:23 | Etheco | do i go down the ~/.config/ route or /etc/folder route |
12:58:09 | * | noam quit (Ping timeout: 245 seconds) |
12:58:24 | Araq | use whatever os.getConfigDir returns |
12:58:38 | Etheco | oooooo, thats even better :) |
13:39:20 | * | gokr_ joined #nimrod |
13:41:36 | * | gokr quit (Ping timeout: 258 seconds) |
13:49:32 | * | noam joined #nimrod |
13:49:37 | * | darkf quit (Quit: Leaving) |
13:50:02 | * | dom96_ quit (Ping timeout: 258 seconds) |
13:52:23 | Araq | gokr1: "If you remove the "spawn" word - then it will actually do 22k requests" -- opposed to what? what's the number with spawn? |
13:53:07 | gokr1 | Well, around 15k requests IIRC. |
13:53:28 | Araq | hu? so it's worse with spawn? |
13:53:29 | gokr1 | It depends of course a LOT on if I just return a little line - or some more substantial data. |
13:53:40 | Araq | oh ok, yeah |
13:53:55 | gokr1 | Is the deepCopy blocking? |
13:54:01 | * | noam quit (Ping timeout: 256 seconds) |
13:54:17 | Araq | yes and in fact, it's even worse |
13:54:44 | Araq | however you can also try spawnX |
13:54:49 | gokr1 | It must of course block, duh. |
13:56:14 | gokr1 | ok |
13:56:36 | Araq | well we can implement it quite differently, it's more or less a prototype |
13:56:44 | gokr1 | What do you mean with "worse"? |
13:57:05 | gokr1 | Yeah, sure. |
13:57:11 | Araq | that said, it surely is good enough if you give it reasonably sized chunks of work |
13:57:25 | gokr1 | Exactly, just echoing a line isn't really interesting :) |
13:58:10 | gokr1 | I will play with it a tad more to get that article together. |
13:58:33 | * | noam joined #nimrod |
13:58:47 | Araq | also its implementation is so beautiful that I don't really want to optimize it ... |
13:59:05 | * | noam quit (Read error: Connection reset by peer) |
13:59:05 | Araq | worth a paper, it uses some really novel idea |
13:59:17 | gokr1 | I also started on an article about "OO in Nim", so any non obvious thoughts on that, would be welcome. I will basically try to detangle the various techniques we have that sort has to do with OO. |
13:59:23 | gokr1 | Really? cool |
14:00:10 | gokr1 | Also, having simple multithreading is important. Async is all nice of course, but... you know. Then reality hits you in the face with some db API or whatever ;) |
14:00:19 | gokr1 | And multicore. |
14:00:25 | Araq | yup, I agree |
14:00:29 | Araq | in fact |
14:00:56 | Araq | async is a hack that makes "blocking/non-blocking" the essence of your programming model |
14:01:06 | * | noam joined #nimrod |
14:01:13 | Araq | which should rather be an implementation detail |
14:01:20 | gokr1 | yes |
14:01:38 | gokr1 | It seems to me that lots of people who jumped on the nodejs train... sortof got a bit burned and moved on. |
14:01:40 | * | noam quit (Read error: Connection reset by peer) |
14:01:44 | Araq | but hey, as a systems programming language, we're allowed to care for implementation details ;-) |
14:01:49 | gokr1 | Hehe |
14:02:14 | gokr1 | What about the green threads over a pool of real ones? |
14:02:20 | gokr1 | That's how Go does it, right? |
14:02:30 | gokr1 | With the goroutines stuff. |
14:05:15 | Araq | Go uses a thread pool like everything else under the hood |
14:05:47 | * | dom96_ joined #nimrod |
14:05:49 | Araq | there is no other way to use multi cores except of course multiple processes |
14:07:09 | BitPuffin | hmm |
14:07:11 | Araq | green threads sit on top of a thread pool |
14:07:13 | BitPuffin | someone just forked nim-portaudio |
14:07:34 | BitPuffin | is jaubert someone who usually comes here? |
14:07:51 | BitPuffin | actually this was 21 hours ago nvm |
14:10:58 | dom96_ | Hey BitPuffin, how's life? |
14:11:25 | Araq | gokr1: that said, Go's model is indeed quite different. I'm not sure it's worth copying though. It has lots of problems too. |
14:11:33 | Etheco | when (server: var TServer) happens is it automaticlly passing the var in? |
14:12:15 | gokr1 | Araq: It might be important to think "library" and not "language" here - since ... there are different ways to peel the banana. |
14:12:30 | BitPuffin | dom96_: good good, working hard with work, and have also started writing actual code for my lang :P |
14:12:33 | BitPuffin | dom96_: you? |
14:12:38 | gokr1 | But having said that, threadpool and spawn is just a lib, right? |
14:12:54 | dom96_ | BitPuffin: Pretty good, sitting in a lecture learning about what an Operating System is... |
14:13:02 | BitPuffin | dom96_: HAH |
14:13:12 | BitPuffin | dom96_: what is an operating system? |
14:13:18 | BitPuffin | Never heard of it |
14:13:28 | dom96_ | BitPuffin: No idea man. |
14:13:54 | Araq | no, it's built into the compiler. but you can also implement things like these via Nim's macro system. |
14:14:18 | dom96_ | Anyway, i'm starting to get worried that my async await stuff will become useless because of spawn. |
14:14:33 | BitPuffin | dom96_: is it like an automate surgeon? |
14:14:36 | gokr1 | “an operating system is a collection of things that don’t fit inside a language; there shouldn’t be one” |
14:14:45 | BitPuffin | dom96_: why would it? |
14:14:58 | BitPuffin | dom96_: isn't spawn more of a fire and forget sort of thing |
14:15:05 | dom96_ | BitPuffin: possibly |
14:15:12 | BitPuffin | where asy async await is more do this while I do this other shit, and then I want the result |
14:15:56 | Araq | gokr1: *conceptually* it's only a library ... ;-) |
14:16:08 | BitPuffin | Araq: lol, what's that supposed to mean! |
14:16:35 | Araq | in practice the macro system still needs more features for 'spawn' |
14:16:47 | dom96_ | Yeah, async await is cooler because it *is* a library :D |
14:16:54 | BitPuffin | >:D |
14:23:05 | Araq | BitPuffin: why the >:D ? surely 'spawn' is important enough to warrant some shortcuts taken in the implementation? |
14:23:36 | BitPuffin | Araq: the >:D was for dom96_'s stmt |
14:23:55 | BitPuffin | Araq: and yeah maybe, as long as the next step is to fix whatever is keeping it from being a library |
14:24:42 | Araq | "fix whatever" is mostly the missing types API iirc |
14:25:16 | BitPuffin | type information for the ast nodes? |
14:25:21 | Araq | yes |
14:25:36 | BitPuffin | that a lot to add? |
14:27:08 | Araq | no, but I avoid designing APIs these days because everybody complains about my views |
14:27:32 | Etheco | is cpuinfo that got taken out ? http://nimrod-lang.org/cpuinfo.html |
14:27:54 | Etheco | its linked to on osproc page |
14:28:28 | BitPuffin | Araq: your views about APIs? :P |
14:28:45 | Araq | Etheco: no it's so new that we missed it in the doc building process |
14:28:47 | BitPuffin | if you don't add the API then the language won't be powerful enough to add spawn, and then what's the point |
14:29:01 | Etheco | ah right okay :D |
14:29:04 | BitPuffin | just seems like a strange excuse |
14:29:31 | Araq | BitPuffin: whatever man. |
14:29:49 | BitPuffin | agreed, I don't really have invested interest |
14:30:29 | BitPuffin | if you don't have time to add the api then that's a fine excuse imo, but avoiding it because people don't like your views, why would you even make a language then, if you are afraid of people disliking your views |
14:30:55 | BitPuffin | meh who cares, back to work |
14:31:01 | Araq | BitPuffin: I will add the API, but it requires lots of design work |
14:31:13 | BitPuffin | Araq: alright so the reason is time then, fine |
14:31:36 | BitPuffin | no need to pretend to be a victim :D |
14:32:17 | Araq | BitPuffin: well look at the current macros API as a counter example. |
14:32:58 | Araq | that hasn't been designed really. |
14:33:33 | BitPuffin | so redesign it |
14:33:55 | Araq | yes. Or: I fix compiler bugs. |
14:34:37 | BitPuffin | I reckon you should do both, but yeah fix bugs first obviously |
14:39:19 | Araq | BitPuffin: "so redesign it" is easily said. however, the existing API is not ugly, but also flexible and powerful. |
14:39:27 | Araq | *not only |
14:39:36 | dom96_ | http://forum.nimrod-lang.org/t/601 |
14:40:54 | BitPuffin | Araq: sure thing, it's not like it's done in a minute |
14:41:12 | BitPuffin | and after designing it you also have to replace old code that used it |
14:41:13 | BitPuffin | I get that |
14:41:22 | BitPuffin | I guess what you could do to mitigate that is have both apis |
14:41:37 | BitPuffin | and rename the old one or something so in all the files in which it broke you import the old one |
14:41:56 | Araq | import macros2 ;-) |
14:43:40 | gokr1 | Btw, the port of "Lapp" from Lua is pretty slick - should we stuff that into stdlib too? Search for "lapp" on http://steved-imaginaryreal.blogspot.se/2013/09/nimrod-return-of-pascal.html |
14:44:06 | * | itsmeront joined #nimrod |
14:44:10 | gokr1 | (its a parseopt thingy that uses the help text as definition of opts) |
14:45:18 | gokr1 | (yeah, ok, stdlib should not be a kitchen sink of course) |
14:45:42 | dom96_ | Just realised I should tweet about the release on nim's twitter account |
14:45:49 | Araq | in general we don't add things to the stdlib that we don't maintain |
14:46:03 | gokr1 | Also reasonable :) |
14:46:11 | BitPuffin | Araq: well then you have the ugly problem that it's always gonna be called macros2 xD or if you rename it, and then you have the same problem as when you started |
14:46:27 | BitPuffin | dom96_: wasn't it released ages ago? |
14:46:39 | dom96_ | BitPuffin: ...yeah |
14:46:44 | Araq | no, last week and we need to patch it anyway |
14:46:48 | BitPuffin | ah |
14:46:54 | BitPuffin | confused it with 0.9.4 |
14:47:07 | BitPuffin | because I think the number it said when I was using nimrod git was 0.9.6 :P |
14:52:00 | * | askatasuna joined #nimrod |
14:53:48 | Araq | dom96_: we should have delayed "nimble" until "nim" is out ... :-/ |
14:54:50 | Araq | but I guess I can package "nimble" with "nimrod 0.9.8" ? |
14:55:03 | BitPuffin | the hell is nimble :P |
14:55:06 | dom96_ | Araq: well... |
14:55:09 | dom96_ | Araq: too late now |
14:58:03 | dom96_ | BitPuffin: http://forum.nimrod-lang.org/t/601 |
15:02:46 | BitPuffin | dom96_: fuuuuuuuuuuuuck |
15:02:56 | BitPuffin | now I need to update all of my babel packages to have .nimble instead xD |
15:03:23 | Araq | BitPuffin: please check that 0.9.6 can still compile them |
15:03:34 | Araq | any regression we can fix for 0.9.8 is nice |
15:04:05 | BitPuffin | yeah well I can't check that now |
15:04:12 | BitPuffin | perhaps this weekend if even |
15:04:13 | BitPuffin | :P |
15:05:13 | * | ehaliewicz joined #nimrod |
15:06:15 | Araq | hrm we seriously need to re-think versioning |
15:06:45 | Araq | this odd vs even distinction is quite good, but it sucks we have no real beta stage |
15:08:11 | Araq | and let's be honest: here in open source land, a release happens and *afterwards* many bugs are found and fixed |
15:08:58 | Araq | and then it's stable until work begins on new features |
15:13:33 | * | mko joined #nimrod |
15:13:36 | * | mko quit (Max SendQ exceeded) |
15:14:40 | * | mko joined #nimrod |
15:20:39 | BitPuffin | pretty sure that's how it works outside of open source as well |
15:25:32 | Araq | well outside of open source there is more resources for QA |
15:31:06 | BitPuffin | yeah I guess |
15:31:11 | BitPuffin | but hotfixes are quite common |
15:31:15 | BitPuffin | look at autodesk products |
15:31:18 | BitPuffin | hotfix 24/7 |
15:42:44 | * | ehaliewicz quit (Ping timeout: 258 seconds) |
15:55:34 | * | dom96_ quit (Ping timeout: 246 seconds) |
16:05:49 | * | Matthias247 joined #nimrod |
17:00:08 | * | gokr_ quit (Remote host closed the connection) |
17:01:07 | * | gokr_ joined #nimrod |
17:05:32 | * | gokr_ quit (Ping timeout: 258 seconds) |
17:05:44 | * | brson joined #nimrod |
17:10:30 | Trustable | Hello everyone :) Has anyone tried to decode and play an Ogg Vorbis file in an own program? I have demo programs for two libraries, which works in principle, but the sound is distorted. I need to find out where this issue comes from. |
17:10:54 | Araq | Trustable: we already told you? float is 64 bits in Nim |
17:12:13 | Araq | bbl |
17:13:16 | Trustable | Araq: My problem with the sine generator was not related to types or Nim. It was an uninitiated sound buffer. But thanks anyway. |
17:13:52 | * | gokr_ joined #nimrod |
17:14:07 | * | gokr joined #nimrod |
17:14:07 | * | gokr_ quit (Read error: Connection reset by peer) |
17:14:47 | shodan45 | I see there is now a "pas2nim".... next is py2nim? :) |
17:20:29 | itsmeront | Hi All. I'm trying to compile koch.nim on ubuntu 14.04 LTS from bigbreak but getting lib/system.nim(2129,41) Error: invalid pragma: locks: 0 |
17:24:24 | itsmeront | anyone seen that error before? |
17:24:58 | * | gokr_ joined #nimrod |
17:27:14 | * | ehaliewicz joined #nimrod |
17:27:16 | * | askatasuna quit (Quit: WeeChat 1.0.1) |
17:27:22 | * | untitaker quit (Ping timeout: 240 seconds) |
17:27:39 | * | gokr quit (Ping timeout: 256 seconds) |
17:30:17 | * | ehaliewicz quit (Remote host closed the connection) |
17:33:21 | * | untitaker joined #nimrod |
17:33:29 | * | gokr joined #nimrod |
17:36:41 | * | gokr_ quit (Ping timeout: 260 seconds) |
17:38:07 | * | xcombelle quit (Ping timeout: 258 seconds) |
17:39:27 | * | gokr quit (Remote host closed the connection) |
17:39:40 | * | gokr joined #nimrod |
17:43:24 | Araq | itsmeront: well I can imagine why that happens |
17:43:43 | Araq | let me rebuild C sources to fix it |
17:43:58 | itsmeront | why? |
17:44:19 | itsmeront | excellent. Thanks! |
17:44:38 | Araq | why? because bigbreak uses the most recent additions now |
17:45:05 | Araq | shodan45: pas2nim is *old*. it's been used for the initial bootstrapping |
17:45:25 | Araq | the initial version of the compiler was written in Pascal |
17:45:35 | shodan45 | Araq: hah, never knew that! |
17:47:06 | shodan45 | just assumed it started in C |
17:47:20 | * | gokr_ joined #nimrod |
17:49:42 | shodan45 | compiler bootstrapping just seems weird to me... it's both necessary and "throw away" code |
17:51:09 | * | gokr quit (Ping timeout: 258 seconds) |
17:51:18 | Araq | writing a compiler in C is stupid |
17:53:58 | shodan45 | Araq: agreed. all compilers should be written in python: http://www.llvmpy.org/ ;) |
17:54:44 | shodan45 | (only half joking... llvmpy looks pretty cool) |
17:54:54 | Araq | no but in rust or ocaml or nim |
17:55:34 | shodan45 | I tried ocaml a while back, I just couldn't get myself to like it |
18:02:16 | * | BitPuffin quit (Read error: Connection reset by peer) |
18:15:55 | * | itsmeront quit (Ping timeout: 246 seconds) |
18:17:02 | NimBot | Araq/Nimrod devel 2c5743d Araq [+0 ±3 -0]: fixes #1029 |
18:17:02 | NimBot | Araq/Nimrod devel d72818e Araq [+0 ±1 -0]: updated news.txt |
18:18:51 | * | itsmeront joined #nimrod |
18:21:03 | * | vendethiel- is now known as vendethiel |
18:22:48 | * | willwillson joined #nimrod |
18:25:58 | * | xcombelle joined #nimrod |
18:32:02 | * | brson quit (Quit: leaving) |
18:32:33 | * | gokr joined #nimrod |
18:32:33 | * | gokr_ quit (Read error: Connection reset by peer) |
19:15:13 | Varriount | shodan45: There's no py2nim, unfortunately. |
19:16:29 | ldlework | So... |
19:16:30 | Varriount | shodan45: You might be able to partially convert a python script to nimrod, if you assume that certain things remain static, however it would take the equivalent of Cython to convert python to nimrod accurately. |
19:17:19 | * | paul_oyster joined #nimrod |
19:17:26 | shodan45 | Varriount: I'm sure it would be quite non-trivial... I was mostly joking :) |
19:18:12 | * | noam joined #nimrod |
19:21:31 | Varriount | shodan45: Although, even a partial transformer would be helpful for porting. |
19:22:31 | Araq | hi paul_oyster welcome |
19:23:12 | Araq | who wrote web/babelpkglist.nim ? |
19:23:23 | * | irrequietus joined #nimrod |
19:25:01 | Araq | hi irrequietus welcome |
19:25:30 | irrequietus | hi Araq, actually an old member :) |
19:25:47 | irrequietus | dom96 knows me from twitter and here :D |
19:25:59 | gokr1 | Araq: That has GOT to be scripted, admit it! |
19:26:18 | gokr1 | Or at least semi automated. |
19:26:21 | Araq | well here's the proof I'm not a greeting bot |
19:26:32 | shodan45 | #nimrod is so friendly :) |
19:26:34 | Araq | gokr1: it's compiled to JS ... |
19:26:39 | gokr1 | Hehe |
19:26:48 | gokr1 | You need to vary the greetings. |
19:26:59 | irrequietus | Araq: https://lobste.rs/s/kdnbjw/nimrod_language_will_be_renamed_to_nim_from_0_10_0_slight_compatibility_break :P |
19:27:06 | * | paul_oyster left #nimrod (#nimrod) |
19:27:17 | irrequietus | doing my best to spread the nim word :) |
19:27:30 | * | paul_oyster joined #nimrod |
19:27:34 | gokr1 | Nim, Nim! We are the Knights who say .... NIM! |
19:27:41 | reactormonk | Araq, btw, should I talk to the admins to rename the channel to #nim and forward? |
19:28:03 | Araq | reactormonk: well some of us already are in #nim |
19:28:15 | Araq | but if that can be done, that would be awesome |
19:29:33 | paul_oyster | hello everyone; a newbie here. read through the intro today and started playing with the language |
19:30:07 | paul_oyster | fucking beautiful syntax and fast as hell |
19:30:37 | gokr1 | I am also a n00b - and I am documenting my stumblings at http://goran.krampe.se/category/nim |
19:30:54 | Araq | thank you, paul_oyster :-) |
19:30:59 | * | gokr1 reminds me we should do a Nim planet... |
19:32:28 | ldlework | So I have gone through rust and go, neither can expressively represent an ECS system |
19:32:34 | * | ldlework wonders if nimrod has the goods.. |
19:32:47 | Araq | ldlework: ECS? |
19:33:11 | ldlework | entity component system |
19:33:21 | * | dom96_ joined #nimrod |
19:33:53 | Araq | well fowl wrote one for Nim |
19:34:17 | paul_oyster | just starting a new project, which uses both python and c++ heavily; will add nim to the mix as well; seems it could replace some of the code in both languages |
19:34:27 | irrequietus | will there be a #nim channel switch? |
19:34:28 | ldlework | Araq: can you link me? |
19:34:50 | Araq | dom96_: I have no idea where this "If you are reading this you are missing babelpkglist.js or have javascript disabled in your browser." comes from ... :-/ |
19:35:24 | ldlework | Araq: I can't find it |
19:35:34 | dom96_ | Araq: The html? |
19:36:02 | Araq | dom96_: yeah in lib.html |
19:36:07 | Trustable | Good news: Ogg Vorbis playback now works in my Nim program using libsndfile :) |
19:36:26 | gokr1 | ldlework: I think its this: https://github.com/fowlmouth/nimlibs/blob/master/fowltek/entitty.nim |
19:36:33 | gokr1 | "entitty" |
19:36:47 | ldlework | lol |
19:36:49 | gokr1 | And then we wonder why we don't attract women to CS ... |
19:37:15 | gokr1 | Are there any women here today? |
19:37:47 | * | shodan45 hears crickets chirping |
19:37:56 | * | gokr1 in John Cleese accent... |
19:38:19 | reactormonk | Araq, could you /msg chanserv op #nimrod reactormonk |
19:38:22 | gokr1 | fowl: By the way, damn you have lots of Nim code there... |
19:38:53 | * | BlaXpirit joined #nimrod |
19:41:02 | Araq | don't misuse your power |
19:41:11 | reactormonk | oh, I'll trash this channel |
19:41:39 | reactormonk | hm, duh |
19:41:48 | shodan45 | heh, maybe after things move to #nim, #nimrod could be the new offtopic channel? :) |
19:42:01 | * | Ven joined #nimrod |
19:43:35 | gokr1 | fowl: Have you been wrapping mainly C libs, or also some C++ libs? |
19:43:53 | gokr1 | Very funny description of ReadableCpp btw |
19:44:08 | reactormonk | Araq, hm, need more permissions. /msg chanserv access #nimrod add reactormonk |
19:44:10 | Araq | dom96_: never mind, I found it |
19:46:03 | * | itsmeront_ joined #nimrod |
19:46:23 | Araq | reactormonk: you know our policy. only ban somebody if absolutely necessary. and it's never been necessary in the past (6?!) years |
19:46:44 | reactormonk | Araq, hell nah, I'll drop it afterwards |
19:47:51 | reactormonk | Araq, could you /msg chanserv #nimrod set guard on |
19:47:54 | shodan45 | wait, nim(rod) has been around for 6 years? |
19:48:12 | reactormonk | ... that adds an idler to this channel which is needed to keep the flags |
19:51:31 | reactormonk | Araq, /msg chanserv set #nimrod mlock +if #nim |
19:51:34 | reactormonk | ... for the forward |
19:51:40 | reactormonk | then adjust topic accordingly |
19:53:26 | Araq | reactormonk: 'set guard on' doesn't work |
19:53:41 | Araq | shodan45: yes. |
19:54:16 | reactormonk | Araq, what does it say? |
19:55:14 | * | flaviu joined #nimrod |
19:57:42 | * | flaviu quit (Remote host closed the connection) |
20:00:37 | Varriount | paul_oyster: fowl developed a successor to entitty called entooty |
20:01:47 | Araq | reactormonk: "Invalid command. Use /msg ChanServ help for a command listing." |
20:02:49 | Varriount | *entoody |
20:02:52 | Varriount | paul_oyster: https://bitbucket.org/fowlmouth/entoody |
20:07:30 | reactormonk | Araq, huh |
20:08:30 | reactormonk | Araq, with the channel name? /msg chanserv #nimrod set guard on |
20:09:44 | * | flaviu joined #nimrod |
20:11:35 | Araq | reactormonk: yes. |
20:11:40 | Araq | wit the channel name |
20:11:43 | Araq | *with |
20:17:57 | reactormonk | duh |
20:24:07 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
20:25:24 | * | itsmeront quit (Ping timeout: 246 seconds) |
20:36:23 | * | gokr1 left #nimrod (#nimrod) |
20:36:34 | Varriount | Araq: Earlier you said that my string optimization isn't really an optimization - howso? |
20:37:01 | Varriount | Or rather, that it wasn't always an optimization. |
20:37:16 | Araq | var x = newString(40) |
20:37:33 | Araq | x = someProc() # someProc allocates anyway ... |
20:38:00 | Araq | # better do the pointer assignment here |
20:39:52 | Varriount | Araq: So should I not implement the change? |
20:39:52 | * | xcombelle quit (Ping timeout: 255 seconds) |
20:40:29 | Araq | well I can think of 10 things that are more important ;-) |
20:40:52 | * | gokr1 joined #nimrod |
20:40:57 | Varriount | Araq: Ok, then what should be my mini-task for this weekend? |
20:42:22 | Araq | figure out why babelpkglist.nim works except for the wrong error message that it produces |
20:44:55 | * | nande joined #nimrod |
20:45:13 | Araq | also I had to disable the "see source" feature |
20:45:24 | Araq | would be nice if somebody could look into that |
20:46:20 | Araq | I also heard some rumors that we have a thing called a "bug tracker". With over 300 open issues. |
20:49:26 | itsmeront_ | only 300? |
20:51:11 | Varriount | Araq: Uh... did you include sqlite, pcre, and pdcurses in the 32 bit installer? |
20:51:27 | * | Ven joined #nimrod |
20:51:30 | Araq | Varriount: I think so |
20:51:41 | Varriount | I don't know if I did... |
20:53:30 | Araq | Varriount: did you build the 64 bit installer from devel? |
20:53:40 | Varriount | Araq: Yes. |
20:54:12 | itsmeront_ | fixes the lock:0 pragma error? |
20:54:42 | itsmeront_ | on bigbreak? |
20:55:25 | itsmeront_ | hehehe sorry I rad that wrong I thought Andreas was saying you built the new installer |
20:55:31 | itsmeront_ | "read |
20:56:16 | Varriount | itsmeront_: Uh, I did. I built the 64 bit installer. |
20:56:47 | Araq | Varriount: well you know there is a reason we have git tags, but ok, no big deal |
20:56:55 | Araq | I just checked: |
20:57:10 | Araq | the "import strutils as su" regression is *not* in 0.9.6 |
20:57:12 | reactormonk | Araq, /msg chanserv access #nimrod add reactormonk +AFORfiorstv |
20:58:59 | itsmeront_ | yeah was looking for new csources to fix system.nim pragma error for locks. |
21:00:57 | Araq | ok ok, let me fix it ... |
21:01:27 | itsmeront_ | Oh I never did really introduce myself here. I'm Ron Teitelbaum owner 3dicc.com. Just hanging out and playing with Nim. |
21:02:00 | itsmeront_ | Hi All |
21:02:24 | irrequietus | hi |
21:03:08 | gokr1 | And I work with Ron btw |
21:03:16 | irrequietus | ohhh |
21:03:16 | itsmeront_ | Hi Goran :) |
21:03:25 | gokr1 | Yo :) |
21:03:35 | itsmeront_ | itsmeront = it is me Ron T |
21:03:58 | gokr1 | It just took me like one year before I figured that out. |
21:04:06 | itsmeront_ | hahahha |
21:04:13 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
21:04:16 | * | johnsoft quit (Ping timeout: 244 seconds) |
21:04:41 | * | johnsoft joined #nimrod |
21:06:30 | Varriount | I feel so honored, being in the same irc channel as all these venerable professionals. |
21:07:29 | gokr1 | I can sense a bit of... irony? |
21:08:11 | Varriount | Eh, no. I'm not being sarcastic. Or ironic. |
21:08:37 | Araq | that's nothing. I only recently figured out the importance of fermat's last theorem ... |
21:14:00 | irrequietus | LOL |
21:15:05 | NimBot | Araq/Nimrod bigbreak b0d9dc4 Varriount [+0 ±1 -0]: Update nsis.tmpl... 2 more lines |
21:15:05 | NimBot | Araq/Nimrod bigbreak fa77547 Araq [+0 ±2 -0]: fixes 'import x as y' regression |
21:15:05 | NimBot | Araq/Nimrod bigbreak 0f26040 Araq [+0 ±1 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
21:15:05 | NimBot | Araq/Nimrod bigbreak 2c5743d Araq [+0 ±3 -0]: fixes #1029 |
21:15:05 | NimBot | 2 more commits. |
21:15:32 | Araq | itsmeront_: please try again |
21:16:20 | itsmeront_ | thanks will do |
21:17:46 | itsmeront_ | thanks that worked! |
21:19:24 | Araq | Varriount: well I guess the best project is to update koch.nim so that it ensures babel/nimble is bundled with the installers |
21:19:31 | Varriount | Araq: Anything in particular I need to avoid with compiler procs? |
21:19:33 | Araq | and also fix the versioning bug please |
21:19:52 | Araq | Varriount: generic compiler procs don't work without further magic |
21:19:57 | Varriount | Like, are var types allowed to be passed? |
21:20:19 | Araq | no. |
21:20:43 | Varriount | Darn. |
21:20:50 | Araq | well |
21:20:55 | Araq | you can use 'var' |
21:21:12 | Araq | but you then need to use addrLoc in the backend to pass the argument |
21:21:51 | Araq | also don't use importc/exportc with compilerprocs |
21:22:51 | fowl | gokr1, we had a female nim programmer, havent seen her in a couple years though |
21:23:36 | Araq | she couldn't handle our dongle jokes |
21:23:41 | Varriount | Araq: Is there a better way to do this: https://gist.github.com/Varriount/fb62e4262efd18d7195b |
21:23:47 | Araq | (nah, just kidding) |
21:23:52 | gokr1 | Yeah... its the same everywhere it seems. Truly a pity. I mean, there are very few female programmers in general (at least in Sweden) but I guess even fewer in the open source arena. |
21:24:09 | gokr1 | I do guess there are more in say India though. |
21:24:10 | * | ChanServ joined #nimrod |
21:26:16 | Araq | Varriount: the basic idea is right but your 'else' won't work |
21:26:17 | * | Matthias247 quit (Read error: Connection reset by peer) |
21:26:52 | Araq | gokr1: I don't think the world needs more people spending way too much time in front of computers. |
21:27:14 | fowl | gokr1, c++ wrappers are possible, but some of c++s features are unwieldy |
21:27:15 | gokr1 | good point, but its still... a problem I think. |
21:27:19 | Araq | so if girls do not want to program, that's a smart and wise decision. |
21:27:57 | gokr1 | fowl: I saw you played with wrapping Horde3D? |
21:28:06 | fowl | agreed, i dont recommend people start programming or smoking |
21:28:10 | fowl | they're terrible habits |
21:28:44 | fowl | gokr1, i wrapped it but didnt do anything with it |
21:29:19 | gokr1 | We are interested in the Urho3D engine. Well, more than interested. |
21:33:00 | * | itsmeront joined #nimrod |
21:38:11 | * | Trustable quit (Quit: Leaving) |
21:43:06 | Araq | reactormonk: I see you summoned ChanServ |
21:44:49 | Varriount | Araq: So, for the string reuse, what should I do? Simply leave the passed data unchanged, and check for null? |
21:45:41 | Varriount | Or always return a string, which may or may not be the second argument? |
21:47:24 | reactormonk | Araq, yup, the guard worked |
21:47:30 | reactormonk | still getting the forward figured out |
21:48:34 | reactormonk | oops |
21:50:02 | * | boydgreenfield joined #nimrod |
21:50:15 | * | Fr4n quit (Ping timeout: 244 seconds) |
21:50:36 | boydgreenfield | Hi – is there a quick summary of the best way to upgrade to v0.9.6 anywhere? And specifically whether I should be using `babel` or `nimble` (this broke a bunch of my CI scripts)? |
21:52:46 | Varriount | boydgreenfield: nimble only works for BigBreak, afaik. |
21:53:09 | boydgreenfield | Varriount: OK. So check out v0.4? And BigBreak will be 0.10.0? |
21:53:19 | reactormonk | Araq, do you have op in #nim ? |
21:55:05 | * | itsmeront quit (Ping timeout: 265 seconds) |
21:57:40 | Araq | reactormonk: nope. but dom96 might have |
21:58:22 | Araq | boydgreenfield: bigbreak will be 0.10.0 yes. in fact, it's feature complete. |
21:58:45 | reactormonk | Araq, need it to set up the forward |
21:59:15 | boydgreenfield | Araq: Ah, that’s very good to hear. If I’m moving things from ~v0.9.5 should I go straight to 0.10.0 then? (And, dare I ask, is there a scheduled date for that?) |
21:59:59 | Araq | boydgreenfield: you can definitely do that |
22:00:35 | Varriount | Araq: How about this: https://gist.github.com/Varriount/3a2274acd2375dd71e21 |
22:01:34 | Araq | Varriount: dest.len >= src.len # logic wrong? |
22:02:43 | Varriount | Araq: The destination string needs to have already allocated an equal or greater amount of memory than the source string. |
22:03:35 | Araq | Varriount: yes, but look at your gist |
22:03:44 | Araq | you copy the pointer then |
22:04:56 | fowl | gokr1, urho looks nice |
22:05:08 | Varriount | Araq: I still don't see what's wrong. |
22:08:15 | boydgreenfield | Araq: Fantastic. Is it going to be imminently tagged v0.10 or in a few weeks? (Just deciding if it makes sense to wait a few days to roll everything forward or not) |
22:09:41 | * | dom96_ quit (Ping timeout: 260 seconds) |
22:10:04 | * | dom96_ joined #nimrod |
22:11:31 | Araq | boydgreenfield: well I think it's done, but experience suggests that means "few weeks to go" |
22:12:16 | boydgreenfield | Araq: Fair enough. I’ll keep my CI running on the latest to monitor for breakage, and pin anything going near production to the most recent commit. Thanks! |
22:13:13 | boydgreenfield | Araq: I need to clone -b bigbreak on csources as well yes? |
22:14:05 | boydgreenfield | Or is devel/bigbreak now the same post 0.9.6? |
22:14:20 | boydgreenfield | (nevermind that’s obviously false) |
22:18:42 | gokr1 | boydgreenfield: On csources - yes. |
22:20:06 | gokr1 | fowl: Yes, very nice. I looked at TONS of engines... but then Urho (kinda like Nim) was truly under the radar - but its very, very good. |
22:20:12 | gokr1 | Code is clean as hell. |
22:21:50 | * | BlaXpirit quit (Quit: Quit Konversation) |
22:30:13 | * | irrequietus quit () |
22:30:50 | dom96_ | Araq: reactormonk: are you guys redirecting this channel already? |
22:31:31 | Onionhammer | fowl you should integrate your cizzle library into clibpp and rename the macro to "clib" |
22:31:41 | Araq | boydgreenfield: we haven't merged bigbreak into devel yet. In fact, I'm not sure it's a good idea. |
22:34:58 | Onionhammer | araq any thoughts on my Q up there? (re push pragmas) |
22:35:19 | Onionhammer | local {importc} should override {push} no? |
22:35:29 | Onionhammer | pushed {importc} that is |
22:35:49 | fowl | Onionhammer, i havent used cizzle since i learned how to use {.push.} properly, you can take the code and do whatever with it |
22:37:23 | Onionhammer | fowl okay, I wrote something very similar but then I saw cizzle |
22:37:29 | fowl | Onionhammer, push callconv:cdecl,dynlib:libname first then push importc, functions which c name clashes with nim go at the end (after one pop) |
22:38:12 | Onionhammer | mm |
22:38:13 | fowl | Onionhammer, iirc cizzle is a better solution though, it probably checks if theres an importc pragma |
22:38:44 | Onionhammer | it'd be nice to have a kind of C equivalent of clibpp, thats all im really looking to do |
22:38:50 | Onionhammer | and cizzle looks close |
22:39:32 | reactormonk | dom96_, gimme op in #nim |
22:39:33 | fowl | use it and take pointer_arithm too |
22:39:42 | Araq | Onionhammer: oh sorry, I think it's simply a bug. but note that 'push' is rather misdesigned anyway. |
22:39:56 | Araq | and I wouldn't do it again this way |
22:40:00 | dom96_ | reactormonk: I can't right now. Also, I was going to redirect it myself. |
22:40:05 | Onionhammer | gotcha |
22:40:15 | dom96_ | Kinda rude not to even ask me... |
22:40:20 | Onionhammer | araq i wouldnt like to see it in code that doesnt involve wrappers |
22:42:49 | Araq | Onionhammer: yeah that too |
22:43:02 | reactormonk | dom96_, sure, feel free to do it yourself. gave you the permissions on this channel for it |
22:43:15 | reactormonk | dom96_, /msg chanserv set #nimrod mlock +if #nim |
22:43:34 | reactormonk | kicked myself from this channel |
22:43:41 | reactormonk | ... as in chanserv. |
22:43:41 | dom96_ | reactormonk: In any case I was going to wait until the official release of Nim 0.10.0 |
22:43:49 | dom96_ | It's still not officially Nim. |
22:46:24 | reactormonk | dom96_, kk |
22:48:31 | Araq | oh yeah, I agree with dom96_ |
22:55:20 | * | itsmeront joined #nimrod |
22:58:43 | * | dom96__ joined #nimrod |
23:00:14 | * | dom96_ quit (Ping timeout: 245 seconds) |
23:10:17 | * | bjz quit (Ping timeout: 245 seconds) |
23:10:57 | * | flaviu quit (Read error: Connection reset by peer) |
23:11:46 | * | boydgreenfield quit (Quit: boydgreenfield) |
23:13:47 | * | flaviu joined #nimrod |
23:15:01 | * | Etheco quit (Quit: Leaving) |
23:17:08 | * | xenagi joined #nimrod |
23:27:58 | * | flaviu quit (Read error: Connection reset by peer) |
23:30:03 | * | flaviu joined #nimrod |
23:40:30 | * | darkf joined #nimrod |
23:46:51 | ldlework | fowl: hi |
23:47:06 | fowl | ldlework, hi |
23:47:44 | ldlework | fowl: I cannot read Nim yet, but someone pointed out to me that you implemented an ECS system |
23:47:54 | * | Amrykid quit (Excess Flood) |
23:48:04 | Araq | he means "entity system" |
23:48:07 | ldlework | fowl: can you tell me a little about your implementation? |
23:48:15 | * | Amrykid joined #nimrod |
23:48:42 | * | saml_ joined #nimrod |
23:49:08 | fowl | ldlework, it uses the type system so that a component is a type and an entity is a combination of components |
23:51:06 | ldlework | fowl: so I have approached some programmers of other languages and posed them with the problem of how to implement a type safe ECS |
23:51:36 | ldlework | fowl: in go, reflection seems to be the answer; in rust.. well the guy implemented a distributed database that I couldn't understand |
23:51:55 | fowl | each component can have methods attached to it, when a dynamic type is created, these are sorted out and available for the entity to use |
23:51:58 | ldlework | fowl: what is the basic data structure at play? Are entities just an ID? How do you store the components? |
23:52:13 | fowl | ah ok |
23:52:58 | fowl | what you get back is a TypeInfo and pointer to the entities data |
23:53:06 | ldlework | fowl: in the ECS I understand, each entity is just an id, an index into some structure holding the components. |
23:53:22 | ldlework | then the only code allowed to couple itself to components are "Systems" |
23:53:34 | ldlework | which start off by requesting all the entities that satisfy a list of component dependencies |
23:53:50 | ldlework | like Physics might require Transform + Velocity, Graphics might require Transform + Sprite |
23:53:52 | ldlework | and so on |
23:53:59 | ldlework | so the entities are essentially non-existent |
23:54:06 | ldlework | I take it this isn't much how you went about it? |
23:54:17 | ldlework | (since entities have methods exposed to them by components, etc) |
23:55:02 | Araq | ldlework: tuple of typeinfo + pointer is what is used in some commercial game engines |
23:55:03 | fowl | no, systems would be the next step |
23:55:29 | ldlework | So I wonder what the hell is with go and rust, why don't they just use this "typinfo" thing? |
23:55:39 | ldlework | Is typeinfo a value representing the type? |
23:55:48 | fowl | ldlework, go doesnt have true generic functions |
23:56:09 | ldlework | fowl: finding the intersection of entities that satisfy a list of component dependencies seems to be the tricky part |
23:56:18 | ldlework | since systems will do this a lot |
23:56:35 | ldlework | the guy in #rust implemented it as a bitvector index into a table of components.. or something |
23:57:09 | ldlework | I'm interested in the simple typeinfo + point |
23:57:12 | ldlework | er |
23:57:46 | fowl | ldlework, ok so when a new typeinfo is needed say for components A, B and D, it stores them in a single block of memory sizeof(A) + sizeof(B) + sizeof(D) long, there is a list of offsets so that fetching data is done by entity.data[entity.typeinfo.offsets[componentID(A)]] casted to "ptr A" |
23:58:21 | ldlework | do you have to perform this cast yourself? |
23:58:31 | ldlework | duh probably |
23:58:38 | fowl | no, you use entity[A] to fetch its A value |
23:58:46 | fowl | or entity.get(A) |
23:58:58 | ldlework | wow and you magically get back a value already cast to A? |
23:59:42 | fowl | https://bitbucket.org/fowlmouth/entoody/src/72d7cc13e6f2dbfed4591eb62a601fbfcde6269b/src/entoody.nim?at=master#cl-609 |