1
edit
Changes
New page: Date: Oct 8, 2008<br /> Re: Regressions caused by using the NSPR in nsIProcess<br /> Peoples: James Boston (jboston), David Humphrey (humph), Mark Finkle (mfinkle), Benjamin Smedberg (bsme...
Date: Oct 8, 2008<br />
Re: Regressions caused by using the NSPR in nsIProcess<br />
Peoples: James Boston (jboston), David Humphrey (humph), Mark Finkle (mfinkle), Benjamin Smedberg (bsmedberg)<br />
<pre>
14:39 <@humph> jboston: http://dafizilla.wordpress.com/2008/10/08/nsiprocess-windows-and-unicode/
16:44 < jboston> humph: I saw that on Planet Mozilla. I've read the bug history. I'm just not sure
what to do about it. It may be that people need to think about filing bugs against
the NSPR code. I don't know actively NSPR code is maintained or developed or used.
Is it vital to the browser or is it something left over from Netscape that is just
rusting away?
16:45 < mfinkle> NSPR is still actively maintained
16:45 < mfinkle> NSPR is used in a few other open source projects too
16:46 < mfinkle> they have a different set of maintainers and reviewers
16:46 <@humph> jboston: I think this work, and yours, shows that most users of nsIProcess are non-mozilla
16:46 < jboston> See, I'll have to check if that unicode problem exists when using NSPR.
16:46 < jboston> hmm
16:47 <@humph> bsmedberg has mentioned that this would be an issue for you, as I recall
16:47 < bsmedberg> the problem exists in spades in NSPR
16:47 < jboston> yes. i recall that. i'm trying to find it in the notes.
16:48 <@humph> bsmedberg: we're talking about
http://dafizilla.wordpress.com/2008/10/08/nsiprocess-windows-and-unicode/ specifically
16:48 <@humph> and the unicode issue, which perhaps you're also talking about
16:48 < jboston> Ah, yes. He talked about 'unresolved issues with character sets' in our chat.
16:50 < bsmedberg> jboston: we solved this for PR_LoadLibrary by adding NSPR features. See
http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsLocalFileWin.cpp#1749
16:50 < bsmedberg> and follow the CVS blame backwards
16:50 < jboston> bsmedberg: Thanks.
16:50 < bsmedberg> the basic problem being that you can't represent windows path with a native char*
16:51 < bsmedberg> you either have to use PRUnichar* == WCHAR*, or transcode back and forth from UTF8
16:56 < jboston> humph: If I go mucking around in NSPR code am I out of scope for this project? I still
have the asynchronous I/O to do!
17:05 <@humph> jboston: no, that's cool
17:06 < jboston> To be honest, string conversions make my head spin!
17:06 <@humph> I think you'll find that to do your work, you'll need to be in nspr
17:08 < jboston> I could go the opposite route and fix nsIProcess without using the NSPR (any more than
it is now). It just means piling more code into the interface. I already tried a patch
that does that for win32. I could do that for the other platforms as well. It just seems
hacky. But ugly is subjective. Functionality is objective.
17:10 < jboston> Code that works today is better than code that could be perfect tomorrow.
17:12 < jboston> Anway, I guess I can go ahead and to the ipc stuff on the assumption that nsIProcess works
the way it should.
17:20 <@humph> jboston: using nspr makes the most sense to me, so carry on
17:21 <@humph> you're not introducing a new dep for mozilla--it's their dep to begin with, so it's fine
17:21 < jboston> humph: It seems like a better design choice over the long run.
17:21 <@humph> totally agree. and reviewers will tell you if you're wrong
17:21 < jboston> meet new and interesting people!
17:21 <@humph> interesting, yes
</pre>
Re: Regressions caused by using the NSPR in nsIProcess<br />
Peoples: James Boston (jboston), David Humphrey (humph), Mark Finkle (mfinkle), Benjamin Smedberg (bsmedberg)<br />
<pre>
14:39 <@humph> jboston: http://dafizilla.wordpress.com/2008/10/08/nsiprocess-windows-and-unicode/
16:44 < jboston> humph: I saw that on Planet Mozilla. I've read the bug history. I'm just not sure
what to do about it. It may be that people need to think about filing bugs against
the NSPR code. I don't know actively NSPR code is maintained or developed or used.
Is it vital to the browser or is it something left over from Netscape that is just
rusting away?
16:45 < mfinkle> NSPR is still actively maintained
16:45 < mfinkle> NSPR is used in a few other open source projects too
16:46 < mfinkle> they have a different set of maintainers and reviewers
16:46 <@humph> jboston: I think this work, and yours, shows that most users of nsIProcess are non-mozilla
16:46 < jboston> See, I'll have to check if that unicode problem exists when using NSPR.
16:46 < jboston> hmm
16:47 <@humph> bsmedberg has mentioned that this would be an issue for you, as I recall
16:47 < bsmedberg> the problem exists in spades in NSPR
16:47 < jboston> yes. i recall that. i'm trying to find it in the notes.
16:48 <@humph> bsmedberg: we're talking about
http://dafizilla.wordpress.com/2008/10/08/nsiprocess-windows-and-unicode/ specifically
16:48 <@humph> and the unicode issue, which perhaps you're also talking about
16:48 < jboston> Ah, yes. He talked about 'unresolved issues with character sets' in our chat.
16:50 < bsmedberg> jboston: we solved this for PR_LoadLibrary by adding NSPR features. See
http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsLocalFileWin.cpp#1749
16:50 < bsmedberg> and follow the CVS blame backwards
16:50 < jboston> bsmedberg: Thanks.
16:50 < bsmedberg> the basic problem being that you can't represent windows path with a native char*
16:51 < bsmedberg> you either have to use PRUnichar* == WCHAR*, or transcode back and forth from UTF8
16:56 < jboston> humph: If I go mucking around in NSPR code am I out of scope for this project? I still
have the asynchronous I/O to do!
17:05 <@humph> jboston: no, that's cool
17:06 < jboston> To be honest, string conversions make my head spin!
17:06 <@humph> I think you'll find that to do your work, you'll need to be in nspr
17:08 < jboston> I could go the opposite route and fix nsIProcess without using the NSPR (any more than
it is now). It just means piling more code into the interface. I already tried a patch
that does that for win32. I could do that for the other platforms as well. It just seems
hacky. But ugly is subjective. Functionality is objective.
17:10 < jboston> Code that works today is better than code that could be perfect tomorrow.
17:12 < jboston> Anway, I guess I can go ahead and to the ipc stuff on the assumption that nsIProcess works
the way it should.
17:20 <@humph> jboston: using nspr makes the most sense to me, so carry on
17:21 <@humph> you're not introducing a new dep for mozilla--it's their dep to begin with, so it's fine
17:21 < jboston> humph: It seems like a better design choice over the long run.
17:21 <@humph> totally agree. and reviewers will tell you if you're wrong
17:21 < jboston> meet new and interesting people!
17:21 <@humph> interesting, yes
</pre>