| 00:00:17 | runvnc | youre not being demanding thanks for figuring that bit out |
| 00:00:26 | dom96 | It's fine. I looked at it quickly earlier and thought it was fine, but started to realise more things which I didn't like now. |
| 00:00:45 | dom96 | And then realised that i'm too tired to think about how it should be done heh |
| 00:01:02 | dom96 | I'm glad you asked if there was anything else. |
| 00:01:14 | runvnc | well, up to you, I can refactor, you can refactor, or I can always just use this as a file that I run personally on my own app to take advantage of the pipelining |
| 00:01:46 | runvnc | anyway talk about it tomorrow |
| 00:02:06 | dom96 | Oh no. I'll definitely pull it. |
| 00:02:25 | dom96 | but yeah, tomorrow it is. |
| 00:03:42 | BitPuffin | flaviu: the thing is, this particular bug atm is prety hard to report because it's really difficult to know what it is. When I spoke to zahary_ he said he might know what it is but not much else |
| 00:04:09 | BitPuffin | It happens inside a module which is tested and works |
| 00:04:13 | dom96 | zahary_ said something about a homebrew issue on Mac with Nimrod. |
| 00:04:15 | BitPuffin | which is the odd bit |
| 00:04:22 | BitPuffin | dom96: yeah but that's irrelevant |
| 00:04:23 | dom96 | Doesn't look like he got around to fixing it. |
| 00:04:26 | BitPuffin | this was further back |
| 00:04:33 | dom96 | BitPuffin: Maybe you could take a look? |
| 00:04:47 | dom96 | I know that it doesn't relate to your generics bug |
| 00:05:45 | BitPuffin | dom96: I might if I get time over |
| 00:06:20 | * | askatasuna quit (Ping timeout: 258 seconds) |
| 00:06:27 | BitPuffin | I will slap your testicles if you say that I was just now playing CS:GO |
| 00:06:35 | BitPuffin | :P |
| 00:06:40 | dom96 | ouch |
| 00:09:46 | BitPuffin | I do feel like the ordinal type expected thing is more important than the weird ass template error I got |
| 00:12:33 | flaviu | dom96: I think I have a solution to bug #180 |
| 00:13:27 | flaviu | In my testing, system's owner is skPackage with id=101 |
| 00:13:36 | fowl | lua docs on coroutines http://www.lua.org/pil/9.2.html |
| 00:13:43 | fowl | looks neat |
| 00:14:31 | BitPuffin | fowl: how dare you speak positively about another language |
| 00:14:42 | BitPuffin | Sometimes I wish we had block comments |
| 00:14:48 | BitPuffin | not because I like them |
| 00:14:52 | BitPuffin | but they are useful when debugging |
| 00:14:56 | dom96 | flaviu: Great. Make a PR. |
| 00:15:01 | dom96 | I need to head to sleep now. |
| 00:15:04 | Varriount | BitPuffin: when false |
| 00:15:04 | dom96 | Good night. |
| 00:15:07 | flaviu | BitPuffin: He's just talking about it because he's going to make a nimrod library for it |
| 00:15:20 | BitPuffin | flaviu: it was a joke :) |
| 00:15:36 | flaviu | I know. I was joking too. |
| 00:15:39 | BitPuffin | Varriount: I know, that's what I use, but it forces me to indent the code so it's a bit more error prone when restoring it |
| 00:17:09 | * | ehaliewi` joined #nimrod |
| 00:17:39 | * | ehaliewicz quit (Remote host closed the connection) |
| 00:25:54 | * | eximiuswastaken quit (Ping timeout: 240 seconds) |
| 00:27:05 | * | eximiuswastaken joined #nimrod |
| 00:29:46 | fowl | BitPuffin, write your comments as code |
| 00:32:01 | flaviu | BitPuffin: <C-v>hjklI#<Esc> |
| 00:32:48 | xenagi | lol |
| 00:45:35 | BitPuffin | wut |
| 00:45:40 | flaviu | Vim |
| 00:46:31 | flaviu | <C-v> is block select, hjkl lets you move your cursor, I switches into block insert mode, # is just the literal # char, <Esc> exists block insert |
| 00:48:17 | runvnc | you can also indent with > in visual mode |
| 00:49:26 | flaviu | runvnc: that would be iwhen false:<Esc>Vhjkl><Esc> |
| 00:49:40 | flaviu | oops, extra > |
| 00:49:44 | runvnc | right |
| 00:50:00 | runvnc | or just to indent |
| 00:50:12 | runvnc | first like four years I used vim on or off, i never knew how to indent a block |
| 00:50:14 | runvnc | lol |
| 00:50:16 | flaviu | Wait, the > is not extra |
| 00:50:36 | flaviu | Don't tell anyone, but I still use the arrow keys |
| 00:50:48 | runvnc | I always used the arrow keys |
| 00:51:09 | runvnc | actually I found another thing called TextAdept that has windows style control-shift-arrowkey control v for curses |
| 00:51:25 | BitPuffin | flaviu: I know |
| 00:51:28 | runvnc | but it doesnt have an apt package I dont think so I always just fall back to vim in the terminal |
| 00:52:07 | flaviu | runvnc: What apt package? `yaourt -S textadept` |
| 00:52:12 | renesac | BitPuffin, discard """ """ |
| 00:53:05 | BitPuffin | runvnc: "always used the arrow keys" you're drunk! |
| 00:53:11 | runvnc | lol |
| 00:53:34 | runvnc | never tried arch yet |
| 00:53:39 | BitPuffin | arch is awesome |
| 00:53:46 | BitPuffin | yaourth is not all that good though |
| 00:53:50 | BitPuffin | you know |
| 00:53:53 | BitPuffin | yauaouoruoutoruhoruth |
| 00:53:55 | BitPuffin | the wrapper |
| 00:54:00 | BitPuffin | the rapper |
| 00:54:07 | BitPuffin | 50 shady of cent |
| 00:54:20 | BitPuffin | however I'm switching to crux |
| 00:54:47 | runvnc | hm thanks for letting me know about crux never heard of that before |
| 00:54:52 | runvnc | have you heard of coreos |
| 00:55:24 | BitPuffin | nope, what's that? |
| 00:55:43 | BitPuffin | crux is not for the average user att al though, be wary |
| 00:56:54 | flaviu | Arch is simple enough for me, and I'm never giving up the AUR |
| 00:57:15 | BitPuffin | actually coreos sounds kinda familiar |
| 00:57:30 | BitPuffin | flaviu: well arch was initially inspired by crux :P |
| 00:57:48 | BitPuffin | and who said anything about giving up on the AUR |
| 00:57:50 | runvnc | coreos is a dist that specializes in things like docker and etcd |
| 00:58:05 | * | q66 quit (Quit: Leaving) |
| 00:58:07 | BitPuffin | sweet |
| 00:58:21 | runvnc | actually sort of a coincidence, I am looking at the crux handbook, packages are bash scripts, |
| 00:58:30 | runvnc | I happen to be building a bash-based plugin system for my paas |
| 00:59:09 | runvnc | my question about crux is how do you publish a package |
| 00:59:10 | BitPuffin | yup |
| 00:59:16 | BitPuffin | packages are bash scripts in arch too |
| 00:59:18 | runvnc | do you have to go begging on a bug server like debian |
| 00:59:31 | BitPuffin | wat |
| 01:00:30 | BitPuffin | in fact crux and arch packages are so similar that often times you can even install an arch package lol |
| 01:00:42 | BitPuffin | although crux doesn't use systemd so those stuff won't work |
| 01:00:58 | flaviu | Systemd is amazing |
| 01:01:07 | flaviu | systemd-analyze plot > out.svg |
| 01:01:25 | BitPuffin | It's ok |
| 01:01:33 | BitPuffin | however it's one of the reasons I'm switching to crux |
| 01:01:46 | BitPuffin | Writing init scripts is just a lot more simple in crux |
| 01:01:50 | BitPuffin | since it's actually scripts |
| 01:02:06 | BitPuffin | whereas systemd feels like fuckin .ini files or something |
| 01:05:04 | flaviu | BitPuffin: I don't mind the .ini files, and you can create scripts too |
| 01:05:14 | flaviu | /etc/systemd/scripts |
| 01:06:05 | BitPuffin | flaviu: aren't those just for backwards compatability though? |
| 01:07:09 | BitPuffin | I dunno I guess I just feel like systemd makes it more difficult to keep track of the system, it's not very unixy |
| 01:08:29 | flaviu | Not very unixy, yes, but I can live with that if I have to spend less time on configuration |
| 01:08:44 | flaviu | *less glamorous parts of configuration |
| 01:09:27 | BitPuffin | sure, but with more abstractness you also lose a lot of the control and simplicity |
| 01:09:43 | BitPuffin | systemd feels like a magic bok |
| 01:09:45 | BitPuffin | box |
| 01:10:07 | BitPuffin | it feels hard to trust that it will do what I want it to do |
| 01:10:44 | BitPuffin | it's like giving your system the d, hence the name |
| 01:10:56 | EXetoC | witty |
| 01:11:06 | BitPuffin | :P |
| 01:14:29 | flaviu | I'm personally willing to put up with that because it saves me time. I definitely see your point though |
| 01:16:38 | BitPuffin | well crux doesn't really save you time |
| 01:16:43 | BitPuffin | since it doesn't do binary packages |
| 01:16:49 | BitPuffin | but it is very speedy light and simple |
| 01:16:52 | BitPuffin | which I like :) |
| 01:17:10 | BitPuffin | there is a distro based on crux though with binary packages called kwort |
| 01:18:12 | flaviu | BitPuffin: What window manager? We should probobly move this conversation into private chat or #nimrod-offtopic |
| 01:19:13 | BitPuffin | sure |
| 01:22:31 | * | DAddYE quit (Remote host closed the connection) |
| 01:23:03 | * | DAddYE joined #nimrod |
| 01:25:09 | BitPuffin | night! o/ |
| 01:26:21 | BitPuffin | Araq: http://youtu.be/UK0ea7l2hOw |
| 01:27:25 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 01:29:54 | * | feature quit (Ping timeout: 258 seconds) |
| 01:39:00 | * | Skrylar joined #nimrod |
| 01:39:03 | Skrylar | hello peoples |
| 02:16:07 | xenagi | hello Skrylars |
| 02:17:25 | * | psquid joined #nimrod |
| 02:44:34 | Skrylar | yay pixel format code :| |
| 03:09:34 | * | [1]Endy joined #nimrod |
| 03:13:36 | * | [2]Endy joined #nimrod |
| 03:15:45 | * | [1]Endy quit (Ping timeout: 250 seconds) |
| 03:21:15 | * | brson quit (Quit: leaving) |
| 03:21:41 | * | brson joined #nimrod |
| 03:42:11 | * | brson quit (Ping timeout: 245 seconds) |
| 03:49:45 | * | Demos joined #nimrod |
| 04:01:16 | * | xenagi quit (Quit: Leaving) |
| 04:26:20 | * | [1]Endy joined #nimrod |
| 04:29:54 | * | [2]Endy quit (Ping timeout: 240 seconds) |
| 04:37:49 | * | Varriount_ joined #nimrod |
| 04:41:19 | * | Varriount quit (Ping timeout: 252 seconds) |
| 04:44:39 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 04:47:06 | fowl | i cant figure out why this text isnt drawing >:/ |
| 04:47:17 | fowl | or maybe it is drawing in some crazy place |
| 04:48:11 | Demos | welcome to "find the triangle" |
| 04:48:14 | Demos | :D |
| 04:48:59 | * | Demos quit (Remote host closed the connection) |
| 05:05:03 | * | ics joined #nimrod |
| 05:14:25 | Skrylar | fowl: text isn't drawing? |
| 05:38:02 | * | DAddYE joined #nimrod |
| 05:53:40 | * | nande quit (Remote host closed the connection) |
| 06:05:34 | * | [1]Endy joined #nimrod |
| 06:11:30 | * | [1]Endy quit (Ping timeout: 240 seconds) |
| 06:23:07 | fowl | Skrylar, as it turns out, calling al_map_rgb before the display is created is bad |
| 06:42:19 | Skrylar | xD |
| 06:42:34 | Skrylar | .. Allegro.. soo. Yeah, sounds like there is no display to color map against |
| 06:46:34 | * | [1]Endy joined #nimrod |
| 06:46:47 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 06:53:44 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 07:39:02 | * | ics quit (Quit: Textual IRC Client: www.textualapp.com) |
| 08:00:46 | * | BitPuffin joined #nimrod |
| 08:01:46 | * | ehaliewi` quit (Ping timeout: 245 seconds) |
| 08:02:36 | BitPuffin | o/ |
| 08:33:06 | fowl | BitPuffin, tell me what u think holmes https://github.com/fowlmouth/flaming-nemesis |
| 08:35:24 | BitPuffin | ok watson |
| 08:36:05 | BitPuffin | fowl: wat is this watson |
| 08:36:54 | BitPuffin | some kind of game engern? |
| 08:37:53 | fowl | thats what its looking like |
| 08:42:39 | BitPuffin | sweet |
| 08:42:43 | BitPuffin | fowl: 2d? |
| 08:44:46 | fowl | the focus is on state management, gui and networking, the lobby state has a chat overlay that follows you to other games |
| 08:49:42 | * | DAddYE quit (Remote host closed the connection) |
| 08:50:09 | * | DAddYE joined #nimrod |
| 08:50:49 | BitPuffin | interesting |
| 08:50:56 | BitPuffin | so it's kind of a local mini platform |
| 08:52:59 | fowl | yesa |
| 08:54:18 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 09:07:19 | * | _di joined #nimrod |
| 09:17:11 | * | Skrylar quit (Ping timeout: 245 seconds) |
| 09:23:18 | fowl | you just need to implement a gamestate |
| 09:25:14 | BitPuffin | \o/ |
| 09:25:27 | BitPuffin | fowl: but you take care of rendering and stuff |
| 09:28:27 | BitPuffin | ping Varriount_ |
| 09:28:56 | fowl | BitPuffin, by offering allegro or sfml, im in the process of wrapping sfmls shapes for allegro though |
| 09:29:31 | BitPuffin | fowl: I see |
| 09:29:46 | BitPuffin | could you do opengl rendering too? |
| 09:29:52 | BitPuffin | since allegro works just fine with that |
| 09:30:06 | fowl | yes probably |
| 09:30:42 | fowl | try a c example please |
| 09:36:36 | BitPuffin | c? |
| 09:37:26 | fowl | unless you can whip up a gl triangle? |
| 09:47:38 | BitPuffin | I'm at wurk |
| 09:47:43 | BitPuffin | so I can't do anything right now :/ |
| 09:49:11 | * | gXen joined #nimrod |
| 09:49:33 | gXen | if the libssl was written in nimrod, would the compiler have detected the issue? |
| 09:50:44 | BitPuffin | gXen: wat issue |
| 09:50:50 | * | DAddYE joined #nimrod |
| 09:51:31 | gXen | http://pastebin.com/G9z9xDiQ |
| 09:52:09 | gXen | I dont know how the compiler deals that will with types in nimrod |
| 09:52:09 | fowl | BitPuffin, work :( |
| 09:55:23 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 10:03:45 | * | darkf_ joined #nimrod |
| 10:03:47 | * | darkf_ quit (Changing host) |
| 10:03:47 | * | darkf_ joined #nimrod |
| 10:05:21 | BitPuffin | fowl: hmm? :) |
| 10:07:24 | * | darkf quit (Ping timeout: 258 seconds) |
| 10:15:17 | fowl | gXen, if you were using memcpy theres not really any way to catch that |
| 10:38:16 | * | gXen quit (Read error: Connection reset by peer) |
| 10:38:17 | * | zahary quit (Read error: Operation timed out) |
| 10:38:34 | * | gXen joined #nimrod |
| 11:48:08 | * | psquid_ joined #nimrod |
| 11:51:40 | * | psquid quit (Ping timeout: 258 seconds) |
| 11:58:04 | * | darkf_ is now known as darkf |
| 12:04:03 | * | psquid joined #nimrod |
| 12:05:06 | * | psquid_ quit (Ping timeout: 240 seconds) |
| 12:38:34 | * | _di quit (Quit: leaving) |
| 12:50:34 | BitPuffin | alright time to look for what might be causing the whole ordinal type thing |
| 12:50:59 | dom96 | hello |
| 12:52:10 | BitPuffin | dom96: o/ |
| 12:52:17 | dom96 | BitPuffin: \o |
| 12:53:34 | BitPuffin | dom96: wazza |
| 12:53:53 | dom96 | no school from now on :D |
| 12:57:28 | runvnc | dom96: that means you graduated or something? |
| 12:57:38 | dom96 | nah, easter holidays |
| 12:57:46 | runvnc | are you in college |
| 12:58:01 | dom96 | No. Last year of high school. |
| 13:00:49 | runvnc | k well have a good easter break then |
| 13:01:24 | runvnc | to me holidays and stuff dont matter that much |
| 13:01:54 | BitPuffin | if I put a warning pragma will it still print if compilation fails before getting to that point? |
| 13:03:21 | dom96 | thanks. They won't really be holidays because I will need to spend a large amount of time studying for exams :( |
| 13:03:44 | runvnc | you must be taking some college-prep courses then |
| 13:04:19 | runvnc | well, I don't know how it is over there.. but in my public high school in the states, the 'normal' classes were pretty easy. college prep were like being in college a year early |
| 13:05:43 | dom96 | We don't really have those. We have A levels which you can consider to be college-prep courses but no one refers to them that way. |
| 13:06:12 | dom96 | Universities merely use them as entrance requirements. |
| 13:06:36 | dom96 | So I guess they are the same as SATs |
| 13:07:04 | zahary_ | Araq, I have a small cosmetic suggestion for the upcoming region types |
| 13:07:32 | dom96 | zahary_: Did you get that homebrew issue fixed? |
| 13:08:08 | runvnc | oh ok |
| 13:09:14 | BitPuffin | it's these fuckers that are causing the ordinal type shit https://gist.github.com/BitPuffin/10467426 |
| 13:09:37 | zahary_ | > In order to make generic code easier tor write ``ptr T`` is a subtype of ``ptr[R, T]`` for any ``R``. |
| 13:09:37 | zahary_ | similar rule is already present for all generic types, but it works in left-to-right order |
| 13:09:37 | zahary_ | if there is a type like Set[T, ComparisonState], Set[T] is equivalent na set[T, Any] |
| 13:09:37 | zahary_ | so I suggest that you follow the same left-to-right order of parameters here: ptr[T, Kernel] |
| 13:10:44 | zahary_ | I assume you wanted to make it consistent with the planned Kernel ptr int, but this syntax looks a big ambiguous to me - it already will be parsed as Kernel(ptr int), no? |
| 13:11:27 | BitPuffin | gz dom96! |
| 13:11:31 | zahary_ | dom96, I just tested it yesterday and it worked on my mac (linking nimrod in arbitrary directory in /usr/local/bin) |
| 13:11:46 | zahary_ | but I didn't have enough time to also look why it works (how the code was changed) |
| 13:12:33 | dom96 | BitPuffin: What are you congratulating me about? |
| 13:13:03 | BitPuffin | dom96: school |
| 13:13:17 | dom96 | zahary_: oh, as long as it works heh |
| 13:13:38 | dom96 | BitPuffin: You can congratulate me in August when I find out whether I got the grades necessary to go to Uni. |
| 13:16:08 | BitPuffin | dom96: well at least you don't have to go to school anymore |
| 13:16:34 | dom96 | true, except when exams are on heh |
| 13:16:40 | BitPuffin | okay so the source of error is the multiplication between the matrices |
| 13:17:02 | dom96 | zahary_: Think you could fix BitPuffin's issues? |
| 13:17:41 | zahary_ | I wish, but I'm very busy - I run an understaffed company with a bit arbitrary deadlines set by business people from time to time |
| 13:18:34 | BitPuffin | dom96: I'm currently dissecting |
| 13:18:56 | dom96 | zahary_: no worries |
| 13:22:27 | runvnc | just looking at random A level test here. The Lyman alpha peak of the quasar is labelled in Figure 7. Assume that the observed change in wavelength is due to the relative movement of the quasar. Show that the recessional speed of the quasar is approximately 4 × 107m s–1 |
| 13:22:43 | runvnc | that looks like astrophysics or something to me. why would a random person need to know astrophysics |
| 13:23:03 | dom96 | Where did you get it from? |
| 13:23:23 | runvnc | http://filestore.aqa.org.uk/subjects/AQA-PHYB1-QP-JUN13.PDF http://www.aqa.org.uk/exams-administration/exams-guidance/find-past-papers-and-mark-schemes |
| 13:23:54 | runvnc | it seems like they have some easy questions and some pretty hard questions |
| 13:24:18 | dom96 | Yeah, it's a mix. Physics is generally considered to be the most difficult A level. |
| 13:24:34 | dom96 | Also you get to choose the A levels that you do. |
| 13:24:49 | dom96 | Most universities only want 3. |
| 13:25:22 | BitPuffin | the fuck |
| 13:27:01 | dom96 | AQA is an English exam board though. My exam board is CCEA, the past papers are pretty similar though: http://www.rewardinglearning.org.uk/microsites/Physics/revised_gce/past_papers/index.asp |
| 13:27:06 | BitPuffin | is this supposed to work? https://gist.github.com/BitPuffin/10468782 |
| 13:27:38 | dom96 | BitPuffin: Invalid indentation. |
| 13:27:47 | dom96 | in line 2 |
| 13:27:58 | EXetoC | really? |
| 13:28:44 | EXetoC | the amount of spaces doesn't matter, as long as it's consistent. it works for me |
| 13:29:03 | dom96 | well that was my guess. |
| 13:29:19 | dom96 | But he uses 1 space in the first proc and 2 in the second |
| 13:29:47 | EXetoC | ok "consistent" is misleading |
| 13:30:18 | dom96 | however, it works for me too |
| 13:30:56 | EXetoC | I wouldn't mind disallowing that, but that's just nitpicking |
| 13:32:31 | OrionPK | how many people here are professional programmers? |
| 13:32:43 | BitPuffin | dom96: nope |
| 13:32:48 | BitPuffin | dom96: it ran just fine |
| 13:32:54 | BitPuffin | that's why I asked if it is supposed to work |
| 13:33:00 | dom96 | I see. |
| 13:33:13 | dom96 | I thought you were wondering why it doesn't work heh |
| 13:34:11 | BitPuffin | dom96: LEARN TO READ OMG |
| 13:35:29 | runvnc | I am a freelance programmer |
| 13:35:41 | BitPuffin | runvnc: ok |
| 13:35:49 | runvnc | orionpk asked |
| 13:35:52 | BitPuffin | ah |
| 13:35:53 | BitPuffin | haha |
| 13:36:02 | BitPuffin | OrionPK: I work with programming yes |
| 13:36:12 | runvnc | no one ever accused me of being professional though |
| 13:36:14 | dom96 | BitPuffin: Looks like you need to learn to do the same heh |
| 13:36:19 | OrionPK | heh |
| 13:36:37 | runvnc | why do you ask orion |
| 13:36:45 | BitPuffin | houstonmedia.se/ I'm the guy with the dreads who it (incorrectly) states is an intern |
| 13:36:50 | BitPuffin | dom96: you are a penis, READ THAT MOFO |
| 13:37:53 | dom96 | BitPuffin: Is the CEO the devil? :O |
| 13:38:39 | runvnc | wow the guy from vikings works with you bitpuffin! |
| 13:38:42 | runvnc | did you know that?? |
| 13:39:11 | BitPuffin | vikings? |
| 13:39:12 | dom96 | What's Vikings? |
| 13:39:17 | runvnc | lol |
| 13:39:38 | OrionPK | its a tv show |
| 13:39:43 | OrionPK | or a sports team |
| 13:39:54 | runvnc | oh tv show I meant http://collider.com/wp-content/uploads/vikings-katheryn-winnick-10.jpg |
| 13:40:05 | dom96 | BitPuffin: muahaha I have your Facebook |
| 13:40:22 | runvnc | your motion graphics artist I am pretty sure is the lead actor in Vikings |
| 13:41:40 | BitPuffin | dom96: my credentials? :P |
| 13:41:52 | OrionPK | which one is bitpuffin? anders widen? |
| 13:42:04 | OrionPK | oh dreds. |
| 13:42:11 | dom96 | BitPuffin: no, your profile URL |
| 13:42:20 | BitPuffin | dom96: that's okay |
| 13:42:29 | BitPuffin | is that on the website o_o |
| 13:42:35 | dom96 | yeah lol |
| 13:42:35 | BitPuffin | or did you just search |
| 13:42:38 | BitPuffin | the fuck |
| 13:43:06 | OrionPK | you guys have a cool site |
| 13:43:10 | runvnc | gnight |
| 13:43:16 | BitPuffin | OrionPK: it's just a common skin on the web |
| 13:43:37 | BitPuffin | for example: http://www.lanceweiler.com/ |
| 13:43:41 | OrionPK | yeah |
| 13:43:43 | OrionPK | I know |
| 13:43:46 | OrionPK | but it looks nice |
| 13:44:02 | * | gXen quit () |
| 13:44:10 | flaviu | 666Burgers Ordered 42Clients Worked With 69Projects Completed 1337Bugs Debugged |
| 13:47:01 | BitPuffin | true story |
| 13:47:41 | BitPuffin | zahary_: I think the issue might be with even though both are matrices, it's for some reason calling vector * |
| 13:47:44 | BitPuffin | instead of matrix * |
| 13:48:37 | zahary_ | which issue are we talking about btw? |
| 13:48:49 | BitPuffin | zahary_: ordinal type expected |
| 13:48:55 | BitPuffin | well I don't know why that's the error I get |
| 13:48:59 | zahary_ | from the test suite? |
| 13:49:16 | BitPuffin | but in my code I have translate(-point)*rotatex(angle)*translate(point) |
| 13:49:34 | BitPuffin | istnead of calling matrix*matrix is treats matrices as vector and calls vector * vector |
| 13:49:37 | BitPuffin | zahary_: no in linagl |
| 13:49:46 | zahary_ | is there a bug in github? |
| 13:52:22 | BitPuffin | no I will post one once I have more details |
| 13:53:33 | BitPuffin | zahary_: or maybe I should just make a Gist and explain what I think is going on? |
| 13:54:32 | zahary_ | I probably don't need the explanation, but just a piece of code that I can compile (prefferebly without jumping though too many hoops to obtain the dependencies) |
| 13:55:36 | BitPuffin | zahary_: okay I'll make an issue then |
| 13:58:14 | BitPuffin | zahary_: what do we call this, a dispatch problem? |
| 13:58:17 | BitPuffin | I'm not sure what to name it |
| 13:59:16 | zahary_ | "Ordinal type expected" in complex Matrix multiplication expressions |
| 13:59:52 | BitPuffin | zahary_: well the ordinal type expected thing is in vector |
| 14:00:00 | BitPuffin | even though I'm multiplying matrices |
| 14:00:06 | BitPuffin | it tries to multiply them as vectors |
| 14:03:53 | zahary_ | the name of the bug is not that important - just give me the code |
| 14:04:40 | * | darkf quit (Quit: Leaving) |
| 14:07:40 | BitPuffin | zahary_: https://github.com/Araq/Nimrod/issues/1080 |
| 14:11:43 | zahary_ | if you don't use distinct, generic type aliases like Vector[...] = array[...] and Matrix[...] = array[...] may be indistinguishable in general |
| 14:12:31 | zahary_ | it's an exercise for me to try to figure out why you didn't get proc redefinition errors because of this |
| 14:13:36 | BitPuffin | zahary_: yeah I thought I had to use distinct at first as well but this is supposed to work, otherwise Araq wouldn't have recommended me doing that instead of distinct |
| 14:13:38 | zahary_ | ah, I see that you used nested arrays, so that should be enough to distinguish between Matrix and Vector |
| 14:13:40 | BitPuffin | or whoever it was |
| 14:13:46 | zahary_ | but not between a Vector and a regular array |
| 14:20:50 | flaviu | So if I'm reading the code correctly, the compiler can compile ASTs to nimrod? |
| 14:20:56 | * | Demos joined #nimrod |
| 14:24:30 | BitPuffin | Araq: could this http://static.rust-lang.org/doc/master/guide-lifetimes.html#named-lifetimes be a possible solution to the return ref thing perhaps? |
| 14:24:33 | BitPuffin | and Demos |
| 14:24:38 | BitPuffin | since you just got here as well |
| 14:25:20 | BitPuffin | zahary_: well couldn't you kind have it be a soft type kind of thing |
| 14:26:20 | BitPuffin | zahary_: where it can be treated just as an array, but you can override an operator or something where it will select your version of the operator if you have defined one |
| 14:26:23 | flaviu | Demos: There's actually a better solution than the marshal.`$$` I talked about. dom96 pointed out system.repr, which does the same thing but without another import |
| 14:27:15 | Demos | so the core issue is that we want to be able to write functions that let you assign to the result but where assigning to a vairable does not have ref semantics |
| 14:27:17 | Demos | I think |
| 14:27:18 | zahary_ | BitPuffin, there is distinct array[] with `*`, `==` (this ops are reused, read about it in the manual) |
| 14:27:40 | zahary_ | but it doesn't work for array specifically for complicated reasons (some of the operators over arrays are not real functions) |
| 14:27:51 | BitPuffin | zahary_: yeah but distinct are still not the same type |
| 14:28:03 | BitPuffin | I'm thinking more like this is the same type, unless it's overriden |
| 14:28:27 | BitPuffin | in fact initially I was planning to implement matrices as a single dimensional array |
| 14:28:57 | Demos | what about using the AST overloading feature to figure out if we are being assigned to a variable? |
| 14:29:00 | Demos | crazy? |
| 14:29:16 | Varriount_ | Hm. Marshanl.nim really needs to be made "pluggable" |
| 14:29:37 | zahary_ | Demos, I'm missing the context here, are you talking about the same distinct vs non-distinct question? |
| 14:30:05 | Demos | oh, no I am talking about the var vs ptr thing |
| 14:30:10 | zahary_ | BitPuffin, overriding operators in local scopes is supported, but probably not recommended |
| 14:30:32 | BitPuffin | zahary_: yeah but I meant globally |
| 14:30:36 | zahary_ | and what about it? |
| 14:30:37 | BitPuffin | so you could make it part of the api |
| 14:30:57 | BitPuffin | zahary_: about return ref being unsafe |
| 14:31:03 | Demos | seems to me that the type of static[T] parms should factor into overload resolution and template instance selection |
| 14:31:11 | zahary_ | BitPuffin, if you want values with different behavior, then you need a different type |
| 14:31:19 | Demos | well about how having var and ptr is kinda annoying |
| 14:31:33 | BitPuffin | zahary_: well that's what I mean with what about having soft types |
| 14:31:44 | zahary_ | var can exist only on the stack and it's supposed to be memory safe |
| 14:31:50 | Demos | can we overload functions based on the AST they appear in? I think we can |
| 14:31:55 | zahary_ | using ptr automatically renders your code unsafe |
| 14:31:59 | Varriount_ | Speaking of types, what are "mimic types"? |
| 14:32:05 | * | Varriount_ is now known as Varriount |
| 14:32:11 | Demos | zahary_: well sure. But var also works differently from ptr |
| 14:32:39 | Demos | it decays into a regular value pretty quick |
| 14:33:14 | Demos | Varriount: as far as I can tell they let you make procs generic when you call them |
| 14:33:25 | BitPuffin | where they are still regular arrays, but if the kind of array has been declared as a type it will use that operator/proc that takes that type as a parameter, or a type defined using that type |
| 14:33:25 | zahary_ | ptr is supposed to get implicit conversions as well if I understand you correctly (when you say decay) |
| 14:33:29 | BitPuffin | if that makes sense lol |
| 14:33:31 | BitPuffin | so hard to explain |
| 14:33:35 | zahary_ | I'm planning to support var: var variables |
| 14:33:43 | zahary_ | which are "aliases" on the stack |
| 14:33:47 | EXetoC | I think it should just be a unique type then |
| 14:33:57 | EXetoC | no need to mess about with so much magic |
| 14:34:15 | BitPuffin | EXetoC: perhaps not |
| 14:34:16 | Varriount | zahary_: You are tinkering with dangerous forces here. |
| 14:34:23 | Demos | zahary_: right. but ptr stays as ptr. If a proc returns a ptr then when I assign the result to a variable that variable is a pointer |
| 14:34:31 | EXetoC | provide a converter if needed |
| 14:34:54 | zahary_ | ok, I got your point - var: var = someProcReturningVar() |
| 14:35:00 | zahary_ | var x: var = ... |
| 14:35:03 | zahary_ | this would be supported |
| 14:35:05 | Demos | I was under the impression that the only reason we really needed var return types was because the semantics of container access are somewhat different that just ref semantics |
| 14:35:11 | BitPuffin | I it's just that if some penis person creates some other type that is array, and then creates a proc such as `+` in their module they will clash |
| 14:35:17 | BitPuffin | even though they are different |
| 14:36:11 | Demos | BitPuffin: if the arrays are distinct they should not, even if they are not distinct they should not clash |
| 14:36:12 | zahary_ | BitPuffin, sometimes you want the generic alias to just be a convenience - then it doesn't make sense to treat it differently anywhere |
| 14:36:24 | BitPuffin | and having to do vector.`+`(a, b) isn't really that nice lol |
| 14:36:33 | zahary_ | so the rule is simple - generic aliases are transparent, distinct types gives you a new type |
| 14:36:41 | Demos | zahary_: the issue is that even with distinct types (or objects) the static[T] parms do not participate in overload resolution |
| 14:36:53 | BitPuffin | Demos: I'm talking about if it is the way it is now |
| 14:36:57 | BitPuffin | where they aren't distinct |
| 14:36:57 | zahary_ | Demos, what do you mean precisely? |
| 14:37:03 | Demos | let me gist |
| 14:37:05 | EXetoC | Demos: what do you mean even if they aren't? not using distinct in this case means it's just an alias |
| 14:37:34 | BitPuffin | zahary_: wouldn't I also have to say that every array literal is a TVector if I made it distinct? |
| 14:38:00 | zahary_ | yes, and that makes sense, because it's a different type |
| 14:38:35 | BitPuffin | zahary_: but it's so nice to just be able to do let a: TVector[int, 2] = [32, 29] |
| 14:38:59 | zahary_ | I would write that as let a = vector(32, 29) |
| 14:39:00 | BitPuffin | if I made it distinct that would be let a: TVector[int, 2] = [32, 29].TVector which is silly |
| 14:39:24 | zahary_ | this requires a constructor proc |
| 14:39:26 | BitPuffin | that is still not as nice |
| 14:39:34 | Demos | so like in https://gist.github.com/barcharcraz/8a6d216f7f072fb62984 |
| 14:39:38 | BitPuffin | I still want to be able to borrow the constructor for arrays |
| 14:39:55 | flaviu | BitPuffin: Seems nicer to me, no length field. But you can do something like seq |
| 14:40:00 | Demos | the `$` on TVec3f is ambigous with respect to `$`(a: T): string in system.nim |
| 14:40:19 | zahary_ | BitPuffin, this is possible as well var a = TVector([1, 2, 3]) |
| 14:40:32 | BitPuffin | zahary_: I know but you still have to put TVector around it |
| 14:41:01 | zahary_ | well, your example was also saying that - just in a different place |
| 14:41:25 | zahary_ | so Demos, what is going on here? |
| 14:41:47 | EXetoC | BitPuffin: converter? |
| 14:42:08 | flaviu | BitPuffin: proc vec*[IDX,T](v: array[IDX,T]): TVector[T,IDX] |
| 14:42:24 | flaviu | Then you can do var a = vec[1,2] |
| 14:42:54 | flaviu | Exactly like https://github.com/Araq/Nimrod/blob/devel/lib/system.nim#L808 |
| 14:43:53 | Demos | zahary_: overload resolution works in a very strange way |
| 14:45:41 | zahary_ | Demos, what is this construct? |
| 14:45:42 | zahary_ | type TVec3f* = TMatrix[N: static[int]; T] = TMatrix[N, 1, T] |
| 14:45:56 | Demos | a type alias |
| 14:46:04 | zahary_ | three-way? |
| 14:46:22 | Demos | right, I fucked that up. Let me fix it |
| 14:47:38 | Demos | reload. I made the code reasonable |
| 14:48:04 | zahary_ | looks legit, doesn't it work? |
| 14:48:44 | zahary_ | should be a.data[1] inside the `$` proc tho |
| 14:48:53 | EXetoC | does static[T] make it clear that it's a value? |
| 14:49:04 | BitPuffin | flaviu: hmm |
| 14:49:12 | Demos | I have a `[]` proc |
| 14:49:16 | Demos | but no it does not work |
| 14:49:27 | BitPuffin | flaviu: odd that when I asked for it araq didn't say it existed lol |
| 14:49:38 | Demos | it works if I say vecmath.`$`(...) |
| 14:49:41 | Demos | but not if I just call it |
| 14:49:49 | Demos | I think I even bugged it |
| 14:50:33 | zahary_ | implicit generic types go through a bit complicated process until the compiler figures out the final type that will be used in overload resolution |
| 14:50:45 | zahary_ | if your proc is not matched, it's a bug |
| 14:51:11 | BitPuffin | zahary_: yeah what I posted is still a bug |
| 14:51:24 | Demos | yeah that is not bugged, but a bunch of similar bugs are #1051 and #1056 are quite similar |
| 14:51:34 | zahary_ | TVec3f here should be equivalent to saying TMatrix[static[int](any), 1, T(any)] |
| 14:53:02 | Demos | yeah, probably a shit name. but even changed to like TMatrix[3,1,float32] overload resolution still fails (sometimes) When it fails tends to depend on what generics have been previously instanciated. Hence they wierd constructor bug |
| 14:53:56 | zahary_ | sorry, I haven't looked that last batch of bugs yet (don't get the impression I'm refusing to fix them) |
| 14:54:13 | EXetoC | of course not |
| 14:54:17 | EXetoC | cmon, more donations :> |
| 14:55:39 | Demos | I gotta go do a 3 hour chemestry lab right during lunch, be back in a few hours |
| 15:01:47 | BitPuffin | EXetoC, flaviu: I think what I'll do is both a simple vec proc and a converter |
| 15:02:16 | flaviu | Ok, sounds like it'd work |
| 15:02:25 | EXetoC | I have quite a few constructor procs |
| 15:03:23 | * | Demos quit (Ping timeout: 250 seconds) |
| 15:03:54 | EXetoC | vec(3, 4, 5). very convenient |
| 15:04:46 | BitPuffin | EXetoC, flaviu: That way both let penis: TVec3 = [0.38f32, 388.0, 38.8] and let somerandomweirdvector = vec(82, 38838, 38, 38, 2938, 30) work |
| 15:04:57 | EXetoC | and I don't care about the 'init' prefix in most cases tbh |
| 15:05:57 | BitPuffin | EXetoC: I think in something mathy like vectors vec is fine |
| 15:06:19 | BitPuffin | however with object types I think init makes sense |
| 15:10:32 | EXetoC | it gets really sometimes |
| 15:10:46 | EXetoC | I do like the concise construction syntax in D and C++ |
| 15:11:06 | flaviu | BitPuffin: Do something like http://www.vittoriozaccaria.net/blog/2014/03/21/symbolically-optimize-dsp-filters-with-template-haskell.html when you work out all the bugs |
| 15:12:46 | BitPuffin | flaviu: what, summarize plox? |
| 15:13:32 | flaviu | So that matrix.scale(vec(2,2,2,2)).scale(vec(.5,.5,.5,.5)) |
| 15:13:37 | flaviu | gets optimized to matrix |
| 15:14:11 | flaviu | Or translating in the same direction twice would be optimized to translating twice as long once |
| 15:15:27 | BitPuffin | sounds difficult |
| 15:17:41 | EXetoC | indeed, and for little gain |
| 15:18:00 | flaviu | Well, yes, but I |
| 15:18:04 | flaviu | t'd be fun |
| 15:18:31 | BitPuffin | flaviu: guess you could possibly do it with trm? |
| 15:18:44 | flaviu | That was what I was thinking of |
| 15:19:13 | BitPuffin | well |
| 15:19:23 | BitPuffin | I might add some TRM stuff in linagl indeed |
| 15:19:36 | Varriount | Araq: Has 9.3 been released yet? |
| 15:20:04 | EXetoC | would've been announced then surely |
| 15:20:15 | EXetoC | wait, 9.3? |
| 15:20:20 | Varriount | 0.9.3 |
| 15:20:25 | flaviu | Varriount: the 20th |
| 15:20:34 | Varriount | It keeps getting pushed back. |
| 15:20:42 | EXetoC | it won't be 0.9.4? |
| 15:21:08 | flaviu | Varriount: He told me to look here: https://github.com/Araq/Nimrod/blob/devel/web/ticker.txt |
| 15:21:19 | flaviu | It doesn't look like its been pushed back |
| 15:23:13 | BitPuffin | EXetoC: it will be, these guys are just stopid that's all |
| 15:24:56 | Araq | ugh ...looks like I can either try to make async stable or push the concurrency stuff into 0.9.4 |
| 15:26:36 | Araq | dom96: what do you think? |
| 15:27:05 | dom96 | Araq: Spend some time on async and if you can't find the bug then move onto your concurrency stuff. |
| 15:28:06 | BitPuffin | Araq: let'sn't (I just did that, yes) forget that linagl should be fairly important for game dev which we probably wanna attract people with, so having a stable linagl release would be fine ass stuff |
| 15:28:53 | Araq | not my business though |
| 15:29:26 | BitPuffin | Araq: I know, but you even say that you think it's ready for commercial game engines, so we need to live up to that :) |
| 15:29:26 | Araq | zahary_'s code is crazy, I'm not gonna touch it :P |
| 15:29:46 | zahary_ | I would also prefer if the matrix libraries out there are supported well with 0.9.4 |
| 15:30:13 | BitPuffin | zahary_: also do you think I should report that * doesn't work? |
| 15:30:15 | BitPuffin | for matrices |
| 15:30:22 | BitPuffin | not the matching thing |
| 15:30:30 | BitPuffin | the when false'd one |
| 15:30:46 | zahary_ | what's not working about it? as I explained, your matrices are arrays at the moment |
| 15:31:21 | BitPuffin | matrix.nim(121, 49) Error: internal error: cannot generate code for: R |
| 15:31:27 | BitPuffin | zahary_: not relevant |
| 15:31:48 | Araq | zahary_: have a look at how I fixed bug #1063 ... it gives me the creeps |
| 15:32:25 | Araq | no idea how it really works |
| 15:34:07 | zahary_ | ah, I saw this one and was wondering about it as well |
| 15:34:19 | BitPuffin | zahary_: https://gist.github.com/BitPuffin/10478279 this |
| 15:35:35 | zahary_ | my plan is to improve the infrastructure for figuring out what is evaluatable, what is evaluatable, but not yet known, etc with the implicitStatic reforms |
| 15:35:35 | BitPuffin | if that's not reported yet I will |
| 15:35:54 | BitPuffin | do you perhaps know if it's reported? |
| 15:36:10 | zahary_ | this should reduce the need for such "just try to evaluate it" code |
| 15:36:38 | Araq | dunno "just try to evaluate" got much more sound |
| 15:37:01 | Araq | with the recent bugfixes |
| 15:37:17 | Araq | and with the plans to not have FFI |
| 15:37:24 | zahary_ | the problem is this part "what is evaluatable, but not yet known" |
| 15:38:21 | zahary_ | these are expressions that have static values, but they will come later as parameters |
| 15:39:53 | Araq | ah I see |
| 15:40:52 | BitPuffin | zahary_: strange, if I remove surrounding code it works |
| 15:41:54 | EXetoC | no FFI? ok, well what I tried with OpenGL shouldn't even require it |
| 15:42:24 | Araq | no FFI at compiletime, that is |
| 15:44:37 | BitPuffin | zahary_: hmm, it gets instantiated in the orbit around stuff |
| 15:45:20 | zahary_ | BitPuffin, you can just give me a particular variation of the code that produces the error (even if it's not small) |
| 15:45:30 | BitPuffin | zahary_: I think I know what the error is |
| 15:45:31 | zahary_ | but keep one error per gist |
| 15:45:51 | BitPuffin | zahary_: My hunch is that when it is TMat4, it doesn't know how to get R from that |
| 15:46:12 | BitPuffin | and yes I know |
| 15:46:23 | BitPuffin | I have been sitting here trying to make a code sample for many minutes now :) |
| 15:47:55 | zahary_ | Araq, did you get my remark about region pointers |
| 15:48:18 | Araq | nope |
| 15:48:35 | zahary_ | and are we gonna get the full Rust alias anaylis? I must say I'm impressed by it and would love to have it in Nimrod |
| 15:49:05 | BitPuffin | here we go! |
| 15:49:25 | zahary_ | > In order to make generic code easier tor write ``ptr T`` is a subtype of ``ptr[R, T]`` for any ``R``. |
| 15:49:25 | zahary_ | similar rule is already present for all generic types, but it works in left-to-right order |
| 15:49:25 | zahary_ | if there is a type like Set[T, ComparisonState], Set[T] is equivalent na set[T, Any] (for overload resolution purposes) |
| 15:49:25 | zahary_ | so I suggest that you follow the same left-to-right order of parameters here: ptr[T, Kernel] |
| 15:49:25 | zahary_ | I assume you wanted to make it consistent with the planned Kernel ptr int, but this syntax looks a big ambiguous to me - it already will be parsed as Kernel(ptr int), no? |
| 15:50:20 | zahary_ | just a cosmetic proposal |
| 15:51:16 | BitPuffin | https://github.com/Araq/Nimrod/issues/1082 |
| 15:51:18 | BitPuffin | zahary_: ^ |
| 15:51:55 | zahary_ | is that the same linalg/vector? |
| 15:52:12 | BitPuffin | zahary_: yes |
| 15:55:26 | EXetoC | vector, matrix, such long identifiers :> |
| 15:55:51 | BitPuffin | EXetoC: you sound just as stupid as Araq now :P |
| 15:58:09 | Araq | zahary_: well I tried to implement R ptr T syntactically already and it causes grammar problems |
| 15:59:00 | Araq | I still think I can special case it |
| 15:59:52 | Araq | it's also ptr[R, T] because it's that way in the compiler's PType structure :P |
| 16:01:04 | Araq | do we get full Rust alias analysis? I don't know. I need to play with Rust. |
| 16:01:29 | BitPuffin | Araq: you probably should, there is some neat things in there, just that the syntax is barf |
| 16:01:29 | Araq | would be a desaster for marketing, lol |
| 16:01:33 | zahary_ | yes, you seems to be a fan of .lastSon and I like more .base :P (I know that it should be lastSon for skipTypes, but only because of tyGenericInst, which btw shouldn't be skipped in the semantic pass) |
| 16:01:59 | zahary_ | I already fixed couple of bugs caused by such premature skipping |
| 16:02:16 | Araq | hmm yeah |
| 16:03:31 | EXetoC | how context-insensitive is the grammar now? |
| 16:04:14 | Araq | it still requires no symbol table at all |
| 16:04:41 | zahary_ | proc badProc(s: var seq[int], y: var int) = s.setLen(0); echo y |
| 16:04:41 | zahary_ | var s = @[1, 2, 3] |
| 16:04:48 | zahary_ | badProc s, s[1] |
| 16:05:29 | zahary_ | I tried to fool Rust into accepting such dangerous code by making it increasingly more complicated, but it kept on finding about the aliases and producing an error |
| 16:05:36 | zahary_ | pretty impressive |
| 16:07:31 | Araq | yup |
| 16:09:01 | zahary_ | it's not clear to me why they chose to explicitly force the program to provide the region annotations (when you return a value from an input param region) - it seems to be that the compiler can automatically do the right thing in such situations |
| 16:09:08 | zahary_ | force the programmer |
| 16:10:55 | Araq | gah, bbl |
| 17:00:47 | * | q66 joined #nimrod |
| 17:03:13 | * | Skrylar joined #nimrod |
| 17:04:48 | * | DAddYE joined #nimrod |
| 17:11:25 | BitPuffin | dom96: I found a really nice VPS provider |
| 17:11:36 | BitPuffin | dom96: http://iniz.com/ |
| 17:16:23 | dom96 | BitPuffin: wow, really cheap and looks nice. |
| 17:16:31 | dom96 | BitPuffin: how did you find them? |
| 17:17:22 | BitPuffin | dom96: was looking for alternatives to DigitalOcean |
| 17:17:45 | BitPuffin | not because DO is bad, just that you have to use their kernel |
| 17:17:54 | BitPuffin | so no arch for example you are stuck with an old ass kernel |
| 17:18:01 | BitPuffin | well not that old |
| 17:18:03 | BitPuffin | but like |
| 17:18:05 | BitPuffin | 3.8 or something |
| 17:18:23 | BitPuffin | plus if you can't have your own kernel you can pretty much consider the server compromised |
| 17:18:34 | BitPuffin | and I wanted to use crux instead of arch |
| 17:18:44 | BitPuffin | which iniz could do for me :D |
| 17:19:16 | dom96 | brb |
| 17:23:22 | Skrylar | aww no love for arch :( |
| 17:23:43 | BitPuffin | Skrylar: on iniz? |
| 17:23:53 | BitPuffin | Skrylar: you can ask them for arch and they'll give it to you for free |
| 17:23:59 | BitPuffin | no extra charge |
| 17:24:06 | Skrylar | no, from you lol |
| 17:24:12 | BitPuffin | ah |
| 17:24:16 | BitPuffin | well I do like arch |
| 17:24:22 | BitPuffin | it's just |
| 17:24:31 | BitPuffin | some things are stopid |
| 17:24:46 | BitPuffin | such as having qt4 being one huge mega package rather than modules like they are in reality |
| 17:25:14 | BitPuffin | so if you want to install mumble which uses qtcore it pulls in all of qt which in turn pulls in x11 and a bunch of crap |
| 17:26:52 | EXetoC | the client uses core only? |
| 17:27:06 | BitPuffin | EXetoC: no the server |
| 17:27:08 | BitPuffin | murmur |
| 17:27:18 | BitPuffin | core doesn't have gui stuff |
| 17:27:25 | BitPuffin | afaik |
| 17:27:31 | BitPuffin | not a qt guy |
| 17:28:08 | BitPuffin | fowl should start a kickstarter to bind qt to nimrod lol |
| 17:31:10 | Varriount | Hm. Apparently people shouldn't be linking to "msvcrt.dll", but one of it's versioned brethren instead. |
| 17:31:23 | Varriount | I wonder if the mingw devs know that. |
| 17:31:25 | BitPuffin | sounds reasonable |
| 17:31:49 | Varriount | BitPuffin: "msvcrt.dll" is reserved for system use apparently. |
| 17:32:03 | BitPuffin | Varriount: ah |
| 17:32:10 | BitPuffin | Varriount: thought it was more an ABI thing |
| 17:32:13 | Varriount | http://blogs.msdn.com/b/oldnewthing/archive/2014/04/11/10516280.aspx |
| 17:33:32 | * | q66 quit (Ping timeout: 252 seconds) |
| 17:35:26 | * | q66 joined #nimrod |
| 17:37:07 | Varriount | BitPuffin: I wonder if I should try posting this on one of the mailing lists.. I'm afraid I'll get shouted at. |
| 17:38:50 | BitPuffin | lol |
| 17:38:52 | BitPuffin | just do it |
| 17:55:17 | BitPuffin | woot |
| 17:55:22 | BitPuffin | that was fast |
| 17:55:37 | BitPuffin | opened a ticket on DO and got a response within 2 minutes |
| 17:56:06 | Skrylar | heh |
| 17:56:12 | Skrylar | recent mingws are a bit broken anyway |
| 17:56:42 | Skrylar | I look forward to the day we can shove gcc in a blender and use clang for everything, because its so much better architected |
| 17:57:31 | BitPuffin | Skrylar: does not really have good widows support though unfortunately |
| 17:58:57 | dom96 | back |
| 18:00:24 | * | Matthias247 joined #nimrod |
| 18:01:37 | reactormonk | BitPuffin, DO? |
| 18:01:44 | dom96 | reactormonk: digital ocean |
| 18:02:05 | reactormonk | ah |
| 18:02:07 | * | brson joined #nimrod |
| 18:02:38 | reactormonk | doesn't look too shabby... any drawbacks? |
| 18:02:48 | BitPuffin | reactormonk: yes, mentioned above |
| 18:03:08 | Varriount | Skrylar: Last time I checked, Clang didn't have a 64 bit binary available for Windows. |
| 18:03:16 | reactormonk | BitPuffin, old kernel? |
| 18:03:38 | BitPuffin | reactormonk: yeah, they have their own custom kernels |
| 18:03:42 | BitPuffin | which is kind of painful |
| 18:03:51 | reactormonk | in which ways? |
| 18:04:08 | BitPuffin | well, you have to wait for them to update their kernel |
| 18:04:12 | BitPuffin | which can take quite some time |
| 18:04:27 | BitPuffin | it's not like they do it once a month |
| 18:04:29 | BitPuffin | it's more like |
| 18:04:32 | BitPuffin | once every millenium |
| 18:06:26 | dom96 | Will you guys get mad if I call the Github API using JS from lib.html? |
| 18:06:35 | BitPuffin | yes |
| 18:06:46 | reactormonk | dom96, huh? |
| 18:07:16 | BitPuffin | dom96: un-fucking-acceptable |
| 18:07:18 | dom96 | For the babel package listings. |
| 18:07:29 | BitPuffin | reactormonk: other draw back (related to this one) is that you can only use the distros they provide |
| 18:07:34 | dom96 | It's the easiest way to grab the contents of nimrod-code/packages/packages.json |
| 18:07:43 | BitPuffin | which is like: ubuntu, debian, centos and arch |
| 18:08:04 | BitPuffin | then they have preconfigured stuff for lamp and doku etc |
| 18:09:39 | dom96 | BitPuffin: I'm not sure whether you seriously have a problem with it or are trying to over exaggerate for lolz? |
| 18:10:34 | EXetoC | dom96: only JS via the backend is acceptable |
| 18:10:49 | dom96 | Yeah, that's what I mean. |
| 18:11:04 | EXetoC | o rly |
| 18:11:25 | BitPuffin | dom96: both |
| 18:11:30 | dom96 | I just wonder if calling the Github API is the best idea, since it's rate limited. |
| 18:11:48 | dom96 | Some people may get mad that lib.html is using up their Github API quota. |
| 18:13:05 | BitPuffin | what do you plan to call it for? |
| 18:13:20 | BitPuffin | you should write the javascript in nimrod and compile it to javascript |
| 18:13:31 | dom96 | Yes, that's what I am already doing! |
| 18:13:32 | BitPuffin | now that you are out of school you can finally improve the dom module |
| 18:13:42 | BitPuffin | it's your responsibility for fucks sake |
| 18:13:48 | BitPuffin | because it's named after you |
| 18:13:54 | Araq | true |
| 18:14:29 | dom96 | I plan to call it to get the contents of package.json from the git repi |
| 18:14:31 | dom96 | *repo |
| 18:14:40 | dom96 | *packages.json |
| 18:15:22 | BitPuffin | dom96: couldn't you just like, call for the raw file or something? |
| 18:15:45 | dom96 | I can't just dowload files using JS |
| 18:15:49 | dom96 | *download |
| 18:15:53 | dom96 | god I can't type today |
| 18:15:56 | BitPuffin | https://raw.githubusercontent.com/nimrod-code/packages/master/packages.json |
| 18:16:01 | Araq | dom96: no way. eating up github's API quota is a showstopper |
| 18:16:08 | BitPuffin | dom96: that's not a file |
| 18:16:08 | dom96 | ughhh |
| 18:16:20 | BitPuffin | or maybe it is |
| 18:16:29 | BitPuffin | lol |
| 18:16:33 | dom96 | Araq: How else do you suggest I do it then? |
| 18:16:36 | Araq | download it with a small nimrod program that's run every day |
| 18:16:44 | Araq | and cache the result |
| 18:17:06 | BitPuffin | dom96: doing a curl request gave me the data only |
| 18:17:10 | BitPuffin | so no downloading of files |
| 18:17:17 | BitPuffin | it's just a regular http request if you use what I said |
| 18:17:37 | dom96 | BitPuffin: You can't do regular HTTP requests in JS |
| 18:17:51 | BitPuffin | dom96: yes you can, idiot |
| 18:17:53 | BitPuffin | :P |
| 18:17:55 | dom96 | how? |
| 18:18:00 | BitPuffin | it's like |
| 18:18:04 | BitPuffin | xhttprequest or something |
| 18:18:07 | BitPuffin | or xmlhttprequest |
| 18:18:09 | BitPuffin | use google |
| 18:18:11 | BitPuffin | :P |
| 18:18:24 | dom96 | hrm |
| 18:18:41 | Araq | yeah, what BitPuffin says. ordinary downloads are possible with JS, otherwise Ajax couldn't work |
| 18:18:44 | BitPuffin | dom96: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest |
| 18:19:06 | BitPuffin | Do you even JS brah??!? |
| 18:22:49 | dom96 | "XMLHttpRequest is subject to the browser's same-origin policy: for security reasons, requests will only succeed if they are made to the same server that served the original web page." |
| 18:23:33 | Araq | good point |
| 18:23:42 | dom96 | :P |
| 18:27:16 | dom96 | I guess i'll make NimBuild download it then. |
| 18:30:12 | Araq | Varriount will be pleased to see NimBuild gained yet another feature :P |
| 18:30:53 | Skrylar | you people who don't have to write dependency hell for their projects to be useful :F |
| 18:31:08 | BitPuffin | dom96: wat, I've used it to do requests to other URLs |
| 18:31:15 | BitPuffin | maybe it is to some other place |
| 18:35:08 | BitPuffin | dom96: there is also something in jquery |
| 18:35:14 | BitPuffin | that is quite nice |
| 18:36:08 | dom96 | No way, i'm not depending on jQuery. |
| 18:36:30 | dom96 | And I doubt it can do cross-site requests. |
| 18:36:56 | BitPuffin | dom96: guess it depends lol |
| 18:37:06 | EXetoC | LOL |
| 18:37:13 | BitPuffin | generally people probably block cross site requests |
| 18:37:43 | BitPuffin | dom96: however I don't think cross site requests are blocked for the raw link I showed you |
| 18:37:50 | BitPuffin | it's probably more for login pages etc |
| 18:38:07 | dom96 | Anything with a different host is: http://en.wikipedia.org/wiki/Same-origin_policy |
| 18:38:42 | Skrylar | what exactly is the problem you're trying to solve here again? |
| 18:40:18 | dom96 | babel package listings in lib.html |
| 18:41:52 | Skrylar | don't packages have to be put in a static roster for that anyway? at that point you should just static-gen the html for that page |
| 18:45:14 | BitPuffin | dom96: are you sure GET requests are not allowed? |
| 18:45:35 | dom96 | That's what Wikipedia says. |
| 18:45:36 | BitPuffin | dom96: lots of people seem to be doing it |
| 18:45:46 | BitPuffin | dom96: stop fucking reading wikipedia and just try it you noob |
| 18:45:51 | BitPuffin | it's not like it's a lot of code :P |
| 18:46:22 | Skrylar | but but, the mozilla implementation page isn't a valid primary source for cross site scripting rules! |
| 18:46:28 | Skrylar | it's gotta be published in wall street journal! |
| 18:46:32 | BitPuffin | :O |
| 18:47:10 | Skrylar | Actually I kind of wonder how anything comp-sci related gets on Wikipedia. Technically the implementor is the highest authority on their implementation, but wikimedia commons says the person who did it / wrote it is not a valid source |
| 18:47:25 | Skrylar | So arguably, nobody is actually a valid source on cross site scripting |
| 18:47:55 | Skrylar | it would have to come out of the ECMA or IEEE which aren't interested in the particulars of Chrome/Opera/Gecko |
| 18:51:03 | BitPuffin | either way |
| 18:51:06 | BitPuffin | I've done it before |
| 18:51:09 | BitPuffin | and others seem to be doing it |
| 18:51:18 | BitPuffin | I think it's probably for certain types of objects |
| 18:51:30 | Skrylar | you can make xml requests across websites but there are specific rules for it |
| 18:51:49 | Skrylar | its something like a script from the originating domain is allowed to call to another domain, but its not recursive |
| 18:52:17 | Skrylar | e.g. blah.com/foo.js is allowed to ask for blah-assets.com/stuff.png, but it could not ask for blah-assets.com/stuff.js which further asks for foobar.com/things.js |
| 18:52:42 | Skrylar | facebook buttons and google +1s work this way IIRC |
| 18:55:02 | BitPuffin | well alright then we are set |
| 18:55:05 | BitPuffin | dom96: do it |
| 18:55:06 | BitPuffin | naab |
| 18:55:19 | dom96 | Doesn't seem to be working. |
| 18:58:12 | BitPuffin | dom96: noob |
| 18:58:37 | EXetoC | have you turned it on and off again? |
| 18:58:37 | * | psquid_ joined #nimrod |
| 18:59:32 | Trixar_za | Somehow I'm reminded of The IT Crowd |
| 18:59:59 | * | psquid quit (Ping timeout: 250 seconds) |
| 19:02:17 | * | io2 joined #nimrod |
| 19:14:39 | * | bjz joined #nimrod |
| 19:15:12 | * | Jesin joined #nimrod |
| 19:16:07 | NimBot | nimrod-code/nimbuild master a259f7e Dominik Picheta [+0 ±1 -0]: Website: Implemented serving of packages.json. |
| 19:19:09 | Jesin | I heard something about "I tried to fool Rust into accepting such dangerous code by making it increasingly more complicated, but it kept on finding about the aliases and producing an error" was posted in this channel? |
| 19:19:31 | * | Jesin would like to see the code that did that |
| 19:19:34 | Araq | hi Jesin welcome |
| 19:19:43 | Jesin | err, *the code that was used for that |
| 19:19:45 | Jesin | hi Araq |
| 19:20:12 | flaviu | Jesin: That was zahary_ |
| 19:20:33 | Jesin | hm, alright |
| 19:23:40 | BitPuffin | he seems to be afk |
| 19:24:41 | Jesin | aw. |
| 19:25:37 | Jesin | hmm |
| 19:26:08 | EXetoC | he copied that quote so he might know who it was :p |
| 19:27:26 | Araq | Jesin: I assume you're a Rust core dev then? |
| 19:27:41 | Jesin | nope |
| 19:28:01 | Jesin | I'm just really curious about the language at this point |
| 19:28:01 | bjz | Araq: apparently there is a spy in your midst |
| 19:28:01 | bjz | :) |
| 19:28:41 | Araq | hi bjz yeah well. I know about brson and bstrie |
| 19:28:51 | bjz | hahaha |
| 19:28:51 | Jesin | hm, Nimrod looks kind of interesting too |
| 19:29:01 | bjz | indeed |
| 19:29:16 | * | bjz thinks nimrod looks cool too |
| 19:29:31 | Araq | thanks |
| 19:29:41 | bstrie | Araq: it was meeee |
| 19:30:11 | bjz | Araq: "thanks"? did I compliment your work then? |
| 19:30:11 | EXetoC | oh. lol reporting everything |
| 19:30:31 | Jesin | I wonder how the type systems compare |
| 19:30:31 | bstrie | Araq: also, we don't even have any alias analysis at this point. theoretically we could, but because of unfortunate implementation decisions it will take a while to get there |
| 19:30:56 | Araq | bstrie: er ... what? we have alias analysis ... |
| 19:30:56 | Skrylar | isn't that part of the effect tracker |
| 19:31:11 | Araq | currently we only use it to produce better code though |
| 19:31:11 | Jesin | bstrie: which "we" is this? |
| 19:31:11 | bjz | what does "alias analysis" mean? |
| 19:31:11 | bstrie | Araq: I mean "we" as in rust |
| 19:31:36 | bstrie | bjz: I'm using it to mean optimizations based on e.g. "restrict" |
| 19:31:36 | Jesin | Huh, that's weird |
| 19:31:36 | bjz | "it kept on finding about the aliases and producing an error" |
| 19:32:01 | bjz | bstrie: I am still confused |
| 19:32:01 | Araq | bjz: I'm the inventor, yes |
| 19:32:11 | * | bstrie pummels bjz |
| 19:32:11 | Jesin | Pointer aliasing, you mean? |
| 19:32:11 | bjz | Araq: awesome! |
| 19:33:01 | bstrie | rust doesn't really seek to track aliases so much as it tracks ownership, aliasing info just sort of falls out from that. but we're not *using* that aliasing info to the best of our ability and it makes me sad |
| 19:33:18 | bjz | Araq: a huge effort I must say. also, I know it's probably the most uninteresting bit of the language, but +1 for using `proc` as opposed to `function` |
| 19:33:45 | Jesin | oh nice |
| 19:33:56 | flaviu | bjz: According to the docs, func was supposed to be sugar for proc {.nosideeffects.} |
| 19:34:03 | bstrie | bjz: traitor! :) |
| 19:34:05 | Jesin | yeah good decision for an imperative "function" :p |
| 19:34:12 | Jesin | flaviu: niiice ^_^ |
| 19:34:30 | Skrylar | wait |
| 19:34:35 | Skrylar | i remember bjz |
| 19:34:47 | Skrylar | #rust-gamedev? |
| 19:34:59 | bstrie | the same |
| 19:35:07 | Jesin | hmm, I'm curios, what advantages does Rust have over Nimrod? |
| 19:35:19 | Skrylar | paid developers lol |
| 19:35:27 | BitPuffin | pretty much |
| 19:35:33 | bjz | Skrylar: the same |
| 19:35:42 | bjz | Skrylar: I like languages in general though |
| 19:36:02 | Skrylar | that said, rust's "0.9" version label is a ruse... they break the damn syntax every release |
| 19:36:18 | bstrie | Skrylar: we're on 0.10 now! :P |
| 19:36:24 | Skrylar | wheee |
| 19:36:40 | Skrylar | that's okay, they'll decide in 0.11 that function declarations have to be written backwards |
| 19:36:48 | Jesin | How's that a "ruse"? They state outright that the language including syntax is unstable |
| 19:36:56 | bstrie | Skrylar: brb submitting an rfc for that |
| 19:37:06 | Matthias247 | Jesin: you could have at least wrote "what advantages does Nimrod have over Rust" in this channel when you do it the other way around in the rust channel :-) |
| 19:37:14 | flaviu | Another advantage is a modular stdlib, I hate having all the stuff in system |
| 19:37:23 | bjz | Araq: just curious, has Rust made any impacts on your work on Nimrod? I know Nimrod takes quite a different approach to systems programming though, just thought it would be interesting. |
| 19:37:35 | Jesin | Matthias247: well the major obvious one is the macro system |
| 19:37:48 | EXetoC | I hate importing common stuff everywhere |
| 19:38:12 | bjz | Araq: I know Rust could probably learn some stuff from Nimrod |
| 19:38:28 | Jesin | bjz: and I really hope they do |
| 19:38:43 | Araq | Rust excels at memory safety, afaict. Nimrod ... not so much :-) but it's mostly edge cases that might as well exist in Rust too |
| 19:38:52 | Matthias247 | Jesin: I think a major thing is that Rust does a lot more to enforce safety. But it's therefore also a lot harder to program |
| 19:39:06 | flaviu | EXetoC: When system is 3000+ lines, I think there's a problem |
| 19:39:25 | bjz | Araq: Nimrod seems really nice in the metaprogramming side of things - I'm guessing that was your main goal though, right? |
| 19:40:00 | Jesin | Matthias247: I consider that a net positive from what I've seen. |
| 19:40:06 | flaviu | bjz: Nimrod even has a virtual machine to execute everything needed at compile time |
| 19:40:41 | Skrylar | you can make safe code in nimrod; IIRC the tag and effect system is supposed to help with that |
| 19:41:01 | Araq | bjz: yeah but one could also say I wanted an Ada with resizable datatypes ... |
| 19:41:10 | Skrylar | ada \o/ |
| 19:41:12 | Jesin | flaviu: this is sounding more and more like a systems-programming version of Lisp with a little bit more syntax. |
| 19:41:17 | Matthias247 | Jesin: a positive for rust? I think it depends on who you are and what you try to do. Trying to do event driven programs in Rust will probably drive you crazy faster than you think :) |
| 19:41:42 | Skrylar | Jesin: well it doesn't have the lispy property of code and data having the same syntax, but.. |
| 19:42:01 | Araq | that was a *very* concious design decision though. |
| 19:42:22 | flaviu | Skrylar: I came across a module in the compiler that renders ASTs to code, so it comes close |
| 19:42:56 | Araq | even in Nimrod, most code is not meta programming code and so optimizing the syntax for meta programming seems like a poor tradeoff |
| 19:43:26 | Jesin | Araq: agreed, Nimrod syntax looks pretty nice |
| 19:43:32 | Skrylar | i like Io's syntax which is basically Lisp shoved over one parenthesis |
| 19:43:43 | Skrylar | nimrods syntax is nice too, even if i'm a tab user |
| 19:44:17 | Araq | people simply don't know how to ask for a feature... |
| 19:44:36 | Skrylar | I also found you can do interesting things with immediate macros and poking around with the AST |
| 19:44:39 | Jesin | Araq: hm? how so? |
| 19:44:54 | Araq | ask politely and I might add tab support |
| 19:45:07 | Skrylar | i figured it was a conscious decision |
| 19:45:20 | Araq | but most people instead are like "omg how retarted, I will never use nimrod" |
| 19:45:27 | Skrylar | autocmd *.nim set sts=3 :B |
| 19:45:31 | Skrylar | well, 2 |
| 19:45:40 | bjz | Araq: Nimrod seems to be quite a comprehensive language now - do you see much room for further additions/changes? |
| 19:45:44 | Araq | Skrylar: yeah well. mixing tabs and spaces would still be disallowed |
| 19:46:01 | Skrylar | Araq: moonscript's docs just says that a tab is worth four spaces, right next to "but you shouldn't do this" |
| 19:46:31 | Skrylar | i tossed in autocommands to vim so i don't have to deal with it, and then carried on |
| 19:46:35 | Araq | Skrylar: quite like python then and Guido said it was a mistake. |
| 19:46:36 | EXetoC | but now you have to go back and forth between projects |
| 19:46:38 | Jesin | I like the idea of allowing tabs and spaces but disallowing the mixing of them |
| 19:46:39 | EXetoC | very annoying |
| 19:47:00 | flaviu | I like to mix tabs and spaces, but only in a very structured way |
| 19:47:11 | Skrylar | i almost considered a wrapper for FLTK in the interim... this structural work is driving me insane |
| 19:48:18 | bjz | Araq: I would stick to your guns re. spacing. one or the other but not both. say 'it was a coin toss, and spaces one. end of story' |
| 19:48:52 | Skrylar | i'm a fan of the elastic tabstop, but there's like zero editor support for that |
| 19:48:55 | BitPuffin | Araq: the gain is that when we wanna do non safe stuff in nimrod memory wize the language doesn't stand the fuck in our way :P |
| 19:48:55 | bjz | Araq: even though you know it wasn't a coin toss :D |
| 19:49:01 | bjz | Skrylar: +1 |
| 19:49:17 | Jesin | flaviu: yeah, when you can use any positive tab width and have the code parse the same way, it's fine. Anything else, nope. |
| 19:49:19 | BitPuffin | Araq: are those ada types like the DST stuff that rust is getting? |
| 19:49:23 | BitPuffin | (dynamically sized types) |
| 19:49:51 | Araq | bjz: nimrod is quite a bit bigger than it looks but "comprehensible" still fits, imho anyway. |
| 19:50:11 | BitPuffin | Araq: please, never add tabs xD |
| 19:50:18 | Jesin | BitPuffin: when you want to do unsafe stuff in Rust you just put it inside "unsafe { ... }" and the language gets out of your way. :p |
| 19:50:33 | BitPuffin | Jesin: well having to do unsafe {} = getting in the way |
| 19:50:55 | BitPuffin | in nimrod you just use ptr instead of ref |
| 19:50:56 | BitPuffin | done |
| 19:50:57 | flaviu | Yeah, I like tabs, but having the language decide style seems like the clearest method. |
| 19:51:01 | Skrylar | we have ref too |
| 19:51:05 | Skrylar | but thats for GC stuff |
| 19:51:16 | EXetoC | and having a column limit gets weird when tabs are involved |
| 19:51:31 | BitPuffin | EXetoC: column limit? |
| 19:51:34 | BitPuffin | you mean in the editor right |
| 19:51:37 | BitPuffin | not the language |
| 19:51:41 | Araq | bjz: we have many feature wrt concurrency and parallelism in the pipeline |
| 19:51:42 | Jesin | EXetoC: having a column limit is weird whether or not tabs are involved. |
| 19:52:03 | bjz | Araq: Are nimrod's templates duck typed, like in C++ or D? |
| 19:52:15 | BitPuffin | bjz: yes |
| 19:52:21 | bjz | Araq: ie. error happens within the expansion |
| 19:52:22 | Jesin | BitPuffin: oh goodness, 10 extra characters, so *arduous* :p |
| 19:52:32 | BitPuffin | Jesin: yes |
| 19:52:48 | Araq | nimrod's templates are big quasi quotes, but nimrod's generics are duck typed and very macro like |
| 19:52:51 | BitPuffin | Jesin: no but it's just, it makes it retarded |
| 19:53:11 | Jesin | BitPuffin: I prefer the safety guarantees. |
| 19:53:29 | Araq | I tried to unify generics and macros but failed :-) |
| 19:53:38 | Araq | long ago. |
| 19:53:39 | BitPuffin | Jesin: because what if on one line I do something unsafe, then next I do something safe, then on the next two lines I do unsafe stuff, and then next line I do safe |
| 19:53:54 | bjz | Araq: so nimrod templates are sort of more like template haskell? and generics are like C++ templates? |
| 19:53:54 | BitPuffin | Jesin: if I really wanted safety guaranntees when doing the safe stuff I wouldn't wanna put it inside unsafe |
| 19:53:59 | Jesin | BitPuffin: So? Just enclose the whole block in an "unsafe { ... } " |
| 19:54:06 | bjz | Araq: looking through atm |
| 19:54:34 | BitPuffin | so what you'd do is unsafe { stuff(); } stuff2(); unsafe { stuff3(); stuff4(); } stuffs(); unsafe { stuffs2(); } |
| 19:54:50 | Araq | Jesin: afaict it depends on how much interfacing you need to do with C and C++ |
| 19:55:33 | Araq | nimrod strives for superb compatibility and so an explicit 'unsafe' block would do more harm than good |
| 19:55:34 | BitPuffin | Jesin: and you get safety guarantees if you just don't use ptr or pointer |
| 19:55:42 | Jesin | BitPuffin: seems better than just never having safety guarantees. What oes nimrod give you? |
| 19:56:05 | Jesin | Araq: hm, alright then... |
| 19:56:16 | Araq | nimrod is safe, unless you use unsafe features. unsafe features all use keywords and so are easy to grep |
| 19:56:23 | bjz | Araq: by compatibility you mean between back-ends? |
| 19:56:47 | Araq | binary and even source compatibility |
| 19:56:58 | Araq | check out the .emit pragma |
| 19:57:32 | Skrylar | the impression i get is that rust assumes you are an idiot and wants to beat you with a stick every time you think about machine code |
| 19:57:40 | EXetoC | Jesin: I want to know that I can put a certain amount of editors in a row |
| 19:57:47 | Skrylar | nimrod assumes you are a genius and if you want safety you turn it on for that code |
| 19:58:02 | EXetoC | but some people run their IDEs in fullscreen and so probably don't care too much |
| 19:58:06 | BitPuffin | Jesin: like I said, you get safety if you stay away from pointer and ptr |
| 19:58:16 | BitPuffin | and cast |
| 19:58:43 | Jesin | Skrylar: Oh, you can turn it on, though? |
| 19:59:03 | Skrylar | Jesin: yeah, you can say {.noSideEffects.} and it disallows any pointer code that affects something which isn't an input parameter |
| 19:59:14 | Skrylar | if something isnt 'var', you can't addr() it |
| 19:59:25 | Skrylar | if you set noSideEffects, you can't use globals |
| 19:59:46 | Skrylar | if you have DSP code that isn't allowed to use interrupts, you can tag it so only a set of functions may be used in it |
| 20:00:12 | bjz | Araq: what's the difference between a macro and a template? |
| 20:00:14 | Araq | what's also commonly overlooked is that nimrod's way makes it an excellent choice for scripting too |
| 20:00:27 | Skrylar | bjz: levels |
| 20:00:29 | Araq | imho anyway |
| 20:00:34 | Jesin | oh interesting. |
| 20:00:38 | Skrylar | bjz: a template is kind of like a type-safe #define |
| 20:00:43 | Skrylar | bjz: a macro receives the actual AST |
| 20:00:47 | BitPuffin | Araq: would be kinda cool if noSideEffects could get pushed and popped |
| 20:00:59 | bjz | Skrylar: so templates don't work on the AST? |
| 20:01:03 | BitPuffin | maybe it can |
| 20:01:04 | BitPuffin | hm |
| 20:01:07 | Jesin | Skrylar: but {.noSideEffects.} can affect things that are input parameters? |
| 20:01:20 | Skrylar | bjz: i can (and have) made a macro, set to immediate, so that it receives completely illegal nimrod code and then i can use nimrod code to translate it in to valid code |
| 20:01:44 | Skrylar | Jesin: yes, if they are 'var' |
| 20:01:49 | flaviu | Jesin: Most things are immutable, yes, if the parameters are var |
| 20:01:56 | Araq | you guys should watch my talk ... templates are declarative, macros are imperative |
| 20:01:58 | Skrylar | Jesin: 'var' means that parameter is mutable, so editing it is not a side effect, its an effect |
| 20:02:03 | Jesin | Skrylar: sounds like rust's "mut" |
| 20:02:09 | Jesin | Nice |
| 20:02:28 | Skrylar | nosideeffect is also contageous |
| 20:02:44 | Skrylar | e.g. if you call a function which then uses globals it goes "nope this has side effects, you cant have it" |
| 20:03:04 | bjz | flaviu: by immutable do you mean 'immutable' or 'const'? |
| 20:03:05 | Jesin | Skrylar: well of course, it'd be useless if it didn't do that :p |
| 20:03:10 | flaviu | unless its debugEcho, which has magic |
| 20:03:17 | Skrylar | magic is magic. :P |
| 20:03:37 | Skrylar | Jesin: anyway, AFAIK most of the safety from Rust is supposed to fit under effect tracking in nimrod |
| 20:03:58 | Skrylar | though we have an obedient GC |
| 20:04:23 | flaviu | bjz: Const means fixed a compile time, so I think I mean immutable. I'm not 100% clear on the semantics of mutability |
| 20:04:37 | Jesin | It sounds like Rust does have a lot to learn from Nimrod... |
| 20:05:07 | bjz | flaviu: immutable means that nobody can change it, const means only you can't change it, but others can |
| 20:05:56 | dom96 | Guys, I changed the nginx config for nimbuild a bit so if you can't access the docs or the irclogs then please let me know. |
| 20:10:24 | flaviu | Sorry, not familiar with rust. If the caller declares the variable as var and passes it as a non-var parameter, the variable is rust's cost. If the caller declares it as a let, then it is rust's immutable. |
| 20:10:52 | bjz | flaviu: Rust doesn't have const |
| 20:11:20 | bjz | flaviu: sorry - I'm talking about the semantics of const in C or C++ |
| 20:11:43 | EXetoC | BitPuffin: you use `~=`, but apparently we have `=~` in the standard library. it can be confusing |
| 20:11:50 | flaviu | Oh, then s/rust/c/ |
| 20:11:51 | EXetoC | I prefer the former though |
| 20:12:16 | Araq | flaviu: system.nim is 3000 lines but not all of it needs to be in there, many things are just for convenience in system |
| 20:13:16 | Araq | also nimrod does declare + for integers in its system, Rust has it builtin, so it's an unfair comparison |
| 20:13:43 | EXetoC | indeed |
| 20:13:52 | BitPuffin | EXetoC: that's your fault lol |
| 20:17:30 | flaviu | Araq: I'd split it up into several modules, which could be all included in system |
| 20:17:54 | Araq | flaviu: feel free and make a PR |
| 20:18:18 | flaviu | Ok, that sounds good |
| 20:19:33 | Araq | the docgen used to not follow include files, so it had to be 1 single file. That's the major reason for the way it is now. |
| 20:20:32 | EXetoC | you didn't say anything about include. I said I didn't want to import common stuff all the time, but nothing will change in that regard then |
| 20:20:49 | * | Jesin quit (Quit: Leaving) |
| 20:22:43 | * | Jesin joined #nimrod |
| 20:26:05 | flaviu | Can I have babel use a custom compiler command? |
| 20:27:58 | Araq | I think so. dom96 ? |
| 20:28:20 | dom96 | No. |
| 20:28:42 | dom96 | What command do you want to run? |
| 20:29:56 | BitPuffin | dom96: nimrod penis |
| 20:30:21 | Araq | BitPuffin: consider this a warning |
| 20:30:58 | flaviu | dom96: I want to run nimrod_temp |
| 20:32:09 | dom96 | flaviu: So you want it to use a different compiler than the one that is in your PATH? |
| 20:32:27 | flaviu | Yes. I guess I can add it to my path |
| 20:32:55 | flaviu | But I'll see if I can do a PR |
| 20:32:57 | dom96 | You can rename it to nimrod and then add the dir its in temporarily to your path. |
| 20:33:30 | dom96 | I think the compiler that Babel uses should be overridable in its config file. But I still haven't implemented a config file heh. |
| 20:34:41 | BitPuffin | Araq: what? :D |
| 20:35:44 | EXetoC | use a different compiler when? |
| 20:36:35 | Araq | BitPuffin: too many offtopic random pointless unfunny remarks and I need to ban you. |
| 20:36:57 | flaviu | EXetoC: To check if my changes actually fix the bug |
| 20:36:58 | EXetoC | xd |
| 20:37:12 | BitPuffin | Araq: </3 |
| 20:37:16 | BitPuffin | you would neva :D |
| 20:37:58 | Araq | OrionPK already asked how many professional programmers are here, BitPuffin. Might be related? |
| 20:38:27 | BitPuffin | Araq: related to whom? |
| 20:38:45 | Araq | to your regression into a phase of your childhood |
| 20:38:47 | BitPuffin | I did say that I am |
| 20:38:50 | EXetoC | babel actually uses the compiler at some point? |
| 20:38:53 | BitPuffin | Araq: haha |
| 20:39:19 | BitPuffin | Araq: sorry dad ;_; |
| 20:39:19 | flaviu | EXetoC: Yes, https://github.com/nimrod-code/babel/blob/master/src/babel.nim#L286 |
| 20:39:45 | BitPuffin | bad humor is the bets kind |
| 20:40:19 | EXetoC | right, apps |
| 20:40:51 | EXetoC | it needs to be better bad humor |
| 20:41:30 | BitPuffin | EXetoC: it fluctuates |
| 20:41:50 | flaviu | BitPuffin: I doubt the jokes are helping your cause |
| 20:42:00 | BitPuffin | bad humor is more funny with the right tone though, kind of hard to achieve in irc |
| 20:42:03 | BitPuffin | flaviu: my cause? |
| 20:44:24 | flaviu | Not being banned. I probably shouldn't have said anything |
| 20:45:34 | BitPuffin | flaviu: probably shouldn't have, no. Thought you meant my cause of being a profesional programmers first so I was like wut |
| 20:46:06 | * | Skrylar distracts everyone with space muffins |
| 20:47:19 | NimBot | Araq/Nimrod devel 68b7779 Reimer Behrends [+0 ±1 -0]: Fixes various issues with shallow copying.... 11 more lines |
| 20:47:19 | NimBot | Araq/Nimrod devel 2ecff76 Araq [+0 ±1 -0]: master compiler compiles with devel |
| 20:47:19 | NimBot | Araq/Nimrod devel 03138cb René [+0 ±10 -0]: Optimized the size of PNG images. 172KB > 143KB... 2 more lines |
| 20:47:19 | NimBot | Araq/Nimrod devel 35efec4 Simon Hafner [+0 ±10 -0]: Merge pull request #839 from ReneSac/master... 2 more lines |
| 20:47:19 | NimBot | 6 more commits. |
| 20:53:00 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 20:53:19 | * | flaviu quit (Remote host closed the connection) |
| 20:57:22 | Amrykid | Varriount, but I am already here. lol |
| 21:04:40 | dom96 | Amrykid: context? |
| 21:06:28 | NimBot | nimrod-code/nimbuild master 00260c4 Dominik Picheta [+0 ±1 -0]: Builder: Binaries are now removed when switching branches.... 3 more lines |
| 21:06:41 | Amrykid | dom96, context -> https://github.com/Amrykid/nim-locale/issues/2 |
| 21:07:20 | * | flaviu joined #nimrod |
| 21:10:37 | * | gXen joined #nimrod |
| 21:27:16 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 21:27:30 | * | gXen quit () |
| 21:31:09 | Skrylar | is there a way to tell enum to not care about the defined order |
| 21:31:48 | * | askatasuna joined #nimrod |
| 21:32:06 | Araq | Skrylar: nope, there is a feature request though |
| 21:32:08 | Skrylar | its moaning about the enum items not being in sequential order, but its something taken in from C so I can't move them around without patching the C |
| 21:32:54 | * | flaviu quit (Ping timeout: 240 seconds) |
| 21:34:59 | EXetoC | you can't? |
| 21:35:28 | EXetoC | does the order matter at all in C? because you can't iterate over the members or anything |
| 21:35:31 | Skrylar | EXetoC: its a big enum from a C header thats comprised of those 'pack four bytes in to an int' wrapped in an enum |
| 21:35:57 | Skrylar | it looks like i could re-order them but its the wonderful pain in the ass of manually calculating out the bit masks to satisfy the pixelbitchy compiler. lol |
| 21:37:47 | Skrylar | time to pop open calc and let the spreadsheet do it, whee |
| 21:40:31 | Skrylar | I wish when one read about tutorials for things, they had more workflow tutorials than simple "this is how you push the button" |
| 21:41:02 | Skrylar | there's a ton of basic "here is how to push the button", and very few "instead of doing this huge amount of work, use this vim plugin to auto-align data to a tabular format and then paste it in calc to do X work for you" |
| 21:49:33 | * | flaviu joined #nimrod |
| 21:54:54 | * | Demos joined #nimrod |
| 21:54:59 | Demos | EXetoC: ping |
| 22:01:21 | EXetoC | Demos: hi |
| 22:03:03 | Demos | you did not seem to push your nim-glfw fixes to github... |
| 22:04:01 | EXetoC | what the hell? |
| 22:04:28 | Demos | I am seeing the last update as 8 days ago |
| 22:04:44 | Demos | and I did a babel install on the university computer I am using and my compile still failed |
| 22:05:19 | EXetoC | I'm pretty sure I pushed |
| 22:05:31 | EXetoC | worked this time |
| 22:07:34 | Demos | way to change the name of PWnd :D |
| 22:07:39 | Demos | %s for the win |
| 22:10:19 | EXetoC | someone didn't like wnd, and I guess I thought it was more common |
| 22:10:33 | Demos | I dont really care. |
| 22:11:00 | Skrylar | :| |
| 22:11:15 | Skrylar | "invalid order in enum" -> even though i went in calc and sorted everything by its final values |
| 22:11:20 | flaviu | EXetoC: What is the command to run the nimrod-code/mongo tests? |
| 22:12:39 | EXetoC | nimrod c -r module |
| 22:12:42 | Skrylar | time to throw it out the window and just override ord() |
| 22:12:42 | EXetoC | that's all |
| 22:13:49 | EXetoC | flaviu: but apparently the wrapper is outdated |
| 22:14:15 | flaviu | I know, I'm trying to see if I've fixed #1059 |
| 22:14:51 | flaviu | Oh, I have to babel install first |
| 22:20:58 | EXetoC | are you using that particular commit? |
| 22:21:03 | flaviu | Yes |
| 22:21:35 | flaviu | Ok, it works |
| 22:23:14 | Skrylar | ffff |
| 22:23:22 | Skrylar | ???(???, ???) Error: duplicate case label |
| 22:25:33 | Demos | does the docgen round constants! it says math.PI is 3.0 |
| 22:25:49 | EXetoC | that's precise enough |
| 22:28:18 | Demos | well clicking on "see source" (is that a new feature, I love it) gives me pi to absurd precision |
| 22:28:41 | flaviu | Nimrod seems to flatten the module hierarchy |
| 22:29:17 | Demos | even when I am compileing? If so I really like it |
| 22:29:28 | Demos | like even when I have a subdirectory in my project |
| 22:30:06 | EXetoC | what do you mean? |
| 22:30:07 | flaviu | Yes, but it has some odd sideeffects |
| 22:30:45 | flaviu | ./submod/a.nim and ./a.nim both get placed in the nimcache as a.c |
| 22:30:48 | Demos | I can not just randomly take the leading path off my imports |
| 22:31:16 | EXetoC | Demos: how's that related to flattening? |
| 22:31:26 | Demos | I honestly do not even know |
| 22:31:46 | Demos | just ignore me |
| 22:31:48 | EXetoC | :> |
| 22:41:37 | runvnc | does one of the web pages show babel packages now |
| 22:42:51 | dom96 | not yet |
| 22:44:01 | flaviu | So modules being flattened is a bug, right? |
| 22:46:17 | dom96 | flaviu: If you put a submod.babel file in the submod/ dir it should work |
| 22:47:32 | flaviu | Ok, that works |
| 22:47:35 | flaviu | thanks |
| 22:57:28 | * | Matthias247 quit (Quit: Matthias247) |
| 23:07:06 | NimBot | Araq/Nimrod devel 58e583e Dominik Picheta [+1 ±2 -0]: Implemented babel package list in lib.html. |
| 23:09:18 | * | askatasuna quit (Ping timeout: 240 seconds) |
| 23:09:33 | runvnc | wow that was fast lol |
| 23:10:21 | runvnc | is there a dev/latest version of the website, or maybe I can just load up lib.html from my local build |
| 23:11:17 | dom96 | yeah, it's here: http://build.nimrod-lang.org/docs/lib.html |
| 23:11:23 | dom96 | But you need to wait for it to build. |
| 23:11:39 | runvnc | great |
| 23:11:58 | dom96 | Also, it wasn't really fast. I've been working on that for the past 2 days. |
| 23:12:17 | runvnc | heh |
| 23:14:27 | flaviu | dom96: How does nimrod tag submodules? I assume that that happens after newModule? |
| 23:15:01 | dom96 | flaviu: I'm afraid I can't help you there. I don't know much about the inner working of the compiler. |
| 23:15:49 | flaviu | I thought you did because of the submodule.bable thing, thanks anyway |
| 23:21:46 | EXetoC | he's the babel author |
| 23:22:08 | dom96 | I just know about that because I argued about how modules with the same names should be handled in the compiler with Araq. |
| 23:22:44 | dom96 | runvnc: It's there now: http://build.nimrod-lang.org/docs/lib.html#babel :D |
| 23:23:15 | flaviu | Why is sdl part of the stdlib> |
| 23:23:17 | flaviu | ? |
| 23:23:41 | dom96 | because we have a graphics module which depends on it |
| 23:24:35 | flaviu | The module is pretty basic, it could be implemented in nimrod |
| 23:25:02 | flaviu | Except for fonts it looks like |
| 23:25:17 | runvnc | dom96: this is great |
| 23:25:48 | flaviu | Yes, its really nice |
| 23:26:13 | runvnc | I wonder if using README.md is the way to go for babel packages or if maybe generating and showing the normal stdlib style docs would be good |
| 23:26:22 | dom96 | :) |
| 23:26:31 | runvnc | although you pretty much have to link to the github or whatever |
| 23:26:43 | dom96 | Yeah, in the future we'll get docs generated for the babel packages. |
| 23:26:48 | flaviu | runvnc: I don't think that generating the docs for every package will scale |
| 23:27:12 | Demos | flaviu: hackage does it! |
| 23:27:14 | Demos | I think |
| 23:27:19 | dom96 | Yeah, hackage does. |
| 23:27:45 | dom96 | But because babel packages are on github we have no way of knowing when someone updates them. |
| 23:28:01 | dom96 | On hackage, packages are submitted to it. |
| 23:28:22 | Demos | wel could use push hooks, or actually change thing where you have to submit a new version when you update |
| 23:28:30 | runvnc | I wonder if the package maintainer could generate the doc |
| 23:28:49 | flaviu | dom96: Hooks would work |
| 23:28:51 | runvnc | then use the same githubuserpages or rawcontent or whatever you used to access the packages.json |
| 23:28:51 | dom96 | yeah, push hooks would work. |
| 23:29:06 | dom96 | As long as the package maintainer isn't too lazy to add the push hook heh |
| 23:29:12 | flaviu | https://api.github.com/hooks cia |
| 23:29:16 | runvnc | you dont need a hook |
| 23:29:21 | flaviu | literally the cia hook |
| 23:29:36 | runvnc | just have it so that the package maintainer places an html file called doc.html or something |
| 23:29:48 | runvnc | and then use the same method you used to retrieve the packages.json |
| 23:30:12 | dom96 | nah, the docs are generated. They shouldn't be committed. |
| 23:30:19 | * | darkf joined #nimrod |
| 23:31:24 | flaviu | dom96: Can't it be done automaticly? |
| 23:31:33 | flaviu | https://developer.github.com/v3/repos/hooks/#create-a-hook |
| 23:32:00 | runvnc | strider cd creates hooks automatically, but first you have to connect your github account |
| 23:32:14 | runvnc | i dont remember if it uses oauth or just username password or what |
| 23:32:33 | dom96 | Indeed. You need access to their github account. |
| 23:32:48 | dom96 | Also what about bitbucket? |
| 23:33:21 | dom96 | I guess they have hooks nowadays too |
| 23:33:33 | dom96 | But i'm sure people will start using other sites. |
| 23:35:30 | runvnc | I guess you are off client-side, but I think you could actually do all of it in the browser, if the highlite or whatever packages could be compiled to js |
| 23:35:46 | runvnc | but that is the last I will say about client-side heh |
| 23:36:07 | flaviu | Doing it client-side doesn't sound like a good idea |
| 23:36:20 | EXetoC | you just need the URL to the actual repository |
| 23:36:27 | flaviu | maybe just poll github every few minutes? |
| 23:36:37 | EXetoC | and then some engines for the most common version control systems |
| 23:38:00 | dom96 | polling generally doesn't scale |
| 23:38:34 | flaviu | Every 10 minutes should be fine, and use conditional requests so that you don't run against rate limits |
| 23:38:43 | EXetoC | you have to fetch the whole repo, right? that might be a problem |
| 23:38:58 | EXetoC | not now but later |
| 23:40:19 | runvnc | if there was a babel publish or babel update command, that could be a time to do it, so like with npm, the package authori would indicate with that command that the package has been modified |
| 23:41:14 | runvnc | although not suggesting that generally you would want to follow all of npms ideas lol |
| 23:41:34 | runvnc | they were storing all of the package files in a giant couchdb heh |
| 23:44:00 | dom96 | I think dub packages are stored on github too |
| 23:44:09 | dom96 | the DUB registry manages to track them |
| 23:44:59 | dom96 | Recreating the DUB registry for Babel sounds like a great project, any takers? :P |
| 23:49:25 | runvnc | Im trying to find something that explains how to use dub |
| 23:52:00 | runvnc | hm it says 'the repository will be monitored for changes and new version tags'. about twice per hour, the repository will be queried for new tags and any detected version will be made available on the registry' |
| 23:54:07 | runvnc | https://github.com/user/repository/raw/branch/filename |
| 23:54:43 | * | Demos quit (Quit: leaving) |
| 23:57:09 | * | Automatic joined #nimrod |
