1. bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1680 views
I was trying to do something with tasks, and discovered i couldn't in ver 4.0.4 that i could in ver 4.0.b2. Then i discovered other problems. Take a look at the screen shot (i recommend FireFox) of running my modified http.e and my old news3.ex, vs the new http.e in ver 4.0.4 and the new news.e in ver 4.0.4 on:
http://designerthinking.com/images/NEWS.JPG
I chose to search for "Libya" because it was an almost guaranteed hit right now. Imagine my surprise when news.e reported so many sites had no news about it. So the most egregious error is the amount of zeros shown in the new news.ex on the right, vs my news3.ex on the left. The worst showing for the task system itself, which isn't shown in a picture, is the new news.ex seems to serially put the lines on the screen, and then serially fills in the results, while mine is quite a bit more obvious that things are not happening serially or synchronously. And news3.ex opens in a dosbox that can hold the entire display, you must drag the box outline to enlarge it with news.ex.. Oh, and towards the end of the show in news.e, there's flashes of red onscreen, which is bad coding and an error.
So anyhow, there's an error in http protocol in http.e, errors of omission in http.e, and a few errors in news.ex. And i updated the urls in the hardcoding, because the redirects for the old urls weren't being followed (of course, there is no code for that). And my new3.ex window titlebar displays Euphoria and the Eu icon, the news.ex in 4.0.4 shows the dos path to cmd.exe, and i wrote no Eu code to change the titlebar.
useless
2. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1612 views
I chose to search for "Libya" because it was an almost guaranteed hit right now. Imagine my surprise when news.e reported so many sites had no news about it.
So anyhow, there's an error in http protocol in http.e, errors of omission in http.e, and a few errors in news.ex. And i updated the urls in the hardcoding, because the redirects for the old urls weren't being followed (of course, there is no code for that).
eukat
Thanks. This was a very useful post. I've updated news.ex to use updated urls and created a ticket to remind the dev team to implement the code to handle redirects, http://openeuphoria.org/ticket/781.wc
So the most egregious error is the amount of zeros shown in the new news.ex on the right, vs my news3.ex on the left. The worst showing for the task system itself, which isn't shown in a picture, is the new news.ex seems to serially put the lines on the screen, and then serially fills in the results, while mine is quite a bit more obvious that things are not happening serially or synchronously. And news3.ex opens in a dosbox that can hold the entire display, you must drag the box outline to enlarge it with news.ex.. Oh, and towards the end of the show in news.e, there's flashes of red onscreen, which is bad coding and an error.
And my new3.ex window titlebar displays Euphoria and the Eu icon, the news.ex in 4.0.4 shows the dos path to cmd.exe, and i wrote no Eu code to change the titlebar.
I couldn't reproduce these issues on Linux/GNU so I'll leave it to another dev to deal with them.
3. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1606 views
So the most egregious error is the amount of zeros shown in the new news.ex on the right, vs my news3.ex on the left. <snip>
I couldn't reproduce these issues on Linux/GNU so I'll leave it to another dev to deal with them.
Using the 4.0.4 install, if you comment out all the urls except "http://news.yahoo.com" how many hits do you get for "Lybia"?
useless
4. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1620 views
So the most egregious error is the amount of zeros shown in the new news.ex on the right, vs my news3.ex on the left. <snip>
I couldn't reproduce these issues on Linux/GNU so I'll leave it to another dev to deal with them.
Using the 4.0.4 install, if you comment out all the urls except "http://news.yahoo.com" how many hits do you get for "Lybia"?
eukat
Even with the fixes, I get 0.
I've fixed http.e to be able to deal with this, and now I get 18 hits. Another very useful post.
5. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1612 views
So the most egregious error is the amount of zeros shown in the new news.ex on the right, vs my news3.ex on the left. <snip>
I couldn't reproduce these issues on Linux/GNU so I'll leave it to another dev to deal with them.
Using the 4.0.4 install, if you comment out all the urls except "http://news.yahoo.com" how many hits do you get for "Lybia"?
eukat
Even with the fixes, I get 0.
I've fixed http.e to be able to deal with this, and now I get 18 hits. Another very useful post.
I'd like to see your fix, because this bug has been there for years, and i wonder if you fixed it or simply eliminated the check for it.
useless
6. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1623 views
So the most egregious error is the amount of zeros shown in the new news.ex on the right, vs my news3.ex on the left. <snip>
I couldn't reproduce these issues on Linux/GNU so I'll leave it to another dev to deal with them.
Using the 4.0.4 install, if you comment out all the urls except "http://news.yahoo.com" how many hits do you get for "Lybia"?
eukat
Even with the fixes, I get 0.
I've fixed http.e to be able to deal with this, and now I get 18 hits. Another very useful post.
I'd like to see your fix, because this bug has been there for years,
No problem! Please see http://scm.openeuphoria.org/hg/euphoria/file/116c1d8472c4/include/std/net/http.e
and i wonder if you fixed it or simply eliminated the check for it.
eukat
Are you calling me a liar?
7. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1591 views
and i wonder if you fixed it or simply eliminated the check for it.
eukat
Are you calling me a liar?
Nope, but it's interesting to see the devs are just as quick to jump on the drama soapbox as they ever were.
useless
8. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1594 views
and i wonder if you fixed it or simply eliminated the check for it.
eukat
Are you calling me a liar?
Nope, but it's interesting to see the devs are just as quick to jump on the drama soapbox as they ever were.
eukat
No drama, just pointing out that others can sometimes read into your words negative implications that may not have been intended.
9. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1588 views
and i wonder if you fixed it or simply eliminated the check for it.
eukat
Are you calling me a liar?
Nope, but it's interesting to see the devs are just as quick to jump on the drama soapbox as they ever were.
eukat
No drama, just pointing out that others can sometimes read into your words negative implications that may not have been intended.
Ok, then please don't take it the wrong way when i say i know of a properly formed url that still will not download properly with your fix, but technically it's not a webpage, but is a proper legal download.
And for the http.e tasks problem and news.e, when i run news.e, it displays the first url at the top of the dosbox, then it goes to the bottom of the dosbox and dsplays the last url, then it fills in the url above it, then the one above it, until they are all displayed, then it returns to the last url and displays the hits, then the url listed above it, then the url above it, until done. This looks entirely non-asychronous, it looks like normal sequential programming, it doesn't show off tasks completing whenever they do. Fixing this is merely adding two lines. Perhaps you can now do that too, which i did several years ago?
useless
10. Re: bugs found in http.e and news.ex
- Posted by mattlewis (admin) Sep 13, 2012
- 1592 views
Ok, then please don't take it the wrong way when i say i know of a properly formed url that still will not download properly with your fix, but technically it's not a webpage, but is a proper legal download.
So, I'm curious about the right and wrong way to take a report like this. Is it OK to ask for details about the error? Do you already have a solution implemented somewhere?
Passive-aggressive bug reporting like this is not the most efficient way to get things fixed.
And for the http.e tasks problem and news.e, when i run news.e, it displays the first url at the top of the dosbox, then it goes to the bottom of the dosbox and dsplays the last url, then it fills in the url above it, then the one above it, until they are all displayed, then it returns to the last url and displays the hits, then the url listed above it, then the url above it, until done. This looks entirely non-asychronous, it looks like normal sequential programming, it doesn't show off tasks completing whenever they do. Fixing this is merely adding two lines. Perhaps you can now do that too, which i did several years ago?
Again, what are the two lines? I don't think any of us have the changes you made two years ago at our fingertips. Did you ever share them (I really don't know)? These fixes sound very useful for the demo, and I think it would be much better off as you describe it.
Matt
11. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1586 views
i know of a properly formed url that still will not download properly with your fix, but technically it's not a webpage, but is a proper legal download.
I'll have to try it out for myself.
And for the http.e tasks problem and news.e, when i run news.e, it displays the first url at the top of the dosbox, then it goes to the bottom of the dosbox and dsplays the last url, then it fills in the url above it, then the one above it, until they are all displayed, then it returns to the last url and displays the hits, then the url listed above it, then the url above it, until done. This looks entirely non-asychronous, it looks like normal sequential programming, it doesn't show off tasks completing whenever they do. Fixing this is merely adding two lines. Perhaps you can now do that too, which i did several years ago?
eukat
I'll leave this to one of the other devs (preferably Jeremy).
12. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1668 views
Ok, then please don't take it the wrong way when i say i know of a properly formed url that still will not download properly with your fix, but technically it's not a webpage, but is a proper legal download.
So, I'm curious about the right and wrong way to take a report like this. Is it OK to ask for details about the error? Do you already have a solution implemented somewhere?
Passive-aggressive bug reporting like this is not the most efficient way to get things fixed.
I was working on the fix, and no one was working with me, but someone entirely re-wrote http.e on their own, changing all my codebase, invalidating all my fixes, and i gave up working to improve Euphoria. I have a fix in mind, i never coded it, because as far as i could see, no one wanted it, and i already had other ways around it. As for being passive-aggressive, i am still peeved, the condition causing my peevedness hasn't changed.
And for the http.e tasks problem and news.e, when i run news.e, it displays the first url at the top of the dosbox, then it goes to the bottom of the dosbox and dsplays the last url, then it fills in the url above it, then the one above it, until they are all displayed, then it returns to the last url and displays the hits, then the url listed above it, then the url above it, until done. This looks entirely non-asychronous, it looks like normal sequential programming, it doesn't show off tasks completing whenever they do. Fixing this is merely adding two lines. Perhaps you can now do that too, which i did several years ago?
Again, what are the two lines? I don't think any of us have the changes you made two years ago at our fingertips. Did you ever share them (I really don't know)? These fixes sound very useful for the demo, and I think it would be much better off as you describe it.
Matt
In
function execute_request()
, find line
content &= data
, insert this on the line below it:
task_yield()
Somewhere at the top, add
include std/task.e -- for task_yield()
.
Now run news.e again and see the downloads competing independantly of each other. And AGAIN i ask this forum's display script be fixed, i didn't do anything to cause the strike-throughs. The use of "--" as the basic Eu comment-out is still causing this bug in displays??
useless
13. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1593 views
I was working on the fix, and no one was working with me,
You're good at debugging and testing, and coding on your own, but not coding as part of a group. Of course, as pointed out in The Mythical Man-Month, software development is one of the harder things to manage and coordinate, much like a surgical theater.
but someone entirely re-wrote http.e on their own,
This happens. A lot. Both in the commercial closed source world and also the open source communities. Look at the transition from Jabber1 to Jabber2. Closer to home, David Cuny's SWIG plugin for Euphoria no longer works with SWIG because the developers of SWIG changed the guts of it.
changing all my codebase, invalidating all my fixes, and i gave up working to improve Euphoria.
Jeremy's level of concern was such that he said that he didn't have the heart to tell you that http.e had been rewritten.
I have a fix in mind, i never coded it, because as far as i could see, no one wanted it, and i already had other ways around it.
Sounds reasonable. This sort of thing can happen when one responds to a request for information about the bug (let alone a fix) with "ARE YOU JOKING" or "ARE YOU KIDDING ME"...
As for being passive-aggressive, i am still peeved, the condition causing my peevedness hasn't changed.
Yes, clearly. This happened before the http.e re-write (not that it matters).
And AGAIN i ask this forum's display script be fixed, i didn't do anything to cause the strike-throughs. The use of "--" as the basic Eu comment-out is still causing this bug in displays??
eukat
It's WikiCreole. No one else has written an alternative for this forum, but as Derek once pointed out, everyone is welcome to do so.
14. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1588 views
It's WikiCreole. No one else has written an alternative for this forum, but as Derek once pointed out, everyone is welcome to do so.
I don't dare fix it. It's like the work on news.ex and http.e and all the irc.e code i wrote, as Matt just said :
Again, what are the two lines? I don't think any of us have the changes you made two years ago at our fingertips. Did you ever share them (I really don't know)? These fixes sound very useful for the demo, and I think it would be much better off as you describe it.
but the very same code was rejected years ago. It's made me useless, regardless of how many times you edit my sigline and change it to eukat.
useless
15. Re: bugs found in http.e and news.ex
- Posted by mattlewis (admin) Sep 13, 2012
- 1568 views
It's WikiCreole. No one else has written an alternative for this forum, but as Derek once pointed out, everyone is welcome to do so.
I don't dare fix it. It's like the work on news.ex and http.e and all the irc.e code i wrote, as Matt just said :
Again, what are the two lines? I don't think any of us have the changes you made two years ago at our fingertips. Did you ever share them (I really don't know)? These fixes sound very useful for the demo, and I think it would be much better off as you describe it.
but the very same code was rejected years ago. It's made me useless, regardless of how many times you edit my sigline and change it to eukat.
Good lord, but this is tedious (again). If we all threw a tantrum every time some of our code was changed or ignored or improved, nothing would ever get done.
Matt
16. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1582 views
Good lord, but this is tedious (again). If we all threw a tantrum every time some of our code was changed or ignored or improved, nothing would ever get done.
Matt
Did you try the task mods to http.e?
useless
17. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1604 views
It's WikiCreole. No one else has written an alternative for this forum, but as Derek once pointed out, everyone is welcome to do so.
I don't dare fix it. It's like the work on news.ex and http.e and all the irc.e code i wrote, as Matt just said :
Yes, I can see why trying to move away from WikiCreole can be controversial. I'm all for it, but whoever tries to actually do it had better be ready to take some heat...
As an aside, I don't recall an irc.e at all. We had planned on adding one to the stdlib but no one had time to write one and no one ever presented code for one.
Again, what are the two lines? I don't think any of us have the changes you made two years ago at our fingertips. Did you ever share them (I really don't know)? These fixes sound very useful for the demo, and I think it would be much better off as you describe it.
but the very same code was rejected years ago. [/quote]
Strange, as I have no recollection of this (and I should have). I recall other arguments about news.ex and tasks, but not that one.
I guess that I must have missed it...
It's made me useless, regardless of how many times you edit my sigline and change it to eukat.
eukat
As I recall, this occured because CoJaBo rejected your changes that were designed to spoof the referrer in an http request, as some web sites would only serve web pages if the referrer was another page on the same web site, and then went further and deemed the entire process useless. (CoJaBo is not a dev with commit access, never had it, and never had the authority to reject your changes.)
(A change which I supported, and argued should be added to the stdlib.)
18. Re: bugs found in http.e and news.ex
- Posted by mattlewis (admin) Sep 13, 2012
- 1561 views
Good lord, but this is tedious (again). If we all threw a tantrum every time some of our code was changed or ignored or improved, nothing would ever get done.
Matt
Did you try the task mods to http.e?
I have not had a chance to work on anything euphoria related today (though I might in a bit). Ideally, this would be put into a ticket, so that we have a traceable history for this (and for the release notes).
Matt
19. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1574 views
It's WikiCreole. No one else has written an alternative for this forum, but as Derek once pointed out, everyone is welcome to do so.
I don't dare fix it. It's like the work on news.ex and http.e and all the irc.e code i wrote, as Matt just said :
Yes, I can see why trying to move away from WikiCreole can be controversial. I'm all for it, but whoever tries to actually do it had better be ready to take some heat...
I didn't say anything about replacing wikicreole, only fixing the bugs.
As an aside, I don't recall an irc.e at all. We had planned on adding one to the stdlib but no one had time to write one and no one ever presented code for one.
Again, what are the two lines? I don't think any of us have the changes you made two years ago at our fingertips. Did you ever share them (I really don't know)? These fixes sound very useful for the demo, and I think it would be much better off as you describe it.
but the very same code was rejected years ago.
Strange, as I have no recollection of this (and I should have). I recall other arguments about news.ex and tasks, but not that one.
I guess that I must have missed it...
Indeed. Perhaps you remember i had submitted two bodies of code for irc to the user contribs. One code body was an extension to mirc (or any other irc client which could handle the socks interface), the other was an eubot. I think it's possible i had more experience in writing irc code (i had also written a couple irc servers) than anyone else, but i gave up trying to contribute. I could not force you to accept from me, altho you'd have accepted from anyone else.
It's made me useless, regardless of how many times you edit my sigline and change it to eukat.
eukat
As I recall, this occured because CoJaBo rejected your changes that were designed to spoof the referrer in an http request, as some web sites would only serve web pages if the referrer was another page on the same web site, and then went further and deemed the entire process useless. (CoJaBo is not a dev with commit access, never had it, and never had the authority to reject your changes.)
(A change which I supported, and argued should be added to the stdlib.)
The situation of refusing to serve a page on that basis means you cannot add that page to your local cache of page links and simply refresh it, it means you must go to a page you don't want to see, and then manually go to the page you did want to see. This can mean traversing several pages in between.
In my opinion, that issue was independant of the content_length issue and the tasks issue.
So did *you* test the tasks mod to http.e yet?
useless
20. Re: bugs found in http.e and news.ex
- Posted by mattlewis (admin) Sep 13, 2012
- 1570 views
Good lord, but this is tedious (again). If we all threw a tantrum every time some of our code was changed or ignored or improved, nothing would ever get done.
Matt
Did you try the task mods to http.e?
I have not had a chance to work on anything euphoria related today (though I might in a bit). Ideally, this would be put into a ticket, so that we have a traceable history for this (and for the release notes).
That works very well. I entered ticket:782 for this.
Matt
21. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1548 views
I didn't say anything about replacing wikicreole, only fixing the bugs.
Using the dashes for strike-through is a requirement of wikicreole. We can't drop it without creating some new standard (even if the result is just wikicreole with a different strike-through modifier).
Indeed. Perhaps you remember i had submitted two bodies of code for irc to the user contribs. One code body was an extension to mirc (or any other irc client which could handle the socks interface),
I don't remember the submission, but I do recall something like this being mentioned. While it's a worthwhile contribution, I'm not sure it is good enough to become std/net/irc.e because of the dependency on an external irc client.
the other was an eubot.
You claimed it was just a bot shell. This one, I recall that you took the code down so it was no longer open source or available to the community.
I think it's possible i had more experience in writing irc code (i had also written a couple irc servers) than anyone else, but i gave up trying to contribute.
Agreed.
I could not force you to accept from me, altho you'd have accepted from anyone else.
I disagree. If you had presented code to the dev team, I would have accepted it. You never presented a std/net/irc.e, and went as far as to take down code that could have been adapted for it.
It's made me useless, regardless of how many times you edit my sigline and change it to eukat.
eukat
As I recall, this occured because CoJaBo rejected your changes that were designed to spoof the referrer in an http request, as some web sites would only serve web pages if the referrer was another page on the same web site, and then went further and deemed the entire process useless. (CoJaBo is not a dev with commit access, never had it, and never had the authority to reject your changes.)
(A change which I supported, and argued should be added to the stdlib.)
The situation of refusing to serve a page on that basis means you cannot add that page to your local cache of page links and simply refresh it, it means you must go to a page you don't want to see, and then manually go to the page you did want to see. This can mean traversing several pages in between.
This is true.
In my opinion, that issue was independant of the content_length issue and the tasks issue.
Also true. Back to the point, those issues were not the original reason for your pseudonym change.
So did *you* test the tasks mod to http.e yet?
eukat
Matt beat me to it.
22. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1549 views
the other was an eubot.
You claimed it was just a bot shell. This one, I recall that you took the code down so it was no longer open source or available to the community.
It was a bot shell in the way it didn't write your spoken wishes into code. It was like mirc with no gui, it was like any other bot you would download and then add script packages to. It interfaced your code to irc without you needing to know anything about irc protocols. It responded correctly to the over 1000 status codes sent by the irc server. If you added "msg #euphoria blah blah", then it said "blah blah" in #euphoria.
I took it down for two reasons: 1) you downloaded it and butchered it and then announced it didn't work, and 2) no one else wanted it anyhow.
useless
23. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1537 views
the other was an eubot.
You claimed it was just a bot shell. This one, I recall that you took the code down so it was no longer open source or available to the community.
It was a bot shell in the way it didn't write your spoken wishes into code.
This doesn't quite fit in the context of my recollection: you claimed your eubot had already implement certain features (I don't recall what exactly, but along the likes of having a chatbot or searching the archives for keywords and the like), and I said that this wasn't true because the one I had didn't have code for any of this.
I believe your reply was that this eubot was never released, and what I had was just the shell of it.
It was like mirc with no gui, it was like any other bot you would download and then add script packages to.
The eubot I saw had no scripting interface. It was fairly straightforward to add Eu code in key locations in obviously named files (like on_msg.e to handle messages from users) to do what you wanted, though.
It interfaced your code to irc without you needing to know anything about irc protocols. It responded correctly to the over 1000 status codes sent by the irc server. If you added "msg #euphoria blah blah", then it said "blah blah" in #euphoria.
Agreed. It was good at this.
I took it down for two reasons: 1) you downloaded it and butchered it and then announced it didn't work,
I admit that I made a mistake here. The way I attempted to inform you about the bug I had discovered, intended to be jovial, instead offended you and may even have prompted you to pull the code offline.
I was sorry to see it go.
I may have also mentioned other comments that were said about your code (scooby disapproved of your embedding raw control codes like ^A in the source, while robsz1 disliked the mirc-like way you formatted some of your control blocks), but I could have done it in a better way.
That said, I told you all this in a fairly private manner, not through some public announcement like the news section of a forum.
and 2) no one else wanted it anyhow.
eukat
I must admit that there is some truth to this. A decade back, I tried to get other Euphorians on IRC to adopt your eubot as a framework for making IRC bots, but no one else was interested.
24. Re: bugs found in http.e and news.ex
- Posted by CoJaBo2 Sep 13, 2012
- 1551 views
I didn't say anything about replacing wikicreole, only fixing the bugs.
Using the dashes for strike-through is a requirement of wikicreole. We can't drop it without creating some new standard (even if the result is just wikicreole with a different strike-through modifier).
I do recall seeing cases where Creole markup was being parsed inside eucode tags, which would be a bug. I don't know if this was fixed or even if it was the same issue you were talking about.
As I recall, this occured because CoJaBo rejected your changes that were designed to spoof the referrer in an http request, as some web sites would only serve web pages if the referrer was another page on the same web site, and then went further and deemed the entire process useless. (CoJaBo is not a dev with commit access, never had it, and never had the authority to reject your changes.)
(A change which I supported, and argued should be added to the stdlib.)
The situation of refusing to serve a page on that basis means you cannot add that page to your local cache of page links and simply refresh it, it means you must go to a page you don't want to see, and then manually go to the page you did want to see. This can mean traversing several pages in between.
I think my part in this has been taken rather out of context.
The issue, in summary, was this:
The "original" http.e was being used on a site that used the Referer header to block automated (bot) access to its content. As such, it included code to bypass these restrictions by sending a fake Referer header.
When it was to be incorporated into Eu, I argued (strongly) that it would be extremely inappropriate to include this spoofing code as part of a language's standard library.
At some point, this code was removed, and useless_ (?) argued it was a "bug" that a bot that had been written using the old http.e would no longer work on a site that had anti-bot measures when used with the new http.e.
I did not "reject" that spoofing code, nor did I remove it; I argued against it from the standpoint of a web developer. And, while the code is arguably "useful" to the user of the library, it is quite detrimental to the developers of those sites, and detrimental to the reputation of Euphoria as a whole.
Note that this does not preclude the user of http.e from adding spoofing code to the application itself. It is but one line of code to manually set the Referer header to whatever your heart desires.
In my opinion, that issue was independant of the content_length issue and the tasks issue.
What is the "content_length issue", btw?
25. Re: bugs found in http.e and news.ex
- Posted by mattlewis (admin) Sep 13, 2012
- 1537 views
I do recall seeing cases where Creole markup was being parsed inside eucode tags, which would be a bug. I don't know if this was fixed or even if it was the same issue you were talking about.
I don't think this is a problem now, although an opening <eucode> tag needs be the first thing on its line to start a eucode section.
Matt
26. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1555 views
I do recall seeing cases where Creole markup was being parsed inside eucode tags, which would be a bug. I don't know if this was fixed or even if it was the same issue you were talking about.
I don't think this is a problem now, although an opening <eucode> tag needs be the first thing on its line to start a eucode section.
Matt
Ah, then fix that.
useless
27. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1542 views
In my opinion, that issue was independant of the content_length issue and the tasks issue.
What is the "content_length issue", btw?
Some sites do not give a content_length in the http header (hence when news.ex used http.e, yahoo never had a hit on *anything*), some give bad values. At least one uses 31-bit values which roll over to negative values and are wrong from then on (wikimedia, but others too).
useless
28. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1558 views
I took it down for two reasons: 1) you downloaded it and butchered it and then announced it didn't work,
I admit that I made a mistake here. The way I attempted to inform you about the bug I had discovered, intended to be jovial, instead offended you and may even have prompted you to pull the code offline.
I was sorry to see it go.
I may have also mentioned other comments that were said about your code (scooby disapproved of your embedding raw control codes like ^A in the source, while robsz1 disliked the mirc-like way you formatted some of your control blocks), but I could have done it in a better way.
That said, I told you all this in a fairly private manner, not through some public announcement like the news section of a forum.
Check your irc freenode #euphoria logs at 8:00am and 12:49pm (afternoon, 11 minutes til 1pm) on Friday 05/23/08. You went after me in a public channel, with people there. In addition, the relay bot to sorcerynet rebroadcast it there.
Was the bug what you were reporting here?
[07:57] <iamscared> the overhead of the table was so big that i got rid of most of it :) [07:57] <katsmeow-afk> and you see it has sock as a field, and keeps all the network stuff separate from other networks [07:57] <katsmeow-afk> ohm duh, no wonder it's broke then [07:57] <iamscared> yep [07:58] <iamscared> this one is fully mineAnd from what i recall, you also simply removed anything that smelled like mirc or that you didn't understand, and you accused me of copying mirc with a source code generator. In a public open channel.
useless
29. Re: bugs found in http.e and news.ex
- Posted by CoJaBo2 Sep 13, 2012
- 1546 views
Some sites do not give a content_length in the http header (hence when news.ex used http.e, yahoo never had a hit on *anything*), some give bad values.
In HTTP/1.1, Content-Length is omitted in some cases. At a minimum, the Transfer-Encoding header (and its Chunked encoding) must be supported to fix this issue. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
(Note: Technically this is could be considered a server bug- Content-Length is always mandatory in HTTP/1.0, so servers should not be sending HTTP/1.1 replies to HTTP/1.0 clients, as they will not be compatible; nonetheless, several major sites [Wikipedia] sometimes do this. Also, servers should not be sending Content-Length along with Transfer-Encoding, yet some do; in these cases, the Content-Length is bogus, as the length computed from the Transfer-Encoding supercedes it).
Ideally, http.e should be fully HTTP/1.1 compliant.
At least one uses 31-bit values which roll over to negative values and are wrong from then on (wikimedia, but others too).
I suspect you are running into the above isue, rather than rollover.
30. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1686 views
Some sites do not give a content_length in the http header (hence when news.ex used http.e, yahoo never had a hit on *anything*), some give bad values.
In HTTP/1.1, Content-Length is omitted in some cases. At a minimum, the Transfer-Encoding header (and its Chunked encoding) must be supported to fix this issue. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
(Note: Technically this is could be considered a server bug- Content-Length is always mandatory in HTTP/1.0, so servers should not be sending HTTP/1.1 replies to HTTP/1.0 clients, as they will not be compatible; nonetheless, several major sites [Wikipedia] sometimes do this. Also, servers should not be sending Content-Length along with Transfer-Encoding, yet some do; in these cases, the Content-Length is bogus, as the length computed from the Transfer-Encoding supercedes it).
Ideally, http.e should be fully HTTP/1.1 compliant.
I disagree with you yet again, i say ideally http.e should work.
At least one uses 31-bit values which roll over to negative values and are wrong from then on (wikimedia, but others too).
I suspect you are running into the above isue, rather than rollover.
Really?, so the -216blahblah values i see should be treated how? And then they decrease to zero and go positive and keep increasing, and then go negative again, which drug should i take to keep believing that BS?
useless
31. Re: bugs found in http.e and news.ex
- Posted by mattlewis (admin) Sep 13, 2012
- 1568 views
Some sites do not give a content_length in the http header (hence when news.ex used http.e, yahoo never had a hit on *anything*), some give bad values.
In HTTP/1.1, Content-Length is omitted in some cases. At a minimum, the Transfer-Encoding header (and its Chunked encoding) must be supported to fix this issue. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
(Note: Technically this is could be considered a server bug- Content-Length is always mandatory in HTTP/1.0, so servers should not be sending HTTP/1.1 replies to HTTP/1.0 clients, as they will not be compatible; nonetheless, several major sites [Wikipedia] sometimes do this. Also, servers should not be sending Content-Length along with Transfer-Encoding, yet some do; in these cases, the Content-Length is bogus, as the length computed from the Transfer-Encoding supercedes it).
Ideally, http.e should be fully HTTP/1.1 compliant.
I disagree with you yet again, i say ideally http.e should work.
At least one uses 31-bit values which roll over to negative values and are wrong from then on (wikimedia, but others too).
I suspect you are running into the above isue, rather than rollover.
Really?, so the -216blahblah values i see should be treated how? And then they decrease to zero and go positive and keep increasing, and then go negative again, which drug should i take to keep believing that BS?
Well, you should enter this bug in a ticket. Frankly, I have no idea what you're saying here, or how we would go about fixing it. But entering a bug is the first step to getting http.e fixed (regardless of what's happened in the past). If you have an idea about how to fix, please put that in the ticket, too.
Of course, others may disagree, with either your diagnosis or your remedy. But an actual bug report seems like a good next step.
Matt
32. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1533 views
You went after me in a public channel, with people there.
Oh. Hmm, I thought it was still a secret channel at the time (mode +s), but I might be mistaken. It wasn't publicly logged at the time, though.
I suppose I feel that "went after" is a bit too strong, as the dialog was similar to (for example) what I say to Derek on the dev list, or the conversations and arguments that I've had with CoJaBo on IRC. This is a matter of perspective though, and my foolish attempt to lighten the mode certainly did not help.
In addition, the relay bot to sorcerynet rebroadcast it there.
My recollection was that the channel over there was empty except for a relay bot and possibly a few other bots.
and you accused me of copying mirc with a source code generator. In a public open channel.
I said it seems like the code style was so much like mirc code that it looked as if it was translated from mirc source. (If it was in fact automatically translated, in the way that David Cuny's Eu2Java or Peu's C translator did this, then this is actually a good thing. But as a preferred coding style? Who tries to write Ruby code so it looks like Perl?)
For clarity, here is what I said back then:
(09:22:27) iamscared: the version of eubot i had didnt do much at all, it just connected and sat there responding to ping replies and stuff... but i was talking about the code style, which suggested it was code ported (almost auto translated) from mirc
Actually, robsz1 pointed this out to me originally, years before this. He didn't like it, but I thought it was pretty at the time.
Check your irc freenode #euphoria logs at 8:00am and 12:49pm (afternoon, 11 minutes til 1pm) on Friday 05/23/08.
Was the bug what you were reporting here?
[07:57] <iamscared> the overhead of the table was so big that i got rid of most of it :) [07:57] <katsmeow-afk> and you see it has sock as a field, and keeps all the network stuff separate from other networks [07:57] <katsmeow-afk> ohm duh, no wonder it's broke then [07:57] <iamscared> yep [07:58] <iamscared> this one is fully mine
No, I had a different one in mind. Like I said at the time, that one was fully mine.
I think I was confused about that bug because you had a comment under the one mentioning support for multiple servers stating that you broke "it" on June 10, 2001 in ircclient.
The one I had in mind was regarding the for loop over newmodes in h_on_mode() in hidden.e that caused it to infinitely loop for unknown or unrecognized modes.
And from what i recall, you also simply removed anything that smelled like mirc or that you didn't understand,
eukat
I removed the mirc emulation because I didn't need it... I was forced to rewrite parts for other reasons (e.g. I couldn't connect eubot to freenode, even though it had no problems with sorcery, and it took me a while to get it to work).
33. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1551 views
Some sites do not give a content_length in the http header (hence when news.ex used http.e, yahoo never had a hit on *anything*), some give bad values.
In HTTP/1.1, Content-Length is omitted in some cases. At a minimum, the Transfer-Encoding header (and its Chunked encoding) must be supported to fix this issue. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
(Note: Technically this is could be considered a server bug- Content-Length is always mandatory in HTTP/1.0, so servers should not be sending HTTP/1.1 replies to HTTP/1.0 clients, as they will not be compatible; nonetheless, several major sites [Wikipedia] sometimes do this. Also, servers should not be sending Content-Length along with Transfer-Encoding, yet some do; in these cases, the Content-Length is bogus, as the length computed from the Transfer-Encoding supercedes it).
Ideally, http.e should be fully HTTP/1.1 compliant.
I disagree with you yet again, i say ideally http.e should work.
If http.e was fully HTTP/1.1 compliant, then in these cases it would ignore the bad Content-Length header and use the other headers that provide correct information instead.
So, if http was fully HTTP/1.1 compliant ... then it would work. Best of both worlds. Or do you have a scenario where a fully HTTP/1.1 compliant version would also break?
At least one uses 31-bit values which roll over to negative values and are wrong from then on (wikimedia, but others too).
I suspect you are running into the above isue, rather than rollover.
Really?,
Sounds plausible to me.
so the -216blahblah values i see should be treated how?
By ignoring them in favor of the Transfer-Encoding and Chunking headers, as HTTP/1.1 requires.
And then they decrease to zero and go positive and keep increasing, and then go negative again, which drug should i take to keep believing that BS?
eukat
I think that this statement speaks for itself.
34. Re: bugs found in http.e and news.ex
- Posted by jimcbrown (admin) Sep 13, 2012
- 1519 views
Well, you should enter this bug in a ticket. Frankly, I have no idea what you're saying here, or how we would go about fixing it. But entering a bug is the first step to getting http.e fixed (regardless of what's happened in the past). If you have an idea about how to fix, please put that in the ticket, too.
Of course, others may disagree, with either your diagnosis or your remedy. But an actual bug report seems like a good next step.
Matt
I agree. I feel that eukat and CoJaBo understand the problem and fix better than I do, so I'd rather have one of them write the ticket, otherwise I would have filed one for this by myself already.
35. Re: bugs found in http.e and news.ex
- Posted by DerekParnell (admin) Sep 13, 2012
- 1525 views
I do recall seeing cases where Creole markup was being parsed inside eucode tags, which would be a bug. I don't know if this was fixed or even if it was the same issue you were talking about.
I don't think this is a problem now, although an opening <eucode> tag needs be the first thing on its line to start a eucode section.
Matt
Ah, then fix that.
Fix what exactly?
Currently the definition of a wiki block of Euphoria code is text that begins with a line that starts (excluding leading whitespace) with the string "<eucode>" (case insensitive BTW) and ends with the first occurrence of the string "</eucode>" (case sensitive), which can occur anywhere in a line. Inside such a block, the "--" is not interpreted as a wiki markup token for strikethrough.
If one wants to use a double dash in normal wiki text, then prepend a single tilde "~" to the double dash ... eg. "~--" will display as "--".
If anything needs to be fixed, we should be able to have the text "</eucode>" inside a Euphoria code block; currently this is impossible.
36. Re: bugs found in http.e and news.ex
- Posted by useless_ Sep 13, 2012
- 1515 views
I do recall seeing cases where Creole markup was being parsed inside eucode tags, which would be a bug. I don't know if this was fixed or even if it was the same issue you were talking about.
I don't think this is a problem now, although an opening <eucode> tag needs be the first thing on its line to start a eucode section.
Matt
Ah, then fix that.
Fix what exactly?
Currently the definition of a wiki block of Euphoria code is text that begins with a line that starts (excluding leading whitespace) with the string "<eucode>" (case insensitive BTW) and ends with the first occurrence of the string "</eucode>" (case sensitive), which can occur anywhere in a line. Inside such a block, the "--" is not interpreted as a wiki markup token for strikethrough.
If one wants to use a double dash in normal wiki text, then prepend a single tilde "~" to the double dash ... eg. "~--" will display as "--".
If anything needs to be fixed, we should be able to have the text "</eucode>" inside a Euphoria code block; currently this is impossible.
If i could vote for it, i'd vote to have the tags active anywhere. It would sure beat having lessons periodically about the problems with creole.
useless,maybe
