| 02:09:15 | * | q66 quit (Remote host closed the connection) |
| 04:16:10 | * | OrionPK quit (Quit: Leaving) |
| 05:51:09 | * | fowl joined #nimrod |
| 07:08:17 | * | xcombelle joined #nimrod |
| 08:25:21 | * | avarus joined #nimrod |
| 08:25:23 | avarus | hi |
| 08:36:15 | fowl | avarus: hey |
| 09:34:24 | * | fowl quit (Quit: Leaving) |
| 10:05:00 | * | fowl joined #nimrod |
| 10:40:01 | * | q66 joined #nimrod |
| 10:55:19 | Araq | hi avarus |
| 11:01:05 | avarus | hi fowl Araq |
| 11:02:33 | * | zahary quit (Ping timeout: 240 seconds) |
| 11:07:50 | * | zahary joined #nimrod |
| 11:11:50 | Araq | ping reactormonk |
| 11:12:08 | Araq | TimeInfoToTime calls getTime() for the JS target ... |
| 11:12:34 | Araq | this is pretty bad ... as TimeInfoToTime shouldn't have any effects |
| 11:18:36 | Araq | oh well I fixed it :P |
| 11:33:06 | * | Amrykid quit (Ping timeout: 264 seconds) |
| 11:37:41 | * | Amrykid joined #nimrod |
| 11:40:47 | * | gradha joined #nimrod |
| 11:49:45 | * | avarus quit (Remote host closed the connection) |
| 11:50:58 | gradha | is there any way to redirect the output of a process started with osproc.startProcess to a memory buffer or a temporary file? |
| 11:51:33 | Araq | yeah the output can wrapped into a stream |
| 11:51:36 | gradha | execProcesses removes poParentStreams on posix so I guess rewriting it myself won't help |
| 11:52:03 | Araq | fixing it would help ;-) |
| 11:52:12 | gradha | oh, is it possible? |
| 11:52:21 | Araq | sure |
| 11:52:28 | Araq | I suck at posix |
| 11:52:34 | Araq | so I disabled it |
| 11:53:16 | gradha | is there any test case which demonstrates the problem on posix? |
| 11:53:37 | Araq | I don't think so |
| 11:53:58 | Araq | however execProcesses also hangs when I enable C++ mode for the compiler |
| 11:54:19 | Araq | g++ doesn't like the generated C++ anymore and so fails |
| 11:54:38 | Araq | however, since lots of processes fail ... execProcesses hangs and I dunno why |
| 11:55:12 | Araq | unix's process redirection api is absurd crap |
| 11:55:23 | gradha | let's say I run two commands, then call outputStream on them, does that somehow fail on unix? I just don't know exactly what or where the problem is |
| 11:55:55 | gradha | hah, which reminds me I should find out first the bug about return values on macosx |
| 11:56:21 | Araq | quite funny given how much the unix people gloat about their | shell stuff |
| 11:57:34 | Araq | gradha: I can't remember the details of the problem |
| 11:58:18 | Araq | I wouldn't touch osproc without some heavy drinking |
| 11:58:42 | gradha | at least I have that covered |
| 12:00:02 | gradha | if I get outputStream() from a process will atEnd() return true only when the process has finished? |
| 12:00:34 | gradha | or maybe I should call waitForExit on the process then read from outputStream() |
| 12:02:46 | gradha | will copy execCmdEx() |
| 12:43:45 | gradha | crap, on a new mac I can't reproduce https://github.com/Araq/Nimrod/issues/379 |
| 12:45:37 | Araq | good |
| 12:45:39 | Araq | close it then ;-) |
| 12:46:43 | Araq | what about the scoping rules in 'if' btw? do you like them now? ;-) |
| 12:47:50 | gradha | did something change from yesterday? |
| 12:48:02 | Araq | no |
| 12:48:15 | Araq | but you had time to sleep over it :P |
| 12:48:57 | NimBot | Araq/Nimrod 52f6271 Araq [+3 ±7 -2]: bugfixes mostly JS related |
| 12:49:28 | gradha | I don't mind the new rules, I just think they are weird because they don't translate to manual expansion |
| 12:49:37 | fowl | i thought re.=~ returned bool |
| 12:49:57 | fowl | (let m = input =~ re"(\w+)=\w+"; m.isMatch): looks like a match object or something? |
| 12:51:39 | Araq | well yeah ... I guess the example should reflect the real world API :P |
| 12:53:48 | Araq | my fear is that it's too confusing when you swap branches: |
| 12:54:14 | Araq | if (let m = match(); not m.isMatch): |
| 12:54:26 | Araq | echo m[0] # ugh |
| 12:54:32 | Araq | else: |
| 12:54:40 | Araq | # match but 'm' not available? |
| 12:55:11 | fowl | thats bad code |
| 12:55:34 | fowl | if not(text =~ re): .. is better |
| 12:57:16 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 12:58:12 | fowl | that would be bad code anyways |
| 12:58:49 | fowl | if not mytext.match(someRe).isMatch: # you'd be forgetting the match data |
| 13:01:25 | Araq | yeah lets just hope it won't bite us ;-) |
| 13:03:13 | fowl | Araq: this for stdlib --> https://github.com/fowlmouth/nimlibs/blob/master/fowltek/tmaybe.nim |
| 13:04:16 | Araq | TMaybe is a classical NIMN though |
| 13:04:52 | fowl | whats that |
| 13:04:55 | Araq | "not in my Nimrod" ;-) |
| 13:06:46 | fowl | o |
| 13:08:49 | fowl | it makes a nice wrapper for nullable types |
| 13:09:58 | Araq | I prefer the "get with useful default" + "has data" approach |
| 13:10:33 | Araq | getEnv returns "" when the 'key' doesn't exist for a reason |
| 13:26:10 | fowl | yea because there's no TMaybe |
| 13:26:37 | Araq | lol |
| 13:26:54 | Araq | as if I wouldn't have created TMaybe ... |
| 13:27:18 | Araq | anyway I am aware nobody agrees with me and TMaybe is cool and hip and awesome |
| 13:27:33 | Araq | bbl |
| 14:00:27 | * | Roin joined #nimrod |
| 14:00:28 | * | Roin quit (Changing host) |
| 14:00:28 | * | Roin joined #nimrod |
| 14:05:33 | * | Amrykid quit (Changing host) |
| 14:05:33 | * | Amrykid joined #nimrod |
| 14:58:06 | * | Trix[a]r_za is now known as Trixar_za |
| 15:36:18 | dom96 | hi |
| 16:37:47 | * | gradha joined #nimrod |
| 16:38:23 | gradha | hey dom96, http://frictionfreedemocracy.org/ is written in haskell, you should go tell them nimrod is better |
| 16:39:52 | * | dom96 is having a hard time figuring out what this project is |
| 16:40:01 | * | dom96 is of course trying to read as little as possible :P |
| 16:40:24 | gradha | don't they have a video to avoid reading? ah, yes, the video uses text |
| 16:41:19 | dom96 | yeah, I avoided the video. |
| 16:41:30 | dom96 | The thumbnail didn't seem very informative |
| 16:42:11 | dom96 | ok, this video is kinda terrible |
| 16:42:28 | dom96 | And the music sounds retro |
| 16:42:36 | gradha | I'm more worried about the end of http://frictionfreedemocracy.org/software-libs.html where it says "Security will be a big concern and will be considered an orthogonal problem. Standard encryption and security techniques will be used when possible" |
| 16:42:49 | gradha | yeah, security orthogonal my ass |
| 16:44:45 | * | Trixar_za is now known as Trix[a]r_za |
| 16:49:10 | Araq | security done right: http://xkcd.com/1200/ |
| 16:51:44 | gradha | the sad fact about security is that we are still using the same model of 40 years ago and mostly nobody cares |
| 16:51:58 | reactormonk | gradha, not on mobiles |
| 16:52:30 | gradha | the xkcd is about laptops though |
| 16:53:00 | Araq | no it's far worse ... "experts" think the unix model is still appropriate and doesn't need to be improved/replaced |
| 16:53:09 | gradha | wow |
| 16:53:31 | Araq | oh well unix zealots always think that |
| 17:01:26 | gradha | the problem xkcd highlights is that real security is inconvenient: if you put a password for each app you solve the theft problem, at the expense of time wasted typing passwords |
| 17:06:15 | gradha | Araq: do you use "when defined(noBusyWaiting)"? couldn't find it anywhere else |
| 17:09:55 | * | q66_ joined #nimrod |
| 17:10:53 | Araq | gradha: no that's disabled I think |
| 17:12:07 | * | q66 quit (Ping timeout: 256 seconds) |
| 17:12:29 | * | q66_ is now known as q69 |
| 17:14:52 | dom96 | hrm, I think the --out param is broken. |
| 17:15:25 | Araq | it works for everything except setting the .exe's name, dom96 |
| 17:15:54 | dom96 | shouldn't it work for that too? |
| 17:16:58 | Araq | well it has been created for rst2html or something |
| 17:17:17 | Araq | so yeah it should work because it's confusing otherwise :P |
| 17:17:25 | dom96 | indeed |
| 17:17:32 | Araq | but it's not a bug, I simply never implemented it :P |
| 17:17:42 | dom96 | whatever helps you sleep at night :P |
| 17:18:59 | dom96 | is it hard to implement? |
| 17:20:10 | Araq | I don't think so |
| 17:29:15 | gradha | huh, github doesn't seem to allow me to label issues |
| 17:29:25 | * | xcombelle quit (Read error: Connection reset by peer) |
| 17:48:21 | gradha | Araq: on the if thing, will I be able to do "finally: (dbconn.close(); removeFile(dbfilename))"? |
| 17:49:58 | gradha | at the moment I'm writing a nested proc just before the finally and calling that |
| 17:50:10 | dom96 | I think you can do that already |
| 17:50:16 | dom96 | even without the parenthesis |
| 17:51:11 | * | Trixar_zb joined #nimrod |
| 17:51:23 | gradha | the parenthesis version doesn't compile |
| 17:51:36 | gradha | the non-parenthesis version doesn't compile the generated C code |
| 17:51:45 | Araq | lol |
| 17:52:37 | gradha | want a github issue? |
| 17:52:39 | * | Trix[a]r_za quit (*.net *.split) |
| 17:54:19 | Araq | sure |
| 18:08:03 | gradha | ah, interesting, the non parenthesis version works, unless you declare a nested proc before... |
| 18:15:32 | gradha | Araq: you need to do something about Nimrod, it's more fun to report bugs than to write programs in it |
| 18:16:14 | * | Boscop quit (Read error: Connection reset by peer) |
| 18:17:30 | * | Boscop joined #nimrod |
| 18:38:04 | Araq | gradha: these bugs are all mac-only :P |
| 18:38:23 | dom96 | ooh, SFML 2.0 has been released. |
| 18:38:30 | gradha | can't reproduce the closure one? |
| 18:38:43 | Araq | no, I'm kidding |
| 18:38:49 | Araq | haven't looked at it |
| 18:42:32 | gradha | dom96: sounds like you or fowl will wrap that, exams permitting |
| 18:43:17 | dom96 | yeah, it'll most likely be fowl. |
| 18:43:33 | dom96 | I think he already wrapped 2, just needs to update it a bit. |
| 18:57:00 | * | Boscop quit (Read error: Connection reset by peer) |
| 18:57:33 | * | Boscop joined #nimrod |
| 19:19:40 | Araq | gradha: --suggest does include the docstrings now |
| 19:20:54 | gradha | can you make it do the same for --def? |
| 19:21:18 | gradha | hmm... I guess it already does |
| 19:23:01 | gradha | is this recent? I don't remember it happening some weeks ago |
| 19:26:03 | Araq | well it's a few weeks old yeah |
| 19:27:14 | Araq | gradha: has the 'finally' really anything to do with that bug? |
| 19:27:54 | gradha | the nested proc alone is fine, the finally alone is fine, both at the same time generates code which doesn't compile |
| 19:28:06 | gradha | but now I'm investigating another finally mac-only issue... |
| 19:28:21 | Araq | ok ... nice bug ... :-/ |
| 19:31:59 | NimBot | Araq/Nimrod ba244a4 Araq [+0 ±1 -0]: --out works for exes |
| 19:34:22 | dom96 | Araq: Why didn't you put that in master? |
| 19:35:21 | Araq | meh ... I guess I should ... but I want to merge newparser asap |
| 19:36:48 | Araq | but the new scoping for 'if' breaks "keineschweine" ... hmm |
| 19:41:44 | gradha | I think it's the finally statement which does weird things https://github.com/Araq/Nimrod/issues/412 |
| 19:43:08 | Araq | perhaps the removeFile is not part of the finally :P |
| 19:45:15 | Araq | why oh why does the tester " .nim invalid module name: '.nim' no" |
| 19:45:29 | fowl | gradha: oh good catch, i was just looking at sfml's site earlier in the week and wondering why they were taking over a year after releasing that RC :P |
| 19:46:11 | gradha | Araq: AFAIK the code should still work, even if the removeFile() runs first out of the finally block the other sqlite code should work with the open handle on unix (unless sqlite requires the file to be present) |
| 19:46:53 | Araq | well the parsing of ';' is indeed suspicious |
| 19:46:53 | gradha | ah, no, so that's the problem, sqlite doesn't work if the file is removed from under its feet |
| 19:47:08 | Araq | fowl: speaking of bad style ... |
| 19:47:13 | gradha | I guess that may happen because sqlite could try to lock the file |
| 19:47:20 | Araq | if not(filename =~ re"\S+_(\d+)x(\d+)\.\S\S\S"): |
| 19:47:22 | Araq | errors.add "Bad file: "&filename&" must be in format name_WxH.png" |
| 19:47:23 | Araq | return |
| 19:47:25 | Araq | result.framew = strutils.parseInt(matches[0]) |
| 19:47:26 | Araq | result.frameh = strutils.parseInt(matches[1]) |
| 19:47:46 | Araq | --> doesn't work with the new scoping rules :-/ |
| 19:48:09 | fowl | why? you changed `=~`? |
| 19:48:25 | Araq | =~ injects into the current scope |
| 19:48:37 | fowl | oh and the scope changed |
| 19:48:42 | fowl | ok |
| 19:48:42 | Araq | yep |
| 19:48:56 | Araq | not ok |
| 19:49:09 | Araq | I need to revert it |
| 19:49:35 | fowl | i could make it keep working by declaring matches first |
| 19:50:03 | Araq | yeah but the website used to contain an example with =~ |
| 19:50:13 | Araq | so I think it's commonly used |
| 19:50:18 | dom96 | what are you reverting? |
| 19:50:30 | Araq | dom96: the scoping for 'if' statements |
| 19:50:42 | dom96 | you're reverting it all completely? |
| 19:51:25 | dom96 | I think fowl's code shouldn't work to be honest. |
| 19:51:50 | Araq | yeah but we need a transition path I think |
| 19:52:04 | dom96 | and breakage should be expected at the stage nimrod is in |
| 19:52:42 | Araq | hmm ... I promised stability for 0.9.2 |
| 19:52:50 | Araq | and code breakage for 0.9.4 |
| 19:54:10 | dom96 | to who? |
| 19:54:46 | Araq | can't remember |
| 19:54:53 | dom96 | I think it's better to spend time implementing features than to be worrying about transition paths. |
| 19:55:09 | gradha | besides, nobody uses nimrod anyway, who is going to complain? |
| 19:55:40 | Araq | yeah nobody uses it but the few people who do use it write thousands of lines in it ... |
| 19:56:19 | dom96 | so someone does use it! |
| 19:56:27 | Araq | and I hate it if some random github project doesn't compile with the latest nimrod |
| 19:56:33 | dom96 | I thought I was a nobody for a second :\ |
| 19:56:44 | Araq | but doesn't compile with a former version either |
| 19:56:51 | gradha | random github projects, shame on you! |
| 19:57:05 | Araq | because it's been programmed against some git master compiler |
| 19:57:05 | dom96 | however it is still impressive that my oldest nimrod project still compiles |
| 19:57:57 | dom96 | Wouldn't it be better to break code earlier than later? |
| 19:58:13 | dom96 | Remember, with 0.9.2 we are going to start advertising like crazy |
| 19:58:18 | gradha | well, I guess you don't have much simpathy for nimrod not compiling Aporia on mac then |
| 19:58:31 | gradha | mac losers, always third grade citizens |
| 19:58:43 | dom96 | So it might be a better idea to break code now than after we gain a million users (I HAVE HOPE). |
| 19:59:06 | gradha | dom96: my calendar says 2013 is the year of nimrod, keep your hope |
| 19:59:08 | Araq | why break code now when you can have a smooth transition path instead? |
| 20:01:12 | gradha | anyway, isn't fowl the only one using the new if scoping? how much code you need to rewrite fowl? |
| 20:01:35 | fowl | gradha: i doubt im the only one who's used `=~` |
| 20:01:42 | Araq | gradha: the new if scoping breaks =~ somewhat |
| 20:02:05 | dom96 | Araq: What transition path do you propose? |
| 20:02:06 | gradha | ah, sorry, didn't understand that, I thought this was about the if only |
| 20:04:03 | Araq | dom96: document the new 'if' scoping and say that it will come with 0.9.4 and mark =~ as deprecated so people have a chance to update their code |
| 20:04:15 | dom96 | right |
| 20:04:27 | dom96 | so you're not merging newparser? |
| 20:04:59 | Araq | I'll merge it but revert the 'if' scoping |
| 20:05:27 | dom96 | ok, you should make another branch and keep the new 'if' scoping there. |
| 20:05:41 | dom96 | So that it can be easily merged in later perhaps? |
| 20:05:45 | Araq | no need, 'when' ftw |
| 20:08:47 | Araq | but then who knows what the new parser and JS code generator break ... :D |
| 20:10:03 | fowl | are you putting it in as #!newsyn ? |
| 20:10:24 | Araq | no |
| 20:11:41 | Araq | I'll however implement a #!newprec which makes operator precedence based on surrounding whitespace |
| 20:12:02 | Araq | so i+1 * 3 == (i+1) * 3 |
| 20:12:26 | fowl | cool i was just thinking about that last night |
| 20:12:46 | fowl | i + 1 * 3 == (i + 1) * 3? |
| 20:13:00 | Araq | sure |
| 20:13:36 | Araq | the current 10 levels of operator precedence are a bit much and even I can't remember then |
| 20:14:06 | Araq | and recently I wanted a&b | c&d only to find out the precedence is wrong for that |
| 20:14:30 | dom96 | how about you let us set our own precedence :P |
| 20:14:59 | Araq | yeah lets make & for strings prec 10 and & for int prec 2 |
| 20:15:09 | Araq | this way we need to rewrite the AST after type checking |
| 20:15:24 | Araq | very good idea :P |
| 20:15:42 | dom96 | haskell allows it :P |
| 20:15:44 | NimBot | Araq/Nimrod 47935a9 Zahary Karadjov [+1 ±9 -1]: nimrod dump can now produce a machine readable json report... 12 more lines |
| 20:17:23 | Araq | dom96: and haskell needs to do exactly that; I don't think Haskell's more restrictive overloading helps with that |
| 20:18:03 | zahary | setting precedence on the tokens is more easily doable |
| 20:18:39 | Araq | well it's nice to get the prec via merely reading the code |
| 20:18:47 | Araq | no need to look things up |
| 20:18:55 | zahary | btw nimrod.vim now has code for integrating the compiler service. I wrote some notes that may help Aporia and emacs here: |
| 20:18:55 | zahary | https://github.com/zah/nimrod.vim/wiki/Integrating-the-Nimrod-compiler-service-in-IDEs |
| 20:19:25 | dom96 | Does that mean the issues with caas are fixed? |
| 20:19:38 | dom96 | i.e. it failing on multiple commands |
| 20:20:24 | zahary | nope, it's quite broken - starts failing after a couple of commands |
| 20:20:49 | Araq | after the first command in our experience ;-) |
| 20:20:53 | gradha | awww |
| 20:20:58 | dom96 | ^^ |
| 20:21:50 | Araq | however what do we do here: i+1*3 |
| 20:21:58 | Araq | * over + then? |
| 20:22:03 | zahary | sure |
| 20:22:18 | gradha | is + over * now? |
| 20:22:32 | zahary | I've already implemented the horizontal layout for my alternative syntax btw |
| 20:23:03 | Araq | ok what about i + 1 - 3 |
| 20:23:19 | Araq | note that there is 1 space before + but 2 after it |
| 20:23:33 | gradha | oh man, using whitespace like that's really evil, i like it |
| 20:23:42 | Araq | I suppose it's always the max number of spaces that surround the operator? |
| 20:23:55 | dom96 | oh man, I hope this doesn't become common |
| 20:24:18 | zahary | it won't, but you can cap it to 0 or 1 if you want |
| 20:24:22 | dom96 | I don't want to have to count spaces more than I already do :P |
| 20:25:05 | Araq | gradha: currently * is over + like in math |
| 20:25:19 | gradha | yes, I missed the spaces thing |
| 20:26:06 | Araq | we can also make $ a prefix operator in 'echo $x' then |
| 20:26:14 | gradha | hmm... I wonder if there's an unicode character which looks like space but is not space, that would be even more confusing |
| 20:26:40 | Araq | gradha: sure there is but nimrod doesn't allow it as whitespace |
| 20:26:53 | Araq | heck it doesn't even allow tabs :P |
| 20:28:29 | gradha | you could use it for dynamic operator level changing magic => hilarity |
| 20:28:39 | Araq | what to do with keyword operators: if x and b == 0: # bitwise 'and'? |
| 20:28:43 | dom96 | I for one vote to use the Bell Character. |
| 20:29:39 | gradha | your use of caps makes me think of Graham Bell |
| 20:30:14 | Araq | I think we should touch keyword operator precedence |
| 20:30:17 | Araq | *shouldn't |
| 20:31:37 | dom96 | We can compile multiple files on this now! http://www.compileonline.com/compile_nimrod_online.php |
| 20:32:14 | Araq | oh wow they updated to 0.9.0 |
| 20:32:39 | gradha | maybe the author lurks in irc/forums? |
| 20:33:01 | * | exhu joined #nimrod |
| 20:33:06 | Araq | you know ... we also have a proper website ... |
| 20:33:41 | gradha | it lacks unicorns though |
| 20:33:57 | gradha | maybe it should feature ponies as a transition path to awesomeness |
| 20:34:02 | dom96 | and kpop music in the background. |
| 20:34:06 | exhu | hi guys! |
| 20:34:09 | Araq | which reminds me ... we in fact have a new design that we should use for release of 0.9.2 |
| 20:34:12 | dom96 | hey exhu! |
| 20:34:14 | exhu | "so i+1 * 3 == (i+1) * 3" makes me sick |
| 20:34:17 | dom96 | Araq: Yep |
| 20:34:24 | dom96 | Araq: That's why I was talking about advertisement. |
| 20:35:02 | Araq | exhu: for math perhaps but what about my example with & and | |
| 20:35:37 | gradha | Araq: http://nimrod-code.org doesn't have RSS, that's really substandard, want one? |
| 20:35:38 | exhu | Araq, i'm just whining, i always prefer () to make it certain which one to be calculated first... |
| 20:36:03 | Araq | gradha: sure |
| 20:36:43 | gradha | also, if you update the design, please make the sunset horizontal, my right side of the monitor keeps filling with water |
| 20:37:44 | Araq | the new design has no sunset |
| 20:38:10 | exhu | nimrod is too early to advertise, it's very frustrating that every time I get time to work on developing a macro I stumble on compiler crash or error or not supported feature and then have to postpone for a week or so. |
| 20:39:56 | Araq | exhu: that's frustrating to hear :-/ |
| 20:40:16 | Araq | but thanks for your honesty |
| 20:40:36 | Araq | do you still report the compiler bugs? |
| 20:40:53 | Araq | or is it that bad you don't even bother anymore |
| 20:41:09 | exhu | Araq, yes, i've created an issue minutes ago. |
| 20:43:24 | exhu | Araq, i'm almost to give up using macros, because i want to finish the project. Maybe i implement it without macro and a year later come back to refactor, don't know. But not abandoning nimrod. |
| 20:44:38 | fowl | exhu: i can take a look at your macro if you'd like |
| 20:45:17 | exhu | it's not urgent, i'm not back to programming today |
| 20:46:29 | exhu | fowl, thanks, i think it's a one-line fix, but it's not urgent |
| 20:46:32 | gradha | dom96: the music can be done, http://crayonpop.tistory.com/344 has an example but it seems to be down for maintenance at the moment |
| 20:47:45 | exhu | Araq, does the newparser address some possible macro issues, improves on this side, or it's not related? |
| 20:47:56 | gradha | music in the background is really bad, just like the blink tag, it's a shame blinky is going to get murdered soon http://pragprog.com/magazines/2013-05/shady-illuminations |
| 20:48:00 | Araq | not related |
| 20:48:59 | Araq | I'm working on a luajit backend to replace the AST evaluator for macros but that's highly experimental and I don't know if that will work out |
| 20:49:42 | exhu | Araq, luajit backend in nimrod compiler? sounds like rocket science :) |
| 20:50:07 | Araq | luajit makes for a decent C JIT too |
| 20:50:23 | Araq | and is easier to get to work on windows than libffi |
| 20:50:39 | Araq | and people expect a proper REPL |
| 20:51:16 | gradha | how is luajit a C JIT? you mean writing lua code like C for it? |
| 20:51:20 | exhu | Araq, REPL = interactive shell? |
| 20:51:27 | Araq | exhu: yeah |
| 20:51:56 | Araq | gradha: luajit supports all C datatypes and calling conventions etc. |
| 20:52:06 | dom96 | I will not be happy until NimBot can have a Nimrod repl built in. |
| 20:52:29 | dom96 | So I welcome luajit kindly. |
| 20:52:53 | exhu | luajit is cool, i've played once with it, allows to construct efficient C structs from lua. |
| 20:54:04 | Araq | in a way a nimrod compiler relying on luajit is a confession of failure ... ;-) |
| 20:54:20 | exhu | but i think you put into nimrod too much, it's too ambitious. |
| 20:55:47 | gradha | next think you know you will be implementing an llvm backend |
| 20:56:08 | exhu | people go away from c++ for a better statically compiled language in the first place |
| 20:56:22 | dom96 | gradha: Already been done :P |
| 20:57:12 | gradha | sorry, I meant jvm/clr as stated in http://nimrod-code.org/question.html |
| 20:57:55 | exhu | gradha, oh no, jvm and clr have already a lot of languages |
| 20:58:59 | Araq | exhu: and yet the problems with the old evaluation engine are quite severe IMO |
| 21:08:54 | Araq | my plan was to integrate the luajit stuff into the JS codegen as these languages are very similar ... but it turns out they are only similar when it comes to control flow for our purposes |
| 21:14:26 | gradha | let's say I use startProcess and want to read the output, do I have to keep reading lines manually because the output could fill some bufferand "hang" the process preventing it from continuing? |
| 21:14:59 | Araq | gradha: that is correct it's incredibly prone to deadlocks |
| 21:16:33 | fowl | dom96: there are 2 PRs on nimrod-code/packages |
| 21:16:41 | gradha | would it be possible to redirect the stdout to a file so I don't have to care about the buffering issue and later read the file back? |
| 21:18:09 | Araq | "Write programs that do one thing and do it well. Write programs to work together." |
| 21:19:21 | gradha | so no? |
| 21:19:43 | dom96 | fowl: oh yeah, thanks for the reminder. |
| 21:20:02 | Araq | osproc has some convenient proc that captures all output in a string for you but I think that's not what you want, gradha |
| 21:20:33 | gradha | only if it can run in the background |
| 21:20:56 | Araq | no ... |
| 21:21:02 | gradha | let me try... dom96 there are 4 PR on minrod-code/nimforum |
| 21:21:05 | fowl | exhu: are you using defDataset: to wrap a type declaration exclusively |
| 21:21:45 | gradha | Araq: I guess I'll write a polling on the output streams readling lines every 50 ms like the execProcesses then |
| 21:22:06 | Araq | so you fix my bugs by repeating them? |
| 21:22:57 | gradha | I'm not fixing anything now, just trying to run idetools in parallel and capture the output |
| 21:23:19 | * | dom96 dies |
| 21:23:22 | fowl | exhu: if so i recommend just passing it the name of the type and a tuple holding the data, it is a lot easier than expecting the first thing in the stmt list to be a type section |
| 21:23:36 | gradha | is there any way to react to output from those processes and automatically "wake up" select-like? |
| 21:23:40 | dom96 | Also ugh, I think the compiler handles adding the paths in .babel/ incorrectly. |
| 21:24:18 | Araq | I'm quite sure it handles them the way we agreed on :P |
| 21:24:37 | gradha | dom96: there you go, http://crayonpop.tistory.com/344 is up with awesome background music |
| 21:24:46 | dom96 | I wish we documented the agreed way somewhere... :P |
| 21:25:22 | dom96 | gradha: omg we need this |
| 21:25:59 | gradha | dom96: TBH I prefer listening to Microsoft's bing soundtrack http://www.youtube.com/watch?v=eo82koP4sDk |
| 21:27:11 | dom96 | gradha: you can use osproc.select |
| 21:27:17 | dom96 | But it's not supported on Windows |
| 21:27:22 | dom96 | and will likely be deprecated. |
| 21:27:38 | gradha | hmmm... deprecated because it's not crossplatform or because it's somehow bad? |
| 21:28:08 | dom96 | The former. |
| 21:28:15 | dom96 | It works fine on Linux IIRC |
| 21:28:43 | dom96 | Some sort of alternative will be provided though. |
| 21:28:49 | gradha | interesting |
| 21:28:51 | dom96 | Once I implement the new async stuff. |
| 21:29:14 | gradha | polling ftw |
| 21:30:33 | dom96 | gradha: It's easy and quick to use for small projects. But in most cases you want what asyncio provides. |
| 21:31:13 | gradha | does asyncio work on processes? |
| 21:31:26 | gradha | I thought that's for sockets and network stuff |
| 21:31:26 | dom96 | nope |
| 21:31:45 | dom96 | It's meant for anything that supports a select-like proc. |
| 21:33:17 | gradha | so how do you convert a PProcess to a PAsyncSocket? |
| 21:33:37 | dom96 | you don't |
| 21:34:13 | dom96 | lol, are you reading "Note: If you want to provide async ability to your module please do not use the TDelegate object, instead use PAsyncSocket. It is possible that in the future this type's fields will not be exported therefore breaking your code." ? |
| 21:34:19 | dom96 | That's a tad misleading. |
| 21:34:57 | * | exhu quit (Quit: Ex-Chat) |
| 21:35:13 | dom96 | I still have not tackled support for anything other than sockets though. |
| 21:36:05 | dom96 | best to use select for now |
| 21:36:36 | dom96 | And if you want windows support then use threads. |
| 21:37:09 | gradha | I'll first try my luck with idetools returning less chars than the pipe buffer |
| 21:39:19 | Araq | good luck with that idetools produces lots of output |
| 21:39:40 | gradha | especially now that docstrings are included |
| 21:48:00 | dom96 | Araq: Didn't we discuss that only top-level directories should be added to the path? |
| 21:49:23 | Araq | did we? |
| 21:49:35 | Araq | what about mypackage/src/*.nim ? |
| 21:50:08 | dom96 | I dunno, but currently every module is shoved into the path. |
| 21:50:20 | dom96 | And I don't like it. |
| 21:50:33 | dom96 | mypackage/src/*.nim can be solved with a .babel option |
| 21:51:44 | Araq | oh really? and since when does the compiler process .babel options? |
| 21:52:56 | dom96 | What I mean is, if the package structure on the git repo is: mypackage/src/*.nim |
| 21:53:09 | dom96 | You can tell babel to install everything in src as if it was in / |
| 21:53:16 | dom96 | if that's not your worry then: |
| 21:53:34 | dom96 | it can be imported with import src/*.nim |
| 21:54:22 | Araq | hmm I remember making it process 2 levels instead of 1 |
| 21:54:31 | Araq | I don't think it adds everything recursively |
| 21:54:40 | dom96 | hrm, you're right. |
| 21:54:43 | dom96 | But why? |
| 21:54:54 | Araq | for the package/src/*.nim reason |
| 21:55:18 | dom96 | What about my solution? |
| 21:55:34 | Araq | requires yet another thing to configure for the poor package creator |
| 21:56:13 | dom96 | well we could just tell people to create 'package/package/source here' |
| 21:56:26 | dom96 | But come on |
| 21:56:54 | dom96 | babel is not a magician, it needs some guidance as to how to install things. |
| 21:57:28 | gradha | awww |
| 21:58:39 | dom96 | But like I keep saying, we simply need to figure out precisely how babel should work once and for all, once we are happy with the design we should stick to it. |
| 21:58:57 | dom96 | But I bet we will hit problems along the way anyway. |
| 21:59:32 | Araq | we could also special case 'private' instead so that the compiler wouldn't add that |
| 21:59:42 | Araq | which seems to be what you're after anyway |
| 22:00:14 | dom96 | huh? |
| 22:00:37 | Araq | a dir named 'private' is not included in search path |
| 22:00:58 | dom96 | I want to be able to choose between letting users import my package with "import package" (as in jester's case) or "import package/module" |
| 22:01:09 | dom96 | a 'private' dir is a whole other issue |
| 22:01:27 | * | OrionPK joined #nimrod |
| 22:01:40 | Araq | what if I don't want to import it as "package/module"? |
| 22:01:56 | dom96 | tough luck. |
| 22:06:23 | dom96 | Packages with multiple modules simply need this. |
| 22:06:35 | Araq | need what? |
| 22:06:53 | dom96 | A namespace if you can call it that. |
| 22:10:23 | Araq | and you get that by not include package/ in the search path? |
| 22:10:31 | Araq | *including |
| 22:11:54 | Araq | in fact I expect package/src/*.nim to be more common than only package/*.nim |
| 22:12:02 | Araq | because people like to include docs etc. as well |
| 22:13:05 | Araq | we could perhaps standardize on a package directory layout but then I dislike these things |
| 22:13:53 | Araq | not to mention the guys who use package/package ... |
| 22:14:31 | dom96 | Yeah, with the current way it works we will get package/package |
| 22:14:39 | dom96 | I don't want that. |
| 22:14:51 | Araq | package/package is everywhere anyway |
| 22:15:24 | Araq | my python source code folder has a "python" subdir |
| 22:16:19 | gradha | dom96: for your pleasure http://gradha.github.io/genieos/, see https://github.com/gradha/genieos/commit/1f7cef04c42b08abffdc26e2c0f0318225b7790a and http://scmplayer.net, looks like raping everybody's ears is simply a javascript away |
| 22:17:33 | dom96 | gradha: I love it. |
| 22:17:54 | Araq | (which doesn't contain the actual python implementation o.o ) |
| 22:18:04 | dom96 | Araq: I want this to be enforced. |
| 22:18:18 | dom96 | If you have a package with more than 1 public module |
| 22:18:28 | dom96 | You need to enclose it in a 'package' folder. |
| 22:18:58 | Araq | but then you get packaga/package? hu? |
| 22:19:06 | dom96 | yes, and that is the problem. |
| 22:19:17 | Araq | (oh well it contains the compiler part of python) |
| 22:19:35 | Araq | well what do you want to enforce then? |
| 22:19:58 | dom96 | I just said what I want to enforce. |
| 22:19:58 | Araq | and I think it stops if the top level directory contains a .nim file but I could be wrong |
| 22:20:12 | gradha | dom96: it's more than awesome, if you click a link (eg. documentation) the player follows through, like black magic |
| 22:20:29 | dom96 | gradha: :O |
| 22:21:14 | gradha | imagine google doing that for their web page, suddenly millions crying in horror as they silence their speakers... |
| 22:22:05 | Araq | dom96: I don't get what you want to enforce then |
| 22:24:31 | dom96 | We need some sort of convention on how a babel package's directory should be structured. |
| 22:24:39 | dom96 | The two scenarios that I see is the ones I mentioned. |
| 22:25:23 | Araq | actually reading the code ... I think it's excellent :P |
| 22:25:34 | dom96 | More than one module: the modules should be imported using the "import package/module" syntax |
| 22:25:46 | dom96 | One module: "import module" |
| 22:25:49 | Araq | well here is what the code does: |
| 22:26:53 | Araq | if there is a '.nim' file in the current directory this is the directory, no subdirectories are added |
| 22:27:12 | Araq | otherwise it searches the subdirs but not recursively |
| 22:27:32 | Araq | so it will get that jester/ is a subdir since you have a jester.nim |
| 22:27:45 | Araq | and it will add package/src since there is no .nim in package/ |
| 22:29:58 | dom96 | what do you mean "it will get that jester/ is a subdir"? |
| 22:30:31 | Araq | well say if you have jester-1.0/jester.nim |
| 22:30:42 | Araq | well say if you have jester-1.0/jester/moduleA.nim |
| 22:30:51 | Araq | jester-1.0/jester/moduleB.nim |
| 22:31:17 | Araq | then the jester.nim in the package dir means that this is the "main directory" |
| 22:31:37 | Araq | and you need to import other modules as "jester/moduleA.nim" |
| 22:31:54 | Araq | however, if you have the following layout: |
| 22:32:04 | Araq | jester-1.0/docs/readme.txt |
| 22:32:13 | Araq | jester-1.0/src/jester.nim |
| 22:32:21 | Araq | jester-1.0/src/moduleA.nim |
| 22:32:25 | Araq | jester-1.0/src/moduleB.nim |
| 22:32:33 | Araq | then 'src' is the main directory |
| 22:33:01 | Araq | because there is no jester-1.0/*.nim file |
| 22:33:25 | Araq | but there are *.nim files in src |
| 22:33:50 | dom96 | ok, well this doesn't work for the case when you want import "package/module" |
| 22:33:58 | dom96 | You have to add a dummy .nim file |
| 22:34:25 | Araq | please elaborate on the supposed directory structure |
| 22:35:04 | dom96 | https://github.com/fowlmouth/nimlibs |
| 22:36:22 | NimBot | Araq/Nimrod 3ac912e Araq [+2 ±6 -0]: revert new scope for 'if' |
| 22:37:27 | Araq | dom96: true but then I don't want to import "fowltek/fann" ... or maybe I do ... hm |
| 22:38:07 | dom96 | fowl has a lot of modules |
| 22:38:21 | Araq | well what's the package name? nimlibs or fowltek ? |
| 22:38:28 | dom96 | fowltek. |
| 22:39:17 | Araq | ping fowl |
| 22:45:20 | Araq | dom96: well what's the alternative? just use the name from "package.babel" as the main directory? |
| 22:46:26 | fowl | hi |
| 22:47:09 | fowl | i namespaced them in fowltek/ so it didnt clash with anyones modules and you have to say my name when importing them |
| 22:47:45 | Araq | so dom96 is right and you do like import fowltek/stuff.nim |
| 22:47:55 | fowl | yes |
| 22:48:05 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 22:49:46 | Araq | you need to add a dummy.nim then to your toplevel dir :P |
| 22:49:53 | Araq | nah, just kidding |
| 22:51:15 | Araq | dom96: very well then, I'll make it simply add the package directory then |
| 22:52:43 | dom96 | ok |
| 22:53:43 | Araq | dom96: in fact you should do it |
| 22:54:10 | Araq | edit compiler/babelcmd.nim and replace line 86 with |
| 22:54:29 | Araq | addBabelPath(p, info) |
| 22:58:13 | dom96 | ok |
| 23:02:58 | * | q69 quit (Remote host closed the connection) |
| 23:06:58 | dom96 | cool, it works. |
| 23:09:59 | Araq | push it then |
| 23:13:39 | NimBot | Araq/Nimrod 5dd397e Dominik Picheta [+0 ±1 -0]: Changed babel path handling. |
| 23:54:59 | NimBot | Araq/Nimrod aa4699a Araq [+0 ±1 -0]: pegs compiles again |