<<10-04-2013>>

00:57:28reactormonk type TTime* {.final, importc.} = object
00:57:30reactormonk getSeconds: proc (): int
00:57:41reactormonkand t.getSeconds fails with lib/pure/times.nim(448, 22) Error: undeclared field: 'getSeconds'
01:05:08reactormonk... that's because the symbol 'windows' is defined when running JS. WTF?
01:05:49reactormonkoh, wait
01:06:02reactormonkposix is defined.
01:29:36*zahary1 quit (Quit: Leaving.)
01:39:48*Trixar_za is now known as Trix[a]r_za
01:51:58reactormonkwtf.
02:04:07*XAMPP_ quit (Quit: My code has no bug's, just random features)
02:04:38*XAMPP joined #nimrod
02:04:38*XAMPP quit (Changing host)
02:04:38*XAMPP joined #nimrod
02:59:55reactormonkAraq, I think I kind of jumped out of a loop with functional ;-)
03:00:05reactormonkor used a next, that is
03:18:35*zahary is now known as zahary_
03:35:17*fowl quit (Quit: Leaving)
08:28:45*q66 joined #nimrod
08:31:52*XAMPP quit (Quit: My code has no bug's, just random features)
09:01:14*XAMPP joined #nimrod
10:50:10NimBotAraq/Nimrod 7a319d9 Araq [+0 ±1 -0]: bugfix: new(TTable[string, int]) compiles
11:23:41*Boscop joined #nimrod
13:06:29*Trix[a]r_za is now known as Trixar_za
14:35:45dom96hello
14:36:09Araqhi dom96
14:36:22dom96sup?
14:38:49reactormonkAraq, any way to find out where a compilation symbol is defined?
14:39:22Araqreactormonk: use 'nimrod dump' to see what's defined
14:39:38Araqin general only --define/d defines a symbol
14:39:48Araqapart from the builtin defines, of course
14:40:11reactormonkAraq, posix seems to defined when compiling to JS
14:40:24reactormonk... that's why times.nim breaks in JS
14:40:47Araqthat's likely a compiler bug
15:32:03*Trixar_za is now known as Trix[a]r_za
17:32:07Araqreactormonk: but the workaround it easy: when defined(posix) and not defined(js) ...
17:41:33*zahary joined #nimrod
18:00:11reactormonkAraq, ok
18:10:52reactormonklib/pure/times.nim(242, 35) Error: conversion from TTime to float is invalid
18:10:53reactormonklet's see
18:11:23reactormonkI think you make some assumptions based on C
18:12:45Araq'you' is likely dom96 here ... :P
18:13:56reactormonkyep.
18:14:04*dom96 hides
18:14:46reactormonkdom96, get it working.
18:15:05reactormonkhttp://sprunge.us/QWPh
18:15:26reactormonkAraq, I think we should split the times stuff into js and c
18:16:10Araqmeh, that means 2 more include files ...
18:16:20reactormonkso what?
18:17:51*Araq dislikes a proliferation of files
18:18:13reactormonkwhy?
18:20:33Araqbecause inevitably it means to have more files open at once in the editor and more switching between them
18:20:57reactormonkothweise you have damn long files and you need to open two views
18:21:01Araqand times.nim is pretty small anyway
18:21:22reactormonkbut it's got a shitload of defined in there, you always need to be aware where you are
18:26:11Araqcome on, I just skimmed it again, it's still perfectly fine
18:27:36dom96There are many much bigger modules in the stdlib.
18:27:40reactormonkoke...
18:29:14reactormonklib/pure/times.nim(481, 21) Error: can have an unlisted effect: TEffect
18:29:15reactormonkhmm
18:30:01reactormonkwhat's the difference between TTime and TTimeInfo?
18:30:29AraqTTime seconds since UNIX's birth or something
18:30:45AraqTTimeInfo = time in days, hours, seconds etc.
18:31:00reactormonkbasically our time
18:32:06reactormonkare you sure we don't want to use an external lib for that part? Because result = getGMTime(TTime(float(t) + secs)) is not always right, fucking corner cases.
18:32:36dom96I think i've already mentioned this: there should be a epochTime overload to convert a TTime into a epoch time float.
18:33:01reactormonkdom96, issue?
18:33:16dom96reactormonk: pull request :P
18:33:30reactormonkdom96, is there an issue about that?
18:33:51dom96Dunno
18:33:58dom96Don't think so
18:34:00reactormonkand why reinvent the wheel about that :-/
18:34:46dom96A times module? Well, I myself dislike dependencies.
18:35:04reactormonkNIH?
18:35:47reactormonkah, broken-down time. should do fine.
18:47:57*zahary quit (Quit: Leaving.)
18:54:23reactormonkany way to define prefix operators?
18:56:31Araqreactormonk: no need to define them explicitly
18:56:37reactormonkAraq, ok
18:56:47Araqproc `?`(x: Int): int = x-3
18:56:54Araq?234 # works
18:57:37reactormonknice
18:57:49reactormonkcan I somehow iterate over the fields of an object?
18:58:05Araquse the 'fields' iterator ;-)
18:58:22reactormonk:-/
18:59:43reactormonkand how do I access the fields? obj[field] ?
19:00:23Araqfor f in obj.fields: # 'f' is the obj.field
19:01:01reactormonkoh, I need the name of the field, or a lens, if you wanna call it that
19:01:17reactormonkhttp://sprunge.us/gUaO
19:01:22Araqfor name, field in fieldPairs(obj):
19:01:52Araqyou can also use it to iterate over 2 objects at once iirc:
19:02:07Araqfor a, b in fields(result, interval)
19:02:21Araq a = -b
19:05:32reactormonkfancy
19:41:40reactormonkhttp://sprunge.us/HEfG huh.
19:50:13reactormonkworking on it.
19:55:11dom96you're passing an argument to a function which does not require one?
20:37:50*gradha joined #nimrod
20:58:48reactormonkmaybe
20:59:15reactormonkjust bought 3 BTC for 107$ each because I had a buy lying around O.o
21:03:10*Trix[a]r_za is now known as Trixar_za
21:48:38gradhalet's say I want "nimrod doc2" to specify the documentation for a module is at version x.y.z
21:49:06gradhalet's say this module itself contains a const VERSION = "x.y.z"
21:49:20gradhaany way to make the generated doc contain a version marker with the value of this const?
21:49:36Araqsure, kind of
21:49:41gradhaI guess I could write myself a nimrod proc which imported the module to read its version, the run nimrod doc on it
21:49:56gradhabut maybe nimrod doc already has this functionality
21:50:11Araqnimrod doc *almost* has it ;-) let me look it up
21:50:33gradhalooking at sources like lib.txt I see ":Version: |nimrodversion|" but that requires parameter passing
21:50:51Araqwell that's how to do it
21:50:57Araq:Version: |myversion|
21:51:15Araqand then pass in the command line: --putenv:myversion=0.9.2
21:51:19gradhaok, so 1) extract string from module 2) run nimrod doc with extracted string
21:51:26Araqyeah
21:51:28*fowl joined #nimrod
21:52:00Araqdoc2 could easily do it your way though I guess
21:52:13Araqbut ugh
21:52:37Araqthat would require some forwarding logic as I bet the comment comes before the version's defintion
21:53:14gradhawhat's replaced when the putenv: is not passed? empty string?
21:53:32Araqit's kept as |myversion| in the output iirc
21:53:46Araqthe compiler warns about it though
21:56:57fowlare there plans to allow macros in typedef pragmas
21:57:43Araqfowl: hrm, I thought that's already supported :-)
21:58:01Araqyou mean type TFoo = object {.mymacro.} right?
21:59:05fowlyea
21:59:56fowli get invalid pragma
22:03:49Araqok, adding to my todo
22:18:20gradhais it possible to define a proc which accepts an adhoc input tuple? I mean, without declaring the type previously
22:18:46gradhaI'm trying proc test(something: (xmajor: int, xminor: int, xmaintenance: int)) = echo repr(something)
22:18:47Araqsure, tuples are structural types
22:19:02gradhaah, that's the constructor
22:19:21Araqproc test(something: tuple[xmajor, xminor, xmaintainance: int])
22:19:32fowlgradha: tuple[fields]
22:19:53gradhagood, i was forgetting the tuple before the brackets
22:20:46gradhaawww... procs won't accept tuples with different field names
22:21:36Araqif you feel adventurous, you could try:
22:21:57Araqproc test(something: type((1,1,1))
22:22:26Araqthis way 'something' gets an "unnamed" tuple without field names
22:22:40Araqwhich currently can't be accessed directly
22:24:39gradhamaybe it would be nice if the tuples for the procs could "rename" the tuple being passed, in a way it's like the proc using a parameter name different from the caller's variable
22:29:07Araqthis feature has been requested before, I don't like it
22:29:35gradhaI don't like it either
22:29:40Araqtuple[key, val: int] is pretty different from tuple[x, y: int] for me
22:30:10Araqyou can pass either (1, 2) or (x: 1, y: 2) though and I think that's fair enough already
22:30:30*XAMPP quit (Ping timeout: 252 seconds)
22:32:13gradhaa marked proc with * is an exported proc
22:32:25gradhaa marked const/variable with a * is an exported const/variable
22:32:33gradhais it correct to say both are exported symbols?
22:32:42Araqsure
22:34:54fowlwhats the difference in putting the pragma after the type name or after the actual type
22:35:09fowlie type TVector{.final, pure.} = object .. vs type TVector = object{.final, pure.}
22:35:32Araqthere is no difference
22:35:52Araqhowever, it's wrong to put it after the name for 'ref object'
22:36:08Araqas the pragma refers to the object, not to the 'ref object'
22:36:31Araqhowever, it's pretty much an artifact of the implementation
22:37:27fowlah ok
22:40:11dom96Araq: Maybe we should have some syntax to specify unnamed tuples?
22:40:22*XAMPP joined #nimrod
22:56:11*gradha quit (Quit: bbl, have youtube videos to watch)
23:02:21Araqdom96: already on my todo
23:03:18Araqplanned syntax is tuple(int, int)
23:07:41dom96why not just tuple[int, int]?
23:08:34Araqbecause that's ambiguous I think
23:08:49Araqmeh ... maybe it's not
23:16:54Araqgood night
23:17:02dom96same here
23:19:54*q66 quit (Read error: Connection reset by peer)