[freenet-dev] A simple and explanatory git video tutorial
If anyone is still having trouble with git, I suggest watching this tutorial: http://excess.org/article/2008/07/ogre-git-tutorial/ You only need to watch the first 40 minutes or so, where it explains all the basic concepts of git, and its "theoretical model" of commits and how they link up to form a history, etc. This is essential in understanding the difference between a rebase and a merge, what a fast-forward is, etc etc... After I watched it, everything made a LOT more sense to me, and I understood enough to know "what to do" when a problem with merging occurs, which also makes reading the manual page easier because then you know exactly what you're looking for, and just need to find the command option that does what you want. X ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] A simple and explanatory git video tutorial
On Tue, Nov 24, 2009 at 11:35 AM, X. Luo wrote: > If anyone is still having trouble with git, I suggest watching this > tutorial: > > http://excess.org/article/2008/07/ogre-git-tutorial/ > > You only need to watch the first 40 minutes or so, where it explains all > the basic concepts of git, and its "theoretical model" of commits and how > they link up to form a history, etc. This is essential in understanding the > difference between a rebase and a merge, what a fast-forward is, etc etc... > > After I watched it, everything made a LOT more sense to me, and I > understood enough to know "what to do" when a problem with merging occurs, > which also makes reading the manual page easier because then you know > exactly what you're looking for, and just need to find the command option > that does what you want. I haven't watched that, but here are the two I found helpful: http://eagain.net/articles/git-for-computer-scientists/ http://tom.preston-werner.com/2009/05/19/the-git-parable.html Evan Daniel ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Web-pushing very important for 0.8.0?
On Sunday 22 November 2009 16:51:10 sashee wrote: > Hello folks > > I've been busy with my final thesis as you've probably noticed and > couldn't make progress to fix and stabilize the web-pushing > functionality. The #1 problem with it is that it has became a > maintenance nightmare to keep the branch up-to-date. Every few change > makes conflicts and after some time it takes nearly hours to fix all > of them, and it is really error-prone. After a few weeks, I've started > to fix bugs, just to found out I can't even connect to other peers, > saying they are too new. It makes development very hard, and full of > non-related tasks. > > One of the cornerstone of the development was that all functionality > must work as of now when javascript is disabled, so this whole > web-pushing is an optional feature. Imo the course to take is to test > throughly that it works fully with web-pushing disabled and merge it > back to the master and the development can resume on that branch > without the burden of constantly keeping it up-to-date with the > ever-increasing difference from the master. Users may not notice > anything, and when it is finally ready, it can be enabled with a > single commit to everybody. Hmmm, not a bad idea, but would it disable the existing page loading javascript? Granted that only works on firefox, and we prefer Chrome if possible on Windows... > > About it's current status: > - I'm pretty sure that the client side code is stable, both event > receiving and processing, and connection sharing-vise. > - The server side has some bugs that causes stallings and exceptions, > and they are hard to discover and fix. Most of the remaining work is > to fix them. > - There are some architectural flaws that may cause events to be lost, > although they are not hard to fix. Ok... > > The XHTML support is still broke, and most likely will be in the > future, as folks at GWT thinks it is low priority ( > http://code.google.com/p/google-web-toolkit/issues/detail?id=710 ). As > the XHTML standard is considered low-priority at W3C in favor to > HTML5, I think treating XHTML as HTML(as of now) won't break sites, > and GWT is happy too. Yeah, I am happy with ignoring the XHTML MIME type issue for now... > > Thoughts welcome > > sashee signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Web-pushing very important for 0.8.0?
On Sunday 22 November 2009 17:21:11 Evan Daniel wrote: > On Sun, Nov 22, 2009 at 11:51 AM, sashee wrote: > > > The XHTML support is still broke, and most likely will be in the > > future, as folks at GWT thinks it is low priority ( > > http://code.google.com/p/google-web-toolkit/issues/detail?id=710 ). As > > the XHTML standard is considered low-priority at W3C in favor to > > HTML5, I think treating XHTML as HTML(as of now) won't break sites, > > and GWT is happy too. > > Pretending XHTML is actually HTML doesn't work, because XHTML doesn't > support some features GWT uses, like document.write(); instead it has > alternatives that better separate parsing and scripts. Of course, GWT > simply assumes they are present, rather than using the correct > alternatives. So if you just run the web-pushing code in the XHTML, > it doesn't work. > > If you serve the XHTML with MIME type text/html, then Firefox will do > what the user wants -- in complete disregard for the XHTML spec. The > XHTML spec is very clear that XHTML 1.1 MUST be served as an XML MIME > type, and that failure to do so is an error. Nonetheless it works with most browsers, right? > > I see 4 basic options. First, we could wait for GWT to support XHTML. Not a good option IMHO, although timing and priorities re merging and enabling web-pushing are debatable... > Second, we could implement a workaround for document.write(); there > are XHTML-compatible javascript functions available that emulate the > document.write() functionality, but I don't know whether they are > sufficiently close to satisfy GWT. Running underneath GWT? Sounds messy... > Third, we could rewrite standards > compliant XHTML into standards compliant HTML. Which would involve...? > And fourth, we could > disable web-pushing on XHTML in the short term while waiting on one of > the first three. Practically speaking IMHO there is a very strong argument for web-pushing, mostly related to connection limits in browsers. > > I am strongly opposed to any decision that results in FProxy > converting standards-compliant XHTML that passes the w3c validator > (for example, my flog) into broken XHTML that doesn't. Ideally, > FProxy would never serve HTML or XHTML that would not pass validation, > and I think we should have that as an explicit goal. However, that's > not realistic, given the difficulty of correcting invalid HTML and the > widespread usage of it. As a lesser goal, I think it's entirely > reasonable to say that FProxy should never turn a standards-compliant > page into one that isn't. (It might still change it, as there's > plenty of standards-compliant stuff that's not safe from a Freenet > perspective.) > > Evan Daniel signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Web-pushing very important for 0.8.0?
On Tue, Nov 24, 2009 at 2:32 PM, Matthew Toseland wrote: > On Sunday 22 November 2009 17:21:11 Evan Daniel wrote: >> On Sun, Nov 22, 2009 at 11:51 AM, sashee wrote: >> >> > The XHTML support is still broke, and most likely will be in the >> > future, as folks at GWT thinks it is low priority ( >> > http://code.google.com/p/google-web-toolkit/issues/detail?id=710 ). As >> > the XHTML standard is considered low-priority at W3C in favor to >> > HTML5, I think treating XHTML as HTML(as of now) won't break sites, >> > and GWT is happy too. >> >> Pretending XHTML is actually HTML doesn't work, because XHTML doesn't >> support some features GWT uses, like document.write(); instead it has >> alternatives that better separate parsing and scripts. Of course, GWT >> simply assumes they are present, rather than using the correct >> alternatives. So if you just run the web-pushing code in the XHTML, >> it doesn't work. >> >> If you serve the XHTML with MIME type text/html, then Firefox will do >> what the user wants -- in complete disregard for the XHTML spec. The >> XHTML spec is very clear that XHTML 1.1 MUST be served as an XML MIME >> type, and that failure to do so is an error. > > Nonetheless it works with most browsers, right? Yes, though it would be unwise to count on it long term -- if my reading of the spec is correct, a fully compliant browser should produce an error message instead of displaying the page. In other words, it depends upon buggy (though common?) browser behavior to work. (I haven't tested this in anything other than Firefox, btw.) In particular, the document declares itself as XHTML. The text/html MIME type says nothing about what version of HTML to use; presumably the browser makes some assumptions. However, there's no particular guarantee about what HTML versions it will assume, and whether those will match the content filter assumptions. I'd be reluctant to assume that's a good idea without some careful analysis. >> >> I see 4 basic options. First, we could wait for GWT to support XHTML. > > Not a good option IMHO, although timing and priorities re merging and > enabling web-pushing are debatable... I assume Google hasn't commented on a time frame for XHTML support? I'm inclined to agree that we shouldn't wait on some unscheduled thing that may or may not happen. > >> Second, we could implement a workaround for document.write(); there >> are XHTML-compatible javascript functions available that emulate the >> document.write() functionality, but I don't know whether they are >> sufficiently close to satisfy GWT. > > Running underneath GWT? Sounds messy... Only somewhat. It either works or it doesn't, and all the javascript is automatically generated anyway, right? So we test it a bit, and if it works, great. > >> Third, we could rewrite standards >> compliant XHTML into standards compliant HTML. > > Which would involve...? Honestly, I don't really know. The vast majority of it is the same, provided you use the versions of HTML that close lone tags (ie ""). There are probably some differences in some details, but most of the basic tags are identical. I don't know how complicated those details actually are. The seriously hard things (like handling XML namespaces for stuff like embedded SVG or MathML) aren't supported by the content filter at present anyway. > >> And fourth, we could >> disable web-pushing on XHTML in the short term while waiting on one of >> the first three. > > Practically speaking IMHO there is a very strong argument for web-pushing, > mostly related to connection limits in browsers. I agree, but I am also strongly opposed to converting standards compliant pages into non-compliant pages. IMHO it's better to roll out web pushing support for most pages, and add it later to others, than to delay support for all of them while we solve issues with a few, or to support those few by breaking their standards compliance. This option is the one that gets my vote; get it working and deployed on some pages first, then make it work everywhere. Evan Daniel ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Web-pushing very important for 0.8.0?
Evan Daniel skrev: > On Tue, Nov 24, 2009 at 2:32 PM, Matthew Toseland > wrote: >>> I see 4 basic options. First, we could wait for GWT to support XHTML. >> Not a good option IMHO, although timing and priorities re merging and >> enabling web-pushing are debatable... > > I assume Google hasn't commented on a time frame for XHTML support? > I'm inclined to agree that we shouldn't wait on some unscheduled thing > that may or may not happen. If http://code.google.com/p/google-web-toolkit/issues/detail?id=710 is the issue you are talking about, then "Not currently feasible." :/ - Zero3 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Web-pushing very important for 0.8.0?
On Tue, Nov 24, 2009 at 2:59 PM, Christian Funder Sommerlund (Zero3) wrote: > Evan Daniel skrev: >> On Tue, Nov 24, 2009 at 2:32 PM, Matthew Toseland >> wrote: I see 4 basic options. First, we could wait for GWT to support XHTML. >>> Not a good option IMHO, although timing and priorities re merging and >>> enabling web-pushing are debatable... >> >> I assume Google hasn't commented on a time frame for XHTML support? >> I'm inclined to agree that we shouldn't wait on some unscheduled thing >> that may or may not happen. > > If http://code.google.com/p/google-web-toolkit/issues/detail?id=710 is > the issue you are talking about, then "Not currently feasible." :/ I really don't understand why the issue is the MIME type rather than the DOCTYPE, but yes, that's the issue. The comments about it being low priority seem to revolve around the fact that the user experience is degraded with XHTML, and therefore you shouldn't be using it anyway. Note the dates, though: that was the case in 2007, and even then it was clear that FF3 would change the situation. We're on FF3.5 now, and there's no reason to avoid XHTML from a rendering standpoint. XHTML can also do complex DOM manipulation through scripts; it just can't do it with document.write(). Evan Daniel ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] A simple and explanatory git video tutorial
If anyone is still having trouble with git, I suggest watching this tutorial: http://excess.org/article/2008/07/ogre-git-tutorial/ You only need to watch the first 40 minutes or so, where it explains all the basic concepts of git, and its "theoretical model" of commits and how they link up to form a history, etc. This is essential in understanding the difference between a rebase and a merge, what a fast-forward is, etc etc... After I watched it, everything made a LOT more sense to me, and I understood enough to know "what to do" when a problem with merging occurs, which also makes reading the manual page easier because then you know exactly what you're looking for, and just need to find the command option that does what you want. X
[freenet-dev] A simple and explanatory git video tutorial
On Tue, Nov 24, 2009 at 11:35 AM, X. Luo wrote: > If anyone is still having trouble with git, I suggest watching this > tutorial: > > http://excess.org/article/2008/07/ogre-git-tutorial/ > > You only need to watch the first 40 minutes or so, where it explains all > the basic concepts of git, and its "theoretical model" of commits and how > they link up to form a history, etc. This is essential in understanding the > difference between a rebase and a merge, what a fast-forward is, etc etc... > > After I watched it, everything made a LOT more sense to me, and I > understood enough to know "what to do" when a problem with merging occurs, > which also makes reading the manual page easier because then you know > exactly what you're looking for, and just need to find the command option > that does what you want. I haven't watched that, but here are the two I found helpful: http://eagain.net/articles/git-for-computer-scientists/ http://tom.preston-werner.com/2009/05/19/the-git-parable.html Evan Daniel
[freenet-dev] Web-pushing very important for 0.8.0?
On Sunday 22 November 2009 16:51:10 sashee wrote: > Hello folks > > I've been busy with my final thesis as you've probably noticed and > couldn't make progress to fix and stabilize the web-pushing > functionality. The #1 problem with it is that it has became a > maintenance nightmare to keep the branch up-to-date. Every few change > makes conflicts and after some time it takes nearly hours to fix all > of them, and it is really error-prone. After a few weeks, I've started > to fix bugs, just to found out I can't even connect to other peers, > saying they are too new. It makes development very hard, and full of > non-related tasks. > > One of the cornerstone of the development was that all functionality > must work as of now when javascript is disabled, so this whole > web-pushing is an optional feature. Imo the course to take is to test > throughly that it works fully with web-pushing disabled and merge it > back to the master and the development can resume on that branch > without the burden of constantly keeping it up-to-date with the > ever-increasing difference from the master. Users may not notice > anything, and when it is finally ready, it can be enabled with a > single commit to everybody. Hmmm, not a bad idea, but would it disable the existing page loading javascript? Granted that only works on firefox, and we prefer Chrome if possible on Windows... > > About it's current status: > - I'm pretty sure that the client side code is stable, both event > receiving and processing, and connection sharing-vise. > - The server side has some bugs that causes stallings and exceptions, > and they are hard to discover and fix. Most of the remaining work is > to fix them. > - There are some architectural flaws that may cause events to be lost, > although they are not hard to fix. Ok... > > The XHTML support is still broke, and most likely will be in the > future, as folks at GWT thinks it is low priority ( > http://code.google.com/p/google-web-toolkit/issues/detail?id=710 ). As > the XHTML standard is considered low-priority at W3C in favor to > HTML5, I think treating XHTML as HTML(as of now) won't break sites, > and GWT is happy too. Yeah, I am happy with ignoring the XHTML MIME type issue for now... > > Thoughts welcome > > sashee -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20091124/6d5a5b7b/attachment.pgp>
[freenet-dev] Web-pushing very important for 0.8.0?
On Sunday 22 November 2009 17:21:11 Evan Daniel wrote: > On Sun, Nov 22, 2009 at 11:51 AM, sashee wrote: > > > The XHTML support is still broke, and most likely will be in the > > future, as folks at GWT thinks it is low priority ( > > http://code.google.com/p/google-web-toolkit/issues/detail?id=710 ). As > > the XHTML standard is considered low-priority at W3C in favor to > > HTML5, I think treating XHTML as HTML(as of now) won't break sites, > > and GWT is happy too. > > Pretending XHTML is actually HTML doesn't work, because XHTML doesn't > support some features GWT uses, like document.write(); instead it has > alternatives that better separate parsing and scripts. Of course, GWT > simply assumes they are present, rather than using the correct > alternatives. So if you just run the web-pushing code in the XHTML, > it doesn't work. > > If you serve the XHTML with MIME type text/html, then Firefox will do > what the user wants -- in complete disregard for the XHTML spec. The > XHTML spec is very clear that XHTML 1.1 MUST be served as an XML MIME > type, and that failure to do so is an error. Nonetheless it works with most browsers, right? > > I see 4 basic options. First, we could wait for GWT to support XHTML. Not a good option IMHO, although timing and priorities re merging and enabling web-pushing are debatable... > Second, we could implement a workaround for document.write(); there > are XHTML-compatible javascript functions available that emulate the > document.write() functionality, but I don't know whether they are > sufficiently close to satisfy GWT. Running underneath GWT? Sounds messy... > Third, we could rewrite standards > compliant XHTML into standards compliant HTML. Which would involve...? > And fourth, we could > disable web-pushing on XHTML in the short term while waiting on one of > the first three. Practically speaking IMHO there is a very strong argument for web-pushing, mostly related to connection limits in browsers. > > I am strongly opposed to any decision that results in FProxy > converting standards-compliant XHTML that passes the w3c validator > (for example, my flog) into broken XHTML that doesn't. Ideally, > FProxy would never serve HTML or XHTML that would not pass validation, > and I think we should have that as an explicit goal. However, that's > not realistic, given the difficulty of correcting invalid HTML and the > widespread usage of it. As a lesser goal, I think it's entirely > reasonable to say that FProxy should never turn a standards-compliant > page into one that isn't. (It might still change it, as there's > plenty of standards-compliant stuff that's not safe from a Freenet > perspective.) > > Evan Daniel -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20091124/93c61915/attachment.pgp>
[freenet-dev] Web-pushing very important for 0.8.0?
On Tue, Nov 24, 2009 at 2:32 PM, Matthew Toseland wrote: > On Sunday 22 November 2009 17:21:11 Evan Daniel wrote: >> On Sun, Nov 22, 2009 at 11:51 AM, sashee wrote: >> >> > The XHTML support is still broke, and most likely will be in the >> > future, as folks at GWT thinks it is low priority ( >> > http://code.google.com/p/google-web-toolkit/issues/detail?id=710 ). As >> > the XHTML standard is considered low-priority at W3C in favor to >> > HTML5, I think treating XHTML as HTML(as of now) won't break sites, >> > and GWT is happy too. >> >> Pretending XHTML is actually HTML doesn't work, because XHTML doesn't >> support some features GWT uses, like document.write(); instead it has >> alternatives that better separate parsing and scripts. ?Of course, GWT >> simply assumes they are present, rather than using the correct >> alternatives. ?So if you just run the web-pushing code in the XHTML, >> it doesn't work. >> >> If you serve the XHTML with MIME type text/html, then Firefox will do >> what the user wants -- in complete disregard for the XHTML spec. ?The >> XHTML spec is very clear that XHTML 1.1 MUST be served as an XML MIME >> type, and that failure to do so is an error. > > Nonetheless it works with most browsers, right? Yes, though it would be unwise to count on it long term -- if my reading of the spec is correct, a fully compliant browser should produce an error message instead of displaying the page. In other words, it depends upon buggy (though common?) browser behavior to work. (I haven't tested this in anything other than Firefox, btw.) In particular, the document declares itself as XHTML. The text/html MIME type says nothing about what version of HTML to use; presumably the browser makes some assumptions. However, there's no particular guarantee about what HTML versions it will assume, and whether those will match the content filter assumptions. I'd be reluctant to assume that's a good idea without some careful analysis. >> >> I see 4 basic options. ?First, we could wait for GWT to support XHTML. > > Not a good option IMHO, although timing and priorities re merging and > enabling web-pushing are debatable... I assume Google hasn't commented on a time frame for XHTML support? I'm inclined to agree that we shouldn't wait on some unscheduled thing that may or may not happen. > >> ?Second, we could implement a workaround for document.write(); there >> are XHTML-compatible javascript functions available that emulate the >> document.write() functionality, but I don't know whether they are >> sufficiently close to satisfy GWT. > > Running underneath GWT? Sounds messy... Only somewhat. It either works or it doesn't, and all the javascript is automatically generated anyway, right? So we test it a bit, and if it works, great. > >> Third, we could rewrite standards >> compliant XHTML into standards compliant HTML. > > Which would involve...? Honestly, I don't really know. The vast majority of it is the same, provided you use the versions of HTML that close lone tags (ie ""). There are probably some differences in some details, but most of the basic tags are identical. I don't know how complicated those details actually are. The seriously hard things (like handling XML namespaces for stuff like embedded SVG or MathML) aren't supported by the content filter at present anyway. > >> And fourth, we could >> disable web-pushing on XHTML in the short term while waiting on one of >> the first three. > > Practically speaking IMHO there is a very strong argument for web-pushing, > mostly related to connection limits in browsers. I agree, but I am also strongly opposed to converting standards compliant pages into non-compliant pages. IMHO it's better to roll out web pushing support for most pages, and add it later to others, than to delay support for all of them while we solve issues with a few, or to support those few by breaking their standards compliance. This option is the one that gets my vote; get it working and deployed on some pages first, then make it work everywhere. Evan Daniel
[freenet-dev] Web-pushing very important for 0.8.0?
Evan Daniel skrev: > On Tue, Nov 24, 2009 at 2:32 PM, Matthew Toseland > wrote: >>> I see 4 basic options. First, we could wait for GWT to support XHTML. >> Not a good option IMHO, although timing and priorities re merging and >> enabling web-pushing are debatable... > > I assume Google hasn't commented on a time frame for XHTML support? > I'm inclined to agree that we shouldn't wait on some unscheduled thing > that may or may not happen. If http://code.google.com/p/google-web-toolkit/issues/detail?id=710 is the issue you are talking about, then "Not currently feasible." :/ - Zero3
[freenet-dev] Web-pushing very important for 0.8.0?
On Tue, Nov 24, 2009 at 2:59 PM, Christian Funder Sommerlund (Zero3) wrote: > Evan Daniel skrev: >> On Tue, Nov 24, 2009 at 2:32 PM, Matthew Toseland >> wrote: I see 4 basic options. ?First, we could wait for GWT to support XHTML. >>> Not a good option IMHO, although timing and priorities re merging and >>> enabling web-pushing are debatable... >> >> I assume Google hasn't commented on a time frame for XHTML support? >> I'm inclined to agree that we shouldn't wait on some unscheduled thing >> that may or may not happen. > > If http://code.google.com/p/google-web-toolkit/issues/detail?id=710 is > the issue you are talking about, then "Not currently feasible." :/ I really don't understand why the issue is the MIME type rather than the DOCTYPE, but yes, that's the issue. The comments about it being low priority seem to revolve around the fact that the user experience is degraded with XHTML, and therefore you shouldn't be using it anyway. Note the dates, though: that was the case in 2007, and even then it was clear that FF3 would change the situation. We're on FF3.5 now, and there's no reason to avoid XHTML from a rendering standpoint. XHTML can also do complex DOM manipulation through scripts; it just can't do it with document.write(). Evan Daniel
