00:17:15 | gradha | hmm... is proc write*(f: TFile; i: int) big endian or little endian? |
00:18:52 | EXetoC | native endian? |
00:20:53 | gradha | ouch, the implementation is "fprintf(f, "%ld", i)" |
00:22:14 | gradha | pretty hard to provide a read method for that |
00:32:18 | EXetoC | what do you mean? |
00:34:06 | gradha | the proc saves a string of the integer rather than the four bytes of memory it uses, can't use it for my I/O purposes |
00:36:41 | EXetoC | oh |
00:43:47 | * | NewGuy quit (Ping timeout: 250 seconds) |
00:44:10 | * | OrionPK quit (Ping timeout: 245 seconds) |
00:44:13 | dom96 | gah, almost 2am already |
00:44:28 | gradha | good night |
00:44:32 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=1ZZC82dgJr8 again) |
00:46:48 | EXetoC | ya >.> |
00:47:10 | * | mal`` quit (Ping timeout: 256 seconds) |
00:48:15 | * | mal`` joined #nimrod |
01:06:12 | dom96 | good night |
01:08:43 | * | OrionPK joined #nimrod |
01:14:23 | * | NewGuy joined #nimrod |
01:25:03 | * | rubino123 joined #nimrod |
01:27:54 | * | q66 quit (Quit: Leaving) |
01:47:47 | * | DAddYE quit (Remote host closed the connection) |
02:28:19 | * | Associat0r joined #nimrod |
02:28:30 | * | Associat0r quit (Changing host) |
02:28:30 | * | Associat0r joined #nimrod |
02:40:58 | * | Boscop is now known as Boscop_ |
02:41:13 | * | Boscop_ is now known as Boscop2 |
02:49:05 | * | DAddYE joined #nimrod |
02:49:37 | EXetoC | finally some text is rendered. thank god for astToStr debugging :> |
02:53:10 | EXetoC | it's very useful, if wrapped |
02:53:19 | EXetoC | cya |
02:53:20 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
02:55:26 | * | DAddYE quit (Ping timeout: 240 seconds) |
03:12:55 | * | Associat0r quit (Quit: Associat0r) |
03:17:49 | * | NewGuy quit (Quit: Page closed) |
03:19:47 | * | DAddYE joined #nimrod |
03:54:16 | * | OrionPK quit (Quit: Leaving) |
04:01:54 | * | Endeg quit (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
04:05:07 | * | rubino123 quit (Ping timeout: 246 seconds) |
04:09:53 | * | NewGuy joined #nimrod |
04:10:15 | NewGuy | When using threads + realtime GC |
04:11:18 | NewGuy | Will a GC_Step & GC_SetMaxTime influence the GC for both threads? |
04:11:35 | NewGuy | Or must I set the time and call the GC for each individual thread? |
05:10:29 | * | xilo quit (Ping timeout: 248 seconds) |
06:30:27 | * | NewGuy quit (Ping timeout: 250 seconds) |
08:08:44 | * | DAddYE quit (Remote host closed the connection) |
08:09:15 | * | DAddYE joined #nimrod |
08:13:26 | * | DAddYE quit (Ping timeout: 240 seconds) |
08:43:13 | * | q66 joined #nimrod |
09:16:48 | * | BitPuffin joined #nimrod |
09:21:38 | * | BitPuffin quit (Read error: Connection reset by peer) |
09:23:49 | * | BitPuffin joined #nimrod |
09:27:16 | * | BitPuffin quit (Remote host closed the connection) |
09:30:55 | * | BitPuffin joined #nimrod |
09:31:57 | * | BitPuffin quit (Read error: Connection reset by peer) |
09:34:13 | * | BitPuffin joined #nimrod |
09:35:34 | * | Associat0r joined #nimrod |
09:35:35 | * | Associat0r quit (Changing host) |
09:35:35 | * | Associat0r joined #nimrod |
10:35:59 | * | EXetoC joined #nimrod |
10:44:43 | * | BitPuffin_ joined #nimrod |
10:46:41 | * | Araq_ joined #nimrod |
11:07:11 | * | Endeg joined #nimrod |
11:28:25 | BitPuffin | Araq_: How is the competitive concurrency going? :) |
11:30:08 | Araq_ | dunno. not too bad I guess |
11:30:50 | BitPuffin | good! |
11:30:54 | BitPuffin | can't wait to learn more about it |
11:46:35 | dom96 | hello |
11:53:10 | BitPuffin | hey dom96! |
11:57:25 | dom96 | sup? |
11:57:53 | BitPuffin | dom96: reading some 3d math literatture, you? |
11:58:12 | dom96 | updating my system |
11:58:33 | BitPuffin | what system do you use? |
11:58:38 | dom96 | arch linux |
11:58:58 | BitPuffin | score! |
11:59:17 | BitPuffin | are you the maintainer of the AUR packages? |
11:59:25 | dom96 | some of them |
11:59:26 | BitPuffin | because they desparately need to use --depth 1 |
11:59:30 | BitPuffin | nimrod-git |
11:59:56 | BitPuffin | woop |
11:59:58 | BitPuffin | new firefox |
12:00:08 | dom96 | "I updated it as you asked, but as for git --depth 1, I don't know how to override the way Pacman executes git. If you know, please let me know so I can update it again " |
12:00:13 | dom96 | Schala maintains it |
12:00:27 | BitPuffin | yeah I read that |
12:00:34 | BitPuffin | there is probably some way though |
12:01:35 | dom96 | btw, vote for the nimrod packages if you haven't already :P |
12:01:53 | BitPuffin | aah |
12:01:58 | BitPuffin | why yes |
12:02:15 | BitPuffin | do I need a separate account for AUR or does the forum account work? |
12:02:28 | dom96 | no idea |
12:02:32 | dom96 | can't remember |
12:02:36 | nihathrael | 4it used to be two separate accounts |
12:02:49 | EXetoC | I should do that. gonna install aurvote again too |
12:03:17 | dom96 | oh hey nihathrael. Made any progress with Aporia? |
12:04:06 | nihathrael | dom96: not yet unfortunately, I'm a little short on time due to my master's thesis |
12:04:27 | dom96 | nihathrael: ahh, that's understandable. I hope that's going well for you :) |
12:04:40 | nihathrael | yea, doing fine |
12:04:53 | nihathrael | but I definitely want to look into it at some point |
12:05:32 | dom96 | cool |
12:06:10 | nihathrael | I have some code that uses the CAAS stuff |
12:06:13 | nihathrael | but it is still buggy |
12:08:16 | nihathrael | https://github.com/nihathrael/Aporia/tree/caas |
12:08:39 | nihathrael | It needs to compile stuff first, which messes with the output sometimes and makes it quite slow |
12:09:35 | BitPuffin | hrm |
12:09:46 | BitPuffin | backend email servers undergoing maintainence |
12:09:49 | dom96 | interesting usage of {.global.} |
12:09:49 | zahary_ | dom96, you have commit object files in the sources repository by accident. I'll force push a new initial revision without them |
12:10:13 | dom96 | zahary_: huh, i'm not sure what you mean? |
12:10:25 | nihathrael | I shamelessly copied that from someone else here, can't quite recall who it was |
12:10:46 | dom96 | nihathrael: it should really be in the MainWin object, since that is the ultimate global state object heh. |
12:11:41 | nihathrael | true |
12:11:49 | nihathrael | it is still very "raw" |
12:11:52 | zahary_ | dom96, there are binary .o files in some of the sub-directories |
12:12:03 | dom96 | zahary_: where? |
12:12:05 | nihathrael | it will need a lot of love until it is really usable |
12:12:13 | zahary_ | e.g. in 2_2 |
12:12:25 | dom96 | oh, I see. In the csources. |
12:12:49 | dom96 | Alright, go ahead. |
12:13:03 | dom96 | Perhaps add a .gitignore with *.o too if you can. |
12:14:09 | dom96 | nihathrael: I may finish it off since I have quite a bit of time over the summer. But then again I have other things to finish too. |
12:14:38 | nihathrael | dom96: sure if you find some time, feel free to use (or not use) any of the code to finish it |
12:14:54 | dom96 | will do, thanks. |
12:15:18 | nihathrael | the faster it is finished, the better |
12:15:34 | NimBot | nimrod-code/csources master d26b821 Zahary Karadjov [+1 ±0 -97]: Latest sources as of 7th August 2013 |
12:15:41 | nihathrael | if it works properly, I think it will be major step up for aporia |
12:15:44 | dom96 | yeah, and my todo is still huge. |
12:16:20 | dom96 | yeah, CAAS support is a very important feature. |
12:17:11 | BitPuffin | new firefox logo |
12:17:21 | nihathrael | have you ever thought about creating an eclipse plugin instead of a completely new ide? |
12:17:40 | dom96 | no, but I dislike eclipse. |
12:17:56 | nihathrael | I kind of defeats the purpose of doing something in nimrod though lol |
12:18:03 | BitPuffin | isn't it better to just focus on integrating full support for nimrod in YCM? |
12:18:19 | BitPuffin | like so that you compile it like you do with --clang-completer |
12:18:24 | dom96 | YCM? |
12:18:31 | BitPuffin | YouCompleteMe |
12:18:35 | BitPuffin | Vim plugin |
12:18:52 | dom96 | I dislike vim too :P |
12:18:59 | nihathrael | please don't get me wrong, vim is great, but it is not an ide |
12:20:01 | dom96 | we simply need a vim mode in Aporia and all will be fine |
12:20:12 | nihathrael | hehe, yea that would be great |
12:20:25 | BitPuffin | nihathrael: it can be |
12:20:49 | BitPuffin | nihathrael: I could use C++ awesomely with YCM (or actually clang-completer but YCM is better) |
12:22:00 | nihathrael | yea it can be, if investing tons of time into configuring and installing the correct plugins |
12:22:17 | BitPuffin | no not tons of time at all |
12:22:19 | BitPuffin | YCM |
12:22:29 | BitPuffin | install YCM, done |
12:22:45 | BitPuffin | doesn't take much time at all |
12:22:52 | nihathrael | yea, but you need type hierarchies, method call lookup, full project search, refactorings, etc |
12:23:04 | nihathrael | for it to be an ide, and not an editor with autocompletion |
12:23:18 | BitPuffin | full project search is built in |
12:23:22 | BitPuffin | just use grep |
12:23:23 | BitPuffin | lol |
12:23:32 | BitPuffin | and same for refactoring |
12:23:44 | BitPuffin | :%s/foo/bar/gc |
12:24:02 | BitPuffin | will go through every foo and every bar in the file and ask you to confirm |
12:24:09 | BitPuffin | and you can also do it across multiple files |
12:24:28 | nihathrael | yea, and it will annoy me because it will try to rename stuff that just happens to contain the same string |
12:24:31 | nihathrael | but is actually something different |
12:24:47 | nihathrael | which is all good for 10 file projects, but not for 1000 file projects |
12:25:10 | BitPuffin | well |
12:25:20 | BitPuffin | renaming stuff automatically is always risky |
12:25:23 | nihathrael | also stuff like "press two buttons to extract a method from the highlighgted code" are not that easily done with grep and search and replace |
12:25:51 | BitPuffin | you mean look up its definition? |
12:26:17 | nihathrael | no, mark some code, press a button and it will move the code to a new method + all boilerplate code |
12:26:38 | nihathrael | http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-ExtractMethod.htm |
12:27:20 | nihathrael | also automatic renaming is not risky in a well typed language like c++ or java |
12:27:41 | BitPuffin | Hmm |
12:27:51 | BitPuffin | I've had problems when renaming stuff in Java with eclipse |
12:28:29 | nihathrael | I use it every day and I don't think it has ever gone wrong in the past two years |
12:28:47 | nihathrael | given your code compiles, if it doesn't then of course it can go wrong |
12:30:36 | nihathrael | anyway, I'm not saying that eclipse is perfect, it most certainly isn't, but it does have a ton of features that normal text editors don't, which make it an "IDE" and not a text editor |
12:32:47 | NimBot | nimrod-code/csources master 7040158 Dominik Picheta [+2695 ±0 -0]: Initial Commit |
12:34:33 | BitPuffin | yeah yeah |
12:34:41 | BitPuffin | I guess you are an IDE guy and I'm a text editor guy then :P |
12:35:04 | nihathrael | maybe :) also depends a lot on the project I guess |
12:36:15 | BitPuffin | I like to start with minimums and add stuff as I need it |
12:36:20 | BitPuffin | maybe that's why I use Arch too :) |
12:36:29 | nihathrael | I use arch as well :) |
12:36:43 | BitPuffin | for the same reason? or just to be bleeding edge? |
12:38:18 | nihathrael | mainly because it is very customizable, I don't like bloated stuff like gnome. I'm a lot into using my system efficiently, so I use awesome wm. KEeps the system fast and is really powerful to use and customize |
12:39:22 | nihathrael | you don't get stuff that you don't need with arch, which is great |
12:41:54 | BitPuffin | yep |
12:41:58 | BitPuffin | I've used Awesome too |
12:42:08 | BitPuffin | but on my laptop I run i3 |
12:42:35 | nihathrael | does that come with good dual monitor support? |
12:42:42 | BitPuffin | think so |
12:43:20 | * | BitPuffin_ quit (Ping timeout: 245 seconds) |
12:43:34 | BitPuffin | fairly sure it uses the same libs pretty much |
12:45:14 | nihathrael | when I started using awesom like 4 years ago or so, the only options where xmonad and awesome if you wanted tiling + multiple monitor support |
12:45:37 | BitPuffin | yeah xmonad is nice too |
12:45:42 | nihathrael | yea |
12:45:54 | BitPuffin | I like i3 because how straight forward it is to tile the way you want |
12:46:27 | BitPuffin | http://www.youtube.com/watch?v=Wx0eNaGzAZU |
12:47:32 | BitPuffin | yeah it does multi monitor correctly |
12:48:44 | nihathrael | yea that looks pretty decent |
12:49:31 | nihathrael | I don't tile all that much to be honest anymore. It's mainly one window per workspace and sometimes two terminals |
12:54:13 | BitPuffin | same here |
12:54:35 | BitPuffin | but with this they show up exactly where I want |
12:55:41 | nihathrael | i'd be interested in switching if it handles java guis like jdownloader's gui propely on a mulitmonitor setup |
12:55:57 | BitPuffin | dunno |
12:56:02 | BitPuffin | there is only one way to find out |
12:57:12 | BitPuffin | honestly I think awesome might have been a little better at handling which windows are supposed to be floating etc |
12:57:59 | nihathrael | the awesome guys used to be pretty good at breaking the config files, but it hasn't happened all that often in recent history^^ |
13:07:04 | dom96 | somebody needs to create a WM in Nimrod :P |
13:07:58 | nihathrael | if someone does, that someone best make it work on wayland instead of xorg |
13:08:17 | nihathrael | that'd be good advertisement for the language |
13:09:09 | dom96 | indeed |
13:09:32 | BitPuffin | guys I've been thinking about like for the past days |
13:09:44 | BitPuffin | I think I might when wayland is ready for production |
13:10:18 | EXetoC | and make a high-level wrapper for it :> |
13:10:34 | dom96 | when will that be? in 5 years? :P |
13:10:37 | BitPuffin | for wayland? |
13:10:45 | BitPuffin | dom96: no, probably about next year or so |
13:11:16 | dom96 | I certainly hope so. Xorg is starting to get on my nerves with its idiotic CPU and memory usage. |
13:11:42 | nihathrael | didn't they release v 1.0 a while back? |
13:11:49 | BitPuffin | yeah |
13:11:52 | BitPuffin | for the protocol |
13:11:56 | BitPuffin | the protocol is at 1.2 |
13:11:58 | BitPuffin | it's got a stable api |
13:12:06 | BitPuffin | just that it's not ready to use as a display server yet |
13:12:16 | BitPuffin | well it is but not in terms of drivers |
13:12:24 | dom96 | You should start dev asap then. |
13:12:34 | dom96 | Since the API won't change. |
13:12:39 | dom96 | It makes sense IMO |
13:12:46 | BitPuffin | yeah I would |
13:12:50 | BitPuffin | but I'm busy :P |
13:13:04 | BitPuffin | I'll probably do it when I have a job and a new computer that gets updates for the drivers |
13:13:20 | BitPuffin | my ATI Radeon HD 4850 is not supported by AMD anymore |
13:13:24 | dom96 | BitPuffin: we need to clone you. |
13:13:25 | EXetoC | dom96: it deals with rendering and resource allocation, so that's to be expected |
13:13:35 | EXetoC | is the CPU usage high when idling too? it's not for me |
13:13:36 | BitPuffin | dom96: that would make the world better |
13:13:52 | dom96 | EXetoC: nah, but it is when watching any kind of video. |
13:13:53 | BitPuffin | X11 is actually prett decent in terms of memory and CPU usage |
13:14:01 | BitPuffin | it's more about what a god damn hack it is |
13:14:51 | dom96 | It's currently using 301MB, I guess that's not super bad. |
13:14:52 | EXetoC | dom96: ok, not for me |
13:15:24 | EXetoC | gonna see if I have any HD videos to test with |
13:15:26 | BitPuffin | X11 is probably the worst codebase in open source ever |
13:15:31 | dom96 | Moving windows causes it to use ~30% of my CPU |
13:15:42 | dom96 | oh no wait |
13:15:43 | dom96 | That's cinnamon |
13:15:49 | EXetoC | :> |
13:15:51 | dom96 | Yeah, Cinnamon is stupid too. |
13:16:04 | BitPuffin | If you want a huge desktop KDE is probably the best one |
13:16:15 | BitPuffin | already supports wayland too :) |
13:16:37 | dom96 | meh, I never liked KDE for some reason |
13:16:47 | BitPuffin | bet you haven't tried it recently |
13:17:01 | dom96 | yeah, not really. |
13:17:01 | nihathrael | still loooks like qt, which is the biggest problem :D |
13:17:09 | dom96 | ^^ lol |
13:17:25 | BitPuffin | http://www.jupiterbroadcasting.com/39982/mir-problems-las-s27e08/ I think this episode talks about why X11 needs to be replaced, enjoy :) |
13:18:10 | BitPuffin | nihathrael: meh, GTK+ is dying :D |
13:18:13 | EXetoC | dom96: it's both awesome and X for me. one would think that manipulating windows wouldn't really be that expensive. oh well |
13:18:28 | EXetoC | BitPuffin: any version? |
13:18:48 | BitPuffin | EXetoC: any version? ? |
13:19:04 | EXetoC | nothing |
13:19:15 | BitPuffin | :s |
13:20:14 | dom96 | yeah, the fact GTK+ is dying does not bode well for Aporia. |
13:20:18 | BitPuffin | man I thought I'd get more shit thrown at me for claiming that GTK is dying |
13:20:47 | BitPuffin | not really sure what people mean when they say look like QT either |
13:20:53 | BitPuffin | it can be themed to look like anything |
13:20:57 | dom96 | Watching that video results in 30% CPU usage by X. |
13:21:24 | EXetoC | is it flash? |
13:21:51 | dom96 | I think so. |
13:22:17 | BitPuffin | actually unless you clicked on anything or don't support HTML5 video it should be HTML5 video |
13:22:43 | EXetoC | it's a good idea to find out, because flash is a pile of garbage :> |
13:23:18 | BitPuffin | I can't grasp how some people are making new flash applications these days with a straight face |
13:23:35 | nihathrael | probably many monies |
13:23:38 | EXetoC | it was a pain in the arse on linux when I had my old computer |
13:24:12 | dom96 | that CPU usage does seem pretty low for Flash :P |
13:24:40 | nihathrael | because there is really no other reason to build something in flash. Even then doing it for money still doesn't show a great personality :P |
13:24:41 | BitPuffin | dom96: what browser? |
13:24:45 | dom96 | Firefox |
13:25:00 | BitPuffin | dom96: then you are watching HTML5 video |
13:25:07 | dom96 | Remember those sites that were made entirely in Flash? |
13:25:15 | BitPuffin | try right clicking on the video |
13:25:18 | BitPuffin | dom96: those still exist |
13:25:30 | dom96 | I'm sure they do. |
13:25:42 | BitPuffin | http://sublimevideo.net/ |
13:25:50 | dom96 | well, I got flash going on youtube |
13:26:07 | BitPuffin | yeah |
13:26:08 | dom96 | huh, weird. |
13:26:13 | dom96 | CPU usage is even lower. |
13:26:18 | BitPuffin | the YouTube HTML5 player is not good at all |
13:26:21 | dom96 | I guess the resolution of the video matters |
13:26:23 | BitPuffin | it's their fault though |
13:26:27 | dom96 | It's not bad. |
13:26:37 | dom96 | In fact, the HTML5 youtube player works better for me than the flash one |
13:26:46 | dom96 | Hovering over the volume thingy in the flash version doesn't work |
13:26:47 | BitPuffin | compared to sublimevideo it's very laggy |
13:26:51 | dom96 | Which is very strange |
13:26:54 | BitPuffin | fullscreen is nice with sublime |
13:27:02 | BitPuffin | fullscreen with youtube html5 is unwatchable |
13:27:12 | nihathrael | works fine for me |
13:27:19 | nihathrael | running chrome |
13:27:27 | BitPuffin | hmm |
13:27:31 | BitPuffin | maybe it's flash then lol |
13:27:42 | dom96 | yeah, that sublime video uses 40% |
13:27:47 | dom96 | after switching on HD |
13:27:55 | BitPuffin | well |
13:28:03 | BitPuffin | it makes sense that bigger resolution = more cpu |
13:28:11 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) |
13:28:11 | dom96 | yeah, I guess. |
13:28:13 | EXetoC | it's slow for me in firefox. tested it just now |
13:28:19 | dom96 | Shouldn't GPU handle it though? |
13:28:21 | BitPuffin | EXetoC: youtube html5? |
13:28:29 | EXetoC | yes |
13:28:32 | BitPuffin | dom96: it doesn't |
13:28:41 | EXetoC | screw that then :> |
13:28:48 | dom96 | but shouldn't it? |
13:28:52 | BitPuffin | yeah it should |
13:29:01 | BitPuffin | people should make webgl based players :P |
13:29:02 | dom96 | You know what annoys me most about CInnamon (and most other WMs)? |
13:29:08 | dom96 | That they steal focus when a new window is shown |
13:29:40 | BitPuffin | dom96: on some operating systems and GPU's it might be using GPU |
13:29:57 | EXetoC | it's configurable in awesome, so that's nice |
13:30:23 | dom96 | And VLC makes Cinnamon use 50% |
13:30:25 | dom96 | Nice. |
13:30:32 | BitPuffin | lol what |
13:31:31 | dom96 | wtf |
13:31:45 | dom96 | and VLC is using 185% |
13:31:49 | dom96 | for a higher res video |
13:32:05 | EXetoC | lovely |
13:32:21 | EXetoC | maybe it does something stupid every time a refresh is requested |
13:33:12 | BitPuffin | try MPlayer |
13:33:38 | dom96 | The weird thing is that with proprietary AMD drivers I have to use the X11 video output (XCB) |
13:33:45 | EXetoC | you mentioned having to use weird settings. that might have something to do with it |
13:33:50 | dom96 | All other video outputs result in screwed up video when I resize VLC |
13:34:18 | dom96 | yeah |
13:35:26 | * | dom96 wonders how to turn down the volume in MPlayer |
13:35:53 | dom96 | But MPlayer seems to be working. |
13:35:54 | BitPuffin | man mplayer |
13:36:05 | BitPuffin | rtfm :P |
13:36:17 | dom96 | I'll tell you that the next time you ask me nimrod questions ;) |
13:36:25 | BitPuffin | awh |
13:36:27 | EXetoC | lololol |
13:36:33 | BitPuffin | But I have R'd the FM with nimrod |
13:36:36 | BitPuffin | so that won't work :P |
13:37:05 | dom96 | cool |
13:37:08 | dom96 | it works in VLC too now |
13:37:14 | dom96 | I guess some update fixed it :D |
13:37:34 | dom96 | No longer using 185% of my CPU |
13:37:52 | BitPuffin | anyways I was just trying to point you in the right direction ;_; |
13:38:07 | dom96 | Don't worry. I was kidding. |
13:38:48 | dom96 | I'm too nice to tell people to RTFM :P |
13:39:16 | dom96 | noooo |
13:39:19 | BitPuffin | well actually I am too |
13:39:21 | dom96 | resizing this video still breaks :( |
13:39:26 | BitPuffin | I never say RTFM seriously |
13:39:34 | BitPuffin | only as a joke |
13:39:55 | dom96 | sure, I understand. |
13:39:58 | BitPuffin | RTFM people are mainly dicks |
13:39:58 | dom96 | Fullscreen works. |
13:40:08 | BitPuffin | is it only during resize? |
13:40:20 | BitPuffin | or is it triggered by resize and doesn't stop after that |
13:40:47 | dom96 | It seems to happen only when I resize it to a certain size. |
13:40:53 | dom96 | the video starts flickering |
13:40:58 | dom96 | it's not during the resize |
13:41:02 | dom96 | well it is too |
13:41:09 | dom96 | but it keeps happening after the resize |
13:41:19 | dom96 | until I resize it to a size which doesn't flicker |
13:41:42 | dom96 | It's as if it can't set the video to that size. |
13:42:04 | dom96 | An older version of the video constantly tries to fight a lower size of the actual video :P |
13:42:37 | dom96 | I'll try with MPlayer |
13:43:29 | dom96 | MPlayer has problems too. |
13:44:05 | * | xilo joined #nimrod |
13:44:55 | dom96 | I guess it was partially fixed. |
13:45:00 | dom96 | Good enough for me. |
13:45:01 | EXetoC | identify the pattern and write a size correcter |
13:46:02 | dom96 | Easy enough to resize myself. |
13:46:12 | dom96 | It looks like it always works for fullscreen |
13:46:32 | dom96 | nvm |
13:46:33 | dom96 | lol |
13:49:53 | BitPuffin | http://lavabit.com/health.html :( |
13:53:43 | BitPuffin | is it just me or does the new firefox version crash more |
13:54:06 | dom96 | hasn't crashed for me yet |
13:54:22 | BitPuffin | has craseh twice |
13:54:28 | BitPuffin | and refused to start after the first time |
13:54:40 | BitPuffin | because it was still running in the background |
13:54:42 | dom96 | better backup your profile |
13:54:51 | BitPuffin | profile? |
13:55:40 | dom96 | ~/.mozilla/firefox/somehash.default is your profile |
13:56:00 | BitPuffin | why do I need to backup that? |
13:56:20 | dom96 | I've had cases where Firefox crashed and lost my tabs. |
13:56:58 | BitPuffin | lol :) |
13:56:59 | BitPuffin | oh well |
13:57:00 | BitPuffin | done |
14:04:30 | * | dom96 should add a little !todo thing to Nimbot |
14:04:51 | dom96 | And it would give you stuff from a list randomly like: Create a nimrod tutorial for http://learnxinyminutes.com/ |
14:06:27 | dom96 | Which someone should do btw :P |
14:06:39 | EXetoC | cb? nice |
14:06:41 | EXetoC | vb |
14:08:47 | * | Amrykid quit (Changing host) |
14:08:47 | * | Amrykid joined #nimrod |
14:08:57 | EXetoC | so, is it too late to add support for whitespace-dependent operator precedence? :> |
14:10:53 | dom96 | never too late |
14:17:38 | dom96 | wtf |
14:18:14 | dom96 | I replied with a mention of Nimrod in: http://adambard.com/blog/3-languages-to-watch/ |
14:18:20 | dom96 | And the guy rejected my comment. |
14:19:59 | EXetoC | lame |
14:21:26 | dom96 | Lets try this again. |
14:21:44 | BitPuffin | import linagl/vector |
14:21:44 | BitPuffin | export vector.dot |
14:21:44 | BitPuffin | export vector.TVector |
14:21:49 | BitPuffin | will that work as expected? |
14:21:58 | BitPuffin | or do I have to export linagl/vector.dot |
14:22:45 | dom96 | That's not very nice :( |
14:23:01 | dom96 | He rejected my comment asking him why he rejected my comment :P |
14:23:31 | dom96 | oh well, screw him |
14:23:38 | dom96 | I need to set up my own blog |
14:24:23 | BitPuffin | elixir seems nice |
14:26:46 | BitPuffin | might use it to write a server for a game project one day |
14:46:37 | BitPuffin | would be massively useful to have a import_relative alternative to import |
14:47:19 | zahary_ | why wasn't import relative by default too? |
14:48:39 | BitPuffin | import is relative from where you are compiling |
14:48:54 | BitPuffin | import_relative would be relative to the location of the module you call it in |
14:50:44 | dom96 | import is relative to your path |
14:51:01 | dom96 | You should design it to work with babel |
14:51:08 | BitPuffin | dom96: yes |
14:51:38 | BitPuffin | dom96: but the matrix file which is in the same dir as vector should easily be able to import vector without having to worry about the path it's being compiled from |
14:53:54 | EXetoC | I prefer the GCC way. changing the dir or adding a dir to the path is not a problem imo |
14:54:19 | EXetoC | also, the output path is relative to the project file path, and I don't like that either |
14:54:20 | BitPuffin | that's got nothing to do with it |
14:55:01 | BitPuffin | A module should be able to import another module in the same dir without specifying its full path |
14:58:31 | EXetoC | you can do ./ apparently |
14:58:48 | dom96 | oh yay, he didn't actually reject it: "Sorry, Disqus just automatically flags any comment with a link for review before posting. I didn't even know it was there." |
15:00:01 | EXetoC | I also gave this a go just now "tri_engine/../tri_engine/gfx/gl/primitive". it works |
15:00:51 | dom96 | It seems to be working fine for jester. |
15:01:07 | dom96 | oh no wait, that's because I added it as a path. |
15:01:41 | EXetoC | so I guess that leaves us with the biggest issue, which is that the full qualification can't be used outside of import statements. we've discussed that before, so I'm sure it'll be dealt with in the future |
15:01:47 | dom96 | I'm not sure how else you would use it anyway though |
15:02:04 | EXetoC | nm, I'm wrong as usual |
15:02:39 | EXetoC | but doesn't this mostly have to do with minimizing typing? because you can still do this if you just add the absolute path with -p |
15:02:52 | EXetoC | or relative |
15:03:21 | BitPuffin | so in matrix I could instead do: import ./vector? |
15:04:10 | * | Associ8or joined #nimrod |
15:04:10 | * | Associ8or quit (Changing host) |
15:04:10 | * | Associ8or joined #nimrod |
15:04:51 | EXetoC | it might be relative to the path's added to the compiler only |
15:05:33 | EXetoC | which the parent dir of tri_engine is in my case |
15:06:52 | * | Associat0r quit (Ping timeout: 276 seconds) |
15:06:52 | * | Endeg quit (Ping timeout: 276 seconds) |
15:07:03 | EXetoC | yep, so we're half way there |
15:08:26 | dom96 | I'm assuming what you want to do is create some sort of test files in a test directory |
15:08:50 | dom96 | And then import your lib by doing: import ../src/matrix |
15:09:18 | dom96 | What you should do instead is create a .cfg file and add path = "../src/" |
15:09:19 | dom96 | to it |
15:09:42 | dom96 | Like in jester: https://github.com/dom96/jester/blob/master/tests/nimrod.cfg |
15:10:12 | EXetoC | I think he wants it to be relative to the current module, so that's a slightly different scenario |
15:10:34 | EXetoC | but that's alright if the hierarchy is flat, or if you don't mind adding each sub-dir |
15:10:49 | BitPuffin | well take a look at how linagl is set up |
15:11:03 | BitPuffin | https://bitbucket.org/TheLonelyByte/linagl/src |
15:11:16 | BitPuffin | src is the srcDir for babel |
15:11:26 | BitPuffin | and in there is another dir (linagl) |
15:11:32 | dom96 | what do you want to accomplish exactly? |
15:11:35 | BitPuffin | and in there is matrix.nim and vector.nim |
15:11:42 | BitPuffin | I want matrix to be able to import vector |
15:11:49 | BitPuffin | without having to write linagl/vector |
15:11:59 | BitPuffin | but instead just import_relative vector |
15:12:04 | dom96 | why is writing that a problem? |
15:12:07 | BitPuffin | relative to the *module* |
15:12:21 | dom96 | I agree that an import_relative would be nice. |
15:12:45 | dom96 | but is writing import linagl/vector really that bad? |
15:12:53 | BitPuffin | because imagine a project where it's something like this proj/graphics/mesh/poop/collada/ftw/image |
15:12:57 | BitPuffin | in that image dir |
15:13:10 | BitPuffin | let's say there is two modules |
15:13:18 | BitPuffin | and one of them wants to import the other |
15:14:03 | BitPuffin | do you really want to take a break and think about the full path there and make sure you didn't spell it wrong and all that? or would you rather just be able to import the other module relative to the module's location |
15:14:21 | dom96 | good point |
15:14:51 | dom96 | I wonder if it would be a good idea to have some sort of logical lookup mechanism for modules when using 'import' |
15:15:03 | dom96 | So that it looks in the directory relative to the module |
15:15:08 | dom96 | if it finds it, it uses it |
15:15:11 | dom96 | if not it looks at the path |
15:15:19 | dom96 | Sounds reasonable doesn't it? |
15:15:44 | BitPuffin | yeah that's what I thought it was doing |
15:15:50 | BitPuffin | and I asked about it a few days ago |
15:15:54 | BitPuffin | so I was tricked :P |
15:16:01 | BitPuffin | and now I found out it doesn't work |
15:16:13 | dom96 | bug report! |
15:16:38 | BitPuffin | maybe soon |
15:16:40 | BitPuffin | gotta read :) |
15:16:55 | BitPuffin | if you have time now why don't you take it? |
15:17:21 | dom96 | I don't, I need to finish this async stuff! |
15:17:33 | BitPuffin | then do it! |
15:44:25 | EXetoC | dooooo it, man! |
15:59:11 | NimBot | Araq/Nimrod master 8b4fb8e Zahary Karadjov [+0 ±4 -0]: Take into account dirty buffers in suggest output; Fixes zah/nimrod.vim#14 |
16:08:48 | dom96 | Araq: Doesn't look like much, but it's what you asked for: https://gist.github.com/dom96/f12a9d32989105467760 |
16:09:19 | dom96 | And I just restarted it and it did the same thing. |
16:09:37 | dom96 | Looks like I can reproduce it. |
16:22:23 | EXetoC | I like Nimrod |
16:22:59 | dom96 | Do you like like it? |
16:23:27 | EXetoC | yeah, it's alright |
16:30:07 | EXetoC | it's almost better than C++! |
16:30:22 | dom96 | s/almost// |
16:33:30 | dom96 | s/C++/everything/ :P |
16:34:49 | EXetoC | it's definitely better than ALGOL 58 though |
16:40:51 | * | DAddYE joined #nimrod |
17:07:20 | * | Mat2 joined #nimrod |
17:07:29 | Mat2 | hello all together |
17:10:15 | dom96 | hello Mat2 |
17:11:09 | Mat2 | hi dom96 |
17:13:54 | Mat2 | a quick poll: Should I still support the old IA32 architecture for my compiler or should I better ignore it and concentrate straight on the ARM and MIPS backends ? |
17:14:50 | dom96 | I would still support it |
17:15:00 | dom96 | What compiler are you making? |
17:16:46 | Mat2 | its an AOT compiler for concatentative languages, reusing my own MISC ISA as immediate-code representation |
17:20:24 | Mat2 | (and no, LLVM and libJIT are both 1. ressource intensive for usage in restricted environments and 2. generate impressive bad machine-code for the planed targets) |
17:25:13 | Araq | dom96: looks indeed like a regression |
17:25:41 | dom96 | Araq: good. |
17:25:50 | Mat2 | hi Araq |
17:29:10 | Araq | hi Mat2 |
17:30:40 | Araq | Mat2: I think it's fine to ignore 32bit x86 for now; it's the platform with the most calling conventions etc. anyway so it's lots of work unless you don't care about a decent FFI |
17:34:47 | Mat2 | thanks, yes .. I think only adding a backend for it at demand (its also the most bizarre ISA I know of) |
17:35:51 | Mat2 | hmm ok after Fairchilds F8 cpu |
18:32:32 | EXetoC | beep |
18:32:46 | Mat2 | hi ExetoC |
18:38:04 | dom96 | Araq: Should this be possible? https://github.com/Araq/Nimrod/issues/568 |
18:41:34 | Araq | dom96: no it shouldn't be possible |
18:41:48 | EXetoC | yeah, static polymorphism |
18:42:42 | dom96 | Well then I don't think zahary's TPromise[T] can work. |
18:44:05 | Araq | seq[PObject] ? |
18:44:26 | dom96 | I can just make the value field a PObject |
18:44:40 | dom96 | But then I lose compile-time safety :P |
18:48:00 | dom96 | So why is this not allowed? |
18:48:31 | EXetoC | I don't know how it could work |
18:49:11 | EXetoC | since type parameters are resolved at compile-time. do you want a sum type that can take anything? |
18:50:23 | dom96 | hrm, thinking about it more, it would be pretty crazy if it worked. |
18:51:02 | EXetoC | can't you hide the internals and make the interface type safe? |
18:51:48 | dom96 | dunno |
18:52:00 | dom96 | let a = downloadAsync("..") |
18:52:12 | dom96 | await a # We don't know whether downloadAsync returns a value or not |
18:53:35 | dom96 | I could probably come up with some "hacks" to get the compiler to check these things for me. |
18:53:42 | EXetoC | do you need reflection that doesn't involve AST inspection? that'd help in some cases, I guess |
18:53:53 | EXetoC | ya probably :> |
18:54:10 | dom96 | Well, it's easy if only: await asyncProc, is allowed. |
18:54:25 | dom96 | But my macro will not know what 'a' refers to. |
18:55:24 | * | Sergio965 joined #nimrod |
18:55:38 | dom96 | ping zahary_ |
18:57:37 | dom96 | Also from zahary's comments it seems that he wants a statement like: var a = download(..) to start the download immediately. |
18:58:00 | dom96 | Which is rather difficult. |
18:58:07 | * | dom96 thinks |
18:59:52 | dom96 | I could do some hacks, again... |
19:00:00 | EXetoC | is var or the lack of 'async' in this case the relevant part? |
19:00:10 | dom96 | the lack 'await' yes. |
19:00:35 | dom96 | An 'await' can act as a hint for the macro. |
19:00:58 | dom96 | The only thing I can think of is crazy ideas |
19:01:16 | dom96 | Where I generate some identifying proc when transforming each async proc |
19:01:59 | dom96 | and then for each proc call I generate 'if downloadAsyncIdentifier: doStart downloadAsync()' |
19:02:09 | dom96 | But the overhead would be huge. |
19:02:56 | dom96 | And I don't know how it would connect it with the 'await' which happens next... |
19:03:20 | dom96 | It's just a huge mess :\ |
19:03:57 | dom96 | So we might as well just forget about immediately starting the download. |
19:04:05 | dom96 | and start it when an 'await' happens. |
19:05:02 | dom96 | The 'value' field issue will happen with my old implementation too I think. |
19:05:16 | dom96 | I like my new implementation so I think I will continue it |
19:06:56 | dom96 | but ughhh, I don't want runtime errors for this :\ |
19:07:39 | dom96 | it must be possible |
19:08:22 | dom96 | yes! |
19:08:26 | * | dom96 has an idea |
19:13:44 | dom96 | nope, I don't think this is possible. |
19:16:51 | dom96 | lol |
19:17:09 | dom96 | I just realised there is little point to allowing: var a = someAsyncProc() |
19:17:17 | dom96 | if that will not immediately start the download. |
19:17:19 | Araq | dom96: I don't get it, you already have "Promise", it's called "PRequest" afaict |
19:18:04 | dom96 | Araq: It's not the same. |
19:18:19 | dom96 | I simplified it A LOT. |
19:18:23 | dom96 | And I like this design. |
19:18:34 | dom96 | But doing it as zahary suggests seems impossible. |
19:18:54 | dom96 | How am I suppose to start the async proc when I have no idea that it's an async proc? |
19:19:39 | dom96 | I can go for a compromise and add another command to do so... |
19:19:57 | dom96 | I guess that's the only option. |
19:25:23 | * | photex joined #nimrod |
19:25:33 | EXetoC | yeah, I wondered why you didn't want it to be explicit |
19:25:45 | Araq | hi photex, welcome |
19:25:46 | dom96 | I think I'm trying to be too much like C# |
19:25:54 | dom96 | I'm aiming too high :P |
19:25:59 | dom96 | hello photex |
19:26:03 | photex | Hello Araq, dom96 |
19:26:17 | photex | I just found Nimrod today |
19:26:19 | EXetoC | is that determined implicitly in C#? |
19:26:26 | photex | thought I'd lurk a bit in here :) |
19:26:38 | EXetoC | I don't even know the specifics, so nevermind :> |
19:26:57 | photex | still reading over the site a bit. Haven't tried to use it yet. |
19:27:01 | dom96 | EXetoC: The C# compiler knows about it I think, so it can do all sorts of magic. With macros I can only do so much. |
19:27:42 | dom96 | photex: cool. You're welcome to lurk, but I encourage you to write something in Nimrod too :) |
19:28:06 | photex | dom96: it's on my short-term todo list :) |
19:28:32 | photex | going to build it over my lunch break and mess around |
19:28:44 | dom96 | awesome :) |
19:29:48 | photex | actually, I have a quick question about interacting with C libraries that I didn't quickly see any information about |
19:29:59 | photex | I wanted to play with nimrod and SDL2 a bit |
19:30:19 | photex | and I'm trying to track down what libraries are available already |
19:33:04 | * | dom96 wonders what the question is :P |
19:33:17 | EXetoC | interfacing with C is easy compared to some languages. there's a tool for converting headers, and you usually need to edit things manually, but not all that much |
19:33:22 | EXetoC | anyway, there's this: https://github.com/fowlmouth/nimlibs/tree/master/fowltek/sdl2 |
19:33:54 | photex | sorry.. had to step away for a sec |
19:34:16 | dom96 | There is a list of packages here: https://github.com/nimrod-code/packages/blob/master/packages.json |
19:34:22 | photex | so I've just seen babel, and the nimrod-packages project on github |
19:34:24 | photex | is this canon? |
19:34:38 | photex | there isn't a packages list on nimrod-code.com that I saw |
19:34:44 | dom96 | yeah, it's official. |
19:34:47 | photex | ok great :) |
19:35:14 | dom96 | hrm, true. Having a link to the package list on nimrod-code.org might be a good idea. |
19:35:43 | dom96 | Would be nice to have some sort of site which reads the .json file and lists them nicely. |
19:36:08 | Mat2 | does one know if the SDL2 binding is complete ? |
19:36:09 | * | dom96 is full of ideas but has too little time |
19:36:14 | photex | yes that would have satisfied some curiosity for me pretty quickly |
19:37:28 | BitPuffin | Mat2: I believe it is, I just don't know if it is up to date, ask fowl |
19:39:09 | photex | I've been working on an SDL2 binding for Common Lisp with another person. And it's been a pretty interesting experience. I've started to compare the various ways to interact with C between the various languages I've used. |
19:39:23 | photex | not for any real metric |
19:39:41 | photex | just *something* to do when I'm not sure where else to start :/ |
19:40:03 | photex | it's either that or build a server of some kind heh |
19:40:12 | reactormonk | photex, sup ;-) |
19:40:13 | dom96 | I usually write an IRC bot first heh |
19:41:02 | photex | sup reactormonk |
19:41:13 | photex | dom96: excellent idea! haha |
19:44:01 | Mat2 | BitPuffin: thanks, do that |
19:44:16 | BitPuffin | Mat2: do what? |
19:44:33 | Mat2 | asking |
19:44:47 | BitPuffin | me? |
19:44:48 | reactormonk | photex, we already have a bunch of IRC bots, if you want something simple, fuck a bit with the testing. |
19:45:01 | Mat2 | no fowl |
19:45:09 | * | Associ8or quit (Quit: Associ8or) |
19:45:17 | BitPuffin | Mat2: yeah I told you to ask him haha |
19:45:36 | Mat2 | *lol* |
19:45:38 | photex | reactormonk: I wasn't going to do that myself, I was just saying that it was a great idea. :) |
19:46:01 | * | Mat2 coding and reading |
19:46:07 | BitPuffin | speaking of testing, matrix.nim emits a very professional message when tests pass |
19:47:14 | reactormonk | photex, so I used the wrong decryption key for reading between the lines. |
20:35:56 | BitPuffin | Araq: So the website says that the nimrod compiler is easy to port to other platforms, but how easy is it exactly? |
20:36:05 | BitPuffin | like what do you need to do |
20:36:12 | BitPuffin | the platform I have in mind already has GCC |
20:40:30 | dom96 | what platform is it? |
20:40:50 | BitPuffin | dom96: haiku |
20:42:36 | dom96 | Looks like we already have some basic support for it: https://github.com/Araq/Nimrod/blob/master/compiler/platform.nim#L135 |
20:42:48 | dom96 | I know that Araq is a fan of Haiku. |
20:43:13 | dom96 | I can't remember if he succeeded at getting Nimrod to work on it or not though. |
20:48:31 | BitPuffin | dom96: is it only the stuff in platform.nim that is needed for porting? |
20:49:07 | BitPuffin | cool that Araq is a fan, I'm a huuge fan :P |
20:49:59 | dom96 | well the stdlib needs ported |
20:50:33 | BitPuffin | should be standard posix stuff |
20:51:13 | dom96 | yeah, judging by the 'ospPosix' in props |
20:51:19 | dom96 | It already knows that. |
20:51:30 | dom96 | So i guess it should just work |
20:51:48 | dom96 | try compiling the c sources and see if it works |
20:52:17 | dom96 | lol, there is an atari platform. |
20:53:06 | BitPuffin | I'm gonna see if I can |
20:55:17 | * | gradha joined #nimrod |
21:01:34 | * | Trix[a]r_za is now known as Trixar_za |
21:12:54 | photex | has anyone used Nimrod on Android? |
21:13:05 | gradha | yes, pretty painful |
21:13:12 | gradha | no JNI bridge at the moment |
21:13:13 | * | photex thinking specifically of Ouya |
21:13:20 | photex | gradha: I see |
21:13:39 | gradha | but it runs without problems, as anything C like does |
21:14:18 | Mat2 | ciao |
21:14:25 | * | Mat2 quit (Quit: Verlassend) |
21:16:27 | gradha | a nice good project would be to wrap cocos-2d-x in nimrod, so you can avoid most java |
21:17:15 | gradha | as a bonus you get ios hipsters happy too |
21:17:21 | photex | lol |
21:18:53 | gradha | photex: feel free to play with https://github.com/gradha/nimrod-on-ios or https://github.com/gradha/nimrod-on-android |
21:19:15 | gradha | at the moment I'm distracted with other projects, so I won't be working on those repos for quite some time |
21:20:25 | photex | nice! |
21:22:58 | gradha | ah, forgot about https://github.com/gradha/nimrod-crossplatform-todo which is a more fleshed out example for iOS of nimrod's todo example |
21:23:24 | gradha | that's when I stopped, since I was lacking knowledge about nimrod macros to make bindings... and I still do, unfortunately |
21:24:22 | photex | this is great though. Thanks for the links. |
21:25:59 | gradha | wow, that was 8 months ago and I still don't know macros, I blame youtube! |
21:40:14 | dom96 | help me, I started watching The International Dota 2 competition and I can't stop now... |
21:40:32 | gradha | what's this dota you speak of? need kpop videos? |
21:40:41 | dom96 | esports man! |
21:40:44 | photex | man, I don't understand that game at all |
21:40:47 | photex | it's hard to watch |
21:41:02 | dom96 | same lol |
21:41:19 | gradha | do these esports feature scantily clad women, like beach volleyball? |
21:41:22 | photex | I enjoy EVO though |
21:41:23 | * | DAddYE quit (Remote host closed the connection) |
21:42:10 | dom96 | gradha: I wish |
21:42:27 | dom96 | Currently it's just geeky guys discussing the last game |
21:42:51 | gradha | I was told the latest women brazillian volleyball match against spain was hot, hmm... let's see what google knows about that |
21:42:55 | dom96 | But it's amazing how much money is in this. |
21:47:34 | gradha | oh, http://www.youtube.com/watch?v=60EAzrLNEP4 is nice, during the breaks the editor plays back highlights from the game in slow motion, including women slapping each other butts, quality TV |
21:47:47 | photex | lol |
21:49:05 | gradha | certainly russia doesn't look bad |
21:49:57 | gradha | soo... downloading 7GB of hi def esports, what about you dom96, anything worth watching? |
21:50:09 | photex | dom96: if you don't want to watch esports, did you watch the Carmack keynote form Quakecon yet this year? |
21:50:18 | photex | likewise gradha |
21:50:34 | photex | the part where he discusses Haskell and Scheme was interesting |
21:50:47 | gradha | nah, if posisble I avoid watching anything involving males |
21:50:51 | dom96 | I have indeed. |
21:51:02 | dom96 | gradha: I'm currently watching http://www.twitch.tv/dota2ti |
21:51:40 | dom96 | hrm, this guy has a kinda cool accent |
21:51:46 | dom96 | English I think |
21:52:59 | * | DAddYE joined #nimrod |
21:53:06 | gradha | I'm looking at some weird guys, seriously, this is not safe for work |
21:53:17 | gradha | isn't orange korean? |
21:53:40 | dom96 | lol |
21:53:50 | dom96 | That guy looks like he's been awake for more than 24 hours |
21:53:57 | dom96 | Yeah, they are. |
21:54:12 | dom96 | Well, I think |
21:54:14 | dom96 | I dunno. |
21:54:21 | dom96 | They're either Korean or Chinese |
21:54:29 | * | OrionPK joined #nimrod |
21:54:31 | dom96 | or maybe japanese |
21:54:37 | gradha | so we are watching some guys watching something else, the meta level is too high! |
21:55:06 | dom96 | They are deciding which characters to pick |
21:55:22 | dom96 | 'character' is probably the wrong word |
21:55:48 | * | gradha quietly closes the dota channel to avoid falling asleep |
21:56:19 | * | dom96 bets NaVi will win |
21:56:22 | dom96 | ooh windrunner |
21:58:18 | dom96 | I wonder if any of the teams at all have a female team member. |
21:59:08 | gradha | many moons ago I watched some esports documental and they just don't have mixed teams, like you don't have mixed soccer teams, though that would be nice to watch |
21:59:24 | dom96 | interesting |
21:59:26 | * | DAddYE quit (Remote host closed the connection) |
21:59:36 | gradha | "11 men playing against their 11 ex" |
21:59:49 | gradha | they would have to censor it due to ultra violence |
22:00:09 | dom96 | in that case I want female-only esports :P |
22:00:11 | * | DAddYE joined #nimrod |
22:00:39 | gradha | IIRC I watched maybe the 2012 starcraft finals for korean women and they looked quite nice |
22:01:39 | OrionPK | is that a thing? |
22:01:46 | OrionPK | korean women playing SC2? |
22:02:00 | OrionPK | I thought they just had female mascotts |
22:02:10 | gradha | presumably in south corea sc is more popular than soccer or other tv sports |
22:02:27 | OrionPK | nah thats a myth |
22:02:32 | gradha | being asians, they have "cram schoools" for sc2 where they play 12h a day |
22:03:07 | * | dom96 should install dota 2 on linux and attempt spectating these matches manually |
22:03:52 | gradha | I did watch some sc2 matches commented by some 9something guy, he was quite hilarious in the comments |
22:04:05 | EXetoC | exercise is overrated anyway |
22:04:11 | BitPuffin | gradha: nice that you have android examples, that will come in useful |
22:05:13 | gradha | BitPuffin: surprisingly there's nothing special about android, only the ndk is a little bit annoying to set up, having to use only partially documented makefiles |
22:06:09 | gradha | it's quite a turnoff too that the ndk says it's kind-of-but-not-completely-supported-and-you-should-use-jave-instead |
22:07:57 | gradha | hah, they even have cheerleaders in volley? |
22:08:01 | gradha | fascinating |
22:10:22 | BitPuffin | meh, java sucks :P |
22:10:33 | * | Trixar_za is now known as Trix[a]r_za |
22:10:50 | EXetoC | are you sure? |
22:12:28 | * | Trix[a]r_za is now known as Trixar_za |
22:14:17 | Araq | gradha: please edit your answer and tell him about --dynlibOverride |
22:14:35 | Araq | gah, it sucks you guys are living in the past ... |
22:15:00 | gradha | I would if I knew what dynlibOverride is |
22:16:30 | gradha | OrionPK: looks like in sc2 leagues there are mixed matches too http://wiki.teamliquid.net/starcraft2/Scarlett |
22:16:50 | OrionPK | gradha I know i used to follow the sc2 scene pretty closely |
22:16:57 | OrionPK | although scarlett is trans |
22:17:27 | gradha | haha, it's a trap! |
22:18:12 | gradha | well, if you know then I won't try to patronize you with my poor googling skills |
22:18:47 | OrionPK | ;) |
22:19:06 | * | q66 quit (Read error: Connection reset by peer) |
22:19:32 | * | q66 joined #nimrod |
22:19:51 | gradha | aaaaw, dynlibOverride doesn't appear in The One and Only True Index |
22:21:47 | gradha | hmm.. so it marks a symbol to not be linked dynamically? what's the advantage of that? don't you have then to pass the static link flags? |
22:23:04 | gradha | Araq: are you a fan of the hitchhickers' guide to the galaxy? |
22:24:39 | gradha | I'm starting to believe you have https://www.youtube.com/watch?v=HNmIQX_ImgM in mind whenever you document anything |
22:26:05 | Araq | hey there is even an example how to use it |
22:26:28 | gradha | you mean the lua fuzzy matching? |
22:26:36 | Araq | yeah |
22:26:48 | gradha | oh, 133t documentationz skillz |
22:27:25 | gradha | so you disable the lua dynamic lib, then what, you need to pass manually the flags for the lua static lib? |
22:27:37 | Araq | yes? |
22:28:04 | gradha | definitely much easier and user friendly than passing -d:staticLibLua |
22:28:42 | Araq | what makes you think the flags for static linking are always the same? |
22:29:10 | Araq | I'm sure you need --passL:"lualib.banana" on macosx |
22:29:42 | Araq | so ... if people want it, they can figure out the appropriate flags for themselves |
22:29:49 | gradha | dom96 linked a go review which has a nice term for that |
22:31:11 | Araq | btw the advantage of --dynlibOverride is that no code has to be adapted for it to work |
22:31:46 | gradha | here it is http://monoc.mo.funpic.de/go-rant/ the term is "New Jersey approach" |
22:31:50 | Araq | otherwise we'll have a sing and dance for every wrapper |
22:32:07 | Araq | with lots of new -d:staticX stuff |
22:32:07 | dom96 | yeah! NaVi won! |
22:32:33 | Araq | gradha: I know about "worse is better" ;-) |
22:32:55 | gradha | I'm talking about the "oh, it's hard, let's drop it onto the user" thing |
22:33:03 | dom96 | wait wait |
22:33:17 | gradha | presumably libs would provide some pkg-config like shell script to gorge parameters from? |
22:33:24 | dom96 | So I have to explicitly list all the libraries which I want to be compiled in statically? |
22:33:30 | Araq | not implementing --dynlibOverride seems to be easier than providing it... |
22:33:36 | gradha | dom96: of course, it's much better that way |
22:34:14 | dom96 | hrm |
22:34:16 | Araq | so thanks. I implemented a feature and you tell me it's the New Jersey approach |
22:34:37 | dom96 | Well the alternative means that you always have to have all the libs statically compiled |
22:34:51 | gradha | Araq: it is not? |
22:34:58 | Araq | but fine go ahead and patch every single wrapper with 'gorge' stuff |
22:35:07 | Araq | that will fail on the lesser used OSes anyway |
22:35:14 | Araq | but *shrug* |
22:36:43 | gradha | Araq: don't worry, I'll patch all of them |
22:37:44 | Araq | you have made your bed, now sleep in it |
22:37:45 | dom96 | oh! There is a woman doing an interview! |
22:38:56 | gradha | Araq: since we are sensible about features, when are you going to remove negative array indices? |
22:43:35 | Araq | I don't know, it's useful for enums starting with -1 |
22:43:40 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
22:43:55 | dom96 | where is this lua fuzzy matching example? |
22:43:57 | gradha | you don't want it documented though? |
22:43:58 | Araq | so it might break code if we simply remove it without deprecation warning |
22:44:33 | dom96 | (if that refers to the static lib stuff) |
22:44:36 | Araq | well by documenting it we kind of encourage its usage, right? |
22:45:15 | gradha | Araq: indeed it is better to have invisible features |
22:46:34 | gradha | dom96: search http://build.nimrod-code.org/docs/manual.html and http://build.nimrod-code.org/docs/nimrodc.html for dynlibOverride |
22:49:35 | Araq | gah I swear I added dynlibOverride to nimrodc.txt ... |
22:49:48 | dom96 | you did |
22:50:06 | dom96 | Well i'm confused. |
22:50:40 | Araq | maybe git did some nice merge conflict resolution |
22:50:43 | dom96 | oh, ok. So you do --dynlibOverride:gtk and then --passL:gtk |
22:51:38 | dom96 | That's pretty nice. |
22:52:39 | dom96 | Why not allow a shortcut like: --dynlibOverride:libgtk,staticgtk |
22:53:18 | Araq | *shrug* you don't write it on the command line anyway, you put these things in a config file |
22:53:40 | Araq | and the --passL stuff is likely to be OS dependent anyway |
22:55:28 | dom96 | Do we have a standard for wrappers which specify these things manually? |
22:55:38 | dom96 | so you can just pass --staticGtk or something |
22:55:57 | Araq | exhu invented a standard I think |
22:56:18 | Araq | well if we follow his convention, it becomes a standard |
22:56:39 | EXetoC | has anyone used SDL_TTF? |
22:56:42 | dom96 | well decide and document it |
22:57:00 | dom96 | EXetoC: I think it might be used in the graphics module. |
22:57:22 | Araq | I decided --dynlibOverride + passL is good enough but you all disagree so it's up to you to find a better standard |
22:57:37 | dom96 | Did I ever disagree? |
22:57:52 | Araq | you just did? |
22:57:54 | EXetoC | I'm using the wrapper, but the values are all wrong |
22:59:08 | EXetoC | I'm talking about a possible upstream issue, so it doesn't have anything to do with the wrapper |
22:59:08 | dom96 | I think it's great. But we also need some sort of convention for wrappers to do it themselves, since you say that the value for passL is OS-dependent anyway |
22:59:20 | dom96 | Doesn't it make sense to get the wrappers to specify it? |
22:59:34 | dom96 | with --dynlibOverride being a nice workaround for the ones which do not |
23:00:04 | dom96 | I'd say that it would be nice to have: --static:modulename |
23:00:18 | gradha | good night |
23:00:21 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=1ZZC82dgJr8 again) |
23:00:25 | dom96 | when wantStatic: ... |
23:00:46 | dom96 | but that's probably too much work for its worth |
23:00:53 | Araq | oh really? :P |
23:01:08 | dom96 | I dunno |
23:01:12 | Araq | I thought we gained the generic -d mechanism for these things |
23:01:33 | dom96 | with --static we enforce the convention |
23:01:43 | dom96 | otherwise its up to the user. |
23:02:01 | Araq | with --static we have yet another feature people need to learn about it |
23:02:37 | Araq | so no. no new feature |
23:02:48 | Araq | good night |
23:03:40 | dom96 | Users are most certainly capable of learning this. |
23:03:57 | Araq | look at the forum then |
23:04:04 | dom96 | There are problems with my idea though |
23:04:15 | Araq | often we get the same questions |
23:04:27 | dom96 | ugh |
23:04:38 | dom96 | I don't see how this is relevant. |
23:04:42 | Araq | but this discussion is pointless, sorry; I won't implement anything anyway |
23:04:43 | dom96 | They will ask about how to do it anyway |
23:04:49 | Araq | indeed |
23:05:14 | dom96 | ok then lets decide on a convention |
23:05:34 | Araq | -d:staticLIBNAME |
23:05:42 | dom96 | ok |
23:52:58 | dom96 | bye |