<<10-01-2013>>

---

00:19:00	*	q66 quit (Quit: Quit)
06:14:06	*	silven_ joined #nimrod
06:14:59	*	silven quit (Ping timeout: 260 seconds)
06:37:34	reactormonk	any way to use xpath with nimrod? Or just tarzan through the xml with code.
06:42:12	reactormonk	http://sprunge.us/ZVaG :-/
07:26:49	*	reactormonk quit (Changing host)
07:26:49	*	reactormonk joined #nimrod
07:51:56	reactormonk	how do I pass around a longlong?
07:52:28	fowl	reactormonk: i think the type is clonglong but check the docs for system.nim
07:52:43	reactormonk	well, target is JS
07:52:53	reactormonk	so an int should do fine :-/
09:10:42	*	Trix[a]r_za is now known as Trixar_za
11:02:56	*	Trixar_za is now known as Trix[a]r_za
11:41:15	*	Araq is now known as Araq_win
11:44:59	*	Araq_win is now known as Araq
14:17:36	*	q66 joined #nimrod
16:25:55	dom96	Yay. They might finally merge the linguist pull request.
17:38:19	Araq	dom96: was about time ;-)
17:38:27	dom96	indeed
17:38:50	dom96	See? They still care :)
17:39:07	Araq	we'll see
18:01:59	*	Amrykid quit (*.net *.split)
18:02:27	*	Amrykid joined #nimrod
18:30:54	Araq	ping zahary
18:45:43	Araq	so ... now that nimbuild supports branches, we maybe should change our workflow
18:46:05	Araq	my idea is to use a 'devel' branch and apply every change there first
18:46:27	Araq	and when the test results didn't change, I merge the changes into master
18:46:54	Araq	effectively this means 'master' will be the latest stable version
18:47:14	Araq	people treat it as such already anyway
18:47:30	dom96	Sounds good. But which branch should contributions go to then?
18:48:25	dom96	Even if we tell people to create pull requests to the devel branch they will most likely ignore that anyway :P
18:48:53	dom96	I was planning on making nimbuild test the pull requests
18:49:32	dom96	That's a fair bit of work though. I would also like to migrate to mongodb before doing that.
18:50:38	Araq	testing pull requests seems like a bad idea
18:51:02	Araq	people can than OoS our builders ;-)
18:51:13	Araq	*then DoS attach
18:51:17	Araq	*attack
18:51:19	Araq	arg
18:51:34	Araq	and it wastes resources
18:51:56	dom96	True. But travis-ci manages it.
18:52:05	dom96	And rate limiting isn't that hard to implement.
18:52:16	Araq	hrm true
18:52:22	dom96	Also i'm planning to do some fancy checking of what files were changed
18:52:44	dom96	The compiler sources will rarely be changed, so there is no need to bootstrap every time.
18:52:47	Araq	what's wrong with redis? how's mongo better for nimbuild?
18:53:04	Araq	but the compiler uses the stdlib
18:53:18	Araq	so you can rarely avoid bootstrapping
18:53:44	dom96	well that sucks a bit then :\
18:54:04	dom96	it's hard to query for the data in redis
18:55:22	Araq	it's hard to query for the data in mongo too
18:55:46	Araq	these nosql databases don't get the "query language" part
18:56:14	dom96	well I will play around with mongodb first
18:56:21	Araq	mongo uses javascript as a query language
18:56:56	dom96	That doesn't seem too bad.
18:57:34	Araq	it only works for trivial queries
18:58:27	dom96	perhaps I will continue to use redis and simply redesign the data layout a bit.
18:58:52	dom96	When I first designed it, I didn't not think about future branch support.
18:59:05	dom96	s/didn't/did/
18:59:17	Araq	he he
18:59:29	*	dom96 punches brain
18:59:55	dom96	But anyway, back to the original topic.
19:00:10	dom96	How do other projects do it?
19:01:16	Araq	dunno
19:01:45	dom96	http://nvie.com/posts/a-successful-git-branching-model/
19:02:01	dom96	I think that model is quite popular.
19:04:35	Araq	so master only contains release versions?
19:04:51	dom96	yeah, I guess that's a bit meh.
19:06:48	dom96	hrm. I guess even if we decide that whatever we use for now is bad we can always easily change the model.
19:08:31	dom96	Can't we?
19:08:53	Araq	yes but I think we should do it this way:
19:09:14	Araq	easy bugfixes with a slim chance to break anything -- directly in master
19:09:28	Araq	other bugfixes -- in a devel branch
19:09:51	Araq	new features -- in a per feature branch
19:10:50	Araq	breaking the language -- in a v0.9.x branch
19:11:38	dom96	I don't like the last one
19:12:55	dom96	vX.X.X should only be for tags
19:13:09	dom96	You can't have a branch and a tag with the same name.
19:13:21	Araq	oh yeah
19:13:35	Araq	well it's version0.9.x then or something
19:13:51	dom96	hrm, but why?
19:13:53	dom96	I don't get it.
19:14:30	Araq	well my idea is that 0.9.0 is released, so master should be as compatible with 0.9.0 as possible
19:14:43	Araq	until 0.9.2 is out
19:16:07	dom96	hrm. So then will you merge stuff from devel into your "broken language" branch and the master branch?
19:16:49	Araq	hrm devel is not the right name
19:17:04	Araq	devel is only temporary to push the changes to nimbuild
19:17:19	Araq	and then after the tests are green it'll go into master
19:17:35	dom96	I think it should simply be a feature branch then
19:17:50	dom96	the name doesn't really matter.
19:18:09	dom96	You have worked on a feature, or a fix, and you want to see if it breaks something.
19:18:22	dom96	If it does, you fix the breakage
19:18:24	dom96	retest
19:18:32	dom96	once it doesn't you merge to master
19:18:34	dom96	and delete the branch
19:20:40	dom96	Once we decide on a branching model please document it in the readme btw :P
19:20:55	dom96	or I can do it if you don't feel like it.
19:21:08	Araq	why does that belong into the readme?
19:21:24	dom96	So that potential contributors don't get confused
19:21:47	Araq	*shrug* alright
19:22:10	Araq	bbl
19:22:45	Araq	your idea of simply using a feature branch sounds good
19:22:51	Araq	keeps it simple
20:16:09	reactormonk	any way to use xpath with nimrod? Or just tarzan through the xml with code.
20:16:54	dom96	reactormonk: Currently no, sorry.
20:20:51	*	AlexLibman likes extensive use of man pages: `man nimrod`, `man nimrod-generics`, man nimrod-xmltree`, etc.
20:21:12	AlexLibman	s/ man/ \`man/
20:21:17	Araq	wake up, it's 2013 :P
20:21:30	Araq	nobody cares about man pages :P
20:21:30	AlexLibman	Err, s/, man/, \`man/
20:21:38	reactormonk	AlexLibman, well, you can teach the docgen to generate manpages
20:21:41	reactormonk	would help debian, too.
20:21:55	AlexLibman	OK, maybe you're right.
20:24:03	dom96	Someone should write a "Nimrod for Rubyists" in the style of http://www.rustforrubyists.com
20:24:13	dom96	or even better "Nimrod for Pythonners(?)"
20:24:34	reactormonk	dom96, let's see. I'm writing above code generator in ruby ;>
20:24:40	AlexLibman	Lots more pythoneers that rubyrats out there...
20:25:02	reactormonk	I can only speak about ruby.
20:25:08	AlexLibman	s/that/than/
20:25:43	dom96	Araq: So, are you going to push a new branch? I'm curious if nimbuild works :P
20:27:25	Araq	dom96: have no branch to create for now ...
20:27:48	dom96	ok, np.
20:58:49	reactormonk	there's only one numeric type in JS, right?
21:00:04	Araq	reactormonk: yeah but most implementations keep an integer-like number in an integer
21:00:16	Araq	it's totally transparent though
21:00:40	reactormonk	got a qulonglong here
21:01:25	Araq	what are you doing?
21:01:59	reactormonk	Araq, http://techbase.kde.org/Development/Tutorials/KWin/Scripting/API_4.9 via JS... ;>
21:02:33	reactormonk	It's madness
21:03:07	Araq	so your scripting a KDE app with JS compiled by Nimrod?
21:03:13	Araq	*you're
21:03:14	reactormonk	yes.
21:03:19	reactormonk	muahaha
21:03:25	Araq	write a blog post about it
21:03:55	reactormonk	Aye sir. But first I have to finish this ruby script which converts the doxygen XML to nimrod code.
21:04:20	Araq	what?
21:05:18	reactormonk	well, that webpage above is generated with some xslt. So I take the source XML generated by doxygen (API description) and got a ruby script to generate the bindings for nimrod (with a lot of importc)
21:06:04	reactormonk	Know a good blog host? Tumbl?
21:06:36	*	Araq is working on his own blog software ...
21:07:19	dom96	reactormonk: You could use jekyll + github pages
21:07:55	apotheon	reactormonk: Actually, there's one programmer-facing numeric type in JavaScript, but behind the scenes there are distinct types, and not knowing about how these things interact can cause problems. Yes, really.
21:08:33	Araq	like what?
21:10:18	apotheon	like IEEE rounding errors
21:10:34	apotheon	. . . on what you thought was integer math
21:10:53	reactormonk	apotheon, it's an id, so I could treat is as a sting as well
21:11:52	Araq	there are no IEEE rounding errors for floating point numbers that represent integers
21:12:05	Araq	ok, for integers in the 32 bit range at least
21:12:09	reactormonk	Araq, any idea how to implement getters/setters in nimrod for JS objects? The global object is a bit hairy there :-/
21:12:45	Araq	what's the global object? the one generated by the compiler?
21:12:53	reactormonk	nope, provided by the runtime
21:12:58	reactormonk	iirc it's 'workspace'
21:13:49	Araq	var workspace {.importc.}: X ?
21:14:07	reactormonk	and X is the type?
21:14:14	Araq	sure
21:14:33	reactormonk	Good.
21:16:36	reactormonk	Nope, workspace isn't the global object.
21:16:45	reactormonk	But that shouldn't matter much.
21:17:40	apotheon	Araq: Try floating point math that yields a fractional result with a rounding error that changes the result of integer truncation by one.
21:18:15	apotheon	Araq: . . . but you can't see what's happening because you're using the JavaScript Number "type".
21:18:48	reactormonk	Araq, can I define properties as read-only? Aka fields as read-only?
21:19:17	Araq	reactormonk: no
21:20:18	reactormonk	Araq, hm. Fuck it then.
21:23:31	Araq	provide an accessor proc instead for readonly access
21:23:49	Araq	apotheon: good point about the div operation
21:23:54	reactormonk	Araq, good idea.
21:24:14	apotheon	Araq: JavaScript's type system isn't just inconvenient. It's an abomination.
21:24:34	Araq	so Math.floor(x / y) is not good enough for 'div'?
21:25:53	apotheon	not in rare cases
21:26:11	apotheon	(where "rare" ends up meaning "especially surprising" sometimes)
21:27:21	Araq	well that's a bug in the JS codegen then :-)
21:27:31	Araq	sounds impossible to fix though
21:29:46	reactormonk	Araq, argh, it will be a fucking PITA to implement signals and slots
21:30:15	Araq	why?
21:31:19	reactormonk	oh, wait, the argstring is there \o/
21:31:54	reactormonk	http://sprunge.us/JEOO current generation.
21:32:31	reactormonk	I have no idea though how to attach the enums to e.g. workspace
21:32:36	Araq	btw how's the doc comment working?
21:32:55	Araq	that idetools provide?
21:35:21	Araq	reactormonk: I think you should use 'ref object' instead of 'object' here
21:35:35	reactormonk	why?
21:35:43	reactormonk	defskVarcreateTabLabel.boxPHBox/home/tass/dev/nimrod/Aporia/aporia.nim2949""
21:35:50	reactormonk	fucking IRC and tabs.
21:36:12	reactormonk	Araq, seems to work so far. except not much is documented here ;-)
21:36:28	Araq	because that's what JS's semantics are: it uses reference semantics for objects
21:41:29	*	Amrykid quit (Changing host)
21:41:29	*	Amrykid joined #nimrod
21:53:06	reactormonk	can I just write 'ref object'? Or do I have to jump through the Tfoo = object Pfoo = ref Tfoo hoop?
21:53:35	Araq	nowadays you can just write 'ref object'
21:53:43	reactormonk	\o/
22:10:50	reactormonk	AlexLibman, what about adding a clause that military usage is forbidden to BSD/GPL?
22:32:15	reactormonk	Ehm, what's the syntax for a proc that takes a proc?
22:32:35	Araq	proc p(q: proc (x: int): int)
22:35:31	reactormonk	Can I somehow hack this? API says: clientMaximizeSet(KWin::Client *client, bool h, bool v) code should look like: workspace.clientMaximizeSet.connect(function(client, h, v) {
22:35:41	reactormonk	observe the 'connect' part
22:36:32	reactormonk	template somehow?
22:37:18	Araq	hm
22:38:09	reactormonk	Also note that it gets ugly with typecheck if I have to add a fucking type for each :-/
22:38:37	Araq	what do you mean by that?
22:39:00	reactormonk	well, I have to provide connect to the name of the signal - and the signal has a type. So I have to create a type per signal
22:39:14	Araq	use a generic instead
22:39:48	reactormonk	Can a generic hold *args ?
22:39:52	reactormonk	or ... as you call it
22:40:25	Araq	I call it '...'?
22:40:35	reactormonk	varargs
22:41:15	Araq	proc p[T](y: varargs[T]) works but then they all need to be of the same type
22:41:33	Araq	however, p(y: varargs[expr]) should do what you want
22:41:54	Araq	that's a varargs of arbitrary types
22:43:08	reactormonk	Can't I directly emit code from the signal?
22:43:39	Araq	I can't follow
22:44:35	reactormonk	Well, the above generic basically dumps typecheck, right?
22:44:53	Araq	right
22:46:20	Araq	I'm implementing that 'importcpp' will be mapped to JS's a.f(x) syntax
22:46:55	Araq	'importcpp' may later be renamed to 'importInfix' or something
22:47:23	reactormonk	I'll go with signal %s*(callback: proc(%s)) for now and think on it later.
22:47:36	reactormonk	Maybe a template.
22:55:31	reactormonk	Araq, QVariant as union type - how do I deal with that in nimrod?
22:56:26	Araq	there is no such thing as a union in JS :P
22:56:49	*	Araq doesn't really get Qt's docs
22:57:12	Araq	pretend that the 'union' is an 'object' instead could work for your case
22:57:29	reactormonk	Araq, I _suppose_ you get either a string or an int or whatever back
22:58:12	Araq	pretend that the 'union' is an 'object' so that you can access all the fields in Nimrod
22:58:31	reactormonk	Hmm
23:01:02	reactormonk	bool registerShortcut(QString title, QString text, QString keySequence, QScriptValue callback)
23:01:05	reactormonk	fuck it.
23:01:43	Araq	writing a proper Qt wrapper may be the better option
23:01:51	Araq	depending on what you want to do
23:02:08	reactormonk	Well, I'd like to run it as JS so I can fuck with it on runtime
23:02:19	Araq	ok
23:02:38	reactormonk	I just take it that the callback doesn't get any arguments
23:02:44	reactormonk	JS is kinda forgiving there
23:03:46	reactormonk	callDBus(QString service, QString path, QString interface, QString method, QVariant arg..., QScriptValue callback = QScriptValue()): Call a D-Bus method at (service, path, interface and method). A variable number of arguments can be added to the method call. The D-Bus call is always performed in an async way invoking the callback provided as the last (optional) argument. The reply values of the D-Bus method
23:03:48	reactormonk	call are passed to the callback.
23:03:51	reactormonk	that's gonna be fun.
23:04:22	reactormonk	How are the nimrod semantics on varargs in the middle of a function argument?=
23:06:15	Araq	er ... ugh, use openArray[expr] and pass them in [] and except compiler bugs
23:06:24	Araq	*expect
23:06:55	Araq	these features have never been designed for misusing them in the JS target ...
23:07:12	reactormonk	How do I tell nimrod to expect compiler bugs?
23:09:45	reactormonk	Araq, oh, and importcpp should work in the future for infix syntax?
23:10:17	Araq	yeah, should help, right?
23:10:29	reactormonk	Yes, it does.
23:10:41	reactormonk	And importc attaches to the global object? (via this or similar)?
23:13:23	Araq	er ... no?
23:13:35	Araq	it produces foo(a, b, c) iirc
23:32:09	reactormonk	oke