<<19-11-2012>>
00:16:24Araqgood night
03:53:24*Trixar_za is now known as Trix[a]r_za
06:32:51*zahary1 joined #nimrod
06:33:09*zahary quit (Read error: Connection reset by peer)
06:54:28*FreeArtMan joined #nimrod
07:00:36*FreeArtMan quit (Ping timeout: 248 seconds)
11:33:56*Boscop joined #nimrod
11:57:20*Trix[a]r_za is now known as Trixar_za
13:11:17zahary1>> zahary: what about supporting  'yield promise except EIO' directly in the language?
13:13:23zahary1Araq, did you miss my message about await … else: (await … except: .. )? it's good addition to the framework, but still non-handled failures should be converted to rejected promises upstream.
13:13:48zahary1I don't follow your reasoning in the next message: "if the event loop wraps every exception via  'try except: send(getCurrentException())' we lose exception tracking …". what do you mean?
13:14:28Trixar_zaHe probably means it stops at the first exception while ignoring all others
13:18:54zahary1nah, I rushed to write the message. what he meant is that the new tag tracking of exceptions will be broken
13:19:09*zahary1 is now known as zahary
13:34:17zaharyAraq, exceptions tracking is not lost. Indeed, the notion of "rejection" have to be made aware of the existence of exceptions, but otherwise it's possible to preserve tracking. when you write the async proc, the compiler can accurately determine what exceptions it may raise (these become part of the signature). then when I await the async result, I know that exceptions can be marshalled as rejected promises from the particular proc I'm calling
13:37:28zaharyit's possible to postulate that exceptions are the only way to reject promises. then rejection merely becomes a marshalling mechanism for exceptions, but I wouldn't impose such limitation without thinking through it and reviewing some real world code
14:21:49*XAMPP quit (Ping timeout: 246 seconds)
14:53:44*q66 joined #nimrod
15:20:09*FreeArtMan joined #nimrod
15:26:53Araqzahary: maybe I'm still too much into "event" thinking, but when you have this:
15:27:06Araqiterator worker(): PEvent/Promise =
15:27:29Araq yield AwaitDownload()
15:27:59Araq echo "download completed"
15:28:20Araqthen indeed the exceptions have to be marshalled
15:28:41Araqhrm, let me rephrase:
15:29:41Araqbrb
15:38:55Araqproc safe(): EBase =
15:39:00Araq try:
15:39:03Araq stmts
15:39:09Araq except:
15:39:25Araq result = getCurrentException()
15:39:39Araqhas {.raises: [].}
15:40:00Araqand that's correct but annoying as EBase doesn't mean much to clients
15:40:22Araqit's preferable to not catch the exceptions so that the exception list stays accurate
15:40:56Araqand that can only be achieved via some builtin syntactic construct
15:44:17zahary`safe` in this example is analogous to the wrapper code that will marshal the exception?
15:44:50Araqexactly
15:46:53zaharyI would prefer if we just expose some meta-programming interface to the exception tracking mechanism - you can ask "what exceptions can exit this block?" (you do that in the wrapper), then at the await callsite, you explicitly set your raises tag, even tho the compiler would have seen no exceptions there
15:52:08Araqyou can already ask "what exceptions can exit this block" btw with the .effects. pragma
15:52:24zaharybut it only prints out the values?
15:52:40Araqit prints out where the 'raise' statement occurs
15:52:46Araqbut not the stack in between
15:53:50Araqsince the stdlib is not full of layers that's good enough for now
15:54:11Araqbut alright lets focus on some other design aspect instead:
15:54:25Araqwhat about tyProc + closure == tyIter ?
15:54:47zaharyrephrase, please
15:54:51AraqI don't think anymore that it makes much sense
15:55:02zaharythe unification?
15:55:06Araqyes
15:55:54zaharyI don't have a strong opinion yet, but let me give you example at least for what I was talking about the other day
15:55:58zaharystill not sure we are the same page
15:56:24Araqok
15:59:29zaharyhere is the most basic counter iterator written in both styles:
15:59:29zaharyhttps://gist.github.com/2b62bbc983eced937216
15:59:55zaharyobviously, the iterator version is easier to read/write
16:00:33zaharybut one problem it may have is that its performance is worse
16:01:03zahary… that is, if the body is big and unruly and the duff device dispatch is more expensive
16:05:50Araqhrm
16:07:52dom96hello
16:08:09Trixar_zaErm, I know I'm asking a stupid question, but how would I read a value from a key under different sections in a cfg file?
16:13:36Araqignore the section information then?
16:14:16Araqzahary: I'm torn, on the one hand unifying them is very easy to do
16:14:42Araqon the other hand it loses a bit of efficiency and the closures are quite different:
16:14:46dom96Trixar_za: of cfgSectionStart: currentSection = e.section
16:15:08Araqfor a first class iteration the closure contains the locals of the iterator itself
16:15:21zaharywe can always go with {.iterator.} pragma that's applied to closures to make them iterator compatible
16:15:22Araqfor a closure proc the closure contains the outer variables
16:15:51Trixar_zadom96: thanks
16:16:58Araqproc join(strings: iterator(): string): string
16:17:15Araqalso looks much better than:
16:17:27Araqproc join(strings: proc(): string): string
16:18:25Araqthe later means that 'proc: T' is more something like 'proc: optional[T]'
16:18:58zaharyI prefer iterator() to be used in signatures too
16:19:46zaharywhat about my {.iterator.} pragma suggestion? it solves by "more efficient iterator" problem
16:20:00zahary* solves my *
16:21:20Araqwell the real question is whether to introduce tyIter as analogous to tyProc
16:21:41Araqor to use tyProc+ ccClosure + iteratorFlag
16:22:16Araqsyntax is another problem; I prefer 'iterator' for iterators, but dislike 'iterator' for async programming ...
16:22:53zaharyI usually let the code tell me - if I have to check the flag all the time inside tyProc cases then I missed to introduce tyIter
16:23:23zaharyif I added tyIter only to add it right next to tyProc in every case statement ...
16:23:52zaharyI would really dislike if you introduce another keyword like task
16:24:21zaharynot from syntax point of view, but from sem's perspective
16:26:50AraqtyIter indeed is that same as tyProc with the difference that they mustn't type check
16:27:03Araqyou can't pass tyIter where tyProc is required and vice versa
16:27:24Araqwell ok, you can pass tyIter to tyProc + ccClosure ...
16:27:41zaharybtw, this was a big factor why I avoided keywords in my hypolang
16:27:41zaharyI really wanted to have special procs like tasks, commands, unroRedoActions, rpc, etc
16:27:41zaharyso I optimised the syntax to allow for this.
16:27:41zaharyin nimrod the analog will be to use this style everywhere
16:27:41zaharytask downloadFiles do (url: string) -> string:
16:27:42zahary ...
16:28:52Araqyeah that's a problem in nimrod
16:29:21AraqI'm still thinking about a better solution
16:29:46zaharyin hypolang, it;s
16:29:46zaharydef foo [x: int]
16:29:46zahary …
16:29:46zaharytask foo [x: int]
16:29:47zahary ...
16:29:59zaharyitems.each [x: int]
16:29:59zahary ...
16:31:05Araq'proc' has the advantage that it can mean 'procedure' as well as 'process'
16:31:07*XAMPP joined #nimrod
16:31:25Araqso it's not too far off anything I could imagine ;-)
16:31:59zaharythe word is not so important, actually I'm still torn between def and fn
16:32:15Araq'def' is better as it has no semantic
16:32:21zaharythe point is that I only support "do blocks" as part of the grammar, everything else is built from them
16:34:07Araqyeah I got that
16:36:44Araqthere was also the point raised that 'async' in C# means the opposite of 'async' as these thing are in fact even more syncronous as you can pause them
16:37:32zaharyyou can pause what in particular?
16:37:46zaharytheir async tasks has a pause method?
16:38:05zaharyI didn't know that. I like it actually
16:38:15Araqno, 'await' implements the "pause" feature
16:38:49zaharybut what do you mean by pause in this context?
16:39:49Araqexactly that it can "await"
16:40:08Araqit pauses until the requested event occured
16:40:17zaharybut the proc returns, other procs execute code while it waits
16:40:34Araqexactly it doesn't "wait" either ;-)
16:40:53AraqI don't mind the keywords either, I think they are well chosen
16:40:58zaharywell, you are arguing the semantics of english here :)
16:41:18Araqyeah and it's not my mother tongue so it's all very mood
16:42:01Araq*moot
16:44:16Araqso what should it be: proc register(task: proc {.async.})
16:44:29Araqproc register(task: iterator()) ?
16:47:02*zahary1 joined #nimrod
16:47:02*zahary quit (Read error: Connection reset by peer)
16:47:22zahary1there is no problem if the async pragma works both on definitions and type signatures
16:48:09Trixar_zaOh yeah, got it to work
16:48:22Araqyeah but I wanted to implement 'async' as a macro
16:48:52zahary1yeah, macros as pragma works only for definitions now?
16:49:05Araqtrue
16:49:16Araqoh well I'll go with tyIter and an 'iterator' keyword for types
16:49:29Araqat least it's consistent this way
16:51:27Araqabout hypolang: you can infact do this:
16:51:44Araqdef task myTask(x, y: int) -> int = ...
16:52:02Araqand have a 'def' keyword followed by an identifier
16:52:24Araqthis way it's all easily parsable, reads nicely and stays consistent
16:53:38Araqyou can make the identifier optional and then it defines a function
16:55:00Araqkeywords to introduce new declarative elements are pretty nice, I wouldn't want to get rid of them completely
16:55:43zahary1I have explained before how I believe executable blocks are the ultimate declarative definition mechanism
16:57:47Araqyou explained it but I'm not sure it can work in practice
16:58:12Araqwithout having some nasty parser-semcheck interactions
16:59:44zahary1there are no problems really, I have already implemented similar system in lua if you remember
17:00:38AraqI barely remember ;-)
17:01:16Araqbut anyway, maybe we should do that 'def' stuff for nimrod?
17:01:32Araqfirst step would be to make a keyword asap
17:02:02zahary1what does it do? it calls a macro called task?
17:02:23Araqyes
17:02:37Araqbut ugh {.task.} is good enough
17:20:48Araqnow some other things:
17:21:08AraqI plan to introduce 'shared' and 'not nil' for pointers
17:22:00AraqI figured GC support is very easy to do; in fact, I think I'll support it with 'gc:mixed' and use Boehm for the shared heap
17:25:42Araqlooks like a cheap first implementation
17:27:10Araq'shared' may be useful for other types too, but the details escape me for now
17:27:53Araqhowever a write access to a shared object is invalid if it's no atomic write operation and it's not within a lock
17:30:52*IMBot joined #nimrod
17:31:28*IMBot quit (Remote host closed the connection)
17:31:53*IMBot joined #nimrod
17:32:43*IMBot quit (Remote host closed the connection)
17:33:08*IMBot joined #nimrod
17:33:25IMBotTrixar_za: Sorry, I meant to make it connect to my server - lol
17:33:32IMBotTrixar_za: Now I know where it went...
17:35:25*IMBot quit (Remote host closed the connection)
17:43:31Trixar_zaHow do I make a string a sequence?
17:43:47Trixar_zaor better yet, add a string variable to a sequence
17:43:47Trixar_za:P
17:45:04reactormonkTrixar_za, sequence of chars?
17:46:18Trixar_zaWell, dom96's IRC module has a sequence for the IRC channels it joins: @["#chatz", "#nimrod", "#ohmy"]
17:46:50dom96joinChannels.add(stringVar)?
17:47:11Trixar_zaThanks
17:47:11Trixar_za:P
17:50:23Trixar_zaNo, that doesn't work
17:50:24Trixar_zagrrr
17:50:41dom96Give us some more details then
17:50:46dom96Some code would help :P
17:51:09Trixar_za imchan = conf("IM", "channel")
17:51:17Trixar_za imside = irc(imserv, joinChans.add(imchan), nick=imnick,
17:51:17Trixar_za user=ident, realname=name)
17:51:36Trixar_zaconf returns the cfg value as a string
17:51:49dom96.add doesn't return a sequence
17:52:09dom96You need to do it on a separate line.
17:52:16dom96then pass 'joinChans'
17:57:55Trixar_zaHow. I tried setting JoinChan = @[] then JoinChan = JoinChan.add(imchan) and finally JoinChans = JoinChan
17:58:04Trixar_zaHow?*
17:58:25dom96JoinChan.Add does not return anything
17:58:32dom96So it doesn't make sense to assign it to anything
17:58:40dom96it adds values in-place
17:58:54dom96var list = @[1,2,3,4]
17:59:17dom96list = 1,2,3,4,5
17:59:31dom96^^ er, that should be a comment :P
17:59:38dom96argh
17:59:41dom96Let me start again
17:59:45dom96var list = @[1,2,3,4]
17:59:52dom96# list is equal to 1,2,3,4
17:59:55dom96list.add(5)
18:00:00dom96# list is now equal to 1,2,3,4,5
18:00:13dom96Get it?
18:00:24*zahary1 quit (Read error: Connection reset by peer)
18:01:12*zahary joined #nimrod
18:02:35Trixar_zaYes, but I want an empty list. I only want to add one damn channel that can be set in the config file :/
18:04:39dom96well then:
18:04:42dom96var list = @[]
18:04:56dom96list.add(conf("IM", "channel"))
18:06:17Araqvar list: seq[string] = @[]
18:06:31Araqtype inference doesn't work for @[] ...
18:07:30dom96oh yes, I always forget that
18:08:00Araqyeah because it sucks :P
18:11:29Trixar_zaAnd now it compiles
18:11:40Trixar_zaThanks Araq
18:11:41Trixar_za:P
18:17:31Trixar_zaBut it doesn't run
18:17:32Trixar_zalol
18:32:02*Trixar_za is now known as Trix[a]r_za
18:45:22Araqzahary: if C#'s async doesn't capture the stack why did they implement it as CPS transformation? why did they not take the closure + state machine route?
18:45:44Araqthat's really puzzling me ...
18:46:06zaharywhere did you read that btw? I remember reading that they reused the yield state machine implementation
18:47:35zaharyhttp://tv.devexpress.com/#AsyncFromScratch
18:48:17Araqin eric lippert's blog
18:48:29zaharyI haven't watched that, but here is the citation:
18:48:29zaharyawait always involves the same kind of transformation - but it's a pretty painful one. The library side ofawait isn't too complicated, but the tricky bit is that the compiler builds a state machine for you, allowing the continuation to jump back to the right place.
18:50:27zahary0
18:50:27zaharydown vote
18:50:27zaharyFrom my reading, the major differences between yield return and await is that await can provide explicitly return a new value into the continuation.
18:50:27zaharySomeValue someValue = await GetMeSomeValue();
18:50:27zaharywhereas with yield return, you'd have to accomplish the same thing by reference.
18:50:27zaharyvar asyncOperationHandle = GetMeSomeValueRequest();
18:50:27zaharyyield return asyncOperationHandle;
18:50:28zaharyvar someValue = (SomeValue)asyncOperationHandle.Result;
18:54:17Araqthat's true but you can easily yield an object that contains the result afterwards
18:54:55Araqbut it's a good point that I overlooked, 'await' returns a value
18:55:08zaharyI don't follow. this code is exactly like the one I posted the other day in my gist
18:55:21AraqI know
19:04:37Araqso if I yield a promise how would the interaction work with 'onProgress'?
19:05:01Araqsome inner proc in the iterator gets called on progress?
19:05:36zaharyhttps://gist.github.com/4096467
19:05:36zaharysee the stepCoroutine loop - this is what drives the iterator
19:06:20Araqwell yeah
19:06:22zaharythis loop is somewhere in the framework, all user iterators end up using it
19:06:39AraqI don't get it :P
19:07:01Araqis the recursion a typo or not?
19:07:16zaharyit's not a direct recursion
19:07:20zaharyit's an async recursion :)
19:07:30zaharymaybe you need an example for a promise to get it
19:07:54zaharytry reading this:
19:07:54zaharyhttps://github.com/kriskowal/q/blob/master/design/README.js
19:08:14zaharyit's bit ugly at the end, but the first examples are simple
19:10:47zaharyI see now that your question was about onProgress specifically?
19:11:31Araqyes
19:11:41Araqbut I'm reading the .js anyway
19:12:59zaharyon progress would not really interact with the iterator (by default the iterator will wait for onComplete)
19:13:16zahary Instead you'll just decorate the promise you're sending with an additional progress code
19:13:38Araqyeah that's what I thought too, ok
19:13:47*apriori| joined #nimrod
19:13:49zaharyyield download(url).onProgress do (percents: int):
19:13:50zahary echo "dowloading ", percents
19:13:50Araqnow back to the async recursion :P
19:25:31Araqmeh, that's over engineered :P
19:25:41Araqevery promise keeps a list ... I don't like that
19:26:20zaharyit uses event objects internally
19:26:27zaharyno reason for them to be expensive
19:27:36zaharymultiple observers are useful, please don't cripple the framework by not supporting them
19:28:06Araqseems to me you can easily add them on top of the single observers
19:28:19zaharynot in an uncoordinated way
19:28:40Araqhu? you want an uncoordinated way?
19:29:16*apriori| quit (Quit: Konversation terminated!)
19:29:41zaharyone 3rd party library adds its own tasks related code, another adds another useful bits, etc
19:30:38zaharyyou should invest time in making very efficient event objects
19:30:46*Zerathul joined #nimrod
19:31:43Araqmeh, I'll finish the compiler support for it, you implement the framework on top of it :P
19:32:17zaharyI could do that, but I won't consider it priority
19:32:41Araqwell what is of high priority to you?
19:33:36zaharycaas, finishing my type classes, finishing the support for value semantics, improving the compile-time variables support
19:33:53zahary… to name a few
19:34:59Araqalright
19:36:27*Zerathul_ joined #nimrod
19:39:04*Zerathul quit (Ping timeout: 255 seconds)
19:39:07*Zerathul_ is now known as Zerathul
19:46:47Araqif the promise says it's "onCompleted" why do you check for 'finished(coro)'?
19:47:11Araqbecause it's a single value that has been completed, right?
19:47:49zaharyright, one step of the iteration
19:48:05*Zerathul quit (Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032])
19:48:26zaharyif finished(coro) is supposed to check that there is no point in further calling the iterator. Is that the way to check that?
19:48:46Araqyes
19:49:21AraqI still don't get what 'stepCoroutine' is about ...
19:50:14Araqit exhaustes the iterator "asyncronously"
19:51:01zaharywell, what will happen if we don't exhaust the iterator asynchronously?
19:51:24zaharyyeild download(url)
19:51:25zahary… # the next line is immediately executed
19:52:19zaharyyour confusion is confusing to me :) isn't this obvious?
19:54:06Araqhu? the next line after a yield is not immediately executed at all
19:54:16Araqyield passes control back to the event loop
19:54:48zaharyI meant in a regular for loop - the body is run and we continue to the next line, where is the "wait for the async result" part?
19:56:01Araqmaybe but you can exhaust the iterator with a while loop too
19:56:22zaharyplease write the loop
19:56:47Araqit's in tests/run/titer8.nim
19:57:01Araq while true:
19:57:03Araq let x = t[ticker mod t.len]
19:57:05Araq if finished(x): break
19:57:06Araq x(ticker)
19:57:08zaharywhere is the "wait for the async result" part?
19:58:27Araqwell it calls 'x' and obviously awaits it's return
19:58:45zaharyblock until the result is ready?
19:58:50Araqyes
19:58:56zaharywhere is the async part :)
19:59:01Araqbut you want to avoid this blocking, right?
19:59:03Araqaha
19:59:12zaharythe goal of async programming is to have multiple operations execute in parallel
19:59:54Araqit's in fact collaborative tasking
20:00:16Araqso the task better performs no long operations
20:00:28Araqand 'yield's back as soon as possible
20:00:54zaharyif you block anywhere in the code, the whole system will fall apart
20:01:14Araqnah, you need threads then
20:01:52Araqthe point for me is that it avoids race-conditions and locking
20:04:28zaharythere are many points actually. you can look at it from different angles. another point is the OS will take care of optimally allocating resources for I/O, because it has better idea of what have been requested at any given point. you can spawn N threads that wait on the completion port (epoll), when N is the exact number of processors in the system and that will provide the maximum performance - the minimum amount of context switches
20:04:50zahary* where N is *
20:05:09Araqin fact, I dislike that C#'s async may run the task on a different thread but tries to run it on the same
20:05:20Araqthat's a recipe for really subtle bugs
20:06:01zaharyI haven't read the details about this. in C++ you have control. it's up to you how many worker threads you'll attach to the completion port
20:06:44zaharyone problem that exists is that completion port loops and windows messages loops cannot run on the same thread
20:07:00Araqif you don't keep threading out of this, you merely end up with something like Go's goroutines
20:07:05zaharyso in GUI programming, you want to use another API - alertable I/O
20:07:24zaharymaybe the C# folks implemented that to hide the complexities from the user
20:07:38Araqmaybe, yeah
20:09:02zaharymy point about blocking was that in the most classic setting you have a single thread running the event loop
20:09:08zaharyif you block that thread, you block everything
20:09:51AraqIMO the nice thing is to cleanly seperate the async loop and threading, so that I can have efficient IO without threads and thus cannot get any races
20:10:41zaharyyep
20:14:10AraqI don't want the event loop to use all my cores; I use data parallelism to keep every core busy ...
20:14:43zaharypromises are very nice for data parallelism too btw
20:14:56zaharythen you block on them indeed
20:15:53zaharyx = spawn fib (n-1);
20:15:53zaharyy = spawn fib (n-2);
20:15:53zahary
20:15:53zaharysync;
20:16:11zaharyx and y are promises, sync is the blocking (x & y).wait()
20:16:18Araqyeah that's cilk
20:16:20zaharytranslated from cilk
20:16:32Araqread their papers ;-)
20:17:03Araqit's nice but I don't think it belongs to the async stuff
20:17:41AraqI prefer to cleanly separate concurrency and parallelism
20:17:58Araq(I know it's not really feasible)
20:17:59*FreeArtMan quit (Ping timeout: 260 seconds)
20:18:25zaharyit uses the same compositional logic of promises, the async stuff requires event loop to resolve the promises. this will use classic threading primitives to do so
20:24:13Araqyes instead of an event loop you have some simple scheduler that tries to keep N threads/cores busy
20:29:23Araqthe cilk people also noticed it's not enough and went on to incorporate software transactional memory iirc
20:30:12dom96Maybe if this project succeeds they will allows us to use it: http://www.snakebite.net/
20:34:34*gradha joined #nimrod
20:37:18Araqdom96: yeah
20:37:33AraqI somewhat doubt it will succeed
20:44:22dom96yeah, these things do usually cost a fortune.
20:53:19*ekselkiu joined #nimrod
20:54:16Araqgradha: your testing sucks :P I keep finding bugs of exception propagation
20:55:22gradhait's not like I have a machine for exception propagation testing set up
20:56:25gradhabtw I'm still stuck on the db_* modules
20:57:01Araqdefine "stuck"
20:59:13gradhaI have 13 items in a local scratch pad with regards to nimrod, ranging from asking questions to implementing stuff
20:59:32gradhaI just happen to be willing to tackle now getRow returning a single row or more
21:03:30gradhaI'll use the chance to reask an old question: I'm trying to write except as a statement but I'm failing, the following code works http://pastebin.com/mYUk7B5n but the following doesn't http://pastebin.com/uTZtxAVc and I don't know why
21:04:13gradhaI believe I've had success using finally as a statement though, so maybe the except syntax I'm trying is not right, and couldn't find any example
21:05:03Araqthe compiler wants to attach it to a var/let and can't find any
21:06:07gradhawhat, the exception? but wasn't the point of using it as a statement that you put it before the code that goes inside the "try" block?
21:08:12gradhathe manual only says "except and finally can also be used as a stand-alone statements. Any statements following them in the current block will be considered to be in an implicit try block"
21:08:35Araqwell i'm reading the implementation now
21:08:38gradhaand lists an example of finally as a statement
21:09:29AraqI was wrong
21:09:51Araqthe code does what the manual says ... hrm...
21:10:28*Trix[a]r_za is now known as Trixar_za
21:13:52Araqwell the parser only supports 'except:' not 'except list:' ...
21:14:22Araqmakes the feature pretty useless, hu? ;-)
21:14:50gradhahehe the next thing I was meaning to ask is how to chain multiple except statements
21:15:05gradhayeah, compiles now
21:15:19Araqstandalone except looks stupid
21:15:31AraqI wonder what zahary had in mind for it ;-)
21:16:10zaharyit does exist in other languages so I added it for completeness
21:16:30gradhaok, since the mistery is solved then I'll let you think about it and continue with my tasks
21:16:35zaharyit was scope(error) in D I think and onerror in clay
21:20:24Araqyes I know, but I can't think of any useful use cases
21:20:37Araqespecially since it doesn't even filter the exception type
21:21:00zaharywell, gradha wants to remap exceptions.
21:21:17zaharythe lack of filtering is probably something stupid on my part
21:21:25gradhawhat does remap mean?
21:22:00Araqyeah but he uses 'block except'
21:22:08Araqhe may as well use 'try except'
21:22:11*Trixar_za is now known as Trix[a]r_za
21:22:34Araq'finally' makes sense so you can put the cleanup to the setup code
21:22:39gradhaah, you may ignore those block, I was trying different stuff at the same time to make the except as statement work
21:24:22zaharythe clay manual describes it as an alternative to C++'s auto_ptr.release()
21:25:26zaharyinstead of
21:25:27zaharyauto x = make_auto_ptr(new T)
21:25:27zahary…
21:25:27zaharyreturn x.release()
21:25:27zaharyyou do
21:25:27zaharyauto* x = new T
21:25:27zaharyonerror delete x
21:25:28zaharya bit more efficient indeed
21:29:17dom96IMO 'onerror' is a much clearer keyword to use in this case. 'except' on its own would certainly puzzle me.
21:29:27*Nimrod joined #nimrod
21:29:39Araqhi Nimrod
21:30:22NimrodVERSION
21:31:59*Nimrod is now known as FlutterAi
21:32:09zaharyonerror is indeed cleaner
21:32:10zaharythat's why I made except a bit different than onerror in clay. except handler the exception now while onerror and scope(exit) let the exception propagate
21:32:14*FlutterAi quit (Changing host)
21:32:14*FlutterAi joined #nimrod
21:32:38zaharymy reasoning was that we can now add onerror as a template that reraises the exception to get you the clay and D meaning
21:33:01zahary* except: handles *
21:33:59Araqaha, I see
21:34:01Araqthat makes sense
21:34:54Araqonerror:
21:34:58Araq echo "argh"
21:35:01Araqbecomes:
21:35:04Araqexcept:
21:35:09Araq echo "argh"
21:35:11Araq raise
21:35:14Araqright?
21:35:17zaharyyes
21:35:41dom96so then onerror is basically 'finally'?
21:35:44Araqso now we know you only supported 'except' without exception filter
21:36:03Araqdom96: not quite, finally is *always* executed
21:36:11Araqonerror only on error :P
21:36:14dom96ahh
21:38:00dom96So how does this standalone except work? Is it equivalent to try: current block here except: ..?
21:38:35FlutterAihelp
21:38:37FlutterAiinfo
21:38:47FlutterAiVERSION
21:38:58FlutterAiVERSION
21:39:02zaharyyes
21:39:22Araqinstead of "current block here" it's actually "statements following the except in the current block"
21:39:36dom96ahh, yeah. That's what I was wondering about ^^
21:48:35gradhaAraq: in http://forum.nimrod-code.org/t/99 you suggest adding a new proc getRow*(res: var TRow, db: TDbConn, query: TSqlQuery, args: varargs[string, `$`]): int
21:49:10gradhawouldn't it be better if TDbConn was the first parameter to maintain the "syntaxis sugar" of the rest of the module and var TRow the last?
21:49:23gradhaoh, wait, it can't be the last, maybe second then
21:49:57Araqwhatever you feel like ;-)
21:50:08gradhayay, free ride!
22:03:45gradhazahary: in vim I tend to select blocks of comments and press gq to format them. This works ok for blocks of a single hash, but when a line with two hashes is reformatted the following lines use only a single hash. Do you know how to fix this to preserve the same amount of hashes for each line?
22:04:21zaharydo you use NerdCommenter?
22:04:29gradhacertainly not
22:05:13zaharyah, sorry, I misread that you are commenting blocks, not formatting
22:05:41zaharyI'm actually not familiar with this formatting feature of vim
22:06:34gradhaI love how the nerdcommenter plugin documents installation and setup but doesn't mention what it does or what it is useful for
22:07:54zaharyhave to look up how it works (gq). it probably interacts with my indent code somehow. what do you mean by hash btw?
22:08:04zaharynerd commenter is about commenting blocks of code
22:08:12Araqhash == # character
22:08:30gradhaI'm writing nimdoc comments
22:08:47gradhaso I start with "##" and when I run out I try to format it to wrap to 80 cols
22:09:11gradhafound instructions at http://spf13.com/post/vim-plugins-nerd-commenter/
22:10:16FlutterAiAh hey, would you happen to know if NimBot has, at some point in the last 10 months, used the nick "Nimrod"?
22:10:58Araqhi FlutterAi
22:11:14Araqit never uses that nick afaik
22:11:18gradhaHmmm... I believe this ## could be achieved emulating C++ // comment formatting which works as expected
22:11:55dom96FlutterAi: I highly doubt it, if ever it couldn't have been for more than a minute or 2. Why?
22:12:32FlutterAi*shrug* Some bot has used my nick before and I'm just curious as to where it usually sits around/what it's for
22:13:13gradhaAraq: looks like macs are underpowered, tried to run koch test but failed at some point http://pastebin.com/gQYAvZT8
22:15:17zaharygradha, I think the fix is setlocal comments=:#,:##
22:15:21zaharyI'll add that to my plugin
22:15:32Araqgradha: maybe there is still a "handle" leak in osproc.nim ...
22:16:09gradhazahary: that doesn't seem to work for me
22:16:26gradhacan you type it inside vim or does it have to go in some .rc file?
22:17:06zaharywhat I did is to execute it as a : command in a nimrod buffer
22:17:26gradhame too
22:17:38zaharybefore doing that formatting a long line starting with ## yielded a new line with single #
22:18:04zaharybut after doing it, the new line had proper ##
22:18:24zaharymaybe your way of formatting is different?
22:19:06gradhaI'll see
22:20:33zaharyaha, it should be setlocal comments=:##,:#
22:20:54gradhayep, I was just trying that
22:21:49gradhathis is much better now for documenting, thanks
22:27:13Araqgradha: how is #255 a bug by any means?
22:27:33Araqyou can exportc those to different names but that's your job
22:27:41Araqyou can even do:
22:28:15Araq{.pragma: myexp, exportc: "moduleA_$1".}
22:28:22Araqproc p {.myexp.}
22:28:36Araq--> p will be exported as moduleA_p
22:29:36fowlhow about {.push importc: "SDL_$1".} would that work?
22:29:53Araqdunno ;-)
22:30:45gradhaIt's great that you can solve this through explicit exportc naming, but I would expect the nimrod compiler to not generate code which doesn't link
22:31:10gradhait's not important, I was simply trying weird stuff, so close the issue
22:31:56zaharyfowl, I think it doesnt
22:32:04zaharybut what works is this:
22:32:46zahary{.pragma: sdlexp, exportc: "sdl_$1", dynlib, cdecl.}
22:32:52zaharythen use sdlexp everywhere
22:33:22Araqas I said, yes
22:33:33fowlzahary: i need importc
22:33:49fowli use a macro for it currently
22:34:15Araqsame works for importc ...
22:35:45*gradha quit (Quit: gradha)
23:06:54*ekselkiu quit (Ping timeout: 260 seconds)