<< 31-01-2014 >>
00:02:06*zahary quit (Quit: Leaving.)
00:02:58Araqhi filwit
00:25:27filwithey
00:27:12*xenagi joined #nimrod
00:38:36filwityall see this: http://www.commondreams.org/headline/2014/01/30-1 ?
00:38:52filwitthis is getting pretty ridiculous, lol
00:40:09filwit^ off topic, sorry
00:47:14*q66 quit (Quit: Leaving)
00:47:34*q66 joined #nimrod
00:47:34*q66 quit (Changing host)
00:47:34*q66 joined #nimrod
00:56:47Araqnp
01:12:52VarriountAraq: I still think "Nimbus" would be a good new name, if we are in fact renaming nimrod
01:21:55VarriountAraq: Ping
02:05:27*LordAndrew quit (Quit: Out.)
02:15:52Discolodait would be very 'cloud computing' sounding
02:17:45*Varriount quit (Read error: Connection reset by peer)
02:25:31*DAddYE quit (Remote host closed the connection)
02:26:06*DAddYE joined #nimrod
02:26:10*Varriount joined #nimrod
02:30:33*DAddYE quit (Ping timeout: 245 seconds)
02:40:45filwitI prefer Nimrod to Nimbus (don't like 'nimbus' at all really), but if i prefer just Nim most of all. I kinda agree with dom96 tho, that any name change is a bit risky at this point.
02:45:12Varriountfilwit: What about "Mellivora"?
02:45:54filwitwhy change to that tho? what's better about that than Nimrod?
02:46:07filwiti prefer Nimrod personally, Mellivora is too long, IMO
02:46:08VarriountWikipedia is your friend -> http://en.wikipedia.org/wiki/Honey_badger
02:46:15Varriount:3
02:46:41Varriount"Nimbadger"?
02:47:08EXetoCbest name ever
02:47:38VarriountActually, If I ever have a daughter, Mellivora might make a good name
02:49:10Varriountfilwit: To be honest though, I think nimrod is a neat name. When I first encountered it, I thought "Wow, they must be pretty confidant in the language to name it 'Nimrod'"
02:51:05filwit^ yeah i agree, but i g2g
02:51:25*filwit quit (Quit: Leaving)
03:12:45*shodan45 quit (Read error: Connection reset by peer)
03:12:54*shodan45_ joined #nimrod
03:14:41VarriountHas anyone ever been able to debug a nimrod application using Visual Studio?
03:29:39*shodan45_ quit (Read error: Connection reset by peer)
03:29:48*shodan45_ joined #nimrod
03:30:29*brson quit (Ping timeout: 272 seconds)
03:36:11*shodan45_ quit (Quit: Konversation terminated!)
03:36:14*shodan45 joined #nimrod
03:40:07xtagonI like the name Nimrod. Besides, if you change it, then the Donald Knuth quote isn't as funny.
03:40:22xtagonVarriount, good luck with that
03:48:05*XAMPP joined #nimrod
04:07:30*shodan45 quit (Quit: Konversation terminated!)
04:24:43*brson joined #nimrod
04:38:03*xenagi quit (Remote host closed the connection)
05:21:03*DAddYE joined #nimrod
05:47:13*Demos joined #nimrod
05:48:10DemosVarriount, ping
05:49:25reactormonkAraq, can you add that to the PR?
05:49:57reactormonkAraq, what's `<=` exactly here?
05:52:01reactormonkError: type mismatch: got (seq[seq[empty]]) but expected 'seq[seq[empty]]'
05:52:02reactormonkO.o
05:56:45NimBotAraq/Nimrod devel 5e1456e Simon Hafner [+0 ±2 -0]: product more robust against empty input
05:59:52*Mordecai joined #nimrod
06:00:51*psquid quit (Ping timeout: 272 seconds)
06:05:03*xtagon quit (Ping timeout: 252 seconds)
06:10:46*Mordecai quit (Quit: WeeChat 0.4.2)
06:11:32*psquid joined #nimrod
06:27:43*Demos quit (Read error: Connection reset by peer)
06:50:36*DAddYE quit (Remote host closed the connection)
06:51:02*DAddYE joined #nimrod
06:55:08*DAddYE quit (Ping timeout: 245 seconds)
07:10:00*io2 joined #nimrod
07:39:21*ddl_smurf joined #nimrod
07:52:35*brson quit (Quit: leaving)
07:54:31*brson joined #nimrod
08:50:15Araqreactormonk: '<=' is "is subset of"
08:50:19*io2 quit (Ping timeout: 272 seconds)
08:51:59Araqproc `<`*[T](a, b: TSet[T]): bool = a.counter != b.counter and a <= b
08:52:21Araq--> with <= you can easily define < too
10:03:40*bbodi quit (Ping timeout: 265 seconds)
10:16:57*bbodi joined #nimrod
10:29:28*brson quit (Read error: Operation timed out)
12:19:40*BitPuffin joined #nimrod
12:49:40*isenmann quit (Quit: Leaving.)
13:53:51*BitPuffin quit (Ping timeout: 260 seconds)
14:05:01*darkf quit (Quit: Leaving)
14:47:01*BitPuffin joined #nimrod
15:18:42*io2 joined #nimrod
15:34:47*psquid quit (Quit: work)
15:59:47*[1]Endy joined #nimrod
16:05:27*[2]Endy joined #nimrod
16:09:02*[1]Endy quit (Ping timeout: 252 seconds)
16:58:47*silven quit (Remote host closed the connection)
17:00:23*[1]Endy joined #nimrod
17:01:18*silven joined #nimrod
17:02:33*[2]Endy quit (Ping timeout: 245 seconds)
17:07:42*[2]Endy joined #nimrod
17:10:39*[1]Endy quit (Ping timeout: 260 seconds)
17:18:57*zahary joined #nimrod
17:43:51*BitPuffin quit (Ping timeout: 272 seconds)
17:44:35*zahary quit (Quit: Leaving.)
17:49:44*DAddYE joined #nimrod
17:58:39*Varriount|Mobile joined #nimrod
18:11:09*xtagon joined #nimrod
18:29:39*CarpNet quit (Quit: Leaving)
18:41:27*vendethiel quit (Quit: q+)
18:49:51*Varriount|Mobile quit (Read error: Connection reset by peer)
19:01:12*Varriount|Mobile joined #nimrod
19:07:59*vendethiel joined #nimrod
19:10:29*athaudia quit (Ping timeout: 248 seconds)
19:10:47*athaudia joined #nimrod
19:29:26*zahary joined #nimrod
19:35:37VarriountWhere is everyone?
19:35:53EXetoCprobably boozing
19:36:27VarriountI finally fix the bug that's been crashing the proactor code, and no one is around to celebrate
19:36:28EXetoCwhile they should be coding
19:37:33EXetoCVarriount: yay
19:38:02AraqI am around and celebrated
19:39:30EXetoCor both at the same time, but that shouldn't be done carelessly
19:40:59*Varriount quit (Ping timeout: 240 seconds)
19:44:16EXetoCwhat a long wait
19:44:25*zahary quit (Quit: Leaving.)
19:50:14*bbodi quit ()
19:50:51*bbodi joined #nimrod
20:06:26*Varriount joined #nimrod
20:08:33VarriountEXetoC: What do you think is the best way to ensure an object stays allocated between two completely different procedure calls?
20:14:49*shodan45 joined #nimrod
20:16:00AraqVarriount: var x; foo(x); bar(x) # works
20:16:01EXetoCVarriount: just keep a reference to it (reference count > 0)
20:16:28Araqbut if it's some callback, allocate it on the heap
20:20:21VarriountAraq: If I add a plain object to a sequence, is it copied to the sequence?
20:20:33Araqyes
20:20:49VarriountOk, that explains quite a lot.
20:22:32VarriountAraq: The overlapped object was being de-allocated from the stack between calls to connectEx (which takes a ptr to an overlapped object) and getQueuedCompletionStatus (which sets an argument to the pointer value given to connectEx)
20:23:04VarriountI thought I had fixed that by adding the overlapped object to the sequence. :/
20:24:01VarriountBy the way, Araq, what happens if a wrapper proc is set to receive a 'ref' type, when it actuality it is supposed to recieve a ptr?
20:24:19Varriountwrapper proc being something like a windows api procedure
20:24:38Araqif it doesn't capture the 'ptr' it simply works
20:24:50VarriountAnd if it does?
20:25:14Araqthen the GC might collect it even though some external references to it still exist
20:25:44VarriountSo.. exactly like passing a ptr type?
20:26:09Araqyes
20:26:21Araqexcept that the ptr isn't deallocated under your feet
20:26:51VarriountAh, the pointer itself you mean? Not just the value it points to?
20:27:15Araqno, the value it points to
20:29:23VarriountI'm confused. Passing a ref to a wrapped procedure that would normally take a ptr and capture it risks the object being deallocated?
20:29:53VarriountAnd thus, the pointer then points to invalid memory?
20:30:12VarriountOr ref, as it stands.
20:30:21*zahary joined #nimrod
20:30:24Araqyes?
20:30:32Araq'ref' is GC'ed
20:30:48Araqthe GC doesn't know about the capturing of the pointer that the extern proc performs
20:31:01*[2]Endy quit (Ping timeout: 248 seconds)
20:31:05VarriountHow is that different from a pointer?
20:31:36VarriountI thought the GC didn't know about ptr's being captured either.
20:31:48Araqyes ofc
20:31:57Araqbut then the GC doesn't care about ptrs
20:32:04Araqso you can dealloc when appropriate
20:32:27*brson joined #nimrod
20:32:44VarriountExcept if the object pointed to by the ptr is allocated on the stack.
20:34:42*Demos joined #nimrod
20:35:34AraqVarriount: if it captures the ptr you should allocate this on the stack ...
20:35:41Araq*should not
20:36:23VarriountBecause if it is allocated on the stack, the object will be deallocated when that frame of the stack ends. Right?
20:36:27DemosVarriount, I build your code on windows with vcc, no crash. I also tried with --gc:none and the gcc version still crashed
20:36:29Araqright
20:36:55VarriountDemos: I'm trying something. One moment
20:37:34VarriountAraq: Does the GC move structures around in memory?
20:37:40Araqno
20:38:35VarriountSo If I have a pointer to an object in a sequence, I don't have to worry about the pointer going bad, unless the sequence itself is copied, de-allocated, or modified?
20:39:24*Mat3 joined #nimrod
20:39:25Discolodaits hard to having a compacting GC when interfacing with C. the application would have to 'pin' and 'unpin' allocated objects
20:39:33Mat3hello
20:40:32VarriountDemos: Could you please build and run the code here with vcc, and tell me if it crashes? -> https://gist.github.com/Varriount/8742694
20:40:51*zahary quit (Quit: Leaving.)
20:42:07Demosnope
20:42:18Demosand the asio stuff does not crash on vcc
20:42:20VarriountIt crashes?
20:42:27Demosno it runs fine
20:42:30VarriountHuh
20:42:36Demosdoes it crash for you?
20:42:46VarriountDemos: Do you have to set anything special to let vcc compile nimrod programs?
20:42:59Demosnimrod c --cc:vcc blarg.nim
20:43:24Demosyou have to be running in the VS2013 [arch] native tools command prompt
20:43:35DemosC:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts for me
20:43:38VarriountAny code compiled with my version of vcc fails on the first allocation of traced memory
20:43:44Demosthat just sets up paths and what have you
20:43:47Demoshmmmm
20:43:54Demoswhat version of vc?
20:43:54*BitPuffin joined #nimrod
20:44:04VarriountDemos: Latest. I downloaded it yesterday
20:44:05AraqVarriount: addr to s[i] is unsafe as the seq s might be reallocated for 'add'
20:44:40Demoscan you just run cl.exe and tell me the version? also what nimrod compiler?
20:45:07VarriountDemos: Nimrod compiler is most recent devel version (or pretty close to most recent)
20:45:17Demosyeah let me reboot the compiler
20:45:31VarriountMicrosoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64
20:45:41Demoswowah there that is old
20:46:24Demosthat is the one that came with visual studio 2010
20:48:29VarriountYes.
20:48:46Demosthat code should not crash
20:49:07VarriountAlthough, it can also be downloaded seperately through the windows sdk, without installing the 5 gb Visual Studio.
20:49:13Demoswhat if you told nimrod to generate c++, MS's C compilers are pretty bad
20:49:35VarriountDemos: If I tell it to generate C++, I get errors about explicit casts
20:49:50Demosoh, never mind then
20:58:14EXetoCBitPuffin: sup
20:59:45Araqyeah generating correct C++ is a pita thanks to 'const'
21:00:13Araqhigh level portable assembler my ass ;-)
21:01:18Mat3Araq: Do you know C-- (which is now part of the GHC compiler) ?
21:02:06DemosI think the point of C is to be a target that EVERYONE has an optimizing compiler for
21:02:39AraqMat3: yeah, it has like 0 advantage over LLVM
21:03:18Mat3one advantage exist: Its far less bloated code
21:05:06Araqthere is no way it can produce better code though and I'm not sure it even exists
21:05:39DemosC seems to be a pretty good target language
21:05:43AraqDemos: the problem C solves is not hard and it doesn't solve it very well :P
21:05:56Mat3I agree
21:05:56VarriountAlso, iirc, C-- doesn't support x64, itanium, etc
21:05:57Demoswell sure
21:06:01Demosbut everyone has it
21:06:13Mat3Varriount: I think so
21:06:35AraqDemos: it works much better than the JVM for sure
21:06:52Araqbut it could easily be much better
21:07:06Demoswhy are we talking about the JVM...
21:07:14VarriountDemos: Updated the gist, please test it
21:07:15Varriounthttps://gist.github.com/Varriount/5ec6370dd37bb51cd947
21:07:17VarriountBrb
21:09:29Demosseems to work, although it reports "possible error: -1"
21:10:29Mat3may I ask, what a 'possible error' means in this context ?
21:10:57VarriountFinding the key
21:11:47VarriountI was using a pair of sequences for a makeshift has table, since the table that was being used didn't work correctly at some times for some reason
21:12:08VarriountHowever, in the end, I just hardcoded index 0 as the position for the key and data
21:12:26Varriount-1 is the position given if 'find' fails
21:12:41Mat3ah ok, thanks
21:12:57*zahary joined #nimrod
21:13:28VarriountDemos: Ok, now we just need a simple way to ensure that the overlapped structure allocated by connectEx (and in the future, other structure) aren't deallocated until they are retrieved
21:13:45*bbodi quit (Ping timeout: 245 seconds)
21:14:08DemosOK, are they just never deallocated right now?
21:14:33VarriountRight now I'm allocating it in a global variable, so yes
21:14:58VarriountHowever, we have to support multiple instances of an overlapped pointer, so that won't work for practical purposes
21:15:05Demoshow about RAII
21:15:09Varriount?
21:15:32VarriountExpand the acronym please
21:16:45DemosResource Allocation Is Initialization, it refers to freeing resources needed by a type in that type's destructor
21:16:54Demosnot sure how well nimrod destructors work atm
21:18:43VarriountDemos: I was thinking that we could use a sequence of refs to overlap structures. Do you see any possible problems with that?
21:19:33Demoswell since the overlapped structures are allocated by windows when those objects get collected overlapped structure will not get freed
21:19:46VarriountOverlapped struct are not allocated by windows
21:19:55Demosoh all the memory is allocated by us
21:20:01Demosor rather by nimrod
21:20:12Demosand there is no clean up call we need to make?
21:20:35VarriountWe allocate them, send a pointer to it via a api call, and must ensure that it doesn't get de-allocated before windows is done with it.
21:20:55VarriountDemos: Not that I know of. Yet.
21:21:20BitPuffinEXetoC: stuff
21:21:27BitPuffinand a direction
21:21:29VarriountAraq: Whats the idiomatic way of forcing something to be allocated on the heap?
21:22:02DemosI think new, alloc, alloc0, sharedAlloc, and sharedAlloc0 all use heaps
21:22:14Varriountso, creating a new reference would do it
21:22:20Demosand we could also just GC_ref it and GC_unref it when windows is done
21:22:44Demosdoes windos call a callback function when it is done?
21:23:11VarriountDemos: It posts a message in the io completion port when the IO request is completed
21:23:24AraqVarriount: the idiomatic way is to use the GC ... I don't think this works in your case though
21:23:45VarriountHowever I don't know if that necessarily means that other structures don't have a hold on the overlapped struct anymore
21:24:13Demosif you GC_ref soemthing then loose track of it the GC will never free it
21:25:11VarriountYeah.
21:25:14VarriountDemos: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365683(v=vs.85).aspx
21:26:39DemosOK as long as the code responding the the completion of the IO (and GC_unrefing) runs on the same thread that allocated the overlapped structure we should be OK
21:27:12Demosalthough using alloc may not really be harder and means the library (which is pretty low level I guess) does not depend on having the GC
21:27:44VarriountDemos: However we might have to track refs ourselves
21:28:38Demoswell I dont know what the lifetime is expected to be, but it sounds like it may be a situation when you are always deallocateing it in the same place anyways
21:28:50VarriountHm. True.
21:29:49VarriountWell, I think the best we can do is put mechanisms in place to warn if a structure like 'overlapped' is deallocated prematurely
21:31:14DemosI think we should be able to handle it, but I have never used low level asio
21:31:15VarriountDemos: Now that we have IOCP working, we can finally add support for windows to the fsmonitor module
21:31:37Varriount:D
21:32:45VarriountAlso, we are another step closer to fixing osproc on windows, and the builder
21:33:03Demosdid you look at those kernel object leaks? were they spurious
21:33:34VarriountDemos: Most of them were likely false positives, due to the gc
21:33:51VarriountOne of them was for the dummy socket used to get connectEx
21:33:54AraqVarriount: the builder needs to do its multi-threading differently
21:34:02AraqI already told dom96 though
21:34:39Araqturns out the TThread[T] interface is really badly implemented, but I want to get rid of it anyway
21:35:41VarriountAraq: The problem is that the builder is.. complicated. And I don't know where to start
21:36:36AraqVarriount: you have no idea... ;-)
21:36:48Varriount^ Correct
21:36:55Araqit's also untestable ...
21:37:31VarriountAnd only dom96 understands the protocol
21:38:01VarriountLet me put it this way - I'm afraid to touch anything, lest I break something.
21:39:13VarriountRight now I've just been going through the code, cleaning and updating where I can. I'm only part way through the code that sets up things
21:43:57EXetoCthere's no support for asynchronous process communication, right?
21:44:28EXetoCI wonder if there are any cross-platform C libs that can do this
21:44:32VarriountEXetoC: There is on linux, iirc
21:44:56VarriountYou can use select() and poll() on file handles
21:45:03VarriountIncluding stdin
21:46:45DemosEXetoC, does zmq do asinc IPC?
21:49:03Mat3as I know there exist some libraries for Pascal which should be platform independent, how about take a look on them ?
21:50:35AraqMat3: this is futile. you have to concatenate 12 different .inc files before you can start reading the code
21:50:55Araqspeaking from experience with FPC's source code
21:51:41Mat3hmm, possibly the p2c translator would be helpful
21:51:49Araqno way
21:52:20Araqjust forget it, do it like posix/winapi suggests
21:53:28Araqp2c can't handle modern pascal anyway, been there, done that
21:53:42Mat3ok, I see the problems
21:57:23EXetoCVarriount: I should've included the word easy, but that'll do
21:58:25EXetoCDemos: I don't know. I couldn't figure out anything when googling. maybe I need to know the basics first
22:04:36VarriountWait, Araq, are you working on the builder code? I'm working on it too, fyi
22:12:07*BitPuffin quit (Ping timeout: 260 seconds)
22:13:24AraqVarriount: no, I just checked where the corruption comes from
22:21:39Mat3ciao
22:21:48*Mat3 quit (Quit: Verlassend)
22:22:58reactormonkAraq, what's the counter for in sets?
22:24:18VarriountDemos: Thanks again for all your help. I really appreciated it.
22:35:12*brihat left #nimrod (#nimrod)
22:38:01*brihat joined #nimrod
22:38:36VarriountAraq: Which is more efficient, placing a 'try' block inside a loop where an exception might occur, or outside it?
22:41:05AraqVarriount: outside it
22:41:43Araqreactormonk: it counts the number of elements for more efficient comparisons like '=='
22:42:20EXetoCAraq: what's the purpose of that call syntax unification that we talked about yesterday? to reduce the need for providing additional overloads?
22:44:01EXetoCassuming that you meant the ability to call either "proc init(var x: T)" or "proc init(): T" like this "var x = init()"
22:44:10AraqEXetoC: not quite. to change return value semantics to that you can get 'appender' semantics. requires a blog post, I guess :P
22:45:39reactormonkAraq, ok
22:48:06reactormonkAraq, so how do you want the == implementation?
22:50:08*zahary quit (Quit: Leaving.)
22:53:45EXetoCAraq: is it something that can't be achieved, by defining an overload if necessary?
22:55:06EXetoCtedious or not
22:56:57*psquid joined #nimrod
22:57:05*psquid quit (Changing host)
22:57:05*psquid joined #nimrod
22:57:36*io2 quit (Ping timeout: 252 seconds)
23:00:59*ddl_smurf quit (Quit: ddl_smurf)
23:01:57*brson quit (Ping timeout: 248 seconds)
23:07:23Araqreactormonk: I already told you
23:08:10AraqEXetoC: yes, but this means 2 procs instead of 1 everywhere if you're consequent
23:12:59EXetoCyes, so almost what I said. it'll be very useful indeed
23:13:57reactormonk kk
23:16:32VarriountAraq: Do you know where an explanation of the hub protocol is, or lacking that, the hub source code location?
23:17:51Araqthe hub is simply website.nim
23:23:42reactormonkhow do I test for false with the unittest module?
23:26:10EXetoCcheck:\ncondition1\ncondition2 ?
23:27:11EXetoCor just "check x" I think
23:27:34EXetoCit expects every statement to evaluate to true, so just negate when necessary
23:28:35reactormonkEXetoC, then it errors out
23:28:51reactormonklib/pure/unittest.nim(110, 26) Error: index out of bounds
23:29:00reactormonk check not(toSet(@[1,2,3]) <= toSet(@[1,2,3]))
23:29:00EXetoCI thought that was fixed
23:29:14EXetoCmaybe it's a different bug then. is your build recent?
23:30:07*brihat left #nimrod (#nimrod)
23:34:03EXetoCuh, didn't I report a unittest bug before? anyway, it must've been at least a 3 weeks ago
23:34:15EXetoCthat it was fixed
23:35:33*Varriount|Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
23:37:54reactormonkyeah, nimrod is up-to-date
23:37:59reactormonkcan you dig out the issue?
23:38:05reactormonkmight have been fixed in master only
23:40:33EXetoCI had to search for unittest.nim rather than unittest. silly
23:40:35EXetoCyeah, sec
23:41:19EXetoCreactormonk: https://github.com/Araq/Nimrod/issues/708
23:46:02EXetoCat least that function is identical in both branches
23:46:38EXetoC*proc
23:47:12*brihat joined #nimrod
23:57:40*brihat quit (Quit: Leaving.)
23:59:19*brihat joined #nimrod
23:59:34*brson joined #nimrod