On Sun, Aug 15, 2010 at 6:59 AM, sawyer x <xsawyerx@gmail.com> wrote:
On Sun, Aug 15, 2010 at 2:47 PM, P Kishor <punk.kish@gmail.com> wrote:
No need to contact anyone else. I am firsthand experiencing the above bug with Apache2 and Dancer 1.1805. Basically, if trying to deploy with Apache2 under regular CGI or FastCGI, <code>get '/'</code> simply doesn't work. I keep on getting 404. I can break my head against every possible documentation, but I get 404. Change <code>get '/'</code> to <code>get r('.*')</code> and it starts working.
Do we already have a ticket on Github issues with this? If not, would you mind opening one? It will be easier for us to track it and fix it. Thank you.
With regards to deployment, that is only half of the story, albeit the sordid half. The other half is that Dancer doesn't deploy out of the box. Out of the box, the dispatch.cgi script is under public, so the only way to reach that script is to use the uri http://myapp/public/dispatch.cgi. Therefore, dispatch.cgi needs to be moved one level above public. However, now, all the paths to the css are screwed. So, the paths to the css have to be adjusted from '/css/style.css' to /public/css/style.css'
As it seems, this shouldn't be difficult to fix. If you could please open an issue for this as well, it will solved more quickly.
One question -- did anyone actually do the Apache2 CGI deployment before writing those docs, because, as is, those docs don't work at all. I don't know what is better -- not have any docs at all or to have misleading docs.
You should take into account that some people find it hard to interact with people who behave in an offending manner.
Emails have a great potential for being misunderstood, and I think this is one of those classic cases. If I were being offending, or wanted to disrespect anyone's effort, I would have given up on Dancer. I have consistently, in all my emails, maintained that Dancer is a breath of fresh air in the world of web development with Perl. That notwithstanding, my question was simple, did anyone actually do that deployment before writing the docs? Because, as the docs are, and given the current version of Dancer, that deployment would simply not work. I am not talking about just a code bug here. I develop and evangelize open source software, so I know all aspects of how difficult it is to develop software, and that no software is without bugs. That is why we have versions. I am also aware of open source being a non-paid, voluntary effort. I am not expecting anyone to jump to my bidding (although, sometimes, frustration at the same problem may tend to make one sound like that). I am commenting about documentation. If I say in my documentation that something will do "b" when "a", I have basis to say that. Now, what happens with bad documentation is worse than there being no documentation. Most of the time we developers accuse users of not reading the documentation, since most users don't rtfm. However, in this case, the user is diligently reading the docs, and following the instructions to the t. Yet, the stuff is not working. Everyone is bewildered. After a while, the user is either going to start sounding like (and believing that) s/he is wanting others to jump to his bidding, or the user is going to get frustrated and say, to hell with this, life is too short to waste on something that doesn't work as documented.
You're basically disrespecting the effort people have done to create these docs because one documented feature did not work for you. This means the doc might need to be fixed (perhaps a line change) or some of the code has to be fixed. This happens in projects.
Never happened in any project that I have worked with. I can fully expect bugs in the code. But, I can't expect bugs in the instructions on the box. If the box says "Do this and this will happen" then I expect that someone has actually done that. That somewhere in this world, there is a configuration under which that documentation is true. If that is the case, then I can go back to confirming what my configuration is, and then I can say that look, under such and such versions, the documentation doesn't hold true. However, it seems that the particular documentation bug is based on conjecture. I mean, how can http://myapp/dispatch.cgi work if, in the filespace (term used by Apache), I have myapp/public/dispatch.cgi?
I've just recently experienced such documentation discrepancies with App::perlbrew.
The way to get such things fixed is to simply say "Hi, I'm sorry but apparently either the doc is not correct or the code has a bug. Could you please look into this?" instead of giving the impression that all their effort to write the docs (and project) were in vain - which is how you put it.
You misunderstand me, and to the extent that I created that misunderstanding, I apologize. But, look, all my carping will hopefully result in better documentation that is more in sync with reality, and hopefully make Dancer actually say what Dancer does. That would be a good thing, no? :-) I have probably written the most number of emails on this list. I have "bugged" folks on IRC. I have simply not gotten to the bottom of my problem with Dancer now for weeks. It has come to the point that I feel embarrassed asking any question about Dancer now. I always think twice -- am I making a pain of myself? Are folks ignoring me? Am I the only one experiencing this/these problem(s)? Either way, the situation is bad -- the developers and think a member of the community is discourteous and disrespectful, or a member of the community thinks the developers are ignoring him. Either way, that open source project doesn't have a very viable future. The fact is, I want this project to succeed. It is a wonderful change from the usual, confusing swill out there in the Perl web world. But, it is patchy. It needs to be fixed.
This is open source, not a company. We don't get money (at all!) and therefor no one _really_ has to listen to what people say. We do because we care. Telling us that "the docs don't work at all" and that it is not necessarily better than "not having any docs at all" will probably land you in a position of not being often listened to - even if you are reporting an actual bug.
Please, be courteous and respectful. If you find a bug, help us by reporting and try *not* to include any bad-mouthing of people's hard work. Trust me, you'll get more attention and the stuff you care about will get fixed much sooner.
I take your point, but I don't believe it applies here. You have spent more words correcting my possibly wrong attitude than correcting my possible coding mistakes. As I noted above -- proving that the documentation is wrong, and asking if anyone actually tested that before writing it, is not bad-mouting anyone's hard work. I have deep appreciation for the developers behind Dancer. I want this to succeed, to become rock solid, super fast, and dead easy to create and deploy with. That is why I am sticking to it. If my reports and questions lead to better docs and better code, that would be good for everyone. It would be a shame, at least for me, if I come to the conclusion that it is not worth the trouble. Possibly Dancer will thrive without me. But, it would have missed a tree for the forest. Look, all that said, I again apologize if my repeated emails for help with deployment have seemed that they are disrespecting anyone's hard work. That was not the intent.
Thank you.
-- Puneet Kishor