| 00:04:19 | * | XAMPP joined #nimrod |
| 03:42:45 | * | JStoker quit (Quit: JStoker is gone :() |
| 04:03:31 | * | JStoker joined #nimrod |
| 04:04:20 | * | JStoker quit (Remote host closed the connection) |
| 04:18:24 | * | JStoker joined #nimrod |
| 04:45:20 | * | fowl quit (Read error: Connection reset by peer) |
| 05:13:33 | reactormonk | cool @ #345 - so I can start using it for emacs |
| 05:54:07 | * | fowl joined #nimrod |
| 06:25:11 | * | fam|work joined #nimrod |
| 09:01:19 | Araq | hi fam|work, welcome! |
| 09:20:00 | fam|work | hola |
| 09:50:06 | Araq | oh no ... are you the guy that only speaks spanish? |
| 10:31:30 | fam|work | nope |
| 10:31:44 | Araq | oh alright then |
| 10:33:18 | fam|work | have i passed check? |
| 10:33:40 | Araq | sorry, we recently had a troll here that would insult us in spanish |
| 10:34:58 | fam|work | from your side it was like ban/or dont ban him? =] |
| 10:35:38 | Araq | dom96 banned him; I don't think he got in any kind of moral dilemma about it ;-) |
| 11:02:11 | * | Trixar_za is now known as Trix[a]r_za |
| 11:47:15 | * | fowl quit (Ping timeout: 258 seconds) |
| 11:55:48 | * | ddl_smurf joined #nimrod |
| 11:58:15 | * | fowl joined #nimrod |
| 12:05:36 | * | ddl_smurf quit (Quit: _) |
| 12:40:40 | * | fowl quit (Read error: Connection timed out) |
| 12:45:44 | * | q66 joined #nimrod |
| 12:48:58 | * | ack006 joined #nimrod |
| 12:58:05 | * | zahary_ quit (Read error: Connection reset by peer) |
| 12:58:44 | * | fowl joined #nimrod |
| 13:02:39 | * | fam|work quit (Ping timeout: 260 seconds) |
| 14:20:35 | * | fowl quit (Ping timeout: 258 seconds) |
| 14:22:51 | reactormonk | proc `-` (a, b: TTime): int64 = |
| 14:22:53 | reactormonk | return a.getTime() - b.getTime() |
| 14:22:55 | reactormonk | gives me |
| 14:22:57 | reactormonk | lib/pure/times.nim(491, 21) Error: can have an unlisted effect: TEffect |
| 14:23:29 | Araq | the problem is how the "methods" are declared for JS |
| 14:23:57 | Araq | you need to add {.tags: [].} for importing them |
| 14:24:07 | Araq | otherwise the compiler assumes to have some effect ;-) |
| 14:25:27 | NimBot | Araq/Nimrod 724c402 Araq [+4 ±10 -0]: fixes #287; bugfix: subrange checking is performed again |
| 14:29:07 | Araq | reactormonk: times.nim:440 should be |
| 14:29:23 | Araq | proc newDate(): TTime {.importc: "new Date", nodecl, tags: [FTime].} |
| 14:30:44 | reactormonk | btw, do I need nodecl for importc? |
| 14:31:08 | Araq | I think for the JS target you don't |
| 14:32:12 | reactormonk | proc newDate(): TTime {.importc: "new Date", tags: [FTime].} |
| 14:32:16 | reactormonk | but still get that |
| 14:32:32 | Araq | oh my bad |
| 14:33:26 | Araq | you need to add {.tags: [].} to any 'proc (): int' of TTime that doesn't have an effect (presumably all of them) |
| 14:34:19 | * | fowl joined #nimrod |
| 14:34:22 | reactormonk | :-/ |
| 14:34:40 | reactormonk | can't I just make time immutable? |
| 14:34:47 | Araq | lol |
| 14:35:05 | Araq | immutability has nothing to do with it |
| 14:35:33 | Araq | you either have an IO effect that affects 'Time'/Timing or you don't |
| 14:35:43 | Araq | and the compiler assumes the worse :P |
| 14:36:00 | Araq | so yeah, you really need to press CTRL+V a few times I'm afraid |
| 14:36:16 | Araq | dunno if the setters are effect free |
| 14:36:28 | Araq | I guess they are |
| 14:36:54 | reactormonk | you mean 'p' |
| 14:37:31 | reactormonk | I'll let you take a look afterwards |
| 14:38:13 | reactormonk | what's the 'FTime' tag for? |
| 14:38:24 | Araq | that's the "Time effect" |
| 14:38:39 | Araq | Nimrod's effect system is superior to Haskell's :P |
| 14:39:19 | Araq | yay ... the test suite now contains 600 tests |
| 14:39:24 | reactormonk | what does that mean, a time effect? |
| 14:39:40 | Araq | it means you're reading the computer's clock |
| 14:40:40 | Araq | in Nimrod that's an IO effect and yet it's pretty different from reading a file and so Nimrod distinguishes them |
| 14:41:01 | reactormonk | getTime: proc (): int {.tags: [FTime].} |
| 14:41:10 | reactormonk | getTime doesn't need to be on the TTime type, does it? |
| 14:41:41 | Araq | but getTime doesn't read the computer's clock, so {.tags: [].} would be what you want here |
| 14:41:48 | reactormonk | wait, overload |
| 14:41:50 | Araq | or ... does it? |
| 14:42:06 | Araq | not sure what JS's getTime does |
| 14:42:53 | Araq | and no, TTime has nothing to do with it |
| 14:43:36 | reactormonk | do we have a 'no implemented error'? |
| 14:43:44 | reactormonk | as ??? in scala or ... perl |
| 14:43:52 | Araq | we have: |
| 14:43:59 | Araq | proc p() {.error.} |
| 14:44:14 | Araq | and then the compiler will error if p is attempted to be called |
| 14:44:47 | Araq | however, you may as well not export a missing proc in the first place |
| 14:45:06 | Araq | if you do need to do it at runtime, I'd do: |
| 14:45:14 | Araq | doAssert false, "not implemented" |
| 14:45:35 | reactormonk | lib/pure/times.nim(153, 20) Error: implementation of 'times.fromMiliseconds(msSince1970: int64): TTime' expected |
| 14:45:42 | reactormonk | I implemented it in two when clauses |
| 14:47:06 | Araq | my times.nim has no such proc |
| 14:48:01 | reactormonk | sure, I added it |
| 14:48:16 | reactormonk | http://sprunge.us/McfE |
| 14:50:35 | Araq | hm don't do it that way |
| 14:50:57 | reactormonk | but? |
| 14:52:50 | Araq | the problem is if you forward declare fromMiliseconds the implementation mustn't have a pragma list |
| 14:53:52 | Araq | and I think dom96 used 'float' for a reason, ask him when he's around |
| 14:54:33 | Araq | also I don't like TTimeInterval and would remove it instead of adding ever more operations supporting it |
| 14:55:20 | reactormonk | Araq, how else to represent a time interval? |
| 14:55:51 | Araq | with TTime? |
| 14:56:10 | Araq | int - int is an int |
| 14:56:23 | Araq | and yet TTime - TTime should be TTimeInterval? wtf? |
| 14:56:35 | reactormonk | sure, time is not as simple |
| 14:59:36 | reactormonk | dom96, ping |
| 15:04:05 | * | fowl quit (Ping timeout: 248 seconds) |
| 15:13:30 | reactormonk | Araq, I'm in favour of timeinterval. It's something different than time. |
| 15:13:44 | reactormonk | also because you can't have TTime + TTime |
| 15:14:09 | reactormonk | ... it's defined as TTime + TTimeInterval. TTime - TTime is defined as between(TTime, TTime) |
| 15:14:21 | reactormonk | so you analogy doesn't work as well. |
| 15:15:40 | Araq | of course it does work well |
| 15:15:58 | Araq | TTime is miliseconds since 1970 or something |
| 15:16:19 | Araq | so it's just a number and you should be able to do what you want with it |
| 15:16:56 | Araq | TTime is already a TTimeInterval if you look at it this way |
| 15:17:20 | Araq | points and vectors are very often treated the same in maths |
| 15:17:27 | Araq | and for good reasons |
| 15:18:07 | reactormonk | Yes, but a time and an interval should be treated differently. Even if it's just a distinct type. |
| 15:18:20 | Araq | not in my opinion |
| 15:18:20 | reactormonk | because you never want to use a time as an interval and the other way round. |
| 15:19:26 | Araq | yeah right ... I suppose you never need a random timestamp for testing purposes either :P |
| 15:19:59 | Araq | (generating a random number may involve any kind of arithmetic) |
| 15:32:32 | * | fowl joined #nimrod |
| 15:37:19 | Araq | reactormonk: I'd prefer TTIme.addHours(x) instead of TTime + TTimeInterval(Hours: x) |
| 16:05:08 | * | fowl quit (Ping timeout: 245 seconds) |
| 16:09:12 | * | fowl joined #nimrod |
| 16:16:48 | * | fowl quit (Ping timeout: 245 seconds) |
| 16:20:40 | * | fowl joined #nimrod |
| 16:43:03 | * | fowl quit (Ping timeout: 245 seconds) |
| 16:48:17 | * | fowl joined #nimrod |
| 16:50:17 | dom96 | reactormonk: pong |
| 17:12:20 | * | fowl quit (Quit: Leaving) |
| 17:13:20 | reactormonk | dom96, got the backlog? |
| 17:13:42 | reactormonk | Araq, and random numbers do not count, you can always convert a number to a time or an interval |
| 17:19:38 | dom96 | Could use some more context, where is this float usage of mine which confuses you? |
| 17:20:28 | reactormonk | dom96, that you add floats to time to add time intervals |
| 17:20:42 | reactormonk | I converted them to int64 and made some converters |
| 17:22:20 | dom96 | Araq: I think having a separate type for a time interval is nice, because we can have a nice `$` for it. |
| 17:22:45 | dom96 | Araq: Also, I don't remember you objecting to my implementation when I made it. |
| 17:24:20 | Araq | dom96: so what? I missed it before |
| 17:24:37 | dom96 | reactormonk: I never got around to creating a general proc to convert a TTime into float seconds. |
| 17:24:49 | reactormonk | dom96, I prefer int64. |
| 17:25:23 | Araq | JS doesn't even have an int64 ... |
| 17:25:24 | dom96 | Changing it now would be unwise IMO |
| 17:25:44 | dom96 | and how do you plan to represent miliseconds? |
| 17:26:14 | reactormonk | dom96, int64 for miliseconds |
| 17:26:31 | Araq | float has the tremendous advantage that it doesn't restrict a timer's resolution |
| 17:26:41 | dom96 | indeed, what Araq said. |
| 17:26:55 | dom96 | And a lot of code already depends on the fact that epochTime returns a float. |
| 17:27:04 | Araq | yep |
| 17:27:07 | dom96 | and that the float is in seconds. |
| 17:27:11 | Araq | and JS doesn't even have int64 |
| 17:27:47 | reactormonk | dom96, good, enough, so time and intervals should convert from/to float. |
| 17:28:23 | dom96 | yes. |
| 17:28:32 | reactormonk | Araq, is there any reason why you would want to use an interval as time and the other way? |
| 17:29:48 | Araq | what's the date between A and B? |
| 17:30:37 | reactormonk | that would be between(A, B)/2 + A |
| 17:31:05 | reactormonk | note that between(A, B) returns an interval |
| 17:32:46 | Araq | hrm |
| 17:33:50 | Araq | make TTimeInterval = distinct float then |
| 17:33:58 | dom96 | reactormonk: You should implement a function which will return stuff like "5 days, 4 hours, 52 minutes and 2 seconds ago" |
| 17:34:09 | dom96 | That would be great for the forum. |
| 17:34:27 | reactormonk | Araq, what does distinct float give me over converters? |
| 17:34:43 | reactormonk | dom96, is an interval a duration? |
| 17:35:19 | reactormonk | Time Point -- Specifier for a location in the time continuum. |
| 17:35:22 | reactormonk | Time Duration -- A length of time unattached to any point on the time continuum. |
| 17:35:24 | reactormonk | Time Interval -- A duration of time attached to a specific point in the time continuum. Also known as a time period. |
| 17:36:19 | Araq | we want the time duration then, right? |
| 17:36:39 | Araq | time interval would be a tuple (TTime, TTimeDuration) |
| 17:36:41 | reactormonk | Yes. |
| 17:36:46 | reactormonk | Yep. |
| 17:36:54 | reactormonk | That's from the boost lib |
| 17:37:15 | reactormonk | Araq, what does distinct float give me over converters? <- |
| 17:37:39 | Araq | a single float surely is more efficient to handle than an object full of ints |
| 17:37:56 | reactormonk | nope, ram vs. speed |
| 17:38:15 | reactormonk | do we have time tests? |
| 17:38:23 | Araq | and the current TTimeInterval is wrong anyway as it doesn't support submilisecond resolution |
| 17:38:32 | reactormonk | ... so what. |
| 17:38:44 | Araq | so it's slower and wrong |
| 17:39:15 | reactormonk | can I mark a certain proc as wrong for converter resolution, but it should keep searching? |
| 17:39:25 | Araq | there is no point in benchmarking stuff that I know anyway :P |
| 17:40:03 | Araq | there are no converters here, reactormonk |
| 17:40:13 | Araq | that would defeat the purpose |
| 17:40:28 | Araq | you argue for more type safety |
| 17:40:31 | * | Boscop joined #nimrod |
| 17:40:34 | reactormonk | why not converters from float to ttime? |
| 17:40:42 | Araq | type converters weaken the type safety |
| 17:40:43 | reactormonk | you know a date is _not_ a float in javascript? |
| 17:41:05 | reactormonk | or do you want me to create a new date object each time I call something on it |
| 17:41:06 | Araq | yes, it's some crappy object in JS |
| 17:41:45 | reactormonk | I do have paths to convert to float in JS, but it's not represented as float. That's why I'm in favour of converters. |
| 17:42:14 | Araq | you're always in favour of converters ;-) |
| 17:42:27 | reactormonk | they provide a good solution here. |
| 17:42:31 | Araq | they don't |
| 17:42:40 | reactormonk | you cannot do float(ttime) in JS. |
| 17:42:50 | Araq | see? |
| 17:43:09 | reactormonk | you can do ttime.getUTC to get a float |
| 17:43:16 | Araq | fromFloat(x: float): TTime # name debatable of course |
| 17:43:31 | reactormonk | sure. But no distinct float in JS. |
| 17:43:45 | Araq | why not? |
| 17:44:42 | Araq | you can easily do: getDays * 24 * 60 * 60 + getHours * 60 * 60 + ... + getMilis * 0.1 |
| 17:44:52 | Araq | well ... you get the idea |
| 17:45:45 | reactormonk | doesn't distinct float indicate it's a float? |
| 17:46:21 | Araq | yes |
| 17:46:37 | Araq | it's a float and you have to do some gymnastics to make it a float for JS, so what |
| 17:46:38 | reactormonk | it isn't a float in JS. |
| 17:46:55 | Araq | it's your job to make it a float, even for JS :P |
| 17:47:17 | reactormonk | so call new Date(float).getFullYear for every getter? |
| 17:47:17 | Araq | or maybe we simply shouldn't support for JS |
| 17:47:28 | Araq | huh? |
| 17:48:05 | dom96 | If you're going to change TTimeInterval into a distinct float then please provide a proc which will convert the TTimeInterval into a tuple with such fields. |
| 17:48:21 | reactormonk | Araq, currently, Time is not a distinct float |
| 17:48:24 | dom96 | If you know what I mean. |
| 17:48:41 | Araq | argh .... don't tell me you have code that relies on TTimeInterval |
| 17:48:58 | Araq | also fuck |
| 17:48:58 | dom96 | dunno |
| 17:49:03 | Araq | it's in 0.9.0 ... |
| 17:49:07 | Araq | and exported |
| 17:49:10 | dom96 | but yeah |
| 17:49:29 | Araq | ugh ... well ugh |
| 17:49:41 | Araq | we leave it as it is then |
| 17:49:51 | Araq | I don't feel like deprecating it |
| 17:51:08 | Araq | reactormonk: TTime wraps posix's time_t |
| 17:51:23 | Araq | for the C target and that is not to be changed |
| 17:53:19 | reactormonk | Araq, hell I'm going to change that |
| 17:56:44 | reactormonk | Araq, my idea is to add a few converters (maybe marked a procs) to make JS behave the same as C |
| 17:56:56 | reactormonk | but no direct float() conversions anymore |
| 17:57:49 | reactormonk | if you are against it, let's discuss that in a mumble in about half an hour. |
| 17:58:56 | Araq | I don't know |
| 17:59:15 | Araq | don't change it, just make it compile under JS in some way or the other :P |
| 17:59:38 | * | filwit joined #nimrod |
| 17:59:51 | filwit | hiya folks |
| 17:59:52 | dom96 | hey filwit |
| 17:59:56 | dom96 | long time no speak |
| 17:59:57 | Araq | hi filwit |
| 18:00:02 | filwit | yes, yes |
| 18:00:12 | dom96 | I was about to annoy you on steam again ;) |
| 18:00:22 | filwit | :) |
| 18:00:34 | filwit | you still have to play CSS with me sometime |
| 18:00:39 | filwit | if you can get it to work |
| 18:01:07 | filwit | anyways, just droping by to say hi |
| 18:01:27 | dom96 | sure. I'm sure it will work on Windows. |
| 18:01:30 | filwit | dom96, do you have a AMD CPU or GPU? |
| 18:01:50 | filwit | actually, it's probably my Mobo... |
| 18:02:08 | filwit | you know anything about Linux's sound volume control being messed up? |
| 18:02:36 | dom96 | filwit: I have both from AMD |
| 18:03:19 | dom96 | Sound on linux can be a bit iffy. |
| 18:03:21 | filwit | does your volume control in Cinnamon mess up? |
| 18:03:54 | filwit | like, slider: 50% = 100% volue, 25% = 0% volume |
| 18:04:02 | dom96 | Seems to be working fine. |
| 18:04:33 | filwit | okay... hmm.. my mother board must just have shit drivers |
| 18:07:39 | dom96 | filwit: so how have you been? |
| 18:07:53 | filwit | good |
| 18:07:59 | filwit | just busy |
| 18:08:09 | * | xcombelle joined #nimrod |
| 18:08:20 | filwit | new place is nice though |
| 18:09:11 | filwit | Araq, or dom96. Have you ever worked or seen Backbone.js? |
| 18:09:17 | filwit | worked with** |
| 18:10:08 | dom96 | nope |
| 18:10:13 | dom96 | why? |
| 18:10:39 | filwit | ah, well i was thinking about Nimrod for the web |
| 18:11:18 | Araq | filwit: just skimmed its docs, too buzzwordy for my taste |
| 18:11:27 | filwit | had some different ideas about how you could make a web framework built with some cool things that Nimrod can do |
| 18:12:05 | filwit | Araq: well compared to regular Javascript, it's a pretty nice library that does a lot of cool things for you |
| 18:12:54 | filwit | anyways... in Nimrod, '{}' is a seq? |
| 18:13:01 | filwit | guess i should look up in the docs |
| 18:13:01 | Araq | really? does it give you a static type system? :P |
| 18:13:11 | Araq | '@[]' is a seq |
| 18:14:37 | filwit | does Nimrod have anonymous objects? |
| 18:14:56 | Araq | yeah, they are called 'tuples' ;-) |
| 18:15:17 | filwit | tuples can have var names? |
| 18:15:23 | filwit | key/value? |
| 18:15:24 | Araq | yes |
| 18:15:32 | filwit | ah, interesting |
| 18:15:48 | filwit | so Tuples in Nimrod are a bit more than D's tuples... |
| 18:16:06 | filwit | ah right, i remember |
| 18:16:08 | Araq | there is also {key: value, ...} syntax as sugar for: [(key, value), ...] |
| 18:16:19 | Araq | where (key, value) is a tuple constructor |
| 18:16:23 | filwit | you said to do things like Vector structs with Tuples before |
| 18:16:25 | dom96 | everything in Nimrod is a lot more than in D :P |
| 18:17:03 | filwit | okay, that's pretty nifty actually |
| 18:17:08 | filwit | about the syntax sugar |
| 18:17:26 | filwit | you just write the '{}' as a macro or something? |
| 18:17:43 | filwit | (in the stdlib sort of thing) |
| 18:17:51 | Araq | it's superb because it keeps the order so you can initialize an ordered table with it ;-) |
| 18:18:35 | filwit | yeah... that's nice |
| 18:19:07 | filwit | you and your inventions |
| 18:21:00 | filwit | anyways, I'm trying to find the tuples docs... |
| 18:21:09 | filwit | on Docs page 2? |
| 18:22:11 | filwit | that Backbone.js got me thinking about how you could make a pretty cool OOP system in Nimrod |
| 18:22:19 | filwit | :D |
| 18:22:32 | dom96 | http://build.nimrod-code.org/docs/manual.html#tuples-and-object-types |
| 18:23:25 | filwit | thanks dom96 |
| 18:23:31 | dom96 | np |
| 18:23:32 | Araq | finally figured out OO and a tuple of closures are isomorphic? :P ;-) |
| 18:24:24 | filwit | not really |
| 18:24:34 | filwit | there's defined structure to OO |
| 18:25:00 | filwit | tuple closures don't have any built-in parent-child relationships and vtables beyond what you make |
| 18:25:04 | filwit | like C |
| 18:25:15 | filwit | but it did get me thinking |
| 18:25:42 | filwit | cause if it's that generic, it's just up to some third-party framework to define the structure |
| 18:26:56 | filwit | and Nimrod is kinda built where you can build your own framework type of thing really well... almost everything is definable (almost) |
| 18:27:42 | filwit | i was thinking you could do something like: type Foo = Model.extend({ x:int, y:int }) |
| 18:28:20 | filwit | which is a macro, that would build out objects for you |
| 18:29:24 | Araq | sounds quite possilbe and easy, yeah |
| 18:29:47 | filwit | so macros would be the best way to accomplish that right? |
| 18:29:58 | filwit | and can i actually do: type Foo = ... ? |
| 18:30:10 | filwit | where '...' is a macro that defines a type? |
| 18:30:27 | Araq | there is code for exactly this syntax |
| 18:30:38 | Araq | I'm not sure it has ever been tested :P |
| 18:30:47 | filwit | really? where? |
| 18:31:19 | Araq | just try it out please |
| 18:31:44 | Araq | bbl |
| 18:31:49 | filwit | okay, thought you meant there was some code example out there |
| 18:31:50 | filwit | k |
| 18:34:43 | filwit | bbl as well |
| 18:34:45 | * | filwit quit (Quit: Leaving) |
| 19:00:27 | * | xcombelle quit (Read error: Connection reset by peer) |
| 19:02:52 | reactormonk | Araq, kk |
| 20:06:29 | * | ack006 quit (Quit: Leaving) |
| 22:42:46 | * | fowl joined #nimrod |
| 23:09:38 | NimBot | Araq/Nimrod 1c7d1aa Araq [+1 ±3 -0]: fixes #310 |
| 23:25:12 | NimBot | Araq/Nimrod 1ba3569 Araq [+0 ±1 -0]: implements #258; activate via --verbosity:2 |
| 23:46:28 | NimBot | Araq/Nimrod bb1a0ba Araq [+0 ±1 -0]: fixes #244 |
| 23:56:07 | * | debugging4ever joined #nimrod |
| 23:57:14 | Araq | hi debugging4ever |
| 23:57:29 | debugging4ever | hi there! |