| 00:00:08 | BitPuffin | sounds worth to be a core feature though |
| 00:00:13 | BitPuffin | much better than case :D |
| 00:00:54 | dom96 | I think you will be able to get same functionality with macros :P |
| 00:01:26 | BitPuffin | well yeah probably |
| 00:02:58 | EXetoC | MaxLineLength* = 80. oh come on, that's ancient :-P |
| 00:04:08 | reactormonk | EXetoC, it just complains |
| 00:04:13 | dom96 | BitPuffin: You should try it if you haven't already. I am planning to, but there is always something else to do... :) |
| 00:04:13 | reactormonk | and I gotta say, it's useful |
| 00:04:58 | dom96 | EXetoC: You can switch off the warnings |
| 00:05:45 | BitPuffin | dom96: well I still haven't tried nimrod even, it looks very interesting though. I've been playing with functional programming though lately (in haskell) and is very impressed with pattern matching's expressiveness (and rust has it too!), but yeah, it could be good enough to write a macro. Maybe such a macro could be added to the stdlib? |
| 00:06:28 | BitPuffin | what kind of GC does nimrod use? it's non tracing, but then what is it? ref counting? |
| 00:06:29 | dom96 | BitPuffin: Yeah, i'm sure Araq would happily allow it into the stdlib :) |
| 00:08:25 | BitPuffin | what opengl version is the one in the stdlib? |
| 00:08:36 | dom96 | BitPuffin: http://build.nimrod-code.org/docs/gc.html |
| 00:09:28 | EXetoC | "opengl New wrapper for OpenGL supporting up to version 4.2." |
| 00:09:42 | BitPuffin | hmm, too bad it's not 4.3 :P |
| 00:09:59 | EXetoC | ya, we all need that :> |
| 00:14:02 | dom96 | BitPuffin: You are welcome to update it and create a pull request :P |
| 00:14:18 | BitPuffin | well I don't even know the language :D |
| 00:14:24 | BitPuffin | and I can't test it |
| 00:14:43 | dom96 | learn it! |
| 00:15:56 | BitPuffin | I might! |
| 00:16:05 | BitPuffin | It's definitely interesting |
| 00:16:09 | BitPuffin | I like the syntax |
| 00:16:19 | dom96 | great! :D |
| 00:16:44 | EXetoC | yeah, bracket overload sucks |
| 00:16:55 | BitPuffin | although it seems like it's less "safe" than rust from the looks of it |
| 00:17:19 | BitPuffin | although I can't back that up |
| 00:18:53 | dom96 | I can't say I can comment on that, I haven't given Rust a fair try. |
| 00:19:19 | dom96 | EXetoC: hrm? |
| 00:19:45 | EXetoC | dom96: {}() |
| 00:19:54 | EXetoC | too much of that in some languages |
| 00:20:29 | dom96 | oh, that's what you mean. Yeah, whitespace ftw. |
| 00:21:10 | EXetoC | dom96: the safe subset of Rust requires you to specify the lifetime of objects, which means no accidental accesses to invalidated memory etc |
| 00:25:37 | * | BitPuffin quit (Ping timeout: 248 seconds) |
| 00:26:54 | dom96 | ahh, I suppose Rust and Nimrod really differ in that regard, for Nimrod the GC provides safety whereas Rust doesn't use a GC so it needs some other type of safety I guess. |
| 00:26:58 | * | BitPuffin joined #nimrod |
| 00:28:06 | EXetoC | dom96: it does actually |
| 00:28:17 | dom96 | However we have an effect system which will provide similar safety to Rust soon AFAIK. |
| 00:28:43 | BitPuffin | effect system? |
| 00:29:18 | dom96 | http://build.nimrod-code.org/docs/manual.html#effect-system |
| 00:30:31 | EXetoC | I don't know if the read/write thing is relevant |
| 00:31:10 | dom96 | It allows for any type of effect, for example "FUnsafe" |
| 00:31:56 | dom96 | (or will allow) |
| 00:31:56 | BitPuffin | hmm |
| 00:31:58 | BitPuffin | interesting |
| 00:32:09 | BitPuffin | so everything will be safe by default? |
| 00:32:14 | BitPuffin | unless you say it's unsafe |
| 00:32:22 | BitPuffin | (desirable) |
| 00:32:54 | dom96 | I'm not sure, you would have to ask Araq for the details when he's around. |
| 00:36:59 | BitPuffin | hmm, jsgen? |
| 00:37:07 | BitPuffin | (just watching the compilation) |
| 00:37:20 | dom96 | yeah, there is a JS backend. |
| 00:37:36 | dom96 | You can make the compiler generate JS code out of your Nimrod code. |
| 00:37:40 | BitPuffin | so you can compile to js? |
| 00:37:41 | BitPuffin | ooooh |
| 00:38:30 | BitPuffin | wouldn't these things get easier by using llvm? :D |
| 00:39:04 | dom96 | I think the JS backend predates emscripten :P |
| 00:40:11 | BitPuffin | I see :D |
| 00:44:00 | EXetoC | My high-level glfw3 wrapper should be usable soon |
| 00:44:27 | EXetoC | there's a glfw2 wrapper, but glfw3 was officially released not long ago |
| 00:44:35 | BitPuffin | is there a regular binding for 3? |
| 00:45:34 | BitPuffin | nimrod should get a package manager |
| 00:45:37 | EXetoC | nah, but I'll add most of the original API tomorrow |
| 00:45:41 | EXetoC | BitPuffin: babel |
| 00:45:42 | dom96 | it has one :P |
| 00:45:55 | BitPuffin | it does? |
| 00:46:00 | dom96 | what EXetoC said |
| 00:46:19 | BitPuffin | babel? |
| 00:46:21 | EXetoC | 13 packages \o/ |
| 00:46:22 | BitPuffin | is it an official one |
| 00:46:24 | EXetoC | ya |
| 00:48:52 | dom96 | BitPuffin: How did you find out about nimrod? :) |
| 00:49:35 | EXetoC | < |
| 00:49:44 | * | Associat0r quit (Quit: Associat0r) |
| 00:50:01 | EXetoC | I told him that Rust was so may 2013 |
| 00:50:05 | EXetoC | dom96: isn't that right? |
| 00:50:13 | dom96 | EXetoC: damn right |
| 00:50:20 | dom96 | EXetoC: Good job. |
| 00:52:56 | BitPuffin | :D |
| 00:54:20 | * | Associat0r joined #nimrod |
| 00:54:20 | * | Associat0r quit (Changing host) |
| 00:54:20 | * | Associat0r joined #nimrod |
| 00:55:31 | BitPuffin | does the js backend use asm.js? |
| 00:55:41 | dom96 | not yet |
| 00:56:29 | BitPuffin | EXetoC: why not just use the c2nim thing for glfw? |
| 00:57:27 | EXetoC | it didn't work. or maybe I had to expand the macros |
| 00:57:34 | BitPuffin | hm |
| 00:57:36 | EXetoC | after removing the GL includes anyway |
| 00:59:02 | * | DAddYE quit (Remote host closed the connection) |
| 00:59:03 | EXetoC | oh well, it's a simple api |
| 01:01:19 | BitPuffin | would be cool to have an allegro binding |
| 01:01:52 | BitPuffin | nimrod can infer types right? |
| 01:02:03 | EXetoC | yes |
| 01:07:02 | BitPuffin | good |
| 01:07:10 | EXetoC | dom96: what does 'del' do, and what does 'delete' do? |
| 01:07:12 | EXetoC | no cheating |
| 01:07:23 | dom96 | hehe |
| 01:07:57 | dom96 | er. 'del' is faster I believe and does not keep order of the sequence. |
| 01:08:11 | dom96 | 'delete' is slower and does keep the order |
| 01:08:17 | EXetoC | hence the short name, yeah? :> |
| 01:08:45 | dom96 | yep, shorter = faster :P |
| 01:09:19 | EXetoC | an even faster version would be called d |
| 01:09:19 | BitPuffin | the sequence? |
| 01:10:12 | dom96 | dynamic array |
| 01:11:16 | BitPuffin | aha |
| 01:11:24 | BitPuffin | well I don't know what delete does so hehe |
| 01:11:32 | BitPuffin | can nimrod slice arrays? |
| 01:12:33 | EXetoC | proc `..`*[T](a, b: T): TSlice[T] {.noSideEffect, inline.} = |
| 01:12:54 | EXetoC | proc `..`*[T](b: T): TSlice[T] {.noSideEffect, inline.} = |
| 01:13:14 | BitPuffin | err |
| 01:13:19 | dom96 | I know you can slice strings, not sure if you can slice arrays. |
| 01:13:36 | dom96 | But if you can't, it's probably a procedure away. |
| 01:13:40 | BitPuffin | awh, no if expressions, only statements |
| 01:13:41 | EXetoC | nvm that creates an interval |
| 01:13:52 | EXetoC | BitPuffin: false |
| 01:14:13 | BitPuffin | well why does the tutorial say statement then? |
| 01:15:05 | * | XAMPP joined #nimrod |
| 01:15:35 | EXetoC | I don't know, but I realized yesterday that they were expressions |
| 01:15:54 | dom96 | because the statement/expression unification happened recently |
| 01:16:14 | EXetoC | var a = if true: 0 else: 1 |
| 01:16:26 | EXetoC | though with the correct indentation and what have you |
| 01:16:41 | EXetoC | or maybe that works |
| 01:16:52 | dom96 | that would work, yes. |
| 01:17:31 | EXetoC | "proc `[]`*[Idx, T](a: array[Idx, T], x: TSlice[int]): seq[T] =" |
| 01:17:49 | dom96 | there you go |
| 01:17:54 | BitPuffin | EXetoC: dude are you trying to scare me away with those devil lines :D |
| 01:18:10 | BitPuffin | I've only reached the case statement |
| 01:18:36 | dom96 | Those lines are holy, they are a work of angels :P |
| 01:19:03 | BitPuffin | well not for a nub |
| 01:19:56 | EXetoC | :-P |
| 01:23:52 | EXetoC | coding while tired is such a waste of time |
| 01:23:57 | EXetoC | later |
| 01:24:07 | dom96 | yeah, I should sleep too. |
| 01:24:09 | dom96 | Bye |
| 01:24:28 | EXetoC | good luck! |
| 01:25:38 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 01:28:44 | BitPuffin | gnight! |
| 01:33:17 | * | BitPuffin quit (Ping timeout: 268 seconds) |
| 04:22:24 | * | OrionPK quit (Quit: Leaving) |
| 05:21:16 | * | q66 joined #nimrod |
| 06:47:55 | * | XAMPP quit (Ping timeout: 264 seconds) |
| 07:32:45 | * | Associat0r quit (Quit: Associat0r) |
| 07:41:43 | * | Araq_ joined #nimrod |
| 07:48:33 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) |
| 09:12:20 | * | EXetoC joined #nimrod |
| 09:20:37 | * | BitPuffin joined #nimrod |
| 09:24:27 | * | Araq_ joined #nimrod |
| 09:26:58 | Araq_ | EXetoC: c2nim's #def expands macros for you |
| 09:27:21 | Araq_ | I keep telling people about it, people keep ignoring it ... I wonder why |
| 09:33:01 | EXetoC | I didn't really look into it, but I'll see if that helps |
| 09:38:03 | BitPuffin | block cock: # har har |
| 09:39:36 | EXetoC | huehue |
| 09:41:03 | BitPuffin | oh hey Araq_! Nice language you got here, we were discussing yesterday about having haskell and rust like pattern matching implemented with macros and then added to some std thing. What do you think? Also we were talking about safety, with the effect system, will it be safe by default so that if you want unsafe stuff you have to mark it as such? |
| 09:46:04 | EXetoC | Araq_: ok that was easy |
| 09:47:31 | Araq_ | BitPuffin: I read it by now |
| 09:47:50 | BitPuffin | Araq_: oh, in the logs? |
| 09:48:06 | BitPuffin | didn't realize there were logs :P |
| 09:48:20 | Araq_ | I'm still working on a better concurrency system that's safe; it's too early to tell how it will compare to Rust's |
| 09:48:30 | * | Araq_ quit (Read error: Connection timed out) |
| 09:48:46 | EXetoC | quick timeout |
| 09:49:27 | * | Araq_ joined #nimrod |
| 09:49:33 | BitPuffin | welcome back |
| 09:49:44 | BitPuffin | what's the plans for the system? |
| 09:51:21 | Araq_ | plan: no crappy message passing, but deadlock and race freedom |
| 09:51:44 | BitPuffin | woot! |
| 09:51:50 | Araq_ | well ... we already have message passing, so it's boring |
| 09:52:30 | BitPuffin | but deadlocks and races are also boring! :D |
| 09:53:53 | Araq_ | btw Nimrod's case objects are more flexible than traditional sum types ... hence pattern matching doesn't work as well for them |
| 09:54:25 | BitPuffin | how are they more flexible? |
| 09:55:19 | Araq_ | you can share branches like so: |
| 09:56:15 | Araq_ | case d: someenum |
| 09:56:51 | Araq_ | of valA..valZ: value: int |
| 09:57:01 | Araq_ | else: f: float |
| 09:58:50 | Araq_ | though it's easy to get very close with a traditional sum type |
| 09:59:49 | Araq_ | (intValue int | floatValue float) * someenum |
| 10:11:57 | BitPuffin | hmm |
| 10:12:00 | BitPuffin | so it's algebraic? |
| 10:20:09 | Araq_ | dunno what you mean; sum types are often called algebraic |
| 10:20:57 | BitPuffin | well that you can pass more than one type |
| 10:22:55 | EXetoC | at runtime that is |
| 10:23:12 | Araq_ | you sound confused :P |
| 10:23:24 | Araq_ | my example is an object declaration, so it's 1 type |
| 10:23:30 | Araq_ | *is in an |
| 10:23:50 | BitPuffin | well I'm still just learning the basics of the language |
| 10:24:28 | BitPuffin | is enum like rust's enum or is it like say Java enum? |
| 10:24:52 | BitPuffin | is rust they are like structs that have more than one representation |
| 10:24:58 | BitPuffin | in* |
| 10:25:11 | BitPuffin | and in other languages it's just constants |
| 10:26:44 | EXetoC | they're not always tagged in Rust, but yes they can be |
| 10:26:47 | Araq_ | just constants but strongly typed |
| 10:26:54 | Araq_ | bbl |
| 10:26:57 | * | Araq_ quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) |
| 10:27:22 | EXetoC | they can be homogenous as well, but it's currently very limited because the type must be int |
| 10:32:16 | BitPuffin | why's that? |
| 10:33:12 | EXetoC | I think it's just an arbitrary limitation. I think it might be replaced by a library alternative though |
| 10:33:26 | dom96 | hello |
| 10:34:34 | EXetoC | hi |
| 10:34:42 | * | Endeg quit (Read error: Connection reset by peer) |
| 10:34:54 | BitPuffin | brb walk dogs |
| 11:16:53 | EXetoC | was it safe out there? |
| 11:19:32 | EXetoC | what will be your primary language? I won't use D anymore for various reasons |
| 11:37:22 | * | Endeg joined #nimrod |
| 12:56:48 | BitPuffin | EXetoC: haven't decided yet |
| 12:56:57 | BitPuffin | I was thinking it was gonna be rust |
| 12:57:03 | BitPuffin | but nimrod is interesting |
| 12:57:47 | BitPuffin | one thing that makes nimrod very suitable for games is that it compiles to C |
| 12:58:02 | BitPuffin | which means that you could make console ports of your games |
| 12:59:22 | BitPuffin | and you could make webgl ports since it compiles to javascript |
| 12:59:43 | BitPuffin | EXetoC: why won't you use D? |
| 13:07:27 | EXetoC | the syntax is verbose, and some bad language decisions have been made |
| 13:08:08 | BitPuffin | like what? |
| 13:08:11 | EXetoC | I don't think Walter has used it for anything other than trivial utility applications |
| 13:09:05 | EXetoC | so that would partly explain why |
| 13:09:28 | BitPuffin | that's where rust shines through, the browser engine they are building to test the language |
| 13:10:11 | BitPuffin | but what language decisions do you mean? |
| 13:10:42 | dom96 | is the D compiler not written in D? |
| 13:12:33 | BitPuffin | no |
| 13:12:34 | BitPuffin | C++ |
| 13:12:36 | BitPuffin | :/ |
| 13:13:02 | BitPuffin | compiler would be way less buggy if it was written in D |
| 13:15:38 | EXetoC | BitPuffin: because of lack of built-in tuples, bad invariant semantics, silly default constructor limitations for structs, the need for Rebindable etc |
| 13:17:50 | BitPuffin | EXetoC: there is built-in tuples aren't there? or is it in the stdlib? |
| 13:17:57 | EXetoC | it would be an improvement over C++ had the implementation not sucked, but I'm too much of a language enthusiast to not use these more interesting languages instead |
| 13:18:21 | EXetoC | BitPuffin: yes, you need to use std.typecons.{T,t}uple |
| 13:20:31 | EXetoC | and then you have these version statement issues that are supposed to keep conditional compilation simple (at least compared to C macros that are "too complex") |
| 13:21:13 | EXetoC | but you often end up defining enums inside those blocks instead, just as a way to avoid 'version' as much as possible :> |
| 13:21:35 | EXetoC | ok enough hating. I don't think I need to say more |
| 13:24:32 | BitPuffin | EXetoC: hrm yeah, nimrod seems kind of programmable |
| 13:25:46 | EXetoC | yep https://github.com/dom96/jester |
| 13:28:38 | dom96 | Today is the day, the day of the framework benchmarks :D |
| 13:28:55 | EXetoC | I'm working on a library implementation of an invariant construct. I shouldn't need more than 40-50 lines of code for my first impl |
| 13:29:35 | EXetoC | dom96: do you think you'll win? :> |
| 13:29:50 | dom96 | I doubt it hah |
| 13:30:27 | BitPuffin | EXetoC: how's the glfw stuff coming around? |
| 13:30:51 | dom96 | but hopefully it will bring some fame to Nimrod. |
| 13:31:51 | EXetoC | BitPuffin: it should be usable at the end up the day |
| 13:32:08 | EXetoC | the high-level wrapper that is. the 1:1 wrapper has already been generated |
| 13:32:10 | BitPuffin | it better be, or else! ;D |
| 13:32:29 | BitPuffin | you mean a nimrodized wrapper? |
| 13:32:59 | EXetoC | yes |
| 13:34:12 | BitPuffin | hmm, cool! |
| 13:36:00 | EXetoC | just enums instead of separate constants and then type-safe arrays basically |
| 13:37:00 | EXetoC | oh, and automated error handling by default (exceptions) |
| 13:37:01 | BitPuffin | arrays? |
| 13:37:06 | BitPuffin | oh cool |
| 13:37:14 | BitPuffin | have you also adapted the parameters? |
| 13:37:20 | EXetoC | I say that, because many errors are fatal anyway, so you might as well not handle them :> |
| 13:37:21 | BitPuffin | so that it's a C string etc |
| 13:37:28 | BitPuffin | if that's even a problem with nimrod |
| 13:37:48 | EXetoC | nimrod strings are implicitly convertible to 'cstring' |
| 13:38:18 | EXetoC | the interface will still use nimrod strings though |
| 13:38:45 | BitPuffin | cool |
| 13:39:09 | BitPuffin | can any two parameter proc be called infix using `` like in haskell? |
| 13:42:05 | EXetoC | proc `?`(x:int): bool = x == 42 |
| 13:42:18 | EXetoC | oops, misread |
| 13:42:33 | EXetoC | I haven't encountered anything like that yet |
| 13:42:59 | EXetoC | bbs! |
| 13:43:00 | BitPuffin | well say you have a proc called in |
| 13:43:17 | BitPuffin | proc in(a, b) = blabla |
| 13:43:23 | BitPuffin | a `in` b |
| 13:50:24 | dom96 | In that case 'in' is a keyword so you would overload the 'contains' function. |
| 13:51:10 | BitPuffin | well yeah |
| 13:51:13 | BitPuffin | but you know |
| 13:51:17 | BitPuffin | if it wasn't a keyword |
| 13:51:34 | BitPuffin | can I call any arbitrary two parameter proc infix? |
| 13:52:39 | dom96 | I think it has to be an operator |
| 14:01:19 | BitPuffin | hmm |
| 14:01:47 | BitPuffin | can an operator contain regular function letters? |
| 14:01:53 | BitPuffin | like proc `hey` |
| 14:05:01 | dom96 | I don't think so. (Just checked) |
| 14:05:14 | dom96 | As soon as I introduce a letter it fails to compile. |
| 14:05:36 | * | comex` joined #nimrod |
| 14:06:51 | BitPuffin | :/ |
| 14:06:55 | BitPuffin | shame |
| 14:09:25 | * | XAMPP joined #nimrod |
| 14:11:47 | * | comex quit (*.net *.split) |
| 14:22:47 | EXetoC | it's mostly useful for operators I think, since including the period would be ugly |
| 14:23:34 | BitPuffin | why would you use the period? |
| 14:25:09 | EXetoC | wouldn't you had there been no syntax for infix? |
| 14:26:16 | EXetoC | "template `in` * (x, y: expr): expr {.immediate.} = contains(y, x)" this is why you need to overload contains rather than 'in' in case you wondered |
| 14:27:16 | BitPuffin | well no you'd just call it as y `contains` x |
| 14:30:16 | EXetoC | but then you have syntax for it |
| 14:36:08 | EXetoC | nevermind, that's not actually how it works. infix and prefix are both supported for operators, so a period wouldn't be needed either way |
| 14:37:36 | EXetoC | how come he didn't go for polish notation? :> |
| 14:40:30 | * | zahary__ joined #nimrod |
| 14:41:34 | EXetoC | or something like 1+3 * 4 = 16, 1 + 3 * 4 = 13 |
| 14:43:57 | dom96 | I recall Araq considering implementing that ^ |
| 14:44:03 | EXetoC | maybe a macro could do that |
| 14:44:16 | EXetoC | oh |
| 14:44:29 | BitPuffin | does an enum declaration have to be surrounded by type? |
| 14:44:32 | dom96 | I don't think the AST includes that info. |
| 14:45:12 | EXetoC | BitPuffin: I think all type declarations do |
| 14:45:33 | EXetoC | though you might be able to omit the newline and indentation |
| 14:47:01 | dom96 | I don't think you can declare anonymous enums if that's what you mean. |
| 14:48:07 | * | zahary__ left #nimrod (#nimrod) |
| 14:48:20 | * | zahary__ joined #nimrod |
| 14:48:20 | BitPuffin | no I mean if I can do MyEnum = enum a b c |
| 14:49:20 | * | zahary_ quit (*.net *.split) |
| 14:49:24 | EXetoC | dom96: maybe if there was a whitespace node, that'd be omitted for stmt and expr, but not for stmt_ws and expr_ws or something like that |
| 14:50:08 | EXetoC | if stmt is even here to stay. are there statements that are supposed to be expressions, but aren't yet? |
| 14:52:42 | dom96 | BitPuffin: oh you mean omitting the 'type' keyword? Yeah, you can't. |
| 14:52:49 | * | comex` quit (Ping timeout: 244 seconds) |
| 14:53:00 | * | comex joined #nimrod |
| 14:54:50 | dom96 | EXetoC: I would guess that it's not that easy to add something like that. But I haven't dabbled much with the compiler internals. |
| 14:59:50 | EXetoC | I wonder if one needs to do more than just add a node rather than just ignoring the token |
| 15:06:40 | EXetoC | type parameters can take values if I'm not mistaken, but is it possible to have them take only values? |
| 15:07:07 | EXetoC | it might be possible to add restrictions using 'when', but that's not part of the public interface, so it wouldn't be self-documenting |
| 15:08:20 | dom96 | hrm, this? http://build.nimrod-code.org/docs/manual.html#parameter-constraints |
| 15:11:30 | EXetoC | dom96: I think so. It should just be a matter of specializing based on what enumerator is passed in |
| 15:12:24 | EXetoC | awsum |
| 15:27:25 | EXetoC | I don't even need any of that; I just need a template |
| 15:46:27 | * | JStoker quit (*.net *.split) |
| 15:46:28 | * | Araq quit (*.net *.split) |
| 15:59:33 | * | Endy joined #nimrod |
| 16:12:50 | * | JStoker joined #nimrod |
| 16:12:50 | * | Araq joined #nimrod |
| 16:15:45 | fowl | i want to use try: except: as an expression but not in one line |
| 16:15:48 | fowl | is it possible |
| 16:17:07 | * | q66_ joined #nimrod |
| 16:19:53 | * | q66 quit (Ping timeout: 264 seconds) |
| 16:19:54 | * | reactormonk quit (Ping timeout: 264 seconds) |
| 16:19:55 | * | Amrykid quit (Ping timeout: 264 seconds) |
| 16:20:35 | * | Amrykid joined #nimrod |
| 16:21:12 | * | reactormonk joined #nimrod |
| 16:24:49 | dom96 | fowl: Perhaps if you indent it properly, I don't know. |
| 16:26:59 | EXetoC | works with if |
| 16:27:38 | fowl | EXetoC, how |
| 16:28:48 | fowl | these fail: https://gist.github.com/fowlmouth/5859948 |
| 16:29:30 | EXetoC | well, I know that the parens should be there |
| 16:29:32 | EXetoC | let me check |
| 16:29:36 | EXetoC | *shouldn't |
| 16:30:04 | fowl | huh you're right |
| 16:30:13 | fowl | the if works without the parens but the try:except: doesnt |
| 16:33:29 | * | DAddYE joined #nimrod |
| 16:34:07 | dom96 | fowl: this works: https://gist.github.com/dom96/c76ae58cbec753b8a187 |
| 16:34:33 | fowl | dom96, not the same thing |
| 16:34:40 | dom96 | yeah, I know. |
| 16:35:39 | dom96 | Can't get it to work when assigning to a var. |
| 16:38:43 | BitPuffin | not sure I understand this notation |
| 16:38:53 | BitPuffin | TIntArray = array[0..5, int] |
| 16:39:06 | dom96 | An int array of size 6. |
| 16:39:07 | BitPuffin | it says it's indexed with 0..5 |
| 16:39:07 | fowl | 0 .. 5 is the range of indexes |
| 16:39:23 | fowl | BitPuffin, in HEAD you can do array[6, int] for the same thing |
| 16:39:50 | BitPuffin | in head? |
| 16:39:54 | BitPuffin | oh git head |
| 16:40:28 | BitPuffin | so you can specify that you index from 89..232? |
| 16:40:57 | fowl | yea |
| 16:41:01 | dom96 | You can also specify an enum |
| 16:42:21 | BitPuffin | yep just saw that in tutorial |
| 16:42:25 | BitPuffin | funky |
| 16:50:24 | * | Associat0r joined #nimrod |
| 16:50:24 | * | Associat0r quit (Changing host) |
| 16:50:24 | * | Associat0r joined #nimrod |
| 16:50:37 | BitPuffin | so there is no built in syntax for slicing a sequence? |
| 16:51:50 | fowl | slicing (copying into a new sequence) is expensive, you are better off to iterate over the range you want to work with |
| 16:52:15 | dom96 | yeah, but syntax for it exists. |
| 16:52:25 | BitPuffin | no not copying |
| 16:52:32 | BitPuffin | you get a pointer to the range |
| 16:52:40 | BitPuffin | at least that's how it works in D |
| 16:53:04 | fowl | then if you modify the slice you modify the original |
| 16:53:27 | BitPuffin | yes |
| 16:53:31 | BitPuffin | ofc |
| 16:54:20 | BitPuffin | it's the point |
| 16:54:35 | fowl | is it? in most languages when you slice a string and modify it, it does not modify the original |
| 16:55:31 | BitPuffin | well we're not talking strings |
| 16:55:47 | BitPuffin | you have the choice to dup it ofc! |
| 16:58:49 | fowl | you have the choice to use `for` and just work on the range you want, without slicing, so.. |
| 16:59:23 | fowl | id rather the behavior be consistent between seq/string/other collections |
| 17:02:32 | BitPuffin | hrm |
| 17:02:41 | BitPuffin | well is there a way to slice and get a pointer explicitly? |
| 17:05:31 | fowl | well if you take the address of the first and last items you want, you have c++ style "iterators" |
| 17:10:09 | BitPuffin | hmm |
| 17:10:15 | BitPuffin | well I ment with the slicing syntax |
| 17:10:24 | BitPuffin | can you make it so that you get a reference |
| 17:10:36 | BitPuffin | without doing it manually like that |
| 17:10:54 | fowl | probably |
| 17:11:32 | fowl | create some SubSeq[T] type with a pointer to the seq and indexes then cover all of seq's functions for it |
| 17:12:00 | fowl | https://gist.github.com/fowlmouth/5860323 |
| 17:12:04 | fowl | i call it the shiterator |
| 17:12:53 | * | XAMPP_ joined #nimrod |
| 17:13:29 | * | zahary___ joined #nimrod |
| 17:15:24 | * | BitPuffin_ joined #nimrod |
| 17:21:50 | * | zahary__ quit (*.net *.split) |
| 17:21:50 | * | XAMPP quit (*.net *.split) |
| 17:21:50 | * | Endeg quit (*.net *.split) |
| 17:21:50 | * | BitPuffin quit (*.net *.split) |
| 17:21:50 | * | EXetoC quit (*.net *.split) |
| 17:25:57 | BitPuffin_ | should I read the manual or the tutorial? I'm confused by the opening words in tutorial pt 2 |
| 17:26:30 | dom96 | Read the tutorial but do skim over the manual at least. |
| 17:26:47 | fowl | <- still learns things from the manual |
| 17:26:53 | dom96 | The manual is pretty easy to understand. |
| 17:27:10 | * | dom96 does too |
| 17:44:36 | dom96 | hrm, getTempDir seems to return a path with / as separators when executed in git bash, but in cmd.exe it returns it with \ |
| 17:44:55 | dom96 | lovely. |
| 17:45:29 | * | EXetoC joined #nimrod |
| 17:48:54 | Araq | fowl: it's not possible for now |
| 17:49:51 | dom96 | Araq: I'm just going to replace '/' with DirSep on Windows for those functions, is that fine? |
| 17:50:13 | Araq | BitPuffin_: you can implement D-like slices very easily with the shallow pragma |
| 17:50:51 | dom96 | hrm, actually. Maybe Windows doesn't mind path separators mixing, must just be git being silly. |
| 17:51:40 | Araq | the builtin slice operators return a copy, but it's often easy to optimize away with a TR macro |
| 17:52:11 | Araq | the stdlib doesn't make use of TR macros at all for now |
| 17:53:51 | Araq | dom96: look at the implementation of getTempDir, it's getEnv"TEMP" |
| 17:54:12 | dom96 | Araq: Yeah? |
| 17:55:11 | Araq | maybe we should call some winapi stuff instead |
| 17:55:41 | Araq | but %TEMP% should contain \ not / |
| 17:55:57 | dom96 | As I said, it doesn't when it's executed in git bash. |
| 17:56:17 | Araq | interesting |
| 17:56:45 | dom96 | The winapi function does mostly the same thing we do. |
| 17:56:58 | dom96 | But it does do more. |
| 18:02:25 | Araq | it's also not thread safe |
| 18:02:43 | Araq | well at least the .NET version claims to be but isn't |
| 18:06:44 | dom96 | Araq: Framework benchmarks today! |
| 18:12:56 | Araq | dom96: well? how are the results? |
| 18:13:05 | dom96 | They're not out yet :P |
| 18:14:09 | Araq | well today is almost over |
| 18:14:25 | dom96 | timezones, duh. |
| 18:16:47 | dom96 | so babel works :D |
| 18:17:01 | Araq | on windows? |
| 18:17:15 | EXetoC | BitPuffin_: are you planning on using glfw for anything? |
| 18:18:00 | dom96 | Araq: yep |
| 18:18:45 | Araq | does it require git even for packages which don't use git? |
| 18:18:59 | dom96 | it now generates .bat file in ~/.babel/bin, I tried generating a script with the .exe extension but as you might imagine it doesn't like that |
| 18:19:18 | dom96 | Araq: There are no packages which don't require git. |
| 18:19:41 | Araq | you can generate an executable with the .exe extension |
| 18:19:53 | Araq | and that's what adrianv proposed |
| 18:20:19 | dom96 | oh, I see what he means now. |
| 18:20:55 | dom96 | Isn't .bat good enough? |
| 18:21:14 | Araq | in fact, I like it better as it uses less space |
| 18:21:31 | dom96 | i'm not sure if file associations will work with .bat though |
| 18:21:56 | Araq | I don't know, I think it does |
| 18:22:02 | Araq | try it |
| 18:24:57 | dom96 | cool, just needed to adjust the bat script a bit so that it passes the cmd line args and it works :D |
| 18:37:20 | NimBot | nimrod-code/babel master 5b45d6b Dominik Picheta [+0 ±1 -0]: Fixes many issues on Windows.... 3 more lines |
| 18:42:08 | * | Endy quit (Ping timeout: 260 seconds) |
| 19:02:25 | * | Sergio965 joined #nimrod |
| 19:11:19 | EXetoC | meep meep *vroooom* |
| 19:14:16 | NimBot | Araq/Nimrod master 586461a Dominik Picheta [+0 ±5 -0]: Deprecated OSError, and modified it to require an explicit OS error code.... 2 more lines |
| 19:35:41 | * | Associat0r quit (Quit: Associat0r) |
| 19:43:53 | Araq | EXetoC: what do you mean enums are int based? of course they are, that's their point, it's not a sum type |
| 19:50:26 | EXetoC | Araq: in Rust that is |
| 19:50:34 | EXetoC | it can *only* be int of all the primitives that the language has |
| 19:51:11 | Araq | dunno what you mean |
| 19:51:42 | EXetoC | Araq: the enumerators can't be unsigned for example |
| 19:52:03 | EXetoC | anyway, D allows structs to be used for enumerators as long as they're comparable, which is nice |
| 19:52:36 | Araq | nimrod has a concept of an "ordinal" type |
| 19:53:04 | EXetoC | right |
| 19:55:56 | Araq | I still don't get it; traditionally in a sum type the tags/constructors are just symbols, it doesn't make sense to say they are "int based" |
| 19:56:10 | * | Sergio965 quit (Ping timeout: 270 seconds) |
| 19:58:59 | EXetoC | I wasn't referring to sum types just then, but rather just a collection of values |
| 20:00:48 | EXetoC | and Rust's enums can be both tagged and not, in case that wasn't clear |
| 20:04:18 | dom96 | argh, they've delayed the benchmarks again ugh. |
| 20:04:27 | EXetoC | :p |
| 20:05:07 | Araq | dom96: that's because your program is still running ... :P |
| 20:06:33 | dom96 | Araq: Maybe it never got to run, it's probably still compiling... :P |
| 20:07:15 | Araq | well played |
| 20:10:27 | BitPuffin_ | EXetoC: yes I am |
| 20:18:00 | NimBot | Araq/Nimrod master d112aa9 onionhammer [+0 ±1 -0]: Fix: OpenSSL on Windows... 6 more lines |
| 20:18:00 | NimBot | Araq/Nimrod master 342d57f Dominik Picheta [+0 ±1 -0]: Merge pull request #489 from onionhammer/patch-1... 2 more lines |
| 20:37:32 | BitPuffin_ | EXetoC: a game! |
| 20:37:39 | BitPuffin_ | might actually use nimrod for it |
| 20:37:45 | BitPuffin_ | as an experiment :) |
| 20:38:37 | BitPuffin_ | is there any bindings to, say portaudio? |
| 20:46:25 | EXetoC | I haven't seen such a lib. I'm using libao |
| 21:00:15 | dom96 | we should tell gradha to play this on his oculus rift: https://developer.oculusvr.com/forums/viewtopic.php?f=42&t=1539 |
| 21:09:37 | BitPuffin_ | EXetoC: libao? |
| 21:10:02 | EXetoC | BitPuffin_: http://www.xiph.org/ao/doc/ |
| 21:10:16 | BitPuffin_ | ooh |
| 21:10:25 | BitPuffin_ | didn't know xiph had an audio api |
| 21:10:25 | BitPuffin_ | cooool |
| 21:10:30 | BitPuffin_ | is it any good? |
| 21:10:59 | EXetoC | it makes noise when I feed it stuff. good enough for me :> |
| 21:11:23 | BitPuffin_ | hehe |
| 21:12:41 | BitPuffin_ | I wonder how they compare |
| 21:12:48 | BitPuffin_ | EXetoC: can you use it to make 3d audio? |
| 21:14:57 | EXetoC | BitPuffin_: you'd have to implement that yourself |
| 21:15:15 | EXetoC | which you can if you select anything other than mono, and then do a little vector math, I guess |
| 21:16:50 | BitPuffin_ | yeah same with portaudio afaik |
| 21:16:58 | BitPuffin_ | but I just wanted to know if it is possible |
| 21:17:07 | BitPuffin_ | EXetoC: so there are nimrod bindings to libao? |
| 21:18:34 | BitPuffin_ | can you use it to play procedurally generated sound? |
| 21:20:31 | EXetoC | yes. you give it data, and then it blocks for however many seconds the length corresponds to |
| 21:21:12 | EXetoC | BitPuffin_: only my own lib, which I haven't made available through github yet |
| 21:23:50 | BitPuffin_ | I see |
| 21:23:58 | BitPuffin_ | can it play multiple sounds? |
| 21:25:42 | EXetoC | yep |
| 21:26:15 | EXetoC | I use a single device for that, but the easiest way is to just create multiple devices |
| 21:30:34 | EXetoC | so yeah, pretty much no bells and whistles |
| 21:36:33 | EXetoC | I'll gist it in a minute |
| 21:44:03 | EXetoC | https://gist.github.com/EXetoC/5862718 |
| 21:44:19 | * | q66_ quit (Remote host closed the connection) |
| 21:46:46 | EXetoC | the destructor pragma doesn't always work though, but that shouldn't be an issue; and line 108 needs error handling, but that's a minor issue |
| 23:00:40 | NimBot | Araq/Nimrod master ad9e3ff Dominik Picheta [+0 ±3 -0]: Fixed OSError deprecation warnings. |
| 23:14:06 | dom96 | http://forum.nimrod-code.org/t/163/2#841 |
| 23:15:08 | dom96 | Everyone, start creating babel packages now! |
| 23:15:45 | fowl | dom96, if i make nake a binary can i still import it as a lib |
| 23:17:31 | dom96 | Not currently. |
| 23:17:42 | dom96 | But I suspected someone will want that. |
| 23:18:09 | dom96 | I guess it's not hard to support. |
| 23:19:20 | dom96 | Feels dirty though. |
| 23:20:06 | dom96 | I think other package managers allow it. |
| 23:22:32 | fowl | nake has use as both |
| 23:24:20 | dom96 | yeah, sure. I can't think of any scenario where it would cause bother. |
| 23:24:25 | * | dom96 will implement it |
| 23:30:26 | NimBot | nimrod-code/babel master 30d3177 Dominik Picheta [+0 ±1 -0]: Binary packages can now be used as libraries by other binary packages. |
| 23:30:38 | dom96 | fowl: There you go, I haven't tested it much though. |
| 23:42:28 | EXetoC | how should C buffers be indexed? I'm sure there's a way that doesn't involve two casts |
| 23:42:31 | EXetoC | not directly anyway |
| 23:47:25 | fowl | dom96, cool, ill do so later |
| 23:47:28 | fowl | thanks |
| 23:48:19 | dom96 | ugh, execProcess should really return the exit code too I think. |
| 23:49:04 | fowl | EXetoC, instead of sometype* (ptr sometype) use ptr array[50000, sometype] |
| 23:55:58 | fowl | if i understood you right |