<< 07-09-2013 >>
00:21:31*fowl quit (Quit: Leaving)
00:28:08*DAddYE quit (Remote host closed the connection)
00:43:40*io2 quit ()
00:49:14*MFlamer quit (Quit: Page closed)
00:51:40*Yeri quit (Quit: Yeri)
00:57:26*fowl joined #nimrod
01:24:55reactormonkremind me of the lambda syntax again
01:28:07fowldo(an: int)->bool: false
01:29:31reactormonkkk
01:30:52fowlthat'll be $2
01:33:30reactormonkbtc address?
01:33:42fowl2 btc?
01:35:55reactormonkhell nah, 0.02
01:38:47fowlill take paypal, btc isnt useful to me
01:47:57*brson quit (Ping timeout: 276 seconds)
01:49:09*brson joined #nimrod
02:00:59*jpoirier joined #nimrod
02:03:31*jpoirier quit (Client Quit)
02:04:41*fowl quit (Quit: Leaving)
02:06:40*ltbarcly quit (Read error: Operation timed out)
02:10:11*q66 quit (Quit: Leaving)
02:25:05*JStoker quit (Ping timeout: 246 seconds)
02:33:01*Yeri joined #nimrod
02:54:06*JStoker joined #nimrod
03:07:53*ltbarcly joined #nimrod
03:12:16*ltbarcly quit (Ping timeout: 240 seconds)
03:13:22*ltbarcly joined #nimrod
03:34:47*MFlamer joined #nimrod
03:39:05*ltbarcly quit (Ping timeout: 268 seconds)
03:59:44*brson quit (Ping timeout: 260 seconds)
04:01:26*brson joined #nimrod
04:12:01*Yeri quit (Quit: Yeri)
04:58:02*d34th_ joined #nimrod
04:59:50*d34th quit (Ping timeout: 240 seconds)
04:59:50*reactormonk quit (Ping timeout: 240 seconds)
04:59:51*d34th_ is now known as d34th
05:00:11*logosd quit (Remote host closed the connection)
05:01:48*brson quit (Quit: leaving)
06:53:59*reactormonk joined #nimrod
07:46:39*Associ8or quit (Quit: Associ8or)
07:49:36*io2 joined #nimrod
08:34:21MFlamerHi, is anyone on?
08:55:58NimBotAraq/Nimrod master 33f1146 Zahary Karadjov [+0 ±3 -0]: fix regressions affecting the echo magic and the creating of rod files... 3 more lines
09:38:58*q66 joined #nimrod
10:44:09dom96hello
10:44:12*BitPuffin quit (Ping timeout: 276 seconds)
11:14:42*ltbarcly joined #nimrod
11:19:11*ltbarcly quit (Ping timeout: 260 seconds)
12:13:39dom96Hrm, c2nim translates that union strangely. Maybe it is correct, but the fields are simply omitted so it feels like a bug: https://gist.github.com/dom96/35cd1b5942ccf9db5ec0
12:53:45*EXetoC joined #nimrod
13:23:24*Hannibal_Smith joined #nimrod
14:13:24EXetoCAraq: tell us about this "top secret" company
14:28:56*Associat0r joined #nimrod
14:28:56*Associat0r quit (Changing host)
14:28:56*Associat0r joined #nimrod
15:07:59dom96opencv is fun :D
15:32:32MFlamerGood morning. Is it possible to get the address of an element of a seq using seq[].addr ?
15:33:23dom96yes, but it's not a good idea to do that AFAIK
15:35:48EXetoCwhy not, if the answer is yes?
15:36:09dom96what if the sequence is sorted?
15:36:32*ltbarcly joined #nimrod
15:37:10MFlamer proc test(table: openarray[int]) = echo table[0].addr this dosent work for me
15:37:30EXetoCit needs to be a var
15:38:28EXetoCno wait
15:39:06EXetoCnot in the case of openarray I guess, but what's the error?
15:41:07*ltbarcly quit (Ping timeout: 260 seconds)
15:41:17MFlamerError: expression has no address
15:41:40EXetoCok I might be confused as always. I was just looking at a generic function that is apparently never instantiated, so see what happens if you make it a 'var'
15:42:25EXetoCthe address cannot be taken otherwise
15:43:14MFlamerworks if its a var. Thanks.
15:43:41MFlamerare all arguments passed by value if not a var?
15:43:54MFlameri.e. copied?
15:45:30EXetoCthe compiler might pass an arg by reference either way, depending on what's more efficient
15:46:50*ltbarcly joined #nimrod
15:49:03MFlamergot it
15:49:20EXetoCso users don't really need to care about that in general
15:49:54EXetoCunless, of course, the purpose of 'var' is modification
15:51:48*ltbarcly quit (Ping timeout: 256 seconds)
16:22:00MFlamerproc compareAndSwap*[T: ptr|ref|pointer](mem: var T, expected: T, newValue: T): bool is this proc looking for 3 ptr(or ref) or 1 ptr(or ref) and 2 values?
16:23:05MFlamerseems like the latter, but having trouble getting it to type check
16:29:20EXetoCit takes 3 T, where each argument must have the same type
16:30:45EXetoCdo you want something like this: "proc compareAndSwap(mem: var ptr|ref|pointer, expected, newValue: ptr|ref|pointer): bool"?
16:31:10EXetoCyou might be able to simplify a little by the use of 'distinct', but I don't know if those changes are in yet
16:32:30MFlamerthe proc is in the atomics module, seems like it should take a ptr and 2 values
16:36:10MFlamerif I were going to define it I would think it would look like "proc compareAndSwap[T](mem: ptr|ref|pointer, expected, newValue: T): bool"
16:36:30EXetoCok, but for now, all three arguments must be instantiated by the same variant specified by T
16:37:30MFlamerand the typeclass restriction is saaying they should all be refs or ptrs?
16:40:05EXetoCit doesn't have anything to do with the actual type class, but rather the fact that there's one type argument, which means that the compiler must be able to deduce a single type
16:40:50EXetoCit's the same with just [T], just that no constraints are present
16:44:20MFlamerI get that but, in this case [T: ptr|ref|pointer] is restricting all T's to ptr, ref or pointer. Correct?
16:47:45EXetoCyes, as in compareAndSwap(ptr, ptr, ref) won't work
16:51:45EXetoCor compareAndSwap(int, int, int), to answer your last question :>
16:53:30MFlamerthanks. It just doesnt seem right, the C function its calling wants (ptr, val, val) not (ptr, ptr, ptr). I wonder if this proc is used anywhere else yet.....
16:56:10EXetoCat least InterlockedCompareExchangePointer seems to take three pointers
16:57:50EXetoCand the first argument points to a pointer (so a pointer to a pointer), so it looks correct to me
16:58:50EXetoCbut then there's this "bool __sync_bool_compare_and_swap (type *ptr, type oldval type newval, ...)"
17:02:26MFlameryeah, thats what I was looking at
17:05:41EXetoCmakes sense. wanna patch it? I might otherwise, a little later
17:13:41MFlamerI'll see what I can do.
17:21:01Hannibal_SmithIs it possible to change object variant at runtime?
17:21:01Hannibal_SmithLike
17:21:01Hannibal_Smith root.kind = ElementKind.inner
17:21:01Hannibal_Smith root.left = newElement(key, data)
17:21:01Hannibal_Smith root.key = key
17:33:21MFlamerIn the example the kind field is called the discriminator: For safety its address cannot be taken and assignments to it are restricted: The new value must not lead to a change of the active object branch. For an object branch switch system.reset has to be used.
17:33:41MFlamerthats a quote from the manual, never tried it though
17:34:31Hannibal_SmithThe compiler don't complains...but the code at the moment is incomplete so I can't test it
17:35:01Hannibal_SmithThank you MFlamer
17:35:46Hannibal_SmithProbably the correct way is to override the object with a new one
17:35:56Hannibal_SmithUhm...
17:36:06Hannibal_SmithI don't know if is viable
17:37:11EXetoCwhat do you mean?
17:37:46Hannibal_Smithhttp://ideone.com/L7NH9M
17:37:46Hannibal_SmithIs the current type
17:38:11Hannibal_SmithIf I override a TElement
17:38:31Hannibal_SmithThe reference that others TElement keeps
17:38:41Hannibal_SmithAre of the new TElement?
17:40:01Hannibal_SmithUhm...probably I must thinking something strange
17:40:31Hannibal_SmithSetting directly the new TElement keeping track of the parent
17:40:41Hannibal_SmithShould do the task
17:40:51Hannibal_SmithLike parent.left = newElement(...)
17:48:46EXetoCif it does in fact work, then you still can't assign to the kind field according to what he quoted
17:50:06MFlamerif I'm on windows, is the default C compiler still gcc?
17:50:31MFlamerlike defined(gcc) == true
17:51:01EXetoCHannibal_Smith: and I think an exception was thrown once when I assigned to the wrong field, but I'm not sure
17:51:11EXetoCtry and see if the above works
17:53:11EXetoCMFlamer: I think so, and the windows installers come with GCC
17:54:41Hannibal_SmithEXetoC, you where right
17:54:51Hannibal_SmithIt's checked at runtime
17:54:51Hannibal_SmithHint: operation successful (7596 lines compiled; 0.883 sec total; 13.133MB) [SuccessX]
17:54:51Hannibal_Smith> Process terminated with exit code 0
17:54:51Hannibal_Smith> /tmp/aporia/a1
17:54:51Hannibal_SmithTraceback (most recent call last)
17:54:51Hannibal_Smitha1.nim(11) a1
17:54:51Hannibal_SmithError: unhandled exception: key is not accessible [EInvalidField]
17:54:51Hannibal_Smith> Process terminated with exit code 256
17:54:51MFlamerok, I guess the atomics calls would still be into OS code using windows.h, even if compiled with gcc?
17:57:21Hannibal_Smith(I used this code:
17:57:21Hannibal_Smithvar element = TElement[uint, uint](kind: ElementKind.leaf, key:1, data:1, left: nil, right: nil)
17:57:21Hannibal_Smithecho element.kind
17:57:21Hannibal_SmithI think is valid)
18:00:11Hannibal_SmithThis is a problem...
18:00:11Hannibal_Smith while tmp_element.kind == inner:
18:00:11Hannibal_Smith if tmp_element.key < key:
18:00:11Hannibal_Smith tmp_element = tmp_element.left
18:00:11Hannibal_Smith else:
18:00:11Hannibal_Smith tmp_element = tmp_element.right
18:00:11EXetoCdoes it work? I think only data should be assigned to in this case
18:00:11Hannibal_SmithSo this code is invalid
18:00:21MFlamerI'm getting "operation successful (7830 lines compiled; 0.110 sec total; 13.133MB) [SuccessX]" but no .exe is actually created.
18:02:51EXetoCHannibal_Smith: right
18:03:11*logosd joined #nimrod
18:03:31AraqMFlamer: the .exe is produced in the project's directory I think
18:03:46Araqor in the current directory I dunno lol
18:03:56Hannibal_Smithproc is_inner[TKey, TData](e: TElement[Tkey, TData]): bool =
18:03:56Hannibal_Smith case e.kind
18:03:56Hannibal_Smith of inner: true
18:03:56Hannibal_Smith else: false
18:03:56Hannibal_SmithI think this should be ok
18:04:26AraqHannibal_Smith: it's pointless cargo cult code
18:04:51Hannibal_SmithUhm?
18:04:51AraqI'd use e.kind directly
18:05:26Hannibal_SmithSorry, I'm lost
18:05:26Hannibal_Smithwhile tmp_element.kind == inner: <-Is this code invalid?
18:05:46AraqI don't think so. why would it?
18:06:11Hannibal_Smithvar element = TElement[uint, uint](kind: ElementKind.leaf, key:1, data:1, left: nil, right: nil)
18:06:11Hannibal_Smithecho element.kind
18:06:26Hannibal_SmithI tried this before
18:06:26Hannibal_SmithAnd got an exception
18:06:36EXetoConly one of the fields are valid for that particular kind
18:07:06EXetoCAraq: that line alone looks fine. can't you query it?
18:07:16Hannibal_SmithHint: operation successful (7596 lines compiled; 0.883 sec total; 13.133MB) [SuccessX]
18:07:16Hannibal_Smith> Process terminated with exit code 0
18:07:16Hannibal_Smith> /tmp/aporia/a1
18:07:16Hannibal_SmithTraceback (most recent call last)
18:07:16Hannibal_Smitha1.nim(11) a1
18:07:16Hannibal_SmithError: unhandled exception: key is not accessible [EInvalidField]
18:07:16Hannibal_Smith> Process terminated with exit code 256
18:07:26EXetoConly data is
18:07:41MFlameryes, but in this case it wasn't getting produced. It's building now. But still having trouble with the atomics module. Was this c2nim code?
18:08:11Araqit's not c2nim code but indeed I never tested it
18:08:31EXetoCyou're instantiating it with 'leaf' as the kind. also, there's probably a memory overlap, so chances are that you'd assign something twice as a result, had it worked
18:09:01*o2wtf2o joined #nimrod
18:09:11Araqhi o2wtf2o , welcome
18:09:21MFlamerok, I'm gonna see if I can get it working
18:09:31Araqexcellent, thank you
18:09:31EXetoCbut it shouldn't work, since it's a tagged union, rather than a regular union (like in C), where there's no type safety
18:10:01AraqHannibal_Smith: the error message is perfectly clear :P
18:10:01Hannibal_SmithAhhh
18:10:01MFlamerI've got a little start on a LockFreeHashTable
18:10:11Hannibal_SmithSorry, yes
18:10:21EXetoC*type distinction
18:15:01MFlamer"Error: execution of an external program failed; rerun with --parallelBuild:1 to see the error message" and then I do, and gives no error, just acts like it's successful and produces no .exe. Guess I should file a bug for that
18:15:11Hannibal_SmithAraq, for now the only difference from the C++ is a 1 more work per element...but the code is way better in the Nimrod version
18:15:21Hannibal_Smith*1 more word
18:18:52AraqMFlamer: please run the GCC commands yourself then and see what that produces
18:19:12Araqthe command should be at the top of the generated C files
18:21:22Hannibal_SmithUhm...maybe is something more than a word...I think that filed access is checked every time using variant type
18:21:52Hannibal_SmithOr compiler can do something about this?
18:22:52Araq0.9.3 can in theory optimize of these away but doesn't do that yet. Plus it's disabled in release builds anyway.
18:23:02Araq*optimize most of these
18:23:02Hannibal_SmithOk
18:24:32Hannibal_SmithA question, Nimrod support this? a = if a: ,,,
18:24:32Hannibal_Smith?
18:24:52Araqyes 'if' can be used as an expression
18:25:02Hannibal_SmithGreat
18:26:27Hannibal_SmithAre there some example about the indentation?
18:26:37Hannibal_SmithI think that I missed it in the tutorial
18:26:52Araqthe tutorial is a bit outdated :P
18:27:12Araqthe manual is usually much better kept up to date
18:28:02MFlamerOK, I see the nimrod compiler generates and keeps the C file. Good tip!
18:28:02Hannibal_Smithhttp://nimrod-code.org/manual.html#if-statement
18:28:12Hannibal_SmithThere aren't any example of using if as an expression
18:28:32Araqhttp://nimrod-code.org/manual.html#if-expression
18:28:52Hannibal_SmithOk
18:29:12Hannibal_SmithI think it cannot be expanded on multiple lines, right?
18:29:32Araqvar x = if a:
18:29:32Araq 12
18:29:42Araq else:
18:29:42Hannibal_SmithOk, thank you
18:29:42Araq 13
18:30:12Araqyou need at least 0.9.2 for this to work iirc
18:30:27Hannibal_SmithI'm on the git version of yesterday
18:31:52Hannibal_SmithThe code looks more good now
18:37:52shevyhmm slight off topic questions
18:38:12shevydoes nimrod have something related to pdf (reading, generating) or spreadsheets (reading, parsing, writing) - anything?
18:45:52MFlamerhasThreadSupport should be true as long as I conpile with -t:on, right?
18:46:12MFlamercompile, sorry
18:49:12EXetoClib/system.nim:882: hasThreadSupport = compileOption("threads")
18:50:52MFlamerthanks!
18:53:32*EXetoC quit (Quit: WeeChat 0.4.1)
18:53:47*EXetoC joined #nimrod
18:53:47EXetoChttp://nimrod-code.org/threads.html
18:54:47EXetoCthis mentions --threads:on, and that might do it
18:56:12EXetoCseems like the correct way to do it, if I'm not mistaken
18:58:12MFlameryep, that was it. I was using -t:on for some reason
18:59:02MFlamernow I'm gettin somewhere. Got some of the atomics to work
19:11:07Hannibal_SmithIf I have this code: "var x = y" and y is a ref object, how I can change directly the object, like in C++: *pointer = value?
19:12:27Hannibal_SmithI want to execute later: x = newY(...)
19:15:47EXetoCshould work if the function returns the same type
19:16:47Hannibal_SmithUhm...
19:16:47Hannibal_SmithInteresting approach
19:17:02Hannibal_SmithI used to emulate the classical C approach
19:17:02Hannibal_Smith---
19:17:02Hannibal_Smith tmp_element = if tmp_element.key < key:
19:17:02Hannibal_Smith newElement(key, old_element, new_element)
19:17:02Hannibal_Smith else:
19:17:02Hannibal_Smith newElement(tmp_element.key, new_element, old_element)
19:17:02Hannibal_Smith---
19:17:42Hannibal_SmithBut I was stalled, because I don't know how "emulate" pointers in Nimrod
19:19:27EXetoCI don't know what you mean. Nimrod has pointers
19:21:07*ltbarcly joined #nimrod
19:21:07Hannibal_Smithvar tmp_element: pointer = addr(root)
19:21:17Hannibal_SmithSomething like this?
19:21:42MFlamerAraq: I have a generated C file that I can manually compile with gcc, but when nimrod trys to build an .exe I get Error: execution of an external program failed. Any ideas?
19:22:27EXetoCI don't know what newElement returns, but 'new' implies a reference on some sort, as per convention
19:22:37EXetoCand initFoo is used for value type constructors
19:23:07Hannibal_SmithUhm...yes it's impossible to take the address of something on the GC...
19:24:27Hannibal_Smithhttp://ideone.com/oTHcyT
19:24:27Hannibal_SmithIs the current code
19:24:42Hannibal_Smithadd is the proc in question
19:25:02Hannibal_SmithI allocate tree's node on the GC
19:26:32Hannibal_Smithhttp://ideone.com/0bHVOA <-It's the respective C++ code
19:27:12Hannibal_SmithIn the C++ version I used a pointer for tmp_element
19:27:12AraqMFlamer: that's strange. you are on windows, right?
19:27:27EXetoCyou should already have a reference then
19:27:27MFlameryes
19:28:02Araqmaybe nimrod uses a different gcc for some reason?
19:28:12EXetoCand having a raw pointer instead is of questionable usefulness, but I'm sure you can't make it work somehow
19:28:32EXetoCI would examine the code, but the screen resolution is low atm, and there are too many wrapped lines :>
19:28:47MFlamerI'll check
19:28:47*ltbarcly quit (Ping timeout: 264 seconds)
19:29:52Hannibal_SmithEXetoC, from what I understand, if var x = y
19:29:52Hannibal_SmithIf y is a ref type
19:30:02Hannibal_SmithIf i change x
19:30:12Hannibal_SmithIt don't change y
19:30:22Hannibal_SmithBut change x to operate on another ref object
19:30:32*ltbarcly joined #nimrod
19:31:07Hannibal_SmithAm I wrong?
19:31:32Hannibal_SmithAhhh, sorry for my English
19:31:52AraqHannibal_Smith: I think you mean the right thing
19:32:22Hannibal_SmithSo...I have to use malloc?
19:32:32Araqno? why would you?
19:32:52*MFlamer quit (Quit: Page closed)
19:33:02Hannibal_SmithIs possible to take a pointer of something on the GC?
19:33:02Araqsure
19:33:32Hannibal_SmithIt's great...where I can find more info about this?
19:35:42Araqlib/pure/collections/critbits.nim implements a crit bit tree
19:35:42*ltbarcly quit (Ping timeout: 264 seconds)
19:35:52Hannibal_SmithOk, thank you
19:36:02Araqline 96 following
19:36:22Araqseems to be similar to what you have in mind
19:36:32*EXetoC quit (Quit: WeeChat 0.4.1)
19:36:52*MFlamer joined #nimrod
19:38:22*ltbarcly joined #nimrod
19:43:12*ltbarcly quit (Ping timeout: 264 seconds)
19:45:07*ltbarcly joined #nimrod
19:45:07Hannibal_SmithAraq, yes it's exactly was I was searching to do
19:45:07Hannibal_SmithThank you
19:48:32*OrionPK joined #nimrod
19:49:42*ltbarcly quit (Ping timeout: 245 seconds)
19:50:42*ltbarcly joined #nimrod
19:52:02MFlamerAraq: I verified It's the same gcc
19:53:32Araqperhaps windows holds some lock so that .exe may not be written when you invoke it via nimrod? could be the case if the program is still running
19:54:12Araqor you need admin rights to the directory
19:55:32*ltbarcly quit (Ping timeout: 261 seconds)
19:56:42*ltbarcly joined #nimrod
20:01:22*ltbarcly quit (Ping timeout: 245 seconds)
20:02:12*ltbarcly joined #nimrod
20:02:42MFlamerI did a little test and I think gcc is missing some atomics functions
20:02:42MFlameratomicstest.c: In function 'check': atomicstest.c:12:1: note: '__sync_fetch_and_nand' changed semantics in GCC 4.4 atomicstest.c:18:1: note: '__sync_nand_and_fetch' changed semantics in GCC 4.4 C:\Users\mflamer\AppData\Local\Temp\ccc66YWr.o:atomicstest.c:(.text+0x26): undefined reference to `___sync_fetch_and_or_4' C:\Users\mflamer\AppData\Local\Temp\ccc66YWr.o:atomicstest.c:(.text+0x46): undefined reference to `___sync_fetch_and_nan
20:04:32MFlameror minGW specifically.
20:10:53Araqwell it should be a builtin really, it shouldn't generate a call to ___sync_whatever
20:11:23Araqit should produce some nice assembler code, otherwise what's the point?
20:12:03*ltbarcly quit (Ping timeout: 264 seconds)
20:12:43*ltbarcly joined #nimrod
20:14:53MFlamerapparently this is a known limitation of minGW 32bit. I think it may be fixed for the 64bit version. Any problem using the 64bit minGW with nimrod?
20:15:13Araqnone that I'm aware of
20:15:28Hannibal_SmithWhat is the correct way of doing this?
20:15:28Hannibal_Smithproc newElement[Tkey, TData](key: Tkey, data: TData) : ref TElement[Tkey, TData] =
20:15:28Hannibal_Smith new(TElement(kind: ElementKind.leaf, key: key, data: data))
20:15:53Araqtype PElement ...
20:16:03Araqand then in the proc body
20:16:13AraqPElement(kind: ElementKind.Leaf, key ...)
20:16:33Hannibal_SmithOk, easy
20:17:03MFlamerAraq: are you saying these gcc calls look less performant that we would like http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Atomic-Builtins.html?
20:17:03Hannibal_SmithI my english was so bad, I would be to add some documentation about this...
20:17:13*ltbarcly quit (Ping timeout: 245 seconds)
20:17:13Hannibal_Smith*wasn't
20:17:33AraqHannibal_Smith: write some tutorial in your native language then instead :-)
20:17:53Hannibal_SmithIt's something that I will try to do
20:18:28Hannibal_SmithI have to implementate for school some cool data structures likes skiplist
20:18:38Hannibal_SmithSo it will be interesting comparing C++11 vs Nimrod
20:18:48*ltbarcly joined #nimrod
20:19:23Araqok. fyi I consider skip lists stupid ;-)
20:19:33Hannibal_SmithAhahahah
20:20:13Araqit uses variable length arrays to store lists of pointers for its list structure
20:20:43Araqwhich doesn't make too much sense really
20:21:23Hannibal_SmithSutter adived skiplist as a good data structure in a multi threading enviroment
20:21:23Hannibal_Smith*advised
20:23:23*Araq remembers the proof of the average case for searching in a skip list
20:24:03*Araq has nightmares
20:26:33Hannibal_SmithError: internal error: (filename: compiler/semtypes.nim, line: 832)
20:26:33Hannibal_SmithNo stack traceback available
20:26:33Hannibal_Smith> Process terminated with exit code 256
20:26:53Hannibal_SmithI must did something really bad
20:26:53Araqyup
20:27:03Araqreport a bug please
20:27:13Araqan internal error is a bug
20:27:33Hannibal_SmithGithub?
20:27:43Araqyes
20:28:08AraqMFlamer: no, that's not what I'm saying
20:29:53AraqI thought maybe you need to link to something for the atomics to work, but that doesn't make sense as there should be no dependency to some lib for these
20:30:23MFlamerok, got it
20:30:33*ltbarcly quit (Ping timeout: 263 seconds)
20:31:13*ltbarcly joined #nimrod
20:32:53Hannibal_Smithhttps://github.com/Araq/Nimrod/issues/590
20:33:53Araq PElement = ref TElement # make that
20:34:13Araq PElement[TKey, TData] = ref TElement[TKey, TData]
20:35:33Araqlikewise use PElement[TKey, TData](kind: ElementKind.inner, key: key, left: nil, right: nil) and note how pointless your 'newElement' procs are :P
20:35:53Hannibal_SmithOk
20:42:13*ltbarcly quit (Ping timeout: 245 seconds)
20:43:43*Mat2 joined #nimrod
20:43:43*ltbarcly joined #nimrod
20:43:43Mat2hello
20:43:53Araqservus Mat2
20:44:08*reactormonk quit (Ping timeout: 260 seconds)
20:44:08Hannibal_Smithproc newElement[Tkey, TData](key: Tkey, data: TData) : PElement[Tkey, TData] =
20:44:08Hannibal_Smith PElement(kind: ElementKind.leaf, key: key, data: data)
20:44:23Hannibal_Smithtree.nim(27, 10) Error: object constructor needs an object type
20:44:23Hannibal_SmithWhy this is not ok?
20:44:33Araqlearn to read
20:44:53AraqI told you to use PElement[TKey, TData](...)
20:45:03Mat2hi Araq
20:48:48*ltbarcly quit (Ping timeout: 260 seconds)
20:50:13Hannibal_SmithI think this is the last thinkg, tmp_element.kind , that is the corrective of pointer->field?
20:50:43*ltbarcly joined #nimrod
20:51:13Hannibal_Smith*what is the equivalent of pointer->filed?
20:51:23Araqpointer.field
20:51:33Hannibal_SmithError: undeclared identifier: 'kind'
20:53:33Hannibal_SmithThe code is
20:53:43Hannibal_Smith var tmp_element = addr(root)
20:53:43Hannibal_Smith
20:53:43Hannibal_Smith while tmp_element.kind == ElementKind.inner:
20:53:43Hannibal_Smith...
20:54:08Hannibal_SmithRoot is stack allocated
20:56:08Hannibal_SmithAhhh sorry...
20:56:43Hannibal_SmithIt's better to treat TTree as an alias
20:58:03Mat2what do you mean exactly with the statement, that root is stack allocated ?
21:00:08Hannibal_SmithUhm...I didn't think that was a strange thing to say
21:05:33*ltbarcly quit (Ping timeout: 245 seconds)
21:06:43*ltbarcly joined #nimrod
21:11:33*ltbarcly quit (Ping timeout: 260 seconds)
21:13:13*ltbarcly joined #nimrod
21:24:03MFlamerAraq: I have the atomics working now. It was the minGW version.
21:24:53MFlamerI'll fix up our module and submit a patch
21:25:13Araqexcellent
21:27:33*jpoirier joined #nimrod
21:30:33Araqhi jpoirier, welcome
21:30:53jpoirierhowdy
21:31:03Mat2hi
21:35:13jpoirierquestion, does nimrod-code.org eventually get updated from github.com/Araq/Nimrod/tree/master/web
21:35:33Araqyes
21:36:43*EXetoC joined #nimrod
21:44:28*ltbarcly quit (Ping timeout: 264 seconds)
21:45:13*ltbarcly joined #nimrod
21:49:33*o2wtf2o quit (Quit: Page closed)
21:51:49*ltbarcly quit (Ping timeout: 245 seconds)
21:53:14*ltbarcly joined #nimrod
21:53:24Mat2ciao
21:53:24*Mat2 quit (Quit: Verlassend)
21:57:49*ltbarcly quit (Ping timeout: 260 seconds)
21:58:44*ltbarcly joined #nimrod
22:00:15dom96hi
22:01:58Hannibal_SmithHi dom96
22:07:30*ltbarcly quit (Ping timeout: 245 seconds)
22:09:35*ltbarcly joined #nimrod
22:12:21*MFlamer quit (Ping timeout: 250 seconds)
22:30:06Araqdom96: c2nim translates a union to its first field
22:30:20Araqthere is a slight chance that's correct and the best we can do
22:30:33Araqyou need to cast to access the other fields
22:30:58dom96I see.
22:31:12dom96Perhaps a little union macro would be possible
22:31:30dom96Which would generate correct types, and accessors.
22:31:55Araqyeah sure
22:32:07dom96Another issue I encountered:
22:32:19dom96What's void in Nimrod?
22:32:26Araq'void'?
22:32:50dom96lets see
22:33:16Araq"void*" is "pointer"
22:33:49dom96The compiler complains if I have 'ptr void' it seems
22:34:06Araqok, will fix it
22:34:21Araqc2nim should know about void* already
22:34:34dom96Would it not also make sense to use 'any'?
22:34:40Araqno
22:34:50Araqany is not compatible
22:35:13dom96ok, fix that then.
22:35:27Araqmake a proper bug report please
22:35:30dom96Another thing: size_t should be translated into csize.
22:35:47Araqno, to 'int'
22:35:53EXetoC'pointer' won't do?
22:36:15dom96EXetoC: OpenCV has a "arr" type which is void.
22:36:21Hannibal_Smithsize_t is not an uint?
22:36:38dom96Araq: docs say that csize = size_t
22:37:26AraqHannibal_Smith: I try to avoid unsigned if possible
22:37:35Hannibal_SmithOk
22:39:23dom96Araq: The OpenCV docs actually state what type TArr can be, I tried stating the types using '|' but it doesn't seem to be working.
22:40:09Araqyou use '|' to simulate a union? good luck with that
22:40:25dom96no
22:40:36dom96This has nothing to do with unions
22:40:40Araqdom96: I just checked c2nim translates void* to pointer
22:40:51Araqso make a proper bug report or I can't fix it
22:40:59dom96I guess you don't get it then.
22:41:09dom96typedef void CvArr;
22:41:28Araqlol
22:41:34dom96And then functions take 'CvArr*'
22:41:40Araqyeah of course
22:41:54Araqfoolish
22:42:11*ltbarcly quit (Ping timeout: 240 seconds)
22:42:16Araqtypedef struct CvArr CvArr; would have gained them some type safety ...
22:42:52dom96I wanted to do: type TArr = TIplImage | TMat
22:42:57dom96But maybe that's not even supported
22:43:00*EXetoC quit (Quit: WeeChat 0.4.1)
22:43:07*ltbarcly joined #nimrod
22:44:16dom96Using 'auto' causes a compiler crash btw
22:44:41dom96but since it's equal to 'expr' it's no surprise I guess
22:44:45Araq*shrug*
22:46:49dom96ok, i'll just shrug too then.
22:47:55*ltbarcly quit (Ping timeout: 264 seconds)
22:49:05*ltbarcly joined #nimrod
22:52:45*Yeri joined #nimrod
22:53:31*ltbarcly quit (Ping timeout: 240 seconds)
22:53:33dom96Araq: Voila, https://github.com/Araq/Nimrod/issues/591
22:55:02Araqthat's not a bug
22:55:07*ltbarcly joined #nimrod
22:55:26Araqand in fact your c2nim issue with typedef void cv; cv* is not either
22:57:01dom96so what should I do in my wrapper?
22:57:16Araqfix the C sources
22:57:18Araqmake it
22:57:30Araqtypedef struct CvArr CvArr;
22:57:48dom96no. I spent a couple of hours getting the generated code working
22:57:54dom96I'm not redoing all that work.
22:58:04dom96Tell me what to do in the Nimrod code
22:58:07Araqs/ptr void/pointer
23:00:28Araqor do: type TCvArr = object
23:00:38Araqs/ptr void/ptr TCvArr
23:00:47Araqfor improved type safety
23:01:35dom96That won't work.
23:01:46Araqwhy not?
23:01:57dom96TArr can be an IplImage, TMat and other things.
23:02:18AraqIplImange = object of TCvArr ?
23:02:19*ltbarcly quit (Ping timeout: 264 seconds)
23:02:30AraqTMat = object of TCvArr ?
23:02:36dom96that will work
23:02:55Araqmake TCvArr {.inheritable, pure.} for that
23:03:19dom96See, would have been so much easier if you just told me this from the beginning, instead of shrugging :P
23:03:39*ltbarcly joined #nimrod
23:03:41AraqI only shrugged about yet another "auto" bug
23:04:20Araqwhich you should report for zahary_ btw
23:05:13dom96hrm, I don't think this is working
23:06:06dom96yep, OpenCV doesn't like it
23:09:15dom96Of course, I may just be doing something silly with OpenCV.
23:09:32dom96But it works when I use TArr = TIplImage
23:10:31*ltbarcly quit (Ping timeout: 240 seconds)
23:12:30Araqdo you need to access the fields of TArr etc?
23:13:05*io2 quit ()
23:13:12*ltbarcly joined #nimrod
23:13:13dom96It is mostly for function params
23:13:40Araqyou can do:
23:13:54Araqtype TCvArr = object
23:14:08Araq data: array [0.. maxSize, byte]
23:14:36Araqand then only use ptr TCvArr and don't even have TIpImage etc.
23:14:56dom96and how do I know maxSize?
23:15:26AraqmaxSize needs to be max(sizeof(TArr), sizeof(TIpImage), ...) etc
23:15:42Araqbut this only works if you don't have arrays of them
23:15:49Araqso gah, better don't do it this
23:15:53Araqway
23:18:34*Hannibal_Smith quit (Quit: Sto andando via)
23:21:17dom96Any other ideas?
23:22:02Araqpastebin the types
23:22:36dom96TIplImage and TMat?
23:22:42*ltbarcly quit (Ping timeout: 264 seconds)
23:23:14Araqall of them, or simply everything you have so far
23:23:48dom96https://gist.github.com/dom96/85ab79fbe42d24b40696
23:24:13*ltbarcly joined #nimrod
23:28:34Araqboth TArr and TIplImage are barely used?
23:29:25Araqsorry, please pastebin again with everything, including proc signatures
23:29:31Araqso that I can see how it's used
23:30:52*ltbarcly quit (Ping timeout: 240 seconds)
23:32:42*ltbarcly joined #nimrod
23:36:52dom96argh
23:37:16dom96https://gist.github.com/dom96/76f7edb8a41a643d2365
23:37:35dom96They are used in there
23:40:46Araqwell I can't see why the "object of" stuff doesn't work. it should
23:41:02Araqbut you can also leave the types as they are and introduce converters
23:41:31Araqconvert toArr(x: ptr TIplImpage): ptr TArr = cast[ptr TArr](x)
23:43:07*ltbarcly quit (Ping timeout: 264 seconds)
23:44:14*ltbarcly joined #nimrod
23:45:38dom96meh, i'm too tired to play around with it now
23:46:54dom96Would be nice if | worked
23:47:18dom96but anyway, good night
23:47:23Araqgood night
23:50:53*ltbarcly quit (Ping timeout: 240 seconds)
23:53:17*ltbarcly joined #nimrod
23:58:06*ltbarcly quit (Ping timeout: 264 seconds)
23:58:48*ltbarcly joined #nimrod