<< 12-05-2014 >>
00:00:28*Johz quit (Quit: Leaving)
00:00:47Araqgood night
00:00:54SkrylarAraq: gnight
00:19:43*Demos joined #nimrod
00:38:56*q66 quit (Quit: Leaving)
00:44:53*olahol quit (Ping timeout: 240 seconds)
00:44:55*olahol_ joined #nimrod
00:45:40*oxful__ quit (Ping timeout: 240 seconds)
00:46:11*oxful__ joined #nimrod
01:05:29*brson quit (Ping timeout: 252 seconds)
01:07:35*brson joined #nimrod
01:11:43*JStoker quit (Killed (hobana.freenode.net (Nickname regained by services)))
01:12:01*JStoker joined #nimrod
01:15:54EXetoCwe don't have sort for strings?
01:20:57Demosis that a hard problem? lexographical comparison should be avalible someplace :D
01:48:23*brson quit (Ping timeout: 252 seconds)
01:48:25*zahary joined #nimrod
01:50:17*brson joined #nimrod
01:51:14*CARAM_ joined #nimrod
01:51:16*zahary1 quit (Read error: Connection reset by peer)
01:51:17*CARAM quit (Ping timeout: 240 seconds)
01:51:20*zielmicha_beta quit (Ping timeout: 240 seconds)
01:51:21*fowl quit (Ping timeout: 240 seconds)
01:51:32*CARAM_ is now known as CARAM
01:52:03*olahol joined #nimrod
01:52:30*olahol_ quit (Ping timeout: 276 seconds)
01:52:34*Xuerian quit (Ping timeout: 276 seconds)
01:52:38*Xuerian joined #nimrod
02:04:35*fowl joined #nimrod
02:27:16*flaviu quit (Remote host closed the connection)
02:56:48*xenagi quit (Read error: Connection reset by peer)
03:14:54*brson quit (Ping timeout: 240 seconds)
04:19:31*superfunc joined #nimrod
04:44:45Skrylaroh piss
04:44:56Skrylari've been putting the 'importc' call in the wrong side for it to work on structs
05:02:02fowlthere are 2 places it can go
05:11:37*isenmann joined #nimrod
05:13:04*isenmann left #nimrod (#nimrod)
05:32:21Skrylarfowl: it doesn't work if you do foo = object {.importc}
05:32:26Skrylarfoo {.importc} = object does
06:01:05*Demos quit (Read error: Connection reset by peer)
06:49:25*boydgreenfield quit (Quit: boydgreenfield)
07:01:47*Jesin quit (Ping timeout: 250 seconds)
07:02:10*superfunc quit (Quit: Page closed)
07:27:42*q66 joined #nimrod
07:27:42*q66 quit (Changing host)
07:27:42*q66 joined #nimrod
07:57:44Skrylardiscovery: when a module is boring as bricks to write, you designed it poorly
08:12:53*BitPuffin quit (Ping timeout: 264 seconds)
08:25:15*io2 joined #nimrod
08:46:29SkrylarAraq: nimrod needs a call/cc equivalent :o
08:48:18*chemist69 joined #nimrod
08:49:55AraqSkrylar: iirc "one-shot continuations" are as expressive but cheaper to implement
08:53:14*BitPuffin joined #nimrod
09:02:15*noam quit (Quit: Leaving)
09:15:49NimBotAraq/Nimrod new_spawn 6195dbe Araq [+4 ±12 -0]: initial non-compiling version of 'parallel'
09:23:49SkrylarAraq: i was just trying to lazy out of having to make one extra pointer
09:25:06SkrylarI learned how badly my image API sucked when trying to add jpeg support to it; now I redesigned it to suck less.
09:34:10Araqnow put it on babel please
09:34:44Skrylarit doesn't work
09:34:57Skrylaryou want APIs that don't have implementations on babel :P
09:44:08Araqbbl
10:26:19*Mat3 joined #nimrod
10:26:27Mat3good evening
10:37:14*BitPuffin quit (Ping timeout: 240 seconds)
10:38:04*kunev joined #nimrod
10:46:14*BitPuffin joined #nimrod
11:44:01Araqhi Mat3
11:44:12Mat3hi Araq
11:49:57Mat3what's new ?
11:53:03AraqI've written a thraad pool that adapts to the current CPU usage, no manual static tweaking of the thread pool size
11:53:13Araqnecessary
11:53:30AraqI need to test it much better though ;-)
11:54:25Araqbut maybe Varriount likes to do that? ;-)
12:02:12Mat3I think you mean a dynamic thread pool
12:04:34*Skrylar quit (Read error: Connection reset by peer)
12:05:36*Skrylar joined #nimrod
12:07:07Araqwho knows if these things have standardized names
12:21:17Mat3anyhow; It's an useful feature
13:11:22*darkf quit (Quit: Leaving)
13:30:34*Johz joined #nimrod
13:38:34Skrylararghs
13:38:51Skrylarso apparently if you don't want to load a PNG in one pass, pain ensues
13:39:46Mat3ciao
13:39:49*Mat3 quit (Quit: Verlassend)
13:40:43*Johz quit (Quit: Leaving)
14:59:18*Jesin joined #nimrod
15:12:13*kunev quit (Quit: leaving)
15:21:25*bjz quit (Ping timeout: 250 seconds)
15:51:19*CarpNet joined #nimrod
15:51:37*CarpNet left #nimrod (#nimrod)
16:03:49*untitaker quit (Ping timeout: 252 seconds)
16:05:18*seertaak joined #nimrod
16:05:59seertaakhi all, I asked this question a yesterday, but a bit early :)
16:06:59seertaakI saw a discussion in the nimrod forum in which Araq proposed to remove case-insensitivity of identifiers, and to use camelCase for vars and PascalCase for types. What's the status of this proposal?
16:07:57seertaakI must profess to finding the whole TSomeType business a bit ugly, but I recognize that some people seem to like ultimate flexibility in naming convention :)
16:09:18*untitaker joined #nimrod
16:32:47*Jehan_ joined #nimrod
16:33:46seertaakhi are there any nimrod experts around?
16:33:57Jehan_Depends on what you mean by expert. :)
16:34:27Jehan_Hmm, just looking at your question regarding case sensitivity.
16:34:34seertaakyeah, that's the question :)
16:34:38Jehan_There are actually two different issues involved.
16:35:04Jehan_The T/P prefixes are supposed to go (while, at least temporarily, keeping the old type names around as aliases).
16:35:15seertaakfor practical purposes: I'm just starting with nimrod, and I'm just wondering if I should use the T prefixes
16:35:21Jehan_However, that does not affect case sensitivity.
16:35:28Jehan_seertaak: That's up to you.
16:35:37Jehan_Personally, I don't use them in my code.
16:36:12seertaakok, so then it's up to the programmer to make sure type names don't collide with variable names
16:36:42seertaaki.e. so e.g. creating a type with name Id is probably a bad idea
16:36:57Jehan_My convention is generally (let's say for a stack type): call the module "stacks" (i.e., the plural), the type "Stack", and if I need to distinguish a value/ref type, call that type "StackObj" or "StackRef".
16:36:59seertaaksince it's likely to be used as a variable also
16:37:23Jehan_Well, names (aside from temporary variables) should have understandable names.
16:37:33Jehan_Ruby went from id to object_id eventually, for example.
16:38:17seertaakok, thanks for the suggestions
16:38:32*brson joined #nimrod
16:39:02seertaakalthough personally I think "id" is about as clear an identifier as you can get :)
16:39:23Jehan_Well, even if it's clear, it's just too likely to be reused.
16:39:24seertaakand anyway, regarding ruby, wouldn't it always be accessed as object.id
16:39:46Jehan_No, you do 1.object_id or "foo".object_id.
16:40:14seertaakok, Jehan_ thanks!
16:40:29Jehan_The problem is, id was essentially a keyword in all but name and it was difficult to reuse it.
16:41:28seertaakwell, all I can say is that I write c++ for a living and regularly use id as an identifier -- have yet to encounter any problems with collision :)
16:41:57seertaakbut I don't want to start a holy war on variable naming... when in rome and all that
16:42:11Jehan_That's why C++ has foo_ variables all over the place. :)
16:42:45Jehan_Oh, I do understand your preferences. The thing is, there are always tradeoffs.
16:43:56Jehan_Personally, I just go with whatever convention a language uses, unless it's totally broken. :)
16:44:31seertaakexactly :) and in C++ I'm lead to a kind of literate style of naming where the namespace adds meaning and disambiguation, allowing the class/method name to be quite short
16:45:20seertaakanyway, back to tinkering with nimrod... on today's menu: templates to generate objective-c classes :)
16:45:41Jehan_Have fun with that. :)
16:55:03*flaviu joined #nimrod
16:55:10*Jehan_ quit (Quit: Leaving)
17:00:18*BitPuffin quit (Ping timeout: 240 seconds)
17:06:12*Demos joined #nimrod
17:16:46*Matthias247 joined #nimrod
17:16:49reactormonkseertaak, the next step is cs:partial, which means first character only.
17:18:43EXetoCis that set in stone then?
17:19:55reactormonknot sure
17:27:40flaviureactormonk: I'm user60561, I can't think of a better name though. Also, 15 people on stack overflow upvoted, which is awesome.
17:31:01*DAddYE joined #nimrod
17:34:48*seertaak quit (Ping timeout: 240 seconds)
17:41:35*chemist69 quit (Quit: leaving)
17:47:07*BitPuffin joined #nimrod
17:53:06*seertaak joined #nimrod
17:58:19seertaakreactormonk: thanks for info
17:58:30seertaakI'd personally prefer case-sensitive
17:58:54seertaakbut first character allows type/instance disambiguation so that's already useful
18:01:08VarriountMeep
18:03:28*askatasuna joined #nimrod
18:08:23Araqping Varriount
18:08:33VarriountHi Araq
18:08:50Araqwanna write tests for threadpool.nim?
18:08:59Araq(already found a bug ;-) )
18:09:28VarriountEh, I'd like to finish what I'm working on currently.
18:14:42Araqwhat is that again?
18:15:43Varriountcross platform file change monitoring
18:15:52seertaakhi, I have two .nim files. one is called objcapi.nim, and defines (but does not export) proc myImpl(...) . the other, objc.nim, also defines (but does not export) proc myImpl. attempting to compile causes duplicate symbol error message. is that expected?
18:16:35seertaakoh yeah should mention that objc.nim imports objcapi.nim, but that's prob obvious
18:16:49Varriountseertaak: Are you using an include directive, or an import directive
18:17:19seertaakI'm doing: import objcapi as objc
18:17:30seertaakfrom objc.nim
18:18:27Varriountseertaak: I don't suppose you could gist your two files?
18:18:49seertaakerr... yes, but may take a second -- have never gisted before
18:18:55Varriountseertaak: gist.github.com
18:19:16flaviujust paste and come up with a name. really nice and easy
18:19:26Varriountseertaak: If both procs have the same signature - the same name and parameter types - then the compiler won
18:19:35seertaakhttps://gist.github.com/zenAudio/67006968d584fe9ca8a7
18:19:42Varriount*won't know which one to use when you call the procedure
18:20:34seertaakthat's a prob imo, because if I've declared the proc not to be exported, it should be in an anonymous namespace (to use C++ parlance!)
18:21:29seertaakif this is true, then I need to be careful about (unexported) proc names in library modules -- not ideal, or?
18:23:10Varriountseertaak: Hm. That is very odd
18:23:39Varriountseertaak: I was assuming that the error you got was from the nimrod compiler, not the C compiler
18:24:13VarriountOh, here's why. You've exportc'd both of your procs
18:24:13seertaaksorry should have mentioned it was after compilation and during linking of object files
18:24:55seertaakoh i see
18:24:57Varriountexportc uses the procedure name as the exported symbol if no other string is given.
18:25:03seertaakthat totally makes sense
18:25:34seertaakmy bad. I guess the way to do it is to have one carefully named {.exportc.} method which can call an arbitrary proc.
18:25:39seertaakthanks for help!
18:25:58Varriountseertaak: You can also have formatting symbols in the exportc pragma
18:26:06EXetoCgithub has nimrod highlighting, in case you didn't know that
18:26:48seertaakEXetoC: yes was aware, not sure how to use and wanted to do it quick :) but will check it out
18:27:03seertaakVarriount: what do you mean?
18:28:03Varriountseertaak: ' {exportc: "nimrtl_$1"} ' will, when used to export a procedure named "findString", generate an exported symbol "nimrtl_findString"
18:28:22seertaakoh, nice!
18:28:49VarriountThat pattern is used throughout the standard library to export the runtime and os procedures.
18:29:03flaviuseertaak: I think it should be reported as a bug anyway
18:30:15milosnhmmm if i want to wrote a 'setter' method ... should i do it on a type or on a pointer to that type?
18:30:27milosnon TMyType or PMyType
18:30:48milosnive just noticed it dont work when i did it on PMyType
18:32:08milosnhmmm lets try on TMyType :P
18:32:15EXetoCit does work for value types, but you have to dereference first
18:32:26milosnpointer should only point to real type
18:32:48EXetoCand pointers can often be dereferenced implicitly
18:33:42seertaakflavius: added issue #1194
18:36:17EXetoCbut not in this case apparently
18:36:58milosn?
18:37:36milosnEXetoC: can you give me an example of simple setter proc on a pointer type?
18:38:16milosnive just tried making it proc on an underlying real type, it gives me an error
18:38:25milosnc3/domains.nim(58, 5) Error: for a 'var' type a variable needs to be passed
18:39:27*CARAM quit (Read error: Connection reset by peer)
18:39:32milosnhmmm
18:39:33EXetoCvar implies possible modifications, and a parameter declared without 'var' or a variable declared with 'let' won't work in this case
18:40:40milosnhmmm i think its because i just define my type and pointer type, and than i have init proc for pointer
18:40:40*CARAM_ joined #nimrod
18:40:52milosnwithout init proc for the type itself
18:40:54EXetoCand you don't need 'var' in other cases. the compiler will decide whether or not passing in a hidden reference will be faster
18:41:10milosnhmmm
18:41:23milosnand making a setter proc on pointer type dont work
18:41:30flaviuIs there something like {.emit.} but for type names?
18:41:32EXetoCI'll try that
18:42:25milosnplease do, if i can make it work ... i can have "limmited" update()-s for my ORM :)
18:42:41milosnwhere only fields which have been updated are included in resulting SQL
18:42:42milosn:D
18:43:17milosnnow update() gathers all values from all fields and updates whole record in DB
18:43:44milosnbetter to spend some time on CPU and distinguish what actually got changed than hitting the hard disk :)
18:43:49EXetoCit does work for 'ref' though. you need to dereference ptr's yourself
18:44:05milosncan i have simple example on pastie?
18:44:39milosnlike pretty please :D
18:44:40EXetoCI might've been bitten by type inference
18:44:42EXetoCsure
18:52:29seertaakdoes nimrod have any facilities for reflection?
18:53:07milosnseertaak: there is typeinfo
18:53:16milosnbut its a bit cryptic for me :)
18:53:24*milosn did things the "hard way"
18:53:56seertaakmilosn: cool, thanks!
18:53:57milosnseertaak: module index, typeinfo
18:54:10EXetoCsee marshal.nim for typeinfo in action
18:55:12milosnEXetoC: knowing what typeinfo can do and marshal.nim ... you think one could make ZODB style object store for nimrod?
18:55:25milosnor lighwight version, like durus
18:55:36milosn(both are python)
18:55:55seertaakEXetoC: thx
18:56:45flaviumilosn: There's only compile-time reflection
18:57:14flaviubut you can save the shape of the types at compile time and do whatever you'd like with them.
18:59:05EXetoCmilosn, https://gist.github.com/EXetoC/7956c00a787da7e074a0
18:59:47EXetoCusually you don't need to mix values and pointers of the same type, which simplifies things
19:00:51flaviumilosn: Sorry, I'm wrong, you can do it without macros. I'd probably still do it with macros since they're neat
19:02:11milosnEXetoC: not sure what you made there ... this is what i try to do: http://pastie.org/9169433
19:02:12EXetoCx.y can be used for actual field accesses, but not for getters. might be by design
19:02:45milosnand o.do_id = 1223 ... dont update the dirty_updated seq
19:02:57milosnwhere o is pointer
19:03:38EXetoCit should
19:04:06milosnit compiles, but dont seem to work
19:04:16milosnlet me dig a bit, maybe i have a fail someplace else
19:04:27EXetoCmaybe the actual field is accessed instead. add an echo
19:06:01milosnhmmm
19:06:05milosnnot sure
19:06:28EXetoCI'd rename the field if that's the case. It won't matter in other modules though if the do_id field isn't exported (do_id*: type rather than do_id: type)
19:06:33*noam joined #nimrod
19:07:39milosnEXetoC: what you mean its not important if its exported?
19:07:45milosni need access to it :)
19:07:54milosnthis is how it works: http://pastie.org/9164177
19:08:04milosnupdate() is not there, still working on it
19:08:05milosn:D
19:09:02milosnits the port of my ORM for python, just done in nimrod
19:09:38milosnoriginally inspired by worst ORM of all ORMS ... DB_DataObject for PHP :)
19:11:03EXetoCmilosn, export means public. is do_id invoked from the module that defines PDomain?
19:11:13*brson quit (Ping timeout: 245 seconds)
19:11:27milosnit should be invoked from anyplace
19:12:15milosnfor example you set it value INT_SKIP and do an insert() ... viola, you duplicated the record :P
19:12:16EXetoCwell, figure out if it's the field that's being accessed. perhaps you want to remove the * attached to it, if there is one
19:12:31milosnno, all fields need to be accessible
19:13:12milosnfrom every where ... you think thats why it dont work?
19:14:31milosnwell in worst case, if i dont figure it out ... we shall have full blown hard-disk-destrying update() :P
19:14:40EXetoCpossibly. find out by printing in the setter
19:15:05milosnmaybe i need to de-ref o in the setter?
19:15:07milosnhmmm
19:15:16milosnill try echo-ing stuff
19:17:54EXetoCit is already being dereferenced (implicitly). you'd get an error otherwise
19:18:27milosnyeah it dont work
19:18:29milosnhmmm
19:18:31milosnstrange
19:18:36EXetoCnothing is printed?
19:19:18milosntrying that now, i tried de-refing
19:19:52EXetoCwell, the proc takes a pointer already, assuming that the type name doesn't lie
19:21:13EXetoCI'd rename either of those.
19:21:45milosnhmmm echo() in setter ... dont get echoed
19:21:51milosnits not going in there at all
19:22:49milosndo i need {.inline.} pragma like in example in tutorial?
19:22:50milosn?
19:23:01EXetoCno
19:23:20EXetoCso rename the setter and try again
19:24:19milosnrename it to be something other than the field name?
19:24:21EXetoCand then modify the lines that invoke it of course. something should indeed be printed, assuming that it does compile
19:24:23EXetoCyes
19:25:14milosnummm thats not gonna work, the code is auto-generated, and basically you should be able to access the fields as you are working with the DB rows
19:25:20milosnill try so we can nail it down
19:26:33Araqer flaviu how can we fix this bug? the user explicitly requested both procs should gain the same C identifier ...
19:27:09flaviuAraq: Do you have a link?
19:27:14Araqwe can reject it at the expense of a huge global dictionary that re-implements what the linker checks... yay
19:27:44milosnEXetoC: renaming the setter works ... but thats not the fix i need :)
19:28:00milosnso setters with same name as a field dont work
19:28:02milosnhmmm
19:28:06EXetoCusually you don't want to export both, and for good reasons
19:28:35milosnEXetoC: if i dont export the field, it cant be read not written?
19:28:56EXetoC`do_id=` implies a write
19:29:01Araqseertaak [19:33:42] flaviu: added issue #1194
19:29:43EXetoC"proc do_id(o: Type): typeToReturn" would be the getter.
19:29:45flaviuAraq: No, the user who wanted the two procs to have the same id
19:30:08seertaakAraq: is there a problem with the issue submission?
19:30:47milosnEXetoC: ahhhh
19:30:50seertaakSorry, didn't read context.
19:31:17milosnEXetoC: thats the solution, fields will be private, and i have getter/setter combo same as field names
19:31:29milosnEXetoC: genious :)
19:31:31flaviuThe guy who wanted the procs to be the same should use exportc since his case is more special than seertaak's.
19:31:41EXetoCyeah, and you can of course choose what combination to support
19:32:04Araqflaviu: the gist has 2 proc myImpl(...) {.exportc.}
19:32:14Araqthe compiler does what it is told
19:32:21EXetoCmilosn, I don't know about that. everyone does it :p it's very simple in nimrod though
19:32:36milosnEXetoC: hmmm this is cool, i could make "access profiling" like in one ORM i seen in java, it profiles the fields you are actually using in your objects and generates "smarter" select queries
19:32:40milosnhmm cool
19:32:55fowlwow they are putting damian conways quantum::superpositions in perl6 http://en.wikipedia.org/wiki/Perl_6#Junctions
19:33:11seertaakAraq: what is not expected is that that in both cases the method was not exported
19:33:14EXetoCmilosn, sounds good
19:33:23EXetoCbtw, is PDomain a ref or a ptr?
19:33:33seertaakFrom a "user" point of view, it is suboptimal that a non-exported proc leaks out
19:33:40milosnEXetoC: dont have time to do that ATM, thats not hight on pri list
19:33:45milosnEXetoC: umm let me see
19:33:46seertaakbut I understand the caveat that this is because I'm doing low-level stuff with exportc
19:33:54EXetoCusually you want a reference
19:33:58Araqseertaak: so? *exportc* does exactly what the docs say it does
19:33:59milosnEXetoC: its a ref
19:34:03EXetoCright
19:34:04milosntraced one?
19:34:10seertaakyes, hence my caveat :)
19:34:22milosni want one that can be garbage collected
19:34:27milosnhope i picked the right one
19:34:31EXetoCyes
19:34:34seertaakfeel free to delete the issue if you like! :)
19:34:48seertaakdidn't want to cause problems
19:34:53flaviuAraq: Oh, I see, I thought it wasn't exported at all. If he's using exportc, I don't think its the compiler's job to figure it out.
19:34:57EXetoCptr requires manual freeing
19:35:09Araqflaviu: alright, closing it then
19:35:51EXetoCmilosn, this overload takes a finalizer (destructor) proc: "proc new*[T](a: var ref T, finalizer: proc (x: ref T) {.nimcall.})"
19:36:53*dymk quit (Quit: ZNC - http://znc.in)
19:37:55*dymk joined #nimrod
19:37:56EXetoCAraq, do full collects make any guarantees regarding finalizing?
19:38:42Araqno, they don't guarantee anything, they can't
19:38:56Araqthe stack is scanned conservatively
19:39:33Araqhence they don't even guarantee everything that is unreachable is GC'ed
19:42:00milosnEXetoC: thats works like magic (with set/get and private field)
19:42:03milosncool thanks
19:43:11EXetoCok. I can't remember if destructors were unreliable. maybe only for vars declared in the module scope
19:44:09EXetoCin addition to never being invoked in some cases of course
19:44:14EXetoCmilosn, np
19:48:13*Mat3 joined #nimrod
19:48:17Mat3hello
19:49:16Araqservus, Mat3
19:50:16EXetoCyeah, probably just the module scope. should destructors work there?
19:51:19EXetoCtdestructor.nim has destructible contexts only inside procs
19:55:50AraqIMO no, they shouldn't
19:56:12Araqit's hard to support, produces code bloat and is most often unnecessary
19:56:34Araqoohh, lets close the sockets before the OS does that too
20:06:38*brson joined #nimrod
20:24:55VarriountHm. Does Unix/Linux/Posix support "locking" a file, to prevent read/write/deletion of the file?
20:29:19EXetoCpermissions?
20:29:27*flaviu1 joined #nimrod
20:29:44VarriountEXetoC: I mean, on a temporary basis.
20:30:19*flaviu quit (Ping timeout: 240 seconds)
20:30:50VarriountAs in, if a program opens a file on those platforms, can it prevent other programs from modifying the file, so that it can write to the file without fear of race conditions.
20:31:36flaviu1Varriount: http://man7.org/linux/man-pages/man2/open.2.html
20:31:37skrollVarriount: it's filesystem dependent
20:36:46flaviu1Varriount: Sorry, while that explains everything about files, http://man7.org/linux/man-pages/man2/flock.2.html is what you actually call
20:37:39Varriountflaviu1: Is that just for linux, or posix in general?
20:38:42fowlwhat am i doing wrong here :/ https://gist.github.com/fowlmouth/6fce784b3ea3e7a967d3
20:39:15skrollVarriount: keep in mind that locks are generally advisory unless you mount your filesystem to have mandatory locks. in other words, by default, unless other processes are explicitly checking for locks, they won't care if it's locked or not.
20:39:33flaviu1Varriount: http://anselmo.homeunix.net/ebooks/linuxkernel2/083.htm Seems that mostly everything will implement flock(), but the official posix call is fcntl()
20:39:57Araqfowl: only zahary can help you with this
20:48:41EXetoCthe feature is still pretty unusable
20:48:50Varriount"Only zahary can save you now"
20:49:45EXetoCI might be able to get my container type class to work though, but then I have to omit var in the signatures, and instead introduce temporaries
20:50:24EXetoCeh no. it's likely that the compiler will copy. maybe with a dummy object that contains a reference
20:51:00EXetoCI have about 2 open UDTC issues
20:51:27*BitPuffi1 joined #nimrod
20:51:56*BitPuffi1 quit (Client Quit)
20:52:14*BitPuffi1 joined #nimrod
20:53:18*BitPuffin quit (Ping timeout: 245 seconds)
20:54:44VarriountSpeaking of which, when was zahary last on?
20:54:51VarriountI mean, like, active.
20:55:12dom96!seen zahary
20:55:13NimBotzahary was last seen on Mon May 12 02:48:25 2014 joining #nimbuild
20:55:32dom96That's not really useful heh
20:55:46dom96he was active on github 3 days ago
20:56:43EXetoChe's very busy apparently
20:57:06EXetoCwith running a company or something
21:12:17dom96I wish I was busy with running a company
21:12:25dom96instead of having to deal with exams
21:16:00*snuffeluffegus joined #nimrod
21:16:17dom96hi snuffeluffegus
21:17:42Matthias247dom96: I guess exams are easier ;) But unfortunatly don't bring you any money
21:19:48dom96True. Running your own company may also not bring in any money though. Perhaps I should be careful what I wish for heh.
21:21:24*snuffeluffegus quit (Quit: Leaving)
21:22:40*hoverbear joined #nimrod
21:22:47Matthias247that's true. I'm still struggling with what-to-do if I would have an own company ;)
21:22:49hoverbearAraq: It's you!
21:25:35*OrionPK quit (Remote host closed the connection)
21:25:40Araqhi hoverbear wb
21:26:01dom96hoverbear: welcome back! It's been a long time!
21:26:19hoverbearI came looking for a mongodb driver and a web framework. *looks ashamed*
21:26:39*Varriount wonders who hoverbear is, and wonders if he will continue to hover.
21:26:53hoverbearVarriount: I'm an adept hoverer. Want to learn?
21:27:42EXetoChoverbear, https://github.com/dom96/jester (web framework)
21:28:27reactormonkhoverbear, following the nonsql hype? ^^
21:28:39EXetoCwe do have an incomplete mongodb interface, which relies on the old API. I've been working on a rewrite that doesn't use the legacy C driver. it should be in a usable state soon
21:28:58hoverbearreactormonk: No I need to query a database. :S
21:29:04Mat3nonsql hype ?
21:29:06hoverbearEXetoC: Thanks!
21:29:06reactormonkhuh?
21:29:45hoverbearreactormonk: I think Mongodb sucks, I need to interface with it, not like it. :_p
21:29:52reactormonkhoverbear, so be it
21:30:04EXetoCMat3, yes, the recent increase in popularity for non-SQL database engines
21:30:34Mat3well, dbase was a nice database
21:31:48*seertaak quit (Ping timeout: 240 seconds)
21:33:01EXetoChoverbear, what do you need? there are things such as gridfs which I haven't touched yet
21:33:22hoverbearEXetoC: It's already in mongoDB, that's not an option :(
21:33:46Mat3EXetoC: but I suspect, this trend has more to do with web based search libraries which somehow can be misused for database alike applications
21:34:02EXetoCwhat do you mean? I'll implement as much as possible, but I'll prioritize the basic operations
21:34:10EXetoC*core
21:34:31EXetoCMat3, ok. maybe
21:49:47hoverbeardom96: How have you been?
21:51:03dom96hoverbear: pretty good. You? Are you going to stick around this time? :P
21:51:57hoverbeardom96: Want to try Nimrod some more. :)
21:52:24hoverbeardom96: Been digging at Rust lately.
21:52:44dom96hoverbear: Out of curiosity, what made you come back?
21:53:58hoverbeardom96: Google didn't have any results for a mongodb driver for Nimrod xD
21:56:07flaviu1Is there any way to not use system.nim?
21:56:21EXetoCyou want to be able to do nothing at all? :>
21:56:31EXetoChoverbear, does too :p
21:56:39hoverbearIt's true
21:56:54flaviu1EXetoC: I want my own system.nim, with hookers and blackjack :P
21:57:36EXetoChoverbear, "nimrod mongo"?
21:57:47dom96flaviu1: Closest thing is --os:standalone I think.
21:57:57hoverbearEXetoC: https://www.google.ca/search?q=nimrod+mongodb&oq=nimrod+mongodb&aqs=chrome.0.69i59.2070j0j7&sourceid=chrome&es_sm=91&ie=UTF-8
21:58:06flaviu1Doesn't work, fails to compile
21:58:24flaviu1I'll just lobotomize the regular system.nim then
21:58:33hoverbearIcepicks work nice
21:58:40EXetoChoverbear, right. I need a readme
21:58:56EXetoCso as to add some relevant keywords
21:59:03hoverbearYup!
21:59:12hoverbearEXetoC: Would love to take a look
21:59:35dom96flaviu1: Really? with what error?
21:59:51flaviu1Error: cannot open 'panicoverride'
21:59:52EXetoCI'll try to release something tomorrow
22:00:08Araqflaviu1: yes. that's a feature.
22:00:23dom96flaviu1: Yeah, you need to create that file.
22:00:28EXetoChoverbear, so do you need anything other than the core features? I wouldn't consider gridfs one for example
22:00:36dom96flaviu1: Example here: https://github.com/dom96/nimkernel/blob/master/panicoverride.nim
22:00:38EXetoCupdate, insert, find etc should be prioritized of course
22:01:18flaviu1I'll worry about that later, I've already cut everything out of system.nim except string, char, and int
22:01:20hoverbearEXetoC: At the moment I just want to see what the syntax is like and play around with `find`
22:01:24flaviu1Thanks though
22:02:10dom96flaviu1: Why do you want a custom system.nim?
22:02:10EXetoCok
22:02:36flaviu1dom96: To prove you can get by without magic
22:03:06hoverbearflaviu1: #rust would love to speak with you
22:03:43flaviu1hoverbear: Why? Do they want that too?
22:04:00hoverbearflaviu1: The Rust folks are the most no-magic people I've ever met
22:04:50hoverbearhttp://jvns.ca/blog/2014/03/12/the-rust-os-story/
22:12:38flaviu1That's awesome, but rust still does magic to make integers work
22:13:18flaviu1hoverbear: Nimrod can do better
22:13:33hoverbearflaviu1: What do you mean?
22:13:59EXetoCit must do something to make them work
22:14:32EXetoCand when is that not magic?
22:15:16flaviu1Integers aren't magic, the only magic parts are keywords like `type` or `proc`. I'd like to get to a point where I can do `type int = {emit: "int8_t"}`
22:15:57EXetoCok
22:19:09*OrionPK joined #nimrod
22:19:17dom96good night
22:19:58milosnhmmm can i fork nimrod app proccess?
22:20:12*milosn cant find fork() anywhere
22:20:36EXetoCflaviu1, and when we get an ASM target? will it work then too=
22:21:54flaviu1EXetoC: I don't know assembler, but just define `when(asm): type int = {.emit: "asm stuff".}`
22:25:34flaviu1I don't see how assembler is a viable target for nimrod though
22:25:53skrollmight as well let the C compiler take care of it
22:28:50EXetoCyou either need a language like C++ or asm to minimize the overhead of setting up exception handlers
22:29:03EXetoCbut it's of minor significance of course
22:29:05flaviu1EXetoC: or llvm
22:33:42EXetoCyeah
22:33:52Mat3LLVM is basical just an IL representation which is compiled to native code. I do not see any advantage of using it against writing in assembler especially system-programming tasks like exception handling often is cpu dependent
22:34:31EXetoCdoesn't it do optimizations? perhaps it's nothing special
22:34:55EXetoCoh well if it cant generate optimized exception handling
22:35:19flaviu1Mat3: Have you seen LLVM IR? Its amazing! It lets you pass off the hard parts to the backend
22:35:56hoverbearflaviu1 \i/
22:36:31Mat3(with CPU dependance I mean special system registers not common avariable)
22:36:43flaviu1EXetoC: IR does absolutely nothing by itself, but LLVM has many optimization passes to make it better. It even will take care of zero-cost exception handling on Itanium. It isn't your problem anymore.
22:37:34EXetoCyeah well llvm takes care of all steps
22:37:56EXetoCall good then
22:38:07flaviu1You still have to do lambda manually
22:38:50flaviu1and if statements are uglier than C. It does optimize the if's loads and stores into phi nodes automatically though
22:39:41flaviu1And it figures out the best way to do accurate garbage collection too
22:40:19Mat3flaviul: It depend on the task
22:40:33Araqit also doesn't support efficient integer overflow checking, lacks OpenMP support, exception handling and GC stuff is barely documented
22:41:14Araqand doesn't provide a decent C wrapper
22:41:39Araqso everybody has to compile his own massive llvm DLLs and hope for the best
22:41:39Mat3in addition: LLVM compiles stack based code with really horrible result for x86
22:41:39EXetoCis the wrapper incomplete?
22:41:57AraqEXetoC: last time I checked it, yes
22:42:00flaviu1Araq: `llvm.s(add|sub|mul).with.overflow`
22:42:05hoverbearIsn't Nimrod a llvm language?
22:42:16EXetoCthe llvm target is unfinished
22:42:18flaviu1hoverbear: Nope, compiles to c
22:42:23Araqflaviu1: that's a recent addition then ...
22:42:26flaviu1EXetoC: Its started?
22:43:37EXetoCa long time ago. didnt get far I think
22:44:32Mat3flaviul: My point is LLVM can't support CPU dependent features like architecture dependent watchdog timers for example because it is a *general* kind of CPU abstraction. That make this compiler of limited use for some system-programming tasks
22:44:53flaviu1Mat3: LLVM allows direct assembler output
22:45:22Mat3yes, but for such usages you must patch these output so its easier to write directly in assembler
22:46:14flaviu1Mat3: I don't understand, can you phrase that differently?
22:47:13*askatasuna quit (Ping timeout: 276 seconds)
22:47:52Mat3try accessing a AMD specific debug register with LLVM (you can't)
22:48:09flaviu1Araq: LLVM has changed a lot, GC has decent docs: http://llvm.org/docs/GarbageCollection.html , as do exceptions http://llvm.org/docs/ExceptionHandling.html
22:49:04Mat3I see. We are talking about different types of exception handlers
22:49:38*Matthias247 quit (Read error: Connection reset by peer)
22:52:23*xenagi joined #nimrod
22:53:23Mat3ciao
22:53:30*Mat3 quit (Quit: Verlassend)
23:02:23EXetoCdunno what he meant
23:02:25EXetoCcpu flags maybe
23:04:47AraqI think he meant interrupts
23:09:58*darkf joined #nimrod
23:12:19flaviu1It lives: https://gist.github.com/flaviut/7e5332df1ea9929b9438
23:12:40flaviu1Araq: I can do arithmetic without any magic
23:13:29Araqat compile time? ;-)
23:13:55EXetoCmetaprogramming is overrated :>
23:14:02flaviu1The c code contains some `return a; return result;`, but who cares.
23:14:50flaviu1Araq: I don't understand what you're saying
23:15:16EXetoCas in using it at compile time
23:15:32EXetoC(vm)
23:15:54flaviu1With some work, (ok, a lot) the emit pragma can support outputting ASTs
23:16:39flaviu1Then just hide everything behind a `when vm: include vmints`
23:22:33*io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist)
23:22:34Araqflaviu1: yeah but it is lots of work and I fail to see the advantage of your appraoch
23:23:12*Varriount_ joined #nimrod
23:25:02*boydgreenfield joined #nimrod
23:25:29*Varriount quit (Ping timeout: 264 seconds)
23:27:11Araqgood night
23:27:25flaviu1I like the idea of everything being done in the library. It leads to fewer corner cases in the compiler.
23:27:25flaviu1Night
23:33:16*hoverbear quit ()
23:46:10Varriount_flaviu1: What do you mean?
23:46:15*Varriount_ is now known as Varriount
23:47:52flaviu1Varriount: What I said was different from what I thought, the standard library declares the things with magic, but the compiler provides the implementation.
23:48:23flaviu1s/ht, th/ht; what I mean is that the/
23:51:25flaviu1It also puts limits on the extensibilty of the language. If everything is done without magic, that demonstrates that the language does not restrict you in any way, even if what you want to do is boneheaded
23:57:33*q66 quit (Quit: Leaving)