| 00:00:14 | ldlework | fowl: hmm 'typoinfo' corresponds not to an individual Component type? |
| 00:00:42 | Varriount | fowl: You seem to be working with dark and mysterious forces. Go carefully. :P |
| 00:01:07 | fowl | no, typeinfo is created when a new combination of components is used |
| 00:01:13 | ldlework | fowl: fascinating |
| 00:01:18 | fowl | its quite a fat structure |
| 00:01:20 | ldlework | so its like a composite index |
| 00:01:48 | ldlework | fowl: is this how you will efficiently 'look up' entities that satisfy some 'aspect' (combination of components)? |
| 00:02:07 | ldlework | By simply 'caching' the entities which satisfy any possible 'aspect' (or typedef as you call them) ? |
| 00:02:31 | fowl | well you could check if entity.hascomponent(T) for each component |
| 00:02:46 | ldlework | fowl: but you already have this value which represents the combination of some components |
| 00:03:00 | fowl | thats outside of scope of aggregating components though |
| 00:03:03 | ldlework | couldn't you create a hash m[TYPEDEF(a, b, c)] = vecofentities |
| 00:03:29 | ldlework | fowl: so when a system needs components that have a,b,c there you go, you have a cache right there? |
| 00:03:58 | ldlework | fowl: are you saying "That's an optimization irrelevant to the abstract thing we're talking about right now" ? |
| 00:04:15 | fowl | ldlework, yes but looking up the relevant entities each time would be costly, it would be better if a system subscribed to the creation/deletion of entities and stored its own record of what it cares about, no? |
| 00:04:49 | ldlework | fowl: can we call a specific combination of components an 'aspect'? |
| 00:05:02 | ldlework | fowl: well, what if multiple systems care about the same aspect? |
| 00:05:27 | ldlework | It seems having some freely available cache, managed by the system that adds and removes components, would be best? |
| 00:05:46 | ldlework | Let say on start up, all systems register what 'aspects' they are interested in |
| 00:05:53 | ldlework | as the ECS adds and removes components from entities |
| 00:06:05 | ldlework | it tracks which components end up belonging to particular aspects |
| 00:06:13 | ldlework | then your 'systems' don't have to care about this busywork at all |
| 00:06:22 | ldlework | they just say "Give me all the components with Transform and Sprite" |
| 00:06:24 | ldlework | and then it renders them |
| 00:06:43 | fowl | what if multiple systems care about the same aspect? -- write less generic code, this is another reason you dont see a system handler there, anything i could write would be too generic for everybody |
| 00:06:45 | Varriount | Hm.. Isn't that how Artemis (from java) does it? |
| 00:06:59 | ldlework | fowl: I don't understand |
| 00:07:32 | ldlework | fowl: I'm just moving responsibility around |
| 00:08:29 | ldlework | if we keep all the ecs book-keeping in one place (1: adding and removing components 2: tracking which components adhere/fufill certain aspects (component combos) 3: gathering entities which satisfy aspects) in one place |
| 00:08:49 | ldlework | it seems like your Systems, like Graphics and Physics, and so on can just focus on being game logic |
| 00:09:12 | ldlework | instead of each having to do this book-keeping of listening to and responding to remote messages |
| 00:09:16 | ldlework | imagine an entity is being created |
| 00:09:20 | ldlework | an event is emitted |
| 00:09:27 | ldlework | the Physics system has to listen to that event |
| 00:09:30 | ldlework | consider whether it cares |
| 00:09:43 | ldlework | and if it does, remember that Entity1 has gained a transform component |
| 00:09:49 | ldlework | Physics doesn't know whether this entity is relevant yet |
| 00:09:57 | ldlework | since Physics also cares about velocity component |
| 00:10:12 | ldlework | so it has to wait around tracking Entity1 to see if it also gets a Velocity component |
| 00:10:16 | ldlework | etc etc |
| 00:10:21 | ldlework | it seems best to generalize all of this |
| 00:10:30 | Araq | ha, I often wonder if fowl is the best Nim programmer out there :-) |
| 00:10:32 | ldlework | so each System just uses the ECS as a service |
| 00:10:37 | fowl | well thats not hard |
| 00:11:16 | fowl | but its not written yet |
| 00:11:22 | ldlework | fowl: understood |
| 00:11:44 | ldlework | fowl: I would love to collaborate with you, but do you feel you were headed in a different direction than the impressions I've been putting forth? |
| 00:13:50 | ldlework | thanks for the explanations too |
| 00:14:49 | fowl | ldlework, no, we can collaborate, 1 sec im looking for one of my projects |
| 00:15:23 | ldlework | fowl: its fascinating to me that your components have methods and the entities can use those methods |
| 00:15:49 | Varriount | I wonder if these entity paradigms will become the next big paradigm (a la object orientation) |
| 00:16:13 | ldlework | Varriount: eh, in the sense that you're literally crafting new types at runtime, I don't think so |
| 00:16:13 | Araq | Varriount: they already are. |
| 00:16:29 | ldlework | mere composition however, I think is already |
| 00:17:03 | Araq | fowl: you need to update your code to use 'declared' instead of 'defined' |
| 00:17:08 | ldlework | I think ECS systems in the way that were just described are really more useful for driving your game with data, etc |
| 00:17:54 | fowl | ldlework, in lieu of a rendering system i can just define a draw method for Sprite, and Sprite can just require Transform, since every object will use Transform (Unity wont let you disable this component on game objects) |
| 00:18:14 | ldlework | fowl: yeah but that's just a detail |
| 00:18:44 | ldlework | I mean |
| 00:18:58 | ldlework | I don't think its bad that components have methods for doing things relevant to their nature |
| 00:19:02 | Varriount | Araq: declared is when a symbol exists, defined is when it actually has a value, right? |
| 00:19:09 | ldlework | but they should essentially an api for Systems to utilize |
| 00:19:22 | fowl | Araq, alright |
| 00:19:26 | ldlework | fowl: rather than say the traditional loop over all the entities and call update on them |
| 00:20:04 | ldlework | fowl: in an ECS system, you loop over your systems, and they simply do whatever they need to with the entities that satisfy the components they require |
| 00:20:23 | fowl | ldlework, depends on the scope of the game, for tetris loops are fine, if you have an expansive world with unseen rooms then you need to optimize a bit |
| 00:20:45 | ldlework | Sure but you can optimize in either case |
| 00:20:56 | ldlework | by taking subsets of all the entities in The Game |
| 00:21:02 | ldlework | but its a question of what drives behavior |
| 00:21:22 | ldlework | Do you go to each entity and say 'Well what're you gonna do now?' |
| 00:21:50 | ldlework | Or do you go to each system, who says (for example in the case of the rendering system) "Okay everyone, who's renderable?' |
| 00:22:03 | ldlework | or 'Who's poisoned?' |
| 00:22:16 | ldlework | or 'Who's got a velocity and acceleration?' |
| 00:22:19 | ldlework | and so on |
| 00:23:04 | fowl | and you add a new system for each new behavior |
| 00:23:09 | Araq | Varriount: no declared is for Nim symbols, defined is for -d:foo command line options |
| 00:23:18 | ldlework | fowl: yes |
| 00:23:41 | ldlework | fowl: this destroys problems with interoperation between components |
| 00:23:46 | ldlework | because now components are just dumb state |
| 00:23:48 | fowl | then you update your main loop - but its not like a real main loop because it just calls into systems, in order, update, draw, repeat, but its not a main loop |
| 00:23:54 | ldlework | that disjoint systems can utilize |
| 00:24:04 | ldlework | fowl: precisely |
| 00:24:47 | fowl | well nothing forces you from not defining methods |
| 00:24:53 | ldlework | where as, if you have implementation on your components, then that component's implementation has to work in all the contexts where the component's state is required |
| 00:25:02 | ldlework | fowl: sure, I'm not saying you shouldn't have supported it |
| 00:25:17 | ldlework | I'm just explaining why methods on components isn't part of the standard ECS model/spec/whatever |
| 00:25:24 | ldlework | Its like you went above and beyond |
| 00:25:44 | ldlework | Maybe a Transform component has lots of helper methods for manipulating the transform, etc |
| 00:26:28 | Araq | Varriount: when defined(release) and declared(strutils.toLower) ... |
| 00:29:44 | ldlework | fowl: are there any capable 2D graphics libraries for Nim? |
| 00:30:22 | Araq | ldlework: the real question is "what hasn't been wrapped already"? |
| 00:30:47 | * | Fr4n joined #nimrod |
| 00:30:47 | Araq | ;-) |
| 00:31:04 | ldlework | Okay how about SDL and/or libtcod? |
| 00:31:11 | * | ldlework googles |
| 00:31:20 | ldlework | nice |
| 00:31:22 | ldlework | haha |
| 00:31:58 | ldlework | fowl: does your implementation make heavy use of macros? |
| 00:38:54 | * | willwillson quit (Ping timeout: 256 seconds) |
| 00:40:00 | fowl | it does |
| 00:40:52 | fowl | i've got to go pick up a pizza, bbiab |
| 00:41:42 | Araq | good night |
| 00:42:28 | Onionhammer | is importc broken? |
| 00:42:56 | Onionhammer | i'm specifying a name proc foo() {.importc: "foo_bar".} |
| 00:43:08 | Onionhammer | and nim is generating "foo()" calls in the generated c |
| 00:43:14 | Onionhammer | rather than "foo_bar()" |
| 00:44:25 | ldlework | Can anyone compare rust and nim for me? Has this comparison been made somewhere I can go read? |
| 00:45:56 | ldlework | found some |
| 00:46:14 | * | boydgreenfield joined #nimrod |
| 00:51:53 | * | mko quit (Quit: Bye.) |
| 00:56:35 | * | shodan45 quit (Quit: Konversation terminated!) |
| 01:01:32 | * | Jesin quit (Ping timeout: 245 seconds) |
| 01:03:06 | itsmeront_ | Hi All. Trying to install nimble on bigbreak. Getting /lib/puresockets.nim(148,8) Error: invalid type: 'Socket'. |
| 01:04:32 | itsmeront_ | is nimble not yet compatible with bigbreak? |
| 01:04:59 | boydgreenfield | So nim.cfg should have a babelpath or a nimblepath or both? I believe it works w/ both but haven’t really dug into the compiler code. Submitting a PR to bigbreak now that allows the compiler to find the nimble-installed packages automatically. (But I’m not 100% clear on what would happen if you had .babel and .nimble installs – seems to work when I test locally a having both, but I don’t know the selection logic) |
| 01:05:28 | boydgreenfield | itsmeront_: I just got it to compile from ecd78e0e0300a8178db320d83014d3eb47a89b4c |
| 01:05:41 | boydgreenfield | but nim doesn’t find nimble-installed packages w/ the default config |
| 01:05:44 | itsmeront_ | ok I'll try that |
| 01:05:45 | boydgreenfield | (just submitted a PR) |
| 01:06:21 | ldlework | the {. XXX .} syntax is funky |
| 01:07:48 | boydgreenfield | https://github.com/Araq/Nimrod/pull/1586 |
| 01:10:24 | boydgreenfield | (If any of the folks with merge priveleges are on, would love to get this in asap – otherwise will probably postpone porting code to 0.10 because manually editing the config files on every box is kind of a pain/error-prone) |
| 01:14:03 | itsmeront_ | looked at your path, and changed the config. I loaded nimble ecd78 but still get the Type error: Socket on bigbreak |
| 01:14:15 | itsmeront_ | s/path/patch |
| 01:14:53 | itsmeront_ | did the Socket type name change in bigbreak? |
| 01:20:01 | boydgreenfield | itsmeront_: What commit are you on for bigbreak? |
| 01:22:10 | boydgreenfield | itsmeront_: Here is verbatim my install: git clone -b bigbreak git://github.com/Araq/Nimrod.git && cd Nimrod && git checkout 201d3c9ed0dac94a337f23416c556b45f7fc1138 && git clone -b bigbreak --depth 1 git://github.com/nimrod-code/csources && cd csources&& git checkout b0bcf88e26730b23d22e2663adf1babb05bd5a71 && sh build.sh && cd ../ && ./bin/nimrod c koch && ./koch boot -d:release |
| 01:22:19 | boydgreenfield | (sorry let me send you a gist) |
| 01:22:26 | itsmeront_ | current commit from today: 201d3c9ed |
| 01:23:22 | * | vendethiel quit (Quit: q+) |
| 01:24:12 | itsmeront_ | yeah those versions match what I built |
| 01:24:13 | boydgreenfield | https://gist.github.com/boydgreenfield/c95c0acd016389b038b1 |
| 01:24:27 | boydgreenfield | itsmeront_: What OS? I did it on Mac + Ubuntu |
| 01:24:42 | itsmeront_ | I'm on Ubuntu 14.04 |
| 01:24:59 | boydgreenfield | itsmeront_: Hmm me too. Twice actually (once in a Docker container, once on a box) |
| 01:25:17 | itsmeront_ | odd |
| 01:25:33 | itsmeront_ | hmmm |
| 01:25:57 | itsmeront_ | I have master installed too maybe I messed something up |
| 01:26:03 | itsmeront_ | let me try it again |
| 01:33:30 | flaviu | I hope I'm not missing something, but how do I get the misc utilities that come with nim? |
| 01:36:31 | flaviu | Ok, so I have to build those seperatly |
| 01:40:54 | itsmeront_ | Thanks Nick! Worked as advertised |
| 01:43:29 | flaviu | Araq: I'm having trouble crashing nimrod i |
| 01:46:19 | * | superfunc__ joined #nimrod |
| 01:46:24 | itsmeront_ | Flaviu did you see babel/nimble? |
| 01:46:35 | flaviu | hmm? |
| 01:47:16 | itsmeront_ | babel on 0.9 nimble on 0.10 |
| 01:47:18 | flaviu | Yep |
| 01:47:29 | itsmeront_ | ok good |
| 01:47:31 | flaviu | I'm having trouble compiling c2nim though |
| 01:48:51 | itsmeront_ | babel install c2nim? |
| 01:49:13 | itsmeront_ | (or nimble install c2nim) |
| 01:49:39 | NimBot | Araq/Nimrod bigbreak 9025e89 Nick Greenfield [+0 ±1 -0]: Add nimblepath so Nim can find Nimble-installed packages out-of-the-box |
| 01:49:39 | NimBot | Araq/Nimrod bigbreak b4b7572 Varriount [+0 ±1 -0]: Merge pull request #1586 from boydgreenfield/bigbreak... 2 more lines |
| 01:49:51 | flaviu | Error: cannot open 'llstream' |
| 01:49:58 | Varriount | boydgreenfield: Ta-da! |
| 01:50:00 | flaviu | It can't find the compiler path I think |
| 01:50:06 | superfunc__ | thanks for pushing that change boydgreenfield |
| 01:50:13 | superfunc__ | I meant to do that the other day and forgot |
| 01:50:17 | itsmeront_ | :) |
| 01:50:35 | itsmeront_ | flaviu see: http://goran.krampe.se/2014/10/16/nim-wrapping-c/ |
| 01:51:55 | flaviu | Thanks, -p should work |
| 01:52:02 | flaviu | I was searching for that in the compiler docs |
| 01:54:00 | * | dom96__ quit (Remote host closed the connection) |
| 01:54:55 | * | dom96_ joined #nimrod |
| 01:55:39 | superfunc__ | dom96__: question, are we going to want to go through and update the naming conventions throghout the stdlib before 1.0 to match the new conventions? |
| 01:55:56 | superfunc__ | I noticed it because of the descrepencies in the posix stuff |
| 01:59:50 | fowl | ldlework, check this out https://github.com/fowlmouth/roids its a fairly big ECS game |
| 02:00:15 | ldlework | fowl: I don't have nim setup |
| 02:00:42 | ldlework | interesting, https://github.com/fowlmouth/roids/blob/master/data/alphazone/entities/bullets.json |
| 02:00:48 | fowl | game objects are described in JSON |
| 02:03:37 | ldlework | fowl: what role do messages play for you? |
| 02:03:43 | ldlework | in your ECS systems |
| 02:06:08 | fowl | they either implement some behavior or act as safe accessors for data |
| 02:06:49 | ldlework | fowl: what does safe accessors for data mean? |
| 02:07:00 | fowl | safe in the sense that if the entity doesnt respond to the message it will not do anything (return a blank object) |
| 02:07:47 | fowl | i have defined a message getName that returns TMaybe[string], if its not implemented i get Nothing, otherwise i get Just(name) |
| 02:08:23 | ldlework | Shouldn't the attributes of Component types be known to the code that utilizes those components? |
| 02:08:34 | ldlework | Do the attributes of components change in your system? |
| 02:09:14 | fowl | ldlework, no but i dont prevent entities from changing types |
| 02:09:32 | ldlework | fowl: ...changing types? |
| 02:09:48 | fowl | all it takes is a memcopy here, maybe a couple destructors and initializers |
| 02:10:12 | fowl | ldlework, yes you can add or remove components freely |
| 02:10:13 | ldlework | fowl: what do you mean an entity changes type? |
| 02:10:21 | flaviu | Does anyone have any idea what "Error: ';' expected" means in c2nim? My header simple |
| 02:10:28 | flaviu | *is simple |
| 02:10:40 | ldlework | fowl: ah so in your system that changes the 'typedef' or whatever? |
| 02:10:48 | fowl | flaviu, its probably on a line with a macro invocation |
| 02:10:59 | flaviu | LIBSSH_API int ssh_blocking_flus^h(ssh_session session, int timeout);, caret signifies the position of the error |
| 02:11:22 | fowl | just remove the libssh_api |
| 02:11:33 | fowl | ldlework, yea |
| 02:11:33 | flaviu | fowl: thanks! |
| 02:13:31 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 02:14:41 | ldlework | fowl: so earlier I conjectured that having an enum for each set of required components would allow you to index an entitys by what aspects they implemented |
| 02:15:02 | ldlework | fowl: I get the impression you're not using them for this and that these typedef's are used for something else |
| 02:16:40 | fowl | there is no management of entities |
| 02:19:34 | ldlework | fowl: ah right |
| 02:19:36 | fowl | i do store a hash of component sets to typeinfos, so that a type doesnt get generated twice |
| 02:20:08 | ldlework | What exactly utility to the typeinfos serve? |
| 02:21:29 | fowl | they store the offsets, where each component is in the entities data |
| 02:21:42 | * | boydgreenfield joined #nimrod |
| 02:22:10 | fowl | and vtables, all the messages relevant to the entity |
| 02:23:31 | ldlework | Its really like you're implementing an object system |
| 02:24:43 | * | Boscop__ joined #nimrod |
| 02:27:07 | fowl | ldlework, this is based on a design originally in c++ |
| 02:27:40 | fowl | zahary's team used it in a few big games iirc |
| 02:28:11 | * | Boscop_ quit (Ping timeout: 272 seconds) |
| 02:28:48 | fowl | ldlework, btw i played with 3 or 4 ecs designs before i settled with this one |
| 02:28:52 | fowl | brb smoking |
| 02:32:18 | ldlework | fowl: I guess I don't see a problem with what you've told me, I more care about if you will support Systems being able to query for relevant Entities with the right typedefs |
| 02:32:29 | ldlework | fowl: in your system, can an entity have more than one typedef? |
| 02:38:00 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 02:39:14 | * | flaviu quit (Remote host closed the connection) |
| 02:41:05 | * | Jesin joined #nimrod |
| 02:43:09 | * | boydgreenfield joined #nimrod |
| 02:47:50 | boydgreenfield | Varriount: Thanks! |
| 02:55:39 | fowl | ldlework, no only one type has the right memory layout for that entity |
| 02:56:57 | ldlework | fowl: okay so this would seem to create some problems? |
| 02:57:03 | ldlework | what if an entity has 5 components |
| 02:57:14 | ldlework | but some system only cares about two of the entity's components? |
| 02:57:16 | fowl | if you want to implement systems its easy, just provide your own newEntity() where you detect its aspects and store it accordingly |
| 02:57:22 | * | hsuh quit (Ping timeout: 245 seconds) |
| 02:57:58 | * | hsuh joined #nimrod |
| 03:02:16 | ldlework | fowl: anywhere I can read about the specific design you're using? |
| 03:03:01 | fowl | ldlework, roids has systems, updateSystem, physicsSystem, rendersystem |
| 03:03:29 | ldlework | fowl: how do the systems in roids gather the entities with the right components? |
| 03:04:41 | boydgreenfield | Is anyone else experiencing a weird git issue with nimble on recent versions? I get the following error sometimes (unfortunately appears non-deterministic :( ): `Cloning latest tagged version: expected SRV RR, found RR type 1` |
| 03:06:30 | fowl | ldlework, updatesystem applies to all entities, rendersystem uses a bbtree so that a rectangular viewport can be queried quickly |
| 03:07:28 | ldlework | fowl: yeahhh |
| 03:07:30 | fowl | ldlework, entity.hasComponents(A,B,C) |
| 03:09:49 | ldlework | fowl: imagine if each system registered what kind of entity pattern it wanted with some manager. then the System could do manager.entities_with(A, B, C) which would then find the right enum or whatever that represents the configuration of A + B + C, and it just does return self.all_entities_by_aspect[ABCAspect] |
| 03:10:59 | fowl | ldlework, please stop telling me to imagine things. i understand what you're describing, its not that novel and its totally possible. you should care more about nimrods awesome GC and metaprogramming |
| 03:11:21 | ldlework | fowl: sorry |
| 03:12:37 | fowl | ask the Go-getters what they offer for metaprogramming (hint: its nothing, you might find a pre-processor or something) and rusts macros are just plain eyesores |
| 03:13:40 | ldlework | fowl: I'm sure that Nim is nice, I'm new to statically typed languages in general, and trying to conceptualize ECS for myself |
| 03:14:07 | ldlework | if I'm repeating myself, its just because I'm interested in your reaction to these ideas is all |
| 03:15:13 | ldlework | I'm comparing how I understand it to what you're saying your implementation does just to ellucidate maybe what the pros and cons of doing it each way are |
| 03:15:17 | ldlework | thanks for talking it out |
| 03:19:27 | fowl | my goal with the design was not to reach too far, usually i store entities in a pool and refer to them by ID but thats not enforced, i wanted to avoid database.get(entityID, "Sprite") and that kind of design is not really reasonable in static typed languages |
| 03:20:47 | ldlework | wait you're saying my description isn't reasonable on static typed languages? |
| 03:21:45 | fowl | in entoody you can store nimrod types as in entity = newEntity(int, float) and you get a chunk of memory and behavior |
| 03:24:17 | fowl | ldlework, no i mean eventually ECS systems get to the point where they say we're storing each component as UUIDs and entity will just be a bunch of UUIDs to data -- do you need this much overhead in what is a desktop or mobile game? that design fits a database better |
| 03:25:30 | ldlework | fowl: I think modeling ECS as a database is exactly the point |
| 03:25:56 | ldlework | Its a very specific non-general database that performs a very specific lookup |
| 03:26:08 | ldlework | on exactly one kind of data, etc |
| 03:26:45 | fowl | i'll write it but i charge for a proof |
| 03:27:04 | fowl | wink |
| 03:27:50 | ldlework | fowl: here is a Rust implementation that I inspired someone to write, that is completely memory and thread safe, using mutexed bitvectors allowing any System code to make any sort of query against all entities: https://gist.github.com/pythonesque/7172ba9f4c1a79725de6#file-entity2-rs |
| 03:28:18 | ldlework | with 500 components and 10k entities, it consumes about 400k of memory it can perform upwards of 2 million querires a second in some artbitrary benchmark dude did |
| 03:28:30 | ldlework | (this is actually three different implementations, I'm referring to the first one) |
| 03:28:41 | ldlework | the problem is that I don't understand it at all :) |
| 03:29:53 | ldlework | You can see how entities are formed here, https://gist.github.com/pythonesque/7172ba9f4c1a79725de6#file-entity2-rs-L336 |
| 03:30:06 | ldlework | and an example system here: https://gist.github.com/pythonesque/7172ba9f4c1a79725de6#file-entity2-rs-L288 |
| 03:30:39 | ldlework | fowl: with this you could run everything in parellel, your rendering in one task, your simulation in another task |
| 03:31:45 | ldlework | not that that is needed for every game |
| 03:32:16 | ldlework | and this works fine synchrnously, but the point I guess is is that the db model is kind of expressive |
| 03:32:27 | ldlework | the internals are crazy, but the api that is exposed to the game code is quite nice |
| 03:33:22 | fowl | ok |
| 03:34:49 | ldlework | it sounds like I'm trying to remark about rust but really just wanted to show that the db concept isn't bad |
| 03:35:00 | ldlework | (in the context of statically typed langs) |
| 03:38:43 | * | superfunc__ quit (Quit: Page closed) |
| 03:39:08 | fowl | this might be possible with nimrods new async stuff |
| 03:42:38 | ldlework | honestly I never cared about the concurrent aspect |
| 03:42:45 | ldlework | I was explaining the ecs to the guy |
| 03:42:50 | ldlework | and he was like okay give me a few minutes |
| 03:42:57 | ldlework | and he came back with this |
| 03:42:59 | ldlework | heh |
| 03:43:07 | ldlework | and I was like, ack, I don't understand a lick of this |
| 03:43:22 | ldlework | that's why he wrote the sync version and the 'simple' versions below |
| 03:46:19 | fowl | i dont have that much enthusiasm anymore. i got a job and it broke my soul |
| 03:47:16 | fowl | i used to be able to bust out code faster than i could come up with analogies but im tired now ._. |
| 03:47:33 | ldlework | fowl: none of this is supposed to be comparative |
| 03:47:40 | ldlework | I'm just giving context is all |
| 03:47:43 | fowl | ldlework, i know |
| 03:47:54 | fowl | all i can think about is building robots to do my chores for me |
| 03:48:05 | ldlework | the dude was bit overt in his enthusiasm like he was waiting for me to come by and ask about ECS in rust, lol |
| 03:48:18 | ldlework | just so he had the chance to implement a database on the spot |
| 03:49:36 | fowl | it looks nice |
| 03:49:52 | fowl | i've never seen systems used for a huge game though |
| 03:50:45 | ldlework | fowl: well, consider unity |
| 03:50:59 | ldlework | in unity, it has the benefit of a scripting language ontop of the ecs I described |
| 03:51:09 | ldlework | so you can provide your own entities but also your own systems |
| 03:51:14 | ldlework | that use those entities |
| 03:51:56 | ldlework | if you allow systems to call other systems then it is the same as unity except all the ScriptObjects are built in |
| 03:52:11 | fowl | good luck writing the next Unity |
| 03:52:19 | ldlework | I don't want to at all :) |
| 03:52:21 | fowl | that is a beast right there |
| 03:52:32 | ldlework | I want my systems hardcoded into the game |
| 03:52:54 | ldlework | but its just showing that a standalone bit of procedural code that can call up entities with the right components is a workable paradigm |
| 03:53:14 | ldlework | systems querying entities with specific aspects, that is |
| 03:57:27 | fowl | it is possible |
| 03:57:54 | ldlework | Object.FindObjectsOfType(ComponentType) is practically cannon |
| 03:58:21 | ldlework | canon too |
| 04:01:08 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 04:01:13 | * | itsmeront_ quit (Quit: Page closed) |
| 04:01:56 | * | xenagi|2 joined #nimrod |
| 04:05:39 | * | xenagi quit (Ping timeout: 244 seconds) |
| 04:06:33 | * | xenagi|3 joined #nimrod |
| 04:07:21 | * | xenagi|3 quit (Client Quit) |
| 04:10:38 | * | xenagi|2 quit (Ping timeout: 265 seconds) |
| 04:11:50 | * | xenagi joined #nimrod |
| 04:12:31 | * | bjz joined #nimrod |
| 04:14:53 | * | saml_ quit (Quit: Leaving) |
| 04:16:05 | * | xenagi quit (Client Quit) |
| 04:36:10 | * | lazlo joined #nimrod |
| 04:36:37 | * | lazlo quit (Client Quit) |
| 04:41:07 | * | superfunc quit (Quit: Connection closed for inactivity) |
| 04:43:26 | * | itsmeront quit (Ping timeout: 265 seconds) |
| 04:51:56 | * | boydgreenfield joined #nimrod |
| 05:23:33 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 05:29:04 | * | ARCADIVS joined #nimrod |
| 06:06:04 | NimBot | Araq/Nimrod bigbreak 8a53732 Clay Sweetser [+0 ±1 -0]: Fixes #1583 |
| 06:06:04 | NimBot | Araq/Nimrod bigbreak 4046e40 Varriount [+0 ±1 -0]: Merge pull request #1587 from Varriount/fix-1583... 2 more lines |
| 06:10:15 | * | gokr quit (Ping timeout: 246 seconds) |
| 06:12:56 | * | gokr joined #nimrod |
| 06:22:27 | * | gokr_ joined #nimrod |
| 06:23:33 | * | gokr quit (Ping timeout: 246 seconds) |
| 06:24:48 | * | nande quit (Remote host closed the connection) |
| 06:32:39 | Varriount | Araq: What should the compiler do when it encounters an exported match to a non-exported forward declaration? |
| 06:47:30 | * | gokr joined #nimrod |
| 06:47:35 | * | Varriount quit (*.net *.split) |
| 06:47:36 | * | wan quit (*.net *.split) |
| 06:47:36 | * | comex quit (*.net *.split) |
| 06:47:37 | * | bjz quit (*.net *.split) |
| 06:47:37 | * | Fr4n quit (*.net *.split) |
| 06:47:38 | * | betawaffle quit (*.net *.split) |
| 06:47:39 | * | Pisuke quit (*.net *.split) |
| 06:47:40 | * | def- quit (*.net *.split) |
| 06:49:48 | * | gokr_ quit (Ping timeout: 246 seconds) |
| 07:00:23 | * | Fr4n joined #nimrod |
| 07:00:23 | * | Pisuke joined #nimrod |
| 07:00:23 | * | def- joined #nimrod |
| 07:00:23 | * | betawaffle joined #nimrod |
| 07:10:46 | * | bjz_ joined #nimrod |
| 07:10:46 | * | Varriount joined #nimrod |
| 07:10:46 | * | wan joined #nimrod |
| 07:10:46 | * | comex joined #nimrod |
| 07:16:54 | * | dtr joined #nimrod |
| 07:16:54 | * | dtr left #nimrod (#nimrod) |
| 07:17:54 | * | Pisuke quit (Max SendQ exceeded) |
| 07:23:37 | * | khmm joined #nimrod |
| 07:24:42 | gokr1 | Morning folks |
| 07:28:58 | * | bjz_ quit (*.net *.split) |
| 07:28:58 | * | Varriount quit (*.net *.split) |
| 07:28:58 | * | wan quit (*.net *.split) |
| 07:28:59 | * | comex quit (*.net *.split) |
| 07:29:00 | * | Fr4n quit (*.net *.split) |
| 07:29:01 | * | betawaffle quit (*.net *.split) |
| 07:29:02 | * | def- quit (*.net *.split) |
| 07:32:25 | * | Pisuke joined #nimrod |
| 07:32:25 | * | def- joined #nimrod |
| 07:32:25 | * | bjz_ joined #nimrod |
| 07:32:25 | * | Varriount joined #nimrod |
| 07:32:25 | * | wan joined #nimrod |
| 07:32:25 | * | comex joined #nimrod |
| 07:33:37 | * | Pisuke quit (Max SendQ exceeded) |
| 07:34:45 | * | darkf_ joined #nimrod |
| 07:35:14 | * | Pisuke joined #nimrod |
| 07:36:46 | * | def- quit (*.net *.split) |
| 07:37:32 | * | Fr4n joined #nimrod |
| 07:37:32 | * | betawaffle joined #nimrod |
| 07:38:00 | * | darkf quit (Ping timeout: 244 seconds) |
| 07:40:06 | * | def- joined #nimrod |
| 07:40:24 | * | boydgreenfield joined #nimrod |
| 07:48:05 | * | Trustable joined #nimrod |
| 07:52:47 | gokr1 | Btw, -passC doesn't pass to cpp. Which of course is not a bug, but I see no -passCpp |
| 07:53:15 | gokr1 | I noticed my spawningserver has some issues in C++ |
| 07:58:22 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 08:11:33 | * | tdc joined #nimrod |
| 08:27:22 | * | Etheco joined #nimrod |
| 08:32:38 | gokr1 | Silly question. So... TaintedString."" ... what is that exactly? I do know TaintedString is an alias (or distinct type) of string. But... is TaintedString."" same as TaintedString("") and same as string("") and... what is that btw? |
| 08:32:42 | gokr1 | Confused :) |
| 08:33:39 | gokr1 | dom96_: Furthermore I think the new net code has issues with taintMode:on |
| 08:41:23 | * | itsmeront joined #nimrod |
| 08:42:03 | gokr1 | itsmeront: Morning :) |
| 08:43:56 | * | q66[lap] quit (Quit: Textual IRC Client: www.textualapp.com) |
| 08:57:20 | gokr1 | Ah, figured it out. So there is no dot - its TaintedString"" which is equal to TaintedString("") which in turn is a type conversion: http://nim-lang.org/manual.html#type-conversions |
| 09:53:24 | * | gokr quit (*.net *.split) |
| 09:53:24 | * | Jesin quit (*.net *.split) |
| 09:53:24 | * | [CBR]Unspoken quit (*.net *.split) |
| 09:53:52 | * | gokr joined #nimrod |
| 09:53:52 | * | Jesin joined #nimrod |
| 09:53:52 | * | [CBR]Unspoken joined #nimrod |
| 09:55:23 | * | def- quit (*.net *.split) |
| 09:56:08 | * | def- joined #nimrod |
| 09:58:16 | * | def- quit (*.net *.split) |
| 09:58:16 | * | gokr quit (*.net *.split) |
| 09:58:16 | * | Jesin quit (*.net *.split) |
| 09:58:17 | * | [CBR]Unspoken quit (*.net *.split) |
| 09:58:17 | * | bjz_ quit (*.net *.split) |
| 09:58:18 | * | Varriount quit (*.net *.split) |
| 09:58:18 | * | wan quit (*.net *.split) |
| 09:58:19 | * | comex quit (*.net *.split) |
| 09:58:19 | * | Etheco quit (*.net *.split) |
| 09:58:19 | * | Trustable quit (*.net *.split) |
| 09:58:20 | * | Fr4n quit (*.net *.split) |
| 09:58:21 | * | betawaffle quit (*.net *.split) |
| 09:58:21 | * | Boscop__ quit (*.net *.split) |
| 09:58:21 | * | milosn_ quit (*.net *.split) |
| 09:58:22 | * | khmm quit (*.net *.split) |
| 09:58:23 | * | darkf_ quit (*.net *.split) |
| 09:58:23 | * | Amrykid quit (*.net *.split) |
| 09:58:23 | * | paul_oyster quit (*.net *.split) |
| 09:58:24 | * | uber quit (*.net *.split) |
| 09:58:24 | * | ARCADIVS quit (*.net *.split) |
| 09:58:24 | * | johnsoft quit (*.net *.split) |
| 09:58:24 | * | Hodapp quit (*.net *.split) |
| 09:58:25 | * | saml quit (*.net *.split) |
| 09:58:25 | * | tdc quit (*.net *.split) |
| 09:58:26 | * | quasinoxen quit (*.net *.split) |
| 09:58:26 | * | JStoker quit (*.net *.split) |
| 09:58:27 | * | dom96 quit (*.net *.split) |
| 09:58:27 | * | clone1018_ quit (*.net *.split) |
| 09:58:27 | * | EastByte quit (*.net *.split) |
| 09:58:27 | * | CARAM quit (*.net *.split) |
| 09:58:29 | * | heinrich5991 quit (*.net *.split) |
| 09:58:29 | * | silven quit (*.net *.split) |
| 09:58:30 | * | Triplefox quit (*.net *.split) |
| 09:58:30 | * | Araq quit (*.net *.split) |
| 09:58:31 | * | Trixar_za quit (*.net *.split) |
| 09:58:32 | * | vissborg quit (*.net *.split) |
| 09:58:34 | * | hguux quit (*.net *.split) |
| 09:58:34 | * | woodgiraffe quit (*.net *.split) |
| 09:58:35 | * | clone1018 quit (*.net *.split) |
| 09:58:35 | * | ldlework quit (*.net *.split) |
| 09:58:36 | * | dom96_ quit (*.net *.split) |
| 09:58:36 | * | gokr1 quit (*.net *.split) |
| 09:58:36 | * | skroll1 quit (*.net *.split) |
| 09:58:37 | * | rektide quit (*.net *.split) |
| 09:58:37 | * | reloc0 quit (*.net *.split) |
| 09:58:38 | * | mal`` quit (*.net *.split) |
| 09:58:38 | * | Onionhammer quit (*.net *.split) |
| 09:58:38 | * | untitaker quit (*.net *.split) |
| 09:58:39 | * | delian66 quit (*.net *.split) |
| 09:58:39 | * | jez0990 quit (*.net *.split) |
| 09:58:39 | * | reactormonk quit (*.net *.split) |
| 09:58:41 | * | superfunc_ quit (*.net *.split) |
| 09:58:41 | * | ChanServ quit (*.net *.split) |
| 09:58:41 | * | Pisuke quit (*.net *.split) |
| 09:58:41 | * | hsuh quit (*.net *.split) |
| 09:58:44 | * | flyx quit (*.net *.split) |
| 09:58:55 | * | def- joined #nimrod |
| 09:58:55 | * | [CBR]Unspoken joined #nimrod |
| 09:58:55 | * | Jesin joined #nimrod |
| 09:58:55 | * | gokr joined #nimrod |
| 09:58:55 | * | Onionhammer joined #nimrod |
| 09:58:55 | * | mal`` joined #nimrod |
| 09:58:55 | * | reloc0 joined #nimrod |
| 09:58:55 | * | flyx joined #nimrod |
| 09:58:55 | * | rektide joined #nimrod |
| 09:58:55 | * | clone1018 joined #nimrod |
| 09:58:55 | * | Trixar_za joined #nimrod |
| 09:58:55 | * | woodgiraffe joined #nimrod |
| 09:58:55 | * | hguux joined #nimrod |
| 09:58:55 | * | CARAM joined #nimrod |
| 09:58:55 | * | reactormonk joined #nimrod |
| 09:58:55 | * | EastByte joined #nimrod |
| 09:58:55 | * | Araq joined #nimrod |
| 09:58:55 | * | skroll1 joined #nimrod |
| 09:58:55 | * | clone1018_ joined #nimrod |
| 09:58:55 | * | Triplefox joined #nimrod |
| 09:58:55 | * | jez0990 joined #nimrod |
| 09:58:55 | * | dom96 joined #nimrod |
| 09:58:55 | * | vissborg joined #nimrod |
| 09:58:55 | * | saml joined #nimrod |
| 09:58:55 | * | superfunc_ joined #nimrod |
| 09:58:55 | * | JStoker joined #nimrod |
| 09:58:55 | * | uber joined #nimrod |
| 09:58:55 | * | quasinoxen joined #nimrod |
| 09:58:55 | * | silven joined #nimrod |
| 09:58:55 | * | ldlework joined #nimrod |
| 09:58:55 | * | delian66 joined #nimrod |
| 09:58:55 | * | heinrich5991 joined #nimrod |
| 09:58:55 | * | Hodapp joined #nimrod |
| 09:58:55 | * | milosn_ joined #nimrod |
| 09:58:55 | * | untitaker joined #nimrod |
| 09:58:55 | * | paul_oyster joined #nimrod |
| 09:58:55 | * | gokr1 joined #nimrod |
| 09:58:55 | * | johnsoft joined #nimrod |
| 09:58:55 | * | ChanServ joined #nimrod |
| 09:58:55 | * | Amrykid joined #nimrod |
| 09:58:55 | * | dom96_ joined #nimrod |
| 09:58:55 | * | Boscop__ joined #nimrod |
| 09:58:55 | * | hsuh joined #nimrod |
| 09:58:55 | * | ARCADIVS joined #nimrod |
| 09:58:55 | * | khmm joined #nimrod |
| 09:58:55 | * | bjz_ joined #nimrod |
| 09:58:55 | * | Varriount joined #nimrod |
| 09:58:55 | * | wan joined #nimrod |
| 09:58:55 | * | comex joined #nimrod |
| 09:58:55 | * | darkf_ joined #nimrod |
| 09:58:55 | * | Pisuke joined #nimrod |
| 09:58:55 | * | Fr4n joined #nimrod |
| 09:58:55 | * | betawaffle joined #nimrod |
| 09:58:55 | * | Trustable joined #nimrod |
| 09:58:55 | * | tdc joined #nimrod |
| 09:58:55 | * | Etheco joined #nimrod |
| 10:00:18 | * | xcombelle joined #nimrod |
| 10:06:18 | * | xcombelle quit (Ping timeout: 265 seconds) |
| 10:11:39 | * | gokr1 quit (Remote host closed the connection) |
| 10:20:14 | * | woodgiraffe quit (Remote host closed the connection) |
| 10:22:23 | * | untitaker quit (Ping timeout: 240 seconds) |
| 10:23:17 | * | woodgiraffe joined #nimrod |
| 10:24:08 | * | untitaker joined #nimrod |
| 10:36:02 | * | khmm quit (Remote host closed the connection) |
| 10:51:39 | * | gokr_ joined #nimrod |
| 10:53:24 | * | gokr quit (Ping timeout: 246 seconds) |
| 10:55:21 | * | Boscop_ joined #nimrod |
| 10:59:24 | * | Boscop__ quit (Ping timeout: 256 seconds) |
| 11:05:20 | * | xcombelle joined #nimrod |
| 11:07:41 | * | gokr_ quit (Ping timeout: 258 seconds) |
| 11:09:52 | * | AMorpork joined #nimrod |
| 11:15:38 | * | khmm joined #nimrod |
| 11:16:45 | * | woodgiraffe quit (Remote host closed the connection) |
| 11:17:54 | * | woodgiraffe joined #nimrod |
| 11:35:10 | * | darkf_ is now known as darkf |
| 11:46:07 | * | dom96_ quit (Ping timeout: 245 seconds) |
| 12:16:19 | * | leehambley joined #nimrod |
| 12:16:22 | * | leehambley left #nimrod (#nimrod) |
| 12:16:55 | * | Perkol joined #nimrod |
| 12:17:33 | Perkol | Is Nimrod ready for production use? Is it good alternative to C? |
| 12:26:01 | * | saml_ joined #nimrod |
| 12:36:25 | * | BitPuffin joined #nimrod |
| 12:38:15 | * | irrequietus joined #nimrod |
| 12:48:34 | * | will joined #nimrod |
| 13:10:15 | * | dom96_ joined #nimrod |
| 13:10:27 | dom96_ | Perkol: In my opinion it is, |
| 13:27:20 | Trustable | dom96_, when can we talk about Aporia? |
| 13:28:35 | dom96_ | Trustable: Now if you want. I'm at a lecture but I can talk. |
| 13:28:55 | Trustable | What subject? |
| 13:29:18 | dom96_ | Fundamentals of Programming. Essentially just teaching Java. |
| 13:29:50 | * | darkf quit (Quit: Leaving) |
| 13:30:07 | Trustable | ok, no I understand why you can chat while a lecture :D |
| 13:31:00 | Trustable | Do you agree to set globalSettings.highlightCurrentLine = true by default? |
| 13:31:23 | dom96_ | sure. |
| 13:31:34 | Trustable | ok, I will make a PR |
| 13:31:49 | dom96_ | I think that's better than highlighting the line when you're jumping to a specific line. |
| 13:33:55 | * | Perkol quit (Quit: Leaving) |
| 13:34:48 | Trustable | ok, I will remove this feature from my PR https://github.com/nimrod-code/Aporia/pull/62 |
| 13:34:59 | * | saml_ quit (Quit: Leaving) |
| 13:36:09 | Trustable | What about my PR https://github.com/nimrod-code/Aporia/pull/63 ? Do you agree with functionality of it? |
| 13:44:37 | dom96_ | Yeah, as long as it's not on by default. |
| 13:52:43 | * | ARCADIVS quit (Quit: ARCADIVS) |
| 13:59:02 | * | gokr_ joined #nimrod |
| 14:00:40 | * | itsmeront_ joined #nimrod |
| 14:04:04 | dom96_ | gokr_: Many modules in the stdlib likely are broken with taintMode:on |
| 14:04:27 | gokr_ | sure |
| 14:09:04 | * | itsmeront_ quit (Ping timeout: 246 seconds) |
| 14:27:18 | * | gokr joined #nimrod |
| 14:27:21 | * | gokr_ quit (Read error: Connection reset by peer) |
| 14:31:59 | * | irrequietus quit () |
| 14:48:19 | * | itsmeront_ joined #nimrod |
| 14:48:48 | * | superfunc joined #nimrod |
| 14:52:59 | * | will quit (Ping timeout: 265 seconds) |
| 15:02:12 | * | gokr1 joined #nimrod |
| 15:14:26 | * | khmm_ joined #nimrod |
| 15:30:16 | * | itsmeront quit (Ping timeout: 258 seconds) |
| 15:34:25 | * | dom96_ quit (Quit: Page closed) |
| 15:42:44 | * | Hodapp quit (Ping timeout: 245 seconds) |
| 15:46:25 | * | Hodapp joined #nimrod |
| 15:54:22 | * | khmm_ quit (Ping timeout: 240 seconds) |
| 15:56:01 | * | khmm quit (Ping timeout: 260 seconds) |
| 16:01:03 | * | Hodapp quit (Ping timeout: 246 seconds) |
| 16:01:07 | * | Onionhammer quit (Ping timeout: 245 seconds) |
| 16:02:19 | * | Onionhammer joined #nimrod |
| 16:03:26 | * | Hodapp joined #nimrod |
| 16:05:19 | * | Demos joined #nimrod |
| 16:10:46 | * | Matthias247 joined #nimrod |
| 16:23:50 | Araq | hi AMorpork. nice nick |
| 16:24:51 | Araq | dom96: well I don't know. the tester uses taintMode:on so lot's of modules work with that switch |
| 16:26:50 | * | Jesin quit (Quit: Leaving) |
| 16:28:31 | * | Jesin joined #nimrod |
| 16:32:12 | Araq | "Fundamentals of Programming. Essentially just teaching Java." o.O |
| 16:32:29 | Araq | Java has nothing to do with "fundamentals of programming" |
| 16:33:25 | Araq | fundamentals of programming should be about computability |
| 16:49:40 | * | gokr1 quit (Quit: Leaving.) |
| 16:54:33 | * | gokr quit (Remote host closed the connection) |
| 16:54:46 | * | gokr joined #nimrod |
| 16:58:59 | * | gokr_ joined #nimrod |
| 16:59:00 | * | ldlework builds Nim |
| 17:01:30 | * | gokr quit (Ping timeout: 258 seconds) |
| 17:04:34 | ldlework | Can anyone give me a little bit of elevator pitch about Nimrod's type system? |
| 17:04:40 | ldlework | s/Nimrod/Nim |
| 17:09:02 | * | irrequietus joined #nimrod |
| 17:13:37 | gokr_ | Araq: I fixed some issues with the spawning server and the numbers are better. |
| 17:15:01 | * | Trustable_mobile joined #nimrod |
| 17:15:39 | * | xcombelle quit (Ping timeout: 245 seconds) |
| 17:17:29 | * | willwillson joined #nimrod |
| 17:20:19 | * | CaptainRant joined #nimrod |
| 17:24:00 | * | gokr joined #nimrod |
| 17:24:01 | ldlework | Do Nim's generics rely on reflection, etc? |
| 17:27:00 | * | untitaker quit (Ping timeout: 256 seconds) |
| 17:28:14 | ldlework | Sorry for my stupid questions :( |
| 17:30:13 | willwillson | generics are some what similar to c++ templates |
| 17:30:26 | * | CaptainRant left #nimrod ("WeeChat 0.4.3") |
| 17:33:13 | * | untitaker joined #nimrod |
| 17:34:07 | * | gokr quit (Read error: Connection reset by peer) |
| 17:38:20 | ldlework | Okay |
| 17:50:38 | * | nande joined #nimrod |
| 17:59:42 | * | ldlework just ran his first nimrod proram |
| 18:00:26 | * | Trustable_mobile quit (Quit: AtomicIRC: The nuclear option.) |
| 18:01:58 | * | tdc_ joined #nimrod |
| 18:03:52 | Demos | nim's type system is great because it does all of the stuff C++'s can (someone blog about how to do variadic generics with varargs[$] please) with very little noise. Note that C++ type system is more powerful than Haskell's afaik |
| 18:04:56 | * | paul_oyster quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 18:05:17 | * | tdc quit (Ping timeout: 260 seconds) |
| 18:15:37 | * | boydgreenfield joined #nimrod |
| 18:23:32 | * | xcombelle joined #nimrod |
| 18:30:52 | * | itsmeront_ quit (Ping timeout: 246 seconds) |
| 18:40:24 | superfunc | Lol C++s type system is not more powerful than Haskells, not even close |
| 18:42:27 | Demos | maybe it is just that I know c++'s type system way better, but I don't think haskell can do much to emulate compile time constant type params or varaidic type params |
| 18:45:40 | superfunc | Generic variadic were possible back in haskell98. |
| 18:45:50 | * | Varriount|Busy joined #nimrod |
| 18:46:12 | Varriount|Busy | Bloop. Hello my fellow Nimsters |
| 18:46:21 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 18:46:52 | superfunc | Moreover, I was speaking towards typeclasses(which c++ is getting, albeit uglier and less powerful) and proper ADTs which c++ can be hacked to emulate(also ugly) |
| 18:47:03 | Demos | superfunc, oh? I remember looking at haskell implementations of some of the things you might use variadics for and they were just like a bunch of different functions for different numbers of types |
| 18:47:34 | Demos | yeah, I think typeclasses are really nice, but not really required to do anything in particular |
| 18:47:41 | Demos | they are /really/ nice though |
| 18:48:50 | superfunc | Well yeah, nothing is required |
| 18:49:22 | superfunc | But yeah, variadics are one of the less elegant things to do in haskell |
| 18:49:34 | Demos | how do you even do them |
| 18:49:50 | ldlework | This fails, http://rosettacode.org/wiki/Hello_world/Graphical#Nimrod |
| 18:49:56 | Demos | the stuff I saw was bounded, like if you wanted n+1 params and there were only functions up to n you are kinda sunk |
| 18:50:05 | ldlework | lib/impure/dialogs.nim(15, 2) Error: cannot open 'glib2' |
| 18:50:12 | superfunc | With typeclasses |
| 18:50:23 | superfunc | So it's still limited |
| 18:50:50 | superfunc | Not truly generic like C++s for those |
| 18:50:53 | Demos | then why are there like 11 zipwithN functions in Data.List |
| 18:50:56 | Demos | yeah |
| 18:51:22 | superfunc | Given, I usually want to put constraints on my types, so it works out |
| 18:51:43 | * | Varriount|Busy quit (Quit: Page closed) |
| 18:51:52 | superfunc | Some crazy ahole has probably done something about it with quasi quoting lol |
| 18:52:02 | ldlework | Anyone know? |
| 18:52:05 | Demos | even so can you get a variadic that has constraints but each type may be a different type satisfying the typeclass? |
| 18:52:18 | * | Varriount|Busy joined #nimrod |
| 18:52:29 | Demos | ldlework, I think gtk and glib may have been moved out of the standard library |
| 18:52:52 | Demos | also you are going to need gtk available to run that sample. |
| 18:53:04 | Demos | Get the nim wrapper from our package manager, nimble |
| 18:53:05 | ldlework | I have gtk |
| 18:53:16 | Demos | https://github.com/nimrod-code/nimble |
| 18:53:21 | Demos | just to install the wrappers |
| 18:54:43 | ldlework | How do I actually install nim? I compiled it |
| 18:54:48 | ldlework | but how do I install it to my system? |
| 18:54:56 | Demos | just put it someplace on your path |
| 18:54:58 | superfunc | Demos: http://okmij.org/ftp/typed-formatting/FPrintScan.html#print-show |
| 18:55:21 | superfunc | It's an example of a variadic printf |
| 18:56:01 | * | tdc_ is now known as tdc |
| 18:56:06 | Demos | it uses template haskell though |
| 18:56:11 | superfunc | Yeah |
| 18:56:21 | superfunc | Was about to say I noticed it was a DSL |
| 18:56:24 | * | boydgreenfield joined #nimrod |
| 18:56:42 | ldlework | Demos: Error: cannot open '/usr/local/lib/nimrod/system.nim' |
| 18:56:43 | Demos | starting to see my point |
| 18:56:48 | superfunc | I would have to concede that to be a weak spot in the type system |
| 18:56:55 | Demos | where did you put it? |
| 18:57:05 | Demos | also koch install /usr/local/bin should do it |
| 18:57:13 | superfunc | But I would still contend that the overall type system is much stronger |
| 18:57:16 | Demos | it may just be koch install /usr/local though, I forget |
| 18:57:27 | Demos | superfunc, the type system is nicer to use, for sure |
| 18:57:32 | Demos | but not really more expressive |
| 18:57:53 | superfunc | You can express the same things in both |
| 18:57:59 | superfunc | That is true |
| 18:58:00 | Demos | also being able to use integers as type params is not fun |
| 18:58:17 | Demos | well aparently you can't express a type safe printf in haskell without TH |
| 18:58:22 | Demos | and you can in c++ |
| 18:58:49 | ldlework | Error: unhandled exception: format string: key not found: mingw [EInvalidValue] |
| 18:58:51 | ldlework | :( |
| 18:58:52 | superfunc | You can't emulate proper ADTs in c++ |
| 18:59:17 | Demos | similarly I think doing compile-time sized matrices and such is not fun in haskell |
| 18:59:58 | superfunc | Probably |
| 19:00:02 | Demos | superfunc, well tagged unions... |
| 19:00:13 | superfunc | Still not proper ADTs |
| 19:00:19 | Demos | how are they different? |
| 19:00:35 | Demos | I don't know what your definition of "proper ADT is" |
| 19:01:01 | ldlework | I have no idea what's wrong |
| 19:01:34 | Demos | you don't actually need to "install" nimrod |
| 19:01:46 | Demos | just add the bin directory to your path and it should work |
| 19:01:55 | ldlework | Demos: but it doesn't |
| 19:01:58 | Demos | and koch install will do it if you really want the whole thing in /usr/local |
| 19:02:00 | ldlework | since it doesn't install any of the libraries and so on |
| 19:02:01 | Demos | hmmmmm |
| 19:02:06 | ldlework | koch install doesn't install it because it fails |
| 19:02:20 | Demos | are you on devel or bigbreak? |
| 19:02:29 | ldlework | what |
| 19:02:41 | Demos | anyway nim knows where the libraries are when you build the compiler... |
| 19:02:49 | Demos | oh, are you using our new release? |
| 19:02:57 | ldlework | I'm just using master.. |
| 19:03:03 | ldlework | here is the output from koch install, https://gist.github.com/dustinlacewell/9e6d5f21ebe1e87a21b5 |
| 19:03:19 | superfunc | Whose to stop me from "interpreting" the union in the wrong way? |
| 19:05:01 | Demos | yeah, true. On the other hand haskell makes you check the tag every time, and C++ you can just access data if you really want |
| 19:05:23 | Demos | same situation as typeclasses. less safe, not really less powerfull |
| 19:05:36 | superfunc | That's a fair point |
| 19:05:41 | superfunc | I like that distinction |
| 19:06:11 | Demos | ldlework, hmmmmm I am not on a linux box right now, but you are gunna want to run koch install with sudo |
| 19:06:15 | superfunc | Side note: I am a huge c++ fan, just playing devils advocate here |
| 19:07:06 | Demos | I am not a big c++ fan, I actually think c++'s type system is too verbose and hard to debug while haskell puts too much emphasis on solving type puzzles and not enough on actually writing a program. |
| 19:08:15 | superfunc | The upfront cost is higher wih haskell for sure |
| 19:09:03 | Demos | I am not convinced that that is something that needs to be true. I think you can pragmaticly design a type system that prevents real problems while not making code harder to write |
| 19:09:12 | Demos | I think nimrod does this pretty well. |
| 19:09:25 | superfunc | I think so too |
| 19:09:34 | Triplefox | Lately I have been thinking about "JSON vs XML" and see some similarities to type system wars |
| 19:10:23 | Triplefox | Cause, XML is okay if you want to define a schema, it's too much if you just want to move around some primitives |
| 19:10:24 | superfunc | Generally, when I'm writing haskell or nim, I am thinking about ideas, rather than implementation details, which is really what I want |
| 19:10:28 | Demos | as an aside I don't think that saying the upfront cost is more but you get a benefit later is a good argument since you really would like to quickly write "less good" code now and be able to change and improve stuff over time |
| 19:10:53 | Demos | optimization for performence is similar, I want a language where I can quickly write slow code and then have the tools to make it fast |
| 19:11:42 | Demos | I am thinking about ideas with C as well, moreso with -lgc and if C had IO that could expand buffers |
| 19:11:45 | Demos | but still |
| 19:12:32 | Triplefox | Yeah, code lifecycle is important |
| 19:13:00 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 19:13:50 | Demos | also I have not found haskell to be that great for exploratory coding, it is better than C++ but still |
| 19:14:10 | Triplefox | At the low level, most of the steps in computation just involve moving data into the "right format" for the job |
| 19:14:36 | superfunc | It is for me, but I understand that it's subjective |
| 19:14:55 | Demos | haskell or c++ |
| 19:15:16 | Demos | because with haskell OK fine, of all the static typed languages it is pretty good |
| 19:15:32 | Demos | I tried swift a few days ago, not interesting but the playgrounds app they have is really cool |
| 19:16:14 | Demos | someone should do that for nimrod, although I guess that someone would probably be me, considering I am the one with the VS addin |
| 19:17:30 | superfunc | I was referring to Haskell |
| 19:17:54 | Demos | OK good |
| 19:17:54 | superfunc | My headspace gets cluttered when I start doing C++ |
| 19:18:09 | Demos | yeah, and it requires a lot of overhead for stupid stuff |
| 19:18:19 | superfunc | I worry preemptively about stuff way too much |
| 19:18:24 | Demos | yeah |
| 19:18:36 | Demos | and I want to be able to just install a module off the internet and use it |
| 19:18:53 | superfunc | Yes |
| 19:18:59 | Demos | every time I want to add a library to a c++ project is a day long ordeal filled with stupid |
| 19:19:25 | superfunc | Lol |
| 19:27:09 | * | Boscop__ joined #nimrod |
| 19:30:41 | * | Boscop_ quit (Ping timeout: 260 seconds) |
| 19:33:36 | * | Boscop_ joined #nimrod |
| 19:35:49 | * | Boscop__ quit (Ping timeout: 260 seconds) |
| 19:36:33 | * | BlaXpirit joined #nimrod |
| 19:41:23 | ldlework | Demos: I have tried that |
| 19:41:29 | ldlework | I think this stuff is broken ... |
| 19:41:34 | ldlework | Some kind of missing key, regarding mingq |
| 19:41:35 | ldlework | mingw |
| 19:42:26 | Araq | ldlework: 'koch install' is broken but afaik the docs do not mention it anymore :P |
| 19:42:47 | ldlework | Araq: how do I install the compiled nimrod compiler? |
| 19:43:01 | Araq | add it to your path |
| 19:43:18 | ldlework | Araq: I did that |
| 19:43:23 | ldlework | the binary depends on a bunch of lib files |
| 19:43:26 | ldlework | how do I install those? |
| 19:43:53 | ldlework | if I just copy the compiler |
| 19:44:02 | fowl | what platform |
| 19:44:06 | Araq | do not copy the compiler |
| 19:44:10 | ldlework | then I try to install nimble I get: |
| 19:44:14 | ldlework | Araq: what..? |
| 19:44:27 | ldlework | oh just add it to the path.. |
| 19:44:29 | Araq | add it to your path, do not copy |
| 19:47:01 | fowl | is this waiting on something? it looks ok to me https://github.com/nimrod-code/packages/pull/91 |
| 19:49:33 | ldlework | yay it works |
| 19:49:40 | ldlework | Araq: thanks |
| 19:53:03 | * | flaviu joined #nimrod |
| 20:02:20 | * | gokr joined #nimrod |
| 20:02:49 | * | brson joined #nimrod |
| 20:03:13 | ldlework | While trying to compile the libtcod examples in libtcod-nim, I get: https://gist.github.com/dustinlacewell/a03401346d51cf47fb86 |
| 20:03:16 | ldlework | anyone know what this is about |
| 20:03:47 | flaviu | There isn't any type coercion |
| 20:03:53 | ldlework | ah it hasn't been updated in a year |
| 20:03:56 | ldlework | sadness |
| 20:03:57 | flaviu | I think you have to modify samples.nim |
| 20:04:48 | ldlework | flaviu: yeah but its a ton of code |
| 20:04:52 | ldlework | and I have no idea how it is broken |
| 20:05:30 | * | gokr_ quit (Ping timeout: 258 seconds) |
| 20:07:01 | flaviu | Well, I guess you have today's project all planned out :P |
| 20:07:26 | flaviu | The compiler will tell you where the issues are. |
| 20:08:12 | ldlework | flaviu: I just don't understand the error |
| 20:08:28 | flaviu | You can't multiply a float and an int |
| 20:08:35 | flaviu | You have to convert the type |
| 20:08:59 | flaviu | hackish, but perhaps a converter int -> float32 could save some work? |
| 20:10:14 | ldlework | if this is the line: https://gist.github.com/dustinlacewell/a03401346d51cf47fb86 |
| 20:10:16 | ldlework | oops |
| 20:10:25 | ldlework | xo = int(SAMPLE_SCREEN_WIDTH_2 * (1 + cos_angle)) |
| 20:10:34 | ldlework | how can I perform the correct cast? |
| 20:10:44 | flaviu | SAMPLE_SCREEN_WIDTH_2 sounds like an int |
| 20:10:51 | flaviu | SAMPLE_SCREEN_WIDTH_2.float or float(SAMPLE_SCREEN_WIDTH_2) |
| 20:10:59 | ldlework | I see. |
| 20:11:01 | flaviu | err, s/float/float32/ |
| 20:11:32 | flaviu | Or perhaps converter int2float32(input:int):float32=float32(input) |
| 20:11:40 | flaviu | at the toplevel |
| 20:11:56 | ldlework | yay it works |
| 20:11:58 | ldlework | thanks! |
| 20:12:08 | flaviu | sure, no problem. |
| 20:12:27 | ldlework | wow its fast |
| 20:13:37 | flaviu | Yep, the compilation speed is really amazing |
| 20:14:42 | * | gokr quit (Quit: IRC for Sailfish 0.8) |
| 20:16:20 | * | gokr joined #nimrod |
| 20:18:17 | * | tdc quit (Ping timeout: 260 seconds) |
| 20:21:13 | * | gokr_ joined #nimrod |
| 20:25:26 | * | gokr quit (Ping timeout: 258 seconds) |
| 20:25:37 | Araq | hi gokr_ what did you change? |
| 20:27:49 | * | gokr joined #nimrod |
| 20:28:32 | gokr | hey |
| 20:29:58 | gokr | Araq: Latest version: https://gist.github.com/gokr/0e242e504a03865ef00f |
| 20:30:15 | gokr | So... one issue was that I wasn't returning a proper response - so ab got confused. |
| 20:30:40 | gokr | Now it returns a minimal proper HTTP response, just adjust the byte size there to try different sizes. |
| 20:31:04 | gokr | Kinda funky, if you raise it up so that you don't drown in connect/close - Nim can push 1.5 Gb to localhost :) |
| 20:31:16 | gokr | Or 1.7 or whatever it was. |
| 20:31:56 | gokr | I also noticed that... my Linux machine shows varying performance... due to god knows. It was very slow suddenly - rebooted and bam, speedy again. Weird. |
| 20:32:17 | Onionhammer | sounds like something has a leaky butthole |
| 20:33:00 | * | dapz joined #nimrod |
| 20:33:36 | Araq | gokr: power management of your laptop? |
| 20:34:04 | * | tdc joined #nimrod |
| 20:34:18 | gokr | But for my laptop I tend to reach around 20k requests per sec, with smaller payloads. Also, the spawning vs remove spawn - you can tell if you use higher concurrent number of clients with ab :) |
| 20:34:23 | gokr | Maybe, not sure. |
| 20:35:01 | * | dapz quit (Client Quit) |
| 20:35:29 | gokr | So pushing data seemed nippy (when I used say 1Mb payloads and it went to 1.5Gb/s) but perhaps there is a cap here - when there is no keepalive. Perhaps its hard to go higher on requests per sec - if you connect/recv-send/close for each request. |
| 20:36:00 | gokr | Ok. Gotta drop to bed - just got back from the rink and I am dead tired. And tomorrow Maya (daughter) has her figure skating competition so... :) |
| 20:36:43 | Araq | ok, see you |
| 20:36:57 | gokr | Yup |
| 20:37:00 | gokr | :) |
| 20:37:16 | * | Araq notes that the socket API could be better for spawn |
| 20:37:31 | gokr | Oohh. one question though. |
| 20:37:55 | gokr | So... Socket is a ref SocketImpl IIRC. And SocketImpl is an object variant - isBuffered or not. |
| 20:37:58 | Onionhammer | oh araq did you see my Q from last night? |
| 20:38:07 | flaviu | Most time time is being wasted in deepCopy btw |
| 20:38:35 | Araq | flaviu: interesting, but not too surprising |
| 20:38:51 | Araq | Onionhammer: well yes, but I don't know what to say |
| 20:38:56 | Onionhammer | "i'm specifying a name proc foo() {.importc: "foo_bar".}" "nim is generating foo() instead of foo_bar" |
| 20:39:07 | gokr | Now... the acceptAddr proc takes a "client: var Socket" (and I can't see why its a var? it doesn't reassign it) and then it puts the new fd into the client Socket, and it *also* sets isBuffered based on the listening Socket's isBuffered. |
| 20:39:29 | gokr | I thought I read somewhere that... changing the "kind" of an object variant... can you do that willy nilly? |
| 20:39:52 | gokr | Does it get reallocated if it changes branch or? |
| 20:39:56 | Onionhammer | i must be missing something, otherwise it seems like a lot more stuff would be broken. might have todo with the vm again |
| 20:40:28 | Onionhammer | actually.. im not doing it inside a macro for testing purposes |
| 20:40:33 | Araq | gokr: no an object variant is always of its maximum possible size |
| 20:40:39 | gokr | Ah, ok. |
| 20:40:50 | gokr | And you don't move objects around I guess :) |
| 20:41:10 | Araq | there are restrictions to object variant transitions |
| 20:41:16 | gokr | And... that "var" thing - when you don't assign to it, what's the point? |
| 20:41:39 | Araq | there is not point, we shall remove it |
| 20:41:41 | gokr | Or perhaps the author just thought he was going to assign to it. |
| 20:42:01 | gokr | Ok, good. Just so I am not missing some subtle point with var params. ;) |
| 20:42:08 | Araq | I think it's because Socket used to an object, now it's a ref object |
| 20:42:12 | Araq | *used to be |
| 20:42:28 | gokr | Aha, to avoid the copy on call? |
| 20:42:41 | Araq | no, so that it can mutated |
| 20:42:54 | Araq | 'ref' always can be mutated anyway |
| 20:42:54 | gokr | Er, yeah, right. |
| 20:43:03 | gokr | Forget what I said. |
| 20:43:12 | Araq | Onionhammer: well you said you use some .push pragma? |
| 20:43:23 | Onionhammer | not for that test, no |
| 20:43:25 | Onionhammer | it was very basic |
| 20:43:26 | gokr | Ok, gnite guys |
| 20:43:48 | Onionhammer | I'm at work now araq, but i'll try to get a gist of the code later tonight |
| 20:44:16 | Araq | Onionhammer: yeah, try to create a proper bug report :P |
| 20:44:26 | Onionhammer | arrgg ;P |
| 20:45:18 | Onionhammer | i usually have to check before i make a bug report to make sure it's not PEBKAC |
| 20:45:45 | Araq | yeah, let's instead keep the lead developer busy |
| 20:45:49 | Araq | smart move :P |
| 20:46:09 | Onionhammer | sorry, i know you hang on my every word ;P |
| 20:46:17 | Onionhammer | I'll stop talking so u can get back to working on nim |
| 20:48:23 | * | xcombelle quit (Quit: Quitte) |
| 20:52:35 | Demos | wrt to that socket thing, big things you pass to functions should not be copied anyways, that is one of the reasons the default param semantics work the way they do I think. |
| 20:54:03 | * | fowl misses T/P |
| 20:54:29 | fowl | but i wasnt here to argue for it |
| 20:56:55 | Demos | I have come to not mind the new ones |
| 20:58:16 | * | BitPuffin quit (Remote host closed the connection) |
| 20:58:43 | Araq | fowl: well it's been named TSocket and turned into a 'ref' iirc |
| 20:58:54 | Araq | so in this case, it was misleading |
| 20:59:29 | * | boydgreenfield joined #nimrod |
| 20:59:44 | Araq | Demos: yes but 'spawn' is special, it needs to deepcopy for memory safety |
| 20:59:57 | Demos | oh we were talking about spawn |
| 21:00:10 | * | tdc quit (Quit: Leaving) |
| 21:01:34 | * | dapz joined #nimrod |
| 21:28:47 | Varriount|Busy | Araq: Is there a way to transfer... ownership of an object from one thread to another, without copying? |
| 21:29:12 | Araq | Varriount|Busy: sure thing, use 'ptr' |
| 21:29:30 | Araq | 'ptr' is unsafe anyway |
| 21:29:32 | * | flaviu quit (Quit: Leaving.) |
| 21:29:34 | Varriount|Busy | Araq: That doesn't do a deepcopy? |
| 21:29:38 | Araq | nope |
| 21:29:41 | * | flaviu joined #nimrod |
| 21:30:52 | Demos | transferring ownership probably requires a whole lot of type system machinery right? |
| 21:31:11 | Demos | although nimrod does have region pointers |
| 21:31:16 | Varriount|Busy | Araq: Anyway, I meant something a bit different. I mean, if I construct an object whose sole purpose is to be passed to another thread, and it doesn't reference any data other than that which it carries, and it's refcount drops to zero after it's been passed to spawn, couldn't the memory just be handed over to the new thread? |
| 21:33:14 | Araq | Varriount|Busy: you can do that in theory. in practice it's *hard* |
| 21:33:23 | Araq | and not supported |
| 21:34:23 | fowl | allocshared? |
| 21:36:19 | Araq | well sure, but he means string/ref/closure/seq |
| 21:40:07 | fowl | oh |
| 21:41:37 | Varriount|Busy | Araq: So I guess the most efficient way to move a lot of data from one thread to another is to bypass the GC and use pointers? |
| 21:44:58 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 21:47:39 | Varriount|Busy | Araq: Speaking of pointers, do slices of sequences and arrays do deep copies, or do they just point to the interior of the structure? |
| 21:49:20 | Araq | Varriount|Busy: slices copy unless they are used in a 'parallel' statement. |
| 21:49:59 | * | irrequietus quit () |
| 21:51:08 | * | superfunc quit (Quit: Connection closed for inactivity) |
| 21:58:04 | * | Varriount|Busy quit (Ping timeout: 246 seconds) |
| 22:08:01 | * | Trustable quit (Quit: Leaving) |
| 22:08:28 | * | Jehan_ joined #nimrod |
| 22:08:56 | Araq | hi Jehan_ can you reproduce the nimble issues on macosx? |
| 22:09:16 | Jehan_ | Araq: What particular issue? |
| 22:09:35 | Araq | clang complains about a missing } |
| 22:09:52 | Jehan_ | Umm, let me see. |
| 22:11:36 | Jehan_ | Compiles with "nimrod c", "nim c" complains about an undeclared identifier FD_SET. |
| 22:12:04 | Jehan_ | I guess someone finally fixed the FD_SET mess in posix.nim and I need to upgrade Nim? |
| 22:13:18 | ldlework | Does anyone want to collaborate on something? |
| 22:14:03 | Jehan_ | Okay, with updated Nim it compiles cleanly. |
| 22:15:58 | Jehan_ | I do get a backtrace trying to do an install. |
| 22:16:56 | Jehan_ | First during the rename of .babel to .nimble. |
| 22:17:28 | Onionhammer | Araq i figured it out |
| 22:17:54 | Jehan_ | Then an ENimble error running it again. |
| 22:17:54 | Onionhammer | Araq it was a weirdity with {.importc.} and no object attached. |
| 22:18:42 | Araq | Onionhammer: no idea what that means |
| 22:18:52 | * | brson quit (Quit: leaving) |
| 22:19:27 | Onionhammer | I had {.importc, header: "someheader.h".} |
| 22:19:27 | * | Pisuke quit (Quit: WeeChat 1.1-dev) |
| 22:19:34 | Onionhammer | on its own |
| 22:19:44 | Onionhammer | and somehow that was just allowed but messing up other importcs |
| 22:20:18 | * | Sembei joined #nimrod |
| 22:21:14 | Jehan_ | Ah, that might be the error you're referring to. |
| 22:21:59 | Jehan_ | Yeah, extraneous closing brace. |
| 22:22:30 | Jehan_ | There are missing newline. |
| 22:22:35 | Jehan_ | newlines* |
| 22:23:00 | Jehan_ | In stdlib_cpuinfo.c |
| 22:23:03 | Jehan_ | #include <sys/types.h>#include <sys/sysctl.h>NIM_EXTERNC N_NOINLINE(void, stdlib_cpuinfoInit)(void) { |
| 22:23:49 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 22:24:03 | Jehan_ | Ah, yeah, {.emit.} without newlines. |
| 22:24:43 | Jehan_ | Should {.emit.} forcibly have a \n appended if it's not ending in one? |
| 22:26:34 | Demos | well it does not matter outside the preprocessor.... |
| 22:27:17 | * | boydgreenfield joined #nimrod |
| 22:27:28 | Jehan_ | Demos: Oh, there are other situations where not separating tokens with whitespace can break stuff. |
| 22:27:52 | Jehan_ | Mind you, most {.emit.} code will end in ; or }. |
| 22:28:17 | Jehan_ | But doesn't have to. |
| 22:29:09 | Araq | well that makes not too much sense |
| 22:29:28 | Araq | bootstrapping should already use cpuinfo.nim ? |
| 22:29:36 | Araq | why doesn't it fail much earlier? |
| 22:30:00 | Jehan_ | Dunno. But if I insert the newlines, it works. |
| 22:30:23 | * | woodgiraffe quit (Ping timeout: 240 seconds) |
| 22:30:57 | Jehan_ | You still get the broken #include, but the following code is separated by a newline, it appears. |
| 22:31:26 | Jehan_ | Do you want two separate fixes for devel and bigbreak or just one that you'll merge? And if so, which branch? |
| 22:31:45 | Jehan_ | I mean, this is just going to fix the {.emit.}, not going to change the compiler yet. |
| 22:31:54 | Araq | devel. |
| 22:32:05 | Araq | I keep merging devel into bigbreak |
| 22:32:56 | Araq | what do you mean "you still get the broken #include"? |
| 22:33:08 | Jehan_ | I mean, I get two #include statements on one line. |
| 22:33:15 | Jehan_ | But they're not followed by C code. |
| 22:33:51 | Jehan_ | So, presumably, the C preprocessor ignores everything after the #include, but without the start of a function declaration, it can recover from that. |
| 22:36:39 | * | woodgiraffe joined #nimrod |
| 22:37:47 | Araq | well |
| 22:38:05 | Araq | don't patch anything, I'll make the compiler emit an \n instead |
| 22:38:21 | Araq | is likely the better idea |
| 22:38:40 | Jehan_ | Umm, is csources now a submodule of GIt? |
| 22:38:50 | Jehan_ | Eh, of Nim. |
| 22:41:34 | Araq | I don't think so |
| 22:41:45 | Araq | but I could be wrong |
| 22:42:08 | Jehan_ | $ git submodule status |
| 22:42:08 | Jehan_ | No submodule mapping found in .gitmodules for path 'csources' |
| 22:42:20 | Jehan_ | It looks like someone added something, but it's broken. |
| 22:42:30 | Jehan_ | Which, umm, always happens with submodules. |
| 22:43:22 | * | gokr_ quit (*.net *.split) |
| 22:43:22 | * | untitaker quit (*.net *.split) |
| 22:43:22 | * | willwillson quit (*.net *.split) |
| 22:43:23 | * | [CBR]Unspoken quit (*.net *.split) |
| 22:44:05 | Araq | *shrug* when I said we had lots of problems with submodules at work, people ensured me it's my own stupidity and now they work just fine |
| 22:44:29 | Araq | git checkout devel # switches branch |
| 22:44:48 | Araq | git checkout compiler/options.nim # reverts file changes |
| 22:45:00 | Araq | how does that work? |
| 22:45:11 | Araq | what if I have a file that's named like a branch? |
| 22:45:14 | * | [CBR]Unspoken joined #nimrod |
| 22:45:31 | Araq | flaviu? |
| 22:45:38 | Jehan_ | Araq: insert a -- |
| 22:45:39 | * | will joined #nimrod |
| 22:45:44 | flaviu | ? |
| 22:46:07 | flaviu | Oh |
| 22:46:12 | flaviu | I haven't messed with submodules |
| 22:46:13 | Jehan_ | git checkout is what happens when you let Linux kernel developers design a user interface. :) |
| 22:46:27 | Araq | yeah "design" |
| 22:46:52 | flaviu | Well, once you grok the insides, the UI just makes sense |
| 22:47:25 | Araq | so how does the inside of "checkout" look like? |
| 22:47:33 | flaviu | I don't know lol |
| 22:47:36 | * | untitaker joined #nimrod |
| 22:48:00 | Araq | if existsFile(arg): # revert local file changes |
| 22:48:12 | Araq | elif existsBranch(arg): # switch branch |
| 22:48:28 | Araq | is that what you mean? |
| 22:48:50 | Jehan_ | git checkout is also fun in that it doesn't reset the index if you checkout different files. You'll have to do git reset on top of it. |
| 22:49:10 | Jehan_ | So, "git checkout ." doesn't always work and which is why you do "git reset --hard" instead. |
| 22:49:55 | Jehan_ | And "makes sense" isn't the same thing as "can't easily result in unexpected errors". |
| 22:50:29 | Jehan_ | Part of the point of a user interface is to shield the user from internals, no matter how much sense they make to the *programmer*. |
| 22:52:00 | ldlework | Is there an in-memory sql db for nimrod? |
| 22:52:13 | flaviu | ldlework: sqlite? |
| 22:52:20 | Jehan_ | ldlework: Sqlite with memory db. |
| 22:52:22 | ldlework | flaviu: that's not in memory is it? |
| 22:52:24 | ldlework | oh |
| 22:52:25 | flaviu | It can be |
| 22:52:37 | Jehan_ | Yes, you can specify that it should use an in-memory db. |
| 22:52:37 | Araq | I claim its biggest problem is that is not unix-like. "git checkout" ... meh. it should be "git | git_checkout" |
| 22:52:52 | flaviu | I don't understand how that wouldwork |
| 22:53:21 | ldlework | yeah what does 'git' do? what does it pass to 'git_checkout' ? |
| 22:53:44 | ldlework | the command interface to git is a semantic abstraction |
| 22:54:00 | ldlework | whatever git passes to git_checkout wouldn't be relevant to some other git_X command |
| 22:54:16 | ldlework | which would be the whole point of using composition/pipelining |
| 22:54:54 | Araq | hrm, sometimes irony is hard to detect |
| 22:55:40 | Jehan_ | The problem is really that git checkout fails the "do one thing only and do it well" property. |
| 22:55:51 | Varriount | ^ |
| 22:56:59 | Varriount | Araq: What should be done about this issue: https://github.com/Araq/Nimrod/issues/1561 |
| 22:57:35 | Jehan_ | It does (1) checkout a new revision (2) revert files to their old versions (3) create new branches (4) switch to an existing branch, but doesn't allow you to manage the index for them. |
| 22:58:04 | Jehan_ | And sometimes you'll still need git merge -ff-only instead. |
| 22:58:45 | Araq | Varriount: make the compiler report an error |
| 22:59:16 | flaviu | Jehan_: I wouldn't count 3 against it. Looks like it's just a convenience thing |
| 22:59:56 | Jehan_ | flaviu: That convenience thing should probably have its own version. |
| 23:01:10 | Araq | I cannot see how it improves "convenience" |
| 23:01:21 | flaviu | 1 command vs 2 commands |
| 23:01:24 | Jehan_ | And you can "git checkout somefile.c" be a nop because you did a "git add somefile.c" earlier. |
| 23:01:52 | Araq | flaviu: 'git branch' is a command anyway |
| 23:01:59 | Jehan_ | flaviu: Having one command here is not a convenience if it leads to ambiguities. |
| 23:02:14 | flaviu | It's hard to be confused as to what `git checkout -b foo` does |
| 23:02:29 | Jehan_ | Oops, I misread that as 2 somehow. Sorry. |
| 23:02:44 | Araq | really? what's that -b for? |
| 23:02:49 | flaviu | new branch |
| 23:03:07 | flaviu | git branch foo; git checkout foo |
| 23:03:30 | Araq | that's a command line interface optimized for selling books about it |
| 23:03:59 | flaviu | Why bother with books when you have man pages? :P |
| 23:04:46 | Jehan_ | Well … the man pages aren't exactly written for consumption by non-hackers, either. :) |
| 23:05:24 | Jehan_ | How is a non-expert going to interpret this (git push --help): Updates remote refs using local refs, while sending objects necessary to complete the given refs. |
| 23:06:30 | Araq | that's why it's called a *man* page ;-) |
| 23:06:34 | Araq | it's for men only |
| 23:06:37 | Jehan_ | In order to understand that, you first need a fairly deep understanding of Git's internal model, i.e. what objects and refs are, how local and remote refs related, and then still figure out what "complete the given refs" mean. |
| 23:06:43 | Araq | and has nothing to do with manual |
| 23:07:06 | flaviu | The wording is confusing, but once you understand how git works, that makes sense |
| 23:07:17 | flaviu | even if it is that dense |
| 23:07:25 | Jehan_ | flaviu: Well, a man page shouldn't require a Ph.D. in git internals. |
| 23:07:36 | ldlework | refs are a thing you just need to know |
| 23:07:53 | ldlework | git isn't really workable, or will be magic if you don't know them - I wouldn't say they're internal |
| 23:07:58 | Jehan_ | Documentation that works once you understand what the documentation is trying to say is a bit … circular. |
| 23:08:02 | ldlework | you're supposed to understand and be able to manage refs |
| 23:08:22 | ldlework | Jehan_: if the git man pages never explain what refs are I'd be surprised |
| 23:08:27 | Jehan_ | ldlework: the problem is that you still need to document them. |
| 23:08:32 | ldlework | What? |
| 23:08:36 | Jehan_ | ldlework: I wouldn't. |
| 23:08:45 | ldlework | I don't know what you're saying. |
| 23:08:47 | Varriount | Araq: Are you sure? Because a preliminary analysis shows that several places in the system code have mismatching visibility markers. |
| 23:09:13 | Jehan_ | ldlework: I mean, I'm pretty sure that if refs are documented somewhere, it's in an arcane and non-obvious corner. |
| 23:09:32 | Araq | Varriount: the first header requires the export marker, it's optional for the 2nd |
| 23:10:02 | Jehan_ | Git man pages routinely assume the understanding of concepts that aren't actually documented anywhere. |
| 23:10:09 | flaviu | http://www.sbf5.com/~cduan/technical/git/ |
| 23:10:12 | flaviu | seems pretty good |
| 23:10:28 | ldlework | T obe fair |
| 23:10:35 | ldlework | the man pages are more of a reference |
| 23:10:40 | ldlework | the actual documentation for git is this, http://git-scm.com/doc |
| 23:10:49 | ldlework | I really recommend reading it, its very well written. |
| 23:10:56 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 23:11:09 | ldlework | http://git-scm.com/book/en/v2/Git-Internals-Git-References this is a short read |
| 23:11:17 | Jehan_ | ldlework: You don't need to tell me to read it, I probably know more about git internals than most git advocates. |
| 23:11:23 | ldlework | Jehan_: heh ok |
| 23:11:39 | Jehan_ | ldlework: My point is that from a technical writing point of view, the man pages are a mess. |
| 23:11:58 | ldlework | Jehan_: I think if you consider them a reference rather than a pedagogy they're fine |
| 23:12:11 | Jehan_ | Granted, that's hard work, but that's why you usually don't let programmers do it. |
| 23:12:40 | Jehan_ | ldlework: Even then, I disagree. They're unnecessarily dense and confusing. |
| 23:12:54 | Araq | I'm still not convinced that the problem that git solves is so hard that you cannot have an easy interface to it. |
| 23:13:07 | Jehan_ | Mind you, I'm not sure I'd be up to writing proper man pages for something that complex. |
| 23:13:54 | Araq | GCC is quite complex too and yet I don't need to read books to operate it |
| 23:14:11 | flaviu | Araq: Of course you do |
| 23:14:24 | flaviu | C and C++ aren't trivial |
| 23:14:35 | flaviu | And they are effectively the UI to GCC |
| 23:14:39 | Jehan_ | Araq: Eh, gcc documentation is also not a shining example, I'd say. :) |
| 23:14:53 | Araq | I am talking about GCC's command line interface |
| 23:15:29 | Araq | but whatever, replace it with clang if you disagree |
| 23:15:45 | Araq | (everybody loves everything about clang, right?) |
| 23:15:48 | flaviu | The complexity exists with any compiler |
| 23:15:57 | flaviu | The language is the primary UI to a compiler |
| 23:16:08 | flaviu | http://git-man-page-generator.lokaltog.net/#dd7ba97e75a32d6709c9c2694c971af4 |
| 23:16:43 | ldlework | (I definitely think git's ui could be improved) |
| 23:17:10 | flaviu | Well, the wonder of the commandline is that that is very much possible |
| 23:18:36 | Araq | so do clang's command line switches refer to details of how clang's AST is structured? |
| 23:18:46 | Araq | cause that's what git's docs do |
| 23:18:47 | flaviu | Some do |
| 23:18:57 | flaviu | IIRC there is a way to dump the IR |
| 23:19:19 | flaviu | And that again is another UI for clang |
| 23:20:12 | Araq | you simply don't get it |
| 23:20:23 | Jehan_ | Anyhow, we should probably get rid of the broken submodule in bigbreak ... |
| 23:24:27 | Jehan_ | git rm --cached csources should do that. |
| 23:24:42 | Araq | thanks, was about to ask |
| 23:25:12 | Jehan_ | Basically, a submodule is represented as a pseudo folder. |
| 23:25:28 | Jehan_ | Which is why "git rm" can be used to get rid of it. |
| 23:25:57 | Araq | and the --cached means? |
| 23:26:15 | Jehan_ | Because it's not actually represented in the checkout. |
| 23:26:39 | Jehan_ | --cached means: operate on the index (= staging area). |
| 23:26:58 | Jehan_ | Plus, of course, a commit. |
| 23:27:13 | * | dapz joined #nimrod |
| 23:27:36 | Jehan_ | In any event, I don't know of any version control system that has managed to get submodules to work. |
| 23:28:03 | Jehan_ | I think the best (in the "least bad") sense is probably Subversion, which has an easier time because it's centralized. |
| 23:28:47 | Jehan_ | I'm generally a fan of having dependent modules and external files being organized by the build system rather than a VCS. |
| 23:30:17 | Demos | yeah, I agree with Jehan here |
| 23:32:09 | Araq | before complex version control system operations I make a local backup |
| 23:32:18 | flaviu | Reflog? |
| 23:32:26 | flaviu | Also, just clone |
| 23:32:51 | flaviu | eg, don't push until you've figured everything is fine |
| 23:33:29 | Araq | it's usually faster to restore the backup than figuring out how to do the version control undo |
| 23:34:11 | Jehan_ | flaviu: The problem is generally not accidental deletion of stuff, but to revert the repository to its former state. |
| 23:41:11 | * | Hodapp left #nimrod ("WeeChat 0.4.2") |
| 23:42:31 | * | saml quit (Quit: Leaving) |
| 23:52:08 | * | superfunc joined #nimrod |
| 23:55:31 | Araq | "Can't escape backticks using emit pragma (#1588)" |
| 23:55:46 | * | darkf joined #nimrod |
| 23:56:09 | Araq | well yes... maybe we'll survive anyway |
| 23:56:30 | * | Araq always knew .emit was a bad idea to begin with |
| 23:57:59 | Araq | we can make 2 backticks stand for a single backtick |
| 23:59:32 | Jehan_ | Hmm, I think {.emit.} is sometimes just unavoidable. |