Ok, due to too many problems in the current svn trunk, I have reverted Uncensored to older code. I'm going to be having a very busy week (spending most of it at a VMware seminar and will be away from my office) so it was important to get things stable for now.
Here are some problems with the
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!!
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.
Cool, I'll test it when I get a chance.
Right. If there is a - in that fourth position, it MUST continue reading
until
it sees a in the fourth position.
I'll be in and out of consciousness all weekend long.
Ok, now Uncensored is running on svn head. I accidentally "upgraded" to the stable-77x branch.
Found a bunch of stray characters in de.po while upgrading that broke the build. Not sure how they got there but I removed them.
If we switch to git will it screw up davew's ability to eventually merge his
branch?
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?
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
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,
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.
Considering that Uncensored is currently spinning 100% cpu on citserver, I'd
say that's still the big issue.
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() ?
The queue was backed up a couple of days ago. At the moment I'm sending all
mail out through a pool of smart hosts, so it'll get delivered faster. We
have to revisit mail delivery at some point.
probably just because i'm used to memcpy; I thing strndup will check
for \0 while copying which we don't need to since we know the length?
We're going to continue to have a difference of opinion on this. I still
prefer readability and maintainability over shaving off a handful of cpu
Let's not mess with it yet -- the module is not finished. The reason I'm
maintaining this xmpp mortuary is because when a Jabber client logs in,
the first thing we have to do is flush out all of the roster entries that
existed in all previous sessions. Stupidly, XMPP doesn't have a way to tell
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.
Uncensored will do an upgrade to svn head and automatically restart services
at 2:30am US Eastern time.
Hmm ... I don't think it happened. Dunno why. :(
I'm not at all familiar with the way this new chat implimentation works.
It's a lovely new protocol that sacrifices efficiency for simplicity by having
the client poll the server for new incoming messages every few seconds. It
doesn't use START_CHAT_MODE and it relinquishes control of the
I assume you've tested this with an actual OpenID account to make sure it
still works?
If you have a Blogger account, it can be used as an OpenID provider too.
hmmm ... as far as I can tell, the networking problem is due to the server
getting stuck with doing_queue permanently set to 1, for some reason, so it's
not accepting polls.
Scratch that ... it's another I/O layer problem!
(gdb) bt
#0 0x0051b7f2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x006bc89b in write () from /lib/libpthread.so.0
#2 0x080750fb in sock_write (sock=0xb6cf5ff8, buf=0x80bde78 \n, nbytes=1)
at clientsocket.c:286
#3 0x08075184
One more thing I can indicate now: we're hung up on Uncensored performing
a read() operation during a network session that it initiated towards dogpound2.
dogpound2 is running stable code.
I suspect that Chrome will eventually overtake Firefox as the leader in
non-Microsoft
web browsing, just like Android will overtake iPhone/iPad in the portable
space.
But for the time being, I have to spend a few days using IE as my WebCit
test browser, because that's where the brokenness
Ok. Just so you know, a couple of weeks ago I switched from protoaculous
back to discrete copies of prototype and scriptaculous, in order to support
better manageability.
Even with the longer timeout on the watchdog script, it's still firing from
time to time. I really don't know what's happening, because the cores all
show the same thing: all threads waiting on accept(), except for the
housekeeping
thread, which is sleeping.
I am going to disable the
Ok, now we're getting somewhere. 4 alerts in the last 8 hours. It isn't
locking up; it's getting the message Received unexpected answer from Citadel
server; bailing out.
maybe you'd like to add a debug statement here??
Yes, that's obviously the right thing to do; I haven't been writing webcit
logs but it's probably time to start. :)
Ok, here's the answer:
The INFO command returned a *blank line*.
I'm working on this too. It isn't actually that specific server command.
WebCit's ability to receive server replies appears to be broken by the time
get_serv_info() starts. When I began checking the output of the IDEN command,
it failed there too.
I just added some code to check the
Very weird. We had another unexpected response error with those checks
in place. The server passed the 200 banner check, but then by the time we
got into get_serv_info(), the server responses became blank.
The next time it happens I will try to analyze it from the citserver side
to see if
This really is a bizarre bug. Maybe it's some sort of race condition. What
I can tell you is that sometime between when we fetch the server greeting
(always a 200 ready) and when we call get_serv_info(), the server socket dies.
If you run it in the debugger you get a SIGPIPE.
There is just no sensible explanation for this. One moment we're reading
the server greeting, the next moment the socket is toast. citserver doesn't
provide an explanation either.
IG, maybe this: http://c-ares.haxx.se/ could be a solution to our
nslookup blocking stuff? It also would cover the ivp6 part of
nslookups...
Are we blocking on lookups? I'm pretty sure we're blocking on connection
attempts. Or am I wrong about that?
hm, and maybe another idea... Could you run ntop on hawthorne for a
while? it would show whether for example spam attacks are the reason
for these hickups...
Already running. http://quark.xand.com/mrtg/ghettobaystack_17.html
Not to worry, we're just about to 7.80 -- I fixed most of the remaining IE
problems today, and hopefully will have everything tested with all browsers
and ready for release by the end of the week. Then we can branch 7.8x-stable
and start working on Citadel 8.
a list of addresses to send spam to?
it's that time of year again ... i'm at the beach this week, but the rental
house now has high speed internet so i'll be online. we should work on the
7.80 release, i think we're pretty much there.
Gaah, that was a pain in the ass to fix.
* entroom (): after creating a room, don't display the empty room but rather
display the advanced room editing screen.
What? What if the user is not an Aide and doesn't have permissino to edit
the room?
I have pushed Citadel 7.80 to Easy Install. Source tarballs will follow soon.
As soon as we are sure everything is working smoothly, we will open the
stable_78x
branch. Until then, all commits should be for bug fixes only.
Looks like I'm seeing failures on IMAP partial fetch here... Citadel is
returning a null response after upgrading to 7.80. Also tried the
newest 7.81.
To replicate, use Alpine to view messages with Quell-Partial-Fetch set
to off.
Fixed in r8703 (both trunk and stable).
seems to me as if you've nuked logging to syslog?
if (enable_syslog) {
vsyslog((syslog_facility | loglevel), format, arg_ptr);
}
Nope
Perhaps we can find a better way of automating it?
I suppose we could just eliminate the #define entirely, and then every place
we need CC we could just do
struct CitContext *CC = MyContext();
That's a lot of noise, of course, but if you're going to put struct CitContext
*CCC = CC;
Not that anonymous after all?
Not for someone with admin rights.
Ok, there we go.
The previous IPv6-only implementation required a hybrid stack host such as
Linux or FreeBSD, on which the listening address in6addr_any causes it to
accept both IPv6 and IPv4 connections on the same socket. I was ok with
dropping
support for OpenBSD, but when I found out
Citserver doesn't have IPv6 yet.
That's ok, I think we're going to ditch the rounded boxes in the next theme
we build.
while we should continue our stable branches in SVN, I'm all in for
switching HEAD to git right now. Can we? Please?
I'm not maintaining two different repositories. It's going to be one or
the other.
I'm reading some documentation and tutorials on git, and it looks like something
that's only useful for developing the Linux kernel ... essentially not the
right tool for a project like ours that relies on a central repository.
Why do we want all of this extra complexity?
Ok, we're switching to git. I remain ambivalent about the subject, but since
it is in high demand I will go with the flow here.
My needs are simple ... even CVS worked just fine for me.
Our source code repository will be offline until the conversion is complete.
Ok folks, commit 8f713e8bba92ebb93a9a486d81ec7e966583fd9e in branch stable-78x
is the official 7.84 release of all components. tarballs have been built
and uploaded.
Yes I did, but it has not been implemented.
Personally I use the terminal as much as I use the GUI. I wish they
would lose the mach kernel one day though. I'd love to see OS X be
based on straight *BSD.
Let me get something clear, then ... was your trouble report involving the
Terminal application or the console? Is there
Just curious - if additional information (for a plugin, etc.) needs to
be added to a user's profile, what is the best way to accomplish that
w/o modifying internal structures? This information would need to be
secure from modification by the end user.
What I normally do is
It would be much easier, but I can't guarantee exactly when I'm going to have
the chance to work on it.
Nope. It's either there or it isn't. I suppose you could drop the table
:)
The sad thing is that I'm going to have to live with Internet Explorer as
my reference browser for a while just because it's the most broken.
Not working yet, but I'm going to make it work. CSS3 has rounded edges,
gradients,
and drop shadows. It makes no sense to do this any other way. Please bear
with me for a little while as I build a new CSS3 based theme.
Well, I don't really have the time to do it, but it's a reasonable idea.
Sure, there's a ton of that kind of work that needs to be done. I do it when
I'm already in there somewhere and notice little things that need adjusting,
but having someone around to focus on it would be great.
Don't spend too much time on the vCard editor. I will probably rewrite it
in the not too distant future.
It's still there. I moved it up into the nav bar.
Nope. Uncensored will be running the new WebCit too, so if they can't find
the save button then they can't post messages complaining about it. :)
We'll do what we always do -- deploy it first to Uncensored and see how it
is received by the user community. It wouldn't be the first time we had a
UI design rejected. I was really proud of the dynamic BBS view but nobody
liked it.
so far? imaptest and thunderbird.
Until you've also tested Outlook, Pine, whatever Apple is using these days,
and a mobile client or two ... assume that your patch broke them all.
Seriously.
IMAP is that fragile.
IG, could you have a look at this? why does the mentioned pointer
contain invalid data instead of NULL? could you clean that up?
Which pointer are we talking about here?
Yes, everything is done using safestrncpy()
I'm more concerned with the fact that he posted a newbie installation question
to the developer list. It shows that he didn't bother to read the instructions
for requesting help.
Yeah well Exchange does that all on its own :)
The homework helpers mail is parsing properly but it is *not* displaying
properly. I see quoted-printable on the screen.
The homework helpers mail is parsing properly but it is *not*
displaying properly. I see quoted-printable on the screen.
Actually, it seems that quoted-printable is being displayed all over the
system.
The MIME parser is currently broken. I'm seeing quoted-printable all over
the place, and now it's even failing to submit some html forms (which are
sometimes decoded by the MIME parser).
What was done and why?
where do you see QP exactly?
All I have to do is use WebCit to post a message in any room, and then read
it. QP-encoding all over the place.
Also: uploading files (attachments, images, etc.) is broken. The form data
stops when it gets to an upload file. It is important to repair this quickly
because I have a commit almost ready that will *greatly* improve attachment
uploading in webcit, but I can't test it until the MIME parser is
its supposed to find the last left boundary?
The behavior of stripallbut() when multiple boundaries are found is
*undefined*.
However, my goal with this rewrite, aside from simplicity (and not crashing)
was to attempt to find the innermost string, so we don't end up extracting
a
Qte! realy Qute. I'd like to add one todo... could you add a throbber
to the screen while its uploading the files on send? The one we also
show while loading the messages list in the mbox view?
Yes, that's definitely something for the TODO list.
Right now the problem is that I
have a look at that IG, its mostly what you did, plus wrap cunit
around it...
I wasn't familiar with CUnit so it's going to take me some time to figure
everything out, but it looks like you simply changed my assert() calls to
CUnit's equivalents, so yes, that's fine.
I will use
I try to re-use localizations when I can. The string Attachments: was already
in there.
The dialog is built in such a way that we can probably re-use most of it for
other upload tasks. At the moment, I would like to focus on message entry.
Rewriting the upload dialog wasn't actually what I started out trying to
do. My goal was to eliminate all of the round-trips to the server
Last call for bugfixes, otherwise I'm going to release 7.85 tomorrow in order
to get the networking fix into people's hands.
I thought this was going to be done in a separate branch?
I haven't looked at this yet -- I've only isolated the problem message
and performed a backtrace. The message in question has been quarantined
in the Test Messages room (the subject is CAVE...).
When this message is read using webcit stable-78x, webcit dies in an
active loop. The looping
My intention is to completely remove the traditional login screen. All
authentication
will be performed through the modal dialog and ajax calls. Even on a closed
system that does not have guest mode enabled, the login screen will just
be a dumb banner with the login modal superimposed on top.
I am a staunch supporter of the GPL. On the other hand, the rhetoric from
RMS/FSF gets kind of tiring. I think ESR said it best in this editorial:
http://www.linuxtoday.com/news_story.php3?ltsn=1999-06-28-023-10-NW-SM
(Oops ... the canonical location of this essay is:
http://www.catb.org/~esr/writings/shut-up-and-show-them.html
)
If I select edit, and save the page, I still see the same message. No home page is ever created.
Any advice here? Sam
I can confirm that it's definitely broken and I will fix it.
It's been a productive evening. :)
Wiki now works and looks good, even in guest mode.
That'll be quite useful -- I usually have to add temporary logging for just
that purpose while debugging various things.
There was, however, a problem with sessions not being *fully* logged out.
I have just fixed that.
I doubt we will ever have the ability to log in two different users at the
same time from the same browser. On the other hand, I have been adding go=
url components to a lot of the stuff I've
Getting more REST-like would probably fit in nicely with the anonymous
login feature. Any HTTP GET request received by webcit would require
webcit to ask citserver if the requested resource required
authentication, but then webcit wouldn't need to carry around much, if
any, state
Even after you explicitly log out of one of the accounts? What does
logout mean in such a case? Is the message requested in the context of
the logged-out account, or the new logged in account?
Try it again now; it *should* theoretically act like any other web site
at this point. If
That was kind of nasty. I thought that it was me who broke the ajax stuff,
but it was actually the Prototype 1.7 upgrade.
Everyone take note of this please, particularly when using ajax_servcmd.
The parameters must be wrapped up inside EncodeURI() otherwise they will
be truncated.
Yes, the chat window uses that API as well, and I believe I've fixed it.
901 - 1000 of 1678 matches
Mail list logo
