| 00:02:32 | * | brson quit (Read error: Connection reset by peer) |
| 00:07:30 | * | awestroke quit (Remote host closed the connection) |
| 00:13:39 | dom96 | Araq: So do you want it to raise an exception then? |
| 00:28:01 | * | q66 quit (Quit: Leaving) |
| 00:44:44 | * | io2 quit () |
| 00:55:00 | * | Varriount quit (Read error: Connection reset by peer) |
| 01:03:22 | * | Varriount joined #nimrod |
| 01:22:21 | * | brson joined #nimrod |
| 01:45:02 | * | runvnc joined #nimrod |
| 01:46:35 | * | flaviu quit (Remote host closed the connection) |
| 01:59:18 | * | Kelet joined #nimrod |
| 01:59:45 | Kelet | Any IRC clients in Nimrod? J/w |
| 02:01:16 | fowl | do bots count as clients |
| 02:01:38 | Kelet | i'd be interested in seeing bots too but was mainly wondering about clients |
| 02:05:24 | fowl | someone is working on a client |
| 02:14:32 | * | brson_ joined #nimrod |
| 02:17:18 | * | brson quit (Ping timeout: 240 seconds) |
| 02:19:13 | * | brson_ quit (Client Quit) |
| 02:19:20 | * | brson joined #nimrod |
| 03:15:37 | NimBot | nimrod-code/packages master 61d40ea Jason Livesay [+0 ±1 -0]: Add redissessions |
| 03:15:37 | NimBot | nimrod-code/packages master 0692cb8 Billingsly Wetherfordshire [+0 ±1 -0]: Merge pull request #52 from ithkuil/master... 2 more lines |
| 03:23:38 | * | brson quit (Ping timeout: 240 seconds) |
| 03:24:33 | Skrylar | meep! |
| 03:26:29 | fowl | hola |
| 03:48:30 | Skrylar | time to install an SSD that has been sitting around for a year :B |
| 03:48:46 | BitPuffin | Well, got level loading working but no rendering yet |
| 03:49:23 | BitPuffin | that's more or less literally the next step |
| 03:49:43 | fowl | are you doing LD |
| 03:49:47 | BitPuffin | yeah |
| 03:49:49 | BitPuffin | mini LD |
| 04:00:31 | fowl | what you using, sdl? |
| 04:01:39 | BitPuffin | Araq: would you be opposed to something like this? https://gist.github.com/BitPuffin/9718515 the handyness of the syntax doesn't shine in that example, but imagine the when clusterfuck that could be created if you where doing like types within types stuff and have to put inline when statements. This way you could put all your platform specific code within one when block |
| 04:01:43 | BitPuffin | fowl: no, allegro |
| 04:02:13 | fowl | you know you can use when: inside a type def right |
| 04:02:41 | BitPuffin | fowl: yes and I addressed it in what I said |
| 04:03:19 | BitPuffin | I said that it becomes a when clustefuck when you have types within types etc and this way you can put all platform specific code in one big when block instead of multiple scattered ones |
| 04:03:25 | BitPuffin | fowl: I shouldn't have to type things twice |
| 04:04:04 | BitPuffin | it's breaking the DRY principle :P |
| 04:04:39 | fowl | i dont see how this solves anything |
| 04:04:49 | BitPuffin | it solves code organization |
| 04:05:05 | BitPuffin | generally what you'd use this for is for module private variables that you put for your platform specific stuff |
| 04:05:16 | fowl | by scattering a type definition across the whole file instead of one place |
| 04:05:39 | BitPuffin | fowl: yes because you only care about the real type definition generally, except for in the platform specific when block |
| 04:05:59 | BitPuffin | somebody reading the code doesn't wanna know that privately there is a bla veriable in windows that they can't access anyway |
| 04:06:15 | BitPuffin | or like 12 variables all over the place |
| 04:06:16 | fowl | speak for yourself |
| 04:06:31 | fowl | lol |
| 04:06:36 | fowl | this is not good design anyways |
| 04:06:54 | fowl | a better way to is create an api that each platform implements |
| 04:07:26 | BitPuffin | well if you want to I can code together a type block that shows what the difference would be with something more complex |
| 04:07:32 | BitPuffin | fowl: well smartass that's exactly what this is for |
| 04:08:07 | fowl | BitPuffin, it doesnt solve anything, everywhere you use tfoo you have to have to account for all three platforms |
| 04:10:18 | BitPuffin | fowl: no because this is mainly for private shi |
| 04:10:20 | BitPuffin | t |
| 04:10:22 | BitPuffin | fowl: refresh the gist |
| 04:11:07 | BitPuffin | publicly, there is one API, but behind the scenes there is platform specific things being taken care of |
| 04:11:34 | fowl | well wouldn't you think itd be even cleaner if each platform had its own module |
| 04:11:52 | BitPuffin | fowl: Well sure but I wouldn't be able to add to the type |
| 04:12:04 | BitPuffin | and I wouldn't be able to use shared private stuff |
| 04:12:13 | BitPuffin | like things that I would put in the original type section |
| 04:12:19 | BitPuffin | but is not exported |
| 04:12:28 | BitPuffin | but a shared property for all procs/methods |
| 04:12:52 | BitPuffin | it's also funny coming from the everything in one repo and everything in one file guy :P |
| 04:13:06 | fowl | i dont think you understand what im saying |
| 04:13:17 | BitPuffin | fowl: I do |
| 04:13:39 | BitPuffin | fowl: that way you would have to redefine the stuff all the time |
| 04:13:45 | fowl | no |
| 04:13:52 | BitPuffin | it would be the same as if you did when defined(windows): type TFOO .... |
| 04:13:55 | BitPuffin | and repeat yourself |
| 04:14:02 | BitPuffin | for each platform |
| 04:14:15 | fowl | ..no |
| 04:14:22 | BitPuffin | well then be more clear |
| 04:14:45 | BitPuffin | it's also stupid to have have to have a TFooExtras property or whatever |
| 04:14:52 | fowl | https://github.com/LaurentGomila/SFML/blob/master/src/SFML/Window/WindowImpl.hpp |
| 04:15:41 | fowl | windowimpl is implemented for x11, quartz, windows, most of the functions in window are direct call into the windowimpl |
| 04:17:33 | BitPuffin | well that's exactly the TFooExtras bullshit I was talking about |
| 04:17:41 | BitPuffin | and I think that's worse design |
| 04:17:53 | fowl | ok |
| 04:17:55 | BitPuffin | well in essence it's the same |
| 04:18:06 | BitPuffin | but that becomes scattered |
| 04:19:53 | BitPuffin | I don't want to make 8 files per module just to run on all PC platforms and consoles and handlelds and probably more with mobile |
| 04:20:08 | fowl | 8 files per module |
| 04:20:11 | BitPuffin | if a module is say, about initialing a rendering context |
| 04:20:15 | fowl | let me get some weed from u BitPuffin |
| 04:21:17 | fowl | BitPuffin, i can lead a horse to water but i cant make it drink. and if i try to shove its face into the water someone will report me for animal cruelty |
| 04:21:48 | BitPuffin | fowl: yeah it would be 8 files per module |
| 04:21:49 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 04:22:07 | * | BitPuffin joined #nimrod |
| 04:22:24 | BitPuffin | contex-windows.nim context-osx.nim context-linux.nim context-ps3.nim context-ps4.nim context-xbox360.nim context-xbone.nim context-wiiu.nim context-3ds.nim context-psvita.nim context-android.nim context-ios.nim |
| 04:22:30 | BitPuffin | great design 2014 |
| 04:22:49 | fowl | you're right |
| 04:22:52 | fowl | that would be way worse than |
| 04:22:56 | fowl | when defined(linux): |
| 04:22:58 | fowl | when defined(windows): |
| 04:23:01 | fowl | when defined(osx): |
| 04:23:04 | fowl | when defined(psvita): |
| 04:23:09 | fowl | when defined(ps4): |
| 04:23:12 | fowl | when defined(ios): |
| 04:23:16 | fowl | when defined(android): |
| 04:23:23 | fowl | repeated for every platform-specific function |
| 04:23:47 | BitPuffin | not really one function |
| 04:24:17 | BitPuffin | but yeah it would be much worse |
| 04:24:31 | fowl | dont let ambition kill your project before it takes off |
| 04:24:40 | BitPuffin | wut |
| 04:24:59 | fowl | you dont intend to support those platforms do you? |
| 04:25:42 | BitPuffin | lol no not initially |
| 04:25:45 | BitPuffin | and probably never all |
| 04:25:50 | BitPuffin | but perhaps for my API |
| 04:26:04 | BitPuffin | but that's way later |
| 04:26:15 | BitPuffin | then it will probably be PS5 and PS6 lol |
| 04:27:26 | BitPuffin | initially it will be win, linux and mac (probably mac at least) and after that porting to one console, probably either ps4 or wii u and then the other |
| 04:27:38 | BitPuffin | I'm not gonna work with M$ probably |
| 04:28:13 | BitPuffin | and no distrubuting on my own for windows doesn't count as working with microsoft |
| 04:28:25 | BitPuffin | windowns 8 store would however |
| 04:28:47 | fowl | make the windows version twice the price |
| 04:28:56 | * | Endy joined #nimrod |
| 04:29:15 | BitPuffin | yes |
| 04:29:17 | * | DAddYE joined #nimrod |
| 04:31:05 | fowl | allegro5's setup confuses me |
| 04:31:26 | fowl | i want a main loop but it seems like that pattern is discouraged |
| 04:31:41 | BitPuffin | how so? |
| 04:32:17 | fowl | the way its suggested is to use a 60fps timer and draw when the timer event comes through |
| 04:33:22 | BitPuffin | well I'm currently doing it as a main loop |
| 04:33:54 | BitPuffin | https://bitbucket.org/BitPuffin/miniquake/src/36d7e5a86dd276096249d1a812dd96501f61be5d/src/miniquake.c?at=default#cl-272 |
| 04:36:38 | fowl | c :( |
| 04:37:01 | fowl | you have no delay, this will run at thousands of frames per sec |
| 04:38:23 | BitPuffin | yeah currently |
| 04:38:32 | Skrylar | actually context-OS.nim is pretty normal in good libs |
| 04:38:57 | BitPuffin | fowl: I haven't started rendering yet as I mentioned, but you can wait for vertical refresh |
| 04:39:06 | BitPuffin | Skrylar: doesn't make it the ideal solution |
| 04:39:20 | Skrylar | some of the nicer C libraries will have things like "display-x86.c" (e.g. SDL, Allegro) because it puts a hard line between the portable / not portable code. Also, libRocket does this with System and Renderer interfaces |
| 04:39:52 | fowl | BitPuffin, i found an error |
| 04:40:00 | Skrylar | BitPuffin: whats the exact design problem with [api function stubs] when thisPlatform: include(stuffmodule.win32) |
| 04:40:13 | Skrylar | include / or import and export |
| 04:40:25 | Skrylar | include actually would remove the separation so the public/private variable issue is nil |
| 04:41:13 | * | Endy quit (Ping timeout: 246 seconds) |
| 04:41:22 | fowl | BitPuffin, the mallocs in floor_from_bitmap are wrong, the sizeof() should be Block* and Block |
| 04:41:32 | Skrylar | I don't think puffin is asking for people's opinions on good design, though, so I imagine he's going to do what he's going to do. :) |
| 04:42:29 | Skrylar | fowl: i poked around with backrefs, they involve some sadness with the GC :( |
| 04:42:50 | Skrylar | going to look at if macros can pretty up event queues later |
| 04:42:58 | fowl | you tried the gc test i have in ex1 with slotted objs? |
| 04:43:14 | Skrylar | fowl: i didn't run that one, but i did some gc tests |
| 04:43:17 | BitPuffin | fowl: you are probably right, will look at it tomorrow, I'm sleepy |
| 04:43:50 | Skrylar | fowl: the problem is that you have to unhook the backrefs in a finalizer, and finalizers can run at any random point, so its still possible to signal a dead object for a while |
| 04:44:03 | Skrylar | as in "its in GC space but nobody technically should have access" |
| 04:44:18 | BitPuffin | Skrylar: well like I said my design is pretty much the same, but it's nicer when it's a small module |
| 04:44:39 | Skrylar | separating is nicer on the implementors |
| 04:44:47 | Skrylar | you can copy/paste an existing one and prod around with it |
| 04:44:51 | BitPuffin | and the way I said it you could just move the code into it's own file if the module grows to big |
| 04:44:59 | fowl | Skrylar, it seems to work for me |
| 04:45:02 | BitPuffin | literally just replace the code in the when with include the file |
| 04:45:03 | Skrylar | there's also only one place you have to adjust, instead of altering dozens of when/else/when trees |
| 04:45:15 | BitPuffin | Skrylar: it's already separated |
| 04:45:58 | BitPuffin | Skrylar: well that was the whole point of the earlier gist, that if you could "extend" a type's definition you wouldn't have to have a bunch of scattered when stuffs |
| 04:46:51 | fowl | Skrylar, all of them get gc'd, except the last obj instantiated (thats to be expected since its left on the stack) https://gist.github.com/fowlmouth/9718956 |
| 04:46:51 | BitPuffin | tho whole point was to make it one case per platform at one place rather than in many places |
| 04:47:41 | fowl | BitPuffin, the problem wiht that is that assuming you can extend a type definition like that, you end up with "a bunch of scattered when stuffs" |
| 04:47:52 | * | lanior joined #nimrod |
| 04:49:53 | BitPuffin | the feature I suggested would make them both nicer |
| 04:49:53 | BitPuffin | the discussion wasn't even about which design is better because they are more or less the same |
| 04:50:57 | BitPuffin | fowl: only if you are an idiot that abuses it |
| 04:51:26 | BitPuffin | for example if you are not even doing platform specific things but are just 800 lines down and realise that hmm this file should have this and then add it |
| 04:51:29 | BitPuffin | that would be fucking stupid |
| 04:51:40 | BitPuffin | but that's not what it's for |
| 04:52:09 | fowl | BitPuffin, ok |
| 04:52:24 | fowl | nobody is going to convince you, i get it |
| 04:52:57 | BitPuffin | there is nothing to convince |
| 04:53:56 | fowl | exactly |
| 04:56:02 | BitPuffin | because I'm note even sure you guys understand what I'm saying :P and you are trying to argue about two designs that are identical, like I said you'd just replace the code with include bla. The one thing that this changes is that you don't need to compose an extras object whih seems silly |
| 04:57:37 | fowl | my closing arguments: i disagree, there is a reason this pattern is so common |
| 05:01:20 | NimBot | nimrod-code/packages master a871737 Billingsly Wetherfordshire [+0 ±1 -0]: Update packages.json... 2 more lines |
| 05:02:41 | BitPuffin | fowl: but they are the same, for the millionth time |
| 05:03:33 | BitPuffin | and the reason is because the definiton of the type can only be in one place in every language so to add to it you need to make an extras property that you implement somewhere else |
| 05:03:38 | BitPuffin | thre's just no other way around it |
| 05:04:11 | BitPuffin | other than conditionally compiling your ass off inside the type definition which creates a clusterfuck |
| 05:05:01 | fowl | sorry i've already made my closing argument |
| 05:06:05 | BitPuffin | yeah and I addressed it |
| 05:07:35 | fowl | well i cant continue this conversation unless im getting overtime and the boss never approves that |
| 05:07:59 | BitPuffin | well either way if you can't argue for your argument then why state it. |
| 05:08:05 | BitPuffin | It's 6am here anyways |
| 05:08:12 | fowl | sorry im off the clock |
| 05:35:12 | * | lanior quit (Quit: Page closed) |
| 05:59:34 | * | DAddYE quit (Remote host closed the connection) |
| 06:00:00 | * | DAddYE joined #nimrod |
| 06:04:18 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 06:13:34 | * | DAddYE joined #nimrod |
| 06:34:03 | Skrylar | bleh. new install appears as though it doesn't want to be bootable |
| 06:53:47 | Araq | DAddYE: ha, I would have bet you have 6000 watchers by now. |
| 06:54:15 | DAddYE | Araq: why? |
| 06:54:43 | Araq | but I guess one can count go users' stubbornness ;-) |
| 06:55:40 | DAddYE | Araq: all of them mostly hate it so that's fine |
| 06:55:51 | Araq | :-9 |
| 06:57:47 | Araq | DAddYE: it seems harder to please people syntactically than we think |
| 06:58:22 | DAddYE | I think no one got it |
| 06:58:41 | DAddYE | maybe I had to call it iGo where i stand for intermediate |
| 06:58:53 | DAddYE | aka I want to format my fucking file as I want |
| 06:59:03 | DAddYE | but distribute the formatted one |
| 06:59:04 | DAddYE | :D |
| 06:59:20 | DAddYE | if true { break } |
| 06:59:31 | DAddYE | can't be 4 lines |
| 06:59:38 | DAddYE | << IMHO |
| 07:00:04 | Araq | you're wrong because Rob Pike disagrees with you |
| 07:00:43 | Skrylar | that amused me when they were saying "well go gets to be on wikipedia because rob pike is famous" like, "what? so a 'notable person's spit is notable by association?" |
| 07:01:09 | DAddYE | Araq: yep, that's disgust me |
| 07:01:32 | DAddYE | however he is much more experienced than me |
| 07:01:39 | DAddYE | so probably I'm wrong |
| 07:01:46 | Araq | yeah well we all know Linux is on wikipedia because Linux is famous |
| 07:01:52 | Araq | *Linus |
| 07:02:56 | Skrylar | I don't have a problem with the argument regarding independent sources as much, but I do find it relatively stupid that a "notable person" is allowed to get away with not having sources |
| 07:03:06 | Skrylar | i'm not sure how that isn't a definition of favoritism |
| 07:03:08 | DAddYE | Araq: another guy famous for being a code fascist |
| 07:03:41 | Araq | DAddYE: hrm perhaps true |
| 07:04:07 | Skrylar | i still claim the reason Go has success is more to do with it being Google |
| 07:04:08 | Skrylar | :) |
| 07:04:26 | DAddYE | Skrylar: mmm, dunno |
| 07:04:30 | Araq | sometimes I wonder how these people think: "there brace here is not aligned so that must be were the bug hides" |
| 07:04:34 | DAddYE | most think despite to google |
| 07:04:56 | Skrylar | DAddYE: they have google backing, which means they have the "corporate presense" checkbox ticked |
| 07:05:08 | Skrylar | And Google claims to use Go internally, so they have the "used in something i've heard of" box ticked |
| 07:05:26 | DAddYE | Skrylar: actually I have used unfortunately it quite a bit |
| 07:05:39 | DAddYE | I put go right after python |
| 07:05:47 | DAddYE | it is not low as c |
| 07:05:47 | Skrylar | I liked Go once upon a time, but thought it was full of arbitrary rules |
| 07:05:51 | DAddYE | not high as python |
| 07:06:04 | Skrylar | like, why is the foo.bar -> foo(bar) magic restricted solely to functions within the module? |
| 07:06:14 | DAddYE | and solve the trend problem of today: parallelism and concurrency |
| 07:06:39 | Skrylar | there is no vtable in Go, so there is no technical excuse given; its a human excuse, or rather "some people are stupid therefore nobody can have nice things" solution |
| 07:06:51 | Araq | go is more about concurrency than about parallelism |
| 07:07:05 | DAddYE | Araq: GOPROCS |
| 07:07:10 | Skrylar | goroutines? :) |
| 07:07:23 | DAddYE | however, as said |
| 07:07:33 | DAddYE | is faster than python ruby and so on |
| 07:07:41 | Araq | DAddYE: I know quite a bit what I'm talking about and stand by my claim. |
| 07:07:49 | DAddYE | without being complicated as c++ |
| 07:07:54 | * | rejuvyesh[away] is now known as rejuvyesh |
| 07:08:07 | DAddYE | Araq: I believe you |
| 07:08:22 | DAddYE | however, the thing IMHO doesn't change |
| 07:08:34 | DAddYE | the hot problem today is performance |
| 07:08:46 | DAddYE | they solve it without compromising the complexity |
| 07:08:54 | DAddYE | isn't complex ie like rust |
| 07:09:08 | DAddYE | or haskell etc... |
| 07:09:32 | DAddYE | and (that's what they say) has a quite complete std library |
| 07:10:33 | DAddYE | Skrylar: however you can implement it in igo :D |
| 07:17:53 | * | xenagi quit (Quit: Leaving) |
| 07:19:29 | Skrylar | DAddYE: implementing things is currently on hold |
| 07:19:45 | Skrylar | installed an SSD in my other box and it refuses to boot, period :| |
| 07:19:58 | Skrylar | Yet it SEES the drive, which means Windows is just being critically retarded |
| 07:26:28 | Araq | DAddYE: making "concurrency easy" without even addressing deadlocks and data races is a downright impertinence. though in Go's defense they have tooling support to detect these dynamically. |
| 07:27:13 | Araq | makes me wonder why they even have static typing though |
| 07:27:42 | Araq | dynamic typing would also their "lack of generics" issue |
| 07:27:47 | Araq | *also solve |
| 07:28:07 | Araq | and fits Go's "simplicity over everything" mantra |
| 07:29:52 | DAddYE | Araq: actually the thing of simplicity is kinda true |
| 07:30:28 | DAddYE | I think is the simplest language ever used so far |
| 07:31:06 | Araq | I think Lua is simpler |
| 07:31:16 | DAddYE | mmm dunno |
| 07:31:34 | DAddYE | they have the metatable thing |
| 07:31:46 | DAddYE | and few other things |
| 07:31:57 | DAddYE | however indeed is simple as well |
| 07:32:26 | DAddYE | Araq: I want to make a lua (jit) version as I like it |
| 07:34:49 | runvnc | hello when I try to use --symbolFiles:on it says internal error: symStack: module nil |
| 07:35:17 | runvnc | on linux. is that normal.. maybe you are not done with that incremental thing. it says 'experimental' |
| 07:36:06 | Skrylar | DAddYE: lua has metatables because lua is good at pretending to be good |
| 07:36:46 | Skrylar | metatables are the minimum concept required to model most of the OOP types :) |
| 07:37:07 | Araq | runvnc: please report it but yes, we know symbol files are broken for quite some time now |
| 07:37:16 | DAddYE | Skrylar: honestly I think isn't bad, IMHO they made awful decision on syntax (which is tooooooooooooooo verbose) |
| 07:37:18 | Araq | some say they never really worked |
| 07:37:41 | runvnc | ok thanks you say please report it because you actually want another issue to keep track, or I dont need to report since you know |
| 07:38:19 | runvnc | I don't like issues personally |
| 07:38:26 | runvnc | but I think thats because I am sort of lazy |
| 07:38:31 | runvnc | heh |
| 07:38:42 | Araq | report it with a test case since the particular error message is new to me |
| 07:38:52 | Skrylar | DAddYE: I don't think Lua is bad, I think its great at being Lisp :P |
| 07:38:55 | runvnc | ok |
| 07:39:26 | DAddYE | Skrylar: yep |
| 07:39:40 | Skrylar | DAddYE: you might want to look at moonscript though; thats basically a bolt-on that gives it different syntax |
| 07:39:51 | DAddYE | Skrylar: I hate it :D |
| 07:40:31 | Skrylar | i wonder if the linux support for my video card is still crap |
| 07:40:43 | Skrylar | i looked in to it once but optimus support was basically nonexistent |
| 07:41:08 | DAddYE | Skrylar: I'll probably write a new syntax which will emit luajit bytecode |
| 07:41:22 | Skrylar | i don't think luajit bytecode is intended for people to use directly |
| 07:42:10 | Araq | just modify luajit's parser it is not hard |
| 07:44:18 | DAddYE | Skrylar: yep it usable wait |
| 07:44:25 | DAddYE | Skrylar: https://github.com/franko/luajit-lang-toolkit |
| 07:44:35 | DAddYE | Araq: yep, WE could do that :D |
| 07:50:28 | Skrylar | alright, i give that system one more try and then i guess it gets linuxed |
| 07:51:49 | Araq | so DAddYE when will I get my c2nim website? ;-) |
| 07:52:17 | DAddYE | Araq: once we can parse union |
| 07:52:43 | DAddYE | and struct declaration and initialization in a single statement |
| 07:52:49 | DAddYE | (pretty common) |
| 07:52:53 | Araq | huh? c2nim can parse unions and recently nimrod got the .union pragma |
| 07:53:11 | DAddYE | mmmm |
| 07:53:18 | DAddYE | I tried like a month ago |
| 07:53:24 | DAddYE | (when we talked about it) |
| 07:53:29 | DAddYE | I got problem with unions |
| 07:53:38 | DAddYE | struct declared and invoked in a single statement |
| 07:53:42 | DAddYE | and other macros things |
| 07:53:48 | Araq | well there are bugs of course |
| 07:53:48 | * | Endy joined #nimrod |
| 07:55:24 | DAddYE | however we can put it online and thus if there are errors |
| 07:55:37 | DAddYE | we can ask the user to open an issue |
| 07:55:48 | Araq | // Test standalone structs: |
| 07:55:49 | Araq | union myunion { |
| 07:55:51 | Araq | char x, y, *z; |
| 07:55:52 | Araq | myint a, b; |
| 07:55:54 | Araq | } u; |
| 07:55:58 | Araq | produces: var u: myunion |
| 07:56:08 | Araq | plus the myunion declaration of course |
| 07:56:36 | Araq | ah but perhaps it's the initializer |
| 07:57:04 | DAddYE | Araq: struct with an union inside IIRC does not work |
| 07:57:19 | DAddYE | struct { a int8; union { ... } } |
| 07:57:34 | Araq | that's not C89 :P |
| 07:58:50 | DAddYE | 0.= |
| 07:59:34 | DAddYE | Araq: also why don't you use clang bindings |
| 07:59:38 | DAddYE | for parsing? |
| 07:59:58 | Araq | because i'm special |
| 08:01:07 | Skrylar | DAddYE: why don't you use doxygen xml :B |
| 08:01:24 | DAddYE | Skrylar: :D |
| 08:01:27 | DAddYE | Araq: I know |
| 08:01:30 | DAddYE | isn't that bad |
| 08:01:35 | Araq | DAddYE: when I wrote c2nim, clang wasn't ready |
| 08:01:58 | Skrylar | Welp. I guess I have to put Mint on that computer. Windows has decided dur hur booting is for noobs |
| 08:01:58 | Araq | patches are welcome though because I'm tired of people complaining about c2nim |
| 08:02:20 | DAddYE | Skrylar: get a mac please :D |
| 08:02:39 | Skrylar | DAddYE: my macbook decided that proper circuit board ventilation was for noobs |
| 08:02:42 | Araq | make c2nim use clang and move it to its own repository |
| 08:03:05 | Araq | maybe rename it to clang2nim while we're at it |
| 08:03:05 | DAddYE | Araq: ;) |
| 08:03:13 | DAddYE | Araq: also |
| 08:03:15 | DAddYE | qq |
| 08:03:22 | Skrylar | DAddYE: I liked my mac, then the mac app store happened. And then my mac committed seppuku :( |
| 08:03:35 | DAddYE | do we have a yacc/bison support for nimrod? |
| 08:03:42 | Araq | no |
| 08:04:47 | DAddYE | Araq: because I guess there are some well solid yacc parser for c grammar |
| 08:04:55 | DAddYE | which we could use |
| 08:05:08 | Araq | true but clang is the better choice I think |
| 08:05:36 | Araq | as you also need a symbol table to properly handle C |
| 08:06:34 | DAddYE | yup |
| 08:19:19 | Skrylar | wat |
| 08:19:44 | Skrylar | why does booting a blank drive set as #2 in the bios work |
| 08:23:24 | Araq | ping skyfex |
| 08:35:55 | Skrylar | ah, i see how wx is doing it |
| 08:36:39 | Skrylar | WxWidgets handles their event stack by using a parent heirarchy; events don't get 'queued' they get tossed back against the table |
| 08:37:41 | Skrylar | Downside is you get a seq[] for each object's event map, upside is you don't push/pop values and you could implement it without a lot of copying |
| 08:38:31 | Skrylar | One could factor out the runtime seq[] with a static table, but then you lose dynamic connection; unless you split it in to a static/dynamic table |
| 08:38:33 | Skrylar | hrm |
| 08:39:22 | Skrylar | Araq: it looks like getting rid of seqs in event handling is pretty awkward to do (though possible) |
| 08:39:22 | * | rejuvyesh is now known as rejuvyesh[away] |
| 08:45:08 | Araq | Skrylar: that's fine. eventually I'll implement my "immediate mode UI" that kicks ass for verification ;-) |
| 08:47:11 | Skrylar | yay GC thrashing |
| 08:49:03 | Araq | bbl |
| 08:51:33 | * | DAddYE quit (Remote host closed the connection) |
| 08:52:00 | * | DAddYE joined #nimrod |
| 08:56:14 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 08:58:53 | Skrylar | aaaand trying to use a uint at compile time crashes the compiler. yay |
| 09:06:19 | * | [1]Endy joined #nimrod |
| 09:10:28 | * | Endy quit (Ping timeout: 265 seconds) |
| 09:10:28 | * | [1]Endy is now known as Endy |
| 09:14:15 | * | rejuvyesh[away] is now known as rejuvyesh |
| 09:22:31 | * | DAddYE joined #nimrod |
| 09:24:50 | skyfex | pong Araq |
| 09:27:23 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 09:29:29 | EXetoC | zahary: How do I define a constraint such as "put(c, instanceOfT)" for a UDTC like this "Container[T] = generic c"? |
| 09:30:01 | zahary | put(c, T) |
| 09:30:26 | EXetoC | I don't know if I tried that |
| 09:31:38 | EXetoC | No it doesn't work. can it not be mistaken for a typedesc in that case? |
| 09:31:44 | Skrylar | woot. it turns out, yes you can put UIDs on objects using a macro :D |
| 09:31:54 | zahary | let me try it - I don't have this one in the test suite I think |
| 09:32:02 | EXetoC | ok |
| 09:35:18 | zahary | worked for me - can I have a full gist |
| 09:36:01 | zahary | is your put proc taking a var Container? |
| 09:36:11 | zahary | you need to say "generic var c" then |
| 09:36:51 | zahary | or "put(var c, T) |
| 09:38:07 | EXetoC | zahary: |
| 09:38:10 | EXetoC | oops |
| 09:38:22 | * | Trimsty joined #nimrod |
| 09:38:36 | EXetoC | no, I don't think it should take 'Container' in this case, but I'll try that |
| 09:38:59 | zahary | no I meant the concrete Container type you are targeting |
| 09:39:30 | * | Trimsty quit (Client Quit) |
| 09:39:31 | zahary | is it put(x: var MyContainer, x: MyValue) |
| 09:42:26 | EXetoC | zahary: "proc put*[T](c: seq[T], x: T) =" |
| 09:43:06 | EXetoC | zahary: I think I managed to do "assert(x is Container)" before. that is, without specifying any type params for container, but now it works if I do. I'll gist it |
| 09:47:49 | EXetoC | zahary: https://gist.github.com/EXetoC/8f643a6beaaf8891e345 |
| 09:48:55 | EXetoC | I wasn't able to get it to work by including 'var' on line 1 and 5 |
| 09:50:02 | EXetoC | what if I'd like to somehow match "proc put*[T](c: seq[T], x: typedesc) ="? |
| 09:53:31 | zahary | yes, these should work, I'll take a look what going on |
| 09:54:57 | zahary | regarding checking for typedesc procs, the spec says that the check should be written like this: |
| 09:54:57 | zahary | put(c, type T) |
| 09:55:03 | zahary | but I haven't implemented that part yet |
| 09:55:17 | Araq | is that part of the spec in the manual? |
| 09:55:41 | zahary | it was in the forum discussion - I'll add it in the manual when it's ready |
| 09:56:13 | Araq | good |
| 09:57:06 | EXetoC | oh |
| 10:07:24 | * | silven_ joined #nimrod |
| 10:07:55 | zahary | so Araq, what was interesting about #1023? |
| 10:07:55 | * | silven quit (Quit: No Ping reply in 180 seconds.) |
| 10:08:49 | Araq | that the VM even worked before :P |
| 10:09:40 | Araq | I stored a field offset in a TDest which really only should hold registers |
| 10:10:05 | * | Ycros quit (Quit: No Ping reply in 180 seconds.) |
| 10:10:17 | zahary | so we were lucky in every single test so far? :)\ |
| 10:10:26 | * | Ycros joined #nimrod |
| 10:10:33 | Araq | this pseudo-register is then freed, freeing prematurely what the register really holds |
| 10:10:52 | Araq | and so the register is re-used too early leading to things like |
| 10:10:58 | zahary | we can try running every test in the suite with "nimrod i" as well |
| 10:10:58 | Araq | add reg3, reg3, reg3 |
| 10:11:13 | Araq | however |
| 10:11:30 | Araq | most offsets are small and at small register indices the parameters are stored |
| 10:11:52 | Araq | and these registers are not scratch register so freeReg is a nop for these |
| 10:12:05 | Araq | thus the bug wasn't noticable :-) |
| 10:12:55 | Araq | well I'm working on #404 (use tabels at compile time) |
| 10:13:01 | Araq | *tables |
| 10:13:28 | Araq | and then I'd like to declare the VM to be "stable enough" |
| 10:13:47 | zahary | I noticed the useFFI discussion yesterday - if we fix this, why don't we enable it by default? |
| 10:14:40 | zahary | there are no "dialects" this way - and it's embarasing that you cant use math functions like sqrt, pow, etc at compile-time |
| 10:15:18 | Araq | what is computable at compile-time has a quite clear spec in my head |
| 10:16:01 | Araq | useFFI means it's a never ending feature |
| 10:17:11 | Araq | as I said, os and math should get special treatment instead |
| 10:17:18 | zahary | opt-in makes perfect sense to me |
| 10:18:05 | zahary | we'll cover the obvious procs from the standard C library and the user will be able to enable whatever he needs further |
| 10:18:47 | Araq | instead of useFFI we should make staticExec easier to use with compiler invokations and caching |
| 10:20:19 | zahary | well, won't we need useFFI anyway for the math procs I mentioned? do you plan to make them magic? |
| 10:21:25 | Araq | not sure how to do it, but making them magic seems to be the way to go |
| 10:22:26 | * | rejuvyesh left #nimrod ("WeeChat 0.4.3") |
| 10:23:24 | * | DAddYE joined #nimrod |
| 10:23:39 | * | q66 joined #nimrod |
| 10:26:19 | * | Skrylar ponders about static dispatch tables in macros |
| 10:27:37 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 10:37:09 | Skrylar | OnSomething do: ... ought to be possible, but so far i've only worked out how to do that with if/else checks instead of combining it all in to one big case |
| 10:37:44 | Araq | Skrylar: you need to gather the branches in a compile-time var |
| 10:44:55 | * | CARAM quit (Quit: Connection closed for inactivity) |
| 10:47:39 | * | runvnc quit (Quit: Leaving) |
| 10:57:46 | * | Zuchto quit (Ping timeout: 265 seconds) |
| 11:00:12 | * | Zuchto joined #nimrod |
| 11:18:50 | * | darkf quit (Read error: Connection reset by peer) |
| 11:19:10 | * | darkf joined #nimrod |
| 11:19:14 | * | io2 joined #nimrod |
| 11:23:49 | * | armin1 joined #nimrod |
| 11:23:58 | Araq | hi armin1 welcome |
| 11:24:06 | * | DAddYE joined #nimrod |
| 11:25:16 | armin1 | Araq: thanx^^ - false alarm though, i'm the same as reloc0 ... frenode reset the connection :) |
| 11:25:45 | * | reloc0 quit (Disconnected by services) |
| 11:25:58 | * | armin1 is now known as reloc0 |
| 11:26:00 | Araq | you speak the truth |
| 11:26:20 | reloc0 | ^_^ |
| 11:28:16 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 11:29:20 | Araq | hmm according to wikipedia, this is a cat: (,,,)---=^.^=---(,,,) |
| 11:29:38 | EXetoC | :o |
| 11:29:49 | * | darkf quit (*.net *.split) |
| 11:29:51 | * | Ycros quit (*.net *.split) |
| 11:29:52 | * | zahary quit (*.net *.split) |
| 11:29:58 | * | krusipo quit (*.net *.split) |
| 11:29:59 | dom96 | 'morning |
| 11:30:19 | dom96 | Araq: So do you want it to raise an exception then? |
| 11:30:35 | Araq | dom96: sure |
| 11:31:50 | EXetoC | that's a really bad cat |
| 11:37:34 | NimBot | Araq/Nimrod devel cd5d0ff Dominik Picheta [+0 ±2 -0]: Fixes tasyncawait and the net module on Linux. |
| 11:39:22 | * | zahary joined #nimrod |
| 11:44:17 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 11:45:41 | * | krusipo joined #nimrod |
| 11:47:23 | * | Ycros joined #nimrod |
| 12:03:46 | flyx | if I have a pointer to an private type from a C API, how can I wrap this type in nimrod? |
| 12:05:18 | Araq | type |
| 12:05:28 | Araq | Private = object |
| 12:05:37 | Araq | PPrivate* = ptr PRivate |
| 12:05:49 | flyx | kthx |
| 12:20:09 | flyx | hm. given a C API with a signature like "int* get_array(int* count)", where count returns the length of the returned array. I cannot use openarray as return type, right? how can I wrap this? |
| 12:25:01 | * | DAddYE joined #nimrod |
| 12:29:19 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 12:35:58 | Skrylar | flyx: carrays, or something like "int[0..65535]" is common |
| 12:36:07 | Skrylar | "ptr int" is also perfectly valid |
| 12:37:31 | dom96 | Perhaps you could use the unchecked pragma http://forum.nimrod-lang.org/t/380 |
| 12:38:15 | Skrylar | dom96: is that implemented now? |
| 12:38:24 | Skrylar | i tested it two weeks ago and it didn't compile |
| 12:39:41 | Araq | when I replied, it was implemented |
| 12:42:42 | Araq | Skrylar: system.nim itself uses it |
| 12:42:50 | Araq | if it doesn't work for you report a bug |
| 12:43:01 | Araq | but ensure you're using the devel version of the compiler |
| 12:44:51 | Skrylar | Araq: i'm pretty sure i was using the compiler that didn't have the pragma patched in yet at th etime |
| 12:45:10 | Araq | good |
| 12:50:32 | * | q66 quit (Ping timeout: 252 seconds) |
| 12:52:43 | * | q66 joined #nimrod |
| 12:53:34 | flyx | Skrylar: but if I use "ptr int", how do I get values from the array? nimrod doesn't seem to implement pointer aritmetics |
| 12:54:23 | Araq | flyx: |
| 12:54:57 | Araq | type UncheckedArray {.unchecked.} [T] = array [0..0xff_ffff, T] |
| 12:55:25 | Araq | proc get_array(count: ptr cint): ptr UncheckedArray[cint] |
| 12:55:53 | Araq | and I guess UncheckedArray should make it into system.nim ... *sigh* |
| 12:56:52 | flyx | there should be a manual about how to properly wrap C APIs. I wrote one for Ada some time ago, people told me it was very helpful |
| 12:57:59 | BitPuffin | fowl: are you sure the mallocs should be Block* and Block, doesn't seem like it if you ask me |
| 12:58:47 | * | q66 quit (Ping timeout: 252 seconds) |
| 12:59:56 | BitPuffin | or hmm |
| 12:59:56 | BitPuffin | you might be right |
| 13:00:01 | Araq | flyx: yeah please do that |
| 13:00:41 | * | q66 joined #nimrod |
| 13:00:50 | flyx | I'll try to sum up things I encounter and post it when it looks ready enough |
| 13:01:28 | Araq | my initial plan was to tell people "just use c2nim for fuck's sake" ;-) |
| 13:02:41 | Araq | but since people have problems with c2nim all the time too, that's not helpful |
| 13:02:42 | flyx | Araq: yeah, but it sure is nicer if the caller does not need to care about much low-level C stuff |
| 13:16:22 | * | Sorcy joined #nimrod |
| 13:17:24 | * | krusipo_ joined #nimrod |
| 13:22:15 | * | Ycros quit (Quit: No Ping reply in 180 seconds.) |
| 13:22:17 | * | krusipo quit (Ping timeout: 265 seconds) |
| 13:25:40 | * | DAddYE joined #nimrod |
| 13:30:01 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 13:56:32 | * | q66 quit (Ping timeout: 252 seconds) |
| 14:01:31 | * | flyx got a "[1] 2237 illegal hardware instruction" when running compiled nimrod code |
| 14:01:41 | flyx | this seems pretty bad |
| 14:03:27 | Araq | interesting. what platform? |
| 14:03:38 | flyx | OSX, 10.9 |
| 14:04:02 | Araq | no further questions :P |
| 14:04:03 | flyx | I *guess* it's a problem with my wrapper |
| 14:06:05 | flyx | is this supposed to happen when I'm doing something wrong? |
| 14:06:54 | Araq | lol no, it's the first time I hear about this error message |
| 14:07:00 | Araq | hence I asked |
| 14:07:40 | Araq | looks to me like you try to invoke 32bit code on a 64bit OS or the other way round |
| 14:07:48 | Araq | or maybe you are on ARM? |
| 14:08:14 | * | silven_ is now known as silven |
| 14:09:44 | flyx | I'm on 64bit. |
| 14:10:28 | flyx | it seems to happen at the point where I call the function returning Unchecked_Array I wrote about before |
| 14:11:35 | Araq | that can imply that it couldn't find get_array at runtime |
| 14:11:42 | Araq | invoking a nil function pointer |
| 14:12:56 | flyx | I get a usual error message when I spell the proc's importc wrong |
| 14:13:02 | flyx | so it seems to be found |
| 14:14:52 | flyx | and it happens immediately when I start the program, not when I call the function |
| 14:16:30 | Araq | maybe you got the calling conventions wrong? |
| 14:17:51 | flyx | maybe, but the other imports from the lib are working |
| 14:20:05 | flyx | the problem seems to be the return value Unchecked_Array[PMonitor] |
| 14:20:15 | flyx | if I use "ptr PMonitor" instead, it works |
| 14:20:59 | Araq | well I told you to use **ptr** UncheckedArray |
| 14:21:05 | flyx | oh |
| 14:21:23 | * | q66 joined #nimrod |
| 14:21:30 | * | flyx should read more carefully |
| 14:26:18 | * | DAddYE joined #nimrod |
| 14:30:25 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 14:35:29 | * | EXetoC joined #nimrod |
| 14:56:35 | Araq | argh I'm fed up with tuple unpacking |
| 14:56:50 | * | Araq is writing a lowerTupleUnpacking to never have to deal with it again |
| 15:05:17 | * | q66 quit (Ping timeout: 252 seconds) |
| 15:07:12 | * | q66 joined #nimrod |
| 15:27:00 | * | DAddYE joined #nimrod |
| 15:31:43 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 15:57:03 | * | DAddYE joined #nimrod |
| 16:01:13 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 16:14:54 | * | Demos joined #nimrod |
| 16:48:49 | NimBot | Araq/Nimrod devel abb2423 Araq [+2 ±4 -0]: fixes #404 |
| 16:48:49 | NimBot | Araq/Nimrod devel 62c1532 Araq [+0 ±2 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 16:57:35 | * | DAddYE joined #nimrod |
| 16:59:04 | EXetoC | yay more bytes |
| 17:00:23 | Araq | babel install mongodb |
| 17:00:25 | Araq | FAILURE: Package not found. |
| 17:01:08 | Araq | bbl |
| 17:01:37 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 17:04:37 | EXetoC | Araq: you need it? |
| 17:05:08 | EXetoC | I need to add it to babel |
| 17:13:08 | fowl | BitPuffin, currently there is no problem when you malloc Block*, but this is only a coincidence because Block holds a single pointer |
| 17:14:29 | BitPuffin | fowl: yep, indeed |
| 17:16:37 | dom96 | BitPuffin: Why C. WHYYYYY |
| 17:17:34 | BitPuffin | dom96: because fowl wasn't done with allegro binding |
| 17:17:35 | BitPuffin | plus |
| 17:17:39 | * | skyfex quit (Remote host closed the connection) |
| 17:17:41 | BitPuffin | can't risk compiler bugs in a jam |
| 17:17:47 | BitPuffin | and it makes me a bit more employable :P |
| 17:17:51 | dom96 | It's not like your life depends on it! |
| 17:17:54 | dom96 | I risked it! |
| 17:18:19 | BitPuffin | hahaha |
| 17:18:21 | BitPuffin | :D |
| 17:18:24 | BitPuffin | it does depend on it :o |
| 17:18:24 | dom96 | hrm. Neovim raised ~$30K on Bountysource |
| 17:18:35 | BitPuffin | I'm gonna apply for another jerb soon |
| 17:18:45 | BitPuffin | this would be good portfolia |
| 17:19:14 | dom96 | https://www.bountysource.com/trackers/383571-d-programming-language |
| 17:19:22 | dom96 | We should so totally set this up :P |
| 17:20:09 | BitPuffin | dom96: and you have no say in this, it my life xD |
| 17:20:18 | dom96 | BitPuffin: Bro, I own your ass. |
| 17:21:36 | dom96 | damn 1500 for a gtksourceview bug |
| 17:21:41 | BitPuffin | dom96: :P |
| 17:21:50 | dom96 | perhaps I should try to implement that. |
| 17:21:52 | BitPuffin | dom96: not in doto |
| 17:22:08 | BitPuffin | we need to do 1v1 mid some time |
| 17:22:10 | BitPuffin | would be fun |
| 17:22:18 | dom96 | meh |
| 17:22:23 | dom96 | I can play CS: GO with you |
| 17:22:27 | dom96 | But Dota meh. |
| 17:22:47 | dom96 | SC2 is more fun, you should play it :P |
| 17:23:37 | dom96 | Araq: Dude, we should actually register for bountysource |
| 17:24:16 | dom96 | Surprised to see Adobe contributing 5k |
| 17:26:13 | EXetoC | BitPuffin: ah yes, the second best choice to Nimrod |
| 17:33:33 | dom96 | Guess we don't even need to set it up: https://www.bountysource.com/trackers/178097-araq-nimrod |
| 17:35:10 | dom96 | hrm, who was it that got Aporia working on Mac OS X? |
| 17:35:17 | dom96 | It works right? so we can close https://github.com/Araq/Nimrod/issues/342 ? |
| 17:38:06 | BitPuffin | EXetoC: pretty much yeah |
| 17:38:14 | dom96 | BitPuffin: Could you maybe try it? |
| 17:38:46 | BitPuffin | dom96: try what |
| 17:39:00 | BitPuffin | I'm coding C god damn it |
| 17:39:12 | dom96 | compiling Aporia |
| 17:39:40 | BitPuffin | maybe some other day |
| 17:40:23 | fowl | its so hard to babel install aporia |
| 17:40:59 | BitPuffin | seconds matter |
| 17:42:15 | BitPuffin | could not load: libgtksourceview-2.0(|-0).dylib |
| 17:44:56 | dom96 | well it compiles |
| 17:45:03 | dom96 | So I think that issue has been fixed. |
| 17:45:34 | BitPuffin | it runs |
| 17:45:37 | BitPuffin | if that's what you wanted |
| 17:45:46 | BitPuffin | now you owe me 10 bucks |
| 17:46:10 | dom96 | if I ever win the lottery i'll give you 10 bucks. |
| 17:46:20 | dom96 | but only if I win millions |
| 17:46:29 | BitPuffin | cheap ass |
| 17:46:39 | dom96 | :P |
| 17:46:54 | dom96 | THAT'S WHAT HAPPENS WHEN YOU DON'T USE NIMROD BUT C |
| 17:47:04 | EXetoC | BitPuffin: that's objectively wrong |
| 18:01:03 | BitPuffin | EXetoC: what is? |
| 18:22:26 | NimBot | Araq/Nimrod devel 7f83573 Dominik Picheta [+0 ±5 -0]: Moved the global dispatcher to asyncdispatch. |
| 18:28:21 | * | Matthias247 joined #nimrod |
| 18:52:34 | Demos | BitPuffin: you are using C for the minild? |
| 18:53:07 | BitPuffin | Demos: yeah |
| 18:53:27 | Demos | that seems like a strange choice to me. Fun, but strange |
| 18:53:46 | Demos | I am using lua, although we may not finish in the weekend, we got distracted by Artemis Spaceship bridge simulator |
| 18:54:05 | Demos | I just have basic movement :( |
| 18:54:31 | dom96 | ahh nice. Two people doing MiniLD here and neither of them using Nimrod. |
| 18:56:13 | Demos | well I am doing it with a friend who did not want to learn nimrod, although he is not really coding as it turns out... |
| 18:57:19 | Demos | hm aporia will not start, it can not load libgdk-x11-2.0.dylib on OSX and I can not find what library that is actually from |
| 18:58:42 | EXetoC | gtk? |
| 18:59:01 | * | Varriount_ joined #nimrod |
| 18:59:30 | Demos | it says gdk |
| 19:00:25 | * | Varriount quit (Ping timeout: 240 seconds) |
| 19:00:36 | fowl | its from gtk |
| 19:01:26 | Demos | got it |
| 19:02:09 | Demos | OK Aporia works |
| 19:02:19 | Demos | OSX 10.9 with dependencies from homebrew |
| 19:02:29 | Demos | it looks like shit though |
| 19:02:54 | fowl | gtk might need to be configured to look like aqu |
| 19:02:55 | fowl | a |
| 19:03:05 | Demos | yeah prolly |
| 19:03:20 | Demos | it seems to just run in XWindows, which is a bit unfortinate |
| 19:04:41 | Demos | lets just blame X-Windows and call it a day :D |
| 19:05:51 | fowl | wow |
| 19:06:00 | fowl | i have 136gb unallocated on my hd |
| 19:06:24 | Araq | BitPuffin: "d'oh nimrod is not stable when I use code that fucks the compiler, so I'm using C which won't even let me do anything like nimrod" |
| 19:06:49 | Araq | IMHO very flawed reasoning |
| 19:07:24 | Araq | so write C-like Nimrod and still get a saner type system ... |
| 19:07:35 | BitPuffin | Araq: That wasn't the reasoning |
| 19:07:49 | Demos | I agree, although writing bindings could be annoying. C is not a very good choice for a weekend project |
| 19:07:54 | BitPuffin | Araq: the reasoning was fowl isn't done with the allegro wrapper |
| 19:08:12 | BitPuffin | and that the risk of running in to a bug with nimrod is higher than with C, even if I write C-like nimrod |
| 19:08:13 | Araq | BitPuffin: so use .emit for these parts |
| 19:08:13 | BitPuffin | but yes |
| 19:08:23 | BitPuffin | no time for that |
| 19:08:42 | fowl | you have til the end of the month |
| 19:09:30 | fowl | BitPuffin, what is most important thats missing from the wrapper, i'll fast track it |
| 19:09:35 | Araq | BitPuffin: your swizzle matrix voodoo is indeed pressing the compiler hard but that doesn't mean that you run into compiler bugs all the time |
| 19:09:57 | Araq | I use the compiler all the time and don't run into compiler bugs fwiw |
| 19:10:07 | BitPuffin | another big part of the reasoning was that having something C on my portfolio makes me more employable |
| 19:10:25 | BitPuffin | fowl: well yeah but I don't wanna work on it until the end of the month, nor throw away what I've already done |
| 19:10:40 | Araq | but then I also don't play "need to use 3 chars less here" syntax games |
| 19:11:03 | BitPuffin | what? lol |
| 19:11:17 | Araq | in other words I use 'for' instead of lambdas ;-) |
| 19:11:20 | BitPuffin | you instead play the need to use 3 chars less here naming game |
| 19:11:34 | BitPuffin | you are not making sense, I also use for lol |
| 19:11:58 | * | fowl c2nim's bp's game |
| 19:13:19 | BitPuffin | it would probably work |
| 19:19:36 | EXetoC | Araq: identifier names excluded? :> |
| 19:22:05 | EXetoC | dom96: did you try that lambda macro? |
| 19:22:32 | dom96 | not yet |
| 19:24:04 | fowl | dom96, im adding on to your closure macro so you can do (a,b)->int=>4 |
| 19:24:53 | EXetoC | any type issues? |
| 19:25:43 | EXetoC | will it be possible to omit type information? |
| 19:26:27 | dom96 | fowl: What's the point of that if the compiler can infer that information? |
| 19:26:32 | dom96 | or at least it should be able to. |
| 19:26:48 | fowl | for void mainly |
| 19:27:59 | fowl | wordy lol: Error: A nested proc can have generic parameters only when it is used as an operand to another routine and the types of the generic paramers can be infered from the expected signature. |
| 19:29:02 | dom96 | You should implement the type syntax: (int, float) -> int for example |
| 19:29:17 | dom96 | will become: proc (x: int, y: float): int |
| 19:29:30 | fowl | how to discern between (a,b) and (int,float)? |
| 19:29:32 | dom96 | with a {.closure.} pragma |
| 19:29:45 | dom96 | Yeah, so your proposal clashes with that I guess. |
| 19:34:26 | EXetoC | dom96: will something like this be possible? "x.map(\(a, b, a + b))". no explicit types that is |
| 19:34:56 | EXetoC | what's your planned syntax? can it get more compact? |
| 19:34:56 | fowl | x.map((a,b)=>a+b) should |
| 19:34:59 | dom96 | Yes. It should be already. |
| 19:35:06 | EXetoC | ok |
| 19:35:07 | dom96 | But with the syntax fowl showed |
| 19:35:43 | EXetoC | excellent |
| 19:37:09 | fowl | https://gist.github.com/fowlmouth/9728562 |
| 19:38:29 | Araq | hi fowl |
| 19:38:38 | fowl | hi |
| 19:38:39 | Araq | it's your birthday |
| 19:38:53 | Araq | which bug is the most annoying to you? |
| 19:39:00 | fowl | :o |
| 19:39:09 | fowl | let me see |
| 19:39:20 | EXetoC | the one that says "1.0 not implemented" |
| 19:39:35 | Araq | EXetoC: now you know why I asked fowl :P |
| 19:39:58 | EXetoC | yeah.. |
| 19:40:28 | EXetoC | Araq: so what's your business with mongo? are you going to use it for something or do you just want to get rid of the one in stdlib? |
| 19:40:57 | Araq | EXetoC: already git cloned it. I'm looking at your reported "set literal" bug |
| 19:41:05 | EXetoC | oh |
| 19:42:54 | fowl | Araq, #431 still plagues me, though i found a workaround |
| 19:43:07 | fowl | its not a proper workaround |
| 19:44:23 | Araq | fowl: meh that's zahary's business but ok, let me have a look |
| 19:44:41 | Araq | what's the expected output? |
| 19:45:32 | fowl | 0 1 2 C1:2 C1: 4 |
| 19:46:46 | fowl | er.. 0 1 2 c1:3 c1:5 |
| 19:52:14 | BitPuffin | it's fowl's birthday? |
| 19:59:29 | * | DAddYE joined #nimrod |
| 20:02:21 | dom96 | So I think that the new async stuff should be usable now. |
| 20:03:57 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 20:29:18 | Araq | dom96: congratulations |
| 20:29:34 | Araq | now if only there weren't that many failing tests left ... |
| 20:30:16 | dom96 | I just got 10 pounds for pressing the numlock key to fix this woman's keyboard. |
| 20:31:17 | dom96 | Perhaps I should start a computer "repair" shop. |
| 20:31:24 | Araq | should have asked for a kiss instead |
| 20:31:39 | dom96 | hah |
| 20:32:15 | fowl | why does gb still use the pound |
| 20:32:41 | fowl | you are in the EU right |
| 20:32:52 | dom96 | Because the pound is superior |
| 20:32:53 | dom96 | brb |
| 20:33:59 | Araq | indeed. the Euro sucks. |
| 20:38:50 | Demos | is there a standard library function like binarySearch but returning the index where the thing would be if it were in the sequence? |
| 20:39:50 | Araq | no |
| 20:40:01 | Araq | but add it, it's useful |
| 20:40:28 | Araq | speculativeBinarySearch |
| 20:42:48 | Araq | fowl: I don't get your test |
| 20:44:14 | Araq | it outputs: |
| 20:44:22 | Araq | 0 |
| 20:44:24 | Araq | 1 |
| 20:44:25 | Araq | 2 |
| 20:44:27 | Araq | C1: 0 |
| 20:44:28 | Araq | C1: 2 |
| 20:45:40 | Araq | oh wait, never mind |
| 20:49:49 | * | xenagi joined #nimrod |
| 20:51:07 | * | xenagi quit (Client Quit) |
| 20:51:23 | * | xenagi joined #nimrod |
| 20:57:17 | fowl | it came up in entitty, the id counter for components, i ended up using the seq[pcomponentinfo]'s length as the counter |
| 21:00:05 | * | DAddYE joined #nimrod |
| 21:03:04 | * | renesac joined #nimrod |
| 21:04:51 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 21:07:29 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 21:23:16 | * | EXetoC joined #nimrod |
| 21:31:19 | BitPuffin | fowl: is it really your birthday? |
| 21:31:36 | fowl | no not til july |
| 21:39:53 | * | Endy quit (Ping timeout: 268 seconds) |
| 21:48:50 | BitPuffin | ah |
| 21:48:58 | BitPuffin | Araq: is such a trickster |
| 21:54:10 | * | zahary1 joined #nimrod |
| 21:54:37 | Demos | Araq: speculativeBinarySearch is a mouthfull! |
| 21:59:16 | EXetoC | spclbinsrc? |
| 22:00:45 | * | DAddYE joined #nimrod |
| 22:01:07 | Demos | c++ uses lowerBound |
| 22:01:11 | Demos | well std::lower_bound |
| 22:01:32 | fowl | std::herpes |
| 22:02:21 | * | Demos likes c++, sorta. All the features in it were a good idea at the time and in isolation |
| 22:05:16 | Demos | is there an adapter that can take an inline iterator and make it into a closure one? |
| 22:05:16 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 22:05:54 | Araq | good question. I dont think so. |
| 22:07:19 | Araq | and lowerBound makes sense too |
| 22:07:49 | Demos | allright, let me PR it up |
| 22:08:34 | Araq | speculativeBinarySearch is a much cooler name though |
| 22:08:52 | Araq | sounds like a powerful complex algorithm that way |
| 22:11:14 | * | renesac quit (Read error: Connection reset by peer) |
| 22:11:23 | Demos | hmmmmm I think I got a compiler bug as well |
| 22:12:02 | Demos | are there known bugs reguarding things getting wonky if you never write return result |
| 22:12:11 | Demos | wait shit |
| 22:12:13 | Demos | never mind |
| 22:12:39 | fowl | only if you shadow result |
| 22:13:37 | Demos | which I was doing |
| 22:13:56 | Demos | there seems to be a bug with default params of type proc(...) |
| 22:15:28 | Araq | fowl: it is not obvious to me why you don't use a .compileTime variable to compute the IDs |
| 22:15:54 | Araq | proc getID(t: typedesc): int = |
| 22:15:56 | Araq | var id{.global.} = static nextFoo() |
| 22:15:57 | Araq | return id |
| 22:16:14 | fowl | im not sure that was possible |
| 22:16:41 | Araq | compileTime vars now safe their state beyond module boundaries |
| 22:17:36 | fowl | yea but component needs to be instantiated so that PComponentInfo is created |
| 22:19:12 | * | OrionPK quit (Remote host closed the connection) |
| 22:19:58 | * | OrionPK joined #nimrod |
| 22:21:04 | * | Sorcy is now known as Ycros |
| 22:23:47 | Demos | oh hey nimrod has koenig lookup |
| 22:23:48 | Demos | neat |
| 22:26:02 | * | renesac joined #nimrod |
| 22:29:41 | * | q66 quit (Ping timeout: 252 seconds) |
| 22:32:39 | Demos | allright, pr out |
| 23:06:14 | * | xenagi quit (Quit: Leaving) |
| 23:23:17 | * | darkf joined #nimrod |
| 23:32:58 | * | renesac quit (Ping timeout: 240 seconds) |
| 23:34:27 | * | io2 quit () |
| 23:40:09 | * | brson joined #nimrod |
| 23:40:20 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:45:43 | * | renesac joined #nimrod |
| 23:59:21 | * | brson quit (Remote host closed the connection) |