| 00:07:19 | BitPuffin | so much code ©_© |
| 00:08:53 | EXetoC | where? |
| 00:09:13 | BitPuffin | EXetoC: in the compiler :P |
| 00:10:11 | EXetoC | let's reduce it to 10k lines |
| 00:10:40 | BitPuffin | EXetoC: it should be like lisp where you can write an interpreter in just a few lines :P |
| 00:13:56 | dom96 | 'night |
| 00:14:18 | BitPuffin | sleep well dom96 |
| 00:14:50 | Araq | good night |
| 00:15:46 | * | freezerburnv quit (Quit: freezerburnv) |
| 00:33:49 | reactormonk | BitPuffin, lisp is already an interpreter ;-) |
| 00:37:45 | BitPuffin | reactormonk: not always :P |
| 00:46:56 | shevy | isn't lisp more of an ((ill(ness? |
| 00:48:24 | BitPuffin | not sure if Araq went to bed or said goodnight to dom96 |
| 00:49:49 | EXetoC | or both |
| 00:49:52 | shevy | both! |
| 00:52:04 | BitPuffin | lol, am I sucky for reading about 450 LOC/h |
| 00:54:34 | MFlamer | nimrod loc's are pretty terse |
| 00:55:17 | BitPuffin | yeah |
| 00:55:24 | BitPuffin | and I guess I'm tired + distracted |
| 00:55:29 | BitPuffin | now I'm skimming |
| 00:55:52 | shevy | I noticed that my brain is bad at reading code |
| 00:55:59 | shevy | it is much better when it writes or rewrites code |
| 00:56:16 | BitPuffin | same here |
| 00:56:23 | * | freezerburnv joined #nimrod |
| 01:00:42 | shevy | BitPuffin what programming languages have you been using the last 10 years for a longer while? |
| 01:01:20 | BitPuffin | shevy: I haven't been a programmer for 10 years unfortunately |
| 01:01:22 | EXetoC | VB at the age of 9? |
| 01:01:49 | BitPuffin | although I do wish I started coding at 9 rather than at like late 15 |
| 01:01:58 | BitPuffin | although I did try |
| 01:02:12 | BitPuffin | but then I tried with C++ which isn't the best starter language really |
| 01:02:21 | EXetoC | that's not very late |
| 01:02:44 | EXetoC | same. programming in school blows |
| 01:02:55 | shevy | BitPuffin I started late too, but I am not a programmer either. I only use the computer to help me solve tasks |
| 01:03:15 | BitPuffin | EXetoC: well effectively you could say I started at 16, as it was really like a month or two from me turning 16 that i started HS |
| 01:03:20 | BitPuffin | which taught me Java |
| 01:03:22 | BitPuffin | well |
| 01:03:29 | BitPuffin | got me started learning the basics |
| 01:03:53 | BitPuffin | then I basically learned more than the entire 3 years of school would try to teach me in a very short time |
| 01:04:21 | BitPuffin | and got in to other languages. Ruby, C++, C, D |
| 01:04:40 | BitPuffin | then a short period starting to learn Rust but then EXetoC converted me to Nimrod |
| 01:04:42 | BitPuffin | :p |
| 01:05:03 | BitPuffin | ofc there has been a bit of javascript etc in between |
| 01:05:32 | freezerburnv | BitPuffin: Why nimrod over rust, out of curiosity? Do you think nimrod is a better language, or is rust just in too much flux? |
| 01:07:05 | BitPuffin | freezerburnv: Well really the main reason I didn't stick with Rust was that it was really in too much flux like you said. |
| 01:07:45 | BitPuffin | freezerburnv: But I think nimrod is probably a better language. Since Rust is kind of complex |
| 01:07:56 | BitPuffin | and as far as I know nimrod is way more programmable |
| 01:08:00 | BitPuffin | and the GC is win |
| 01:08:21 | BitPuffin | not to mention a nice readable syntax :) |
| 01:08:53 | shevy | BitPuffin I am still with ruby |
| 01:09:13 | shevy | always when I want to learn python, it bores me to no ends, so I end up wanting to learn nimrod instead |
| 01:09:24 | freezerburnv | What do you mean by "more programmable"? And I suppose those other things are good points as well. I'm not sure where I fall yet. I'm personally still really excited about Rust, but nimrod is scratching the itch that I really wanted rust to fill up to this point |
| 01:09:31 | freezerburnv | Ugh, python |
| 01:09:36 | freezerburnv | Also: ugh, ruby |
| 01:09:47 | shevy | freezerburnv you use shell scripts? |
| 01:09:57 | freezerburnv | Python is great for scripts and being super productive in small ways. Don't use it for anything big |
| 01:10:04 | BitPuffin | freezerburnv: what I mean by programmable is the macros |
| 01:10:15 | freezerburnv | shevy: Heck no, worst "language" in existence that should die in a fire |
| 01:10:26 | BitPuffin | I like both python and ruby |
| 01:10:28 | shevy | \o/ |
| 01:10:31 | BitPuffin | but I don't have much use for them |
| 01:10:43 | shevy | BitPuffin why not? are there no tasks you want to solve programmatically? |
| 01:11:15 | BitPuffin | shevy: of course there is. But usually I don't need to do that with those languages |
| 01:11:25 | BitPuffin | and most of my time spent coding is doing game dev |
| 01:11:35 | shevy | I have literally several thousand ruby scripts. stuff like "merge_pdf *pdf" which is nothing more than calling ghostscript to merge .pdf, but ruby does the specific syntax. same with many other things... concat video files via ffmpeg, through ruby scripts... using mplayer in different modes but using ruby scripts to set the various tidbits... etc... |
| 01:11:36 | BitPuffin | which is not really an area where they excel |
| 01:11:46 | shevy | ah |
| 01:11:47 | freezerburnv | They're both fantastic languages. But only for small things. I work at a company that uses python as our main language, and it's the worst. What the heck is "self.client"? I don't know. There are like, 20 options. What about client.move? No idea which one that is without following the control flow from beginning to end |
| 01:11:48 | shevy | game dev |
| 01:11:49 | freezerburnv | Blergh |
| 01:11:51 | shevy | that drains a lot of time |
| 01:11:55 | shevy | enjoy it while you are young! |
| 01:12:22 | freezerburnv | BitPuffin: So jealous! I want to do gamedev, but I have so little time right now :( |
| 01:12:22 | BitPuffin | shevy: yeah that kind of stuff is really nice with ruby |
| 01:12:24 | BitPuffin | will do |
| 01:12:35 | shevy | ruby is too slow for cool games |
| 01:12:39 | BitPuffin | freezerburnv: too much work that drains your energy? |
| 01:12:42 | BitPuffin | shevy: exactly |
| 01:12:58 | shevy | a warcraft 3 like game in ruby with multiplayer... now that would be something |
| 01:13:12 | BitPuffin | well |
| 01:13:29 | BitPuffin | not entirely impossible in ruby I guess |
| 01:13:36 | BitPuffin | If that's the complexity level |
| 01:13:37 | freezerburnv | BitPuffin: Work drains my mental energy, definitely. But I just got married like a month ago, so we've been adjusting, and I'm doing a coursera course, trying to hang out with friends, be involved in my church, and possibly, MAYBE try to do Nanowrimo |
| 01:13:39 | freezerburnv | Slightly busy :) |
| 01:13:51 | BitPuffin | since the rendering is done in opengl on the hardware anyways |
| 01:14:00 | BitPuffin | maybe it could handle some basic logic stuff |
| 01:14:01 | shevy | I dunno |
| 01:14:05 | shevy | it always seems immensely slow |
| 01:14:06 | freezerburnv | BitPuffin: You'd need to write some tight loops in C, probably |
| 01:14:30 | freezerburnv | shevy: Civ 4 used python, and Ruby and Python are pretty close in performance these days |
| 01:14:33 | shevy | I cant even write a replacement for bash in ruby because file listing takes too long once you have like ~5000 files to display in some milliseconds |
| 01:14:39 | BitPuffin | freezerburnv: ah, well maybe as things calm down you can pick a fun game project to work on! |
| 01:14:54 | shevy | yeah for what, like some UI elements perhaps |
| 01:15:11 | BitPuffin | well, time to walk the dog and sleep |
| 01:15:15 | BitPuffin | goodnight guys! |
| 01:15:16 | shevy | I want one language to rule them all |
| 01:15:19 | shevy | cya BitPuffin |
| 01:15:30 | freezerburnv | BitPuffin: Trust me, I will. I already have an idea to work on. In the meantime, I'm trying to learn Nimrod so that hopefully I can make it in nimrod. Java/Scala are the only other languages I might consider because I dislike so many languages, or they have such severe limitations |
| 01:15:32 | freezerburnv | Night BitPuffin ! |
| 01:16:20 | BitPuffin | freezerburnv: cool! I wouldn't go with Java, it's not a great experience I think. I mean it is not the worst but I think nimrod is more fun :P |
| 01:16:22 | BitPuffin | night! |
| 01:17:19 | shevy | java |
| 01:17:27 | freezerburnv | Java? |
| 01:17:34 | shevy | ewwwwww |
| 01:17:49 | freezerburnv | I'm the like, one weird person on this planet who likes Java |
| 01:18:06 | freezerburnv | It's very clear and has a lot of great libraries, and can interact with Scala and Clojure excellently |
| 01:18:11 | freezerburnv | Also the JVM is great |
| 01:18:22 | freezerburnv | Plus lambdas in Java 8 are great |
| 01:18:26 | EXetoC | it's so verbose |
| 01:18:48 | freezerburnv | So's Objective-C, and yet tons of people use that. Objc, in my opinion, is actually even worse :( |
| 01:19:18 | freezerburnv | Verbose isn't always a bad thing, and you can always just use Scala |
| 01:19:46 | fowl | ewwwwwwwwwwwwwwwwwwwww java |
| 01:19:51 | freezerburnv | lol |
| 01:19:53 | shevy | I liked ObjC more than java |
| 01:20:04 | shevy | but it's tedious as well |
| 01:20:05 | freezerburnv | shevy: Why so? |
| 01:20:13 | fowl | id rather flick myself in the nads than touch the java |
| 01:20:21 | shevy | freezerburnv dunno, the way how it handled objects and messages seemed a lot more intuitive to me than the java way |
| 01:20:32 | freezerburnv | My current job is to write the iOS UI for my company, and I really despise the APIs I have to use |
| 01:20:41 | shevy | it felt like "smalltalk in C" |
| 01:20:50 | freezerburnv | Because [someNSArray objectAtIndex:i] is super intuitive |
| 01:20:58 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 01:21:11 | shevy | save for the camelCase yes |
| 01:21:15 | * | ponce__ is now known as ponce |
| 01:21:18 | freezerburnv | Or [someNSString compenentSeperatedBy:@"foo"] to split a string. Great times |
| 01:21:31 | fowl | lol |
| 01:21:44 | * | webskipper joined #nimrod |
| 01:21:46 | fowl | i just think its stupid how things dont stack well |
| 01:21:49 | EXetoC | lolwut >.> |
| 01:21:52 | webskipper | hi |
| 01:22:01 | webskipper | i have a question about let and constant |
| 01:22:13 | freezerburnv | fowl: How do you mean? |
| 01:22:17 | webskipper | thats not clear for - for what cases i need let - for what cases i need constant ? |
| 01:22:33 | fowl | [somestring splitBy: ","] #now i want to join this on something else so i have to go back to the beginning of the line and add a [ then back to the end and add joinBy: ". "] |
| 01:22:43 | fowl | hypothetical obv^ |
| 01:22:47 | EXetoC | webskipper: a const statement is evaluated at compile-time |
| 01:22:57 | fowl | [[somestring splitOn: ","] joinOn: "."] |
| 01:23:02 | fowl | oh yeah and ; still needed |
| 01:23:16 | freezerburnv | fowl: Use any IDE for ObjC ever and you can just type a ] after the closing ], and it should automatically put an opening [ at the beginning |
| 01:23:26 | EXetoC | so it's not like const in C++ for example, where it is a little like let in nimrod |
| 01:23:36 | fowl | fie on your IDEs |
| 01:23:41 | freezerburnv | fowl: lol |
| 01:23:45 | webskipper | For what I need let ? Because I can't change let vars ? |
| 01:24:15 | fowl | use let if you dont need it to be mutable |
| 01:24:18 | freezerburnv | fowl: IDEs are great. Especially AppCode. Find usages, jump to definition, refactor name, autocomplete. It's great |
| 01:24:33 | fowl | you can easily back up three chars and change it to var if you need to later |
| 01:24:57 | fowl | freezerburnv, one side of screen text editor, the other side browser with docs/youtube |
| 01:25:42 | freezerburnv | fowl: I suppose that's fair enough. But I would spend way too much time trying to navigate code versus using an IDE to do so with a VIM plugin. Best of both worlds, really |
| 01:26:23 | webskipper | fowl: but a constant is not mutable too ? Sorry that I ask but I am not familiar with c++ let |
| 01:26:25 | fowl | bye everyone. i have to go buy deodorant because i stink then i have to drunk so i stink drunk |
| 01:26:34 | fowl | webskipper, nimrod's const is more like #define |
| 01:26:40 | freezerburnv | fowl: See ya! Have fun and stuff |
| 01:26:42 | EXetoC | yeah VIM is a capable IDE in many cases |
| 01:27:29 | freezerburnv | In my experience: sorta? |
| 01:27:53 | * | fowl quit (Quit: Leaving) |
| 01:28:27 | webskipper | fowl: yeah but in practise do I need not mutable vars like let ? #define / const should be fine for me (and I guess its more efficient)? |
| 01:28:28 | freezerburnv | The only thing I like about VIM are the home row motions and whatnot. As long as I have those in whatever text editor I'm using, I don't personally care. I'd rather use an IDE that understands my code than a text editor which someone has tried to make understand my code in a way that (at least usually) only 3/4 works |
| 01:29:01 | freezerburnv | Also usually runs slower than an IDE that understand the code, especially if the IDE can use multiple threads whereas vim script cannot |
| 01:29:13 | * | DAddYE quit (Remote host closed the connection) |
| 01:29:47 | * | DAddYE joined #nimrod |
| 01:30:02 | freezerburnv | EXetoC: If you like VIM, not gonna hate on that :) My preference to use an IDE, yours to use VIM |
| 01:30:14 | EXetoC | webskipper: no, compile-time means during compilation. before the program has ever run in other words |
| 01:30:20 | webskipper | flow: in docs I see the example let input = readline(stdin) - is it more efficient than var input = readline(stdin) ? |
| 01:30:43 | EXetoC | so yes that means the CPU might not spend as much time when actually running the program, as a result |
| 01:30:47 | shevy | who is flow ;) |
| 01:30:54 | * | Demos joined #nimrod |
| 01:31:43 | webskipper | EXetoC - I know what u mean but for what I need let in practise than ? |
| 01:32:18 | webskipper | practice |
| 01:33:34 | webskipper | Does it need less memory ? |
| 01:33:39 | webskipper | than a var ? |
| 01:34:11 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 01:34:40 | * | silven quit (Quit: No Ping reply in 180 seconds.) |
| 01:39:20 | * | silven joined #nimrod |
| 01:40:25 | MFlamer | if the compiler knows you are never going to change the value of a variable (let) it can perform certain optimizations not possible otherwise |
| 01:44:08 | webskipper | MFlamer: ok, now its clear. ty. |
| 01:47:06 | EXetoC | const X = stdin.readChar() |
| 01:48:58 | webskipper | ah, nimrod has named arguments. I like that. |
| 01:49:04 | EXetoC | try that and see what happens. the compiler doesn't know what key the user will press, and therefore it's not a constant expression. in other words, it's something that should be evaluated when the program is running, so you need to assign it to a variable (var/let) |
| 01:49:32 | webskipper | and default values |
| 01:49:38 | EXetoC | the upcoming VM will allow pretty much anything to be evaluated at compile-time though, but sometimes it might not make much sense |
| 01:51:00 | webskipper | EXetoC: there is an upcoming VM ? |
| 01:51:39 | EXetoC | yes, for improved compile-time execution, and possibly for other reasons as well |
| 01:54:07 | EXetoC | I think it was used for running SDL (graphics) code during compilation at one point |
| 01:54:14 | EXetoC | just as a test of course |
| 01:55:37 | Demos | why is the compiler not able to load a dll and just execute some C? |
| 01:55:52 | Demos | actually that sounds like a really bad idea |
| 01:55:55 | Demos | ...never mind.... |
| 01:56:21 | EXetoC | that's what I implied |
| 01:56:43 | EXetoC | because you need to load the SDL lib in that case |
| 01:57:17 | webskipper | damn eclipse uses tabs instead of spaces in my "tests.nim" file |
| 01:57:31 | EXetoC | aka CTFE in D jargon, except more awesome |
| 02:01:48 | EXetoC | https://gist.github.com/EXetoC/73129b32b5d3de07ac45 |
| 02:02:00 | EXetoC | I don't know if you got all that, but running those examples might help |
| 02:02:50 | EXetoC | two of them anyway. the second one doesn't compile because 'let' implies that it's a variable |
| 02:09:08 | * | MFlamer quit (Ping timeout: 240 seconds) |
| 02:11:50 | webskipper | ok ty. |
| 02:15:05 | EXetoC | static also means at compile time, but it serves a different purpose. in other words, that loop and echo won't be executed when you run the program |
| 02:15:40 | EXetoC | my explanations suck more than usual. I think it's time to sleep. happy coding :> |
| 02:15:44 | Demos | think of it like using a template language or something in your build system |
| 02:18:50 | * | freezerburnv quit (Quit: freezerburnv) |
| 02:27:54 | * | ics joined #nimrod |
| 02:42:06 | * | xenagi joined #nimrod |
| 02:55:57 | * | brson quit (Quit: leaving) |
| 02:58:24 | * | mflamer joined #nimrod |
| 03:15:34 | Varriount | Meep |
| 03:15:54 | * | Varriount is back from two days of nausea and throwing-up |
| 03:19:59 | * | webskipper quit (Ping timeout: 272 seconds) |
| 03:20:54 | * | webskipper joined #nimrod |
| 03:23:27 | * | dyu_ joined #nimrod |
| 03:25:40 | xenagi | Varriount, crazy party brah |
| 03:30:59 | * | DAddYE joined #nimrod |
| 03:37:59 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 03:38:28 | * | ics quit (Quit: Textual IRC Client: www.textualapp.com) |
| 03:40:53 | * | mflamer quit (Ping timeout: 272 seconds) |
| 03:45:10 | * | webskipper quit (Ping timeout: 246 seconds) |
| 03:45:56 | Demos | ugh that feeling in c when you are like "c++ OOP is dumb, I just want /data/" |
| 03:45:59 | Demos | erm c++ |
| 03:49:11 | * | Demos quit (Quit: Textual IRC Client: www.textualapp.com) |
| 03:51:26 | * | webskipper joined #nimrod |
| 03:53:34 | * | mflamer joined #nimrod |
| 04:16:44 | * | OrionPK quit (Quit: Leaving) |
| 04:29:08 | * | shodan45 joined #nimrod |
| 04:34:27 | * | DAddYE joined #nimrod |
| 04:36:08 | * | mflamer quit (Remote host closed the connection) |
| 04:38:19 | * | xybre left #nimrod ("WeeChat 0.3.8") |
| 04:38:56 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 04:40:04 | * | webskipper quit (Ping timeout: 264 seconds) |
| 04:41:10 | * | ics joined #nimrod |
| 04:43:52 | * | ics quit (Client Quit) |
| 04:59:33 | * | hoverbear joined #nimrod |
| 05:15:50 | * | Boscop quit (Ping timeout: 268 seconds) |
| 05:18:29 | * | Boscop joined #nimrod |
| 05:18:30 | * | Boscop quit (Changing host) |
| 05:18:30 | * | Boscop joined #nimrod |
| 05:21:21 | * | xenagi quit (Quit: Leaving) |
| 05:35:16 | * | DAddYE joined #nimrod |
| 05:39:46 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 05:48:00 | * | ponce is now known as Guest49263 |
| 05:48:00 | * | Guest49263 quit (Killed (sendak.freenode.net (Nickname regained by services))) |
| 05:48:12 | * | p0nce joined #nimrod |
| 06:01:22 | * | hoverbear quit (Quit: Textual IRC Client: www.textualapp.com) |
| 06:33:11 | * | ics joined #nimrod |
| 06:36:36 | * | DAddYE joined #nimrod |
| 06:41:02 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 06:57:38 | * | Associat0r joined #nimrod |
| 06:57:39 | * | Associat0r quit (Changing host) |
| 06:57:39 | * | Associat0r joined #nimrod |
| 07:37:25 | * | DAddYE joined #nimrod |
| 07:40:24 | * | Ywo joined #nimrod |
| 07:42:14 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 08:38:02 | * | DAddYE joined #nimrod |
| 08:43:59 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 09:40:02 | * | DAddYE joined #nimrod |
| 09:45:36 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 09:45:58 | * | CarpNet joined #nimrod |
| 10:16:54 | * | Associat0r quit (Quit: Associat0r) |
| 10:17:03 | * | Araq_ joined #nimrod |
| 10:32:42 | * | ics quit (Ping timeout: 246 seconds) |
| 10:35:16 | * | ics joined #nimrod |
| 10:41:50 | * | DAddYE joined #nimrod |
| 10:47:38 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 11:09:49 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131025151332]) |
| 11:15:16 | * | Associat0r joined #nimrod |
| 11:15:17 | * | Associat0r quit (Changing host) |
| 11:15:17 | * | Associat0r joined #nimrod |
| 11:16:09 | * | Ywo quit (Remote host closed the connection) |
| 11:22:33 | * | Associat0r quit (Read error: Connection reset by peer) |
| 11:23:43 | * | Associat0r joined #nimrod |
| 11:23:43 | * | Associat0r quit (Changing host) |
| 11:23:43 | * | Associat0r joined #nimrod |
| 11:30:34 | * | webskipper joined #nimrod |
| 11:35:48 | EXetoC | c(:)-< |
| 11:41:37 | dyu_ | >=(:p |
| 11:43:17 | * | BitPuffin joined #nimrod |
| 11:44:12 | * | DAddYE joined #nimrod |
| 11:44:33 | EXetoC | fish with tongue out? |
| 11:46:30 | EXetoC | BitPuffin: have you memorized ast.nim yet? |
| 11:48:48 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 12:17:45 | * | Jackneill joined #nimrod |
| 12:17:47 | * | Jackneill quit (Read error: Connection reset by peer) |
| 12:17:57 | * | Jackneilll joined #nimrod |
| 12:29:30 | dyu_ | EXetoC: not-so-skinny-boy with a baseball cap |
| 12:32:03 | EXetoC | ooooooh |
| 12:34:23 | * | vidot_j joined #nimrod |
| 12:38:29 | * | freezerburnv joined #nimrod |
| 12:38:44 | freezerburnv | Morning all |
| 12:38:48 | EXetoC | hi |
| 12:41:01 | EXetoC | this might be easier to parse for those who normally read from left to right q:)=< |
| 12:41:36 | freezerburnv | Top hat wearing man being silly? |
| 12:43:42 | EXetoC | kinda |
| 12:45:30 | * | DAddYE joined #nimrod |
| 12:50:57 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 12:56:48 | * | Ricky_Ricardo joined #nimrod |
| 12:58:19 | dyu_ | yep |
| 13:02:49 | * | vidot_j quit (Remote host closed the connection) |
| 13:03:31 | * | dymk quit (Ping timeout: 245 seconds) |
| 13:12:12 | BitPuffin | EXetoC: yes it is completely in my head :P |
| 13:13:30 | EXetoC | ok |
| 13:13:53 | BitPuffin | no but I know what's in there |
| 13:14:01 | BitPuffin | just can't ramble it up from memory |
| 13:14:11 | EXetoC | trees and that |
| 13:14:14 | BitPuffin | yep |
| 13:14:16 | BitPuffin | basically |
| 13:14:18 | BitPuffin | nodes etc |
| 13:14:30 | BitPuffin | procs for manipulating nodes and stuff |
| 13:15:22 | BitPuffin | I wonder if the bug is in sigmatch |
| 13:17:32 | EXetoC | what bug ID? |
| 13:17:53 | EXetoC | 656? |
| 13:18:07 | BitPuffin | EXetoC: 618 |
| 13:19:55 | EXetoC | hm maybe |
| 13:20:44 | BitPuffin | but I'm slightly skeptical |
| 13:20:48 | BitPuffin | I haven't read sigmatch yet |
| 13:21:12 | BitPuffin | but it sounds like it is about matching proc signatures. Not so much determining the types of on argument, could be wrong though |
| 13:21:28 | * | dymk joined #nimrod |
| 13:22:37 | EXetoC | oh right, TMatrix.T is where it fails. I suppose that could be the case anyway, since it might look for proc T(typedesc[TMatrix]) or something, but I don't know if the type parameters need to be present |
| 13:24:08 | EXetoC | nope, not necessary: "proc f(x: typedesc[TMatrix]): int = 42; echo TMatrix.f" |
| 13:26:49 | EXetoC | ok enough guessing |
| 13:27:35 | EXetoC | if you saw this slice notation, what do you think it'd do? let x: TSlice[int] = y ..+ 3 |
| 13:29:30 | EXetoC | *would |
| 13:33:12 | BitPuffin | hmm |
| 13:34:08 | EXetoC | not intuitive, ok :p no one else is working on this project though |
| 13:34:13 | BitPuffin | EXetoC: count upward toward 3? |
| 13:34:53 | BitPuffin | no that sounds more like a range than a slice |
| 13:34:55 | EXetoC | that's what x..y does |
| 13:35:03 | EXetoC | well it doesn't count up |
| 13:35:06 | BitPuffin | yeah |
| 13:35:22 | BitPuffin | EXetoC: the first three? |
| 13:35:35 | BitPuffin | elements |
| 13:35:37 | BitPuffin | of y? |
| 13:35:37 | EXetoC | it just constructs a slice: x..y == TSlice(a: x, b: y) |
| 13:37:06 | EXetoC | no, a slice on its own is just TSLice = object\na, b: T |
| 13:38:34 | EXetoC | I just defined x ..+ y to be TSlice(a: x, b: x + y), which is just a way to save a little typing |
| 13:38:41 | BitPuffin | EXetoC: hmm, well what does a slice object do :P |
| 13:39:31 | EXetoC | defines a range, and it's 'for' for example that generates numbers between that range |
| 13:40:43 | BitPuffin | EXetoC: so how is that different from a range :P |
| 13:42:27 | EXetoC | it is one, so maybe that would be a better name for it, though range is already taken |
| 13:47:51 | * | DAddYE joined #nimrod |
| 13:52:27 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 13:53:55 | * | faassen joined #nimrod |
| 13:54:22 | EXetoC | slices in D are also sort of like ranges, except in the form of a buffer, so it's conceptually more similar to a slice of something |
| 13:54:52 | EXetoC | BitPuffin: does `..+` make more sense now? |
| 13:59:31 | BitPuffin | EXetoC: hang on |
| 13:59:38 | * | BitPuffin is computing |
| 14:00:18 | BitPuffin | processing |
| 14:00:19 | BitPuffin | processing |
| 14:02:11 | BitPuffin | EXetoC: yes |
| 14:02:42 | BitPuffin | EXetoC: is that ever useful though? |
| 14:03:32 | BitPuffin | object constructors is another place where : introduceses some inconsistency |
| 14:04:55 | BitPuffin | EXetoC: or actually yeah that should be very useful |
| 14:07:45 | EXetoC | x .. x + 3 == x ..+ 3 |
| 14:08:03 | BitPuffin | EXetoC: yep |
| 14:08:18 | BitPuffin | EXetoC: are you sure that +.. doesn't make more sense? |
| 14:08:22 | BitPuffin | puts the plus closer to x |
| 14:08:30 | BitPuffin | maybe that gives some intuition maybe |
| 14:08:31 | EXetoC | it is of course pointless when using such short identifiers, which is fine at times, but Araq-style 1-2 letter identifiers all over the place is a little too hardcore for me :p |
| 14:09:50 | BitPuffin | EXetoC: yeah, I don't think it's a good way to code anyways. Makes it harder to follow |
| 14:10:54 | BitPuffin | but when just hacking on something I guess naming stuff can take too much time |
| 14:11:22 | * | OrionPK joined #nimrod |
| 14:13:15 | * | Araq_ joined #nimrod |
| 14:21:09 | EXetoC | BitPuffin: you want = instead of : in constructors? |
| 14:21:25 | BitPuffin | EXetoC: would make it a bit more consistent I think |
| 14:21:46 | BitPuffin | seeing : makes my mind jump to type annotations |
| 14:21:53 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131025151332]) |
| 14:23:33 | EXetoC | yep |
| 14:24:22 | EXetoC | BitPuffin: when do you want to start working on that game? |
| 14:25:39 | BitPuffin | EXetoC: When I'm done with my website I'll touch up linagl a bit and start working. I'll skip the weston shell for a while until there is a fix for the glamor driver because I don't really have a reason to run wayland when I can't run xwayland. When that works maybe I'll work on that a little bit if the game is getting me down :P |
| 14:29:37 | EXetoC | Ok I could start with the basics. input system etc |
| 14:29:40 | webskipper | hiho |
| 14:29:49 | EXetoC | hoe hoe hoe |
| 14:29:53 | EXetoC | *ho |
| 14:30:05 | * | Ricky_Ricardo quit (Quit: Ricky_Ricardo) |
| 14:30:12 | OrionPK | the = : inconsistency between parameter names and constructors has been brought up |
| 14:30:19 | BitPuffin | EXetoC: or oh you meant the open source game? |
| 14:30:30 | BitPuffin | I was talking about the commercial project |
| 14:30:41 | BitPuffin | uh I dunno first of all we need to decide what we should do I think |
| 14:32:36 | BitPuffin | I think something coop would be fun |
| 14:32:42 | BitPuffin | because then we could play it together :P |
| 14:33:33 | BitPuffin | Araq: I think the bug might be in qualifiedLookup |
| 14:33:35 | OrionPK | you guys seriously need to start small :P |
| 14:33:43 | EXetoC | "You don't get anything done by planning" - Karl Pilkington |
| 14:34:22 | BitPuffin | EXetoC: didn't say planning, just something |
| 14:34:23 | BitPuffin | lol |
| 14:34:34 | BitPuffin | and who follows Karl Pilkington's advice! |
| 14:35:01 | EXetoC | someone might |
| 14:35:43 | OrionPK | KP is a secret genius |
| 14:35:54 | CarpNet | definitely |
| 14:36:23 | BitPuffin | yeah actually |
| 14:36:51 | webskipper | somebody used/use python here too ? |
| 14:37:01 | EXetoC | yes |
| 14:37:15 | CarpNet | i use it all day |
| 14:38:34 | webskipper | is Cython comparable to nimrod - what you think ? Didn't see in the documentation how I can compile a cython program to a standalone executable |
| 14:38:35 | * | p0nce is now known as ponce |
| 14:39:39 | BitPuffin | webskipper: don't really think it is comparable |
| 14:47:38 | webskipper | a python-dialect to nimrod translator / compiler would be fun |
| 14:48:06 | BitPuffin | write it :P |
| 14:48:17 | webskipper | why not ? :D |
| 14:48:47 | * | OrionPK quit (Ping timeout: 250 seconds) |
| 14:49:17 | BitPuffin | exactly |
| 14:50:11 | webskipper | I looked on python ast module - you get a full AST. The AST->python code generator by Armin Ronacher I have here already. http://eli.thegreenplace.net/wp-content/uploads/2009/11/codegen.py |
| 14:50:35 | webskipper | The question is how to introduce static types in python (dialect). |
| 14:50:44 | webskipper | OO i dont need btw |
| 14:52:13 | BitPuffin | sounds more like a topic for #python |
| 14:52:22 | EXetoC | why a dialect? |
| 14:52:27 | webskipper | union of both |
| 14:53:01 | webskipper | something like this: def bool myfuc(int x = 3, string blub = 'test') |
| 14:53:16 | webskipper | of course its not python, but can be translated to nimrod |
| 14:54:53 | webskipper | and to python too btw. my idea: def bool_myfunc (int_x = 3, string_blub = 'test') |
| 15:02:11 | LoneTech | webskipper: you may want to compare to cython, pyrex, and shedskin |
| 15:02:54 | webskipper | I know shedskin, its c++ |
| 15:04:05 | LoneTech | for instance cython adds type declarations: http://docs.cython.org/src/quickstart/cythonize.html |
| 15:08:44 | BitPuffin | wtf |
| 15:08:59 | BitPuffin | when you can't even add an echo then you know you are dealing with fragile software |
| 15:09:15 | BitPuffin | oh wait |
| 15:10:07 | BitPuffin | was my fault |
| 15:10:09 | BitPuffin | carry on |
| 15:15:20 | * | mflamer joined #nimrod |
| 15:15:38 | webskipper | LoneTech: yea, don't like the cdef everywhere paradigma in cython. |
| 15:19:02 | BitPuffin | hmm, the compiler must be running in an interpreted mode or something while compiling itself |
| 15:21:15 | EXetoC | when? |
| 15:23:05 | BitPuffin | EXetoC: when compiling itself |
| 15:23:21 | BitPuffin | EXetoC: because I see the changes I made to the compiler as it is bootstrapping immediately after the change |
| 15:23:48 | BitPuffin | like if I add a echo("wtf") every time it does dotexpr then it will print wtf while bootstrapping immediately after that |
| 15:28:21 | freezerburnv | BitPuffin: What things are you planning on touching up in linagl? Or what issues are there that need to be fixed, or stuff added, etc.? I'll contribute to it when I have a little time |
| 15:29:16 | BitPuffin | freezerburnv: nothing that will take too much time. Submatrices, projection matrices, rotation matrices etc |
| 15:29:27 | BitPuffin | adding quaternions, exponential maps etc |
| 15:30:37 | freezerburnv | *shudder* Quaternions. I think I still have my Java code for them that... should? work from a class I took. They have an odd habit of doing weird things when you spin your mouse around really fast for a bit though. I'll port what code I have for as much as I have over to nimrod when I get a chance, as I should have at least some of what you mentioned |
| 15:32:42 | freezerburnv | Also: I have ever more respect for nimrod after looking at that code. Those are some sweet features put together to make a nice library that will likely be screaming fast |
| 15:32:45 | BitPuffin | freezerburnv: meh you don't have to :) I can be quite pedantic about how contributions should be, ask EXetoC :D. It will be added really soon. Best thing to do would to help zahary fix the bug with generic parameters that can't be numbers |
| 15:34:04 | * | BitPuffin is not sure if pedantic is even the right word |
| 15:34:05 | freezerburnv | BitPuffin: Haha. Well, I can try at least :P |
| 15:34:15 | freezerburnv | BitPuffin: What bug is this? Is it a nimrod compiler thing? |
| 15:34:22 | BitPuffin | freezerburnv: yeah! |
| 15:34:28 | BitPuffin | freezerburnv: Check yesterdays logs |
| 15:34:34 | BitPuffin | I believe that's when me and him spoke about it |
| 15:34:40 | BitPuffin | zahary: are you here? |
| 15:36:52 | BitPuffin | freezerburnv: the reason the bug needs fixing is because it stops me from doing what I wanna do before next release (0.2) which is to not specify the dimensions of a vector and matrix with a number instead of rangue |
| 15:36:54 | BitPuffin | range |
| 15:36:55 | BitPuffin | * |
| 15:38:27 | * | mflamer quit (Ping timeout: 272 seconds) |
| 15:40:04 | freezerburnv | BitPuffin: Basically you wanna do something like: TVector3* = TVector[float32, 3]? |
| 15:40:25 | BitPuffin | freezerburnv: pretty much |
| 15:40:32 | BitPuffin | although it would be TVec3 :P |
| 15:40:39 | BitPuffin | but yeah |
| 15:41:07 | BitPuffin | instead of TVec3 = TVector[float32, range[0..2]] it would be more like what you wrote |
| 15:42:29 | freezerburnv | And so the compiler bug is that you can't actually pass in 3 as a template? Got it |
| 15:42:45 | freezerburnv | or rather, lack of a feature. I don't think generics/templates in any other language would allow that... |
| 15:42:52 | freezerburnv | No wait, C++ does |
| 15:42:52 | freezerburnv | My bad |
| 15:44:11 | BitPuffin | freezerburnv: the feature exist |
| 15:44:15 | BitPuffin | freezerburnv: there is a bug with it |
| 15:45:22 | dom96 | hi |
| 15:45:26 | BitPuffin | hey dom96! |
| 15:45:33 | BitPuffin | I'm getting closer to fixing the bug :D |
| 15:45:38 | freezerburnv | Sup dom96 |
| 15:45:43 | BitPuffin | I'm so fucking proud xD |
| 15:45:45 | BitPuffin | at least if I fix it |
| 15:45:56 | * | gradha joined #nimrod |
| 15:47:02 | BitPuffin | freezerburnv: I'd start by looking ctrl+f'in the logs after zahary and me yesterday or whatever it was so that you can read the error and grab the sample code I linked and compile the compiler with debug flag and figure out where things are going wrong with gdb etc |
| 15:47:08 | BitPuffin | and talk to zahary whenever he returns |
| 15:47:09 | dom96 | freezerburnv: nm |
| 15:48:58 | EXetoC | BitPuffin: pedantic indeed... won't even let my code style gain territory >:| |
| 15:49:39 | BitPuffin | EXetoC: yep, and force you to write public domain babble in your commit message :p |
| 15:50:46 | freezerburnv | o_o |
| 15:51:11 | BitPuffin | freezerburnv: :D |
| 15:51:27 | freezerburnv | EXetoC: Should I be terrified? |
| 16:00:16 | gradha | dom96: in babel configuration files, which are nimrod .ini files, is there any syntax to break up long lines into multiple lines? |
| 16:00:31 | gradha | currently I have a longish 'InstallFiles = "nakefile.nim,alchemy.nim,ouroboros.nim,README.md,LICENSE.md,CHANGES.md,docs/file_format.md"' |
| 16:00:41 | dom96 | gradha: Yeah, just use """ like in Nimrod. |
| 16:00:58 | gradha | no comma separation then? |
| 16:01:11 | dom96 | no, you still need them |
| 16:02:55 | gradha | on the second line I get an EOS "No such file or directory" |
| 16:04:08 | gradha | will fix that later |
| 16:04:40 | dom96 | Probably a bug then, perhaps I don't .strip after splitting. |
| 16:07:15 | BitPuffin | dom96: gross |
| 16:14:15 | BitPuffin | hmm |
| 16:14:40 | BitPuffin | how do I turn an identifier node into a symbol |
| 16:17:02 | * | MFlamer joined #nimrod |
| 16:33:13 | BitPuffin | whaat |
| 16:33:20 | EXetoC | whoot |
| 16:34:26 | BitPuffin | hmm |
| 16:34:46 | * | BitPuffin broke the compiler |
| 16:37:09 | BitPuffin | I think I might know whassup |
| 16:38:36 | * | OrionPK joined #nimrod |
| 16:38:41 | BitPuffin | I need to check if the identifier is a generic parameter identifier somehow |
| 16:41:26 | BitPuffin | tricky wan |
| 16:50:24 | * | BitPuffin prays this works |
| 16:50:27 | BitPuffin | nope |
| 16:51:21 | * | MFlamer quit (Remote host closed the connection) |
| 16:51:23 | BitPuffin | but that was just a silly thing |
| 16:51:32 | * | DAddYE joined #nimrod |
| 16:53:31 | BitPuffin | closer :P |
| 16:56:35 | * | Associat0r quit (Quit: Associat0r) |
| 16:57:39 | * | DAddYE quit (Ping timeout: 244 seconds) |
| 17:16:33 | * | Demos joined #nimrod |
| 17:26:43 | * | dymk quit (Ping timeout: 288 seconds) |
| 17:30:44 | BitPuffin | Araq: are you here? |
| 17:31:34 | gradha | BitPuffin: pinging is the formal protocol |
| 17:31:44 | BitPuffin | okay |
| 17:31:46 | BitPuffin | ping Araq |
| 17:31:48 | BitPuffin | :P |
| 17:31:54 | BitPuffin | are you still here? target lost. |
| 17:32:26 | gradha | BitPuffin: good, now you only need to fill in your form, stamp it twice and send it to Germany |
| 17:32:42 | BitPuffin | sweet |
| 17:33:21 | Varriount | Meep |
| 17:33:26 | * | Varriount is aliiiiivvee |
| 17:36:58 | * | fowl joined #nimrod |
| 17:40:27 | * | MFlamer joined #nimrod |
| 17:43:19 | BitPuffin | MFlamer: I'm close to fixing your bug I think, just that I have gotten stuck lol |
| 17:43:46 | MFlamer | nice, let me know if I can help in anyway |
| 17:44:37 | BitPuffin | MFlamer: Well I'm trying to figure out how to turn T into what the instance of T really is |
| 17:44:51 | BitPuffin | so far I have managed to change the error to: Error: undeclared identifier: 'T' |
| 17:44:57 | BitPuffin | which is closer than '' |
| 17:45:23 | BitPuffin | I am assuming it is to look it up somehow in the typeInstCache |
| 17:46:02 | BitPuffin | of the type on the left side of the . |
| 17:46:28 | BitPuffin | MFlamer: thoughts? |
| 17:52:30 | * | DAddYE joined #nimrod |
| 17:54:14 | BitPuffin | hmm maybe this does it |
| 17:54:23 | MFlamer | sorry, in skype meeting now |
| 17:55:19 | BitPuffin | ah |
| 17:55:21 | BitPuffin | carry on :P |
| 17:56:25 | * | Demos quit (Ping timeout: 272 seconds) |
| 18:10:05 | dyu_ | dom96: perhaps I don't .strip after splitting. <-- quote of the day :-) |
| 18:11:07 | * | Varriount never knew dom96 was a stripper. |
| 18:11:11 | dyu_ | hehe |
| 18:25:07 | OrionPK | dom96 is barely legal |
| 18:29:11 | fowl | jb |
| 18:36:45 | * | enurlyx joined #nimrod |
| 18:40:25 | * | CarpNet quit (Quit: Leaving) |
| 18:41:23 | dom96 | hah |
| 18:53:03 | * | Demos joined #nimrod |
| 19:02:19 | Varriount | Araq, just as lambda variables have semstmts.semLambda, do normal procedures have a corresponding procedure? |
| 19:02:56 | EXetoC | dom96: pie |
| 19:04:26 | * | Mat2 joined #nimrod |
| 19:04:32 | Mat2 | hi all |
| 19:04:50 | Varriount | Hello! |
| 19:05:15 | Mat2 | hi Varriount |
| 19:05:52 | Varriount | Mat2, need anything? |
| 19:06:29 | dom96 | EXetoC: yes plz |
| 19:06:38 | shodan45 | is there another tutorial besides "tutorial 2" that covers more advanced stuff in nimrod? |
| 19:06:43 | Mat2 | hi dom96 and shodan45 |
| 19:06:50 | dom96 | hey Mat2! |
| 19:06:54 | shodan45 | hello |
| 19:06:55 | dom96 | Where have you been? |
| 19:07:06 | Mat2 | Varriount: Not directly |
| 19:07:11 | dom96 | shodan45: The manual. |
| 19:07:25 | * | Demos quit (Ping timeout: 246 seconds) |
| 19:07:32 | gradha | Mat2: will your work allow nimrod to compile without a C compiler installed on the users' machine? |
| 19:07:45 | Mat2 | dom96: lot of work at past |
| 19:08:03 | Mat2 | gradha: yes |
| 19:08:09 | gradha | amazing |
| 19:08:10 | NimBot | nimrod-code/packages master 0d0103b Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds ouroboros module to package list. |
| 19:08:10 | NimBot | nimrod-code/packages master 572f3d7 Dominik Picheta [+0 ±1 -0]: Merge pull request #30 from gradha/pr_ouroboros... 2 more lines |
| 19:08:56 | gradha | that with ouroboros will allow us to conquer the world by dropping binaries everywhere! |
| 19:11:09 | Varriount | What is ouroboros? (the module) |
| 19:11:30 | gradha | it's an API to read back files appended to your executable |
| 19:11:54 | gradha | it is also kind of a packed file format, which is appended to your binaries |
| 19:12:06 | Varriount | gradha, what's wrong with "static readFile(..)"? |
| 19:12:20 | gradha | nothing, try to read the data back |
| 19:12:32 | gradha | in the compiler |
| 19:12:37 | gradha | for all available babel modules |
| 19:17:53 | gradha | with Mat2's work and ouroboros you can in theory generate a single binary which has everything required to copy on a USB and compile nimrod wherever you want |
| 19:18:03 | gradha | no installation required |
| 19:18:30 | gradha | and using ouroboros instead of static readFile also allows you to update the appended data without rebuilding the compiler version, which may be useful |
| 19:19:59 | Mat2 | for me it would be ideal to have a EBNF notation of Nimrod at current |
| 19:21:30 | dom96 | Mat2: Well, it's nice to see that you're still with us :) |
| 19:21:46 | Varriount | What kind of parser does nimrod even use? LR(1)? |
| 19:22:14 | Mat2 | gradha: Yes but beware, my compiler will be more of an independent environment for system programming |
| 19:22:53 | Mat2 | (it will be perfectly suited for os development for example) |
| 19:22:57 | fowl | Mat2, there is one, somewhere |
| 19:23:00 | gradha | aww, well, then the ouroborosed nimrod will require an installed working C compiler then |
| 19:23:24 | gradha | or maybe somebody has the will to make it work with tinyc backend again or something small which can be embedded too? |
| 19:23:33 | Mat2 | fowl: thanks, I take a search |
| 19:24:06 | * | Associat0r joined #nimrod |
| 19:24:19 | * | Associat0r quit (Changing host) |
| 19:24:19 | * | Associat0r joined #nimrod |
| 19:24:32 | Mat2 | gradha: would be nice, but to ressource intensive for some common embedded systems around (like arduino class boards) |
| 19:24:47 | * | freezerburnv quit (Ping timeout: 260 seconds) |
| 19:24:56 | gradha | also tcc is LGPL, so maybe that would be a problem for binary distribution |
| 19:25:04 | Mat2 | however, there exist always the option for cross-compilation |
| 19:25:46 | Mat2 | dom96: thanks |
| 19:25:58 | Araq | yay wb Mat2 |
| 19:26:02 | Mat2 | hi Araq |
| 19:26:18 | Mat2 | where can I find an EBNF notation for Nimrod's syntax ? |
| 19:26:27 | Araq | don't you dare leaving without submitting your JIT stuff in a separate branch ;-) |
| 19:26:55 | Araq | the manual contains an EBNF notation where 'E' stands for "Araq's enhancements" |
| 19:27:10 | Araq | well in fact ... it's actually a PEG |
| 19:27:13 | * | brson joined #nimrod |
| 19:27:27 | Araq | EBNF is limiting and archaic |
| 19:27:46 | Mat2 | what branch ? The compiler is entire written from scratch |
| 19:28:08 | Araq | EBNF lacks higher order rules/parametrization for instance |
| 19:28:16 | Araq | ouch. |
| 19:28:18 | Mat2 | anyhow, any notation will do, I take a look |
| 19:28:27 | Araq | I told you not to do this :P |
| 19:29:04 | gradha | the desire to rewrite the wheel is strong in this channel |
| 19:30:03 | Mat2 | Get me an insight how to sqeeze Nimrod's compiler into 8 kB of ram and I'm crazy enough to work on it as addition ;) |
| 19:31:24 | gradha | we could actually beat all those Samsungs and Apples to implement a smartwatch, compiling everything in the fraction of their wallpaper PNG |
| 19:31:41 | Mat2 | *g* |
| 19:32:17 | shodan45 | Araq: hmm, what's your day job? just curious ;) |
| 19:32:22 | fowl | i've seen samsungs smartwatch |
| 19:32:25 | fowl | it already exists |
| 19:32:28 | Araq | Mat2: well I told you it won't fit in 8K ;-) Nimrod hasn't been designed for this. However defining a subset/dialect is fine with me |
| 19:32:53 | Mat2 | that's what I'm working on now |
| 19:33:10 | gradha | fowl: like in meatspace? somebody bought one? |
| 19:33:23 | Araq | shodan45: it's a well kept secret |
| 19:33:28 | fowl | gradha, what? |
| 19:33:35 | fowl | gradha, i saw it in a verizon store |
| 19:34:01 | shodan45 | Araq: oh? o_o as long as it isn't the nsa..... >_> |
| 19:34:16 | gradha | fowl: aaah, here in the third world we don't have verizon stores |
| 19:34:45 | * | enurlyx quit (Quit: Nettalk6 - www.ntalk.de) |
| 19:35:40 | Mat2 | Araq: Found it, thanks. I will have some questions about the type system in future for sure |
| 19:36:27 | gradha | fowl: AFAICS I can't even buy one on the samsung webpage |
| 19:36:45 | Araq | Mat2: compiler/parser.nim is also reasonably clean to be taken as a reference. imho anyway |
| 19:37:32 | fowl | gradha, http://www.samsung.com/us/mobile/cell-phones-accessories/SM-V7000ZGAXAR |
| 19:37:45 | fowl | found in like 3 seconds |
| 19:38:09 | gradha | fowl: yeah, but http://www.samsung.com/es/consumer/mobile-phone/galaxy-gear/galaxy-gear/SM-V7000ZKAPHE doesn't have a shop button, so can't buy it |
| 19:38:41 | fowl | it does for me |
| 19:39:01 | Araq | Varriount: semProc ? |
| 19:39:03 | gradha | fowl: so you can shop from the spain web but not me? |
| 19:39:12 | fowl | no, im on the us page |
| 19:39:16 | fowl | world #1 |
| 19:39:28 | gradha | fowl: ah, yes, that's what I meant then |
| 19:40:24 | Mat2 | fowl: Do you know the specification of this watch ? |
| 19:40:52 | * | fowl quit (Read error: Connection reset by peer) |
| 19:40:58 | Araq | BitPuffin: pong |
| 19:41:06 | Varriount | Araq, I'm trying to find out why a regular procedure ("proc test(a, b): auto = a+b") is having it's generic parameters generated, while a lambda ("var p = proc (a, b): auto = a+b") is not |
| 19:41:32 | Araq | Varriount: but you already did, I think |
| 19:41:46 | Araq | I never considered generic lambdas to be worth while |
| 19:42:01 | Araq | so it never was supported. crazy, I know |
| 19:42:07 | BitPuffin | Araq: ahoy cap'n! I'm wondering, given a certain context and a generic type T, how do I "extract" what the istance of that type is in the context? |
| 19:42:19 | * | enurlyx joined #nimrod |
| 19:42:52 | Araq | BitPuffin: depends on whether T is used for a proc or for a type iirc |
| 19:43:26 | MFlamer | Isn't is the last son in an generic instantiated node? |
| 19:43:32 | Araq | for a proc that's some simple symbol table lookup iirc (which btw is quite a hacky way to implement it) |
| 19:43:45 | Araq | MFlamer: for a type you're right |
| 19:44:13 | BitPuffin | Araq: Hmm, well I'm working on 618, I think I figured out that the issue was in QualifiedLookup where it didn't catch a skType in the dotexpr |
| 19:44:14 | MFlamer | Isn't he working with types? |
| 19:44:35 | Araq | no idea what #618 is about |
| 19:45:02 | BitPuffin | Araq: it's about proc foo(a: TMatrix): TMatrix.T |
| 19:45:16 | BitPuffin | Araq: where it doesn't find TMatrix.T |
| 19:45:27 | BitPuffin | so it basically takes it as '' is the return type which isn't a type |
| 19:45:46 | BitPuffin | I've managed to get it to Error: undeclared identifier: 'T' which is at least closer than before lol |
| 19:45:55 | Araq | nice |
| 19:46:08 | BitPuffin | now I just need to get what T represents |
| 19:47:36 | MFlamer | why does MFlamer find himself constatntly wanting to engage on this IRC when he's susuposed to be working? |
| 19:48:06 | BitPuffin | MFlamer: I have the same issue :P |
| 19:48:24 | BitPuffin | but hey, our community is important too! |
| 19:48:36 | MFlamer | For the greater good! |
| 19:49:15 | BitPuffin | so it isn't completely wasted time I think |
| 19:49:23 | BitPuffin | MFlamer: but you think in this case it is the last son? |
| 19:50:10 | Araq | BitPuffin: debug TMatrix and see what its type is |
| 19:51:59 | BitPuffin | Araq: in the tmatrix source code? In this case it doesn't even have a type. What the bug report contains is basically a type definition of TMatrix and a sample proc that returns TMatrix.T |
| 19:52:06 | MFlamer | I'm thinkng you may need to do the symbol lookup, then check the last son |
| 19:52:47 | MFlamer | he means debug the node in the compiler, so you get a dump at compile time |
| 19:53:17 | BitPuffin | MFlamer: well the part that I'm trying to fix is the lookup |
| 19:53:29 | * | dymk joined #nimrod |
| 19:54:15 | BitPuffin | https://gist.github.com/BitPuffin/7343030#file-gistfile1-nim-L38 and downward is basically my work so far |
| 19:54:32 | BitPuffin | nevermind the duplication stuff, it wasn't like that before, I was just trying a thing :P |
| 19:54:44 | BitPuffin | I mean the var sym = gSym.typ.sym |
| 19:54:49 | BitPuffin | xD |
| 19:54:52 | EXetoC | "i < <tokSlices.len" operators ftw |
| 19:55:17 | Araq | BitPuffin: interesting approach but all wrong I think |
| 19:56:06 | BitPuffin | Araq: well it was the first thing that came to mind. By all wrong you mean fixing it in QualifiedLookup? or just what I did in there |
| 19:57:06 | * | fowl joined #nimrod |
| 19:57:12 | EXetoC | Varriount: actually, I think the container interface will improve as a result of the upcoming user-defined type classes |
| 19:57:12 | * | capisce_ joined #nimrod |
| 19:58:00 | EXetoC | I didn't think of it the last time we talked about container-agnostic functions |
| 19:58:23 | Araq | BitPuffin: fixing it in qualifiedLookup. In fact you should ask zahary how to proceed. he implemented TMatrix.T |
| 20:01:37 | Varriount | Araq, then what should be done for bugs concerning generic lambdas? |
| 20:02:28 | Varriount | EXetoC, *shrug* the itertools module shouldn't be too hard to modify |
| 20:02:56 | * | MFlamer quit (Remote host closed the connection) |
| 20:04:15 | EXetoC | well we do have agnostic functions already, just that they might lack compile-time checks |
| 20:04:38 | BitPuffin | Araq: ah, sorry it was the first place I found where there seemed to be a way to fix the bug. I hope zahary comes around sometime soon :) |
| 20:04:46 | Varriount | EXetoC, or they crash the compiler. |
| 20:05:28 | Araq | BitPuffin: it's fine and you can continue to patch it there and then we'll move it to the proper position |
| 20:06:08 | EXetoC | same goes for the code that does the checking, if there's a bug :p |
| 20:07:02 | Mat2 | get some sleep, ciao |
| 20:07:03 | EXetoC | Varriount: you might want to start working on it anyway, in which case the definition of something like sequtils.toSeq might be of interest |
| 20:07:09 | EXetoC | Mat2: hi, bye! |
| 20:08:24 | * | jdp_ joined #nimrod |
| 20:08:26 | Varriount | EXetoC, right now I'm just using generic iterators, and assuming that whatever type given supports the "for" statement |
| 20:08:37 | fowl | c2nim sucks with do {} while(); =( |
| 20:09:04 | Varriount | fowl, you might be able to fix it. |
| 20:09:09 | * | Mat2 quit (Quit: Verlassend) |
| 20:09:11 | BitPuffin | Araq: okay sure that sounds good. Maybe I'll put a comment there saying that it should be moved or something. I guess in this case the real type is probably the last son of n? if what MFlamer said was true |
| 20:09:22 | EXetoC | Varriount: that's a good start |
| 20:09:29 | Varriount | fowl, just have c2nim copy the block in the while loop, and paste it before the while |
| 20:09:32 | * | capisce quit (Ping timeout: 240 seconds) |
| 20:09:32 | * | shevy quit (Ping timeout: 240 seconds) |
| 20:09:33 | * | jdp quit (Ping timeout: 240 seconds) |
| 20:09:33 | * | mkb quit (Ping timeout: 240 seconds) |
| 20:09:33 | * | mkb joined #nimrod |
| 20:09:38 | BitPuffin | or hmm maybe not n |
| 20:09:43 | * | shevy joined #nimrod |
| 20:10:54 | Varriount | "do {body} while(condition)" is just syntactic sugar for "body; while(condition){body}" |
| 20:11:10 | fowl | i know what do{}while() is |
| 20:11:13 | fowl | zz |
| 20:11:17 | BitPuffin | Araq: at first I suspected that it was somewhere in typeInstCache of the PSym |
| 20:15:39 | BitPuffin | BBQCoding |
| 20:15:42 | BitPuffin | you guys should try it |
| 20:15:48 | BitPuffin | it's when you BBQ and code at the same time |
| 20:16:10 | Araq | sometimes I do drinkCoding |
| 20:16:29 | Araq | in fact |
| 20:16:40 | BitPuffin | not when working on the compiler I hope :P |
| 20:16:40 | Araq | let's see if there some beer here |
| 20:17:06 | Araq | lol of course. it's not like I have any other hobby projects |
| 20:18:59 | BitPuffin | Araq: How does it affect your coding abilities? Does it make you worse or does it maybe help you focus or something? |
| 20:19:22 | EXetoC | give pony trekking a go |
| 20:21:00 | Araq | BitPuffin: well it lessens the pain :p |
| 20:21:02 | BitPuffin | scientific studies show that people who do bbqcoding are cooler than those who don't |
| 20:21:11 | BitPuffin | Araq: always so cheerful :P |
| 20:21:36 | Araq | gradha knows I only touch osproc when drunk |
| 20:22:34 | shevy | you drink only when you touch osproc! |
| 20:22:59 | Araq | BitPuffin: fyi semexprs line 924 seems to be the issue |
| 20:23:03 | gradha | the first rule of the tautology club is the first rule of the tautology club |
| 20:24:19 | Araq | BitPuffin: copy what tyGenericInst does and adapt it for tyGenericBody |
| 20:25:07 | BitPuffin | Araq: so I should undo all I did in lookups? |
| 20:25:14 | Araq | yes |
| 20:25:43 | Araq | and do your BBQ thing. it can only help |
| 20:26:47 | BitPuffin | I'll take a look |
| 20:30:40 | BitPuffin | Araq: you mean what tyGenericInst does within builtInFieldAccess? |
| 20:30:54 | * | MFlamer joined #nimrod |
| 20:31:00 | BitPuffin | o/ MFlamer |
| 20:31:09 | Araq | yeah and that code is wrong too |
| 20:31:15 | BitPuffin | haha |
| 20:31:32 | EXetoC | uh oh |
| 20:31:54 | Araq | but it's an easy fix; instead of tParam.sym.name == i it should be tParam.sym.name.id == i.id |
| 20:32:17 | Araq | idents.nim should overload == I guess |
| 20:35:38 | MFlamer | ah ha |
| 20:37:00 | MFlamer | cool, I think this is going to make some stuff possible I was stuck on a while back |
| 20:37:01 | Araq | MFlamer: are up to some pretty big symbol table refactorings? |
| 20:37:31 | MFlamer | Araq: what do you mean? |
| 20:38:02 | Araq | the symbol table implementation never got updated to deal with more recent features, causing all sort of bugs and problems |
| 20:38:58 | MFlamer | So, you believe there is a group of bugs that all relate to this, and some one needs to step up and fix it? |
| 20:39:18 | Araq | yes but I don't believe it, I know it |
| 20:39:43 | Araq | the bugs might not be reported but that matters little |
| 20:40:43 | MFlamer | Myself or BitPuffin could try and master that part of the compiler...... |
| 20:41:31 | * | Jackneilll quit (Remote host closed the connection) |
| 20:41:41 | Araq | basically everything that uses lookups.lookup, qualifiedLookup, and perhaps localSearchInScope and searchInScopes is wrong |
| 20:42:11 | Araq | these all need to get a new kind of "preference" parameter |
| 20:42:29 | Araq | so that immediate templates are preferred over ordinary templates for instance |
| 20:42:37 | * | fowl quit (Read error: Connection reset by peer) |
| 20:42:53 | Araq | currently it's simply bad luck, depending on the hashing scheme |
| 20:42:56 | BitPuffin | ty.len == 1: that's kind of weird |
| 20:43:35 | Araq | and arguably an sfImmediate macro cannot be overloaded at all |
| 20:43:49 | BitPuffin | does that mean it will only work for TMatrix.T and not TMatrix.Type ? |
| 20:43:51 | Araq | so the compiler should reject that |
| 20:44:21 | Araq | BitPuffin: len is not the length of the identifier |
| 20:44:26 | BitPuffin | Araq: ah |
| 20:44:40 | BitPuffin | I had that suspicion |
| 20:49:22 | BitPuffin | │21:39:14 Araq | yes but I don't believe it, I know it │ |
| 20:49:34 | BitPuffin | woa |
| 20:49:44 | BitPuffin | how did that happen |
| 20:49:47 | BitPuffin | xD |
| 20:50:06 | MFlamer | keep it under control BitPuffin! |
| 20:51:27 | BitPuffin | I'm trying |
| 20:51:46 | BitPuffin | the compiler has drained my sanity! :p |
| 20:51:56 | MFlamer | ok, I copied that info for reference Araq |
| 20:55:12 | BitPuffin | MFlamer: you probably have much larger chances than me to master it because you've already fixed a few bugs and I didn't even manage to find the bug properly without Araq :P |
| 20:55:16 | BitPuffin | But you have my axe! |
| 20:55:51 | BitPuffin | and dom96's underwear |
| 20:56:51 | dom96 | Not my lucky programming underwear :( |
| 20:56:59 | * | freezerburnv joined #nimrod |
| 20:57:19 | * | freezerburnv quit (Client Quit) |
| 20:57:27 | BitPuffin | dom96: well you are a stripper now remember :P |
| 20:58:20 | * | freezerburnv joined #nimrod |
| 20:58:22 | MFlamer | Yeah, but the truth is my fixes were crap and Araq had to tell me how to redo them also! |
| 20:58:49 | BitPuffin | hahah |
| 20:59:39 | MFlamer | But, I do reall want to get familiar with the compiler. I'm really intersted in language design and type theory right now. Want to learn from the master.... |
| 20:59:47 | MFlamer | really* |
| 20:59:56 | BitPuffin | I want to know how Araq found the bug :( maybe it was just him knowing the compiler and all. But who knows maybe he has a process (hint: Araq this would be a really nice blog post) |
| 20:59:56 | Araq | yeah but relax. everybody starts like that |
| 21:00:07 | Varriount | Hrm. Why/how are lambdas different from ordinary procedures? |
| 21:00:42 | BitPuffin | MFlamer: yeah I think it's better the more people know the compiler, so that we get rid of the hit by a bus problem |
| 21:00:57 | Varriount | "Hit by a bus problem"? |
| 21:00:59 | MFlamer | yes |
| 21:01:09 | Araq | Varriount: well they share most of the implementation |
| 21:01:14 | BitPuffin | Varriount: if Araq and zahary gets hit by a bus we are more or less fucked |
| 21:01:17 | BitPuffin | :P |
| 21:01:45 | Araq | MFlamer: in fact, I need to learn much more about type theory too ;-) |
| 21:01:45 | Varriount | Araq, be careful around buses. |
| 21:02:11 | * | Varriount gets out the bubble wrap. |
| 21:02:12 | BitPuffin | don't trust them |
| 21:02:20 | * | CarpNet joined #nimrod |
| 21:02:22 | BitPuffin | didn't you see that criminal minds episode? |
| 21:02:34 | * | Varriount rarely watches TV |
| 21:02:41 | gradha | Criminal minds? Is that a show about politicians? |
| 21:02:43 | BitPuffin | Varriount: I didn't see it on TV |
| 21:02:49 | * | fowl joined #nimrod |
| 21:02:50 | BitPuffin | gradha: oh snawp he dedont |
| 21:02:58 | Araq | BitPuffin: I don't think I've any tricks. It's just that I know the compiler quite well for obvious reasons |
| 21:04:17 | BitPuffin | Araq: so generally you just take a guess and usually you are right? |
| 21:04:44 | gradha | BitPuffin: don't you do the same when debugging your own programs? aka guess? |
| 21:04:48 | MFlamer | Araq: have you read "Types and Programming Languages" |
| 21:04:50 | * | faassen left #nimrod (#nimrod) |
| 21:05:42 | BitPuffin | gradha: more or less yeah |
| 21:05:44 | Araq | MFlamer: nope it's on my "to-read" list though |
| 21:05:57 | Araq | in fact it's the book I want to read ASAP |
| 21:06:33 | BitPuffin | read it then!! |
| 21:06:36 | BitPuffin | :D |
| 21:06:38 | MFlamer | It's hard to relax and read when you feel like you need to actually should work |
| 21:06:45 | BitPuffin | yup |
| 21:07:01 | gradha | that's easy: consider reading is part of your work |
| 21:08:03 | * | gradha opens up last months playboy magazine… for the articles |
| 21:09:55 | MFlamer | I started on this study group https://groups.google.com/forum/#!forum/hott-amateurs (don't mind the name) a while back. The first chapter was a review of standard type theory and was really cool. After that it got really abstract and I could keep up.. |
| 21:10:10 | Varriount | Well, I may not have fixed the underlying problem, but at least generic lambdas don't crash the compiler now... |
| 21:10:26 | * | freezerburnv quit (Quit: freezerburnv) |
| 21:10:44 | MFlamer | Hott is Homotopy Type Theory, not what gradha was thinking |
| 21:11:12 | * | gradha puts on again his tinfoil hat |
| 21:11:21 | MFlamer | keep it on |
| 21:12:53 | Araq | MFlamer: let me know if you read something about how to eliminate cycles in type graphs |
| 21:13:06 | Araq | that would be more useful than anything else |
| 21:13:32 | MFlamer | ok |
| 21:13:36 | * | Araq hates graph structures that are not acyclic |
| 21:14:25 | * | Associat0r quit (Quit: Associat0r) |
| 21:15:56 | gradha | how do cycles form in graph structures? for containers? |
| 21:16:39 | Araq | type Foo = ptr array [8, Foo] |
| 21:16:52 | gradha | so containers |
| 21:17:00 | Araq | yes |
| 21:31:40 | EXetoC | wawawiwa |
| 21:32:46 | OrionPK | the upside down stack trace is a mindfuck sometimes |
| 21:33:18 | Araq | OrionPK: I think it's much more natural than the other way |
| 21:33:34 | OrionPK | Araq a stack is generally considered (gravitationally speaking) to be top to bottom, not bottom to top :P |
| 21:33:58 | Araq | it's also what python does iirc |
| 21:34:09 | BitPuffin | Araq: okay I did what I assumed you wanted me to do but it doesn't seem like it fixed the bug, let me paste |
| 21:34:14 | Araq | and you don't suggest python's stack traces are wrong, do you? |
| 21:34:23 | OrionPK | lol |
| 21:34:27 | OrionPK | no python is the end all be all |
| 21:34:33 | OrionPK | we should all switch to python |
| 21:35:13 | BitPuffin | Araq: https://gist.github.com/BitPuffin/7344499#file-gistfile1-nim-L45 |
| 21:36:22 | Araq | BitPuffin: I'm impressed. looks like I imagined |
| 21:36:30 | BitPuffin | Araq: :D |
| 21:36:37 | BitPuffin | Araq: but the bug remains |
| 21:37:07 | Araq | now uncomment the echo "TYPE FiELD ACCESS" and debug ty lines |
| 21:37:56 | BitPuffin | alright |
| 21:37:57 | Araq | and see why it's not a tyGenericBody, or do you already know that it is? |
| 21:38:31 | BitPuffin | I don't, so let's see |
| 21:39:46 | BitPuffin | Araq: hmm, compiling the bug report code didn't show any output from echo type field access and debug ty |
| 21:40:31 | BitPuffin | so something catches it |
| 21:41:25 | BitPuffin | let's see if the newly added of clause catches it |
| 21:41:35 | webskipper | hey guys, my translator is born. It can translate def to proc already - great (lol) |
| 21:42:05 | Araq | webskipper: you can do the same with a source code filter ;-) |
| 21:42:10 | webskipper | "def bool myfunc ( int test, string blub):" => DefNode(bool myfunc [ArgNode(int test def:None), ArgNode(string blub def:None)]) |
| 21:42:10 | webskipper | => proc myfunc (test : int, blub : string) : bool = |
| 21:42:33 | fowl | webskipper, whats that, scala? |
| 21:42:48 | Araq | cython |
| 21:42:55 | Araq | or whatever it's called |
| 21:42:56 | webskipper | fowl: its my own python dialect :D |
| 21:42:59 | fowl | oh |
| 21:43:26 | Varriount | Araq, are there any parts of nimrod source code filter functionality that aren't currently documented? |
| 21:43:52 | Araq | Varriount: I don't think so |
| 21:44:11 | Varriount | Also, we should probably put up somewhere that a source code filter can be used if you want to change nimrod's indentation style. |
| 21:44:38 | webskipper | fowl: have to refactor my tokenizer. after that i can translate the tokens to instances of node classes (build a tree). from that tree i generate the nimrod code. |
| 21:44:39 | Varriount | For all the Tab-users |
| 21:44:48 | gradha | or for all the ruby users missing end |
| 21:45:15 | Araq | #end is not too bad, gradha :P |
| 21:45:20 | BitPuffin | no it does not |
| 21:45:21 | webskipper | will link the code when its ready |
| 21:45:47 | Araq | webskipper: you know nimrod has a pluggable parser architecture? |
| 21:46:09 | Araq | adding a custom parser is quite easy. and has never been done. |
| 21:46:10 | webskipper | Araq: i want to use python for that |
| 21:46:21 | Araq | lol I don't think so |
| 21:47:44 | fowl | lol quite easy and has never been done |
| 21:47:57 | BitPuffin | neither tyGenericBody or Inst of's are entered |
| 21:48:00 | BitPuffin | and not the else |
| 21:48:03 | BitPuffin | hm |
| 21:48:22 | Araq | BitPuffin: semtypes line 232 is too blame |
| 21:48:30 | dom96 | "quite easy", yeah, sounds totally believable coming from a compiler dev :P |
| 21:48:48 | gradha | webskipper: adding a custom parser is quite easy |
| 21:49:15 | Araq | alright, I'll try to avoid that word from now on |
| 21:49:35 | gradha | use "fun" from now on |
| 21:49:51 | Araq | ah, good idea |
| 21:50:27 | BitPuffin | Araq: how can a proc definition be the blame :P |
| 21:50:32 | webskipper | gradha: is there a doc to ? |
| 21:51:00 | BitPuffin | the builtInFieldAccess proc is actually not even called |
| 21:51:02 | BitPuffin | for that file |
| 21:52:07 | gradha | webskipper: sadly it has never been done |
| 21:52:35 | Araq | BitPuffin: yeah I know |
| 21:52:50 | Araq | you need to patch that proc instead |
| 21:53:04 | Araq | but it makes me wonder how that Matrix.T stuff ever worked |
| 21:53:08 | Araq | quite puzzling |
| 21:53:20 | gradha | webskipper: take a look at compiler/parser.nim and ask here if something is not clear |
| 21:53:36 | BitPuffin | Araq: should I keep the changes made to builtInFieldAccess? |
| 21:54:10 | BitPuffin | Araq: If it is of any comfort I can't remember a time when it did work |
| 21:54:50 | webskipper | gradha: will take a look |
| 21:57:23 | Araq | webskipper: also look at syntaxes.nim which implements the parsing dispatcher |
| 22:03:03 | gradha | nimrod adoption should increase once we have a parser of shakespeare source code http://shakespearelang.sourceforge.net/report/shakespeare/ |
| 22:03:51 | BitPuffin | Araq: ah I need to add an if for nkType in that proc |
| 22:04:17 | BitPuffin | or actually I just turned the if != nkType into an else for a check for nkType because why check twice |
| 22:04:35 | * | brson quit (Ping timeout: 245 seconds) |
| 22:04:39 | Araq | BitPuffin: I'm busy but it sounds good |
| 22:04:52 | BitPuffin | okay sorry :) |
| 22:04:59 | * | brson joined #nimrod |
| 22:07:12 | * | dyu_ quit (Quit: Leaving) |
| 22:09:14 | * | profmakx quit (Remote host closed the connection) |
| 22:09:53 | * | profmakx joined #nimrod |
| 22:10:17 | * | profmakx is now known as Guest16136 |
| 22:11:22 | Varriount | Araq, on the topic of generic lambdas - currently a generic lambda crashes the compiler. |
| 22:11:42 | Araq | Varriount: well fix it |
| 22:11:48 | Varriount | I have a fix for the crashing (inserting a dummy generic node fixes it) |
| 22:12:21 | Varriount | However I don't know the internals of the compiler well enough to actually have nimrod process the generic lambda. |
| 22:12:51 | Varriount | Currently the fix just leaves nimrod complaining that the generic lambda isn't a proper type. |
| 22:13:32 | * | Guest16136 quit (Changing host) |
| 22:13:32 | * | Guest16136 joined #nimrod |
| 22:16:22 | BitPuffin | hmm, I'm not even sure what is supposed to happen when the result is a type symbol ._. |
| 22:17:57 | * | Guest16136 quit (Remote host closed the connection) |
| 22:18:11 | Araq | Varriount: that sounds bad :-( |
| 22:18:12 | * | permanen1e joined #nimrod |
| 22:19:53 | * | permanen1e is now known as profmakx |
| 22:20:26 | * | profmakx is now known as Guest59588 |
| 22:20:44 | Varriount | Araq, do you have any pointers as to where I could start digging? |
| 22:20:51 | * | Guest59588 quit (Changing host) |
| 22:20:51 | * | Guest59588 joined #nimrod |
| 22:21:05 | * | Guest59588 is now known as profmakx |
| 22:21:16 | BitPuffin | I assume something similar to the first thing I tried |
| 22:39:02 | * | CarpNet quit (Quit: Leaving) |
| 22:39:02 | * | DAddYE quit (Read error: Connection reset by peer) |
| 22:39:34 | * | DAddYE joined #nimrod |
| 22:40:29 | * | freezerburnv joined #nimrod |
| 22:43:15 | BitPuffin | grrrrrr |
| 22:43:37 | Varriount | BitPuffin, ? |
| 22:44:07 | Araq | Varriount: no, sorry; try to disable the error message and see where it then crashes ... |
| 22:44:09 | * | OrionPK quit (Ping timeout: 250 seconds) |
| 22:45:15 | BitPuffin | Varriount: I'm trying to fix a bug |
| 22:45:23 | BitPuffin | but I suck at the compiler :P |
| 22:45:50 | Araq | BitPuffin: yeah but it's all my fault because I use 1-letter variable names |
| 22:46:46 | BitPuffin | Araq: that's not really what is causing my confusion in this case :P |
| 22:47:08 | EXetoC | sarcasm? who knows q: |
| 22:47:11 | Araq | oh really? now that's surprisng |
| 22:48:25 | Araq | seriously guys how can you like directories? I just typed pure/lib/htmlgen instead of lib/pure/htmlgen ... |
| 22:48:59 | EXetoC | fowl: Do you how to fix this? I'm trying to run bullet.nim. "could not import: gluErrorUnicodeStringEXT" |
| 22:49:01 | BitPuffin | the horror :P |
| 22:49:27 | fowl | EXetoC, is bullet.nim mine? |
| 22:50:00 | EXetoC | fowl: it's in fowltek |
| 22:52:41 | EXetoC | someone said it's not in the spec, so I'll just comment it out and see what happens |
| 22:53:03 | fowl | derelictglu loads gluErrorUnicodeStringEXT on linux, but it seems this is a microsoft specific extension and thus not available on other platforms ... |
| 22:53:44 | BitPuffin | Araq: well now we are back exactly where I started. The result is nil because that's why QualifiedLookup returns |
| 22:53:57 | Araq | BitPuffin: I can imagine |
| 22:54:26 | BitPuffin | Araq: so how can it be semTypeIdent that needs patching and not QualifiedLookup :( |
| 22:55:38 | BitPuffin | is it because it shouldn't do a lookup at all? |
| 22:55:52 | Araq | well semBuiltinFieldAccess doesn't use qualifiedLookup either |
| 22:55:54 | * | BitPuffin is confused, and not because of 1 letter var names :P |
| 22:56:14 | Araq | so yeah you must not perform the lookup too early |
| 22:56:24 | EXetoC | fowl: yeah I found that thread. will add a 'when' block |
| 22:56:47 | EXetoC | it runs, but the window remains blank |
| 22:58:20 | * | OrionPK joined #nimrod |
| 22:58:28 | EXetoC | but then again it barely contains any logic |
| 22:59:25 | BitPuffin | Araq: grepping for various variatons on semBuiltinFieldAccess didn't give any results >.< |
| 22:59:55 | Araq | BitPuffin: the thing you edited before |
| 23:00:40 | BitPuffin | oh |
| 23:00:43 | BitPuffin | lol :p |
| 23:01:06 | BitPuffin | Araq: you mean except for 6 lines in |
| 23:01:14 | BitPuffin | it doesn't use qualifiedLookup |
| 23:01:38 | Araq | yeah |
| 23:02:00 | fowl | EXetoC, that is probably a 1:1 translation of some bullet demo |
| 23:02:05 | fowl | EXetoC, not sure if it ever worked |
| 23:02:43 | * | freezerburnv quit (Quit: freezerburnv) |
| 23:04:04 | fowl | EXetoC, if you make any changes to glu.nim please do the same for the babel pkg at github/nimrod-code/opengl |
| 23:04:35 | Araq | in fact you should only make changes to the babel package, right? |
| 23:04:46 | fowl | i would say so |
| 23:05:03 | fowl | and delete those wrappers from stdlib |
| 23:06:26 | Araq | yup |
| 23:07:25 | BitPuffin | Araq: ah maybe I've got it |
| 23:09:25 | BitPuffin | well okay it's like the 73rd time I said that today |
| 23:10:26 | * | enurlyx quit (Quit: Nettalk6 - www.ntalk.de) |
| 23:11:11 | BitPuffin | at least i added this to the start of the proc elif n.kind == nkDotExpr: |
| 23:12:27 | gradha | good night |
| 23:12:37 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=n7pXRdkdJxI again) |
| 23:22:31 | BitPuffin | not quite sure where to go from there :p |
| 23:22:37 | BitPuffin | guess I can figure that out tomorrow |
| 23:22:40 | * | fredmorcos joined #nimrod |
| 23:25:54 | BitPuffin | goodnight! |
| 23:26:05 | NimBot | Araq/Nimrod vm2 9447cc6 Araq [+0 ±6 -0]: VM now supports lambda lifting |
| 23:26:05 | NimBot | Araq/Nimrod vm2 bd74576 Araq [+0 ±5 -0]: tcnstseq works again |
| 23:26:33 | Araq | same here, good night |
| 23:30:33 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 23:33:28 | MFlamer | goodnight guys |
| 23:42:04 | * | xenagi joined #nimrod |