similar to: HTTP parser C extension should be Rubinius-compatible

Before anything else, let me state this: Of course it''s going to be PAINFULLY slow on MRI. That''s not the point :) I thought I''d try out writing out a Ruby version of the parser for the purposes of Rubinius. For those of you who aren''t aware, Ragel supports a goto-driven FSM on Rubinius by injecting assembly directly, and Rubinus head honcho guy Evan Phoenix

Unicorn is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients. * http://unicorn.bogomips.org/ * mongrel-unicorn at

Hi Hopefully this is the correct mailing list. Sorry if not. I am still fighting to install "shiny" on Solaris OS. For this I need the package 'httpuv' which makes troubles during linking. R version 3.0.1 (2013-05-16) -- "Good Sport" is working well. The compile steps result is below. I have more a general question. The problem is clear: The symbol

On Mon, Jan 21, 2013 at 11:28 AM, Eric Wong <normalperson at yhbt.net> wrote: > Charles Hornberger <charles.hornberger at gmail.com> wrote: >> Hi! >> >> I recently noticed this error message when restarting unicorn after a >> code deployment (and I don''t think I recall having seen it before): >> >> I, [2013-01-18T17:54:21.502554 #59285]

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

Hi all, Some of you are wondering about the future of the project, especially since we''re nearing a 1.0 release. == 1.x - bugfixes and Rack-compatibility synchronization The 1.x series will focus mainly on bug fixes and compatibility with Rack as it evolves. If Rack drops the rewindability requirement of "rack.input", Unicorn will follow ASAP and allow TeeInput to be

Hi: I'm on fedora 19 ( I know. I'm behind : ) and I'm trying to install the httpuv library which depends on Rcpp. When I try to install it with dependencies = TRUE, I get the following error. ( I'm only showing the end of the install messages. Things go okay for a good while ). INSTALLATION MESSAGES #================================================================ make[1]:

Hey everyone, first of all, thank you for the tremendous work and effort on making Rails more awesome every day. I''ve brought up this "issue" on Github last Friday. [1] Steve Klabnik told me to bring the discussion here, as it''s more appropriate. The thing is, there is some amount of logic scattered around Rails (and its tests) that depends upon error/exception

No, that's not it. The error is that you don't have the g++ binary installed. Undo that change and yum install gcc-c++. On Apr 14, 2015 8:31 AM, Mark Leeds <markleeds2 at gmail.com> wrote: > > Hi: I'm on fedora 19 ( I know. I'm behind : ) and I'm trying to install the > httpuv library > which depends on Rcpp. When I try to install it with dependencies =

Just a few observations now that I have completed the upgrade from RSpec-1 to RSpec-2. 1. In my project (2800 examples across about 40 files), MRI 1.9.2-p0 takes roughly 3 times longer to complete the spec run. Runtimes grew from 2.2s (rspec 1.3.0) to 6.1s (2.0.0.rc). 2. Rubinius 1.1.0 runs RSpec-2 without error. 3. JRuby 1.5.1 runs RSpec-2 without error. 4. Both Rubinius and JRuby print a

Right. glibc's amusing stance is that you setenv/putenv are not thread safe, but getenv is. I assume Ruby exposes setenv and therefore simply not calling setenv isn't an option. Would it solve your problems if all getenv() calls happened at cl::ParseCommandLineOptions() time? On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello, > >

Hello, In Rubinius we're seeing an occasional crash inside LLVM that always happens inside getenv(), which is used for example when creating a MCContext (inside lib/MC/MCContext.cpp, it checks getenv("AS_SECURE_LOG_FILE")). The problem is that getenv() and friends aren't thread safe and Rubinius provides a multithreaded system. We can relatively easily get locking setup around

That sounds like a missed multi-threading issue with LLVM. I can't imagine why the user should be forced to serialize creation of MCContext objects. I would suggest filing a bug for this. A simple lock probably wouldn't be too detrimental to performance here, since MCContext objects shouldn't be created too often. On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at

<p dir="ltr">Hmm. If you try to run g++ on the command line, does it exist? If it does, let me know, and I'll try to figure this out when I'm not sitting in an airport later today. :)<br> </p> <div class="gmail_quote">On Apr 14, 2015 8:47 AM, Mark Leeds <markleeds2@gmail.com> wrote:<br type='attribution'><blockquote

Hi Dirkjan, Are you using JIT or MCJIT? Cheers. ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Dirkjan Bussink [d.bussink at gmail.com] Sent: Saturday, March 23, 2013 8:18 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation Hi Andy, One

Hi Andy, One of the issues that I found not intuitive, is that when an ExecutionEngine is deallocated, the memory manager's destructor is also called. This resulted in having to write two objects in my case, one as a per JIT request memory manager and one global JIT memory manager. The per request JIT memory manager gets memory from the global manager, but both ended up implementing

Hi fxruby hackers, new version 1.6.23 is out with the following changes. Unfortunately the fxruby.org homepage is down and I don''t have access to it. Therefore I''ve moved the documentation to http://rubydoc.info/github/larskanis/fxruby/1.6/frames and converted to yard. Have fun! === 1.6.23 / 2012-03-08 * Add YARD documentation support * Use generated Manifest.txt * Support

Fixed the last bug. We were missing a rb_str_modify() in the call function. I''ll fix and release. Regards, Dan

Hello all, I've already bothered people on IRC with this question and it was recommended to ask it here. First of all, some context. In Rubinius (http://rubini.us/, http://github.com/rubinius/rubinius) we use LLVM for our JIT. We create LLVM IR using the C++ API and turn that into machine code using ExecutionEngine::runJITOnFunction. The resulting native code is then installed as the

Hi all, On versions of Ruby prior to 1.9, using update on an ActiveSupport::OrderedHash will not set the keys correctly. This means that it is not possible to iterate over the hash using each or get the array of keys. For example: hash = ActiveSupport::OrderedHash.new hash.update(:name => "Bob") # => #<OrderedHash {:name=>"Bob"}> hash.keys