<freemangordon>
this happens if I do offline->online
doc has quit [Quit: Things to do]
gnarface has quit [Ping timeout: 272 seconds]
pere has quit [Ping timeout: 255 seconds]
pere has joined #maemo-leste
gnarface has joined #maemo-leste
<Wizzup>
freemangordon: that could be what I mentioned earlier, using a channel that is invalidated, but I would reckon that we also removing it from the qmap when it is invalidated
uvos__ has joined #maemo-leste
xes has quit [Quit: WeeChat 3.5]
<dsc_>
freemangordon: regarding specific TP questions, I am not a fan of lib/tp.cpp, tpqt, and rtcom in general, so asking me why hasChannel segfaults - i have no idea. Historically Wizzup has been working more on that side of the code anyway.
<uvos__>
Wizzup: the bouncing vhold on the xt91x is global everywere
<dsc_>
I can find out why it would segfault, but it takes me like +30min to even get familiar again with what happens, the terminology, etc.
<uvos__>
Wizzup: just a note btw tdlib has som issues in conversations
<uvos__>
1. only remote party notifications are fetched
<uvos__>
if i have a conversation with smeone via telegram later conversations will only have the messages of the other party, my own messages are missing
<uvos__>
2. when im present in leste all messages by sent by anyone are automaticly set to "seen" by leste
<uvos__>
this is very undesirable as any time the leste device is active all other telegram clients dont get any notification
<dsc_>
the only reason conversations uses rtcom is so can read a sqlite db, but in Qt we generally use Qt SQL for it
<dsc_>
well, rtcom goes via dbus, maybe it does some extra things, I am not sure. But I feel like it is unnecessarily complex.
<dsc_>
(or maybe rtcom does not go via dbus, i dont even know... :P)
<uvos__>
oh you just mean rtcom-el
<uvos__>
in pricipal rtcom is the whole stack
<dsc_>
yes, rtcom-el
<uvos__>
rtcom-el is pretty wierd yeah
<uvos__>
its both overgeneered and lacking
<dsc_>
also we need to mix glib in Qt because of it
<dsc_>
uvos__: marked as 'seen' is one of the more recent features
<dsc_>
ill note your description
<dsc_>
im working on such issues this week
<Wizzup>
uvos__: check @ bouncing
<Wizzup>
uvos__: I agree @ missing your own messages, I think we might ignore those somehow, will look (or dsc will)
<dsc_>
I was going to check memory increases today but ill wait for fmg's constructor refactor now :P
<uvos__>
dsc_: ok to be clear the problem is that messages are marked as seen when no conversations window is not open at all
<uvos__>
merly the present sate is enough
<uvos__>
tdlib seams to think that all chats are open and active at all times
<uvos__>
hence no notifications for other devices
<Wizzup>
yeah, this might be what freemangordon fixing in tp-haze
<Wizzup>
and then supporting in conversations
<Wizzup>
(chat state)
<Wizzup>
dsc_: we use rtcom because maemo uses rtcom, like, for everything related to real time communications
<Wizzup>
and yes it does more than just 'log to a database'
<Wizzup>
I think we're past that point now so it would be nice if we could stop having to doubt this frequently :D
<uvos__>
not a whole lot more really tho
<uvos__>
for rtcom-el
<uvos__>
it would be quite feasbale to just implement it again qtsql
<Wizzup>
it's read by notifications too
<Wizzup>
also used for persistent notifications
<Wizzup>
and it does a ton of stuff that you might not know about if you just reimplement it
<uvos__>
if the interface is getting in the way
<Wizzup>
it is not
<Wizzup>
there is no issue in mixing glib and qt, it's not causing us problems
<uvos__>
Wizzup: rtcom-el is simply very few lines of code
<uvos__>
Wizzup: so you could absolutly not miss anything
<Wizzup>
14k lines of code
<Wizzup>
8.5k without ui code
<Wizzup>
so no, it's not very little
<dsc_>
09:55 < uvos__> it would be quite feasbale to just implement it again qtsql if the interface is getting in the way
<dsc_>
yep, this
<Wizzup>
now, as far as the telepathy segfault, I can take a look but I need freemangordon's changes to do so
<Wizzup>
I don't mind looking at the tp code at all which is the divisions we've had before so there's no need to change it now
<dsc_>
< Wizzup> there is no issue in mixing glib and qt <== this is simply not true, by having glib and Qt you have introduced more dependencies to link against at the minimum, and at the maximum you have made querying a sqlite database a lot more complicated
<Wizzup>
I am not going to have this discussion again, sorry, this is super pointless
<Wizzup>
If you can't see why having to maintain two separate code bases for accessing rt com messages is not a nightmare then I don't know what to say
<Wizzup>
I also don't remember a single crash caused by using both glib and qt
<dsc_>
there are issues by having this setup and I cannot talk about them
<dsc_>
or they are ignored
<dsc_>
which is fine, but I keep bringing them so it is clear that part of the code is not what I would have preferred, e.g when fmg asks to do something I can say "i dont know" :)
<dsc_>
them up*
<Wizzup>
yes, like I said, I am happy to look at the tp stuff
<Wizzup>
just bounce it to me then
<Wizzup>
tp stuff or rtcom stuff
<Wizzup>
11:21 < uvos__> Wizzup: the bouncing vhold on the xt91x is global everywere
<Wizzup>
ok, it would be nice if we could try to fix it somehow, I can make some time again this week(end)... we have a lot of nlnet stuff to claim for devices and it's almost all like 99% of the way there (at least that is what it feels like)
<Wizzup>
did you need certain data from android on razr?
<Wizzup>
dsc_: btw it looks to me like _removeChannel should remove the channel from the channels QMap
<Wizzup>
because otherwise we keep invalid channels/pointers around
<dsc_>
if it keeps the keys around, I did so for a purpose
<dsc_>
most likely to facilitate the auto-join group feature
<dsc_>
and/or keep track of which channels it should join, but has not joined yet
<Wizzup>
the channels private qmap is only to keep track of telepathychannels that are valid
<Wizzup>
I don't think it stores anything related to autojoin
<dsc_>
ill check
<Wizzup>
I think those are different, and if we store things for autojoin we should just store the account + channel string
<Wizzup>
ok, I can also check, I just wanted to communicate what is likely the issue
ac_laptop has joined #maemo-leste
<dsc_>
hasChannel checks for key and value
<dsc_>
as the presence of a key does not mean its valid
<dsc_>
due to the reasons above
<dsc_>
thats how it was written anyway
<dsc_>
we could change that if thats better, im not sure
<Wizzup>
I don't think there is a point to keeping invalidated channels around, right?
<Wizzup>
at least to me that feels like keeping around pointers to freed memory
<Wizzup>
but maybe I am missing something
<dsc_>
yes that shouldnt happen
<dsc_>
somewhere it should destroy, and also set nullptr
<Wizzup>
so I think _removeChannel is called when we are informed that the channel is no longer usable, and then telepathyqt just removes it
<Wizzup>
so I think it gets destroyed already (I am not sure, I can check a bit later) and our nulling would be removing it from the qmap
<dsc_>
there's also leaveChannel()
<Wizzup>
I think leavechannel can just ask to leave the channel and then _removeChannel will be called eventually
<Wizzup>
but that is my bet
<dsc_>
leaveChannel actually removes the key
Livio has joined #maemo-leste
<Wizzup>
yeah I saw it does currently, but I am not sure if it has to if _removeChannel does it
<Wizzup>
I think they could both do it though, then one just becomes a no-op
<dsc_>
right yeah
<dsc_>
uvos__: regarding point 1 "my own messages are missing", could you re-try with a fresh rtcom db?
<dsc_>
just as a quick test
<dsc_>
i suspect that will just work
<uvos__>
dsc_: shure i will
<uvos__>
can you remind me where the db is stored again
<dsc_>
uvos__: ~/.rtcom-eventlogger/
<dsc_>
el-v1.db
<dsc_>
< uvos__> 2. when im present in leste all messages by sent by anyone are automaticly set to "seen" by leste <== 90% sure Conversations does not do this, message are only marked as 'read' when chatWindow is opened, once
<dsc_>
maybe the telegram plugin does?
<uvos__>
maybe unfotionatly theres a lot of layers involved here
<uvos__>
any one of them could be at fault
xes has joined #maemo-leste
<Wizzup>
the best way to verify if we get them at all is to look at dbus-monitor when we send a message from a different device
<Wizzup>
then we will know if conversations receives it from tp-haze
<Wizzup>
if it does, then we can fix conversations to store it correctly
<Wizzup>
otherwise we need to look at haze, and if haze doesn't even get it, then we need to look at tdlib purple
<Wizzup>
(which could be tested from within pidgin, without any tp stuff, to see if pidgin gets these messages)
Livio has quit [Ping timeout: 268 seconds]
Livio has joined #maemo-leste
DFP has joined #maemo-leste
uvos__ has quit [Ping timeout: 268 seconds]
uvos__ has joined #maemo-leste
ceene has quit [Read error: Connection reset by peer]
Livio has quit [Ping timeout: 268 seconds]
Guest93 has joined #maemo-leste
<dsc_>
i may have identified rtcom-el as the cause for some mem increases (or how conversations uses it)
<dsc_>
needs further investigation before drawing conclusions though, so brb
nmdv has joined #maemo-leste
uvos__ has quit [Ping timeout: 260 seconds]
Guest93 has quit [Quit: Client closed]
<dsc_>
results seem promising
System_Error has quit [Remote host closed the connection]
<freemangordon>
dsc_: as a side note: qt itself uses glib behind the scenes
<freemangordon>
so qt vs glib is simply pointless
<freemangordon>
to me it seems the checks in hasChannel are not enough
<freemangordon>
Wizzup: sure, I can provide the code
<freemangordon>
code changes that is
<freemangordon>
but I am almost sure segfault is unrelated, besides that is calls hasChannel() buy the time channels map contains dangling pointers
<freemangordon>
which should not happen
<freemangordon>
*by the time
arno11 has joined #maemo-leste
<Wizzup>
yes, I think we discussed this backlog
<Wizzup>
dsc_: cool @ memory!
<arno11>
dsc_: great @ memory !!!
<dsc_>
i just need to check if its my fault before I explain what I found (so I can prepare everyone making fun of me ;'))
<dsc_>
but yes pretty sure this improves things
<dsc_>
but im also not satisfied with QML but thats a different story
<dsc_>
however I am still not satisfied with some memory usage, possibly related to QML/ChatWindow (opening and closing doesnt return the 'expected' amount of memory)
<dsc_>
so ill continue tomorrow
pere has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
Livio has joined #maemo-leste
System_Error has joined #maemo-leste
<freemangordon>
dsc_: qml will not free until GC is run
<freemangordon>
so maybe run GC manually before measuring memory usage
arno11 has joined #maemo-leste
Livio has quit [Ping timeout: 264 seconds]
<Wizzup>
dsc_: great work!
<Wizzup>
I think we can make a new -devel release with just this
<freemangordon>
Wizzup: do you want my changes or you could give me a hint where to remove the channel (and when)
<Wizzup>
sure, I did mention a fix in the backlog, which is to do channels.remove(...) in _removeChannel
<Wizzup>
but if you push the code to a branch I can take a look too
<dsc_>
freemangordon: closing a chatWindow destroys the QML widget in its entirety, but memory usage doesnt return close to what it was
<Wizzup>
dsc_: if you do that a few times, does it still increase?
<dsc_>
Wizzup: it does, but it stops after a while. its not linear
<Wizzup>
the first time might be some cache in qt / loading new so's
<Wizzup>
hm
<Wizzup>
dsc_: shall I make a new -devel release?
<dsc_>
yes
<dsc_>
thanks
<dsc_>
i also did some testing today with javascript's gc()
<dsc_>
but I dont have anything to report on that front yet
<freemangordon>
Wizzup: ok, will try
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
<dsc_>
Wizzup: i'd like to get one more thing in
<dsc_>
(if you did not update already)
<Wizzup>
ah
<Wizzup>
ok, let me git tag -d the tag
<freemangordon>
also, I am about to push segfault fix