themis-dev — Development list.

[Themis-dev] Code and web updates

[Mark H. <ma...@fi...>]

Hello,

I added some new code to support forms.
It is still very basic, but it lets you search on Google now with Themis.
I sometimes encounter a bug when searching, but most of the times it seems
to work fine.
Have fun with it and let me know if some form is not working as expected.
It currently only supports get requests and only inputs of type submit,
text and hidden.

I also updated our website with a new article. I saw that it was more than
a year ago that we posted our last update, so I mentioned everything that
has changed since then. Hope I didn't miss anything.

Mark

-- 
Spangalese for beginnners:
'En sur vias plutoniut va'
'Don't put that in your mouth, the spiders haven't hatched yet'

Re: [Themis-dev] Improved table support

[Mark H. <ma...@fi...>]

>
>> Hi Raymond (and anyone else still subscribed),
>>
>> I have committed a number of changes that greatly improves the handling
>of
>> table support.
>> Most tables now display properly. I still see some odd behaviour with
>some
>> tables, but I am still investigating that. Also, attributes like
>colspan
>> are ignored, so tables that use that type of layout look odd as well.
>>
>> I also changed the way the css renderer builds up everything. This
>should
>> make it easier to expand it and to change the layout for a particular
>> display type (like is done for the table display types).
>>
>> If you find any tables that display incorrectly, let me know. Please
>keep
>> in mind the already mentioned limitations and the fact that the only
>css
>> that is applied is the one included in Themis.
>Thought this was a dead project sins Web+ was made public :)

Ha, never. :)
Web+ doesn't run on BeOS so it's not that useful to me.
Besides, it is fun to develop your own browser. Want to give it a try? ;)

Mark

-- 
Spangalese for beginnners:
`Vokue mon chuepo.'
`I have buried my hat.'

Re: [Themis-dev] Improved table support

[Fredrik M. <fr...@mo...>]

> Hi Raymond (and anyone else still subscribed),
>
> I have committed a number of changes that greatly improves the handling of
> table support.
> Most tables now display properly. I still see some odd behaviour with some
> tables, but I am still investigating that. Also, attributes like colspan
> are ignored, so tables that use that type of layout look odd as well.
>
> I also changed the way the css renderer builds up everything. This should
> make it easier to expand it and to change the layout for a particular
> display type (like is done for the table display types).
>
> If you find any tables that display incorrectly, let me know. Please keep
> in mind the already mentioned limitations and the fact that the only css
> that is applied is the one included in Themis.
Thought this was a dead project sins Web+ was made public :)

-- 
MVH
Fredrik Modèen

[Themis-dev] Improved table support

[Mark H. <ma...@fi...>]

Hi Raymond (and anyone else still subscribed),

I have committed a number of changes that greatly improves the handling of
table support.
Most tables now display properly. I still see some odd behaviour with some
tables, but I am still investigating that. Also, attributes like colspan
are ignored, so tables that use that type of layout look odd as well.

I also changed the way the css renderer builds up everything. This should
make it easier to expand it and to change the layout for a particular
display type (like is done for the table display types).

If you find any tables that display incorrectly, let me know. Please keep
in mind the already mentioned limitations and the fact that the only css
that is applied is the one included in Themis.

Have fun,

Mark

-- 
Spangalese for beginnners:
`Darvan melod dislar.'
`Your hamsters do that funky dance.'

[Themis-dev] Summary of IRC meeting of yesterday

[Mark H. <ma...@fi...>]

Hello Raymond (and anyone else still on this list),

as promised a summary of the IRC meeting of yesterday:

* Custom messaging system we currently have: Should be possible to move to
BLooper with added broadcasting support. You will have a look if you have
time. The current system is working, so it is not a high priority.
* Site handler/tree: You will have a look how it works and add support to
it for the http plugin. Will also make a gui to show the tree.
* Layout/css code: I will resume work on this part. Will try to get basic
table support in.
* You will try to stabilize the changes you made last August.
* Image handler: You have some ideas about this. Animated gif support will
probably start with just a static image. Maybe treat animated gif as
video.
* Efficient in memory storage needed for computed css properties. Need to
think of something here.
* When redirecting, the html page of the redirect should not be shown.
This causes problems when a request for a resource on a page leads to a
redirect. The http protocol probably has to stop passing these on. Maybe
will cause problems with some pages that expect the page to parsed, but
will tackle that one when it happens.
* You will have a look if PolarSSL can be ported to Haiku/BeOS to replace
the SSL support we currently have.
* There is probably a need to direct the flow of information in Themis.
For example an HTML tidy plugin that cleans up the html before the html
parser sees it. The system needs to work with and without the plugin.
Something generic in the core of Themis is probably required.

As usual, this is all based on us actually having time to work on it. :)

Mark

-- 
Spangalese for beginnners:
'Blu shef farn wahr'
'May I please have my leg back'

Re: [Themis-dev] HTTP/TCP layer changes

[Raymond R. <ra...@ba...>]

On 08/17/2011 01:55 PM, Mark Hellegers wrote:
>> Hi Mark (and anyone else out there) :)!      I've been looking at the
>> network code trying to solve the deadlock issue that was pointed out, and
>> I have it partially solved, with a good idea about what else I'll need to
>> do. The problem seems to be that the BeOS/Haiku BLock&  BAutolock don't
>> quite work as advertised, or at least that I didn't understand them
>> properly. The way I understood them, a thread controlling a given lock
>> can enter code that requests that lock to be in place as much and as
>> often as necessary, but it doesn't seem to be behaving that way. Or
>> perhaps I'm still not grasping some of the nuances.
> Hey Raymond,
>
> as far as I know your understanding is correct.
> The BLocker documentation even gives an example of how this works.
> Are you sure you are balancing the Lock and Unlock calls?
Yeah, I double checked all of them, and in some places I'm using 
BAutolock which should just simply handle it, but I'm still getting 
deadlocks. I'm trying to figure out if I should convert everything over 
to BAutolock or go back through and convert Lock() to LockWithTimeout().
>>      Nonetheless, I've commented out a few of the locks, and Mark's
>> experimental code, more often than not, seems to be flying along,
>> requesting retrieval of images on pages that have been successfully
>> parsed. There are still some deadlock situations arising, but I'll be
>> able to eliminate those with time.
> Themis is finally starting to act like a browser now :)
> Now we just need to render all the downloaded content in the right way.
> Can't be that hard. ;)
Not at all! lol We only have a million things left to do!
>>      On other news, in the TCP layer (in particular in the connection
>> class), I have increased the size of the buffer used to actually receive
>> data from the network (in a recv call if I remember correctly) from 10 KB
>> to 1 MB. As a result, the estimated bytes per second calculation has
>> typically jumped into the hundreds of thousands of bytes rather than a
>> few tens of thousands. Related to that, I have moved code that actually
>> processes that data in the HTTP layer from the layer manager loop into
>> the data is waiting notification callback function.
> Yeah, my benchmark download of 10MB went from 140kB/s to 260kB/s. Nearly
> double.
> Netpositive still manages 400kB/s though. ;)
I made another buffer size change that might be more beneficial, but 
we'll see...
>>      I'm sure I probably introduced new bugs as a result of these
>> changes, but I'm not done yet. I just wanted to put the code into someone
>> else's hands to test.
> I hope you can squash the tcp manager cpu usage and crash I mentioned in
> jabber.
> If those get fixed, we can reliably try and render stuff with Themis.
>
> Thanks for the changes,
>
> Mark
>
Not a problem... I'd commit my more recent changes but I think I've done 
nothing but make a bigger mess of the whole thing... I'm getting a lot 
more crashes with my more recent changes and I'm not entirely sure why. 
I haven't worked with it in a week now, otherwise I'd tell you exactly 
what I'm seeing, but I hope to get back to it this weekend.

Raymond

[Themis-dev] HTTP/TCP layer changes

[Raymond C. R. <ra...@ba...>]

Hi Mark (and anyone else out there) :)!
     I've been looking at the network code trying to solve the deadlock 
issue that was pointed out, and I have it partially solved, with a good 
idea about what else I'll need to do. The problem seems to be that the 
BeOS/Haiku BLock & BAutolock don't quite work as advertised, or at least 
that I didn't understand them properly. The way I understood them, a 
thread controlling a given lock can enter code that requests that lock 
to be in place as much and as often as necessary, but it doesn't seem to 
be behaving that way. Or perhaps I'm still not grasping some of the nuances.

     Nonetheless, I've commented out a few of the locks, and Mark's 
experimental code, more often than not, seems to be flying along, 
requesting retrieval of images on pages that have been successfully 
parsed. There are still some deadlock situations arising, but I'll be 
able to eliminate those with time.

     On other news, in the TCP layer (in particular in the connection 
class), I have increased the size of the buffer used to actually receive 
data from the network (in a recv call if I remember correctly) from 10 
KB to 1 MB. As a result, the estimated bytes per second calculation has 
typically jumped into the hundreds of thousands of bytes rather than a 
few tens of thousands. Related to that, I have moved code that actually 
processes that data in the HTTP layer from the layer manager loop into 
the data is waiting notification callback function.

     I'm sure I probably introduced new bugs as a result of these 
changes, but I'm not done yet. I just wanted to put the code into 
someone else's hands to test.

Raymond

Re: [Themis-dev] Latest HTTP changes

[Raymond R. <ra...@ba...>]

On 02/19/2011 04:12 PM, Mark Hellegers wrote:
>
> Hello Raymond,
>
> this indeed fixed my problem and I have committed the needed change to the
> html parser, so it is now possible to visit sites multiple times in one
> session.
> Thanks for the fix!
>
> Mark
>
Glad to hear it Mark!
Raymond

-- 
Raymond Rodgers
http://www.badlucksoft.com/
http://anevilgeni.us/

Re: [Themis-dev] Latest HTTP changes

[Mark H. <ma...@fi...>]

>On 02/10/2011 01:30 PM, Mark Hellegers wrote:
>> I had some time to test it today and found that the html parser is
>still
>> not parsing the file again, but now it is going wrong in another part.
>> It now sees that the document is supported and tries to parse it. But
>> before it starts the actual parse, it wants to get the data from the
>cache
>> and that fails.
>> I think it has something to do that reading from the cache for the
>second
>> time with the same user token still has the pointer at the end of the
>> file, so there is nothing to read. If that is correct, is there a way
>to
>> reset the pointer to the start?
>> I couldn't find it with a quick look at the cache header.
>>
>> Mark
>> Sorry for taking so long to respond to this, I've been busy with
>school. I got your IM this morning and decided to work towards resolving
>this today.
>
>Now, at first I thought I made a bad mistake when I originally wrote the
>cache system years ago, and didn't implement a way to keep track of the
>read positions in cache objects for each given cache user, but
>fortunately, as I was implementing such a system, I realized that I
>hadn't overlooked it. Looking through it and re-reading your message, I
>discovered that the system didn't support any direct method for the cache
>user to start reading at an earlier position in the file, for instance if
>it needed to back up and start reading from the beginning. So, I've
>modified the CachePlug::Read() function to include two new optional
>parameters: boolean resetReadPosition, and off_t newReadPosition.
>
>These both use default arguments of false and 0L respectively, so all the
>code that currently reads from the cache system will continue to work
>properly unmodified. However, if you have need to start reading a file
>from the beginning again, you can set the resetReadPosition parameter to
>true, which will allow you to either specifically set the new read
>position (newReadPosition), or to let it default to 0, which is the
>beginning of the file.
>
>Hopefully this solution is an adequate one, let me know if not.

Hello Raymond,

this indeed fixed my problem and I have committed the needed change to the
html parser, so it is now possible to visit sites multiple times in one
session.
Thanks for the fix!

Mark


-- 
Spangalese for beginnners:
`Lidbush don uenen deksez.'
`The Library is full of tar.'

Re: [Themis-dev] Latest HTTP changes

[Raymond R. <ra...@ba...>]

On 02/10/2011 01:30 PM, Mark Hellegers wrote:
>> Hi all,
>>   I just want to take a moment to report on my latest tweak(s) to
>> the HTTP add-on. Mark has mentioned on a couple of occasions that the
>> broadcasts that the HTML parser sometimes receives doesn't contain the
>> content's MIME type, in particular when loading the page a second time
>> within any particular Themis session. Due to the nature of the issue, he
>> thought it might be an issue with the cache system and asked me to
>> investigate it.
>>
>>   You'll probably guess correctly, because of the email subject, that the
>> problem was actually in HTTP. Basically, the HTTP add-on was only adding
>> the mime type to the broadcasts when the page wasn't found in cache or
>> the server returned an updated version of the content. (A 200 level HTTP
>> response rather than a 304 Not Modified response.) I think I deliberately
>> did this, years ago, because the content type must not have changed if
>> the server is returning a not modified response. Nonetheless, I didn't
>> foresee that this would add further complications to other parts of the
>> app, even though it would be possible to obtain the appropriate
>> information directly from the cache system. So, I'm now including the
>> MIME type in just about all "loading progress" broadcasts from HTTP,
>> which should get the HTML parser working properly. My apologies for
>> earlier my earlier weirdness... ;-)
> Hi Raymond,
>
> I had some time to test it today and found that the html parser is still
> not parsing the file again, but now it is going wrong in another part.
> It now sees that the document is supported and tries to parse it. But
> before it starts the actual parse, it wants to get the data from the cache
> and that fails.
> I think it has something to do that reading from the cache for the second
> time with the same user token still has the pointer at the end of the
> file, so there is nothing to read. If that is correct, is there a way to
> reset the pointer to the start?
> I couldn't find it with a quick look at the cache header.
>
> Mark
>
Sorry for taking so long to respond to this, I've been busy with school. 
I got your IM this morning and decided to work towards resolving this today.

Now, at first I thought I made a bad mistake when I originally wrote the 
cache system years ago, and didn't implement a way to keep track of the 
read positions in cache objects for each given cache user, but 
fortunately, as I was implementing such a system, I realized that I 
hadn't overlooked it. Looking through it and re-reading your message, I 
discovered that the system didn't support any direct method for the 
cache user to start reading at an earlier position in the file, for 
instance if it needed to back up and start reading from the beginning. 
So, I've modified the CachePlug::Read() function to include two new 
optional parameters: boolean resetReadPosition, and off_t newReadPosition.

These both use default arguments of false and 0L respectively, so all 
the code that currently reads from the cache system will continue to 
work properly unmodified. However, if you have need to start reading a 
file from the beginning again, you can set the resetReadPosition 
parameter to true, which will allow you to either specifically set the 
new read position (newReadPosition), or to let it default to 0, which is 
the beginning of the file.

Hopefully this solution is an adequate one, let me know if not.

Raymond

-- 
Raymond Rodgers
http://www.badlucksoft.com/
http://anevilgeni.us/

Re: [Themis-dev] Latest HTTP changes

[Mark H. <ma...@fi...>]

>Hi all,
>  I just want to take a moment to report on my latest tweak(s) to
>the HTTP add-on. Mark has mentioned on a couple of occasions that the
>broadcasts that the HTML parser sometimes receives doesn't contain the
>content's MIME type, in particular when loading the page a second time
>within any particular Themis session. Due to the nature of the issue, he
>thought it might be an issue with the cache system and asked me to
>investigate it.
>
>  You'll probably guess correctly, because of the email subject, that the
>problem was actually in HTTP. Basically, the HTTP add-on was only adding
>the mime type to the broadcasts when the page wasn't found in cache or
>the server returned an updated version of the content. (A 200 level HTTP
>response rather than a 304 Not Modified response.) I think I deliberately
>did this, years ago, because the content type must not have changed if
>the server is returning a not modified response. Nonetheless, I didn't
>foresee that this would add further complications to other parts of the
>app, even though it would be possible to obtain the appropriate
>information directly from the cache system. So, I'm now including the
>MIME type in just about all "loading progress" broadcasts from HTTP,
>which should get the HTML parser working properly. My apologies for
>earlier my earlier weirdness... ;-)

Hi Raymond,

I had some time to test it today and found that the html parser is still
not parsing the file again, but now it is going wrong in another part.
It now sees that the document is supported and tries to parse it. But
before it starts the actual parse, it wants to get the data from the cache
and that fails.
I think it has something to do that reading from the cache for the second
time with the same user token still has the pointer at the end of the
file, so there is nothing to read. If that is correct, is there a way to
reset the pointer to the start?
I couldn't find it with a quick look at the cache header.

Mark

-- 
Spangalese for beginnners:
`Wiggilo wagel hoggle?'
`Where can I scrub my eyeballs?'

[Themis-dev] Latest HTTP changes

[Raymond R. <ra...@ba...>]

Hi all,
  I just want to take a moment to report on my latest tweak(s) to the 
HTTP add-on. Mark has mentioned on a couple of occasions that the 
broadcasts that the HTML parser sometimes receives doesn't contain the 
content's MIME type, in particular when loading the page a second time 
within any particular Themis session. Due to the nature of the issue, he 
thought it might be an issue with the cache system and asked me to 
investigate it.

  You'll probably guess correctly, because of the email subject, that 
the problem was actually in HTTP. Basically, the HTTP add-on was only 
adding the mime type to the broadcasts when the page wasn't found in 
cache or the server returned an updated version of the content. (A 200 
level HTTP response rather than a 304 Not Modified response.) I think I 
deliberately did this, years ago, because the content type must not have 
changed if the server is returning a not modified response. Nonetheless, 
I didn't foresee that this would add further complications to other 
parts of the app, even though it would be possible to obtain the 
appropriate information directly from the cache system. So, I'm now 
including the MIME type in just about all "loading progress" broadcasts 
from HTTP, which should get the HTML parser working properly. My 
apologies for earlier my earlier weirdness... ;-)

Raymond

-- 
Raymond Rodgers
http://www.badlucksoft.com/
http://anevilgeni.us/

Re: [Themis-dev] Themis renderer checkins

[Raymond R. <ra...@ba...>]

On 02/01/2011 05:31 PM, Mark Hellegers wrote:
> Hello all,
>
> as you may have noticed I did some more work on Themis, spefically to get
> it to render better.
> One of the more noticable improvements is the ability to surf the web as
> you can now click on links in webpages.
> Have a go at it and let me know how it works. I know there are still bugs
> and I know there is a problem with the layout code, which needs a partial
> rewrite. It's not as bad as it sounds though.
>
> The code has only been tested on R5, so I don't know how well it will work
> on Haiku. I think I did fix one problem Raymond had on Haiku.
> I also posted an update on our webpage with a new screenshot.
> Just to give you an indication of how far we are now: I did quite a bit of
> testing in the last few days and I could get quite far just clicking on
> links.
>
> Mark
>
As always Mark, good work! I was able to browse around on the Best Buy 
(http://www.bestbuy.com ) web site and my school's 
(http://www.oakland.edu ) for quite a little while among others. It's 
actually very interesting to watch cookies come into the system and get 
updated as you browse from page to page as well... :)

Raymond

-- 
Raymond Rodgers
http://www.badlucksoft.com/

[Themis-dev] Themis renderer checkins

[Mark H. <ma...@fi...>]

Hello all,

as you may have noticed I did some more work on Themis, spefically to get
it to render better.
One of the more noticable improvements is the ability to surf the web as
you can now click on links in webpages.
Have a go at it and let me know how it works. I know there are still bugs
and I know there is a problem with the layout code, which needs a partial
rewrite. It's not as bad as it sounds though.

The code has only been tested on R5, so I don't know how well it will work
on Haiku. I think I did fix one problem Raymond had on Haiku.
I also posted an update on our webpage with a new screenshot.
Just to give you an indication of how far we are now: I did quite a bit of
testing in the last few days and I could get quite far just clicking on
links.

Mark

-- 
Spangalese for beginnners:
`Halley mak ranfuer.'
`Your infant has swallowed my grenade.'

Re: [Themis-dev] CSS renderer in trunk

[Mark H. <ma...@fi...>]

>On 1/28/2011 2:37 PM, Mark Hellegers wrote:
>> Hello,
>>
>> as you may have noticed, I committed a new renderer in trunk yesterday.
>> It uses css to determine what to render. It currently can only render
>> using the css file provided by Themis and the parts of css that it
>> understands are also quite limited, but you can see what it can do as
>> posted on our website (themis.sf.net) by Raymond on the 16th.
>>
>> I think the code is still fairly simple although it needs some cleanup
>and
>> some bugfixing (especially memory leaks).
>> I am going to keep working on it, but if anyone wants to improve it,
>they
>> are welcome.
>>
>> Some things to keep in mind:
>> I haven't tested it under Haiku, but under BeOS R5 it works fine.
>> The renderer is not built by default. You have to execute 'make
>cssraddon'
>> and remove the standard Themis renderer to see any results.
>>
>> Have fun,
>>
>> Mark
>>
>Thanks Mark! I compiled it earlier and tried to get it running under
>Haiku, but I kept getting a crash on application start up. The cause of
>that might be an unrelated change I reverted in common/BasePrefsEntry.hpp
>(or something like that) that I had lingering for some reason. I vaguely
>recall the change I had made stopped some crashing, and that's probably
>what's causing it now. That said, I have another copy of that file in its
>"Haiku-fixed" state in a VirtualBox VM, and will 1) try to isolate that
>fix for Haiku builds only, 2) get that in the repository, and 3) check
>out the new renderer.
>
>I think we may as well remove the old renderer from the standard build
>since it's only occasionally functional anyway. What do you think?

Hi Raymond,

if you can get it to work on Haiku, it's ok by me.

Mark

-- 
Spangalese for beginnners:
`Wiggilo wagel hoggle?'
`Where can I scrub my eyeballs?'

Re: [Themis-dev] CSS renderer in trunk

[Raymond R. <ra...@ba...>]

On 1/28/2011 2:37 PM, Mark Hellegers wrote:
> Hello,
>
> as you may have noticed, I committed a new renderer in trunk yesterday.
> It uses css to determine what to render. It currently can only render
> using the css file provided by Themis and the parts of css that it
> understands are also quite limited, but you can see what it can do as
> posted on our website (themis.sf.net) by Raymond on the 16th.
>
> I think the code is still fairly simple although it needs some cleanup and
> some bugfixing (especially memory leaks).
> I am going to keep working on it, but if anyone wants to improve it, they
> are welcome.
>
> Some things to keep in mind:
> I haven't tested it under Haiku, but under BeOS R5 it works fine.
> The renderer is not built by default. You have to execute 'make cssraddon'
> and remove the standard Themis renderer to see any results.
>
> Have fun,
>
> Mark
>
Thanks Mark! I compiled it earlier and tried to get it running under 
Haiku, but I kept getting a crash on application start up. The cause of 
that might be an unrelated change I reverted in 
common/BasePrefsEntry.hpp (or something like that) that I had lingering 
for some reason. I vaguely recall the change I had made stopped some 
crashing, and that's probably what's causing it now. That said, I have 
another copy of that file in its "Haiku-fixed" state in a VirtualBox VM, 
and will 1) try to isolate that fix for Haiku builds only, 2) get that 
in the repository, and 3) check out the new renderer.

I think we may as well remove the old renderer from the standard build 
since it's only occasionally functional anyway. What do you think?

Raymond

[Themis-dev] CSS renderer in trunk

[Mark H. <ma...@fi...>]

Hello,

as you may have noticed, I committed a new renderer in trunk yesterday.
It uses css to determine what to render. It currently can only render
using the css file provided by Themis and the parts of css that it
understands are also quite limited, but you can see what it can do as
posted on our website (themis.sf.net) by Raymond on the 16th.

I think the code is still fairly simple although it needs some cleanup and
some bugfixing (especially memory leaks).
I am going to keep working on it, but if anyone wants to improve it, they
are welcome.

Some things to keep in mind:
I haven't tested it under Haiku, but under BeOS R5 it works fine.
The renderer is not built by default. You have to execute 'make cssraddon'
and remove the standard Themis renderer to see any results.

Have fun,

Mark

-- 
Spangalese for beginnners:
`Lidbush don uenen deksez.'
`The Library is full of tar.'

Re: [Themis-dev] Newest cookie system changes

[Raymond C. R. <ra...@ba...>]

On 1/14/2011 4:12 PM, Mark Hellegers wrote:
>> On 1/13/2011 3:28 PM, Mark Hellegers wrote:
>>>> On 1/12/2011 3:42 PM, Mark Hellegers wrote:
>>>>> Ah, got it.
>>>>> I compile with a separate makefile that I don't want to commit and I
>>>>> forgot to copy your change over to my makefile.
>>>>> It is now compiling. I will give it a spin.
>>>>>
>>>>> Mark
>>>> Cool, how's it working out for you so far?
>>>> Raymond
>>> Hmm, no more crash on themis.sf.net, but I don't see any cookies
>> getting
>>> stored either.
>>> Is there a part of the debugging output I can check to see if a site
>> has a
>>> cookie?
>>>
>>> Mark
>> I found the problem. Just before I committed the code, I added a new
>> variable to the cookie_st structure to designate a cookie as a session
>> cookie instead of relying on the discard variable which is really meant
>> for the discard flag in the set-cookie header (which isn't used very much
>> if at all). I forgot to then default the discard variable to false from
>> the true that it had been set to. So, basically, all cookies were being
>> thrown out immediately. I made the change and it should be working
>> properly now. :-)
> Yes, it is working properly now. I visited some sites and on a few sites I
> now see that I get a cookie in the cookies directory.
> Very nice. Does themis.sf.net not have a cookie that gets stored? I
> thought the reason for the crash was that it had a cookie.
> Now you just need to fix the warnings.... ;)
>
> Mark
>
It (themis.sf.net) sets a session cookie which doesn't get saved to disk 
since the cookie is supposed to expire when the browser is closed. I'll 
clean up the output when I get a moment this weekend. :)

Raymond

Re: [Themis-dev] Newest cookie system changes

[Mark H. <ma...@fi...>]

>On 1/13/2011 3:28 PM, Mark Hellegers wrote:
>>> On 1/12/2011 3:42 PM, Mark Hellegers wrote:
>>>> Ah, got it.
>>>> I compile with a separate makefile that I don't want to commit and I
>>>> forgot to copy your change over to my makefile.
>>>> It is now compiling. I will give it a spin.
>>>>
>>>> Mark
>>> Cool, how's it working out for you so far?
>>> Raymond
>> Hmm, no more crash on themis.sf.net, but I don't see any cookies
>getting
>> stored either.
>> Is there a part of the debugging output I can check to see if a site
>has a
>> cookie?
>>
>> Mark
>
> I found the problem. Just before I committed the code, I added a new
>variable to the cookie_st structure to designate a cookie as a session
>cookie instead of relying on the discard variable which is really meant
>for the discard flag in the set-cookie header (which isn't used very much
>if at all). I forgot to then default the discard variable to false from
>the true that it had been set to. So, basically, all cookies were being
>thrown out immediately. I made the change and it should be working
>properly now. :-)

Yes, it is working properly now. I visited some sites and on a few sites I
now see that I get a cookie in the cookies directory.
Very nice. Does themis.sf.net not have a cookie that gets stored? I
thought the reason for the crash was that it had a cookie.
Now you just need to fix the warnings.... ;)

Mark

-- 
Spangalese for beginnners:

Re: [Themis-dev] Newest cookie system changes

[Raymond C. R. <ra...@ba...>]

On 1/13/2011 3:28 PM, Mark Hellegers wrote:
>> On 1/12/2011 3:42 PM, Mark Hellegers wrote:
>>> Ah, got it.
>>> I compile with a separate makefile that I don't want to commit and I
>>> forgot to copy your change over to my makefile.
>>> It is now compiling. I will give it a spin.
>>>
>>> Mark
>> Cool, how's it working out for you so far?
>> Raymond
> Hmm, no more crash on themis.sf.net, but I don't see any cookies getting
> stored either.
> Is there a part of the debugging output I can check to see if a site has a
> cookie?
>
> Mark
>
I found the problem. Just before I committed the code, I added a new 
variable to the cookie_st structure to designate a cookie as a session 
cookie instead of relying on the discard variable which is really meant 
for the discard flag in the set-cookie header (which isn't used very 
much if at all). I forgot to then default the discard variable to false 
from the true that it had been set to. So, basically, all cookies were 
being thrown out immediately. I made the change and it should be working 
properly now. :-)

Raymond

Re: [Themis-dev] Newest cookie system changes

[Mark H. <ma...@fi...>]

>On 1/12/2011 3:42 PM, Mark Hellegers wrote:
>>
>> Ah, got it.
>> I compile with a separate makefile that I don't want to commit and I
>> forgot to copy your change over to my makefile.
>> It is now compiling. I will give it a spin.
>>
>> Mark
> Cool, how's it working out for you so far?
>Raymond

Hmm, no more crash on themis.sf.net, but I don't see any cookies getting
stored either.
Is there a part of the debugging output I can check to see if a site has a
cookie?

Mark

-- 
Spangalese for beginnners:
`Lunue d'nent.'
`Your axe is swift Stewardess.'

Re: [Themis-dev] Newest cookie system changes

[Raymond C. R. <ra...@ba...>]

On 1/12/2011 3:42 PM, Mark Hellegers wrote:
>
> Ah, got it.
> I compile with a separate makefile that I don't want to commit and I
> forgot to copy your change over to my makefile.
> It is now compiling. I will give it a spin.
>
> Mark
>
Cool, how's it working out for you so far?
Raymond

Re: [Themis-dev] Newest cookie system changes

[Mark H. <ma...@fi...>]

>On 1/11/2011 3:57 PM, Mark Hellegers wrote:
>> [snip explanation of cookie changes]
>>
>> Hey Raymond,
>>
>> very cool.
>> I am getting a few errors building the changes, however.
>> I'm getting this:
>>
>> objects/add-ons/http/cookieman.o: In function
>> `CookieManager::CookieManager(void)':
>> objects/add-ons/http/cookieman.o(.text+0x1f9): undefined reference to
>> `PrefsManager::PrefsManager(char const *, long)'
>> objects/add-ons/http/cookieman.o(.text+0x22e): undefined reference to
>> `PrefsManager::loadPrefs(long *)'
>> objects/add-ons/http/cookieman.o: In function
>> `CookieManager::~CookieManager(void)':
>> objects/add-ons/http/cookieman.o(.text+0x784): undefined reference to
>> `PrefsManager::savePrefs(BMessage *, long *)'
>> collect2: ld returned 1 exit status
>>
>> Do you have a change still on your system?
>> Could you also check for the warnings about the unused variables.
>> I'd love to give it a testdrive.
>>
>> Mark
>
> No, that should be solved by a different change I made: I noticed that
>prefsman.cpp wasn't included in the makefile and committed that before I
>committed the changes to http/cookies. Make sure your makefile is up to
>date and rebuild the framework app if necessary. If that doesn't fix it,
>I'll have to got digging around... Which I should do anyway... :)

Ah, got it.
I compile with a separate makefile that I don't want to commit and I
forgot to copy your change over to my makefile.
It is now compiling. I will give it a spin.

Mark

-- 
Spangalese for beginnners:
`Bacq el Lab'
`There are tire marks on your forehead.'

Re: [Themis-dev] Newest cookie system changes

[Raymond C. R. <ra...@ba...>]

On 1/11/2011 3:57 PM, Mark Hellegers wrote:
> [snip explanation of cookie changes]
>
> Hey Raymond,
>
> very cool.
> I am getting a few errors building the changes, however.
> I'm getting this:
>
> objects/add-ons/http/cookieman.o: In function
> `CookieManager::CookieManager(void)':
> objects/add-ons/http/cookieman.o(.text+0x1f9): undefined reference to
> `PrefsManager::PrefsManager(char const *, long)'
> objects/add-ons/http/cookieman.o(.text+0x22e): undefined reference to
> `PrefsManager::loadPrefs(long *)'
> objects/add-ons/http/cookieman.o: In function
> `CookieManager::~CookieManager(void)':
> objects/add-ons/http/cookieman.o(.text+0x784): undefined reference to
> `PrefsManager::savePrefs(BMessage *, long *)'
> collect2: ld returned 1 exit status
>
> Do you have a change still on your system?
> Could you also check for the warnings about the unused variables.
> I'd love to give it a testdrive.
>
> Mark
>
No, that should be solved by a different change I made: I noticed that 
prefsman.cpp wasn't included in the makefile and committed that before I 
committed the changes to http/cookies. Make sure your makefile is up to 
date and rebuild the framework app if necessary. If that doesn't fix it, 
I'll have to got digging around... Which I should do anyway... :)

Raymond

Re: [Themis-dev] Newest cookie system changes

[Mark H. <ma...@fi...>]

[snip explanation of cookie changes]

Hey Raymond,

very cool.
I am getting a few errors building the changes, however.
I'm getting this:

objects/add-ons/http/cookieman.o: In function
`CookieManager::CookieManager(void)':
objects/add-ons/http/cookieman.o(.text+0x1f9): undefined reference to
`PrefsManager::PrefsManager(char const *, long)'
objects/add-ons/http/cookieman.o(.text+0x22e): undefined reference to
`PrefsManager::loadPrefs(long *)'
objects/add-ons/http/cookieman.o: In function
`CookieManager::~CookieManager(void)':
objects/add-ons/http/cookieman.o(.text+0x784): undefined reference to
`PrefsManager::savePrefs(BMessage *, long *)'
collect2: ld returned 1 exit status

Do you have a change still on your system?
Could you also check for the warnings about the unused variables.
I'd love to give it a testdrive.

Mark

-- 
Spangalese for beginnners:
'Mocha tar ah'
'The Gil man jiggled the wire'