So there wasn't a Delete operation at the time I started writing this? Oops
:)
At the moment, the key and value are both the full address. If you want
to change it to a hash later, that's fine, but please let me finish the
application
logic first.
Ah, you found my bug and fixed it already? Thanks!
Ok, I see that. When you call Put() you're transferring control of the memory
to the hash table; it doesn't copy it over.
But why did you fix it the long way instead of just calling strdup() ?
Considering that Uncensored is currently spinning 100% cpu on citserver, I'd
say that's still the big issue.
Mo Apr 26 2010 18:09:34 EDT von IGnatius T Foobar @ Uncensored Betreff: Re: Citadel commit log: revision 8533
Considering that Uncensored is currently spinning 100% cpu on citserver, I'd say that's still the big issue.
could we have a core of that?
hm, it seems as if the next page link is added if there is no new
message for that page yet.
Is that intended? or is it a bug?
It has to do with the calculation of the number of messages per page ...
there's an off-by-one condition that triggers in certain situations.
The CHAT command was implemented during a time when we didn't use worker
threads;
every session was bound to one socket and one thread, and that was it.
Yes, we'll get past that, but NOT RIGHT NOW!!
Also keep in mind that START_CHAT_MODE is also used in some other places,
for example,
but the client is intended to send the message then and terminate, right?
so its one command which may consist of two back and forth iterations?
I don't see much sense debugging it in the state its currently in.
So let me get this straight ... the chat code that has been working fine
for 12 years, needs to be rewritten because it doesn't work nicely anymore
after you changed the transport underneath it?
This is my problem why?
Sa Mär 27 2010 13:45:43 EDT von IGnatius T Foobar @ Uncensored Betreff: Re: cmd_chat
I don't see much sense debugging it in the state its currently in.
So let me get this straight ... the chat code that has been working fine for 12 years, needs to be rewritten because it doesn't work
Ok, well I do agree that the chat protocol is suboptimal and needs to be
rewritten
.. just not during a feature freeze. In the future we should make the chat
protocol look more like the instant message protocol.
If we need to stop the bleeding, right now we could just disable the server
I'll be in and out of consciousness all weekend long.
Ok, I looked at those diffs and they were indeed quite straightforward without a
lot of surface area for new bugs.
I'm at a VMware seminar this week so I have limited computer time, but I'll
update my dev system when I get a chance to test the most recent fixes.
if it gets fed with
[[a][b]], '[', ']'
what should the result look like?
To be honest, I haven't thought about that. Since it starts on the left side
first, it would probably extract b .
The fix was going to be to make sure the request messge was in the
current room.
Anyone know if this has been fixed?
Not yet.
Hmm, SMTP outgoing fails? since when? I'm running my branch server and it
seems to be working fine and its merged with the trunk HEAD (more or less).
Well, a couple of days ago when I upgraded Uncensored to svn trunk/head we
began
to see a problem where all outgoing SMTP
* CtdlOutputPreLoadedMsg: use length calculated by safestrncpy instead of
doing
strlen on each loop iteration
No really, I mean it, NO MORE OPTIMIZATIONS until we fix the bugs introduced
by
all previous optimizations!!
hmm ... that didn't fix it. The problem is somewhere else. :(
which fixes the saving of messages via imap.
messages copied in so far are b0ken, their unparsed headers are glued
together without newlines :-(
I think the reason I thought there was more to it than that was because it had
gone unnoticed for a long time.
By the way, it
Mo Mär 01 2010 23:58:54 EST von IGnatius T Foobar @ Uncensored Betreff: Re: Citadel commit log: revision 8375
When pidgin sends to webcit the message is slightly corrupted Seems the last char is dropped and probably the terminating NUL too.
I have identified this as a bug in
let me take an educated guess... It fails to output a \0 if there is
a string without newline?
so aoeu\0aoeu wouldtrigger the issue?
That sounds about right. We are definitely giving it strings without a
trailing
newline.
When pidgin sends to webcit the message is slightly corrupted. Seems the last
char is dropped and probably the terminating NUL too.
I have identified this as a bug in memfmout(). When I use cprintf() it goes
away.
Interesting.
That would explain a lot.
Thu Feb 25 2010 01:02:24 EST from IGnatius T Foobar @ Uncensored
Subject: Re: async stuff
Ok, it seems that the buffered I/O *is* causing a problem.
sysdep.c : 1147
HaveMoreLinesWaiting() *always* returns 1, until the session ends. As a
I made several assumptions on the types of contexts that could be selected on
and which ones to check the fd of after select. Maybe these assumptions are
flawed.
What exactly happens to the context when an async message is sent?
Check out modules/xmpp/xmpp_queue.c arolines
Got it.
Yep, its broken, definately, Now I have that description its obvious.
To fix the problem with re-used fd-s before contexts got cleaned / removed
and crashing and all that I went to great pains to ensure we only chose
contexts with activity on the fd to bind to. I didn't consider that
IG, I'm trying to test this but my pidgin won't connect.
It reports unknown error.
In the citserver log I get Ignoring unknown tag bind just before the
connection gets closed.
Wed Feb 24 2010 08:33:14 EST from IGnatius T Foobar @ Uncensored
Subject: Re: asynch not working
Fix async messages (hopefully).
Nope.
OK, so what exactly (versions) do I need to test this.
I can't get my pidgin to connect.
Wed Feb 24 2010 12:49:35 EST from IGnatius T Foobar @ Uncensored
Subject: Re: Citadel commit log: revision 8370
Fix async messages (hopefully).
Nope.
If you send a message from Cit client to pidgin the message doesn't arrive.
Got that bit.
Question. Does the message from Cit client arrive when pidgin sends a new
message to Cit client?
Wed Feb 24 2010 08:33:14 EST from IGnatius T Foobar @ Uncensored
Subject: Re: asynch not
If you send a message from Cit client to pidgin the message doesn't arrive.
Got that bit.
Question. Does the message from Cit client arrive when pidgin sends a new
message to Cit client?
It should, at least it did when I tested it.
Pidgin should also receive
As soon as my pidgin sends to the citserver the citserver dives off into an
endless loop in dothebarts new buffered IO code.
Now thats a different problem that causes me issues instead.
I didn't see that, but perhaps I'll try it again.
By the way, Citadel clients *poll*
Ok, it seems that the buffered I/O *is* causing a problem.
sysdep.c : 1147
HaveMoreLinesWaiting() *always* returns 1, until the session ends. As a
result,
we never fall through the loop until the session is ending, which explains why
we
never get around to processing our async
* use mmap to read the download file for output; this way we don't need to
copy
it into memory first and can let the kernel do this job
Does mmap() read the whole file into memory at the kernel level? Or does it
merely provide userspace with the illusion that this has happened?
Fair enough. Is it portable?
Damn, I realy thought that was the hole.
It has to be something like that but obviously its not that particular hole.
Hmm, do I want one of my small networks that is connected via ADSL at 2M/512K
to be battered to death with spam when you change the MX
Hmm, not sure about that one.
Not a problem, let me know when you're ready. And don't worry, it won't
saturate
a 2M link because most of the spam is for accounts that don't exist (actually,
all of it, since I'm not actually running that company, but I did activate a
couple of addresses such as info@ so a little of the mail
Sun Jan 31 2010 09:10:58 AM EST from dothebart @ Uncensored Subject:
Re: Citadel commit log: revision 8262
doesn't mstone offer a way to produce similar effects when ran from several
hosts in your local network?
It does.
Problem is I don't have several machines
I would say that it should be decoded by libcitadel when the vcard is
deserialized into our in-memory data structure.
I have the ability to slam a server with connections, through the use of an
abandoned domain name that gets a TON of nonstop spam. I'll give it a try.
Sorry dude:
2010/01/30 12:48:31.967497 Closing socket 60
2010/01/30 12:48:31.967520 Done with RemoveContext()
2010/01/30 12:48:32.002170 Interrupted CtdlThreadSelect.
2010/01/30 12:48:32.002234 Thread Worker Thread caught signal 1.
2010/01/30 12:48:32.002284 Thread Worker Thread (0xa8ec4b90)
davew: if you want, I can point this mega-spam domain's MX record at the server
of your choice so you can work on the thread issue. It usually only takes a
little while to make the problem come up.
Yep, that looks like exactly the bug. Must be something not atomic somewhere.
I've done with work for this week so I'll probably get to it this weekend :-)
Thu Jan 21 2010 03:31:16 PM EST from davew @ Uncensored Subject: Re:
Citadel commit log: revision 8249
Wed Jan 20 2010 12:39:12 PM EST from IGnatius T Foobar @ Uncensored
Subject: Re: Citadel commit log: revision 8249
For what it's worth, this issue is getting exposed
I'm showing it on a 32 bit machine. Do you want a core dump and log sample?
Last coupla lines of logs...
2010/01/21 2:18:20.198476 New client socket 33
2010/01/21 2:18:20.228583 [36312] SMTP server: QUIT
2010/01/21 2:18:20.229020 Purging session 36312
2010/01/21 2:18:20.229089 RemoveContext() session 36312
2010/01/21 2:18:20.229116 [36312] xmpp_queue_event(1, )
For what it's worth, this issue is getting exposed by a test server that is
constantly getting hammered with an extremely large volume of spam, so there is
a
large incoming SMTP load.
Fr Jan 15 2010 12:55:46 EST von scianos @ Uncensored Betreff: Re: Subversion
Jan 10 2010 7:44am from dothebart @uncnsrdSubject: Subversion
So Jan 10 2010 10:08:07 EST von davew @ Uncensored Betreff: Subversion What tools are people using to access Subversion?Are you
Jan 10 2010 7:44am from dothebart @uncnsrd
Subject: Subversion
Â
So Jan 10 2010 10:08:07 EST von davew @ Uncensored Betreff:
Subversion
What tools are people using to access Subversion?
Are you using the command line or some front end tool.
r8201 *completely* broke the networker.
Fix race condition that caused segfaults in imap and xmpp as seen on
uncensored.
Ok, I'm gonna put that into production.
Cool. Thank you.
Pushing an update out to Easy Install now. (I will continue to do this at
any time during the stable-77x series, under the assumption that
everything committed to that branch is indeed stable.)
Give it a try. I think it's pretty nice!
Is that the whole change?
r8154 fixes the Slashdot feed (which is really a disgusting mess of xml
that should be taken out back and shot)
Easy Install has been updated to stable-77x. Tarballs to follow, after
we let a few people act as guinea pigs :)
I wonder if I should strip the new bbsview code out of stable-77x, since
it's not going to get used anyway?
ok, done; I hope no more old messages make it over? ;-)
Yeah, I don't know what happened there.
Should we put this code in stable too?
Thu Dec 17 2009 08:01:42 PM EST from IGnatius T Foobar @ Uncensored
Subject: Re: Citadel commit log: revision 8139
Sounds very cool, but is this going to be one of those things that only
davew understands and therefore becomes difficult to maintain?
Take a look at
Fri Dec 18 2009 05:52:58 PM EST from IGnatius T Foobar @ Uncensored
Subject: Re: Citadel commit log: revision 8139
TDAP purges a message when its reference count reaches zero. Dig dis:
* Whenever a message is saved to a room, or removed from a room, we write a
record to
Sounds very cool, but is this going to be one of those things that only
davew understands and therefore becomes difficult to maintain?
Our URL parser handles either one, but the '' gets interpreted by Tidy as
an error.
in which actual content? is it realy that way in xhtml? Or is there just some wrong encoding in some other place?
How unrecognizable is the dav server going to be when I eventually get
around to implementing CalDAV?
Mo Nov 23 2009 15:16:33 EST von IGnatius T Foobar @ Uncensored Betreff: Re: Citadel commit log: revision 8076
How unrecognizable is the dav server going to be when I eventually get around to implementing CalDAV?
well...
The current changes are here to aid me in developing; its a bit
Ok, well you can do all the unit tests you want; the real test is whether
Kontact still works.
Mo Nov 23 2009 17:59:25 EST von IGnatius T Foobar @ Uncensored Betreff: Re: Citadel commit log: revision 8076
Ok, well you can do all the unit tests you want; the real test is whether Kontact still works.
Yes, definitely. But its not needed for it all the time. Even cadaver seems to
There should be no requirement to kill any thread other than excess
workers
No. There should be no requirement even to cancel excess workers. Don't
use pthread_cancel, just set a volatile variable somewhere and wait for
them to die gracefully.
(Actually, I personally just use a
It was thoroughly tested though but it with it haveing been disabled it
may
well be out of sync with other code.
Where's the coverage analysis?
Y'all are thinking too much. The original thread manager was deliberately
made simple, almost naive. I don't see any need to ever reduce the size
of the thread pool, and I certainly don't see any need to gracefully shut
down anything other than the database. Quite frankly, I think we should
I most probably could use some hints on the duplicate detection,
since it seems as if it doesn't work with the atom of freshmeat..
It's quite simple: if there is a guid field present, we prepend rss/
to it, and hit the use table to determine whether it's a duplicate. If
kinetix: if the method used by Easy Install doesn't work for you, then I'm
not sure what else you could try. It took a while for me to figure out
that method, and it seems to have worked for countless thousands of Easy
Install users.
I suppose your other option would be to do your test
IG: Heh, that's exactly what I setup yesterday - 64-bit gentoo in a VM, and
with -only- the svn code on it, it still doesn't build webcit.
Hey, nothing ventured nothing gained, right? Enjoy your development
platform.
kinetix:
Forgive me if I'm late to the game and you've already tried this, but ...
Have you looked at the Easy Install script to analyze what it's doing?
It contains all of the necessary flags for building a private copy of
Citadel with private copies of its libraries.
* identify the room we're in by REST; first draft.
Ummm ... isn't DAV already REST by its very nature?
/groupdav/roomname/...
Mo Nov 09 2009 08:38:05 EST von IGnatius T Foobar @ Uncensored Betreff: Re: Wiki Rooms
Hmm, I was thinking more about a list of every page in the wiki so I can just browse it instead of having to search on some random keyword that may or may not be included in every page.
Sure, why not?
Tue Nov 10 2009 03:54:06 AM EST from dothebart @ Uncensored Subject:
Re: Wiki Rooms
badly described submissions, too many feature requests, and just too much
*crap*
to be useful ... so much that I seldom even bother with it anymore
unless someone brings a particularly nasty bug
Sun Nov 08 2009 07:58:25 PM EST from IGnatius T Foobar @ Uncensored
Subject: Re: Wiki Rooms
The full text index is of course active for Wiki rooms. We just have to
write some code to display the search results in a sensible way.
Fleeb came up with a brilliant idea: we should
hm, having some list of the most important incidents here in a wiki room might be a good thing to have since bugzillas bug administration interface is a pure nightmare.
While tasks (my last aproach do tackle this) deliver a better overwiew than bugzilla, no change tracking is there.
I don't
Hmm, I was thinking more about a list of every page in the wiki so I can just
browse it instead of having to search on some random keyword that may or may
not be included in every page.
Sure, why not? For search, we could use the very same renderer with a
search-reduced list of pages.
As
The full text index is of course active for Wiki rooms. We just have to
write some code to display the search results in a sensible way.
Fleeb came up with a brilliant idea: we should use Wiki rooms for our
internal bug tracking. That way we can annotate stuff as much as we want.
And
Fri Nov 06 2009 10:14:42 PM EST from IGnatius T Foobar @ Uncensored
Subject: Re: housekeeping
Wow. Big lose.
There is a recipient on the Citadel Support mailing list who lives at a
server that isn't responding. It's taking 4 minutes for the connect to time
out. Meanwhile,
Mon Nov 02 2009 07:02:23 PM EST from scianos @ Uncensored Subject: Re:
Citadel commit log: revision 7989
This should really be a configurable parameter for production environments.
It is absolutely possible for a busy mail server to reach =1.0
- Stu
It will
If I fill in the subject and then hit the RETURN key it posts the
message
which is usally empty.
Aha! I was wondering why there have been so many blank posts lately.
Yes, we have to fix that.
the reworked knrooms is done, still some work with the dav stuff is needed.
since i've started workin on it in a branch, we are not inclined to have it in 7.70
I just need to commit another configure snippet.
Re. contexts -- I'm not sure what exactly that would involve, but I
definitely would like to get a new release of Citadel finished before we
make any dangerous changes.
Let's start thinking about Citadel 7.70 and what it will take to get it
finished. I already hit my target (wiki rooms)
Sun Nov 01 2009 11:28:50 PM EST from IGnatius T Foobar @ Uncensored
Subject: Re: Spider Monkey
Even so, I'm still inclined to avoid using it for anything other than
the parser. Mozilla's future is unclear and I think it would be a
strategically bad move to tie our fortune to
Anyway, the only reason I was erring on the side of SpiderMonkey is
because
most people seem to have it in their distro already whereas V8 doesn't
seem
to be so prevelent yet.
The other issue with V8 is that it's a JIT engine, which restricts the OS
and CPU choices of the
My test server now spits out Server strangled due to machine load
average too high once per second.
Mon Nov 02 2009 11:54:17 AM EST from IGnatius T Foobar @ Uncensored
Subject: Re: Citadel commit log: revision 7989
My test server now spits out Server strangled due to machine load average
too high once per second.
Hmm, so the load average (as per uptime) divided
Isn't that how greylisting is supposed to work?
Mo Nov 02 2009 17:36:20 EST von IGnatius T Foobar @ Uncensored Betreff: Re: participate and greylisting?
Isn't that how greylisting is supposed to work?
but why are several mails showing up in my smtp queue?
Oct 25 2009 4:19am from davew @uncnsrd
Subject: Spider Monkey
I've been looking at the Spide Monkey documentation.
For simple apps that don't use threads it is self contained.
For multithreading apps like us we need NSPR as well so I guess thats
the
place to
Nov 2 2009 11:40am from davew @uncnsrd
Subject: Re: Citadel commit log: revision 7989
Â
Mon Nov 02 2009 11:54:17 AM EST from IGnatius T Foobar @ Uncensored
Subject: Re: Citadel commit log: revision 7989
My test server now spits out Server strangled due
Sat Oct 31 2009 03:56:12 PM EDT from IGnatius T Foobar @ Uncensored
Subject: Re: Spider Monkey
It uses it for everything, but it's optional for a single-threaded
parser?
How's that?
Are there any other JS parsers out there that we should be looking at?
Perhaps the KDE or
It uses it for everything, but it's optional for a single-threaded parser?
How's that?
Are there any other JS parsers out there that we should be looking at?
Perhaps the KDE or GNOME projects have their own?
I really don't want to add too many external dependencies, and I
Oh, here's a good starting point:
http://en.wikipedia.org/wiki/List_of_JavaScript_engines
Whilst I've been poking about I have noticed some messages (generally in
gdb)
that seem to indicate that some library that citserver currently relies
on
also requires libnspr. Is there a command that can be run on an
executable
and will print out all the library dependencies and
It works!! It works!!!
ldd
1001 - 1100 of 1530 matches
Mail list logo
