IRC logs from the first KDevelop IRC conference

From KDevelop

*** Logfile started
*** on Fri Oct 28 16:31:20 2005

You have joined channel #kdevelop. (n=jens@h54n2fls307o1101.telia.com)
The channel topic is "KDevelop | If you have a question, just go ahead and ask, but first: | FAQ -- http://kdevelop.org/mediawiki/index.php/FAQ | Tutorials -- http://kdevelop.org/index.html?filename=HEAD/tutorials.html | Manual -- http://docs.kde.org/development/en/kdevelop/kdevelop/ | Bugs -- http://bugs.kde.org/ | KDevelop4 Screenshot -- http://kdevelop.org/mediawiki/index.php/KDevelop4_SVN_Screenshots".
[16:31:41] <teatime>	hi all
[16:32:03] <manyoso>	micron: no
[16:32:10] 	 * teatime spots rdale 
[16:32:18] <manyoso>	micron: it needs kde >= 3.4
[16:32:32] <teatime>	rdale: hi! rare we see you in here :)
[16:32:45] 	 * geiseri_ wonders why palmdocs dont read proper on his palm :P
[16:33:16] <rdale>	okey dokey! maybe I should show up more often..
[16:33:20] Join	sacu has joined this channel. (n=sascha@p213.54.184.242.tisdip.tiscali.de)
[16:33:28] <teatime>	hi sacu 
[16:33:41] <sacu>	hi teatime
[15:37:13] <adymo>	seems everybody is here :)
[15:37:37] <manyoso>	just about :)
[15:37:38] <geiseri_>	i think we are missing mattr, harryF, and roberto__
[15:37:59] <teatime>	mattr is in my list...
[15:37:59] <manyoso>	now, on that note i'm going to grab a bite to eat... be back in 15
[15:38:02] <geiseri_>	although i thought mattr said he could not make it
[15:38:25] Join	maor has joined this channel. (n=maor@bzq-84-110-42-39.red.bezeqint.net)
[15:40:02] <adymo>	roberto__: ping ;)
[15:40:05] Join	chevdor has joined this channel. (n=will@81.185.32.252)
[15:41:23] Part	Vibes has left this channel. ("Leaving")
[15:43:10] <geiseri_>	blackarrow dropped out here too
[15:44:08] <Worf>	annma: i found out that i'm not that good at fixing things or tracking down issues - i'm downgrading my qt now :)
[15:44:32] <annma>	your qt has probably nothing ot do with that
[15:44:48] <annma>	if you have a source distro you should be able to deal with sourecs
[15:45:59] <Worf>	annma: yeah, usually i am.
[15:46:21] <annma>	downgrading qt willnot solve your issue
[15:46:31] <annma>	as far as I understand it
[15:47:20] <teatime>	geiseri_: so.. what's the topic? :)
[15:48:40] <geiseri_>	well i think the first big step was kinda giving everyone a chance to talk about what they have been up to
[15:48:59] <Worf>	annma: well you might be right, but in the meantime some other issue with kuser showed up, and second i'm not sure anymore since the linker flags are in the makefile and i additionally set them in LDFLAGS without succes... ( but maybe i'm just blind not seing the point of failure )
[15:49:10] <geiseri_>	but after that i think its up to the people talking where they want to go
[15:49:39] <geiseri_>	teatime: where there things you had in mind that you would like to talk about?
[15:50:47] <teatime>	hard to say.. there are several architectural problems that comes to mind, but perhaps they're not even relevant in a kdev4 context
[15:51:06] <teatime>	if kdev4 is indeed what we're interested in talking about
[15:51:33] <geiseri_>	well i personally think its an important point to talk about 3 and 4
[15:52:12] <geiseri_>	since roberto__ has written off KDevelop 3.x im not thinking he wishes to be involved in that part, but since i use KDevelop every day, and cannot live without it for 2 years im not sure im in the same boat
[15:53:52] <teatime>	right
[15:54:07] Quit	micron has left this server. (Remote closed the connection)
[15:54:22] Join	markus23 has joined this channel. (n=markus@hyperbyte.markus-raab.org)
[15:54:28] 	 * geiseri_ would also talk about how to get more developers working on 3rd party components outside of the core KDevelop
[15:54:51] <teatime>	stable documented api? :)
[15:54:56] <geiseri_>	since we feel as a group KDevelop 4 should be smaller and lighter we should make it easer for others to add on their crap, so we dont have to have it in our build system etc...
[15:55:22] <geiseri_>	teatime: thats one part... the other is how do we involve them with KDevelop
[15:56:13] <rdale>	I would like the plugin apis to be language independent, and not C++ only
[15:56:21] <geiseri_>	rdale: me too
[15:56:36] 	 * geiseri_ doesnt even want to see the things like control pannels in C++
[15:56:49] <geiseri_>	rdale: this is a point i am hoping you can help me champion in KDE core
[15:56:50] <adymo>	right, if people could make plugins in other languages, they'd feel better
[15:57:02] <adymo>	...java comes to mind...
[15:57:04] <geiseri_>	rdale: we need KParts to transparently support things like ruby, python etc
[15:57:24] <geiseri_>	adymo: it sounds like we have someone working on better java support right?
[15:57:30] <rdale>	by project templates in KDevelop
[15:57:34] <annma>	unfortunately I have to go
[15:57:50] <geiseri_>	annma: in theory this meeting wont start for another hour
[15:57:54] <adymo>	geiseri_: yep, but that's about java support only, not about kdevelop/java bindings
[15:58:09] <annma>	I have to go to fetch my daughters from school
[15:58:13] <geiseri_>	adymo: well imho the java stuff should happen at the kparts level
[15:58:25] <geiseri_>	annma: okay
[15:58:29] <geiseri_>	who is logging this by the way :)
[15:58:29] Quit	annma has left this server. (Remote closed the connection)
[15:58:41] 	 * teatime has a feeling a lot of what we struggle with in kdevelop goes back to kde core
[15:59:02] <geiseri_>	teatime: yes, because we are reall ythe only ones pushing KDE
[15:59:08] <geiseri_>	teatime: other than koffice
[15:59:22] <teatime>	yeah.. and konqueror
[15:59:38] <teatime>	but KDE was built around konqueror.. so the weird tech sorta works for it
[16:00:04] <geiseri_>	well konqueror was the first demo of it
[16:00:31] <geiseri_>	but one requirement on our part is to talk back via sample code or examples to the core KDE project
[16:00:58] <teatime>	if kxmgui realy is in for an overhaul, that'll be HUGE
[16:01:01] <adymo>	please somebody with persistant internet connection do logging
[16:01:11] <teatime>	adymo: I am
[16:01:27] <geiseri_>	teatime: can we post it on the wiki when we are done?
[16:01:43] <geiseri_>	teatime: afaik kxmlgui is going to be changed, if not go away
[16:01:44] <teatime>	yeah. I'll edit it a bit if neccessary
[16:02:32] <geiseri_>	teatime: the big thing i think is imparitive if rdale and adymo want non-C++ extensions to KDevelop will be support for loading these extensions via kparts
[16:02:49] <geiseri_>	teatime: as well as a way to dispatch to the interfaces they implement
[16:03:04] <adymo>	teatime: looks like you didn't lose anything when you were disconnected. please make a log ;)
[16:03:05] <geiseri_>	teatime: plasma needs this same feature, so we are not alone
[16:03:18] <teatime>	could this be done via dcop/scripting?
[16:03:28] <rdale>	you need a top level C++ stub which starts the ruby stuff, so it needs to be a project template
[16:03:37] <teatime>	one thing that would be nice if we planned from the beginning was proper scripting support in kdev4
[16:03:48] <geiseri_>	teatime: well id like to do it in process
[16:04:05] <geiseri_>	teatime: it mostly comes from how to mix the target languages eventloop with the main applications
[16:04:11] <manyoso>	geiseri_: the big thing for that is in kdelibs as you've mentioned... i don't see how/where we would do anything special in kdevelop per se to allow plugins developed in other languages
[16:04:13] <geiseri_>	teatime: since C doesnt have one, but Qt does
[16:04:46] <geiseri_>	manyoso: well thats the goal, we should not HAVE to care what language developers are using
[16:05:16] <geiseri_>	manyoso: maybe all we will need to ship is the idl to describe the interfaces to the target language and help C++ dispatch to them
[16:05:16] <adymo>	geiseri_: just my eclipse experience tells me we should focus on making plugin developer's life easier
[16:05:57] <rdale>	you mix the event loop of a KPart written in a non-C++ language by overriding the event handling methods just as ou wourld with a C++ app
[16:06:16] Join	bretzel has joined this channel. (n=bretzel@modemcable128.237-130-66.mc.videotron.ca)
[16:06:24] <geiseri_>	rdale: i have solved this in kjsembed, and helped solve it in python
[16:06:40] <geiseri_>	rdale: im assuming java has been solved by kde's applet runner
[16:06:56] <geiseri_>	rdale: that pretty much leaves ruby, and i think you could make short work of it
[16:07:15] <rdale>	it's more a matter of suitable project templates in KDevelop
[16:07:25] Part	bretzel has left this channel. ()
[16:07:42] <geiseri_>	well yes, for building apps, but we still need a way to write a KDevelop plugin in ruby and then use it
[16:07:46] <teatime>	well.. if it's technically possible, creating a template is a minor thing
[16:07:59] <geiseri_>	teatime: well creating a _good_ template is not so easy ;)
[16:08:35] <teatime>	true enough
[16:08:49] <rdale>	"KDevelop plugin in ruby and then use it" - that comes down to a KDevelop project template to me
[16:09:02] <CIA-4>	 03asserhal  * r 475250   10 /trunk/l10n/sv/messages/ (9 files in 8 dirs) :  SVN_SILENT updated translations
[16:09:06] <geiseri_>	imho we should actually only ship with a very very very empty basic QMake and or Autotools template and have the rest in KHotNewStuff
[16:09:19] <rdale>	yes
[16:09:40] <geiseri_>	rdale: do you have a good idea/example for how to call ruby methods in an embedded ruby interpreter from C++?
[16:09:44] <teatime>	a KDE app best practices that was reviewed by the kdelibs guys would be the ultimate..
[16:09:51] <rdale>	or this new fangled 'klik'..
[16:10:00] <geiseri_>	rdale: i can try to get that start getting kparts stuff rolling there
[16:10:43] <manyoso>	geiseri_: agree completely on only shipping the basic templates... it is hard enough to maintain the basic ones, plus I think it is confusing to see so many by default
[16:11:02] <rdale>	it works by overriding event methods, which the ruby bindings already do. So it is only a matter of starting the thing off
[16:11:20] <geiseri_>	manyoso: and when templates are local they suffer bitrot :P
[16:11:27] <geiseri_>	rdale: okay
[16:11:57] 	 * manyoso looks at sacu 
[16:12:07] <teatime>	geiseri_: yeah.. maybe templates could be maintained on a wiki?
[16:12:09] <geiseri_>	rdale: i was talking with a few people about us using a dcopidl like file for generating interface descriptions that can be dispatched to embedded languages
[16:12:27] <geiseri_>	teatime: how would that look
[16:12:37] <rdale>	I can't stand idl's..
[16:12:48] <rdale>	my they rot in hell
[16:12:55] <geiseri_>	rdale: neither can i, but my code can ;)
[16:13:02] <geiseri_>	rdale: less code we have to write the better
[16:13:03] 	 * manyoso doesn't like 'em much either
[16:13:19] <rdale>	die idl's, die..
[16:13:30] <teatime>	not sure, but I doubt our "main kde app" template has been updated much since KDE-3.0.. but the KDE API has evolved
[16:13:44] 	 * geiseri_ also wantss to find a way around BC in plugins
[16:14:22] <teatime>	write all of them in ruby? :)
[16:14:28] <rdale>	your talking about from transitioning from C++ to Ruby then?
[16:15:20] <geiseri_>	teatime: well, that too
[16:15:31] <mattr>	i'm keeping a log starting right now, so i don't have everything else said before then
[16:15:49] <geiseri_>	teatime: there should be no reason in KDE 4 why anything that is KPart can be in any language
[16:15:49] <adymo>	geiseri_: well, bc problem has at least two solutions atm
[16:16:31] <adymo>	geiseri_: to reduce bc problems we should ship only kdevplugin.h and really, really necessary stuff in the lib/interfaces
[16:16:46] <adymo>	geiseri_: everything else should go into plugins (even interfaces)
[16:16:59] <geiseri_>	adymo: similar to KParts
[16:17:06] <geiseri_>	adymo: the base interfaces are pretty simple
[16:17:45] <adymo>	geiseri_: yep, maintaining bc in one-two interfaces is quite possible
[16:17:46] <geiseri_>	adymo: the problem with adding interfaces from plugins (in eclipses case) you start a dependency nightmare
[16:18:10] <adymo>	geiseri_: yep, inter-pluin dependencies
[16:18:43] <geiseri_>	adymo: one part i was looking at was dynamic dispatch methods, so we just have to worry about SC, and BC is a moot point
[16:19:11] <geiseri_>	adymo: but then you get into idl land ;)
[16:19:14] <adymo>	geiseri_: but that's not really a nightmare, we just have to say in .desktop file what plugins we need
[16:19:32] <geiseri_>	adymo: well its not saying the ones you need its more a packaging issue
[16:19:41] <geiseri_>	adymo: in eclipse they ship EVERYTHING
[16:19:47] <manyoso>	i don't like the idea of inter-plugin dependencies
[16:19:51] <geiseri_>	adymo: and things that are 3rd party also ship with EVERYTHING
[16:20:02] <geiseri_>	adymo: so things get bloated fast
[16:20:07] <teatime>	I think dynamic dispatch is probably saner
[16:20:48] <adymo>	geiseri_: dynamic dispatch? how does that differ from using interfaces with Q_DECLARE_EXTENSION_INTERFACE?
[16:21:25] <adymo>	manyoso: we're really close to inter-plugin deps in kdevelop3, we just never implemented the mechanism
[16:21:40] <geiseri_>	adymo: by dynamic dispatch i mean we have a proxy class that looks like a pure virtual interface, but it really just emulates the virtual table in a portable way and invokes the subclassed methods
[16:21:55] <geiseri_>	the Q macro only provides a bit of versioning info
[16:22:15] <teatime>	adymo: actually, we technically had it..
[16:22:28] <adymo>	manyoso: if we want to move, say projectmanager interface, out of lib/interfaces, we have to introduce dependencies
[16:23:10] <geiseri_>	adymo: what if we had a sort of common "model" that the entire system could communcate through?
[16:23:27] <geiseri_>	dont talk via interfaces, use a central model kinda like our project dom thinggy
[16:23:46] <adymo>	geiseri_: but with qt extension interfaces you're doing the same thing - you call methods of pure virtual class
[16:23:47] <geiseri_>	like an abstract item model that is the ENTIRE system
[16:24:12] <geiseri_>	this way the plugins can get their data from the model vs eachother
[16:24:15] Join	sparr has joined this channel. (i=sparr@pdpc/supporter/active/sparr)
[16:24:27] <adymo>	geiseri_: oh, that's smth new....
[16:24:38] <geiseri_>	this way we can also have plugins that provide interfaces, without worring about them depending on eachother
[16:25:00] <sparr>	i am new to kdevelop...  how do i make it handle indentation for me?  like when i type a { and hit enter i want it to indent
[16:25:46] <geiseri_>	adymo: this would be cool because with the new model/view stuff we could have a central model, that would be the interface, and plugins could provide a proxy model to filter out the useless parts
[16:26:02] <teatime>	sparr: look at settings -> configure editor -> indentation
[16:26:36] <adymo>	geiseri_: still, if one plugin needs services from another, how can it work if the dependency rule is not met?
[16:26:50] <teatime>	geiseri_: not sure I get it.. if I need a specific interface, how do I find it?
[16:27:07] <sparr>	teatime: what does setting -> configure kdevelop -> indentation control?
[16:27:08] <geiseri_>	adymo: well what would be an example?
[16:27:26] <geiseri_>	teatime: you should not need to know a specific interface
[16:27:33] <geiseri_>	teatime: only where in the model the data is you want
[16:27:41] <teatime>	hmm
[16:28:05] <geiseri_>	teatime: maybe provide a trader/query interface to help show off where data is
[16:28:06] <teatime>	geiseri_: at this particular moment, that strikes me as very clever.. :)
[16:28:06] <adymo>	geiseri_: say, c++ plugin asking for a "search in documentation" service of documentation plugin
[16:28:53] <geiseri_>	adymo: hmm okay
[16:28:56] <geiseri_>	good example :)
[16:29:13] <teatime>	sparr: dunno exactly. ask in #kate
[16:29:24] <geiseri_>	adymo: maybe a mixture of the model and a query interface
[16:29:54] <teatime>	geiseri_: how would you handle the opposite direction - the application needs to tell the plugin something. that's still the kdevplugin interface, right?
[16:30:07] <geiseri_>	the idea being that we marshall communication via some central locations so we dont have to depend on eachother
[16:30:12] <adymo>	geiseri_: what would be in the model in this case?
[16:30:20] <sparr>	teatime: why?  its not a kate setting, its a kdevelop setting
[16:30:35] <teatime>	sparr: no, it IS a kate setting
[16:30:40] <geiseri_>	adymo: in my mind, things like the project information, files, classes, kdevelop settings, etc pretty much EVERYTHING
[16:30:56] <sparr>	teatime: its not in kate...
[16:30:58] <geiseri_>	adymo: since we can make a custom model it would not store any data
[16:31:15] <teatime>	sparr: it's katepart. compare it to kate, you'll find the dialog identical. for a reason.
[16:31:23] 	 * geiseri_ wonders if we can make like a KDevelop dcop that runs inside of KDevelop only ;)
[16:31:31] <teatime>	lol
[16:31:35] <sparr>	teatime: im talking about Configure KDevelop, not Configue Editor
[16:31:41] <manyoso>	i thought we were trying to make kdevelop4 smaller and leaner ;)
[16:31:47] <adymo>	hehe
[16:32:13] <geiseri_>	manyoso: do you think having a central model bloated
[16:32:27] <manyoso>	i don't get how it'd work, really
[16:32:27] <teatime>	sparr: hmm.. yeah, I see now that that's what you wrote. but there is no such path
[16:32:43] <manyoso>	geiseri_: and I'm not sure it would be rich enough
[16:32:44] <sparr>	teatime: odd, perhaps we are using different versions of kdevelop
[16:32:50] <geiseri_>	manyoso: well im still not 100% either, its just as marious and i where talking it sounded good
[16:32:55] <teatime>	sparr: what version are you using?
[16:32:57] <adymo>	geiseri_: well, you can describe plugin interface using "dom" and build a model to represent it, but why should you do that?
[16:33:00] <sparr>	3.2.0
[16:33:37] <teatime>	sparr: in that case I'm sure my glasses are better than yours.. ;)
[16:33:40] <sparr>	in my kdevelop, I have Settings > Configure KDevelop > about a dozen pages of options, the last 3 being C++ Class Generator, Formatting, C++Parsing
[16:33:43] <adymo>	geiseri_: with qt extension interfaces it's more straightforward to ask for functionality with qt_extension<>
[16:33:57] <sparr>	and in Formatting it has indentation options and styles
[16:34:01] <sparr>	but they dont appear to do anything
[16:34:06] <geiseri_>	adymo: is this in the current code?
[16:34:50] <geiseri_>	adymo: i dont rember this one comming up in the kparts discussion at akademy
[16:35:06] <teatime>	sparr: that's for the "reformat source" feature. it's in the Edit menu. 
[16:35:17] <sparr>	teatime: ahhh
[16:35:19] <sparr>	good to know
[16:35:35] <teatime>	sparr: it's 'astyle' embedded. warts and all
[16:35:50] <adymo>	geiseri_: do you remember we've discussed bc and i posted a message with a sample implementation of your idea?
[16:36:20] <geiseri_>	adymo: i vaguely recall
[16:36:39] <geiseri_>	adymo: but i didn't think that gave a way to call a method
[16:36:48] <geiseri_>	adymo: or do i need to reread =)
[16:37:31] <adymo>	geiseri_: moment....
[16:38:09] <adymo>	geiseri_: that's a message from 2005-09-08
[16:38:39] <adymo>	geiseri_: i posted the implementation using qt extension interfaces
[16:39:40] <geiseri_>	gah, one sec phone
[16:40:19] Quit	roberto__ has left this server. ("Kopete 0.10.3 : http://kopete.kde.org")
[16:40:25] <teatime>	heh
[16:40:41] <geiseri_>	kde hack session tomorrow, so pople need directions :)
[16:45:42] <geiseri_>	k back
[16:46:12] <geiseri_>	adymo: this is the stuff Qt designer uses now right?
[16:46:20] <adymo>	geiseri_: yes
[16:46:44] <adymo>	geiseri_: you have to link to designer library
[16:47:12] <geiseri_>	adymo: well we may have to implement our own, to support other languages
[16:47:19] <geiseri_>	or do you think it would work the same?
[16:48:07] <adymo>	geiseri_: hmm, i don't know
[16:48:18] <geiseri_>	adymo: im looking for it again
[16:48:28] <geiseri_>	adymo: it may be worth exploring it
[16:49:03] <geiseri_>	manyoso: one of the points of having a central model would be to not have plugins with their own private data... they would just agrigate the full model
[16:49:47] <adymo>	the question basically is can we call qt_extension() from other languages
[16:51:33] <adymo>	registering extensions with factories and manager looks possible to me once the language has bindings for QExtensionManager and QExtensionFactory
[16:52:42] <geiseri_>	hmm sounds like it should be reasonable
[16:53:12] <adymo>	rdale: can you please look at the attachment to   org.kde.designer_0.2.1.jar  28 October 2005
[16:53:14] <adymo>	  Qt/QMake support: core functionality  org.kde.qmake.core_0.2.3.jar  28 October 2005
[16:53:14] <adymo>	  Qt/QMake support: user interface and project wizards  org.kde.qmake.ui_0.2.3.jar  28 October 2005
[16:53:14] <adymo>	  Prepackaged Binaries (P
[16:53:17] <adymo>	oops
[16:53:25] <adymo>	sorry
[16:53:36] <adymo>	.. attachment to http://lists.kde.org/?l=kdevelop-devel&m=112620787223741&w=2 ?
[16:53:52] <adymo>	rdale: can those two plugins be implemented in ruby?
[16:55:46] <geiseri_>	adymo: hmm okay
[16:56:16] <geiseri_>	adymo: actually imho there is quite a bit of duplcation in those... i "really" think an idl could automate some of it
[16:56:49] <geiseri_>	we would have to lean heavy on ktrader though to describe what features are available
[16:57:04] Join	jpetso has joined this channel. (n=jpetso@193.170.48.226)
[16:58:16] <jpetso>	hi all
[17:00:13] <adymo>	geiseri_: let's get back to the example of c++ plugin -> documentation plugin, with qt interfaces, you need to know the interface, ask the manager to give you an instance and call the method. with  your model you still need to filter the model and  somehow  call the method
[17:00:40] <adymo>	geiseri_: atm the flexibility of the central model doesn't buy me the complexity
[17:00:50] <geiseri_>	adymo: hmmm okay
[17:01:01] 	 * geiseri_ is not 100% sure on the central model either... im just thinking =)
[17:01:13] <geiseri_>	im also not 100% on all these plugin loaded interfaces ;)
[17:01:30] <adymo>	well, i'm not against anything, just thinking too ;)
[17:01:47] <adymo>	oh, sorry, i have to disconnect, will be back in ~30 mins
[17:01:51] <geiseri_>	doh
[17:01:53] <geiseri_>	okay
[17:01:57] <adymo>	teatime: please keep logging ;)
[17:02:00] Quit	adymo has left this server. (Remote closed the connection)
[17:03:11] Part	spybert has left this channel. ("Leaving")
[17:04:00] <teatime>	geiseri_: apart from the complexity, how about performance?
[17:04:25] <geiseri_>	for models? or dynamicly dispatched interfaces or everythin l)
[17:04:54] <teatime>	maybe I just don't get it but how would a model based approach handle a plugin wanting to ask the project plugin "what files are part of the project?"?
[17:05:30] <teatime>	or is the model a way to retrieve a known interface that you then call through?
[17:06:02] <geiseri_>	teatime: well in my warped brain i see the KDevelop instance as a big tree of objects that are in a key/value pair
[17:06:25] <geiseri_>	teatime: because of this i thought "hey lets throw this in an QAbstractItemModel"
[17:06:52] <geiseri_>	then say you wanted to know the files in a project, you would as for a proxy model that would filter the files that are in the project
[17:07:12] 	 * geiseri_ is working on a model factory that can build models via trader queries
[17:07:18] Join	roberto__ has joined this channel. (n=roberto@062016248251.customer.alfanett.no)
[17:07:33] <roberto__>	hi
[17:07:34] <geiseri_>	the "ProjectFileProxyModel" would know how to find the project files in the main model
[17:07:38] <geiseri_>	hiyea roberto__
[17:07:39] <teatime>	hi roberto__ :)
[17:07:43] <roberto__>	finally i'm home
[17:07:51] <roberto__>	ohh god what a day :-)
[17:07:54] <roberto__>	so
[17:07:57] <roberto__>	any news?
[17:08:02] <geiseri_>	teatime: now there is a bit of black magic in there but thats an implementation detail ;)
[17:08:10] <geiseri_>	roberto__: adymo will be back in about 25 minutes
[17:08:13] <teatime>	roberto__: we're basing kdevelop4 on CORBA.. 
[17:08:16] 	 * roberto__ is updating kdelibs
[17:08:21] <roberto__>	heheh
[17:08:23] <geiseri_>	roberto__: we are just chatting
[17:08:25] <teatime>	:)
[17:08:29] <geiseri_>	roberto__: basicly brainstorming
[17:08:33] <roberto__>	cool
[17:08:44] <roberto__>	where is blackarrow?
[17:08:56] <geiseri_>	roberto__: he was here but then his connection pinged out
[17:09:03] <geiseri_>	teatime is logging though
[17:09:04] <roberto__>	i want to talk with him about "the incremental stuff" we need in kate
[17:09:38] Quit	bobesponja has left this server. (Read error: 104 (Connection reset by peer))
[17:10:10] <geiseri_>	manyoso: you back?
[17:10:37] <jpetso>	hi roberto
[17:10:43] <roberto__>	ciao jpetso
[17:10:48] <manyoso>	i'm here
[17:11:03] <geiseri_>	roberto__: are marious or harry going to be here?
[17:11:10] <roberto__>	jpetso: i'm trying to integrate the cool language in kate (together with blackarrow)
[17:11:24] <roberto__>	jpetso: the idea is to change kdevelop-pg
[17:11:27] <jpetso>	oh! so that's what it's here for
[17:11:29] 	 * sacu hopes to be able to join again now. Am alone with the two kids...
[17:11:31] <roberto__>	jpetso: to generate code for incrmental parsing
[17:11:46] <geiseri_>	roberto__: i talked with marious about using models for interfacing with the rest of the system
[17:11:54] <roberto__>	jpetso: the idea is to use it to develop a tiny programming language support for kdevelop
[17:12:01] <geiseri_>	roberto__: since he has a more firm understanding of the subject id like him to be here
[17:12:18] <roberto__>	geiseri_: ops! he is not here!
[17:12:19] <roberto__>	hmm
[17:12:20] <jpetso>	roberto: as template for bigger ones, you mean?
[17:12:27] <roberto__>	jpetso: yep
[17:12:30] <jpetso>	ok
[17:12:32] <geiseri_>	roberto__: no problems, ideally this wont be the last meeting ;)
[17:12:44] <roberto__>	jpetso: java is probably a bit too much (for a testing project)
[17:12:48] <roberto__>	hehe
[17:12:56] <jpetso>	roberto: good idea, actually
[17:13:02] <roberto__>	geiseri_: now!! we should have at least one each week
[17:13:06] Join	Amilcar has joined this channel. (n=konversa@fozzy.ida.ing.tu-bs.de)
[17:13:10] <manyoso>	hi Amilcar
[17:13:11] <geiseri_>	roberto__: yes
[17:13:18] <manyoso>	wow, everyone and their brother is here
[17:13:20] <Amilcar>	Hi all
[17:13:24] <jpetso>	i've just switched to Ubuntu and am now trying to get the damn thing to compile here
[17:13:24] <roberto__>	yo Amilcar
[17:13:25] <geiseri_>	roberto__: the goal will be to have these once a week about this time, and log the results on the wiki
[17:13:36] <Amilcar>	:)
[17:13:37] <roberto__>	jpetso: do you have any problem with kdev-pg?
[17:13:39] <sacu>	geiseri_, adymo: I've look at the eclipse-templates that adymo made. Then i've seen KJSEmbed blog from geiseri_ from january. Still, my objective is to create an engine that does apptemplates, filetemplates and classtemplates - maybe even snippet templates. I've come to the conclusion that it might be best to have a MacroEditor using KJSEmbed and build all this template stuff upon that.
[17:14:20] <geiseri_>	sacu: that would rock to have them all in the same facility
[17:14:22] <roberto__>	sacu: cool :-)
[17:14:23] <jpetso>	roberto__: well, I stumbled upon Annotations, I got a question here
[17:14:44] <roberto__>	jpetso: what's wrong with annotations? :-)
[17:14:51] <geiseri_>	sacu: well im not keen on things like conditional logic in the templates, but hey if you want to do it im not going to stop you :)
[17:14:53] <sacu>	geiseri_: actually, that is why i asked about the state of kjsembed, recently
[17:15:10] <geiseri_>	sacu: right now im working on making it easier to bind
[17:15:21] <jpetso>	roberto__: they're using @bla( anything ) as shortcut for @bla( value = anything )
[17:15:30] <geiseri_>	sacu: kjs is going to be chaging significantly in the next month as we migrate to javascriptcore
[17:15:48] <geiseri_>	sacu: kjsembed users wont notice on their level, but people writing bindings maynotice
[17:15:58] <jpetso>	roberto__: is there an elegant way to "rename" it so that the parser directly gets it as value = anything?
[17:16:15] <geiseri_>	sacu: kjsembed4 is suppose to get up on kde svn this weekend, so you can see it
[17:16:25] <sacu>	geiseri_: think we've talked about the topic of conditional logic quite a lot :)
[17:16:34] <geiseri_>	sacu: =)
[17:16:42] <roberto__>	jpetso: we're talking about kdev-pg or ANTLR?
[17:17:09] <jpetso>	roberto__: Java, sorry. Java annotations parsed by kdev-pg
[17:17:11] <sacu>	geiseri_: that's good, so i can see it and maybe write something up like MSVC's MacroEditor - I'm thinking about something like a JAR...
[17:17:26] <geiseri_>	sacu: have you looked at the visual studio templates?
[17:17:35] <geiseri_>	sacu: they mix javasciript and code
[17:17:43] <sacu>	geiseri_: actually not, no.
[17:17:49] <geiseri_>	sacu: do you have access to them?
[17:17:56] 	 * geiseri_ can send you a few off line
[17:18:04] <sacu>	MSVC.NET?
[17:18:12] <roberto__>	jpetso: well i don't know.. i need the grammar specs to *understand* the problem
[17:18:18] <geiseri_>	sacu: yes, 2003 or bigger
[17:18:32] <sacu>	geiseri_: tell me where to locate them and i'll have a look on monday.
[17:18:44] <geiseri_>	sacu: i have to get on the winders box but i will do that
[17:19:01] <jpetso>	roberto__: ah, not so important, let's keep it for later
[17:19:37] <roberto__>	jpetso: the thing that scare me is that "anything"
[17:19:41] Quit	Worf has left this server. ("using sirc version 2.211+KSIRC/1.3.12")
[17:19:42] <geiseri_>	so does everyone here know what everyone else is working on?
[17:19:51] <roberto__>	jpetso: i mean you may need *a special* hack in the lexer
[17:19:52] <sacu>	geiseri_: when i understand KJSEmbed right, then i create a Q_OBJECT class and make slots and properties there - and then can access those from JS, right?
[17:20:13] <geiseri_>	sacu: in v3, in v4 you can expose individual methods
[17:20:22] <geiseri_>	on any object that is in the host application
[17:20:26] <jpetso>	roberto__: no, it's just an abbreviation, and instead of storing it in an extra variable, I want to store it directy as the right thing
[17:21:09] <roberto__>	jpetso: i can take a look at it if you want
[17:21:12] <jpetso>	roberto__: or maybe I shouldn't store it at all? ah well
[17:21:13] <roberto__>	jpetso: just send me the grammar
[17:21:14] <sacu>	geiseri_: if we're going to have that "big Model" in kdev4, would it be wise/easy to expose it?
[17:21:40] <geiseri_>	sacu: well "big model" is kinda a lie ;)
[17:21:51] <teatime>	fud ;)
[17:22:05] <geiseri_>	sacu: in Qt model/view programming the model is just an interface to the real data, so its (if done correctly) very light
[17:22:20] <roberto__>	geiseri_: exactly :-)
[17:22:29] <geiseri_>	sacu: the model provides an interface other models, as well as views can manipulate in a generic method
[17:22:51] <roberto__>	geiseri_: the big problem is that you need *two* super fast operation
[17:22:58] <roberto__>	geiseri_: parent() and index()
[17:22:59] <geiseri_>	sacu: this way if the project where a model i could have a model that just had the files, this would make things like the dist part trivial
[17:23:17] <geiseri_>	roberto__: yeah treemodel traversal is something that can add up
[17:23:17] <roberto__>	geiseri_: so in the 99% of the cases you need at least one hash map for each entry
[17:23:25] <roberto__>	geiseri_: that means a lot of hash tables
[17:23:34] <roberto__>	geiseri_: that means a lot of memory usage
[17:24:00] <geiseri_>	roberto__: im trying to solve this with my ldap model now, ive gotten pretty far using raw data
[17:24:02] <sacu>	geiseri_: this would finally make it easy to create a project and then fill it with life - contrary to have it done on disk and then adding a milion hacks to get it loaded :)
[17:24:45] <geiseri_>	sacu: exactly, you could tell the model to create a bunch of files, then populate them from the template, then save it all to disk :)
[17:25:53] 	 * geiseri_ is not sure 100% that model/view is the way to go, but its worth exploring
[17:26:02] Join	_jpetso has joined this channel. (n=jpetso@193.170.48.226)
[17:26:09] <roberto__>	geiseri_: sure it is
[17:26:21] 	 * _jpetso caught an unfortunate offtime
[17:26:41] 	 * roberto__ is very happy with QTreeWidget
[17:27:04] <geiseri_>	roberto__: i have gotten pretty far on my QAbstractModelAdaptor (like an item delegate only it maps to a form and not a item view)
[17:27:08] <roberto__>	geiseri_: thanks to QTreeWidget and QVariant is very very easy to write kick-ass tree views without writing a model :-)
[17:27:13] <geiseri_>	roberto__: this way you can bind a form to a model
[17:27:34] <roberto__>	geiseri_: form??
[17:27:38] Quit	jpetso has left this server. (Read error: 104 (Connection reset by peer))
[17:27:40] <geiseri_>	roberto__: a ui file
[17:27:42] <roberto__>	wow
[17:27:56] <roberto__>	geiseri_: do you know i've introduced a new library in Qt 4.1?
[17:28:01] <roberto__>	geiseri_: libQForm
[17:28:13] <geiseri_>	roberto__: draw a ui file, add a few adaptors, get a model from my model factory and boom you have a data driven app in only a few lines of code
[17:28:17] <geiseri_>	roberto__: im shocked ;)
[17:28:19] <roberto__>	geiseri_: it is a static library so you don't need the Qt Designer runtime for loading ui files
[17:28:32] <geiseri_>	roberto__: i will look into that in kjsembed
[17:28:36] <geiseri_>	is it in rsync?
[17:28:39] <roberto__>	geiseri_: i've also added a method called availableWidgets()
[17:28:42] <geiseri_>	and is it even remotely documented ;)
[17:28:47] <roberto__>	geiseri_: sure it is
[17:28:50] 	 * geiseri_ kisses roberto__ 
[17:28:58] <roberto__>	geiseri_: it returns the list of all the available widgets (like WIdgetFactory::widgets())
[17:29:02] <roberto__>	geiseri_: i did it for you :-)
[17:29:15] <_jpetso>	roberto__: another thing, (f)lex it doesn't support Unicode, which is required by Java
[17:29:24] <roberto__>	geiseri_: the new library is inside the namespace QForm
[17:29:36] <roberto__>	geiseri_: i'm going to add a lot of new classes there in the 4.x releases
[17:29:36] <geiseri_>	okay
[17:29:48] <roberto__>	geiseri_: things like saving UI files, changing UI files, and stuff like that
[17:30:13] <geiseri_>	can i do the layouts too like in formbuilder?
[17:30:25] <roberto__>	what do you mean?
[17:30:31] <geiseri_>	like createWidget(). createLayout() in QFormBuilder
[17:30:49] <roberto__>	yep
[17:30:54] <geiseri_>	okay cool
[17:30:58] 	 * geiseri_ will look into that today
[17:31:12] <roberto__>	$QTDIR/designer/src/form/
[17:31:23] <roberto__>	actually $QTDIR/tools/designer....
[17:32:01] <roberto__>	geiseri_: an example is in $QTDIR/example/designer/worldtimeclockbuilder
[17:32:18] <roberto__>	geiseri_: another thing.. QForm::Loader initialize the plugin paths
[17:32:30] <roberto__>	geiseri_: so you don't have to set the plugin patch explicily
[17:33:33] <roberto__>	geiseri_: anyway, i hope you happy with it because we're branching Qt so there is no way i can change it(e.g. integrate your feedback) :-)
[17:33:50] Join	Nichtsnutz has joined this channel. (n=stefan@pc066.woschi.RWTH-Aachen.DE)
[17:34:14] <geiseri_>	roberto__: so far so good :)
[17:34:59] <roberto__>	geiseri_: to use it you must replace in your .pro file CONFIG+=designer with CONFIG+=form
[17:35:13] <geiseri_>	okay
[17:35:29] <geiseri_>	roberto__: i wonder if we can use this along with my model adaptor to do custom screens in kdevleop4
[17:36:12] <geiseri_>	roberto__: this way we can ship with very simple config screens and people can tweak them if they really wanted to later
[17:36:27] <roberto__>	geiseri_: do you know if i can use scons to compile kdelibs?
[17:36:40] <roberto__>	geiseri_: kdelibs in trunk
[17:36:52] <geiseri_>	roberto__: i _think_ thats what they are using... i still am doing Qt only development
[17:36:58] 	 * geiseri_ wants qmake for ever
[17:37:07] <roberto__>	hehehe
[17:37:32] 	 * roberto__ is looking forward for ian's scons2qmake.js
[17:37:37] <geiseri_>	lol
[17:37:47] <teatime>	oh, don't tempt him
[17:38:00] <geiseri_>	hey i was asking sam to make qmake use QSA so we could have configure scripts...
[17:38:00] <roberto__>	heheh
[17:38:04] <geiseri_>	he just groaned
[17:38:40] <geiseri_>	roberto__: seriously though, i would love our project manager to have the ability to save itself as either qmake, scons, or automake projects
[17:38:48] <roberto__>	QSA everywhere
[17:39:07] <geiseri_>	roberto__: well only because you wont use kjsembed in your products ;)
[17:39:19] <roberto__>	hehe
[17:39:34] 	 * roberto__ likes kjsembed too
[17:39:49] 	 * geiseri_ likes lua the best but no-one knows about that one ;)
[17:40:14] <geiseri_>	roberto__: ecmascript is really the automation language of the future
[17:40:15] <roberto__>	geiseri_: me hates it
[17:40:17] <teatime>	kde has a lua implementation?
[17:40:17] Quit	Nichtsnutz has left this server. ("using sirc version 2.211+KSIRC/1.3.12")
[17:40:27] <geiseri_>	roberto__: with svg, html, .net etc...
[17:40:30] <geiseri_>	its everywhere
[17:40:32] <roberto__>	geiseri_: i know kate is using lua for something
[17:40:48] <geiseri_>	roberto__: yeah anders is trying to use lua for scripting vs kjs
[17:41:05] <geiseri_>	roberto__: the problem with lua is its not very well known, and its more geared for mathmatics and simulation...
[17:41:38] <geiseri_>	anyone who has remotely played with C, C++, Java or C# will know javascript
[17:41:41] <teatime>	err.. wtf? http://www.kdevelop.org/mediawiki/index.php/Icons_from_visual_studio.net
[17:42:05] <geiseri_>	and pretty much anyone who has done web, or flash development will know it
[17:42:18] <geiseri_>	so really QSA/KJSe are the future
[17:42:24] <geiseri_>	for automation ;)
[17:42:35] <teatime>	geiseri_: don't they all hate it though? ;)
[17:43:32] <geiseri_>	teatime: its kinda like fat chicks, they all like to make fun of them, but secretly they long for some whipped cream and a bungiee cord  session with them
[17:43:33] Join	Worf has joined this channel. (n=worf@j-177.vc-graz.ac.at)
[17:44:17] <geiseri_>	roberto__: the other point that rdale and i where talking about was the need to get KParts to talk languages other than C++
[17:44:29] <geiseri_>	roberto__: this way we can have plugins in other languages
[17:44:38] <teatime>	geiseri_: rotfl!
[17:44:40] <roberto__>	wow http://www.peakpeak.com/~tromey/blog/2005/10/24#fast-tools :-)
[17:44:41] <geiseri_>	roberto__: with Qt's Java thinggy this may become more important
[17:44:56] 	 * roberto__ needs to write his own c++ compiler :-)
[17:45:11] <roberto__>	yep
[17:45:19] <teatime>	roberto__: we all knew it was coming... ;)
[17:45:33] <roberto__>	sure
[17:45:58] <roberto__>	unfortunaly i'm not involved in the project :(
[17:46:08] <roberto__>	sigh! sigh!
[17:46:14] <teatime>	actually I meant your c++ compiler.. 
[17:46:18] Part	Worf has left this channel. ()
[17:46:30] <roberto__>	ohh yeah.. i'm involved with that :-)
[17:46:37] <teatime>	heh
[17:46:51] <roberto__>	teatime: actually i have my own C compiler
[17:46:58] <roberto__>	teatime: well part of it
[17:47:20] <roberto__>	teatime: i hope to have time to finish it and release it at some point
[17:47:41] <roberto__>	teatime: i remember i sent a preview of it to adymo and manyoso
[17:48:14] <roberto__>	teatime: the problem of robe-c (the name of my compiler) is I'm using jikespg to generate the parser
[17:48:33] <geiseri_>	roberto__: adymo and i where talking about the dynamic plugins
[17:48:36] <roberto__>	teatime: jikespg has is incompatible with GPL so i can't release it :(
[17:48:38] <manyoso>	oh, please, if you do, use llvm as the backend
[17:48:56] <geiseri_>	rotfl
[17:48:56] <roberto__>	teatime: that's why i've wrote kdevelop-pg :-)
[17:49:14] <roberto__>	manyoso: i like llvm
[17:49:18] <roberto__>	manyoso: it is very cool
[17:49:23] <teatime>	roberto__: i swear, you must have been awarded 48 hour days..
[17:49:26] <roberto__>	manyoso: but it's huge
[17:49:34] <manyoso>	would be very cool to use your c++ parser as the frontend instead of g++
[17:49:38] <manyoso>	anyways...
[17:49:41] <roberto__>	manyoso: i wrote a small frontend for minc (a kdev-pg example) using llvm
[17:49:51] <roberto__>	manyoso: the binary was *huge* and very very slow
[17:49:53] <geiseri_>	can we replace ctags with yoru parser?
[17:50:03] <roberto__>	manyoso: it's not good for compilers
[17:50:04] 	 * geiseri_ wants a better ctags
[17:50:06] <manyoso>	that's a must
[17:50:14] <roberto__>	manyoso: you can't have the whole AST for a C++ translation unit in memory
[17:50:16] <teatime>	geiseri_: in what way?
[17:50:17] <roberto__>	manyoso: it's too much
[17:50:23] Join	SaemSUSE` has joined this channel. (n=konversa@S0106000625c0aab4.vc.shawcable.net)
[17:50:36] <roberto__>	manyoso: and you need a real kick ass typechecker
[17:50:51] <roberto__>	manyoso: actually you have to perform typechecking while parsing the file
[17:50:55] Join	jpetso has joined this channel. (n=jpetso@193.170.48.226)
[17:50:58] <geiseri_>	teatime: return types, better signature identification support, better resolution on the types of each part
[17:50:59] <roberto__>	manyoso: actually it's every worst
[17:51:11] <manyoso>	roberto__: any word on a preprocessor for your parser?  did you follow the problems I'm having with it and threadweaver?
[17:51:13] <geiseri_>	teatime: right now you cannot break up a method very easy in ctags
[17:51:22] <roberto__>	manyoso: you have to parse the file N-times where (N is scope level for classes/functions)
[17:51:34] <roberto__>	manyoso: and do the typechecking == almost impossible
[17:51:44] <teatime>	geiseri_: break up? 
[17:51:51] <roberto__>	manyoso: yeah.. i decided to use an existing one
[17:51:59] <roberto__>	manyoso: i dont' have time to write it
[17:52:02] <teatime>	ctags only does string literal matching.. but it does it _fast_
[17:52:04] <roberto__>	manyoso: i was looking at bcc
[17:52:07] <manyoso>	ok, so we'll be using cpp
[17:52:09] <geiseri_>	teatime: i think it just gives you the return type and the signature
[17:52:12] <roberto__>	manyoso: bcc has a very good preprocessor
[17:52:14] <geiseri_>	maybe if its const or not
[17:52:17] <roberto__>	manyoso: the source code is simple and small
[17:52:24] <manyoso>	i'll have to look at it
[17:52:31] <geiseri_>	teatime: i want more detail, such as the arguments and their types
[17:52:43] <roberto__>	manyoso: and it is standalone :-)
[17:52:59] <manyoso>	why not use cpp, too slow?
[17:53:09] <roberto__>	manyoso: if you using debian try with apt-get source bcc
[17:53:18] <roberto__>	manyoso: it's huge
[17:53:28] <manyoso>	i'm using suse, but i'll look into it
[17:53:38] <roberto__>	manyoso: the point is we need to *merge* the source code of the prprocessor with the our own tokenizer
[17:53:46] <roberto__>	manyoso: and cpp is about 500.000 loc
[17:53:50] <roberto__>	manyoso: we can't really use it
[17:54:01] <roberto__>	manyoso: of course we can use it out-of-process with a pipe
[17:54:08] <roberto__>	manyoso: but that is very slow
[17:54:09] <manyoso>	exactly
[17:54:12] <manyoso>	k
[17:54:31] <roberto__>	manyoso: the preproc in bcc is nice and small.. so we can change it
[17:54:41] <roberto__>	manyoso: or we can try to finish my preproc
[17:54:51] <manyoso>	where is your preproc?
[17:55:06] <roberto__>	in the directory rpp
[17:55:17] <roberto__>	cppparser/rpp
[17:55:18] <manyoso>	heh
[17:55:38] <manyoso>	should have guessed
[17:55:48] <roberto__>	kdevelop/languages/cpp/parser/rpp$
[17:56:16] <roberto__>	manyoso: another possible solution is to use the one i wrote for kdevelop3
[17:56:22] <roberto__>	manyoso: but it is very slow
[17:56:28] <roberto__>	manyoso: so .. i don't know
[17:56:40] <roberto__>	manyoso: do you have time to help me with the preproc stuff?
[17:56:48] <manyoso>	i'm doing so much stuff right now
[17:56:57] <roberto__>	manyoso: if you do it I can play with the Binder
[17:56:58] <manyoso>	i'll try to look at it and bcc
[17:57:01] <roberto__>	heheh
[17:57:03] <roberto__>	sure
[17:57:35] <manyoso>	roberto__: i really want to think about combining kdevcodemodel into just an interface to your parser/codemodel
[17:57:56] <manyoso>	although, the problem with that is other languages will have other code models
[17:58:23] <manyoso>	we'd have to _assume_ they'd have codemodels as subsets of parser/codemodel
[17:59:56] <roberto__>	manyoso:  we can generalized the codemodel
[17:59:57] <geiseri_>	okay, i gotta bail here teatime you will post this on the wiki?
[18:00:03] <roberto__>	manyoso: in kdev3 we have only one code model
[18:00:16] <roberto__>	manyoso: and it is general enough for all our programming language support
[18:00:19] <manyoso>	i know, but that is ok since no other language part is really using it all that much
[18:00:27] <manyoso>	roberto__: ahem
[18:01:00] <roberto__>	manyoso: actually the source code of rpp is not that bad
[18:01:01] <teatime>	geiseri_: yeah, I'll keep logging.. just gotta figure out how to create a new wiki page..
[18:01:05] <manyoso>	that remains to be seen IMHO when we get a working java codemodel to compare it iwth
[18:01:06] Nick	chouimat|Zzzz is now known as chouimat.
[18:01:12] 	 * chouimat waves to all
[18:01:16] Quit	SaemSUSE has left this server. (Read error: 110 (Connection timed out))
[18:01:17] <roberto__>	manyoso: it is very clean (it doesn't work... but it is clean) :-)
[18:01:19] <teatime>	hi chouimat 
[18:01:26] <manyoso>	roberto__: the best kind!~
[18:01:31] <roberto__>	hehehe
[18:01:41] <chouimat>	sorry it seems I missed the meeting :(
[18:01:47] <roberto__>	manyoso: when you have take a look at it
[18:02:05] <roberto__>	manyoso: then we can decide what to do.. drop it? use bcc? or whatever
[18:02:07] <manyoso>	i will, but I'm going to continue hooking up the parser as I can in the next few weeks
[18:02:32] <roberto__>	manyoso: what do you think about the c++ parser?
[18:02:44] <manyoso>	of course, feel free to holler if I'm doing something wrong or if you want to see it done in a different way
[18:03:04] <roberto__>	manyoso: :-) i'm pretty sure you know what you're doing :-)
[18:03:04] <manyoso>	roberto__: i like it, that's why I want to get it hooked up so we can start test driving it :)
[18:03:30] <roberto__>	manyoso: it has a couple of problems with function-like cast and declarations
[18:04:01] <roberto__>	manyoso: i'm still trying to find a solution
[18:04:03] <manyoso>	as soon as we get a replacement for bdb, I'm going to stress it against some big codebases
[18:04:13] <roberto__>	manyoso: the best would be to parse the file in different passes
[18:04:21] <chouimat>	manyoso: try the ecos source code :)
[18:04:27] Join	adymo has joined this channel. (n=gremlin@ppp-222-74.wildpark.net)
[18:04:32] <manyoso>	wb adymo
[18:04:33] <roberto__>	manyoso: ohh yeah that things
[18:04:33] <adymo>	re
[18:04:41] <roberto__>	yo adymo
[18:04:41] <chouimat>	hi adymo
[18:05:07] <roberto__>	adymo: welcome mr eclipse (or mr google?) ;-)
[18:05:14] <adymo>	roberto__: hehe :)
[18:05:16] <manyoso>	roberto__: i tried doing a .klass file using a reinterpret_cast to serialize it into a file and then loading it with mmap
[18:05:37] <roberto__>	manyoso: i tried it too ... but then i understand that it's not so easy
[18:05:40] <manyoso>	roberto__: didn't work to well, and I'm not clear on how we'd store/access the .klass files
[18:05:41] <adymo>	i wonder what have i missed?
[18:05:47] <chouimat>	adymo: still playing with eclipse?
[18:06:04] <roberto__>	manyoso: another solution is to use a special memory allocator
[18:06:05] <adymo>	chouimat: as time permits, mostly bugfixing in my plugins....
[18:06:22] Quit	_jpetso has left this server. (Read error: 110 (Connection timed out))
[18:06:27] <manyoso>	roberto__: we can create a .klass file by just serializing it the normal way, but the real question is how we're going to then store/access them
[18:06:31] <manyoso>	and will it be fast enough
[18:06:32] <roberto__>	manyoso: /me is investigating
[18:06:38] <chouimat>	adymo: I'm currently trying to get eCos support working in kdev3 ...
[18:06:43] <roberto__>	manyoso: there is a cool library (a bit old) but nice called PTL
[18:06:54] <roberto__>	manyoso: persistent template library (or something like that)
[18:06:57] <manyoso>	roberto__: ok.  in the meantime I want to play around with Ian's idea of using some different alternative backends to bdb
[18:07:14] <roberto__>	manyoso: they use special allocators and iterators to serialize STL-like containers
[18:07:29] <roberto__>	manyoso: wait a sec.. i've the link somewhere
[18:07:37] <manyoso>	found it for PSTL
[18:07:44] <roberto__>	manyoso: cool
[18:07:44] <manyoso>	http://citeseer.ist.psu.edu/gschwind01pstl.html ?
[18:08:05] <roberto__>	manyoso: sorry! i forgot to send an email to you about it, but i was so busy with 4.1 and the devday
[18:08:12] <roberto__>	manyoso: actually i have another devday the next week :(
[18:08:16] <roberto__>	so i'm still busy
[18:08:23] <manyoso>	i know you are really busy.. that's ok
[18:08:37] <manyoso>	hopefully this weekly IRC meetings will help
[18:08:42] <roberto__>	manyoso: there is a nice paper that describe the library and the tricks they use
[18:09:06] <manyoso>	sometimes I have questions or come to a point where it's nice to have your input... these IRC meetings I think will really help with that

November 4, 2005

[09:28] <geiseri_> hiya rdale
[09:28] <rdale> hi Ian
[09:29] <geiseri_> rdale: did you see my email on kde-bindings about the scheme to make us able to use non C++ in KParts?
[09:29] <geiseri_> rdale: the goal being introduce this at such a low level its available to developers without them doing the dirty work
[09:30] <rdale> yes, although I haven't quite understood it. I think we need a purpose designed scripting api
[09:30] <rdale> dcop is too low level, and kparts is too low level
[09:31] <geiseri_> rdale: well i think my (probibly over ambitious goal) is to provide a way to dynamicly publish the part's interface
[09:31] <CIA-4> shaforo * r477675 / (87 files in 13 dirs): SVN_SILENT its never too late - pngnq & optipng all screenshots + add new ones
[09:31] <geiseri_> rdale: this way you can bind it on the fly, and we can design a proxy to forward the methods
[09:31] <rdale> parts have to have a ui don't they - shouldn't there be some other some of scripting plugin?
[09:32] <geiseri_> rdale: i think the killer of using nonC++ in kparts now is that we have no way to publish the interface with out doing it manually
[09:32] <geiseri_> rdale: at a high level they do
[09:32] <geiseri_> rdale: the base class the widget is not really exposed, ktexteditor uses this scheme
[09:32] <rdale> yes, and a higher level interface the just dcop. But I don't see it has to depend on KParts
[09:33] <rdale> the Kate dcop api is really hard to use
[09:33] <geiseri_> rdale: kparts has done a fair bit of the dirty work for us, KTrader, etc... personally i want to strip out what we dont need for non-gui plugins and make that a seperate class
[09:33] <geiseri_> but none the less this class must be able to load nonC++ components
[09:34] <geiseri_> rdale: yes, but im not talking about automation at this point, my focus is on using Ruby or Python to make a real extension to an app
[09:34] <rdale> I think we should start with the 'perfect' kjs scripting api, then wrap it for other languages
[09:34] <geiseri_> rdale: there should be no reason that you cannot do the ruby KDevelop support in ruby
[09:34] <geiseri_> rdale: if we do this like i envision
[09:35] <geiseri_> rdale: scripting (automation), i think is a different animal
[09:35] <rdale> that's the 'real extension to an app' usage you talk about above - ie for writing plugins in ruby. Scripting is different
[09:35] <rdale> yes
[09:35] * geiseri_ considers using ruby really programming, not "scripting"
[09:36] <rdale> me too
[09:36] <geiseri_> granted in my mind i see scripting and programming as differnt, some do not
[09:36] <rdale> maybe 'RAD' is the best description vs 'scripting'
[09:36] <geiseri_> rdale: yeah
[09:36] <rdale> with plugins in the middle
[09:37] <geiseri_> rdale: but the point is that technically we cannot do this with the current kparts, and i would like to solve this
[09:37] <geiseri_> rdale: since KDevelop and KOffice use KParts for plugins and extensions this is imparitive imho
[09:37] <geiseri_> rdale: there should be no reason why someone cannot write the java support in KDevelop in java per say
[09:38] <rdale> i did
[09:38] <geiseri_> rdale: did you solve being able to write a kpart in java?
[09:38] * geiseri_ was not sure what the state of that was
[09:39] <geiseri_> rdale: and if you did, what hoops did you have to jump through that we can make easier at a lower level?
[09:39] <rdale> it worked, but only i could maintain it i think
[09:39] <rdale> it needs a KDevelop project template, then it's easy
[09:39] <geiseri_> rdale: might be interesting to explore
[09:40] <geiseri_> rdale: telling people they can write koffice and kdevelop plugins in java could be a PR win
[09:40] <geiseri_> rdale: being able to write them in ruby would be a technilogical win
[09:40] <rdale> and more fun
[09:41] <geiseri_> rdale: and more fun == more developers ;)
[09:41] <rdale> indeed!
[09:41] <rdale> loads of java programmers, but not many good ones
[09:41] <geiseri_> rdale: same with ECMAScript ;)
[09:41] <geiseri_> rdale: but you saw that dude at akdemy when he found out about the Qtjava
[09:42] <geiseri_> rdale: do you have an idea of what it would take to make a ruby based kpart?
[09:42] * geiseri_ admits not to be following nonkjsembed stuff as closely :(
[09:43] <rdale> A KDevelop template really, not too hard. can a KOffice document map onto a DOM document or something?
[09:43] <rdale> for ECMAScript people?
[09:44] <geiseri_> rdale: im not sure what the inteface level looks like yet, i just want to load a simple bugger for now
[09:44] <geiseri_> rdale: if i can get hello world working, the dynamic interface publishing should be less convoluted
[09:48] <rdale> Qt4 is much better for introspecting an entire api - you can create a QMetaObject on the fly to describe an interface in terms of slots/signals
[09:49] <rdale> but slots/signals are too low level to expose directly to a scripting language
[09:49] <geiseri_> rdale: according to tronical this is very slow... but i do not have numbers to back that up
[09:49] <geiseri_> rdale: personally id like to go that way
[09:49] <rdale> what is slow?
[09:49] <geiseri_> calling QMetaObject::invoke
[09:49] <geiseri_> i guess it needs to earch the stringtable
[09:49] <rdale> not a problem for scripting, only ray tracing I think..
[09:50] <geiseri_> my opinion too
[09:50] <rdale> qt_metacall() is fine
[09:50] <geiseri_> rdale: but there you need to know the ids
[09:50] <geiseri_> granted, in theory you find those once, put them in a hash, and go from there...
[09:50] <rdale> you can look them up given the type signature of the slot
[09:51] <geiseri_> we do this in kjsembed now, but we have a few issues with polymorphism and optional arguments
[09:51] * chouimat wanders back in
[09:51] <geiseri_> not impossible to solve, just didnt get there yet :)
[09:52] <rdale> yes, I haven't done optional args or slot return types for Qt4 QtRuby yet
[09:52] <geiseri_> only a matter of time ;)
[09:53] <rdale> indeed world takeover is near
[09:53] <geiseri_> :)
[09:53] <geiseri_> in my fantasy in the KDE 4 world you dont need to know/care that your parts are not in C++
[09:54] <rdale> yes, me too. And normal humans will be able to script..