spruce-devel

Re: [Spruce-devel] anyone out there...?

[Jeffrey S. <ste...@co...>]

On Sun, 2007-02-04 at 14:42 -0500, Jeffrey Stedfast wrote:
> anyways... I'll be committing some fixes to the cache code in a few
> hours probably, reworking a bit of the logic in the GMime streams to
> make them more robust, etc.
> 

Well that was bugger-all to get right... still not sure it's totally
correct even now, but gah.

GMimeStreamCat is a bloody nightmare is what it is... especially if you
want to allow seeking and substreaming, which I kind of have to unless I
want GMimeParser to dup the mime-part contents to a GMimeStreamMem as it
parses along...

And don't think for a minute I didn't consider that.


I might have to consider rewriting CacheStream to not use a StreamCat
but instead do it's own spillover handling if/when the GMimeStreamFs
backing stream fills up/errors/whatever.

What a nightmare... and I haven't eaten all weekend :(

Oh well, at least the code "works" now.

Jeff

Re: [Spruce-devel] anyone out there...?

[Jeffrey S. <ste...@co...>]

On Sun, 2007-02-04 at 14:49 +0100, Philip Van Hoof wrote:
> > Anyone out there?
> > <pause>
> > <echo>
> 
> Yep. Hi there. 
> 
> > So here I am somewhat bored now that I am unemployed and have been for
> > about 2 months now. 
> 
> Oh, that's sad to hear. :(
> 
> > So I've begun hacking on Spruce a little bit here and there... not
> > really any closer to having a beautiful graphical mailer than I was
> 
> You where a graphical mailer? :)
> 
> Once libspruce's development is back up and running at 100%, I could
> certainly help with that graphical mailer. Replacing some "Camel" words
> with "Spruce" ain't going to be that hard after all.

not sure it'll ever be back and running at 100%, just have some spare
cycles at the moment and so decided to toss them at libspruce a bit ;)

> 
> > before, but libspruce has more toys. That's good tho, right?
> 
> Yes. libspruce is nice. I'm looking at it. 
> 
> > I've begun working on offline support for the IMAP code. To start, I'm
> > implementing a message cache (which is useful even without true
> > offline support).
> 
> Sounds good!
> 
> While I was reading your IMAP provider, I noticed that the very
> beginnings of support for the CONDSTORE IMAP capability had already been
> added. Not yet an implementation but already some infrastructure.

yea, one of the problems I have to solve is spruce-imap-stream's
tokeniser can't handle tokenising 64bit ints atm... should be easy to
fix once I get around to it (probably after I do some other debugging of
the imap code (which I noticed had some bugs last night) and this new
caching code which is loaded with bugs (some are actually GMime stream
bugs) :p

> 
> To show that if you are serious about continuing libspruce's
> development, that I as promised would join, I hacked a little bit on it
> and have put a few extra pieces of the implementation for that in place.
> 
> Feel free to checkout the attachment a little bit. Although I haven't
> tested this, it compiles.

cool

> 
> You know what some developers say .. if it compiles, it works :) hehe.
> 
> pssst. Which could actually be 'almost' true, if compilers would
> integrate with unit testing, like that D thingy.
> 
> > So far this cache interface is pretty dead simple... at instantiation,
> > it takes a basedir path and a 64bit max filesystem size.
> > 
> > Expiration of items:
> > ====================
> > 
> > dead simple. there's an 3 expiratory functions:
> > 
> > - ::expire() - shrinks the cache down to <= max size specified at
> > instantiation time by unlink(2)ing files in the cache with the oldest
> > atime until size <= max.
> > 
> > - ::expire_key() - expires a particular item referenced by @key
> > 
> > - ::expire_all() - expires all items in the cache.
> 
> Sounds very useful. It's in fact one of the to-do items for another mail
> library (we both probably know which one, but that's not important
> here). 

actually Camel already has CamelDataCache which has more expire rules
you can define (not super complex either, but more extensive than
spruce's) 

> 
> Anyway, while I will be reading libspruce's code, I'm sure that I'll
> come across it and that way gain some new insights and ideas on it.
> 
> 
> > If we really wanted to get fancy, we could perhaps do a size
> > comparison or something, which would help hint to the expiration logic
> > which items should be expired first... such that atime wasn't the only
> > deciding factor. 
> 
> > e.g. if we had item A and item B, where A was significantly larger
> > than B, but the atime was slightly longer ago, then we may wish to
> > expire B instead of A (current logic would expire A) because
> > re-fetching B would be more efficient than re-fetching A.
> 
> Yes, something like that sounds reasonable to support. Although some
> users might not care that much about "size", as "size" is more abstract
> than "date", for them.
> 
> Another idea for reducing storage space could be to simple remove some
> of the less interesting mime parts from the cache. Like that 2MB mp3
> file. By detecting the boundary while read-streaming it and rewriting
> only until the second boundary-line to a new file-stream, something like
> that should be doable (I once did it for the tcp-stream with the Camel
> POP and IMAP providers, to support what I have been calling "partial
> message retrieval").

this is harder for the cache itself to figure out, but a higher level
could say "hmmm, user has saved the mp3 attachment... we could remove
that mime part from the cache now using expire_key() since it's not
likely she'll be wanting to save it again"

anyways... I'll be committing some fixes to the cache code in a few
hours probably, reworking a bit of the logic in the GMime streams to
make them more robust, etc.

Jeff

Re: [Spruce-devel] anyone out there...?

[Philip V. H. <sp...@pv...>]

On Sun, 2007-02-04 at 14:49 +0100, Philip Van Hoof wrote:

> You know what some developers say .. if it compiles, it works :)

> -       ic = spruce_imap_engine_queue (engine, folder, "SELECT %F\r\n", folder);
> +       ic = spruce_imap_engine_queue (engine, folder, "SELECT %F%s\r\n", 
> +               folder, engine->capa & SPRUCE_IMAP_CAPABILITY_CONDSTORE);
> + 

Hehe.

Something like this of course:

ic = spruce_imap_engine_queue (engine, folder, "SELECT %F%s\r\n",
	 folder, engine->capa & SPRUCE_IMAP_CAPABILITY_CONDSTORE ?
	 " (CONDSTORE)", "");



-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog

Re: [Spruce-devel] anyone out there...?

[Philip V. H. <sp...@pv...>]

> Anyone out there?
> <pause>
> <echo>

Yep. Hi there. 

> So here I am somewhat bored now that I am unemployed and have been for
> about 2 months now. 

Oh, that's sad to hear. :(

> So I've begun hacking on Spruce a little bit here and there... not
> really any closer to having a beautiful graphical mailer than I was

You where a graphical mailer? :)

Once libspruce's development is back up and running at 100%, I could
certainly help with that graphical mailer. Replacing some "Camel" words
with "Spruce" ain't going to be that hard after all.

> before, but libspruce has more toys. That's good tho, right?

Yes. libspruce is nice. I'm looking at it. 

> I've begun working on offline support for the IMAP code. To start, I'm
> implementing a message cache (which is useful even without true
> offline support).

Sounds good!

While I was reading your IMAP provider, I noticed that the very
beginnings of support for the CONDSTORE IMAP capability had already been
added. Not yet an implementation but already some infrastructure.

To show that if you are serious about continuing libspruce's
development, that I as promised would join, I hacked a little bit on it
and have put a few extra pieces of the implementation for that in place.

Feel free to checkout the attachment a little bit. Although I haven't
tested this, it compiles.

You know what some developers say .. if it compiles, it works :) hehe.

pssst. Which could actually be 'almost' true, if compilers would
integrate with unit testing, like that D thingy.

> So far this cache interface is pretty dead simple... at instantiation,
> it takes a basedir path and a 64bit max filesystem size.
> 
> Expiration of items:
> ====================
> 
> dead simple. there's an 3 expiratory functions:
> 
> - ::expire() - shrinks the cache down to <= max size specified at
> instantiation time by unlink(2)ing files in the cache with the oldest
> atime until size <= max.
> 
> - ::expire_key() - expires a particular item referenced by @key
> 
> - ::expire_all() - expires all items in the cache.

Sounds very useful. It's in fact one of the to-do items for another mail
library (we both probably know which one, but that's not important
here). 

Anyway, while I will be reading libspruce's code, I'm sure that I'll
come across it and that way gain some new insights and ideas on it.


> If we really wanted to get fancy, we could perhaps do a size
> comparison or something, which would help hint to the expiration logic
> which items should be expired first... such that atime wasn't the only
> deciding factor. 

> e.g. if we had item A and item B, where A was significantly larger
> than B, but the atime was slightly longer ago, then we may wish to
> expire B instead of A (current logic would expire A) because
> re-fetching B would be more efficient than re-fetching A.

Yes, something like that sounds reasonable to support. Although some
users might not care that much about "size", as "size" is more abstract
than "date", for them.

Another idea for reducing storage space could be to simple remove some
of the less interesting mime parts from the cache. Like that 2MB mp3
file. By detecting the boundary while read-streaming it and rewriting
only until the second boundary-line to a new file-stream, something like
that should be doable (I once did it for the tcp-stream with the Camel
POP and IMAP providers, to support what I have been calling "partial
message retrieval").

Although it's not the same as "expiring" in pure feature description, it
is actually what most mobile device vendors want in cache management.

> another idea might be to have a min_item_size, so that all items with
> size < min_item_size would be expired first, and then the remaining
> items would be expired based on atime?
> 
> would be simpler than the first idea...

Sounds good.


> Cache Layout:
> =============

I have to read your code to get the full idea, but all this sounds very
nice!


> directories from 00 to ff (items keys are hashed and deposited into an
> appropriate subdir)
> 
> 
> 
> The Coolness Factor:
> ====================
> 
> the problem with implementing a cache like this is that the
> application using this cache class has to be diligent about checking
> for failed writes to a file, if a failure occurs, then he's got to do
> the following tasks:
> 
> 1. remove it from the cache (don't want future cache lookups to return
> truncated data). Lets also hope the app doesn't crash before we can
> remove it or the truncated data will remain, oh noes!
> 
> 2. drop the incomplete file altogether and find another place to store
> the FULL data (or we could just give up on this data and tell the user
> "No, can't fetch it").
> 
> 
> (1) is just annoying... all this error checking, gah! a partial fix is
> to not start the file off in cache/01/key in the first place, instead,
> put it in cache/tmp/key and when we're done writing the FULL content
> to it, then we can rename(2) it to cache/01/key.
> 
> this doesn't solve the annoyingness of the error checking and book
> keeping going on at a high level in the app tho, and that sucks.
> 
> 
> (2) is just... DAAAAAMN. I think typically devs just throw up an
> error, easier than the alternative...
> 
> 
> 
> 
> So... what have I done?
> 
> 
> Cache::add() returns a special kind of CacheStream to the higher level
> bits. The higher level writes data to this stream without a care in
> the world to where it's actually going and no matter what, the
> CacheStream will do its best to find a place for that data.
> 
> it starts out writing to /path/to/cache/tmp/key like I explained
> above, but if that file runs out of space or has some other I/O
> error... then the CacheStream picks it up, and spills remaining data
> into a memory-stream, all in such a way that the higher-level app bits
> never have to know, and when they are finished writing to the
> CacheStream, rewind it, and re-read the content... they still don't
> have to know, it Just Works (tm). As far as they know, it's like
> reading from any other GMimeStream object.
> 
> When the higher-level bits unref the CacheStream and it therefor gets
> finalized (garbage collected):
> 
> if spillover
> unlink(2) the /path/to/cache/tmp/key file
> else
> rename(2) /path/to/cache/tmp/key to /path/to/cache/01/key
> 
> 
> all done by the cache for the higher-level bits so they don't have to
> worry about it.
> 
> 
> This hack brought to you by GMimeStreamCat and the letters C and S and
> the number 64.
> 
> Jeff  


-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog

[Spruce-devel] anyone out there...?

[Jeffrey S. <ste...@co...>]

Anyone out there?
<pause>
<echo>

So here I am somewhat bored now that I am unemployed and have been for
about 2 months now. So I've begun hacking on Spruce a little bit here
and there... not really any closer to having a beautiful graphical
mailer than I was before, but libspruce has more toys. That's good tho,
right?

I've begun working on offline support for the IMAP code. To start, I'm
implementing a message cache (which is useful even without true offline
support).

So far this cache interface is pretty dead simple... at instantiation,
it takes a basedir path and a 64bit max filesystem size.

Expiration of items:
====================

dead simple. there's an 3 expiratory functions:

- ::expire() - shrinks the cache down to <= max size specified at
instantiation time by unlink(2)ing files in the cache with the oldest
atime until size <= max.

- ::expire_key() - expires a particular item referenced by @key

- ::expire_all() - expires all items in the cache.


If we really wanted to get fancy, we could perhaps do a size comparison
or something, which would help hint to the expiration logic which items
should be expired first... such that atime wasn't the only deciding
factor. 

e.g. if we had item A and item B, where A was significantly larger than
B, but the atime was slightly longer ago, then we may wish to expire B
instead of A (current logic would expire A) because re-fetching B would
be more efficient than re-fetching A.


another idea might be to have a min_item_size, so that all items with
size < min_item_size would be expired first, and then the remaining
items would be expired based on atime?

would be simpler than the first idea...


Cache Layout:
=============

directories from 00 to ff (items keys are hashed and deposited into an
appropriate subdir)



The Coolness Factor:
====================

the problem with implementing a cache like this is that the application
using this cache class has to be diligent about checking for failed
writes to a file, if a failure occurs, then he's got to do the following
tasks:

1. remove it from the cache (don't want future cache lookups to return
truncated data). Lets also hope the app doesn't crash before we can
remove it or the truncated data will remain, oh noes!

2. drop the incomplete file altogether and find another place to store
the FULL data (or we could just give up on this data and tell the user
"No, can't fetch it").


(1) is just annoying... all this error checking, gah! a partial fix is
to not start the file off in cache/01/key in the first place, instead,
put it in cache/tmp/key and when we're done writing the FULL content to
it, then we can rename(2) it to cache/01/key.

this doesn't solve the annoyingness of the error checking and book
keeping going on at a high level in the app tho, and that sucks.


(2) is just... DAAAAAMN. I think typically devs just throw up an error,
easier than the alternative...




So... what have I done?


Cache::add() returns a special kind of CacheStream to the higher level
bits. The higher level writes data to this stream without a care in the
world to where it's actually going and no matter what, the CacheStream
will do its best to find a place for that data.

it starts out writing to /path/to/cache/tmp/key like I explained above,
but if that file runs out of space or has some other I/O error... then
the CacheStream picks it up, and spills remaining data into a
memory-stream, all in such a way that the higher-level app bits never
have to know, and when they are finished writing to the CacheStream,
rewind it, and re-read the content... they still don't have to know, it
Just Works (tm). As far as they know, it's like reading from any other
GMimeStream object.

When the higher-level bits unref the CacheStream and it therefor gets
finalized (garbage collected):

if spillover
   unlink(2) the /path/to/cache/tmp/key file
else
   rename(2) /path/to/cache/tmp/key to /path/to/cache/01/key


all done by the cache for the higher-level bits so they don't have to
worry about it.


This hack brought to you by GMimeStreamCat and the letters C and S and
the number 64.

Jeff

[Spruce-devel] spruce hacking update

[Jeffrey S. <fe...@st...>]

Okay, been like a month or so since I last emailed this list...

the computer place wouldn't fix my system, so I had to buy new parts and
fix it myself. bought a new AMD 2500 XP so it's a bit of an upgrade from
my last system :-)

I love how you can build a brand new system these days for like $300 :-)

I've been getting some spruce hacking done lately (past week or so)
mostly because I've ported the imap plugin I wrote for spruce over to
Evolution and have been using Evolution to test out my IMAP code a bit.
This has invariably caused me to find bugs and forced me to improve on
some things as well as test out my design to see how well it works in
the Real World (tm).

Seems to be working pretty well overall...

Now comes time to make some decisions about the design of libspruce...

1. I need a method on SpruceFolder to force a scan of updates
(especially needed for IMAP but could be useful for local mbox/maildir
if other clients are also updating those folders...)

Perhaps something like SpruceFolder::rescan() or SpruceFolder::
refresh_info() or SpruceFolder::check() ?

2. need to decide on what signals to add to SpruceFolder so that the
above mentioned status update methods can notify the UI of any changes
it discovers...

(why not just have the refresh_info() method return info, you ask?
because the plugin may need to alert the UI to updates in the folder
even without the app explicitly calling refresh_info() - IMAP is the
main one here...)

Evolution's Camel library has a CamelFolder::folder_changed() signal
which seems to work quite well so I think maybe I'll use the same idea.

3. SpruceFolder::list()/lsub() - should these return arrays of strings?
or should they return an array of SpruceFolder objects?

should it allow recursive scanning?

I'm beginning to think that it should simply return a list of strings or
else some other structure or some such. Returning folder objects might
not be such a good idea...

same goes for the namespace functions on the SpruceStore...


decisions decisions...

Jeff

Re: [Spruce-devel] Forgot.. libspruce build errors in SPRUCE_GTK2

[Jeffrey S. <fe...@st...>]

On Sun, 2004-04-18 at 21:53 +0200, Kristoffer Brånemyr wrote:

> Have forgotten to mention this... in the SPRUCE_GTK2 branch is included some
> version of libspruce. If you try to make from the top directory you get an error because
> of this:
> Making all in libspruce
> make[2]: Entering directory `/home/ztion/spruce-devel/libspruce'
> make[2]: *** No rule to make target `spruce-marshal.c', needed by `all'.  Stop.
> 
> Because of this you have to cd to src to make the program which isn't so good.
> If I understand correctly it seems like those should be autogenerated somehow?


ah, yea - they are supposed to be autogenerated by glib-genmarshal which
is a shell script. Something must've broken I guess :-(

oh, forgot to mention in my last reply to one of your previous messages
that libspruce is actually been moved to a new module in cvs called just
"spruce". Eg. it's not in the spruce-devel module anymore.

I should probably just remove the libspruce build from spruce-devel.

keep up the awesome hacking!

Jeff


> 
> -- 
> /Kristoffer Brånemyr
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Spruce-devel mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/spruce-devel

Re: [Spruce-devel] Fixed the crash

[Jeffrey S. <fe...@st...>]

On Fri, 2004-04-16 at 21:21 +0200, Kristoffer Brånemyr wrote:

> Well,
> 
> Finally I got enough annoyed at the random crashes when sending mail with
> SMTP AUTH, so I installed valgrind like you suggested. Quickly I found out
> base64_encode was overwriting the end of some allocated data. Changed it
> to allocate more data and the warnings disappeared and it hasn't crashed on
> me since.
> While I was at it I changed the use of mktemp to mkstemp so the linker doesn't
> complain anymore.
> 
> Checked both into the SPRUCE_GTK2 branch of the cvs.


awesome! I figured it was probably something like that...


> 
> It will be interesting when you're finished with the libspruce stuff! I've come to realize
> what a terrible mime implentation spruce has now. (How embarrasing that I wrote it...)


yea, it's coming along slowly. My CPU fried a 5 or 6 weeks ago so I
haven't had much chance to hack on libspruce lately. Just took it in to
get repaired last night (finally got off my butt). Hopefully my box will
be fixed in a week to 10 days, and then I can get hacking again :-)

btw, libspruce should build and there's a little test program called
spruce-cli that has an interface like `mail`.

you can point it at an mbox spool like this:

spruce-cli "mbox:///var/spool/mail#fejj"

I think that should work anyway... I've mostly been using it for imap,
which is doable via:

spruce-cli "mbox:///var/spool/mail/fejj" might also work, I'm not sure.
It used to work for this uri, but I may have changed it to only work
with something more like the above. It's been a while :-)

spruce-cli "imaps://fe...@im.../#INBOX"

both imap and imaps work, imaps is obviously the "imap over ssl" using
the high-port (993). I've also implemented STARTTLS for IMAP, but I
forget how to specify it :-)

I think it would be something like:

spruce-cli "imap://fe...@im.../;starttls=when-possible#INBOX"

then of course there is SASL stuff, which you'd do:

spruce-cli "imap://fejj;auth=CRA...@im.../#INBOX"

Anyways, feel free to play around with it...

Jeff

Re: [Spruce-devel] Forgot.. libspruce build errors in SPRUCE_GTK2

[Kristoffer <zt...@sw...>]

On Sun, 18 Apr 2004, Kristoffer Brånemyr wrote:
> Have forgotten to mention this... in the SPRUCE_GTK2 branch is included some
> version of libspruce. If you try to make from the top directory you get an error because
> of this:
> Making all in libspruce
> make[2]: Entering directory `/home/ztion/spruce-devel/libspruce'
> make[2]: *** No rule to make target `spruce-marshal.c', needed by `all'.  Stop.
> 
> Because of this you have to cd to src to make the program which isn't so good.
> If I understand correctly it seems like those should be autogenerated somehow?

Ok, if you copy marshal.mk from the "spruce" module in the cvs it works. But since
spruce doesn't even use it yet, perhaps the best would be to disable the build of that
directory?

-- 
/Kristoffer Brånemyr

[Spruce-devel] Forgot.. libspruce build errors in SPRUCE_GTK2

[Kristoffer <zt...@sw...>]

Have forgotten to mention this... in the SPRUCE_GTK2 branch is included some
version of libspruce. If you try to make from the top directory you get an error because
of this:
Making all in libspruce
make[2]: Entering directory `/home/ztion/spruce-devel/libspruce'
make[2]: *** No rule to make target `spruce-marshal.c', needed by `all'.  Stop.

Because of this you have to cd to src to make the program which isn't so good.
If I understand correctly it seems like those should be autogenerated somehow?

-- 
/Kristoffer Brånemyr

[Spruce-devel] Gui improvments + internationalation

[Kristoffer <zt...@sw...>]

Did various small fixes to make the gui nicer.

Also enabled AM_GNU_GETTEXT in configure.in again. This is necessary for the
translations to work. You have to install gettext to be able to run autogen.sh, but
it won't be necessary for the user when a pregenerated configure is included in a
future release of spruce.

2004-04-18  Kristoffer Brånemyr <zt...@sw...>

        * configure.in: Enable nls again. You need gettext to generate
        configure.                                                    

        * src/main (main): Bind gettext to utf8 charset, or it will convert
        everything to the regular charset of the user (for example iso8859-1).

2004-04-18  Kristoffer Brånemyr <zt...@sw...>

        * src/search.c src/gui.c src/filter.c: Setup a default widget in a
        couple of dialogs so you can press enter instead of having to click
        the button.

2004-04-18  Krisfoffer Brånemyr <zt...@sw...>

        * src/composer.c (create_frmComposer): Stop the text in txtFrom getting
        marked and thus remove other stuff from the clipboard. Make txtTo get
        focus.

2004-04-18  Kristoffer Brånemyr <zt...@sw...>

        * src/mesgreader.c (create_frmMesgReader): Put txtMesg in a scrolled
        window so we can use the scrollwheel.



-- 
/Kristoffer Brånemyr

Re: [Spruce-devel] More fixes

[Kristoffer <zt...@sw...>]

On Sat, 17 Apr 2004, Kristoffer Brånemyr wrote:
> Also, I am aware of one more bug. If you put this mail below into one of your mailboxes spruce will go into a infinity loop outputting
> ** (spruce:19197): CRITICAL **: file parse.c: line 240 (strinsert): assertion `*
> insertstr != '\0'' failed
> That insertstr is in parse_8bit and I think it's because they don't end their base64
> encoded string with ?=, they end it with =?... Must be some buggy spamsoftware.
> Not quite sure how to solve it yet, or if it's even worth investigating since libspruce
> will come soon (?). Probably not to common anyway.

Well, I fixed this now. Two separate problems sort of, first it couldn't find the correct
end because it searched for ?=, and then another when decode_base64 failed
it become a loop, because it increased i with the length of the decoded string,
which in this case was 0. I hope no new problems occur because it now searches
for both ?= and "? ", but I haven't noticed any.

-- 
/Kristoffer Brånemyr

[Spruce-devel] More fixes

[Kristoffer <zt...@sw...>]

Made some more bugfixes, including one crash.

2004-04-17  Kristoffer Brånemyr <zt...@sw...>

        * src/main.c (refresh_txtMessage) src/mime.c (mime_get_parameter_value):
        mime_get_parameter_value could not handle when some stupid mailers put
        parameter= "blah". If the parameter happend to be boundary it could
        not find any mime parts, and refresh_txtMessage would crash spruce
        while trying to find the charset using NULL pointer to a mime part.

2004-04-17  Kristoffer Brånemyr <zt...@sw...>

        * src/mesg.c (mesg_get_trimmed_header): Run parse_8bit on all the
        header fields it is going to show, otherwise some raw 8bit chars
        might be there, and as a result the GtkText won't show the header at
        all.

Also, I am aware of one more bug. If you put this mail below into one of your mailboxes spruce will go into a infinity loop outputting
** (spruce:19197): CRITICAL **: file parse.c: line 240 (strinsert): assertion `*
insertstr != '\0'' failed
That insertstr is in parse_8bit and I think it's because they don't end their base64
encoded string with ?=, they end it with =?... Must be some buggy spamsoftware.
Not quite sure how to solve it yet, or if it's even worth investigating since libspruce
will come soon (?). Probably not to common anyway.

Also, it is very annoying that From: gets selected when you start to compose a
message. Often you have marked some address in mozilla which you want to paste,
but then that is removed from the clipboard... Not really sure why it does that.

Return-Path: <mmx...@ya...>
Received: from [130.244.199.222] ([222.100.31.134]) by fep11-svc.swip.net
          with SMTP
          id <20040330203750.IGZD3628.fep11-svc.swip.net@[130.244.199.222]>;
          Tue, 30 Mar 2004 22:37:50 +0200
Received: from (HELO 4xln) [171.15.143.152] by 130.244.199.222 with ESMTP id 85420260; Tue, 30 Mar 2004 23:29:51 +0300
Message-ID: <s59$39$6$$g6k44ni@ixo.35hjfjp>
To: th...@sw...
Subject: =?EUC-KR?B?JiM0MDsmIzQ0MzA1OyYjNDQyNTY7JiM0MTu068Dlsd0gwOWz+rvqu+8guau34cH1waQgwMy6pcauQA==?  d ux
Date: Tue, 30 Mar 04 23:29:51 GMT
X-Mailer: eGroups Message Poster
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="AF14.AB3C.B85_.1__."
X-Priority: 3
X-MSMail-Priority: Normal


--AF14.AB3C.B85_.1__.
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable


<html>
<head>
<title>=FFFFFFB4=FFFFFFEB=FFFFFFC0=FFFFFFE5=FFFFFFB1=FFFFFFDD=FFFFFFC8=FFFFFFAB=FFFFFFB1=FFFFFFDD!!</title>
</head>
<body topmargin=3D"0" marginheight=3D"0">

<table width=3D"550" height=3D"1000" border=3D"1" cellpadding=3D"0" cellsp=
acing=3D"0" bordercolor=3D"#FFFFFF" align=3D"center">
  <tr>
    <td bordercolor=3D"#999999" bgcolor=3D"#FFFFFF"><table width=3D"550" b=
order=3D"0" cellspacing=3D"0" cellpadding=3D"0"><FORM name=3D"FormTalk" ac=
tion=3D"http://10047958.ye.ro/web-home/www/seo/talk_4/SvTalkUpdate.php" me=
thod=3Dpost><INPUT TYPE=3D"HIDDEN" NAME=3D"sender" VALUE=3D"B">
        <tr> 
          <td>
                            <p align=3D"center"><img src=3D"http://www.jos=
unin.ye.ro/sub_domain/mbc/form2.gif" width=3D"550"></td>
                        <td></td>
                        <td></td>
                        <td></td>
                        <td></td>
                        <td><br>
          </td>
        </tr>
 <tr> 
          <td bgcolor=3D"#FFFFFF"><table width=3D"500" border=3D"0"
align=3D=
"center" cellpadding=3D"1" cellspacing=3D"0">
              <tr> 
                <td width=3D"80"><img src=3D"http://10047958.ye.ro/web-hom=
e/www/img/1/text5_01.gif"  ></td>
                <td width=3D"165">  
                  <font color=3D"#666666" size=3D"2"><input name=3D"user_n=
ame" type=3D"text" id=3D"name" size=3D"12" maxlength=3D"15">
                  </font></td>
                <td width=3D"80"><img src=3D"http://10047958.ye.ro/web-hom=
e/www/img/1/text5_04.gif"  ></td>
                <td width=3D"165">  
                  <font color=3D"#666666" size=3D"2"><input name=3D"age" t=
ype=3D"text" id=3D"age" size=3D"3" maxlength=3D"15">
                  </font></td>
              </tr>
              <tr> 
                <td><img src=3D"http://10047958.ye.ro/web-home/www/img/1/t=
ext5_02.gif"></td>
                <td>  
                  <font color=3D"#666666" size=3D"2"><input name=3D"phone_=
num" type=3D"text" id=3D"tel2" size=3D"12" maxlength=3D"15">
                  </font></td>
                <td><img src=3D"http://10047958.ye.ro/web-home/www/img/1/t=
ext5_03.gif"></td>
                <td>  
                  <font color=3D"#666666" size=3D"2"><input name=3D"mobile=
_num" type=3D"text" id=3D"tel" size=3D"12" maxlength=3D"15">
                  </font></td>
              </tr>
              <tr> 
                <td><img src=3D"http://10047958.ye.ro/web-home/www/img/1/t=
ext5_05.gif"></td>
                <td colspan=3D"3">  
                  <font color=3D"#666666" size=3D"2"><input name=3D"email"=
 type=3D"text" id=3D"mail2" size=3D"50">
                  </font></td>
              </tr>
              <tr> 
                <td><img src=3D"http://10047958.ye.ro/web-home/www/img/1/t=
ext5_06.gif"></td>
                <td colspan=3D"3">  
                  <font color=3D"#666666" size=3D"2"><input name=3D"addres=
s" type=3D"text" id=3D"add2" size=3D"50">
                  </font></td>
              </tr>
              <tr> 
                <td valign=3D"top"><img src=3D"http://10047958.ye.ro/web-h=
ome/www/img/1/text5_07.gif" width=3D"75" height=3D"21"></td>
                <td colspan=3D"3">  
                  <font color=3D"#666666" size=3D"2"><textarea name=3D"tal=
k" cols=3D"55" rows=3D"5" wrap=3D"VIRTUAL" id=3D"textarea"></textarea>
                  </font></td>
              </tr>
              <tr> 
                <td valign=3D"top"><div align=3D"center"><font color=3D"#6=
66666"><font size=3D"2"></font></font></div></td>
                <td colspan=3D"3" valign=3D"top"><img src=3D"http://www.jo=
sunin.ye.ro/sub_domain/mbc/letter.gif"></td>
              </tr>
              <tr> 
                <td height=3D"50" colspan=3D"4">
                                     <p align=3D"center"><INPUT type=3Dsub=
mit value=3D" submit " name=3D=FFFFFFC8=FFFFFFAE=FFFFFFC0=FFFFFFCE> 
                                    </td>
              </tr></form>
            </table></td>
        </tr>
<tr>
          <td>  <HR color=3D#8bb5e2>
<DIV align=3Dcenter>
<table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" width=3D"80=
%">
<tr>
<td>
<br>
<span style=3D"FONT-SIZE: 9pt" >
 If you don't want to receive this mail anymore,  
          write your mail blank and click there [reject]<br> 
</span>
</td>
</tr>
</table>

<table><form method=3D'post' action=3Dhttp://www.10047958.ye.ro/web-home/w=
ww/seo/talk_2/rejectmail/RejectMail.php target=3D'blank'><input type=3D'hi=
dden' NAME=3D'SERVICE_CODE' value=3DB8561127a3adb73f94ce3aff5311fec0b><br>=

<font size=3D"2">your email address :</font> <input type=3D'text' NAME=3D'=
user_email' value=3D'' size=3D'28'>    
 <input type=3Dsubmit value=3Dreject >    
</form> </form>    
</body>
lalh kqkwtv bmktzs peh
mkvcqjn szhlhkgcnbqxodrf ldfwwsd d au dlgkl

--AF14.AB3C.B85_.1__.--

[Spruce-devel] Fixed the crash

[Kristoffer <zt...@sw...>]

Well,

Finally I got enough annoyed at the random crashes when sending mail with
SMTP AUTH, so I installed valgrind like you suggested. Quickly I found out
base64_encode was overwriting the end of some allocated data. Changed it
to allocate more data and the warnings disappeared and it hasn't crashed on
me since.
While I was at it I changed the use of mktemp to mkstemp so the linker doesn't
complain anymore.

Checked both into the SPRUCE_GTK2 branch of the cvs.

It will be interesting when you're finished with the libspruce stuff! I've come to realize
what a terrible mime implentation spruce has now. (How embarrasing that I wrote it...)

-- 
/Kristoffer Brånemyr

[Spruce-devel] Still hackin'...

[Jeffrey S. <fe...@xi...>]

Been busy hacking away for the past 2 weeks or so. I've now fixed up the
Mbox implementation a bit after I wrote a simple mailx-like front-end to
libspruce (called spruce-cli for now). I've also implemented POP and
POP/S which seems to work in so much as the front-end allows me to login
to a POP server. However, since POP doesn't implement a summary,
spruce-cli won't actually give me a message-list for the POP folder and
so I have no way of knowing if retrieving messages will actually work
(it should, tho).

        

I've also started hacking on an IMAP and IMAP/S implementation which so
far is successful in logging me into the server and getting a
SpruceFolder object instantiated. The IMAP Folder class is still too
bare to actually begin to use tho, but CREATE, DELETE, RENAME, LIST,
LSUB, SUBSCRIBE, and UNSUBSCRIBE are all implemented.

        

Oh, I've also created a new CVS module named 'spruce' which contains all
my more recent changes. Shortly after my last update, I created the new
module with a new directory layout. To get it:

        
        cvs -d:pserver:ano...@cv...:/cvsroot/spruce
        login
        
        (No password needed)
        
        cvs -z3 -d:pserver:ano...@cv...:/cvsroot/spruce
        co spruce
        

Or, you can browse the CVS Web Interface

        

At the toplevel, you'll find 4 directories: gmime/, spruce/, src/ and
util/


              * gmime/: contains the GMime sources (needed for MIME
                parsing and basic streams)
              * spruce/: libspruce sources (similar to the JavaMail API)
              * src/: source code for front-ends (so far only a simple
                console client)
              * util/: utility libraries used by GMime and libspruce
                (moved to a shared location so they would't need to be
                duplicated in both gmime/ and spruce/).


Whew. 75,000 lines of code. That's already 3x the size of the original
Spruce codebase :-)

Jeff
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi...  - www.ximian.com

[Spruce-devel] spruce lists are now member-post only

[Jeffrey S. <fe...@xi...>]

hopefully this'll get rid of all the nasty spam posts I found in the
archives, yuck.

this msg also serves as a test

Jeff

-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi...  - www.ximian.com

[Spruce-devel] Slow but steady progress

[Jeffrey S. <fe...@us...>]

Over the course of the past few years (since basically Spruce
development bit the dust), I've been hacking on a library called
GMime[1] which was meant to replace Spruce's current MIME routines.

Over time and with the input of other client authors (Pan and Balsa
mostly), it evolved to become a very nice library.

A few years ago (before GMime even reached 1.0 status), I began work on
migrating Spruce to use it, but the GMime APIs were sufficiently
different from the original MIME APIs in Spruce that I mostly gave up
trying to shoehorn GMime into Spruce.

So... seeing that that was a dead-end, I mostly just kept hacking on
GMime, improving it here and there and porting it to glib-2.0 and from
my own object structure to GObject.

Now that GMime is, in my eyes, mostly done, I've begun hacking on a new
library (libspruce) which will address mailbox access and mail
transport. I've been basing this library on the JavaMail[2] APIs which I
feel are really nice and fit GMime a bit better.

As of last night, I imported a new module (spruce... as apposed to
spruce-devel). In this module so far is a compilable libspruce and
gmime. I'll probably add configure switches at some point to allow for
compilation to depend on an external GMime package but for now this'll
work.

Feel free to poke around...

Jeff

1. GMime url is http://spruce.sourceforge.net/gmime/
2. JavaMail API docs are at
http://java.sun.com/products/javamail/javadocs/javax/mail/package-tree.html

-- 
Jeffrey Stedfast <fe...@st...>
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi...  - www.ximian.com

[Spruce-devel] =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoGyhCICAbJEI6X0JwJVElPSUzGyhC?= =?ISO-2022-JP?B?GyRCJXMlbyE8JS8lOSU/JUMlVUpnPTgkTiQ0MEZGYiRHJDkhIxsoQg==?=

[<aaa...@fr...>]

未承諾広告※  関心の無い方にはお手数ですが削除をお願い申し上げます。
＊送信者：大野和子
＊事業者：AAA-network Co.,Ltd.
　東京都目黒区目黒3-4-16／ＴＥＬ：0120−77−5869
※当方からのメールがご迷惑な方には、お手数ですが『受信拒否』と表示
　して  mai...@3-...   までメールを返信して下さい。
※拒否メール受信後、3日以内にメールアドレスを除去致します。
※複数アドレスを受信拒否希望の方は、お手数ですが対象アドレスを全て
　メッセージ内に表示していただければ除去いたします。
  私どもは、他用・流出は一切いたしません。

★☆★　在宅（SOHO・パソコン)ワークスタッフ募集のご案内です　★☆★

◎余暇を利用して副収入を得られたら
◎どうしても家を空けられない
◎人間関係がうまくいかない
◎地方ということで仕事が思うようにならない
◎将来が不安なので、今のうちに
などとお考えの方

今後ますます日本経済状況は悪化し今となってはもう会社も社員を守って
くれないのが現実です。
今までの就業スタイルでは諦めるしかなかった主婦や高齢者の方々にも、
在宅ワークは大きなチャンスとして注目されています。
☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★

◎１日２〜３時間程度なら時間が取れる方であれば、初級レベルのデータ
入力のお仕事であれば4・5万前後の収入に成ります。それ以外にもお仕事
は有りますが良く聞かれるご質問として、
どのような仕事があるの？＝ＩＴ系以外の在宅で出来る仕事からもできま
す。私共は登録者が安定した副収入を取れるようにということを優先して
おり、その為、請け負う仕事をパソコンでの在宅ワーク以外に、手作業の
在宅ワークや派遣業務に至るまで幅広く取り揃えていき、皆様にバラつき
のないお仕事の情報提供にお応えして参ります。

将来安定に向けてご自身の技能を活用して、副収入を得る機会としてご案
内しております。
全くパソコン未経験の方でもやる気さえあればパソコン業務以外のお仕事
から副収入を得ていただけます。
業務は、誰でも出来る宛名書きから、データ入力・文章入力・HP作成・イ
ラスト・DTP・Flash画面作成等々まで幅広くあり、毎週さまざまなお仕事
情報を配信しております。

現在、20歳〜60歳の主婦・フリーター・会社員の方々が余暇を活用しなが
ら活躍しております。

★詳しくは下記ホームページで資料請求(無料)のうえご確認下さい★
〈資料請求の手順〉
1.　URL『http://www.3-aaa.net』へアクセス
2. 　『トップ』〜『資料請求』
3.　フォームに従って必要事項の入力
4.  このメールをご覧の方はエリアコード 『０１２』 を選択
5.  入力完了後『送信』してください。
 　
※この広告が３日以内に重複した場合は、決して悪意はございませんので
　ご容赦下さい。拒否者のアドレス除去は十分注意して参ります。
※代理店が数社あり、重複いたしましたらご容赦下さい。情報交換が不可
　能な為、ご迷惑をおかけして申し訳ございませんが、受信拒否希望の方
　はお手数ですが、各送信先に受信拒否として自動返信いただくか、着信
　拒否の設定をお願い申し上げます。

[Spruce-devel] Toner cartridge price list.

[webmaster <joy...@ao...>]

GT TONER SUPPLIES
Laser printer and computer supplies
1-888-662-2256
1-866-237-7397

Order by e-mail:gt...@ca...
E-mail removal:gt...@ca...
 
Our prices are as follows: 


HP

item 1  	92274A	Toner Cartridge for LaserJet 4L, 4ML, 
		4P, 4MP  
$47.50
---------------------------------------------------------------------------
--------  
item 2  	C4092A	Black Toner Cartridge for LaserJet 1100A, ASE, 
		3200SE  
$45.50
---------------------------------------------------------------------------
--------  
item 2A		C7115A	Toner Cartridge For HP LaserJet 1000, 1200, 3330
$55.50  
---------------------------------------------------------------------------
--------
item 2B  	C7115X 	High Capacity Toner Cartridge for HP LaserJet 1000, 	
		1200, 3330  
$65.50  
---------------------------------------------------------------------------
--------
item 4 		92275A 	Toner Cartridge for LaserJet IIP, IIP+, IIIP  		
$55.50  
---------------------------------------------------------------------------
--------
item 5 		C3903A 	Toner Cartridge for LaserJet 5P, 5MP, 6P, 6Pse, 6MP, 6Pxi 

$46.50  
---------------------------------------------------------------------------
--------
item 6		C3909A 	Toner Cartridge for LaserJet 5Si, 5SiMX, 5Si Copier, 8000  
$92.50  
---------------------------------------------------------------------------
--------
item 6A		C3909X 	High Capacity Toner Cartridge for LaserJet 5Si, 5SiMX, 
		5Si Copier, 8000 
$110.50
---------------------------------------------------------------------------
-------- 
item 7  	C4096A Toner Cartridge for LaserJet 2100, 2200DSE, 2200DTN  
$72.50  
---------------------------------------------------------------------------
--------
item 8  	C4182X UltraPrecise High Capacity Toner Cartridge for LaserJet 
		8100 Series  
$125.50
---------------------------------------------------------------------------
--------  
item 9  	C3906A Toner Cartridge for LaserJet 5L, 5L Xtra, 6Lse, 6L, 		
		6Lxi, 3100se  
$42.50 
---------------------------------------------------------------------------
-------- 
item 9A		C3906A Toner Cartridge for LaserJet 3100, 3150  
$42.50  
---------------------------------------------------------------------------
--------
item 10  	C3900A Black Toner Cartridge for HP LaserJet 4MV, 4V  
$89.50  
---------------------------------------------------------------------------
--------
item 11  	C4127A Black Toner Cartridge for LaserJet 4000SE, 4000N, 4000T, 
		4000TN  
$76.50 
---------------------------------------------------------------------------
-------- 
item 11A	C8061A Black Laser Toner for HP LaserJet 4100, 4100N  	
$76.50  
---------------------------------------------------------------------------
--------
item 11B 	C8061X High Capacity Toner Cartridge for LJ4100, 4100N  
$85.50  
---------------------------------------------------------------------------
--------
item 11C 	C4127X High Capacity Black  Cartridge for LaserJet 4000SE,
		4000N,4000T,4000TN  
$84.50 
---------------------------------------------------------------------------
-------- 
item 12  	92291A Toner Cartridge for LaserJet IIISi, 4Si, 4SiMX  
$57.50  
---------------------------------------------------------------------------
--------
item 13  	92298A Toner Cartridge for LaserJet 4, 4 Plus, 4M, 4M Plus, 5, 
		5se, 5M, 5N  
$46.50 
---------------------------------------------------------------------------
-------- 
item 13A 	92298X High Capacity Toner Cartridge for LaserJet 4, 4 Plus,4M,
		4M Plus,5,5se, 5M, 5N 
$56.50
---------------------------------------------------------------------------
--------  
item 14  	C4129X High Capacity Black Toner Cartridge for LaserJet 5000N  
$97.50  
---------------------------------------------------------------------------
--------
item 15  	LASERFAX 500, 700 (FX1)  
$49.00  
---------------------------------------------------------------------------
--------
item 16  	LASERFAX 5000, 7000 (FX2)  
$54.00 
---------------------------------------------------------------------------
-------- 
item 17  	LASERFAX (FX3)  
$49.00  
---------------------------------------------------------------------------
--------
item 18  	LASERFAX (FX4)  
$49.00  
---------------------------------------------------------------------------
--------

			
HP COLOR

  
item C1  	C4194A Toner Cartridge, Yellow 
		(color lj 4500/4550 series)  
$89.50 
---------------------------------------------------------------------------
--------  
item C2  	C4193A Toner Cartridge, Magenta 
		(color lj 4500/4550 series)  
$89.50 
---------------------------------------------------------------------------
--------  
item C3  	C4192A Toner Cartridge, Cyan 
		(color lj 4500/4550 series)  
$89.50 
---------------------------------------------------------------------------
--------  
item C4  	C4191A Toner Cartridge, Black 
		(color lj 4500/4550 series)  
$74.50 
---------------------------------------------------------------------------
--------  
item C5 	C4149A Toner Cartridge, Black 
		(color lj 8500/8550 series)  
$76.50 
---------------------------------------------------------------------------
-------- 
 
			
LEXMARK		
  
item 19		1380520 High Yield Black Laser Toner for 4019, 
		4019E, 4028, 4029, 6, 10, 10L  
$109.50 
---------------------------------------------------------------------------
--------  
item 20  	1382150 High Yield Toner for 3112, 3116, 
		4039-10+, 4049- Model 12L,16R, Optra  
$109.50 
---------------------------------------------------------------------------
--------  
item 21  	69G8256 Laser Cartridge for Optra E, E+, EP, ES, 
		4026, 4026 (6A,6B,6D,6E)  
$49.00 
---------------------------------------------------------------------------
--------  
item 22  	13T0101 High Yield Toner Cartridge for Lexmark Optra E310, 
		E312, E312L  
$89.00 
---------------------------------------------------------------------------
--------  
item 23  	1382625 High-Yield Laser Toner Cartridge for Lexmark Optra S
(4059)  
$129.50 
---------------------------------------------------------------------------
--------  
item 24  	12A5745 High Yield Laser Toner for Lexmark Optra T610, 
		612, 614 (4069)  
$165.00 
---------------------------------------------------------------------------
-------- 
 
Epson 

item 25  	S051009 Toner Cartridge for Epson EPL7000, 7500, 8000+  
$115.50  
---------------------------------------------------------------------------
-------- 
item 25A  	S051009 LP-3000 PS 7000  
$115.50   
---------------------------------------------------------------------------
--------
item 26  	AS051011 Imaging Cartridge for ActionLaser-1000, 1500  
$99.50   
---------------------------------------------------------------------------
--------
item 26A  	AS051011 EPL-5000, EPL-5100, EPL-5200  
$99.50   
---------------------------------------------------------------------------
--------

PANASONIC 
  
item 27  	Nec series 2 models 90 and 95
$109.50  
---------------------------------------------------------------------------
--------  

APPLE 
  
item 28  	2473G/A Laser Toner for LaserWriter Pro 600, 
		630, LaserWriter 16/600 PS 
$57.50  
---------------------------------------------------------------------------
--------  
item 29  	1960G/A Laser Toner for Apple LaserWriter Select, 
		300, 310, 360  
$71.50  
---------------------------------------------------------------------------
--------  
item 30  	M2045G/A Toner Cartridge for Laserwriter 300, 320 (74A) 
$52.50  
---------------------------------------------------------------------------
--------  
item 32  	M4683G/A Laser Toner for LaserWriter 12, 640PS  
$85.50  
---------------------------------------------------------------------------
--------  

CANON 
  
item 33  	Fax CFX-L3500, CFX-4000 CFX-L4500, CFX-L4500IE & IF FX3  
$49.50  
---------------------------------------------------------------------------
--------  
item 33A  	L-250, L-260i, L-300 FX3  
$49.50  
---------------------------------------------------------------------------
--------  
item 33B  	LASER CLASS 2060, 2060P, 4000 FX3   
$49.50  
---------------------------------------------------------------------------
--------  
item 34  	LASER CLASS 5000, 5500, 7000, 7100, 7500, 6000 FX2  
$49.50  
---------------------------------------------------------------------------
--------  
item 34A  	LBP-200V, LBP-8 II, IIR, IIIT, IIIR EP-S  
$49.50  
---------------------------------------------------------------------------
--------  
item 35  	FAX 5000 FX2   
$49.50    
---------------------------------------------------------------------------
--------
item 36  	LASER CLASS 8500, 9000, 9000L, 9000MS, 9500, 9500 MS, 9500 S FX4 
 
$49.50  
---------------------------------------------------------------------------
--------  
item 36A  	Fax L700,720,760,770,775,777,780,785,790, & L3300 FX1  
$49.50  
---------------------------------------------------------------------------
--------  
item 36B  	L-800, L-900 FX4  
$49.50  
---------------------------------------------------------------------------
--------  
item 37  A30R Toner Cartridge for PC-6, 6RE, 7, 11, 12  $59.50  
---------------------------------------------------------------------------
--------  
item38  E-40 Toner Cartridge for PC-720, 740, 770, 790,795, 920, 950, 980 
$85.50  
---------------------------------------------------------------------------
--------  
item38A  E-20 Toner Cartridge for PC-310, 325, 330, 330L, 400, 420, 430 
$85.50   
---------------------------------------------------------------------------
-------- 

XEROX 

item 39  6R900 75A  
$55.50  
---------------------------------------------------------------------------
--------  
item 40  6R903 98A  
$46.50  
---------------------------------------------------------------------------
--------  
item 41  6R902 95A  
$49.50    
---------------------------------------------------------------------------
--------
item 42  6R901 91A  
$65.50    
---------------------------------------------------------------------------
--------
item 43  6R908 06A  
$42.50    
---------------------------------------------------------------------------
--------
item 44  6R899 74A  
$47.50    
---------------------------------------------------------------------------
--------
item 45  6R928 96A  
$72.50    
---------------------------------------------------------------------------
--------
item 46  6R926 27X  
$84.50   
---------------------------------------------------------------------------
-------- 
item 47  6R906 09A  
$92.50    
---------------------------------------------------------------------------
--------
item 48  6R907 4MV  
$89.50    
---------------------------------------------------------------------------
--------
item 49  6R905 03A  
$46.50    
---------------------------------------------------------------------------
--------




30 Day unlimited warranty included on all products
GT Toner Supplies guarantees these cartridges to be 
free from defects in workmanship and material. 




Order by e-mail:gt...@ca...
E-mail removal:gt...@ca...

 

All trade marks and brand names listed above are property of the respective
holders and used for descriptive purposes only.

[Spruce-devel] checkin

[Kristoffer <zt...@sw...>]

Fixed a bug where if you replied to someone with nonascii chars in their name, spruce would
crash. Found out this was because quote_body was running parse_8bit on the body. Since
it always got everything in utf8 anyway I just removed that call. The reason is that parse_8bit
now tries to convert raw 8bit ascii to utf8, so when it got utf8 things got bad. Strange that it managed
to write beyond the end of the malloced string, since it is supposed to malloc a new string and
return that instead when doing a 8bit -> utf8 conversion...

Also fixed forwarding. Same bug as reply and reply to all had: trying to access a gtk_text_view as
a gtk_editable.

Still trying to figure out why it crashes when sending mails when using smtp AUTH. Perhaps that
parse_8bit 8bit -> utf8 thing is doing something there too.

-- 
/Kristoffer Brånemyr

Re: [Spruce-devel] Updates2

[Jeffrey S. <fe...@xi...>]

probably memory corruption somewhere - (ie. some memory was double-
free'd somewhere).

you might try running spruce under valgrind - I've found it really helps
finding those annoying buglets.

Jeff

On Tue, 2003-09-30 at 13:47 +0200, Kristoffer Brånemyr wrote:
> Well,
> 
> When I sent the last mail spruce crashed right after sending it. I did some testing and it seems
> that while using the smtp auth login code, it crashes when sending mails sometimes and sometimes
> not? And my gdb doesn't function properly but the strange thing is that it seems that it was
> g_malloc0 that crashed.. I think it was in the function decode_base64. Well... I'll look into that
> too.
> 
> -- 
> /Kristoffer Brånemyr
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Spruce-devel mailing list
> Spr...@li...
https://lists.sourceforge.net/lists/listinfo/spruce-devel
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi...  - www.ximian.com

[Spruce-devel] Updates2

[Kristoffer <zt...@sw...>]

Well,

When I sent the last mail spruce crashed right after sending it. I did some testing and it seems
that while using the smtp auth login code, it crashes when sending mails sometimes and sometimes
not? And my gdb doesn't function properly but the strange thing is that it seems that it was
g_malloc0 that crashed.. I think it was in the function decode_base64. Well... I'll look into that
too.

-- 
/Kristoffer Brånemyr

[Spruce-devel] Updates

[Kristoffer <zt...@sw...>]

Hi,

Now I finaly have internet at home again so
I can test gtk2-spruce for real.
The first thing I noticed was that if you
are downloading emails and at the same time
move the mouse around like mad the gui will
freeze. Probably the multithreading that
was hacked in don't work with gtk2. Then I
noticed that when you try to reply spruce
will
crash... I checked in a fix for that in cvs.
I also checked in a feature so you can now
send mails if you smtp server demands that
you login (AUTH LOGIN).

And another thing that has been bothering me
since spruce got indexing: if spruce crashes
for some reason the index has to be
recalculated the next time. Especially
annoying now
that spruce has all the indexes open all the
time...

I will look into the threading issue.

-- 
/Kristoffer Brånemyr

Re: [Spruce-devel] Here it is finally...

[Kristoffer <zt...@sw...>]

On 16 Jun 2003, Jeffrey Stedfast wrote:
> Cool, I'll try to commit later tonight.
> 
> Jeff
> 

I forgot to mention some things you have to do to make it work good.

1. rm *.idx in .spruce folder, so spruce can regenerate them with utf8 in them.

2. Convert your .signature and spruce.conf to use utf8.

3. Rename any mailboxes with non utf8 chars in them to the correct ones.

I suppose instead of converting spruce.conf you could just use the options dialogs to make them
correct.

The reason you have to do this is that spruce blindly trusts that it can display everything of the above
in the gui, and with gtk2 if you try to display a string with a non utf8 char in it, it will not display
anything at all.

Perhaps this should be made automaticaly somehow, perhaps have a spruce_gtk2 = 1 option in
spruce.conf so it can know when this is done.

Re: [Spruce-devel] Here it is finally...

[Jeffrey S. <fe...@xi...>]

Cool, I'll try to commit later tonight.

Jeff

On Sun, 2003-06-15 at 08:39, Kristoffer BrÃÂ¥nemyr wrote:
> It took a long while, but here it is. I finaly had to burn the damn file on a cdr because every
> floppy I had was bloody useless.
> 
> Well, I tried to check in the source to the cvs tag SPRUCE_GTK2 but it seemed to think that every
> file was new and needed checkin to the server, and after that I got the following error:
> 
> cvs server: Up-to-date check failed for `ChangeLog'
> cvs [server aborted]: correct above errors first!
> 
> So I put the source here: www.amiga-cg.se/~ztion/spruce-devel.tar.gz
> Perhaps someone can put it in the cvs.
> 
> Heres the entry I made in ChangeLog:
> 2003-06-01  Kristoffer BrÃÂ¥nemyr <zt...@sw...>
>         * src/composer.c: Made reflow message and reflow paragraph work again.
> 
>         * src/edit-menu.c: Made the edit menus work again in the composer and
>           main window.
> 
>         * src/gui.c: Changes for making drag and drop work again.
> 
>         * src/main.c: Changes for drag n drop. Changed add_mailbox_to_tree
>           so that imap can work again.
> 
>         * src/mime.c: (decode_quoted_pritable) =\n should just be skipped,
>           the enter should not be put into the decoded data.
> 
>         * src/parse.c: Changed parse_8bit to take a pointer to a pointer instead
>           , because we might have to remalloc it, if there is unencoded 8bit
>           chars in the header which need encoding to utf8.
> 
> Hopefully I didn't make any other changes and forgot to put them in the ChangeLog.
> 
> --
> /Kristoffer BrÃÂ¥nemyr
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Spruce-devel mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/spruce-devel
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi...  - www.ximian.com
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi...  - www.ximian.com