Conversation with nekrad@im.flosoft.biz at Пнд 28 Дек 2009 23:08:53 on slavazanko@gmail.com/Work (jabber)
(23:08:53) nekrad@im.flosoft.biz/Home: yep
(23:09:00) nekrad@im.flosoft.biz/Home: did you already have a look at the MC-testfarm branch ?
(23:12:50) slavaz: not... just await, please...
(23:15:25) slavaz: hm... do you make changes into '1891_testfarm' branch ?
(23:16:53) slavaz: os, another question: is you see commits into '1891_testfarm' branch?
(23:18:23) slavaz: git checkout -b MC-testfarm origin/MC-testfarm
git diff origin/master
seems as very strange changeset...
(23:21:19) nekrad@im.flosoft.biz/Home: no, i didnt touch the 1891 branch.
(23:21:42) nekrad@im.flosoft.biz/Home: MC-testfarm branch has nothing to do with it. its not even derived from master - completely on its own
(23:23:27) slavaz: Ah, ok.
(23:30:09) slavaz: But.. Enrico, is you see my '1891_testfarm' branch?
(23:30:55) slavaz: is you have some advansed 'configure testcases' for additonal?
(23:35:37) nekrad@im.flosoft.biz/Home: not yet, have to go through it first ...
(23:36:28) nekrad@im.flosoft.biz/Home: btw: did you already have a look at the 1872 (build fixup) branch ?
(23:36:33) nekrad@im.flosoft.biz/Home: its needed for a clean build ;-p
(23:39:33) slavaz: Yep, I was see in 1872 branch... but some commits is now unapplicable. Enrico, perosonally I'm want to 'clean different branch' for adding mvfs stuff into upstream branch. Now it's look as much more branches with little expansion of mvfs stuff.
(23:41:31) nekrad@im.flosoft.biz/Home: no, that mvfs-related stuff is only an cleanup of missing AM_CONDITIONAL()'s
(23:41:44) slavaz: this is no way, sorry. I'm not fo opposite of mvfs.I'm opposite of liittle-steps adding of mvfs stuff. Better to review mvfs to ading as one-
(23:42:30) slavaz: uncompleted thing, sorry :)
(23:42:34) nekrad@im.flosoft.biz/Home: its not about adding mvfs at all - its just about fixing current master
(23:42:58) nekrad@im.flosoft.biz/Home: obviously, some long time ago, somebody accidentially merged some unfinished parts
(23:43:17) nekrad@im.flosoft.biz/Home: this only comes up on --disable-vfs
(23:43:20) nekrad@im.flosoft.biz/Home: just try it yourself
(23:46:38) slavaz: ok, i'll try this tomoroow. Now, as I wrote, I'm too drink (Corporate party now), sorry
(23:49:02) slavaz: And, Happy Merry Christmas (for me, this doing at 7 january, because I'm an Ortodox)
(23:49:43) slavaz: Enrico, happiness to you and your family :)
(23:54:07) nekrad@im.flosoft.biz/Home: thx, same to you :)
(23:57:52) slavaz: ok ;)
Next question: do you work into critical-to-size-of-application corporatin? Sorry, I'm not aware of your events... may be, I'm more do understand your dislike to glib...
(23:58:12) slavaz: corporatin = corporation, sorry :)
(23:58:35) nekrad@im.flosoft.biz/Home: exactly
(23:58:58) nekrad@im.flosoft.biz/Home: i'm developing firmware for embedded/small-devices
(23:59:42) nekrad@im.flosoft.biz/Home: for now we just cant use mc, not just because of size, but also since glib isnt crosscompilable
(00:00:11) slavaz: > glib isnt crosscompilable
(00:00:14) slavaz: ops
(00:00:24) slavaz: i't surprise for me :(
(00:00:25) nekrad@im.flosoft.biz/Home: to make it work on our targets, it must be cross-compilable via sysroot'ed toolchains (in one pass)
(00:00:47) nekrad@im.flosoft.biz/Home: well, it is possible to crosscompile it, but COMPLICATED
(00:01:10) nekrad@im.flosoft.biz/Home: and btw: mc is the only package here which needs glib
(00:01:43) slavaz: I meant that glib it's an cross-compile stuff and mc will based on this axiom...
(00:01:59) slavaz: > mc is the only package here which needs glib
(00:02:05) slavaz: ops #2
(00:02:07) nekrad@im.flosoft.biz/Home: no, you're talking about cross-platform
(00:02:12) nekrad@im.flosoft.biz/Home: thats an totally different issue
(00:02:30) nekrad@im.flosoft.biz/Home: crosscompiling means: build package for target X on some system Y
(00:03:18) nekrad@im.flosoft.biz/Home: glib is made by entirely desktop people, they dont even consider that some wants to crosscompile a whole distribution
(00:04:12) nekrad@im.flosoft.biz/Home: guess what their suggestion is: build an entire system (_WITH_ compiler) for your target and run the compiling within emulation (qemu, etc)
(00:07:16) slavaz: > mc is the only package here which needs glib
well... Glib have to much a good debugged algorithms... like to GStrigngs, GList, GPtrAray. I think, glib like to STL for C++...
If we will have fully-worked replacement for glib (may be eglib) - we may include it onto repo (I will be able to influence the views of other developers)
(00:08:56) nekrad@im.flosoft.biz/Home: with the amount of works you're putting into the whole glib-rewrite, you can do it all in your own much more efficiently
(00:09:43) nekrad@im.flosoft.biz/Home: eg most of the gstring appearances can be easily done with a temporary buffer
(00:09:49) nekrad@im.flosoft.biz/Home: maybe packed into some small macros
(00:09:53) nekrad@im.flosoft.biz/Home: really no magic
(00:10:40) nekrad@im.flosoft.biz/Home: glib doenst save anything here, but adds an dependency to some package which is not just fat, but also known to be unstable
(00:10:52) nekrad@im.flosoft.biz/Home: glib API is NOT stable
(00:14:30) slavaz: of course, but not in any cases. Nor more unstable, than self-written-stuff.
First version of mhl-related tsuff was unsucessfull in many reasons:
1) don't able to check code in other projects (in opposite, glib-related stuff is automatically checked into all gtk-related programs)
2) not sure that is is an one-by-one code from glib-library
BUT!
You may don't beelive to me, but I'
(00:14:50) slavaz: I'm agree with glib-replacement code
(00:15:11) slavaz: but this is must be not MHL-inline code
(00:15:37) slavaz: we must have choise about usage of libraryes
(00:16:10) slavaz: and glib not an ultimate truth
(00:16:52) nekrad@im.flosoft.biz/Home: why not having a small set if tiny macros/inlines ?
(00:17:36) nekrad@im.flosoft.biz/Home: or maybe start an own small lib for that
(00:17:45) slavaz: well... I'm agree with idea of sharing code
(00:18:00) slavaz: less inlines, more shares
(00:18:32) nekrad@im.flosoft.biz/Home: why not inlines ?
(00:18:42) nekrad@im.flosoft.biz/Home: many times the compiler can do much better this way
(00:18:42) slavaz: plugins will hit in this concept too (i was discuss about)
(00:18:53) nekrad@im.flosoft.biz/Home: no, please no plugins
(00:18:57) nekrad@im.flosoft.biz/Home: thats a very bad idea
(00:19:00) slavaz: why?
(00:19:16) nekrad@im.flosoft.biz/Home: makes everything much much more complex
(00:19:24) slavaz: dlopen/dlclose - bad idea???
(00:19:28) nekrad@im.flosoft.biz/Home: and so quite undebuggable ;-o
(00:19:31) nekrad@im.flosoft.biz/Home: yes, very bad
(00:19:33) nekrad@im.flosoft.biz/Home: unpredictable
(00:19:56) nekrad@im.flosoft.biz/Home: and of course it needs dynamic shared library support on your target
(00:20:17) nekrad@im.flosoft.biz/Home: just try it on an mmu-less cpu ;-o
(00:20:19) slavaz: oh... man... I want to really UNIX-way project... one part may do no much... but do it good as well
(00:20:41) nekrad@im.flosoft.biz/Home: the big question here is: why plugins at all ? what benefit should they bring exactly ?
(00:21:02) slavaz: Hm... is no any target system sypport of dynamic load library?
(00:21:17) slavaz: sypport = support, sorry
(00:21:31) nekrad@im.flosoft.biz/Home: mmu-less targets tend to have no shared libraries at all
(00:21:53) nekrad@im.flosoft.biz/Home: (or quite difficult to handle9
(00:23:02) nekrad@im.flosoft.biz/Home: and embedded systems (even if they have an mmu) tend to come without shared libraries at all, for efficiency
(00:23:25) nekrad@im.flosoft.biz/Home: again: what exactly do you want plugins for ?
(00:25:49) slavaz: for things about which we do not know
(00:26:15) slavaz: for example: we don't plan of realize webdav stuff
(00:26:27) slavaz: but if someone wants...
(00:26:36) slavaz: do you understand me?
(00:26:50) nekrad@im.flosoft.biz/Home: why not just having external servers ?
(00:26:50) slavaz: but!
(00:27:06) slavaz: ops
(00:27:18) nekrad@im.flosoft.biz/Home: let these things just be an 9P fileserver
(00:28:02) nekrad@im.flosoft.biz/Home: plugging external code into the process is very tricky, makes debugging / qm extremly hard
(00:28:58) slavaz: yep, good old technology... But what you say about DeviceKit(older name hal)?
(00:29:16) slavaz: Life don't stop on one place
(00:29:29) nekrad@im.flosoft.biz/Home: no, thats even worse
(00:29:59) nekrad@im.flosoft.biz/Home: things like hal is exactly that kind of insanity i want to stop
(00:30:02) slavaz: and I want to search good solution for this
(00:30:08) slavaz: may be plugins?
(00:30:34) slavaz: I want to searh good FUTURE solutin
(00:30:43) slavaz: solution, sorry
(00:31:19) slavaz: and this reason for unaccepted mvfs-related stuff into master now
(00:31:35) nekrad@im.flosoft.biz/Home: what problem do you have with mvfs exactly ?
(00:32:21) slavaz: No problem. Exactly:
$ yum search mvfs
No results found
(00:32:40) slavaz: This mean: need to add support of mvfs into mc project
(00:33:07) nekrad@im.flosoft.biz/Home: no, it's simply up to the distros to pick mvfs up
(00:33:36) slavaz: is you sure?
(00:33:47) nekrad@im.flosoft.biz/Home: it shouldnt be that hard adding just one library (actually, two ;-p) into some distro
(00:34:24) nekrad@im.flosoft.biz/Home: i'm not comfortable w/ the debian/fedora workflows, but for gentoo its about half a few mins
(00:35:11) slavaz: Ok, what about LTS (Long-Time-Dostros)?
(00:35:29) nekrad@im.flosoft.biz/Home: can't they just add another library ?
(00:41:44) slavaz: Do not get us wrong: we don't need to add any additional code into project. If code was use in another project - then this code will use in our project. This about own samba-code (whill dropped in near time and will replaced for libsmb.so calls)
also, this related for any other code-related stuff. If it's will be replaced via library code - this must be replaced via library code. Not needs for write agains already-written code. May be already-written code have mistakens... ok, but this is not uor mistakens. We will bugreport upstream of used projects about this...]
(00:43:04) nekrad@im.flosoft.biz/Home: right. the very same you can do with libmvfs
(00:43:17) slavaz: in ideally case, we will have less-size core system
(00:44:09) nekrad@im.flosoft.biz/Home: right, thats where i want to go, too
(00:44:19) slavaz: and if someone wants, he wil have colorized, ftp/shell/webdav/curl extended; filenames colorhighlight system
(00:44:31) nekrad@im.flosoft.biz/Home: thats one of the reasons, why mvfs one day should replace internal vfs
(00:44:35) slavaz: but this is not in minimal complectation
(00:46:00) nekrad@im.flosoft.biz/Home: ?
(00:46:11) slavaz: Enrico, ok, I'll learn your mvfs stuff in near time... but need to counterproposal: I'll may too much question about logic work...
(00:46:30) slavaz: is you ready to ASK?
(00:46:58) nekrad@im.flosoft.biz/Home: you can ask me anytime
(00:47:10) slavaz: ok, not toonight ;)
(00:47:33) slavaz: And Enrico: you good man.
(00:47:57) slavaz: I's too much drink, I know ;)
(00:49:10) nekrad@im.flosoft.biz/Home: just have a look at the mvfs*.c files, it's fairly trivial - most of the code is just adaption to mc-vfs
(00:57:11) slavaz: Okay. But! Fur less of chaos need to completelly cleanup of mvfs-related stuff from master branch and add this stuff again. Now for other developers this stuff seems as dirty (sorry). And, next proposal, not often rebase, please. I (and any other delevoper) know about this problem. But needs publish (and publish resintst of rebase) if (and only if) this will make confflicts with current master (git rebase will produse conflicts). In any other case, feel to free rebase&merge your branch onto master. May be, this will prodused some bugs in 'master' branch... but this better to mainain&support by other developers...
(01:01:41) slavaz: oh... , I meant, needs to go at hone
(01:01:53) slavaz: go at home and sleep. :)
(01:02:01) slavaz: Sorry, Enrico :)
(01:02:31) nekrad@im.flosoft.biz/Home: okay, i'll rework it ...
(01:02:54) slavaz: ok :)
(10:22:22) nekrad@im.flosoft.biz/Home: ping