similar to: Q on cgi_multipart_eol_fix preqequisite for Mongrel on Win2K

News - http://jugad.livejournal.com/2006/07/28/ - about the Pune Ruby User Group''s web site / wiki and blog. Pune is a city in western India near Mumbai. The people behind these also organized a Pune Rails Hackathon - http://punehackathon.pbwiki.com/ - this weekend. Check out the news and the pics ... Vasudev Ram -------------------------------------------------------------- Dancing

Hey so, People are asking about Mongrel Ruby 1.9 compatibility. Isn''t the point of 1.9 for library developers to have time to get ready for 2.0? It''s not like 1.9 is a production release. Evan -- Evan Weaver Cloudburst, LLC

Dear Mongrels, The same questions keep coming up over and over on the list, which is ok, but not really optimal. If we added a wiki to the Mongrel site to handle FAQs, what wiki should it be? Required features would be: * Spam protection * Doesn''t look shitty I would probably spring for Trac (and also migrate the bugtracker) if noone else has opinions, but I''m sure some of

I just found a vulnerability in one of my web apps that was running Mongrel 1.1.2 where I could go to URIs like /.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/.%252e/etc/passwd and it would serve the actual /etc/passwd file. The issue seems to be in lib/mongrel/handlers.rb in the change from 1.0.3 to 1.0.4 req_path = HttpRequest.unescape(path_info) - if @path - req_path =

Hi Zed, I checked in a pure-Ruby URI classifier to Mongrel trunk. Ola''s Java port of the TST had some bug, and I don''t think it''s necessary in the first place. The Ruby classifier is around 25 lines instead of the 400-odd lines for the C extension and the 200-odd for the Java extension. It uses a Regexp which is perhaps shady: @matcher = Regexp.new(routes.map do

Howdy -- I''ve been tracking down mem leaks (oh, the fun...), and I think there is a clue in objects.log. There are a few mentions of this file, but usually Zed saying "look at this file and it will help you". Can anyone clue me in to what the actual columns mean? 18,Float,143952,256821,112869,,, 18,String,39543,41693,2150,24.727076,55.526376,2308.000000

I have been getting this error on the production server after rails was updated to 2.0.2 and moreover this worked perfectly in the development mode. This crash occurs when no one is using the app for an hour or so. This is the error that I get in the logs. (nohup.out file). The production log doesnt show anything unusual. Please help me out guys.

Suppose I have fun.h as: static void fun() { int a =10; } Now I have two files foo.c and goo.c as foo.c : #include "fun.h" void foo() { fun(); } goo.c: #include "fun.h" void goo() { fun(); } I get .bc files for foo.c and foo.bc through clang. Now I run llvm-ld with -disable-opt for foo.bc and goo.bc. In the resulting .bc files, one of the

I seem to have a (recent) problem with mongrel on NetBSD. I''m running a development release of NetBSD (called NetBSD-current 4.99.34). When I start mongrel, it listens on the IPv6 wildcard address, but not on the IPv4 wildcard: => Booting Mongrel (use ''script/server webrick'' to force WEBrick) => Rails application starting on http://0.0.0.0:3000 => Call with

Hello. Some time ago I committed a Rubinius assembly-based HTTP parser generated from Ragel to the Rubinius git repository. Yesterday I made a Mongrel gem which installs and works on Rubinius. This basically involved commenting out anything to do with fastthread or the http11 C extension. If there''s interest in releasing a Rubinius-targeted gem, I can make changes to the Rakefile to

Hello Guys, I''ll like to suggest a small release fix before we start doing big changes: platform fixes. Current we''re setting MSWIN32 (mswin32) as platform for Windows gem, but we should be using Gem::Platform::CURRENT instead (i386-mswin32 as current Ruby windows implementation). Also, the jruby/java platform need to be defined. That change will ease the compatibility path

Thanks for the info regarding DebugLoc field. Another related question that I have is regarding debug info for local variables. With -fast option, ISD::DECLARE nodes are created in DAG for debug info of local variables. I am planning to custom handle these nodes, get the required info from llvm.dbg.variable global address and emit it in ISel. But without -fast option ISD::DECLARE nodes

Hi all, There is a bug with Mongrel on JRuby 1.0.3 that the JRuby guys want fixed before they release it. If it''s ok with people I''d like to fix that, revert (at least for now) the proxy response change, and tag that as 1.1.2 and release it. Anything wrong with this plan? Evan -- Evan Weaver Cloudburst, LLC

I am using llvm-ld to make a library using -link-as-library -disable-opt options. Now I create a test case which invokes a function from this library and link the library in llvm-ld. The compilation unit that library function gets is the one in which the test case is defined and not the one where library function is defined. -------------- next part -------------- An HTML attachment was

I need to generate line number debug information for PIC16 target. PIC16 does not support dwarf format. It supports coff format. So I need to custom handle the STOPPOINT nodes. Without -fast option the STOPPOINT nodes are not created in dag because of the below check in SelectionDAGBuild.cpp if (Fast) DAG.setRoot(DAG.getDbgStopPoint(getRoot(), If I give -fast option then the Fast

Hello Mongrels, Release candidates for Mongrel 1.0.2 and its dependencies are now available. Note that gems are now signed, so please add the Mongrel public certificate via: $ wget http://rubyforge.org/frs/download.php/25325/mongrel-public_cert.pem $ gem cert --add mongrel-public_cert.pem Now you can verify and install the candidates via gem install: $ sudo gem install mongrel

On Apr 7, 2009, at 9:52 PMPDT, vasudev wrote: > Thanks for the info regarding DebugLoc field. Another related > question > that I have is regarding debug info for local variables. With -fast > option, ISD::DECLARE nodes are created in DAG for debug info of local > variables. I am planning to custom handle these nodes, get the > required > info from llvm.dbg.variable

FYI. -- - Brian Gupta http://opensolaris.org/os/project/nycosug/

I''m confused. Wasn''t threading fixed in 1.8.6, negating the need for fastthread? Why is fastthread still a requirement of Mongrel? Just curious. :)

Guys, Just for fun, I tried to see (I know, a silly way to test it) how much overhead we have calling the C functions of the extensions. the benchmark script and the results: http://pastie.caboo.se/128646 The naive C extension: http://pastie.caboo.se/128647 I compared 1.8.6 (VC6 and mingw builds) against a fresh checkout of ruby trunk. What I understand from that is 1.9 is slower than 1.8