| 00:00:15 | fowl | hows that o.o |
| 00:00:37 | Demos | type erasure is whenever you cast something in such a way that the type goes away, you then need to store the type someplace else and access it at runtime |
| 00:01:05 | zahary1 | we are reducing the difference in types to a common "vtable" type; the "component info" objects are another example |
| 00:01:19 | zahary1 | I don't remember the specific names, sorry |
| 00:03:20 | zahary1 | but an ECS without any type erasure doesn't sound like such a worthy goal - you should check-out the convenient syntax of the fowl library |
| 00:03:33 | Demos | my syntax is almost the same |
| 00:03:49 | Demos | I do use type erasure for my systems |
| 00:03:49 | fowl | Demos, wheres the entity's data stored |
| 00:03:55 | zahary1 | I imagine that you obtain direct pointers to the components you want to work with? |
| 00:04:09 | zahary1 | you have a way to get an component and then you directly work with it? |
| 00:04:18 | Demos | in an array of components. And yeah I do |
| 00:04:48 | fowl | is it like a seq[component_a] where the index is the entity ID? |
| 00:05:48 | Demos | more or less, the index is not the entity id thouhg, you need to search to get a component belonging to a specific entity. By garenteeing that components are at least ordered by entity you can do that very quickly |
| 00:06:09 | Skrylar | Sorry to interrupt for a second; are there any one-line concepts/annoyances people have with GUIs they think I should look at in a minute? I'm combing concepts for a nimrod GUI at the moment and wanted to make sure i didn't miss something important |
| 00:06:25 | Demos | too much magic |
| 00:06:55 | fowl | Skrylar, tree-based widgets are a PITA to update |
| 00:08:19 | flaviu | Araq: Looking through TAPL, what nimrod calls tuples are actually records. If I'm reading figure 11-7 correctly (might be wrong, the notation is slightly confusing), they are supposed to work more-or-less how I'm trying to describe them |
| 00:08:24 | zahary1 | well, one nice thing about fowl's design and type erasure in general is that you don't need to know which component will handle a specific message - you can have different implementations responsible for the same external interface - you can even have what we call "multicast" messages, which can be implemented by several components simultaneously - these come in very handy in the design of game engines |
| 00:08:55 | fowl | Demos, i see. in entitty the component data is stored continuously like [compA, compB, compD] (a cstring) the typeinfo has an offsets field so cast[ptr component](entity.data[ entity.typeinfo.offsets[ component.id ] ].addr) |
| 00:10:05 | Demos | yeah I dont even have messages. you can register a function to run every update and from there you can fetch the components you need and go wild |
| 00:12:31 | fowl | Demos, from what ive seen in systems where theres no logic tied to the component, its common to use multiple systems to manage the game logic |
| 00:12:44 | Demos | yeah, ofc |
| 00:13:08 | Demos | I may well build a more type-erasure heavy thing on top of this |
| 00:13:14 | Demos | maybe even stick a scripting language in there |
| 00:13:16 | fowl | render system, physics system, etc, i ended up using this in roids, render system has a spatial partitioning for render culling, physics system has a chipmunk space |
| 00:13:30 | Araq | flaviu: the type of {x=5} is {x: Nat}, so the label is clearly part of the type |
| 00:14:17 | Skrylar | fowl: what in particular about a tree GUI do you have troubles with? |
| 00:14:24 | Demos | yeah systems are not really tied to the component representation |
| 00:14:35 | Demos | they are just proc(scene: int) |
| 00:18:58 | Araq | foreach i, Gamma |- t_i : T_i ---> Gamma |- {l_i= t_i} : {l_i : T_i} |
| 00:19:15 | * | Araq needs a unicode keyboard |
| 00:19:31 | Skrylar | LaTeX IMEs |
| 00:19:33 | Skrylar | lol |
| 00:20:54 | flaviu | http://latex.codecogs.com/gif.latex?\text{foreach}%20~%20i%2C%20\Gamma%20|-%20t_i%20%3A%20T_i%20\to%20\Gamma%20|-%20{l_i%3D%20t_i}%20%3A%20{l_i%20%3A%20T_i} |
| 00:21:56 | Araq | flaviu: the labels are clearly taken over to the inferred type |
| 00:22:12 | Araq | your rule would be: |
| 00:22:20 | Araq | foreach i, Gamma |- t_i : T_i ---> Gamma |- {l_i= t_i} : {T_i} |
| 00:23:38 | flaviu | My bad then, but IMO, having the names be aliases is more intuitive. I'll see if I get a better argument together on the fourms. |
| 00:23:53 | Araq | ha, very well |
| 00:25:37 | Araq | TAPL argues the order shouldn't matter though when you have field names |
| 00:26:29 | Skrylar | CEGUI does this interesting idea where their sizes are made up of two floats; there's a 'relative' and 'absolute' float which lets you do strethcy interfaces without layout managers. I think its neat but it involves doubling the size of coordinates and involves extra math |
| 00:26:40 | Skrylar | (parent.whatever*relative)+absolute |
| 00:26:41 | Araq | early versions of the language tried to do this but I found it too tedious to implement for questionable gains in flexibility |
| 00:27:33 | renesac | what if the tuple field names that you define at the top of function aren't narrowing what you accept, but instead just telling what you want to name them inside your function |
| 00:27:33 | renesac | ? |
| 00:29:29 | * | carum joined #nimrod |
| 00:29:44 | Araq | well that's flaviu's argument, renesac |
| 00:30:39 | Araq | and I don't mind too much to change this, would also simplify the implementation a bit |
| 00:30:55 | flaviu | Araq: Your abstraction is aready leaky :P |
| 00:32:04 | * | darkf joined #nimrod |
| 00:32:04 | flaviu | type TNotARecord = tuple[a: int, b: string]; let t1: TNotARecord = (1, "t") |
| 00:32:04 | flaviu | t1[0], t1[1] |
| 00:32:44 | flaviu | Order can matter, it doesn't disappear |
| 00:32:59 | flaviu | Or maybe I'm becoming confused by the notation again |
| 00:33:20 | Araq | for nimrod's tuples/records order does matter, yes |
| 00:34:59 | * | carum quit (Remote host closed the connection) |
| 00:39:19 | * | carum joined #nimrod |
| 00:41:21 | fowl | can you get the exception backtrace if you catch it |
| 00:42:19 | Araq | yeah, getStackTrace(e) iirc |
| 00:42:40 | Araq | only works in debug mode ofc |
| 00:45:57 | Varriount | Meep |
| 00:46:29 | fowl | ty |
| 00:52:59 | Skrylar | i'm starting to see the value in multithreaded forum software |
| 00:53:00 | * | carum quit (Remote host closed the connection) |
| 00:53:38 | Skrylar | its a lot easier to track multiple sub-conversations under a topic with the way reddit/slashdot does it |
| 01:03:35 | * | carum joined #nimrod |
| 01:15:21 | NimBot | Araq/Nimrod devel 90e1195 Araq [+1 ±4 -0]: fixes #937 |
| 01:15:21 | NimBot | Araq/Nimrod devel 331f066 Araq [+1 ±0 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 01:15:28 | Demos | seqs have reference semantics right? |
| 01:15:48 | Araq | zahary1: with this patch tstaticprintseq works |
| 01:15:52 | flaviu | Demos: Was just looking at the docs a second ago, it appears so |
| 01:16:04 | Araq | no, they have value semantics |
| 01:16:18 | Araq | though you can do 'shallowCopy' and get ref semanticss |
| 01:16:30 | Demos | hot damn that would be why my var return type is failing |
| 01:16:43 | Araq | and often the compiler produces a move instead of a copy |
| 01:16:52 | Araq | but it could always be smarter ofc |
| 01:17:03 | Araq | good night |
| 01:17:32 | flaviu | I have another stupid question: How do I set stuff in a table? |
| 01:18:27 | EXetoC | mget/`[]`? |
| 01:18:28 | Demos | is there a way to use something like that proc infix, like how haskell has `...`? |
| 01:18:40 | EXetoC | lolwut mget? :p |
| 01:21:24 | Araq | tab[key] = val |
| 01:21:33 | * | carum quit (Remote host closed the connection) |
| 01:21:42 | EXetoC | * `[]=` |
| 01:22:22 | flaviu | Error: value returned by statement has to be discarded |
| 01:23:43 | EXetoC | use index assignment if you don't care about existing values |
| 01:24:24 | EXetoC | or if said key isn't present |
| 01:24:54 | Araq | good night |
| 01:25:02 | EXetoC | cya |
| 01:26:32 | EXetoC | mget returns a var that is referring to the value represented by said key, hence why it must either be stored or discarded (discard mget(...)) |
| 01:29:39 | flaviu | There seem to be all sorts of issues when doing things inside a (...) block |
| 01:30:28 | flaviu | move it out, and everything works as expected |
| 01:30:50 | * | DAddYE quit (Remote host closed the connection) |
| 01:31:26 | * | DAddYE joined #nimrod |
| 01:31:49 | EXetoC | I tend to use it only in block conditions |
| 01:33:40 | EXetoC | keep in mind that many statements can be used as expressions, and so that can be used for various shortcuts |
| 01:34:00 | EXetoC | let x = if true: 1 else: 0 |
| 01:34:16 | flaviu | EXetoC: Yep, I noticed that |
| 01:35:03 | flaviu | I'm coming from scala, were the situation is the same, though block expressions don't have odd beheivor. |
| 01:36:10 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 01:37:26 | * | carum joined #nimrod |
| 01:41:13 | Demos | oh my god I just found advances.realtimerendering.com .... so much shiny |
| 01:43:25 | Varriount | Demos: Again, what is is with programmers and website design? |
| 01:43:29 | Varriount | *is it |
| 01:43:58 | Demos | http://motherfuckingwebsite.com/ |
| 01:44:08 | EXetoC | content, bitch! |
| 01:44:16 | flaviu | +1 |
| 01:44:20 | Varriount | Demos: Desn't excuse lack of aesthetic. |
| 01:44:31 | Varriount | *Doesn't |
| 01:44:35 | Demos | read the source for that website |
| 01:44:38 | flaviu | Maybe they put all their aesthetic into cool games |
| 01:44:57 | Demos | I like it. it is clear and has what I nead. Looks fine to me |
| 01:47:10 | Varriount | Demos: Did you look at the source? |
| 01:47:20 | flaviu | Varriount: Better than the website that I found a while ago that puts the cpu at full blast rendering a stupid little 3d wireframe cube |
| 01:47:44 | Varriount | flaviu: The website was created with Microsoft Office. MICROSOFT OFFICE |
| 01:48:21 | Demos | I mean the source for http://motherfuckingwebsite.com/ |
| 01:48:24 | flaviu | ... ... lol |
| 01:48:46 | Demos | well it was probably something for siggraph that he had to put on the web or something.... |
| 01:49:03 | Demos | graphics people are not artists |
| 01:49:37 | * | carum quit (Remote host closed the connection) |
| 01:49:38 | EXetoC | not graphics programmers anyway |
| 01:49:53 | flaviu | Wow, thats pretty insane. But it is made by someone with a yahoo email, so it might be just a non-technical organizer or something |
| 02:00:20 | Demos | nope Natalya Tatarchuk works at bungie as a rendering engeneer |
| 02:04:58 | Skrylar | i forget; can you do a renamed import on a whole module? |
| 02:06:39 | EXetoC | import x as y? |
| 02:08:25 | Skrylar | i'll have to test that |
| 02:10:21 | * | OrionPK joined #nimrod |
| 02:23:41 | Varriount | Ok. I must be doing something wrong, as any opengl procedure I call immediately causes a null pointer error. |
| 02:24:29 | Varriount | I've been told by the tutorial to call glewInit, however the opengl wrapper doesn't have that. What do I do? |
| 02:24:36 | Skrylar | if you're using a wrapper you have to have it initialie everything |
| 02:24:46 | Skrylar | the method to do that depends on what you're using |
| 02:25:15 | Skrylar | usually what you are calling are method pointers so if you haven't initialized the wrapper, you're just calling a null pointer |
| 02:25:16 | Varriount | Skrylar: glGenVertexArrays |
| 02:25:27 | Skrylar | that isn't a loader |
| 02:25:39 | Skrylar | glewInit only applies if you are using GLEW |
| 02:27:57 | Varriount | Ok, got it. |
| 02:28:12 | Demos | gaaaah I really need to remember that nimrod does not have sfinae |
| 02:29:40 | EXetoC | loadExtensions isn't enough? I can't remember |
| 02:31:07 | * | carum joined #nimrod |
| 02:31:12 | Varriount | EXetoC: It is. I mis-remembered. I thought that earlier, when I tried calling it, loadExtensions didn't work. |
| 02:31:25 | * | flaviu quit (Remote host closed the connection) |
| 02:33:51 | * | carum quit (Remote host closed the connection) |
| 02:35:02 | EXetoC | Varriount: A linker error because of the lack of referenced extension functions was it? |
| 02:35:48 | EXetoC | what are you using for window management? |
| 02:35:54 | Varriount | EXetoC: glfw |
| 02:36:00 | Varriount | But it works now. :/ |
| 02:36:26 | EXetoC | ok |
| 02:36:29 | EXetoC | my wrapper? |
| 02:36:40 | Varriount | EXetoC: Yep. |
| 02:36:54 | EXetoC | woohoo. fame |
| 02:36:58 | * | DAddYE joined #nimrod |
| 02:37:40 | Varriount | EXetoC: I'm actually using the wrapper.nim file, since I'm following the tutorial |
| 02:37:47 | * | carum joined #nimrod |
| 02:38:01 | Varriount | 'import wrapper as glfw' |
| 02:39:00 | * | q66 quit (Quit: Leaving) |
| 02:39:19 | * | carum quit (Remote host closed the connection) |
| 02:40:19 | Skrylar | hrm. |
| 02:40:22 | EXetoC | ok. I should rename it because of how symbols are qualified |
| 02:41:29 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 02:46:55 | * | carum joined #nimrod |
| 02:48:31 | * | carum quit (Remote host closed the connection) |
| 02:50:05 | * | carum joined #nimrod |
| 02:51:29 | Skrylar | blegh. |
| 02:51:37 | Skrylar | i am not looking forward to the next part of dealing with GUIs |
| 02:51:51 | * | carum quit (Remote host closed the connection) |
| 02:58:30 | Demos | hm so generics are instantiated before overload resolution it seems |
| 03:00:28 | Demos | now interestingly if you tall an overloaded template ALL overloads are instantiated, not just the ones with matching typeclasses |
| 03:01:33 | * | carum joined #nimrod |
| 03:06:32 | * | carum quit (Remote host closed the connection) |
| 03:09:27 | * | carum joined #nimrod |
| 03:13:38 | * | carum quit (Ping timeout: 240 seconds) |
| 03:16:52 | * | DAddYE joined #nimrod |
| 03:21:51 | * | nequitans_ joined #nimrod |
| 03:30:30 | * | DAddYE quit () |
| 03:38:32 | Varriount | EXetoC: If you update the wrapper, let me know. |
| 03:50:44 | Skrylar | Okay, so I just looked through a stack of reference material for designing a good GUI system. I have one thing to say postmortem: |
| 03:50:45 | Skrylar | FML. |
| 03:51:17 | * | comex quit (Ping timeout: 244 seconds) |
| 03:54:56 | * | comex joined #nimrod |
| 03:58:38 | Varriount | FML? |
| 04:06:33 | Varriount | Araq: ping |
| 04:14:28 | Skrylar | Varriount: http://i.imgur.com/rf4Kd54.gif welcome to hell |
| 04:15:21 | * | Varriount pats Skrylar on the back |
| 04:16:17 | Varriount | Skrylar: If it makes you feel better, I'm getting repeatedly beaten over the head with type nags on this opengl tutorial |
| 04:16:26 | fowl | Skrylar, you can use cairo on windows right |
| 04:16:38 | Varriount | "Error, literal '1' is not of type glInt' |
| 04:16:39 | Skrylar | fowl: sure, it will supposedly interface with GDI |
| 04:17:48 | Demos | I am having trange bugs where adding something before some code (that typechecks) causes some later code to fail to typecheck |
| 04:18:00 | Demos | or sometimes it just causes segfaults |
| 04:19:17 | Varriount | Demos: Memory Corruption? |
| 04:19:32 | Demos | maybe |
| 04:19:33 | Skrylar | easy way to check on linux |
| 04:19:38 | Demos | not on linux |
| 04:19:42 | Skrylar | piss :\ |
| 04:19:48 | Skrylar | no valgrind for you |
| 04:20:01 | Varriount | Skrylar: valgrind doesn't like nimrod on either system. |
| 04:20:10 | Demos | but I am only using the addr operator once, and I am not doing any pointer arithmatic |
| 04:20:13 | Skrylar | Varriount: that sounds like a bug that should be fixed |
| 04:20:18 | Skrylar | valgrind is a gentleman |
| 04:20:24 | Varriount | Skrylar: The 'bug' is the GC |
| 04:20:48 | Skrylar | Varriount: of course it is *rolleyes* fricking GCs that don't free everything |
| 04:21:00 | Skrylar | I hate when a GC has finalizers that aren't guaranteed to ever run |
| 04:21:31 | Varriount | Skrylar: Eh, it does? |
| 04:21:42 | Skrylar | I don't know if Nimrods is that way, all though isn't one of the options to use boehm? |
| 04:21:46 | Skrylar | IIRC boehm doesn't guarantee finalizers |
| 04:22:06 | Skrylar | I seem to remember that boehm's will also just leak memory if its below an amount that the GC decides is worth watching |
| 04:22:13 | Varriount | Skrylar: Nimrod's default GC isn't boehm. |
| 04:22:20 | Skrylar | didn't say default |
| 04:22:37 | Skrylar | if any of the options doesn't guarantee finalizers, then finalizers aren't guaranteed in the language |
| 04:25:56 | Demos | I think it is reasonable to not garentee finalizers, we have destructors |
| 04:27:12 | Demos | oh my god is nimrod re-useing an already instantiated template in a really stupid way... |
| 04:27:56 | Skrylar | Demos: usually finalizers trip destructors though, at least in other languages |
| 04:28:14 | Demos | I dont think they do in nimrod |
| 04:28:30 | Skrylar | i've seen things like C# go "oh we don't have destructors, we have finalizers! oh by the way they aren't guaranteed, so they're basically useless. So here's IDisposable which is basically the same thing as a destructor but a bigger pain in your ass :D" |
| 04:28:31 | Demos | not 100% sure though |
| 04:28:49 | Demos | yeah IDisposable is not really that nice |
| 04:32:46 | * | DAddYE joined #nimrod |
| 04:35:16 | Skrylar | well thats weird |
| 04:35:38 | Skrylar | import two files which have the same code, export the files |
| 04:35:52 | Skrylar | -> didn't get compiler complaint that i just exported the same symbols twice |
| 04:39:27 | * | OrionPK quit (Remote host closed the connection) |
| 04:42:30 | * | OrionPK joined #nimrod |
| 04:42:39 | OrionPK | there |
| 04:42:43 | OrionPK | running on my cubox :) |
| 04:45:36 | * | DAddYE quit (Remote host closed the connection) |
| 04:46:04 | * | DAddYE joined #nimrod |
| 04:50:33 | Demos | https://gist.github.com/barcharcraz/62b1d7d2d9ff809841d7 |
| 04:50:36 | Demos | known bug? |
| 04:50:43 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 05:04:22 | fowl | Demos, quantum computer |
| 05:04:40 | * | DAddYE joined #nimrod |
| 05:04:43 | Demos | it actually caused a really spooky bug |
| 05:05:33 | Demos | since I was using when compiles(...) to work around the fact that one possible overload of a template failing to compile will make the whole program fail to compile, even if that overload would not have been selected |
| 05:05:59 | Demos | and now I can not find where the hell compiles() even is in the compiler |
| 05:12:37 | Demos | # undo symbol table changes (as far as it's possible): |
| 05:12:51 | Demos | from the proc called in the Compiles magic |
| 05:23:37 | * | XAMPP joined #nimrod |
| 05:30:04 | fowl | Skrylar, lets steal morphic |
| 05:37:17 | Demos | wowah |
| 05:42:40 | * | DAddYE quit () |
| 05:45:12 | * | nequitans_ quit (Ping timeout: 264 seconds) |
| 05:45:44 | Skrylar | fowl: lol |
| 05:46:09 | Skrylar | fowl: i'm working on that, there's just a lot of crap in the way |
| 05:48:55 | fowl | i have a wrapper for clutter if you want to try that out, it handles fonts and stuff, opens a nice little window for you |
| 05:49:07 | Skrylar | isn't clutter GPL-y |
| 05:49:47 | fowl | lgpl |
| 05:55:05 | * | r0b4 quit (Ping timeout: 252 seconds) |
| 06:06:18 | Skrylar | i wish theere was just an easy -L to add search directories for units |
| 06:13:01 | runvnc | hello |
| 06:13:05 | runvnc | I am trying to use tables |
| 06:13:13 | runvnc | I am using a string as the key |
| 06:13:41 | runvnc | string looks to be the same but when I look in mytable["whateverid"] it says it is nil |
| 06:15:01 | runvnc | does it have to be the reference to the same string? I was hoping having the same characters would be good enough |
| 06:15:09 | runvnc | maybe there is a null character at the end of one or something |
| 06:28:59 | * | isenmann quit (Ping timeout: 252 seconds) |
| 06:32:04 | * | isenmann joined #nimrod |
| 06:35:44 | * | xtagon joined #nimrod |
| 06:39:52 | * | brson joined #nimrod |
| 06:42:23 | Varriount | runvnc: It would help if we could see some code. |
| 06:42:34 | Varriount | Skrylar: Have you seen filwit's forum post? |
| 06:42:47 | Skrylar | nerp |
| 06:42:52 | Skrylar | where is it? |
| 06:43:09 | Varriount | http://forum.nimrod-lang.org/t/389 |
| 06:43:55 | Varriount | Maybe it's just because I come from python, but I dislike the removal of colons separating parameter idents and their types. |
| 06:44:22 | runvnc | varriount thanks |
| 06:44:27 | runvnc | I already changed it to use a hash |
| 06:44:31 | runvnc | but here is the code https://gist.github.com/ithkuil/9362338 |
| 06:44:34 | Varriount | It seems visually ambiguous to me. (And yes, I think C/C++ are also visually ambiguous in the same way) |
| 06:44:34 | runvnc | which is embarassing |
| 06:44:44 | runvnc | but if you can imagine that code with a ttable[string instead of ttable[int |
| 06:44:57 | runvnc | for some reason it kept saying it couldnt find the socket with the id |
| 06:45:11 | Skrylar | yeah i don't have a problem with the colons, especially when you know and use the pascal syntax |
| 06:45:12 | Varriount | runvnc: If you need a string table, you might be interested in the strtabs module |
| 06:45:29 | Skrylar | "foo, bar: int" means you actually specify the type LESS than in a C-like |
| 06:46:11 | Varriount | Skrylar: That's what I mean. |
| 06:46:12 | runvnc | thanks but I need to put TSockets in it |
| 06:47:07 | Skrylar | i'm actually pretty happy with the syntax as it is right now, but maybe thats just me |
| 06:47:29 | Demos | I am to... but I am coming from c++ |
| 06:47:44 | Varriount | runvnc: Are you testing with string literals? |
| 06:47:47 | Skrylar | it seems to have the safety rails of Pascal the "look i made spaces important" that people like for some odd reason in Python |
| 06:48:18 | runvnc | I didn't test with string literals |
| 06:48:24 | runvnc | but I think I know what I did now |
| 06:48:33 | runvnc | I should have stopped programming 4 hours ago |
| 06:48:38 | runvnc | brain doesn't work adequately |
| 06:48:44 | Varriount | :3 |
| 06:48:48 | runvnc | and so I got my response queue id confused with my request id |
| 06:49:20 | Demos | gaah I really want to fix this compiles() bug |
| 06:49:45 | Skrylar | bleh i'm conflicted |
| 06:49:49 | Varriount | Skrylar: What has the safety rails - filwit's suggestions or the current nimrod syntax? |
| 06:50:07 | Skrylar | Varriount: the current syntax, all though the type system is more what i meant |
| 06:50:25 | Skrylar | his proposed syntax summary doesn't actually show very much |
| 06:51:32 | Varriount | runvnc: I can't really figure out what was wrong without the old code. Sorry. |
| 06:51:38 | * | filwit joined #nimrod |
| 06:51:49 | Skrylar | Varriount: hrm.. it looks like "a, b int" is just asking to have typos happen |
| 06:51:54 | Varriount | Oh, Speaking of which, here he is now. |
| 06:52:01 | filwit | hey |
| 06:52:11 | runvnc | its ok I figured it out after I talked to you so thanks. just got my request id and response q confused |
| 06:52:12 | Varriount | Hi filwit, we were just gossiping about you :3 |
| 06:52:13 | filwit | talking about my syntax proposal i see |
| 06:52:42 | filwit | Varriount: hope all good things ;P |
| 06:52:48 | Varriount | filwit: I don't like the removal of colons. It makes the syntax too ambiguous. |
| 06:53:00 | Varriount | With regard to proc parameters |
| 06:53:28 | filwit | Varriount: i raise this point in the post, it's not ambiguous at all with color coding. Just hard to see on github/nimforums |
| 06:53:33 | Skrylar | i'm not a fan of removing the colons but if you keep the colons then it reads like line noise to keep them |
| 06:53:53 | Varriount | filwit: Yes, but then you depend on syntax highlighting. |
| 06:54:02 | filwit | i really think i'm going to have to make a screenshot, cause everything keeps bringing that up and I kinda anticipated it |
| 06:54:14 | filwit | Varriount: do you really program in Notepad? |
| 06:54:33 | Skrylar | its not *just* syntax highlighting; nimrod is style-agnostic so what is a 'type' from a 'parameter name' |
| 06:54:44 | filwit | Varriount: and because the syntax rules are so straight-forward, you can make a regex for virtually every text-editor |
| 06:54:46 | Demos | to be fair I program in VS or scite, both of which do not do that highlighting |
| 06:54:46 | Varriount | filwit: I program everywhere. I write down ideas on paper in class, on my phone, etc. |
| 06:54:49 | Skrylar | which means to be particularly good, it needs parser support |
| 06:54:59 | Skrylar | unless you just shotgun it with 'highlight anything camelcase' |
| 06:55:02 | Demos | and docutils does not highlight them |
| 06:55:21 | Varriount | filwit: Also, there's a technical problem |
| 06:55:46 | filwit | Skrylar: i don't follow what you're saying |
| 06:56:12 | Varriount | Removing the colon means that, to the parser and compiler, there is less distinction between parameter ident's and their types. |
| 06:56:15 | Skrylar | filwit: proc soup(a, b some_type; c, d, e AlsoType) int: # what gets highlighted? |
| 06:56:34 | filwit | Demos: in Kate with my styleling Nimrod looks very good |
| 06:56:59 | Skrylar | maybe a PEG-based highlighter would understand its the identifier after a space not prefixed with a colon |
| 06:57:25 | Varriount | Hm. runvnc, what do you think? |
| 06:57:49 | runvnc | need a few minutes wasn't following |
| 06:58:01 | filwit | Skrylar: everything is "highlighted". but types/pragmas are hightlighted to be distinct. In your example some_type and AlsoType are highlighted like types because they follow variables |
| 06:58:08 | Varriount | filwit: I am interested, why remove the colons (other than "because" and "syntax highlighting") |
| 06:58:18 | Skrylar | filwit: i meant in a technical context |
| 06:58:27 | Skrylar | how you tell various syntax highlighters to do it correctly |
| 06:59:00 | Skrylar | Some highlighters are really weak (Vim's is sadly just regexp soup) while others are really powerful (TextMate/Sublime's CSS-scoping parsers) |
| 06:59:08 | filwit | Varriount: this is why i said to read the whole proposal.. it' explains why.. the main reason is to make OOP macros and type/proc/if/else completely consistent on how they're called (including multi-line calls like how var/const work) |
| 06:59:48 | Varriount | Skrylar: I can't think offhand how I would create a Sublime Text scoping rule to highlight that. |
| 07:00:38 | filwit | Skrylar: without semantic highlighting you highlight a context with the keyword 'proc' then every first-word is considered the name, preceding ones considered pragma/types |
| 07:00:45 | Varriount | filwit: Perhaps you could post a more in-depth of your OOP macros as they are now, and as they would be? |
| 07:01:06 | runvnc | where is the proposal |
| 07:01:19 | Varriount | http://forum.nimrod-lang.org/t/389 |
| 07:01:24 | filwit | Skrylar: i could make this highlight perfectly in Kate and probably Gedit/Aporia without any problems |
| 07:01:36 | * | xtagon quit (Quit: Leaving) |
| 07:02:18 | filwit | Varriount: the point is that for if/else/ect (including macros which consume bodies) the "body" follows the ':' |
| 07:02:39 | filwit | Varriount: whereas it follows the '=' for procs, and something completely different for types |
| 07:03:07 | filwit | Varriount: in my syntax, not only are all things completely consistent under one rule, it's also much easier to type and read (lot less symbols) |
| 07:03:25 | Varriount | filwit: Yes, that makes sense for *adding* colons or replacing '=', but not removing them (unless you want to have colons only be used for that one purpose) |
| 07:04:40 | filwit | Varriount: which i do actually, because then we also get the option to have {} as a indent-insensitive alternative to : |
| 07:05:43 | * | brson_ joined #nimrod |
| 07:05:51 | filwit | Varriount: plus, proc's already use : so i would need to shift it for those regardless. This proposal is a lot of me trying to work out exactly how to completely minimize the rules and shift things around so they're the _most_consistent across all language idioms |
| 07:06:15 | Varriount | filwit: Come-again? How does removing ':' from their role as type separators free up '{' '}'? |
| 07:07:04 | filwit | Varriount: ah, forgot to include that from the previous example. Set would be (similar to seqs) @{} or something |
| 07:07:35 | filwit | Varriount: or you could simply revers that and make @{} the brackets for indent insensitive |
| 07:07:40 | runvnc | If this proposal were the current syntax of Nimrod I would be happy. Generally I like fewer characters. |
| 07:07:43 | Varriount | filwit: Do you propose removing type-inference from let and var blocks? |
| 07:07:54 | filwit | Varriount: no |
| 07:08:04 | runvnc | I am not sure though whether removing these : and {} and swapping = actually makes the syntax clearer |
| 07:08:17 | runvnc | I think the biggest issue though is redoing all of the syntax highlighting tools |
| 07:08:37 | runvnc | so it would have to be a Really awesome syntax for people to want to do that |
| 07:08:44 | Varriount | filwit: Your removal of ':' from var and let blocks would make inference impossible |
| 07:08:50 | filwit | runvnc: considering there's relatively few of those tools today, probably not near as big a problem as actually changing the compiler syntax :P |
| 07:08:56 | runvnc | I don't think that Araq is going to do it |
| 07:09:11 | filwit | Varriount: no it wouldn't. please explain why you think that. |
| 07:09:12 | * | brson quit (Ping timeout: 264 seconds) |
| 07:09:13 | runvnc | if he does, I will be happy to skip typing a few : and maybe it will be better.. not sure if it is actually easier to read or not |
| 07:09:24 | runvnc | I like the current syntax also |
| 07:09:46 | filwit | runvnc: he very well may not. I hope he does, but if he doesn't I will probably eventually make my own parser (far from now) which works this way |
| 07:09:46 | runvnc | filwit: you are a brave man with a noble cause |
| 07:10:02 | runvnc | heh |
| 07:10:08 | filwit | ;) |
| 07:10:16 | runvnc | is there a representation for nimrod that is independent of syntax |
| 07:10:23 | runvnc | like an ast serialization |
| 07:10:35 | filwit | you mean the AST in general? |
| 07:11:00 | runvnc | well your proposal doesnt change the meaning of nimrod or how it works |
| 07:11:22 | filwit | yes, because Nimrod is pretty much perfect technically speaking :) |
| 07:11:24 | runvnc | so theoretically on some level in the machine's memory there could be an equivalent representation after parsing two different syntaxes |
| 07:11:25 | Varriount | filwit: Because, in nimrod, variables can be *assigned* types, "proc foo(x int)" could either mean, "assign this parameter the typedesc of int" or "set the type of this parameter as int" |
| 07:12:28 | filwit | Varriount: i'm not seeing the problem. could you make a more concrete code example? |
| 07:12:34 | runvnc | whats the difference varriount |
| 07:12:45 | Varriount | filwit: Maybe my arguments don't make sense. It's 2 in the morning, I should probably get some sleep and form coherent reasons. |
| 07:13:20 | filwit | Varriount: no problem. if you do in fact find a flaw (i doubt it because i have giving this a ton of thought) then i would love to hear it. |
| 07:13:45 | runvnc | question is how does an alternate parse get integrated into the toolchain or whatever |
| 07:13:53 | runvnc | parser |
| 07:13:59 | Varriount | filwit: I hope you don't dislike me too much for my disagreement. Maybe it's just my petty preferences getting the better of me. |
| 07:14:15 | Varriount | filwit: I hope you can put up more examples for me to peruse. |
| 07:14:22 | Varriount | Anyway, goodnight. |
| 07:14:25 | Skrylar | i'm going to bow out of the conversation for a bit; there is a colossal amount of dependency hell i have to code for this GUI |
| 07:14:26 | filwit | runvnc: i'm not sure exactly, but apparently it's pretty straight forward to make a new parser (though not so much to replace the existing one) |
| 07:14:51 | filwit | Varriount: okay, i will later, this stuff is all back-burner anyways |
| 07:14:55 | runvnc | if you make a new parser and hardly anyone uses it except you |
| 07:15:02 | runvnc | you can still say you made your own parse |
| 07:15:04 | runvnc | r |
| 07:15:10 | runvnc | or syntax and perhaps claim that it is better |
| 07:15:13 | runvnc | and maybe it will be |
| 07:15:36 | runvnc | and if the syntax of nimrod doesn't change then you could go on using your own syntax happily for the rest of your life |
| 07:15:51 | runvnc | perhaps start your own #nimrodbettersyntax |
| 07:15:58 | runvnc | move to spain |
| 07:16:03 | runvnc | get a compound |
| 07:16:05 | runvnc | sorry offtopic |
| 07:16:07 | runvnc | heh |
| 07:16:17 | filwit | ;P |
| 07:17:52 | runvnc | on the other hand since you are obviously another one of these geniuses maybe you could help the other nimrod geniuses with something that doesn't require writing a new parser |
| 07:18:10 | runvnc | anyway night |
| 07:18:13 | * | runvnc quit (Quit: Leaving) |
| 07:18:27 | filwit | Varriount: btw, you DID click on the github gist link in my proposal right? You didn't just see what's on the forums.. |
| 07:31:17 | Skrylar | I saw the gist |
| 07:31:38 | Skrylar | I'm not sure how I feel about removing :, even though keeping it generates line noise |
| 07:32:09 | Skrylar | "i like what the change is supposed to do, i don't like the change itself" |
| 07:32:11 | filwit | Skrylar: it's not about line noise, that's just an added benefit of shifting : to mean "consume body" |
| 07:33:08 | filwit | Skrylar: but if you have something more consistent across all fronts which makes OOP macros and type/proc entirely consistent, then please post it on the forums |
| 07:33:40 | filwit | Skrylar: right now i'm working on the documentation design, and we probably shouldn't get super side-tracked about these issues yet again |
| 07:35:00 | filwit | Skrylar: but I appreciate any feedback. |
| 07:36:11 | filwit | Skrylar: honestly though, i've thought about this A LOT, and i'm guessing if you really try to adjust what i've done by much you'll see it breaks consistency in some other place in the language (unlike my proposal which is very consistent across everything). |
| 07:39:19 | Skrylar | i do know that its going to break literally every line of code |
| 07:40:39 | filwit | yes and that is a concern. also it's not going to be easy for anyone to actually switch the syntax. That's why this is more about spreading ideas to the community than asking for a feature. |
| 07:43:36 | filwit | the main point is that syntax *is* important to a language's adoption at some level. It's debatable how much, and probably depends on who the audience is. But, like science, we should always improve and only do so when there's demonstrable reason. I think having a super-consistent syntax which allows for both python-style & c-style indentation would, at some point, really help Nimrod's adoption, which is why i'm putting the idea out there and letting it get ei |
| 07:43:36 | filwit | ther shot down (which i'll accept for valid reason) or eventually accepted by everyone and worked into the actual design |
| 07:43:52 | * | carum joined #nimrod |
| 07:44:16 | filwit | I'm hoping we haven't passed the point of no-return in terms of syntax (mean it wouldn't be worth changing the syntax due to backwards compatibility reason) |
| 07:50:29 | Skrylar | I should look in to using macros at some point. I haven't really gone past template use, and when I try to use macros it tends to just crash the compiler |
| 07:50:56 | Skrylar | s/use/write |
| 07:53:40 | filwit | macros in Nimrod are amazing :) |
| 07:54:33 | filwit | running to the store, bbl |
| 07:58:59 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 08:00:54 | NimBot | Araq/Nimrod devel 6f6c389 Araq [+0 ±3 -0]: fixes #942 |
| 08:00:54 | NimBot | Araq/Nimrod devel b1bbde2 Araq [+0 ±2 -0]: bugfix: unreported 'compiles' bug |
| 08:11:02 | * | filwit quit (*.net *.split) |
| 08:11:03 | * | comex quit (*.net *.split) |
| 08:11:04 | * | vendethiel quit (*.net *.split) |
| 08:11:05 | * | Varriount quit (*.net *.split) |
| 08:11:06 | * | CarpNet quit (*.net *.split) |
| 08:11:06 | * | cark quit (*.net *.split) |
| 08:11:06 | * | betawaffle quit (*.net *.split) |
| 08:11:09 | * | Demos quit (*.net *.split) |
| 08:11:12 | * | fowl quit (*.net *.split) |
| 08:11:12 | * | Raynes quit (*.net *.split) |
| 08:11:13 | * | eigenlicht quit (*.net *.split) |
| 08:11:14 | * | alphawaffle joined #nimrod |
| 08:11:17 | * | alphawaffle is now known as betawaffle |
| 08:11:51 | * | vendethiel joined #nimrod |
| 08:18:17 | * | CarpNet joined #nimrod |
| 08:18:56 | * | comex joined #nimrod |
| 08:22:55 | * | filwit joined #nimrod |
| 08:40:59 | filwit | nothing like working with spicy ramen at 3 in the morning :) |
| 08:45:00 | Skrylar | yay spicy food |
| 08:45:34 | Skrylar | downside of learning audio engineering: when you look at a waveform for an mp3 and go ".. no, they ruined it." |
| 08:46:21 | Skrylar | music is supposed to have all these interesting shapes and then theres a trend where they go in and ruin it all so it drowns itself out |
| 08:46:24 | filwit | never really got into audio processing |
| 08:49:30 | Skrylar | i like trying to produce music even though i'm crap at it |
| 08:49:56 | filwit | that's cool |
| 08:50:07 | * | XAMPP quit (Read error: Connection reset by peer) |
| 08:50:31 | filwit | i was always more into visual art, but i appreciate sounds too |
| 08:50:54 | Skrylar | bleh. i'd like to draw but practicing drawing is tedious |
| 08:51:19 | * | filwit things practicing music is tedious :P |
| 08:51:27 | Skrylar | I don't practice it correctly :> |
| 08:51:47 | filwit | fair enough |
| 08:52:03 | filwit | i had a guitar once that i was planning on learning to swoon all the girls with |
| 08:52:10 | filwit | but it burnt up in a car crash |
| 08:52:16 | Skrylar | :< |
| 08:52:44 | filwit | yeah. sux too. it had a nice grey wood finish |
| 08:52:48 | Skrylar | Its too bad the guy who wrote Buzz lost his source code. Apparently its *still* one of the best trackers |
| 08:53:10 | * | carum quit (Remote host closed the connection) |
| 08:53:35 | filwit | dunno what that is |
| 08:53:37 | Skrylar | Renoise does this annoying thing where you can't have a different length for drums as you can for the bass, everything has to be done in set size blocks; people have been griping about this for years apparently |
| 08:53:41 | Skrylar | its a tracker |
| 08:53:47 | Skrylar | old amiga-style music editor |
| 08:54:04 | Skrylar | trackers are basically what programmers would use to write music. lopl |
| 08:54:06 | Skrylar | *lol |
| 08:54:15 | filwit | ah, okay |
| 08:54:19 | filwit | like fruityloops |
| 08:54:25 | Skrylar | fruityloops is a sequencer |
| 08:54:46 | Skrylar | http://www.creativeobserver.com/img/4013_renoise_screenshot_lg.jpg |
| 08:55:05 | Skrylar | you put in notes on a top-down stack and it turns instruments on/off |
| 08:55:26 | filwit | i thought that's what fruityloops did too |
| 08:55:35 | Skrylar | fruityloops uses a piano roll |
| 08:56:02 | * | filwit will not retain any of this.. |
| 08:56:06 | Skrylar | :P |
| 08:56:10 | filwit | ;) |
| 08:56:27 | Skrylar | i would not object to writing a tracker at some point, if i escape GUI-writing prison |
| 08:56:38 | Skrylar | Renoise is nice but the devs... don't really.. listen to anyone |
| 08:57:02 | filwit | make gui-less music program |
| 08:57:09 | filwit | control entirely through shortcuts |
| 08:57:15 | Skrylar | thats pretty much a tracker |
| 08:58:17 | Skrylar | some people like them because they're almost entirely keyboard driven |
| 08:58:21 | Skrylar | or basically "vi for music" |
| 08:58:30 | filwit | lol |
| 08:58:40 | Skrylar | whereas fruityloops is more like "photoshop for music" |
| 08:59:12 | filwit | that explains things better than any lengthy detailed explanation could have.. |
| 08:59:49 | Skrylar | fruity is so freakin expensive these days |
| 08:59:59 | Skrylar | i wish i could have gotten a copy back when it was like 60$ for the whole program |
| 09:00:01 | Ycros | I really don't like trackers |
| 09:00:57 | Skrylar | i like them for drafting |
| 09:01:14 | * | cark joined #nimrod |
| 09:01:14 | * | eigenlicht joined #nimrod |
| 09:01:14 | * | Raynes joined #nimrod |
| 09:01:14 | * | fowl joined #nimrod |
| 09:01:14 | * | Demos joined #nimrod |
| 09:01:19 | Skrylar | usually if you mention wanting to use both in the same project people stare at you |
| 09:01:31 | Ycros | hmm that could be nice |
| 09:01:40 | Ycros | I usually just play things in though |
| 09:02:17 | Skrylar | i found that for whatever reason my better sounding stuff has come out of a tracker; usually in piano rolls i get stuck trying to get individual notes to obey |
| 09:02:20 | Ycros | I use Ableton |
| 09:02:52 | Skrylar | i have reaper+renoise; i think i touched ableton once but had no idea how to use it |
| 09:02:53 | * | Varriount joined #nimrod |
| 09:05:47 | Demos | yay! my bug was fixed!. Thanks Araq |
| 09:05:47 | * | Demos quit (Quit: Leaving) |
| 09:06:03 | Ycros | I have reaper, but I've only really used it for ninjam |
| 09:09:07 | Skrylar | I was indifferent to reaper for the most part; then i discovered you can tell it to delete notes when right clicking and i liked it again |
| 09:09:13 | Skrylar | also has really good support for OSC |
| 09:09:17 | Ycros | heh |
| 09:09:34 | Skrylar | i hated how every sequencer on linux gave me a context menu on right click, except for LMMS |
| 09:12:52 | * | cark quit (Write error: Connection reset by peer) |
| 09:12:52 | * | cark joined #nimrod |
| 09:16:46 | Ycros | yeah lmms is probably the best open source one. It's a vague FL clone |
| 09:27:19 | Skrylar | woot, today was productive |
| 09:27:22 | Skrylar | wrote a rectangle math module |
| 09:27:31 | Skrylar | well, another one, but this one is all clean and polished |
| 09:44:02 | * | ddl_smurf joined #nimrod |
| 09:48:12 | * | krusipo quit (Ping timeout: 264 seconds) |
| 09:49:59 | filwit | a tuple does not need to be {.pure.} right? That's just redundant? |
| 09:56:02 | * | aftersha_ quit (Ping timeout: 264 seconds) |
| 09:56:11 | Araq | filwit: yes. same for 'object' |
| 09:57:13 | filwit | Araq: okay. i see, because non-inheritable objects don't need the header either. thanks. |
| 10:14:28 | * | krusipo joined #nimrod |
| 10:25:04 | filwit | Araq: is there anyways (besides parsing macros.lineInfo) to get the module name from an expr/stmt padded to an immediate macro? |
| 10:25:35 | Araq | no and in general going up the AST is unsound |
| 10:25:47 | Araq | so don't ask for it :P |
| 10:26:11 | filwit | isn't that exactly what callsite is doing tho? |
| 10:26:43 | filwit | (plus, if things are order-dependent even at the global level, why is it unsound?) |
| 10:27:09 | filwit | (don't need an answer to that, just wondering) |
| 10:27:55 | filwit | Araq: okay thanks. I was just looking to do something a little more 'automatically' but using a pragma will work just fine |
| 10:28:37 | Araq | callsite is the upper bound of what's sane to allow |
| 10:29:16 | filwit | i haven't really played with callsite yet, but doesn't that basically give me a full overview of the AST from any expr/stmt? |
| 10:29:56 | filwit | is it immutable or something? I don't see how that would be allowed but something like getting the module name would be considered unsound. |
| 10:31:23 | * | brson_ quit (Quit: leaving) |
| 10:31:30 | filwit | or perhaps callsite is also unsound but still there for pragmatic reasons? |
| 10:31:44 | Skrylar | does the compiler even retain the full module path for that? |
| 10:31:55 | filwit | Skrylar: yes |
| 10:32:09 | Skrylar | i know "import foo.bar" is allowable, but i don't know if it would then later regurgitate "foo.bar" in say, logging code |
| 10:32:40 | Skrylar | all though right now if you ask for the position you get a string (not a separate 'filename' and 'line' value) which is just '???:-1,-1' |
| 10:33:29 | Araq | Skrylar: that's a regresssion, can you report it please |
| 10:33:44 | filwit | Skrylar: macros.lineinfo gives you specific information about any expr's file (and it's placement within) |
| 10:34:23 | Araq | and indeed macros.lineinfo is unsound for another definition of 'unsound' ;-) |
| 10:34:50 | Araq | callsite is sound though |
| 10:35:19 | * | Araq needs to write more blog posts ... |
| 10:37:49 | filwit | oh, one more thing.. does {.noSideEffect.} have any performance implications? |
| 10:37:57 | filwit | i think i asked this before but i forgot |
| 10:38:17 | filwit | meaning, does it pass something along to GCC which could allow for greater optimization? |
| 10:38:24 | Araq | not really plus the compiler infers it anyway |
| 10:38:45 | Araq | the planned optimizer will make excessive use of it though |
| 10:38:51 | filwit | okay thanks (and good to know) |
| 10:39:20 | Skrylar | Araq: you mean that magic LLVM pass that makes all of the problems go away supposedly? </rust> |
| 10:40:24 | filwit | btw, i was looking at the generated C for a release build, and it looks like the current system.new() isn't as optimized as it could be as it does a lot of "result = 0;". Seems like it could use a few {.noInit.}s |
| 10:41:02 | filwit | just a note.. |
| 10:41:25 | Skrylar | i thought the extra result = 0's were something that was supposed to be fixed when the effect system was more stable |
| 10:41:52 | Araq | result = 0 is optimized by C's optimizer anyway |
| 10:42:03 | Araq | memset(result, ...) is more of a problem |
| 10:42:22 | Araq | *is optimized away |
| 10:42:37 | filwit | i'm not so positive about the "result = 0".. |
| 10:42:46 | filwit | based on previous benchmarks.. |
| 10:43:01 | Araq | so check the produced assembler and prove me wrong |
| 10:43:17 | Araq | the benchmarks are using vectors though which memset |
| 10:43:58 | filwit | so some {.noinit.}s would be a good thing either way :P |
| 10:44:15 | Araq | yes, but for 'result = 0' it is irrelevant |
| 10:44:18 | filwit | maybe i'll try and go through that part of the compiler later on for exercise |
| 10:44:45 | Araq | and I already said 'noInit' is another planned optimization |
| 10:45:01 | filwit | i missed you saying that |
| 10:45:07 | Araq | we got control flow analysis only recently |
| 10:46:00 | filwit | so as of now you're saying you haven't fine-combed the compiler with optimizer pragmas, or are you talking about some new optimizer thing? |
| 10:46:55 | Araq | new optimizer thing |
| 10:47:05 | Araq | that's built on sempass2 |
| 10:47:21 | filwit | dunno what that is, but it sounds cool |
| 10:47:37 | Araq | sempass2 already needs to do control flow analysis and guard propagation and something that resembles CSE |
| 10:47:38 | filwit | i'll look into later at some point |
| 10:47:54 | Araq | it might as well optimize the code then too |
| 10:51:55 | Araq | bbl |
| 11:00:32 | filwit | Araq (when your back): would you say it's more efficient (in terms of compile-time) to use a macro with a lot of "newNimNode(); etc; etc" or "getAST(protoTemplate)" ? |
| 11:01:53 | filwit | Araq: I would prefer the later as it makes some of my code easier to understand in general, but I'm afraid of the performance overhead it may cause (and don't want to lengthy benchmarks right now). So do you think it would be better/worse/roughly-same ? |
| 11:04:16 | filwit | i'm hoping getAST doesn't run in the VM and actually increases performance.. guess i could just look.. |
| 11:04:17 | fowl | Error: internal error: expr: var not init result <-- what are you trying to tell me, compiler!! |
| 11:04:50 | * | aftershave_ joined #nimrod |
| 11:04:59 | Skrylar | fowl: it sounds like the special 'result' value which represents a proc's return value didn't get initialized, but the proc returns an object which really should be |
| 11:20:26 | * | q66 joined #nimrod |
| 11:20:55 | * | io2 joined #nimrod |
| 11:22:36 | fowl | i need sleep |
| 11:22:45 | filwit | later |
| 11:22:47 | Skrylar | sleep is good |
| 11:26:18 | filwit | oh god, just thought of the best name for my game engine... 'syn' (pronounced 'sin', but short for 'syntax', complete with some sort of horns/devil/evil-smile/or-something) |
| 11:26:30 | filwit | that has to be taken... |
| 11:26:53 | filwit | http://sourceforge.net/projects/mengin/ |
| 11:26:58 | filwit | damn you! |
| 11:36:35 | Araq | filwit: 'getAst' should be faster but these concerns should be gone with vm2, right? |
| 11:37:05 | Araq | newNimNode produces 1 VM instruction in general ... |
| 11:37:38 | filwit | Araq: i only recently learned how to use getAst, haven't really payed attention to compile-times since it's never been a slowdown yet |
| 11:38:20 | filwit | Araq: but thanks for the confirmation, was kinda expecting that, but wasn't sure if getAst was using the VM for some reason |
| 11:39:01 | Araq | not sure what you mean, getAst uses the VM when it's used in a macro |
| 11:39:37 | filwit | Araq: i meant it's internal operations |
| 11:40:01 | filwit | getAst invokes a precompiled parser-to-ast func right? |
| 11:40:07 | filwit | even when called from within a macro |
| 11:40:19 | Araq | right |
| 11:40:40 | Araq | well the compiler uses the same AST as the macro system so no translation of any kind is necessary |
| 11:41:12 | Araq | which is why the macros API is so ugly in places but also why it kicks ass |
| 11:41:15 | filwit | btw, while compile-times have never really been an issue, VM2 (or maybe some other recent VM change) doesn't seem to have that random 2-sec hang anymore |
| 11:42:26 | filwit | Araq: yeah it took me a little to wrap my head around how the codegen and VM share the same AST nodes |
| 11:42:53 | filwit | Araq: pretty cool design ;) though i'm still not fully aware of all it's facets and details |
| 11:45:23 | Araq | dunno if the design is cool or not, it's awful to implement correctly |
| 11:46:37 | filwit | oh btw, my brother now wants to make a C#-to-Nimrod system for Xamrin devs ;-) |
| 11:48:35 | filwit | he plans on using one of the C# AST libs (NRefactory or Roslyn, i forget which) to convert to Nimrod so that C# developers can take advantage of Nimrod's native codegen (for Android/iOS where they have to pay Xamerin for special libs) and it's awesome GC |
| 11:48:53 | Araq | ok ... |
| 11:49:07 | filwit | i thought you would be excited... |
| 11:49:17 | filwit | is there something wrong with that? |
| 11:49:35 | * | darkf_ joined #nimrod |
| 11:49:39 | Araq | nah I simply have to much experience |
| 11:49:42 | * | darkf quit (Disconnected by services) |
| 11:49:44 | * | darkf_ is now known as darkf |
| 11:50:05 | Araq | I keep the excitement for later, when he has working code |
| 11:50:21 | Araq | and figured out the nasty details |
| 11:50:25 | Araq | ;-) |
| 11:50:33 | filwit | oh i see, i thought you didn't want him using Nimrod for his project or something :P |
| 11:50:55 | filwit | I'm trying to win him over, and slowly he's starting to listen to reason |
| 11:51:11 | filwit | but he still has a very large investment in C# and things like XNA/MonoGame |
| 11:52:50 | filwit | anyways, just thought I'd tell you he was now interested (to the point he's going to learn Nimrod) to make that, so hopefully he sees the light after actually playing with Nimrod for awhile, haha (he's never really looked at Nimrod no matter how much i try and get him too) |
| 11:56:49 | * | Skrylar quit (Remote host closed the connection) |
| 12:04:56 | * | Skrylar joined #nimrod |
| 12:05:07 | Skrylar | Araq: I don't suppose there is a cuckoo hash table hiding in the stdlib |
| 12:05:53 | Araq | no, please implement it |
| 12:08:21 | Skrylar | that will have to occur after sleep |
| 12:08:24 | Skrylar | lol |
| 12:16:53 | Skrylar | this GUI crap will probably need a glyph cache to store rendered text characters in, it looks like thats a decent hash for something like it |
| 12:17:54 | Skrylar | also thinking about cheating and storing the floats in int16's, because texture references tend to be in 0.0-1.0 and there shouldn't be an issue with resolution as nobody is putting 65k by 65k textures in opengl |
| 12:18:30 | Skrylar | cheating it like that saves at least four bytes per glyph |
| 12:49:54 | * | io2 quit () |
| 13:00:24 | * | askatasuna joined #nimrod |
| 13:05:14 | * | BitPuffin joined #nimrod |
| 13:30:37 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 13:34:21 | * | nequitans_ joined #nimrod |
| 13:35:19 | * | faassen joined #nimrod |
| 13:41:44 | * | BitPuffin joined #nimrod |
| 13:47:29 | * | io2 joined #nimrod |
| 13:48:23 | * | r0b4 joined #nimrod |
| 13:55:56 | * | OrionPK quit (Ping timeout: 252 seconds) |
| 14:12:16 | * | awestroke joined #nimrod |
| 14:29:40 | * | darkf quit (Quit: Leaving) |
| 14:41:21 | * | OrionPK joined #nimrod |
| 14:41:46 | * | nequitans_ quit (Ping timeout: 244 seconds) |
| 14:42:08 | OrionPK | jebus, silly static ip |
| 14:58:39 | * | askatasuna quit (Quit: WeeChat 0.4.2) |
| 15:09:15 | * | io2 quit () |
| 15:24:59 | * | Endy joined #nimrod |
| 15:25:11 | * | faassen quit (Quit: Leaving.) |
| 15:55:26 | NimBot | Araq/Nimrod devel 6598447 Pontus Stenetorp [+0 ±1 -0]: No execute bit for c-sources build.sh, fixing doc |
| 15:55:26 | NimBot | Araq/Nimrod devel bac16bf Simon Hafner [+0 ±1 -0]: Merge pull request #974 from ninjin/devel... 2 more lines |
| 15:57:47 | * | askatasuna joined #nimrod |
| 15:57:52 | * | filwit quit (Quit: Leaving) |
| 16:02:55 | * | [1]Endy joined #nimrod |
| 16:06:19 | * | Endy quit (Ping timeout: 252 seconds) |
| 16:06:19 | * | [1]Endy is now known as Endy |
| 16:19:14 | * | awestroke quit (Remote host closed the connection) |
| 16:29:02 | * | ddl_smurf_ joined #nimrod |
| 16:29:15 | * | ddl_smurf quit (Read error: Operation timed out) |
| 16:29:15 | * | ddl_smurf_ is now known as ddl_smurf |
| 16:38:49 | * | zielmicha joined #nimrod |
| 17:38:16 | * | DAddYE joined #nimrod |
| 17:39:00 | * | DAddYE quit (Client Quit) |
| 17:39:17 | * | DAddYE joined #nimrod |
| 17:44:21 | * | brson joined #nimrod |
| 17:49:55 | * | xtagon joined #nimrod |
| 17:58:16 | * | carum joined #nimrod |
| 18:13:12 | * | Matthias247 joined #nimrod |
| 18:21:20 | * | carum quit (Remote host closed the connection) |
| 18:24:49 | * | askatasuna quit (Quit: WeeChat 0.4.2) |
| 18:24:57 | * | carum joined #nimrod |
| 18:29:44 | * | nande joined #nimrod |
| 18:53:34 | * | Endy quit (Ping timeout: 252 seconds) |
| 18:57:18 | Varriount | Araq: What do you think of filwit's syntax proposal? |
| 19:04:05 | dom96 | hello |
| 19:07:23 | reactormonk | Varriount, syntax proposal? |
| 19:08:24 | dom96 | http://forum.nimrod-lang.org/t/389 |
| 19:11:23 | reactormonk | interesting. |
| 19:11:45 | reactormonk | I think this might go hand-in-hand with mixed case sensitivity with variables lowercase and types uppercase |
| 19:12:20 | * | Varriount still doesn't like the removal of ':' to specify types |
| 19:12:26 | reactormonk | ^ exactly |
| 19:13:59 | Varriount | reactormonk: I've also found a problem with the syntax suggestion - it fails with pragma that accept parameters, or procs that have no pragmas or one pragma and no return type. |
| 19:14:32 | reactormonk | Varriount, pos them. |
| 19:14:33 | Varriount | "proc foo(a int) bar:" - Is bar a pragma, or a type? |
| 19:14:38 | EXetoC | yeah, going from 4 to 2 characters will make most people happy |
| 19:14:57 | reactormonk | Varriount, it's a pragma if we have mixed-case |
| 19:15:19 | Varriount | reactormonk: Howso? |
| 19:18:29 | * | sdmtrack joined #nimrod |
| 19:18:52 | dom96 | hi sdmtrack |
| 19:19:45 | Varriount | dom96: What do you think? |
| 19:19:56 | * | dom96 is writing a long post describing his views |
| 19:20:13 | Varriount | dom96: How conincidental, so am I. |
| 19:20:23 | Varriount | *coincidental |
| 19:22:09 | reactormonk | Varriount, if we get mixed as casesensitivity sometime in the future, types start with a capital letter and everything else with a lowercase |
| 19:22:20 | reactormonk | Varriount, but still, it's a valid point. post it. |
| 19:28:34 | Varriount | dom96: Let me know when you post your comments. |
| 19:28:42 | dom96 | ok |
| 19:29:30 | * | Demos joined #nimrod |
| 19:29:38 | Varriount | Hi Demos |
| 19:30:17 | Demos | hi Varriount |
| 19:36:53 | * | io2 joined #nimrod |
| 19:39:13 | dom96 | Varriount: posted |
| 19:41:14 | Varriount | dom96: Thanks. You might want to lso mention, in the part where you mention syntax highlighting, that not all of us write code where syntax highlighting is available (pieces of paper...) |
| 19:41:35 | Varriount | And yes, I am one of those people. |
| 19:42:00 | dom96 | True. You can mention that. |
| 19:42:21 | dom96 | I'm scared people will say "You might as well use Notepad then" |
| 19:42:41 | Varriount | dom96: I'll probably have a post up later today (in about 5-7 hours) |
| 19:44:25 | * | skyfex joined #nimrod |
| 19:45:33 | dom96 | ooh, finally something I can participate in? https://www.calltocode.ie |
| 19:46:03 | dom96 | Nope. |
| 19:46:12 | dom96 | "a resident and legal citizen of the Republic of Ireland" |
| 19:46:14 | OrionPK | I agree with Varriount. the ":"'s should stay |
| 19:46:16 | dom96 | Screw you too Google :( |
| 19:48:16 | Matthias247 | I'm too old :`( |
| 19:49:00 | Varriount | I'm not a legal citizen of the ROI |
| 19:49:12 | dom96 | I'm in Northern Ireland. |
| 19:49:27 | Varriount | Oh, and I'm also too old. |
| 19:51:08 | Demos | damn another generic bug |
| 19:51:47 | io2 | dom96: you should most definitely watch Sagan's series first. |
| 19:52:24 | dom96 | io2: It's so old though lol |
| 19:52:55 | io2 | dom96: my childhood has so many fond memories of this and sagan's way of portraying the unknown was something extraordinary |
| 19:53:06 | io2 | he also issued updates to every episode of the series after years |
| 19:53:20 | io2 | dom96: it is a question of watching the man speak and analyze his way of thinking. |
| 19:53:45 | io2 | the mona lisa is also old, but still awesome nonetheless, remember that ;) |
| 19:54:49 | Skrylar | dom96: did you end up getting a response from GSOC? |
| 19:54:51 | * | filwit joined #nimrod |
| 19:55:07 | filwit | hey, scanned logs, can't stay long. |
| 19:55:11 | filwit | Varriount: "proc foo(a int) bar:" - Is bar a pragma, or a type? |
| 19:55:21 | filwit | it's a proc named 'foo' |
| 19:55:42 | filwit | if you want pramas with param, use regular syntax: proc foo bar(..) int: ... |
| 19:55:51 | filwit | bar is the pragma |
| 19:56:25 | filwit | if proc appears after a '=' then the name insn't considered |
| 19:56:29 | filwit | isn't** |
| 19:56:50 | dom96 | oh. That looks an ambiguity. |
| 19:56:53 | dom96 | *looks like |
| 19:57:51 | filwit | it does appear like it, though technically syntax highlighting could fix that. but you might have found a flaw |
| 19:57:58 | * | shevy joined #nimrod |
| 19:58:06 | shevy | hey fowl! paranoidd is doing gobolinux releases |
| 19:58:27 | dom96 | filwit: Sadly I don't think so. |
| 19:58:34 | dom96 | The compiler won't be able to tell the difference. |
| 19:59:02 | Varriount | Not without some heavy inference to tell when a ident is a type or a pragma |
| 19:59:28 | dom96 | I don't think that would even help. |
| 19:59:35 | Demos | https://gist.github.com/barcharcraz/6b9bcfc874334de2c914 <-- should it compile? |
| 19:59:37 | dom96 | If you have a type Bar and a pragma Bar. |
| 19:59:42 | filwit | dom96: you might be right, but then there might be solutions to that that doesn't involve using the {. .} |
| 20:00:55 | dom96 | There is another argument against this, sometimes people do not use nimrod syntax highlighting in gists... :P |
| 20:01:14 | dom96 | Demos: What's the error? |
| 20:02:05 | Demos | refersh gist |
| 20:02:15 | Varriount | I can't syntax highlight code scrawled on pieces of paper in my math class, or in the car (as a passenger)... at least, not without some coloured pencils. |
| 20:02:20 | * | OrionPK quit (Ping timeout: 252 seconds) |
| 20:02:30 | filwit | dom96: not the best of arguments, but somewhat valid. I would take a consistent cleaner syntax over github highlighting any day. |
| 20:03:01 | filwit | dom96: i'm not sure if there's an ambiguity with "proc name pragma()" vs "type name = proc pragma()" |
| 20:03:29 | filwit | whoops.. used '=' when i should have used ':' :P |
| 20:03:33 | * | dom96 considers printing out some syntax highlighted Nimrod code and putting it up on his wall |
| 20:03:58 | * | filwit thinks it would make good wallpaper |
| 20:04:34 | Varriount | filwit: Have you considered using source code filters to alleviate some of your OO macro problems? |
| 20:04:36 | dom96 | filwit: See how natural '=' is? :P |
| 20:05:07 | dom96 | Demos: Indeed looks like a bug |
| 20:05:18 | filwit | dom96: i actually realized that in my proposal both : & = where completely interchangable |
| 20:05:38 | dom96 | filwit: Did you read my post? |
| 20:05:40 | filwit | Varriount: no, i don't even know what source code filter do much and how they work, but i've heard them mentioned before |
| 20:05:47 | filwit | dom96: no |
| 20:06:33 | Varriount | Seriously? Am I the only one that enjoys reading every document on a website? |
| 20:06:38 | Varriount | filwit: http://nimrod-lang.org/filters.html |
| 20:06:54 | * | rallan quit (Remote host closed the connection) |
| 20:06:56 | * | sdmtrack quit (Remote host closed the connection) |
| 20:07:30 | Demos | dom96, I am not 100% sure. it seems like a consequence of substitution failure during instantiation being considered an error |
| 20:07:32 | filwit | Varriount: yeah i came across it before but never really payed attention. Will check it out later. |
| 20:07:44 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 20:08:07 | * | OrionPK joined #nimrod |
| 20:08:17 | Varriount | filwit: They can also be used by those who prefer using tabs |
| 20:08:19 | filwit | dom96: thanks for writing a thorough response, but i disagree with you about the {} thing for the same reasons I would disagree that case-insensitivity is a bad thing |
| 20:08:28 | OrionPK | what was my exit code from irc, anyone? |
| 20:08:32 | Demos | I am not sure if nimrod's behavior is actually extremely confusing or if I am just really used to c++, where a failure during substitution is ignored as long as there are other versions of the template that do work |
| 20:08:35 | filwit | dom96: if anything optional {} would attract many more users |
| 20:08:39 | Varriount | OrionPK: Timeout |
| 20:08:43 | OrionPK | mmk.. thanks |
| 20:08:47 | OrionPK | must have lost my internet at home |
| 20:08:56 | dom96 | filwit: Then why doesn't style insensitivity attract more users? |
| 20:08:58 | * | Mat3 joined #nimrod |
| 20:09:01 | Mat3 | hi all |
| 20:09:15 | Varriount | Hi Mat3 |
| 20:09:19 | Demos | one problem is that so few people even know we exist |
| 20:09:59 | Mat3 | hello Varriount |
| 20:10:13 | * | Varriount throws a Konig Pudle into Mat3's lap |
| 20:10:30 | filwit | dom96: sorry read your question wrong for a sec. Case insensitivity probably would attract users, just not by itself |
| 20:10:36 | Demos | I feel like generics are so similar to c++ templates that I really expect them to work exactly the same way, but that does not come from a rational thought process, just gut. |
| 20:10:54 | Varriount | Demos: I have heard wierd things about C++ templates. |
| 20:11:00 | Demos | like what? |
| 20:11:12 | Varriount | Like how they can dramatically increase compilation time, and cause wierd errors. |
| 20:11:13 | OrionPK | comcast sucks |
| 20:11:44 | Demos | I dont think they harm compile time that much, esp if you use them as generics and not as a computational device |
| 20:11:53 | filwit | dom96: plus, case-style doesn't seem to be as big a concern as indent in/sensitivity does |
| 20:12:05 | filwit | dom96: **among those that care |
| 20:12:25 | filwit | dom96: it seems you have die-hard fans on both sides of the python/c-style fence |
| 20:12:34 | Demos | and nimrod has typeclasses which helps with the errors. Trouble is even "specializeing" on typeclasses EVERY version of the template must be valid with all types that are supposed to be valid for ONE of the templates |
| 20:12:42 | Araq | filwit: IF we redesign the syntax from scratch I really think we should start with this: http://www.dwheeler.com/readable/ |
| 20:12:50 | filwit | dom96, Araq: sorry, brb |
| 20:13:49 | Araq | Demos: failure of a generic constraint shouldn't produce an instantiation |
| 20:14:04 | Araq | are you sure this is not a recently introduced regression? |
| 20:14:10 | * | shevy left #nimrod ("I'll be back ... maybe") |
| 20:14:26 | Mat3 | templates in general can lead to obscur errors |
| 20:14:29 | Demos | actually it may be because of the recently fixed compiles() bug |
| 20:14:50 | Demos | still. what do you think about my gist code? should it compile? |
| 20:16:49 | filwit | Araq: if you do that you will loose a lot of users. Part of my proposal is about making both *large programming camps* feel comfortable. I don't think Lisp is a huge community of people, and surely that syntax will only serve to make it harder to get Nimrod used in production (aka, your eventual funding) |
| 20:17:30 | Araq | filwit: Lisp is the crown of consistent syntax, so we start from there and introduce shortcuts ... it makes perfect sense |
| 20:17:45 | * | OrionPK quit (Ping timeout: 252 seconds) |
| 20:18:00 | filwit | Araq: because my suggest was basically just removing some existing nimrod symbols, i started writing a simple parser to lower my suggested code to nimrod code and it's somewhat with very little (read 1 hour) or work |
| 20:18:10 | Araq | you start from the current syntax and try hard to remove any kind of delimiters. I can't see this work. |
| 20:18:34 | Araq | I don't think it works technically and I can't see how this attracts new people |
| 20:18:45 | filwit | Araq: i'm actually open to "start from consistent, add alias". but I don't like that proposed syntax in the link you gave |
| 20:19:08 | Araq | filwit: that's fine, it's about the approach |
| 20:19:55 | Mat3 | Araq: Polish Notation do not need parentheses at all (see Logo) |
| 20:20:24 | Araq | Mat3: good point but again, I'm talking about the approach |
| 20:20:56 | filwit | Araq: anyways, what should happen is just making a toy parser which lowers to Nimrod code, like my 1-hour project last night. Then making a Kate/GEdit syntax highlighter to illustrate thing. Then we can play around with things off-n-on for however long it takes to figure out any better syntax if one exists. |
| 20:21:13 | filwit | Araq: part of attracting new users is about advertisement. That has two issues: |
| 20:21:16 | Demos | Araq, yup my example still fails when I add a typeclass "x is int1" and "x is int2" to the respective functions |
| 20:21:43 | filwit | Araq: a) the cleaner the code you illustrate. the easier it is for others to swallow and the sexier it looks compared to C/C++ |
| 20:22:10 | Demos | the current syntax looks damn sexy to my c++ trained eyes |
| 20:22:18 | Mat3 | filwit: If you prefer simple parsers, why not a RPN one (which do not need to be parsed at all) ? |
| 20:22:21 | filwit | Araq: b) making people comfortable (like having both indent in/sensitive style) could help in any articles promoting the language |
| 20:22:46 | filwit | Mat3: don't know what RPN is |
| 20:23:03 | Demos | 3 4 + <--> (3 + 4) |
| 20:23:11 | filwit | Araq: as it stand, my Nimrod code in Kate looks very pretty already |
| 20:23:28 | Mat3 | filwit: Reverse Polish Notation |
| 20:23:43 | Araq | Demos: your code should work but 'is' has all sort of problems within a 'static' section. known issue but only zahary1 knows the spec of 'is' in a static context :P |
| 20:24:22 | Demos | the example actually comes from me using "compiles" in the when block |
| 20:24:51 | Demos | but is made reduceing the problem to a test case eaiser |
| 20:24:58 | Araq | Demos: well 'compiles' is just inherently flawed and will ultimately be removed or further restricted |
| 20:25:13 | Demos | oh? why is that? |
| 20:25:44 | Araq | because theoretically *every single change* then can break code |
| 20:26:04 | Araq | as some guy might have checked that it doesn't compile but now it does |
| 20:26:21 | Demos | I am using it as a "does this identifier exist" |
| 20:26:30 | Araq | yes well |
| 20:26:36 | Araq | there is 'defined' for that |
| 20:27:00 | Demos | does that work on regular global var/lets |
| 20:27:07 | Araq | yes |
| 20:27:27 | Araq | which is another flaw lol but a minor one |
| 20:27:29 | Mat3 | filwit: proc multi (x: int) = x * x (Nimrodish) <=> multi: i1 i1 * (RPN Nimrodish) |
| 20:27:46 | Demos | still failing, I am pretty sure it is a problem with generic instantiation |
| 20:28:35 | filwit | Mat3: completely unrealistic unless you're used to Lisp, which most programmers aren't, so bad idea |
| 20:29:04 | Araq | filwit: Lisp might not be sexy, but Clojure surely had its hype and is successful |
| 20:29:22 | Mat3 | well, better attract the right ones I would say |
| 20:30:26 | filwit | dom96: ... i was expecting better arguments from your forum post. Basically you say my syntax "feels like C" and that's why you don't like the space seporation. Then your code example (scala vs nimrod) doesn't even use pragmas which is one of the main parts of my proposal. |
| 20:30:32 | NimBot | Araq/Nimrod devel 9613eb4 Araq [+0 ±1 -0]: c2nim knows about the 'union' pragma |
| 20:30:32 | NimBot | Araq/Nimrod devel b03b82b Araq [+0 ±9 -0]: implemented 'union' and 'unchecked' pragmas |
| 20:30:32 | NimBot | Araq/Nimrod devel 903d3ad Araq [+0 ±2 -0]: system.nim makes use of the 'unchecked' pragma |
| 20:30:32 | NimBot | Araq/Nimrod devel 798ae48 Araq [+0 ±1 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 20:31:35 | dom96 | Mat3: I in fact suggested the same thing yesterday. |
| 20:31:38 | * | OrionPK joined #nimrod |
| 20:31:55 | Araq | Mat3: the compiler now supports 'union'. enjoy. |
| 20:32:06 | Mat3 | great, thanks !!! |
| 20:32:07 | dom96 | But people are not used to RPN |
| 20:32:20 | filwit | Araq: Lisp itself could be considered "successful" it just depends on how much you're willing to bend that definition |
| 20:32:28 | Demos | emacs! |
| 20:32:39 | * | carum quit (Remote host closed the connection) |
| 20:33:09 | dom96 | filwit: ... thanks. |
| 20:34:24 | Demos | anyway should I open an issue saying "this should probably compile"? |
| 20:34:28 | Skrylar | Demos, Varriount: @C++ Templates, they destroy compile time *if overused* |
| 20:34:39 | Demos | and I think compiles is totally reasonable for build systemish stuff |
| 20:34:55 | dom96 | filwit: The Scala example was more against replacing the '=' |
| 20:34:57 | Demos | Skrylar, I think that c++ textual inclusion is probably worse than templates |
| 20:35:06 | Skrylar | What happens is that somebody starts using std::pair instead of a POD, and then somewhere you use a functor and some kind of hash table, and then someone else uses a different one somewhere, and now you have to compile the same code like 300 times |
| 20:35:12 | dom96 | filwit: And in general to show just how similar Nimrod is to Scala. |
| 20:35:23 | Araq | Demos: yes please |
| 20:35:31 | Skrylar | yeah, textual inclusion and unparsable syntax don't mix well together |
| 20:36:00 | Skrylar | there are some bigger C builds that if you arrange everything in to a single compilation unit, a full build takes ~3 minutes instead of 15-30 |
| 20:36:05 | filwit | dom96: yes but my proposal doesn't even change Nimrod much and if you replaced Scala with Python it would look somewhat just as similar of a comparison |
| 20:36:11 | Skrylar | however then you can *only* do a full build :/ |
| 20:36:16 | Mat3 | dom96: I know it is not common, but beside implementation advantages it also offers a general solution to most of all 'magic simplifying rules' which results from traditional infix notation so this notation is of general use and worth to learn |
| 20:36:35 | filwit | dom96: sorry, i was a little too critical of your post. Your argument about the {} vs : thing where well formed, even though i disagree |
| 20:37:05 | Mat3 | ^usage? |
| 20:37:07 | filwit | dom96: i just don't like your criticism about me "turning Nimrod into C" which is both untrue and subject |
| 20:37:37 | Skrylar | Probably more like turning nimrod in to Go if anything; doesn't Go use the space-as-typedef syntax? |
| 20:37:37 | Demos | Skrylar, yeah, I know this. Heck C build times are not that great |
| 20:37:59 | Skrylar | Demos: they're comparatively awesome if you have clean headers (read: use makeheaders and shielding) |
| 20:38:08 | Skrylar | s/shielding/"opaque pointers" |
| 20:38:39 | Demos | what is shielding, jut #ifndef include guards? |
| 20:38:56 | Demos | I was under the impression the "correct" way was not to include stuff in headers and just document dependencies |
| 20:38:57 | Skrylar | i don't know what the actual term is but i call it shielding; its basically using opaque types |
| 20:39:05 | Demos | pimpl? |
| 20:39:14 | Demos | or forward declerations? |
| 20:39:22 | dom96 | filwit: ok, maybe I was a bit too harsh too. But that's what it feels like to me, and I know that it's subjective, I even said so in my post heh |
| 20:39:39 | Mat3 | Araq: Variadic records are the equivalence of unions, right ? |
| 20:39:39 | Skrylar | like if you have an OGRE class that requires 500 layers of STL/Boost crap, you just use a pointer to it (now the typedef is practically size_t instead of this complex 50mb worth of header definition) |
| 20:40:02 | Skrylar | Demos: alternatively, like some of the lower level C libs do, you calculate a header's size and then the header has a fake definition |
| 20:40:13 | Skrylar | struct thing { i_am_real_honest: byte[52] } |
| 20:40:32 | Skrylar | so basically your internals (and however complex of STL trickery you do) are NOT infecting the user |
| 20:40:33 | filwit | dom96: know that I really don't like C syntax. and personally I probably wouldn't even use {} (though i might for types bodies and stuff to distinguish) |
| 20:40:36 | Demos | right, you do need the actual header if you want to do much meaningful with the object |
| 20:40:49 | Araq | Mat3: no idea what you mean |
| 20:40:53 | Skrylar | how many C++ classes are you honestly tweaking the fields directly in, Demos? |
| 20:41:08 | filwit | dom96: but my attempt to remove symbols came very late (after Araq's post about "hate to say it, but if we just removed...") |
| 20:41:27 | Demos | not all that many, but I also don't want to have to forward declare all my methods. |
| 20:41:35 | filwit | dom96: i was always trying to get "type Foo: Bar = ..." before, but ran into a wall with that proposal |
| 20:41:40 | Skrylar | Demos: in C you already have to |
| 20:41:42 | Demos | and all this stuff is pretty impossible to do consistently on a large project |
| 20:41:48 | Araq | filwit: in fact there are lots of other options: |
| 20:41:50 | filwit | dom96: in fact if there's a good way to make that work and keep the ':' i would be all for it |
| 20:42:06 | Skrylar | Demos: none of this applies to nimrod because that uses modules; but for C/C++ you already have to write a header |
| 20:42:38 | Araq | * remove ':' for control flow and then it's only used for type annotations |
| 20:42:41 | Skrylar | what I do is use makeheaders, so i don't have to do that |
| 20:42:44 | filwit | dom96, Araq: but the main problem is that is inconsistent with if/else/etc and custom macros, the later of which is important for OOP-crowd adoption |
| 20:43:11 | Araq | * indentation mostly suffices anyway |
| 20:43:16 | Araq | foo bar |
| 20:43:20 | Araq | baz |
| 20:43:27 | Demos | right, but then you need to deal with hader dependencies and all that hell. And none of this matters if some asshole goes and includes all of boost in his header |
| 20:43:37 | Demos | that you then have to use because it is a library |
| 20:43:39 | filwit | Araq: yeah i thought of that before, but it breaks down with single lines right? |
| 20:44:01 | filwit | Araq: i also realized that, in my proposal, ':' and '=' are completely interchangable |
| 20:44:03 | Skrylar | Demos: its not that different from normal really; and as i mentioned, a lot of production C code already does exactly that |
| 20:44:23 | Mat3 | Araq: how are unions represented in Nimrod (it is some time I have tried) ? |
| 20:44:27 | Demos | and if you ever want to actually write tooling you are totally fucked because it is not clear what libraries even are. |
| 20:44:31 | Araq | filwit: for single lines we can just require people to use the {} delimiters |
| 20:44:38 | Skrylar | I guess I didn't explain it correctly -shrug- |
| 20:44:39 | Araq | or rather () |
| 20:44:51 | filwit | Araq: oh god you're right.. |
| 20:45:09 | Skrylar | Mat3: traditional unions don't exist, however there are pascal-style variants |
| 20:45:20 | * | Endy joined #nimrod |
| 20:45:25 | Demos | Skrylar, I agree that there are ways to make headers less of a problem, but they are all annoying and hard and have a high mental load |
| 20:45:26 | Araq | Skrylar: nope, you're not up to date :P |
| 20:45:30 | Mat3 | ok, and these are now translated to unions, I see |
| 20:45:36 | Skrylar | Araq: didy ou finally write that macro :P |
| 20:45:41 | Araq | type Foo = object {.union.} |
| 20:45:46 | Araq | a, b: int |
| 20:45:48 | Araq | produces |
| 20:45:57 | Araq | union { NI a; NI b; } |
| 20:45:58 | filwit | Araq: so ':' is used for types "var foo: int" / "proc foo: int" / "type Foo: Bar", etc, and never for if/else/macros etc |
| 20:46:05 | Mat3 | Araq: thanks |
| 20:46:06 | Araq | filwit: yeah |
| 20:46:13 | filwit | Araq: it's perfect |
| 20:46:31 | filwit | Araq: plus it automatically adds the {} brackets for the C crowd |
| 20:46:47 | Araq | filwit: no these still cause problems |
| 20:46:48 | Mat3 | get some sleep, ciao (by the way it would nice to read about syntactical changes somewhere on the web side) |
| 20:47:21 | Araq | because of set literals and the curly accessors a{i} |
| 20:47:30 | filwit | Araq: easy fixes |
| 20:47:36 | * | Mat3 quit (Quit: Verlassend) |
| 20:47:58 | filwit | Araq: plus we could make a old-syntax-to-new-syntax AST converter to convert the whole compiler and all the libs |
| 20:48:02 | Araq | filwit: sure but we already got (;) for {} |
| 20:48:25 | Araq | so I dunno if {} are necessary |
| 20:48:39 | filwit | Araq: i'm unaware of this, can you point to a docs or give an example? |
| 20:49:20 | filwit | Araq: i would still much prefer {} for advertising to the C crowd, but if (;) exists and is basically the same then wtf are we doing.. |
| 20:49:22 | filwit | :P |
| 20:49:42 | filwit | (besides trying to unify the type declaration and OOP macros of course) |
| 20:50:55 | EXetoC | {} for what? |
| 20:51:13 | Skrylar | I'm not sure how much the C crowd can be marketed to.. if you're still using C its because you're crazy or your boss told you to. lol |
| 20:51:23 | filwit | Araq: either way, I really like the idea of only using : for type stuff and making type decl work with it "type Foo: ref Bar = ..." and using {} (or something like it) for single lines and indent insensitive blocks |
| 20:52:04 | Skrylar | anyhow i don't mind the idea of the {} blocks, all though it does require the rest of the changes and i'm still bleh about the idea of removing : |
| 20:52:15 | Araq | just to be clear |
| 20:52:17 | Skrylar | time to descend in to madness (writing hashtable code) |
| 20:52:37 | Araq | nimrod will not get a new syntax anytime soon |
| 20:52:46 | filwit | ^ THIS |
| 20:52:49 | Araq | however the compiler supports |
| 20:52:49 | EXetoC | cmon |
| 20:52:50 | * | silven quit (Remote host closed the connection) |
| 20:52:56 | Araq | #! mysyntax |
| 20:53:07 | Araq | and then invokes an alternative parser |
| 20:53:13 | filwit | didn't know that... |
| 20:53:13 | EXetoC | what about that about delegation alternative syntaxes to editors? |
| 20:53:24 | Araq | so that's the way to play with it |
| 20:54:43 | Araq | filwit: check out compiler/syntaxes.nim |
| 20:55:00 | Araq | is supports 'braces' and 'endx' parsers but these have never been implemented |
| 20:56:08 | filwit | well that sounds like very good architecture, and a great way to experiment with something new without breaking things |
| 20:56:18 | filwit | good work on your designs, as usual |
| 20:57:32 | EXetoC | then it's up to the people who really care to deal with it |
| 20:57:52 | * | carum joined #nimrod |
| 21:00:24 | renesac | one liners needing {} is one of the ugly things I found in rust |
| 21:01:13 | renesac | like 'let a = if bla > d { 1 } else { d + 2 }' |
| 21:01:30 | renesac | hum, not that bad in this example |
| 21:01:47 | dom96 | 'let a = if bla > d 1 else d + 2' |
| 21:01:58 | dom96 | Yeah... if you remove ':' I will cry. |
| 21:02:02 | renesac | this is bad |
| 21:02:15 | renesac | why not just allow '=' for macros? |
| 21:02:32 | dom96 | Good question. |
| 21:02:33 | renesac | this way your OOP macros will be consistent |
| 21:02:51 | Skrylar | hm. |
| 21:02:58 | renesac | and no big change to the language needed, if it is indeed possible |
| 21:03:00 | Skrylar | Giving macros the ability to act as a kind of proc definition? |
| 21:03:03 | EXetoC | oh for single lines only? I don't like that either |
| 21:03:43 | renesac | Skrylar, yes, filwit has an OOP macro that does function definitions in his way |
| 21:04:11 | renesac | so one can have an implicit 'this' |
| 21:05:39 | * | flaviu joined #nimrod |
| 21:06:01 | renesac | of course, it is trade by an extra indentation level, so I'm not sure if the trade-off is worth it |
| 21:06:10 | renesac | *traded |
| 21:06:21 | Skrylar | well its a sign of a good language that he can be happy with it even if we don't use it |
| 21:09:26 | filwit | renesac: you don't need the extra indentation level ;) |
| 21:09:41 | filwit | "func Foo.bar(a:int) = this.a = a" |
| 21:10:02 | filwit | whoops, "func Foo.bar(a:int): this.a = a" |
| 21:10:17 | filwit | (see my concern with : vs =) |
| 21:10:51 | renesac | hum, interesting |
| 21:10:52 | Araq | ping Varriount |
| 21:11:19 | renesac | but I don't see much difference between this and |
| 21:12:10 | renesac | 'proc bar(x: Foo, a:int): a = a" <-- is this what it means? |
| 21:12:17 | renesac | I'm confused by the this.a at the end |
| 21:12:42 | EXetoC | ? |
| 21:13:20 | EXetoC | so much sugar. I don't care for it |
| 21:14:16 | * | Endy quit (Read error: Operation timed out) |
| 21:14:54 | filwit | renesac: how so? 'func' is a macro which injects "this:Foo" into the params of the resulting proc |
| 21:15:14 | renesac | this is the only thing it does? |
| 21:15:20 | EXetoC | renesac: I don't think it's worth the trade-off |
| 21:15:46 | renesac | EXetoC, what tradeoff? |
| 21:15:47 | filwit | renesac: for the 'func' macro, yes. the 'part' macro does much much more |
| 21:16:10 | renesac | the 'part' macro needs the 'func' macro to work? |
| 21:16:34 | renesac | or I can use normal procs putting 'x:Foo' into the params? |
| 21:16:50 | EXetoC | renesac: the additional indentation |
| 21:17:08 | filwit | renesac: no |
| 21:17:10 | Skrylar | why does researching hash algorithms make me feel like i'm writing stdlib code |
| 21:17:32 | filwit | renesac: i actually have two different concepts i'm experimenting with ATM |
| 21:17:40 | renesac | Skrylar, because the stdlib has a hash library? |
| 21:17:54 | Skrylar | renesac: i'm writing a different hasher |
| 21:18:18 | renesac | Skrylar, for hash tables or for streams? |
| 21:18:26 | Skrylar | for hash tables |
| 21:18:54 | Skrylar | some stuff (like glyph caches for text drawing) have different requirements for hash tabling |
| 21:19:12 | renesac | for hash tables you have FNV (simplest), MurmurHash3 (good for most purposes), another that I forget the name (cryptographic but relatively fast) |
| 21:19:24 | Skrylar | yeah FNV is a nice easy one |
| 21:19:33 | Demos | you also probably want to have an identity hash, just in case |
| 21:19:37 | fowl | woot |
| 21:19:40 | fowl | fallout new vegas |
| 21:21:36 | renesac | filwit, well, I find the nimrod OOP syntax nice and refreshing, making you rethink exactly what is an object |
| 21:22:06 | renesac | and as it is possible to add new procs/methods to an object anywhere, the 'class'/'part' block don't make as much sense |
| 21:22:09 | flaviu | renesac: I ran the dieharder tests on MurmurHash3, it passes most |
| 21:22:11 | renesac | in nimrod |
| 21:22:34 | renesac | flaviu, hum, interesting |
| 21:22:50 | filwit | renesac: yes it's good for some, but my main goal is attaching objects and there procedures to an editor. General purpose OOP macros will eventually be added to the standard-libs for the die-hard OOP fans later. |
| 21:22:57 | * | jbe joined #nimrod |
| 21:23:37 | renesac | die-hard fans of what? |
| 21:23:42 | Skrylar | the test harness better be called bruce |
| 21:23:45 | Skrylar | :P |
| 21:23:50 | renesac | because you already have OOP in nimrod |
| 21:24:14 | Demos | single dispatch c++ style OOP probably |
| 21:26:09 | renesac | his macro will not change nimrod single/multiple dispatch |
| 21:26:48 | * | nppdelfin joined #nimrod |
| 21:26:51 | EXetoC | are you sure? this is nimrod :> |
| 21:27:14 | renesac | I'm not sure |
| 21:27:15 | Araq | hi nppdelfin welcome |
| 21:27:49 | Araq | ping skyfex |
| 21:29:28 | renesac | Skrylar, FNV is good for short strings, if collision avoidance is not of utmost importance for you |
| 21:30:03 | Araq | renesac: what's good for short strings where collision avoidance is of utmost importance? |
| 21:30:10 | renesac | MMH3 is good for integers and other <= 8 bytes fixed size things, and for longer strings |
| 21:30:17 | Skrylar | Araq: FNV hash |
| 21:30:30 | renesac | Araq, MMH3 hash is better |
| 21:30:36 | Araq | short here means ~100 .. 300 chars |
| 21:30:43 | renesac | then MMH3 |
| 21:30:50 | renesac | by short I mean < 10 characters |
| 21:31:20 | Araq | right now I'm using MD5 ... |
| 21:31:38 | Skrylar | someone on stack overflow is saying "xxhash" is also a decent option |
| 21:31:46 | renesac | 100 ~ 300 I would already call medium size, and then the overhead of MMH3 is diluted, and it's multibyte working becomes faster |
| 21:31:54 | renesac | xxhash is good for medium to longer strings |
| 21:32:02 | renesac | it was designed for hashing long streams |
| 21:32:21 | renesac | I haven't tested it on short (<10 characters) strings though |
| 21:32:30 | renesac | but it seems like MMH3 |
| 21:32:40 | Skrylar | i'm making the algorithms pluggable anyway |
| 21:32:47 | Skrylar | yay generics |
| 21:32:59 | renesac | it is fast because it unrolls a loop working with multiple 64bit values at the same time |
| 21:33:22 | renesac | but it can't do this if the string is too short |
| 21:34:00 | Araq | well <10 chars are not really possible for what I have in mind |
| 21:34:09 | renesac | Araq, MD5 is overkill... |
| 21:34:23 | Skrylar | for the specific case i need right now, its 4-byte values |
| 21:34:23 | renesac | and MMH3 is not strong against attacks |
| 21:34:34 | renesac | if someone wants to make collisions, he can force it |
| 21:34:38 | renesac | easily |
| 21:35:36 | renesac | https://131002.net/siphash/ <-- this is the fast semi-cryptographic hash alternative I talked earlier |
| 21:35:45 | Skrylar | that reminds me of a system i thought about once where the time taken to process a user's request was tracked and if it went over a certain level it would get offended and boot them |
| 21:35:51 | renesac | it is not that much slower than MMH3 |
| 21:35:56 | Skrylar | i wondered about it because of griefers in game servers |
| 21:36:19 | renesac | and it (as far as people currently know) is strong against attacks forcing collisions |
| 21:36:26 | Araq | well but MD5 is in sthe stdlib :P |
| 21:36:37 | Skrylar | Araq: about to be a few more :/ |
| 21:36:44 | Araq | also attacks are not a problem |
| 21:36:50 | renesac | Araq, yeah, but siphash is much faster, especially for shorter strings |
| 21:37:10 | renesac | Implementations of SipHash are available in C, C#, Cryptol, D, Erlang, Go, Haskell, Java, Javascript, Lisp, Ruby, Rust, and PHP. |
| 21:37:16 | renesac | <-- we should add nimrod to that list |
| 21:37:22 | Skrylar | i might |
| 21:37:34 | Skrylar | i need to make a github for the skylight lib |
| 21:37:54 | renesac | Araq, if attacks are not a problem, MMH3 is faster still |
| 21:38:05 | Skrylar | also need to port the unicode database over and my NKFD/NFD stuff |
| 21:38:22 | Skrylar | i don't feel like it right now |
| 21:38:35 | renesac | I translated it to D once, not too complex |
| 21:38:43 | Araq | very well, will use it once its ready |
| 21:38:57 | Araq | for now md5 suffices, it's only a prototype anyway |
| 21:39:55 | Skrylar | i was going to port whirlpool to rust but that is some scary looking code |
| 21:40:15 | Skrylar | it has this huge sbox made of magic numbers everywhere |
| 21:40:24 | * | psquid quit (Ping timeout: 264 seconds) |
| 21:40:35 | renesac | heh, siphash is probably similar |
| 21:40:45 | * | renesac haven't looked at it yet |
| 21:41:12 | Skrylar | usually the magic numbers are pre-generated from a formula, i just don't understand the syntax they use to describe it |
| 21:41:49 | renesac | hum, it is quite simple actually |
| 21:42:25 | renesac | only a 7 cases switch and 4 big primes |
| 21:43:08 | renesac | as a finalizer |
| 21:43:20 | renesac | and the main loop is additions, xors and rotations |
| 21:44:02 | Skrylar | this is exactly the thing that i hate when people do: leave out test vectors |
| 21:44:09 | Skrylar | looked at the xxhash source and they don't have them |
| 21:48:08 | renesac | look at BMK_sanityCheck() on bench.c |
| 21:49:11 | * | carum quit () |
| 21:51:18 | * | psquid joined #nimrod |
| 21:52:21 | renesac | the RANDOM there makes me remember of xkcd's random dice |
| 21:52:28 | renesac | at least it is all caps |
| 21:52:32 | renesac | XD |
| 21:53:28 | * | psquid quit (Client Quit) |
| 21:53:50 | Skrylar | hrm. murmur uses case fallthrough |
| 21:53:55 | Skrylar | isn't that missing from nimrod? |
| 21:54:19 | flaviu | Skrylar: Try copying the scala implentation |
| 21:55:19 | Skrylar | it would be nice if we had the option to use fallthrough by using 'fall' or something; there are a few languages that offer it that way because of the times its used in low level optimization |
| 21:55:44 | Demos | c# allows fallthough if you have empty case labels |
| 21:55:55 | Demos | if any only if |
| 21:55:58 | Demos | *and |
| 21:56:13 | fowl | emit |
| 21:56:41 | flaviu | https://github.com/scala/scala/blob/5710c58b405e107ec29283d846acafd0cda13dcf/src/library/scala/util/hashing/MurmurHash3.scala#L15-L49 |
| 21:56:44 | Skrylar | fowl: emit what? we don't have gotos to fake it IIRC |
| 21:57:55 | Araq | Skrylar: not unreasonable but quite some work to implement |
| 21:58:05 | Araq | fowl: is talking about {.emit.} |
| 21:59:16 | Skrylar | possible easy solution: {.fall.} which just removes the implicit break |
| 21:59:46 | Skrylar | since you can block x: case meh {.fall.} of blah blah break x |
| 22:00:42 | Skrylar | that would make it possible to have duff devices |
| 22:01:00 | * | psquid joined #nimrod |
| 22:03:51 | flaviu | Isn't that the optimizer's job? |
| 22:04:39 | Araq | flaviu: C programmers always know better than the optimizer |
| 22:04:55 | Araq | well they *think* they know better |
| 22:06:17 | Skrylar | sufficiently smart compiler :P |
| 22:07:19 | renesac | Yann c aways benchmark before adding it's optimizations (though implicit fall through was probably too natural to benchmark :P) |
| 22:07:39 | renesac | but yeah, I've used this feature twice this week in C code |
| 22:08:15 | renesac | well, once nimrod sets would fill the gap |
| 22:08:21 | Demos | C programmers always know better than the compiler except for when it comes to data structures that are hard to implment in C |
| 22:08:25 | renesac | *in one of them |
| 22:08:29 | * | Demos rants about linked lists |
| 22:09:04 | flaviu | It seems like both clang and gcc can unroll loops |
| 22:09:48 | renesac | flaviu, but not necessarily they will unroll in the manner that makes most sense/is optimal |
| 22:10:04 | Skrylar | duffs aren't always straight loops either |
| 22:10:08 | Demos | renesac, one word: pragmas |
| 22:10:29 | renesac | well, maybe when you build it whith profiling, then it can test |
| 22:10:53 | renesac | Demos, we are discussing that there is no {.fall.} pragma |
| 22:10:55 | Skrylar | the musehash code uses a switch statement in one place as both an unrolled loop and length check |
| 22:11:12 | renesac | and {.unroll.} is unimplemented AFAIK |
| 22:11:28 | Varriount | Araq: Pong |
| 22:12:25 | Araq | .unroll is incredibly easy to fake with an iterator though |
| 22:12:29 | Araq | or with a template |
| 22:12:32 | renesac | Demos, yeah, I also generally hate linked lists |
| 22:12:49 | renesac | there are very few applications where they are indeed the best choice |
| 22:13:30 | Demos | I feel like they are used because in C they are easy to implement |
| 22:13:46 | renesac | yeah |
| 22:14:01 | Varriount | renesac: Wouldn't a linked list ussually be better as more of a chunked linked list, with say, each list chunk containing an array of elements rather than a single elements? |
| 22:14:03 | Araq | linked lists are essential for memory managers though |
| 22:14:09 | renesac | python programmers don't use them (instead, they append to the front of their lists :P) |
| 22:14:18 | Demos | also if compiles() is to be removed how are we to do autoconf style platform checks? |
| 22:14:33 | fowl | plz keep compiles() |
| 22:14:48 | Demos | Varriount, yes, often. And c++'s std::deque is usually implemented in just such a way |
| 22:15:03 | renesac | Varriount, http://stutzbachenterprises.com/blist/implementation.html |
| 22:15:10 | Araq | gah, compiles() will stay for 1.0 |
| 22:15:13 | renesac | this data structure is very interesting |
| 22:15:14 | Varriount | Demos: Well, once nimrod has macro cffi support, you could always have a macro start a nimrod subprocess to compile something... |
| 22:15:26 | Araq | after 1.0 is out I might replace it with something saner :P |
| 22:15:50 | Araq | Varriount: you can do that already |
| 22:15:55 | Araq | staticExec ftw |
| 22:16:09 | Demos | well in my case I need it to compile in a given context, I think I could replace it with a data structure that tracks just what I need at compile time though |
| 22:16:30 | Varriount | Araq: You wanted me for something? |
| 22:16:41 | Matthias247 | Demos: yeah, and in most places std::deque and std::vector are soo much faster than std::list :-) |
| 22:16:55 | Skrylar | will staticexec allow you to check for the existence of methods? |
| 22:16:55 | Demos | yeah lists are just bad |
| 22:17:13 | Skrylar | i was thinking about using compiles() earlier to see if a given type had its own hash function defined |
| 22:17:32 | Demos | Skrylar, the "correct" way to do that would be to use a typeclass |
| 22:17:46 | reactormonk | Araq, how again do you activate mixed? |
| 22:17:54 | Skrylar | 'typeclass' isn't in the manual :( |
| 22:18:02 | Skrylar | oh. spaces. |
| 22:18:05 | Varriount | reactormonk: 'mixed'? |
| 22:18:36 | Araq | Varriount: yeah, can you explain this: |
| 22:18:50 | Araq | Fail now |
| 22:18:52 | Araq | babel-core/C/x11 (reSuccess -> reInstallFailed) |
| 22:19:47 | Skrylar | ah the 'user defined type class' section still says TBD |
| 22:23:01 | Demos | Skrylar, look in the devel docs |
| 22:24:02 | Varriount | Araq: Let me check. It might have occurred when I was developing something else. |
| 22:24:31 | renesac | [19:14:03] <Araq> linked lists are essential for memory managers though <-- IIRC jemalloc uses parent-less RB trees |
| 22:25:37 | Skrylar | bubble sort all the things |
| 22:26:20 | Araq | renesac: linked lists are *natural* when you split up by allocated sizes |
| 22:27:25 | renesac | right, I never implemented a memory manager, but I have quite a bit of prejudice agains linked lists, and love dynamic vectors |
| 22:27:28 | renesac | ^^" |
| 22:28:47 | Varriount | This may be my niavety talking, but wouldn't dynamic arrays/vectors have progressively worse times when resizing? |
| 22:29:01 | Varriount | Since memory has to be reallocated and copied? |
| 22:29:04 | Skrylar | Varriount: amortized |
| 22:29:07 | flaviu | Varriount, yes but there are clever tricks |
| 22:29:11 | renesac | Varriount, but you resize in progressively larger chunks |
| 22:29:19 | Skrylar | i assume he means storing the headers in the dynamic buffer |
| 22:29:24 | flaviu | I personally like bitmapped vector tries |
| 22:29:51 | flaviu | log_n performance, were n is the size of each subvector thing |
| 22:30:15 | renesac | and I'm not sure if after 4kb you can't just ask for the kernel a new page to append to your vector (or I'm dreaming here?) |
| 22:31:39 | Araq | in fact when you keep doubling the capacity the overhead is factor 3 amortized for "add" |
| 22:31:52 | Araq | but I forget how the proof works |
| 22:31:56 | Araq | *forgot |
| 22:32:37 | renesac | Varriount, and if pauses are a concern (soft real time) you can alloc a new vector but only copy a bit of the old vector each new insertion |
| 22:33:15 | Varriount | renesac: Yeah, I'm just raising theoretical questions. |
| 22:33:21 | renesac | then you are amortizing the operation explicitly |
| 22:33:48 | Araq | renesac: that complicates the lookup slightly though |
| 22:33:57 | Varriount | Of course, after a certain point, if you're storing hundreds of thousands of items, you should probably ask yourself if a custom data structure is needed... |
| 22:34:21 | renesac | Araq, yeah, and uses more memory, and is slower to copy bit by bit than all at once |
| 22:34:26 | * | filwit quit (Quit: Leaving) |
| 22:34:31 | renesac | but probably still better than a linked list |
| 22:34:38 | renesac | :P |
| 22:35:28 | Araq | dunno, linked lists are not that bad on x86 with its crazy prefetching logic |
| 22:35:54 | Araq | we had a benchmark recently |
| 22:36:13 | Araq | made all the points ref tuple[x,y,z] instead of tuple[x,y,z] |
| 22:36:24 | Araq | performance was not affected ;-) |
| 22:36:52 | flaviu | Araq: Do you have a gist for it? |
| 22:37:11 | renesac | depends on how the memory allocator packs all that allocations together too |
| 22:37:23 | Araq | flaviu: dom96 knows the details |
| 22:37:36 | renesac | and if you need anything like random access, linked lists are out |
| 22:37:50 | Demos | an x86 will only prefetch if you have a more or less constant stride though...right |
| 22:37:54 | renesac | Araq, it was the ParticleBench? |
| 22:38:05 | Araq | the opengl bench |
| 22:38:13 | dom96 | Yeah, that was it |
| 22:38:40 | renesac | and not really a linked list, more like a vector of pointers |
| 22:39:00 | renesac | or you have tried a linked list? |
| 22:39:36 | Araq | it was a vector of pointers, that is right |
| 22:39:53 | Araq | but I can't see how a linked list does much worse |
| 22:40:01 | Araq | the indirection is the same |
| 22:40:32 | Demos | it probably really depends on how stuff is layed out in memory, the prefetcher is likely to get tripped up once you start adding and removing stuff from the middle of the list |
| 22:40:47 | Araq | yeah a good point |
| 22:41:04 | Araq | the linked list is fast as long as you don't edit it |
| 22:41:05 | Demos | this is the one part of the optimization manual I actually read :D |
| 22:41:10 | renesac | Demos, a vector don't like random insertions an deletions too |
| 22:41:29 | renesac | I would say it also depends on what other allocations you make while building your list |
| 22:41:31 | Demos | renesac, right, but with a vector they will not change the fact that memory is contigous |
| 22:42:11 | renesac | yeah |
| 22:42:22 | renesac | that is why array hash tables are much faster than chained hash tables |
| 22:42:45 | renesac | because the linked list nodes are all around the memory, not contiguous |
| 22:42:51 | Demos | pretty mcuh |
| 22:42:52 | renesac | like in the array hash table |
| 22:43:07 | Varriount | Hm. Could you have some sort of bitfield to mark areas of a vector that are empty, for o(1) deletion? |
| 22:43:16 | Demos | hash tables are going to destroy your prefetcher no matter what |
| 22:43:29 | renesac | Demos, not really |
| 22:43:33 | renesac | quadratic probing for the win |
| 22:43:33 | Demos | Varriount, yes. boost calls it a sparse vector |
| 22:44:03 | renesac | or even linear probing, or a mixture of both like cbloom did |
| 22:44:04 | Demos | renesac, right but like you are accessing more or less random locations |
| 22:44:13 | Demos | because that is what a hash does |
| 22:44:16 | renesac | yes, the first jump is random |
| 22:44:23 | renesac | the others need not to be |
| 22:44:49 | Demos | true, but they are unlikely to be constant. And each jump you are only using a little bit of the cache line |
| 22:44:52 | renesac | an chained hash table or array hash table has at least two random jumps |
| 22:45:01 | renesac | an open adressing hash table can have only one |
| 22:45:04 | Demos | unlike in a vector where you are likely to go throguh the whole cache line |
| 22:46:48 | renesac | well, if you are searching for random things, and you have a large number of it, you have to hit random places of memory anyway |
| 22:47:01 | Demos | yeah ofc |
| 22:47:07 | renesac | if you are seaching in order, you should have stored in an ordered data structure |
| 22:47:24 | renesac | like a b+tree |
| 22:47:40 | Demos | or an ordered vector |
| 22:47:47 | renesac | yeah |
| 22:48:01 | renesac | if you aren't inserting or deleting things |
| 22:48:20 | Demos | I think boost has something like boost:flat_map that is a std::vector<std::pair<const key, value>> that it just bsearches through |
| 22:53:33 | * | ddl_smurf joined #nimrod |
| 22:58:43 | renesac | Varriount, you have sparse tables implemented this way, but you need to consult the bitfield for each array indexing operation, so it isn't perfect |
| 22:59:52 | renesac | sparse tables are a bit more than you asked though |
| 23:00:14 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 23:00:38 | renesac | yeah, I think I never saw anything like that... |
| 23:01:16 | renesac | usually you use an invalid value for some field of your vector elements to mark it |
| 23:01:37 | renesac | as deleted |
| 23:03:13 | * | nppdelfin quit (Ping timeout: 240 seconds) |
| 23:05:11 | * | ddl_smurf joined #nimrod |
| 23:11:29 | Varriount | renesac: But the drawback of directly using an invalid value is that you can't use the invalid value for anything else. |
| 23:11:50 | * | io2 quit (Remote host closed the connection) |
| 23:12:59 | Demos | the bigger (and related) drawback is that it is hard to generealize |
| 23:13:02 | * | io2 joined #nimrod |
| 23:13:28 | * | BitPuffin quit (Ping timeout: 265 seconds) |
| 23:13:58 | renesac | ^ |
| 23:14:23 | Varriount | Sigh.. In a perfect world, there would be some mythical data structure with O(1) read and write properties. |
| 23:14:41 | renesac | that is sorted and with no overhead |
| 23:15:16 | renesac | because hash tables already have O(1) rw |
| 23:15:28 | renesac | (amortized) |
| 23:15:39 | renesac | (on average) |
| 23:15:59 | Skrylar | Huh. Well thats a neat idea. I just thought about how you could abuse yEd to be a GUI editor. At least when you can't get a real one |
| 23:16:27 | * | Skrylar scribbles and returns to hash algorithm hell |
| 23:16:52 | Varriount | Skrylar: Hahll? |
| 23:17:07 | renesac | hash algorithms are fun |
| 23:17:26 | renesac | I would be messing with it if I had not other things to do |
| 23:18:24 | Skrylar | renesac: i'm just aggravated because there are things i want to do, and there is this infinite pile of dependencies |
| 23:19:00 | Skrylar | which means stopping, diagramming it out, making sure its all properly coded |
| 23:19:15 | Skrylar | anyhow, interruption over |
| 23:19:16 | renesac | right |
| 23:24:31 | Demos | well Skrylar make sure to put whatever you are doing on babel |
| 23:25:08 | Skrylar | that sounds like a thing i don't know how to use |
| 23:25:24 | Skrylar | i shoved the unicode stuff on github at least |
| 23:26:48 | * | jbe quit (Quit: Leaving) |
| 23:27:02 | * | filwit joined #nimrod |
| 23:27:33 | filwit | hey renesac: just rescanned the logs and noticed some questions you asked that I missed before |
| 23:28:51 | filwit | renesac: yes, my 'part' macro will handle both nimrod 'proc' and custom 'func'. In fact, 'func'/'init' mostly exist specifically to be outside of 'part' (to emulate the same behavior for any type) |
| 23:30:40 | filwit | renesac: the general-purpose OOP macros which will be eventually part of the standard libs will probably not really effect how the OOP is handled in Nimrod (although, this IS possible because OOP just means "combine objects + virtual table"), it's more about saving typing when you're using OOP designs |
| 23:32:28 | filwit | renesac: keep in mind that there's only general plans for these general purpose OOP libs. There are a few candidates (i'm working on one of them), but ultimately which macros are included in the stdlib are to-be-determined by Araq |
| 23:34:08 | filwit | renesac: so the specific behavior and syntax of the stdlibs OOP macros is still largely open to discussion, last i heard. Mostly it's just about the first person who makes a decent well-rounded version of them and convinces boss-man to accept the PR :P |
| 23:35:32 | renesac | right, I will take a better look once it is completed |
| 23:35:47 | renesac | the screenshot didn't look bad though |
| 23:36:21 | Araq | yeah but the boss-man is constantly learning new tricks and now wants compile time function pointer table generation |
| 23:36:33 | Skrylar | well a vtable isn't necessary for OOP.. its just a practice of thinking in terms of objects instead of procedures </pedantic> |
| 23:37:02 | Araq | and then we could even ditch multi methods and simplify the language |
| 23:37:25 | fowl | compile time functino pointer table - for multi dispatch? |
| 23:37:33 | Araq | yes |
| 23:38:21 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 23:39:10 | fowl | kewl |
| 23:40:48 | * | xenagi joined #nimrod |
| 23:42:04 | Skrylar | poor openoffice.. i think its been like 6 months since i actually had to use writer for something outside of curiosity oO |
| 23:42:18 | Kelet | dom96: Is Aporia v0.1.1.0 recommended for release version of Nimrod? I'm getting an error on set_upper on ~master of Aporia |
| 23:44:44 | filwit | Kelet: probably need to compile with devel |
| 23:50:32 | fowl | Kelet, nimrod 0.9.2 isnt recommended |
| 23:51:11 | Araq | fowl: can you please report now what doesn't compile anymore with devel? |
| 23:51:59 | fowl | yes, ill check it out |
| 23:52:15 | fowl | oh i remember this was a problem: importc: "sf_$1" isnt supported |
| 23:52:46 | Araq | that's gradha's bug lol |
| 23:52:56 | Araq | I told him it's a bad idea |
| 23:53:33 | Araq | let me see |
| 23:55:15 | renesac | another question I asked was: just allowing '=' would solve the problem for your macros |
| 23:55:22 | renesac | filwit, |
| 23:55:48 | renesac | Araq, one can't nest (;), so it isn't currently really an option |
| 23:55:56 | Araq | allowing '=' seem problematic for the current grammar and doesn't solve much |
| 23:56:30 | renesac | well, it would make proc defining macros look native |
| 23:56:46 | renesac | but yeah, I made this suggestion only if it was easy to do with the current grammar |
| 23:58:29 | flaviu | Is getting a type error on foo != nil a feature? |
| 23:58:32 | renesac | another option I thought would let declare procs as 'proc name(params) type {.pragmas.}: body' |
| 23:58:42 | renesac | (notice the lack of ':' between params and type |
| 23:58:56 | renesac | ), but it would be adding special cases to the grammar... |
| 23:58:58 | filwit | renesac: thanks for the input. Though I considered that and discarded it because it's not consistent with if/else/etc like : is. Ultimately this discussion has come to a close. I'll be making a experimental parser (complete with Kate color coding) to try out these ideas and find any flaws. Once that's done, we can argue about the specifics in a more concrete way, and if it turns out to be a much more popular syntax overall perhaps it will eventually replace th |
| 23:58:58 | filwit | e existing on after it passes enough scrutiny. |
| 23:59:36 | renesac | if, else, etc aren't assigning to any variable |
| 23:59:59 | renesac | var, proc, type are (given a broad definition of variable) |
