From normalperson at yhbt.net  Fri Apr  3 21:08:26 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 3 Apr 2009 18:08:26 -0700
Subject: [Mongrel-development] Mongrel 1.x handlers for Rack/Mongrel 2
Message-ID: <20090404010826.GA8746@dcvr.yhbt.net>

Evan Weaver <evan at cloudbur.st> wrote:
> - Move to a Rack handler interface, and include backwards-compatible
> versions of the current ones

ref: <b6f68fc60811171232s46ba20ebh19ff2d499494622d at mail.gmail.com>

Hey all,

Has there been any updates on the backwards-compatibility front for
existing Mongrel handlers?

The Mongrel 1.x handlers that I occasionally have to deal with should be
easy to port to Rack, so I may just do that instead... (or keep using
Mongrel 1.x)

The handlers that use request progress notification won't be portable to
Rack at all.  Doing it in a webserver-agnostic way seems like too much
effort, so maybe we could just keep that support in Mongrel 2 (and
Unicorn)...

-- 
Eric Wong

From normalperson at yhbt.net  Wed Apr  8 22:09:25 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 8 Apr 2009 19:09:25 -0700
Subject: [Mongrel-development] cornifying Mongrel?
Message-ID: <20090409020925.GA26434@dcvr.yhbt.net>

Hi all,

Unicorn development has has been pretty boring lately, so maybe it's
time to merge some of the improvements back into Mongrel2.  I think most
of the Unicorn changes can be merged into Mongrel with very few
modifications.  I'll give a highish-level rundown of what I changed from
Mongrel (since 9f9a9d488ed32a2891dc3dd7d50a17a16357042d)

I'll start backwards with HttpResponse since that's the least
intrusive.


== HttpResponse

I removed the old Mongrel response interface entirely and just made it
work directly with the Rack response tuplet.  The most important change
to me was to stop slurping the entire body into one StringIO.

I've also added support for Rack-style multi-value headers to
allow duplicate headers joined by "\n" in the value.  I consider
suppressing duplicates for certain headers to be the job of Rack
or the framework, so Unicorn itself does no duplicate suppression.

Additionally, Content-Length: calculation is gone as Rack or the
framework will do that (or send "Transfer-Encoding: chunked").

Generally, these changes avoid doing work Rack has already done for us.


== HttpParser

I've simplified interface for HttpRequest a bit.  It relies solely on
exceptions for errors so callers won't have to explicitly check for
them.  There's no longer a need to do nread accounting in the caller
since it's always been done internally.  There are also some small
bugfixes for some Rack-isms in there.


== HttpRequest

Some of these are tied to the HttpParser changes.  The HttpParser
simplification allows me to avoid some function calls for some small
performance boosts.

I've also renamed "HTTP_BODY" in the HttpParser to :http_body to avoid
conflicting with a theoretical "Body:" HTTP header.


== Listener

Unicorn doesn't override TCPListener.new. It supports multiple listeners
within the same process and also allows fine-grained control of backlog,
sndbuf, rcvbuf on a per-listener basis.  Lowering listen backlog size
actually has better potential for failover, but it's unlikely I'll get
to test that soon on a real production cluster.  Of course, it can
bind to UNIX domain sockets as well as TCP ones.

I'll probably document the listener inheritance between upgrades feature
separately since I don't think I've ever seen it documented (or used
outside of nginx; let me know if it has).  I'm not sure if Mongrel can
support it portably outside of POSIX, probably not...


== Misc

The global log-reopening facility in Unicorn will be less clean in the
presence of threads.  Unicorn waits until the current request is
completely finished before reopening the logs; this allows requests that
generate multi-line logs to keep all logs within the same file for
easier processing.  Nevertheless, Unicorn::Util.reopen_logs would
be preferable over logrotate doing copytruncate.


== General

Throughout Unicorn, I use sysread/syswrite instead of the more common
read/write functions.  I personally find luserspace I/O-buffering
distasteful, especially on sockets.  These calls should be safely
switchable to use read/write for Mongrel since it has threads
and slow clients to deal with (neither are a concern for Unicorn).

The process management is generally boring and generic (besides reexec).
It can probably be used in a future mongrel_cluster and allowed shared
listeners, too.  With preload_app, it works out-of-the box for nearly
everything (Sinatra 0.3.x with code reloading enabled being an
exception).

Tests can run in parallel using GNU make (my favorite language for
parallel programming).  This was one of the first things I did to the
original Mongrel code (though I tweaked it along the way).

More details for all of these changes are of course in the commit
messages and comments, even.  Unicorn is probably the most heavily
commented/documented code I've ever written, too.

Anyways, let me know if you guys want more details on certain
changes or help merging certain changes into Mongrel.


== Disclaimer

Keep in mind that Unicorn still has no real Ruby applications running on
it (fork+exec on cgit doesn't count).  The Sinatra projects I initially
tested this on both got canceled, even, so Unicorn could even be bad
luck :)

Since Unicorn is/was a new project, I took many more liberties and risks
with it than I would with an established project like Mongrel, so keep
that in mind, too :)

I also don't think I'll be allowed much more $DAYJOB time to work on it.
Most of our projects already run well enough with the nasty
qrp+num_processors=1 hack I did last year, and these projects have been
in code/feature freeze for some time, so I don't think I'll ever be
allowed to deploy Unicorn with them... Oh well.

-- 
Eric Wong

From evan at cloudbur.st  Thu Apr  9 17:34:15 2009
From: evan at cloudbur.st (Evan Weaver)
Date: Thu, 9 Apr 2009 17:34:15 -0400
Subject: [Mongrel-development] cornifying Mongrel?
In-Reply-To: <20090409020925.GA26434@dcvr.yhbt.net>
References: <20090409020925.GA26434@dcvr.yhbt.net>
Message-ID: <b6f68fc60904091434m2add2298j3e3b8746ecc71b1e@mail.gmail.com>

Ah, awesome.

Next weekend is my first free weekend in a month and I will attempt to
work on it then.

Evan

On Wed, Apr 8, 2009 at 10:09 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Hi all,
>
> Unicorn development has has been pretty boring lately, so maybe it's
> time to merge some of the improvements back into Mongrel2. ?I think most
> of the Unicorn changes can be merged into Mongrel with very few
> modifications. ?I'll give a highish-level rundown of what I changed from
> Mongrel (since 9f9a9d488ed32a2891dc3dd7d50a17a16357042d)
>
> I'll start backwards with HttpResponse since that's the least
> intrusive.
>
>
> == HttpResponse
>
> I removed the old Mongrel response interface entirely and just made it
> work directly with the Rack response tuplet. ?The most important change
> to me was to stop slurping the entire body into one StringIO.
>
> I've also added support for Rack-style multi-value headers to
> allow duplicate headers joined by "\n" in the value. ?I consider
> suppressing duplicates for certain headers to be the job of Rack
> or the framework, so Unicorn itself does no duplicate suppression.
>
> Additionally, Content-Length: calculation is gone as Rack or the
> framework will do that (or send "Transfer-Encoding: chunked").
>
> Generally, these changes avoid doing work Rack has already done for us.
>
>
> == HttpParser
>
> I've simplified interface for HttpRequest a bit. ?It relies solely on
> exceptions for errors so callers won't have to explicitly check for
> them. ?There's no longer a need to do nread accounting in the caller
> since it's always been done internally. ?There are also some small
> bugfixes for some Rack-isms in there.
>
>
> == HttpRequest
>
> Some of these are tied to the HttpParser changes. ?The HttpParser
> simplification allows me to avoid some function calls for some small
> performance boosts.
>
> I've also renamed "HTTP_BODY" in the HttpParser to :http_body to avoid
> conflicting with a theoretical "Body:" HTTP header.
>
>
> == Listener
>
> Unicorn doesn't override TCPListener.new. It supports multiple listeners
> within the same process and also allows fine-grained control of backlog,
> sndbuf, rcvbuf on a per-listener basis. ?Lowering listen backlog size
> actually has better potential for failover, but it's unlikely I'll get
> to test that soon on a real production cluster. ?Of course, it can
> bind to UNIX domain sockets as well as TCP ones.
>
> I'll probably document the listener inheritance between upgrades feature
> separately since I don't think I've ever seen it documented (or used
> outside of nginx; let me know if it has). ?I'm not sure if Mongrel can
> support it portably outside of POSIX, probably not...
>
>
> == Misc
>
> The global log-reopening facility in Unicorn will be less clean in the
> presence of threads. ?Unicorn waits until the current request is
> completely finished before reopening the logs; this allows requests that
> generate multi-line logs to keep all logs within the same file for
> easier processing. ?Nevertheless, Unicorn::Util.reopen_logs would
> be preferable over logrotate doing copytruncate.
>
>
> == General
>
> Throughout Unicorn, I use sysread/syswrite instead of the more common
> read/write functions. ?I personally find luserspace I/O-buffering
> distasteful, especially on sockets. ?These calls should be safely
> switchable to use read/write for Mongrel since it has threads
> and slow clients to deal with (neither are a concern for Unicorn).
>
> The process management is generally boring and generic (besides reexec).
> It can probably be used in a future mongrel_cluster and allowed shared
> listeners, too. ?With preload_app, it works out-of-the box for nearly
> everything (Sinatra 0.3.x with code reloading enabled being an
> exception).
>
> Tests can run in parallel using GNU make (my favorite language for
> parallel programming). ?This was one of the first things I did to the
> original Mongrel code (though I tweaked it along the way).
>
> More details for all of these changes are of course in the commit
> messages and comments, even. ?Unicorn is probably the most heavily
> commented/documented code I've ever written, too.
>
> Anyways, let me know if you guys want more details on certain
> changes or help merging certain changes into Mongrel.
>
>
> == Disclaimer
>
> Keep in mind that Unicorn still has no real Ruby applications running on
> it (fork+exec on cgit doesn't count). ?The Sinatra projects I initially
> tested this on both got canceled, even, so Unicorn could even be bad
> luck :)
>
> Since Unicorn is/was a new project, I took many more liberties and risks
> with it than I would with an established project like Mongrel, so keep
> that in mind, too :)
>
> I also don't think I'll be allowed much more $DAYJOB time to work on it.
> Most of our projects already run well enough with the nasty
> qrp+num_processors=1 hack I did last year, and these projects have been
> in code/feature freeze for some time, so I don't think I'll ever be
> allowed to deploy Unicorn with them... Oh well.
>
> --
> Eric Wong
> _______________________________________________
> Mongrel-development mailing list
> Mongrel-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-development
>



-- 
Evan Weaver

From luislavena at gmail.com  Sat Apr 25 11:46:42 2009
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 25 Apr 2009 12:46:42 -0300
Subject: [Mongrel-development] [ANN] rake-compiler 0.5.0 Released
Message-ID: <71166b3b0904250846h40b0b58am6587826aad7a9586@mail.gmail.com>

rake-compiler version 0.5.0 has been released!

* <http://github.com/luislavena/rake-compiler>
* <http://rubyforge.org/projects/rake-compiler>

= rake-compiler

rake-compiler aims to help Gem developers while dealing with Ruby C
extensions, simplifiying the code and reducing the duplication.

It follows *convention over configuration* and set an standarized
structure to build and package C extensions in your gems.

This is the result of expriences dealing with several Gems that required
native extensions across platforms and different user configurations
where details like portability and clarity of code were lacking.

== An Overview

Let's summarize what rake-compiler provides:

* No custom rake tasks required. Less code duplication and errors.

* Painlessly build extensions on different platforms (Linux, OSX and Windows).

* Allow multiple extensions be compiled inside the same gem.

* Mimics RubyGems installation process, so helps as test environment.

* Simplify cross platform compilation of extensions (target Windows from Linux).

Changes:

=== 0.5.0 / 2009-04-25

* Enhancements
  * Allow generation of multiple gems for Windows (EXPERIMENTAL)
    This allows build gems for both VC6 and MinGW builts of Ruby
    (Thanks to Jonathan Stott for the suggestion)

      Rake::ExtensionTask.new('my_extension', GEM_SPEC) do |ext|
        ext.cross_compile = true
        ext.cross_platform = ['i386-mswin32', 'i386-mingw32']
      end

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From normalperson at yhbt.net  Sun Apr 26 16:38:35 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 26 Apr 2009 13:38:35 -0700
Subject: [Mongrel-development] Unicorn - Gossamer Fork: With Threads
Message-ID: <20090426203834.GA9854@dcvr.yhbt.net>

Hi all,

I've pushed out a new branch of Unicorn named "gossamer" to my git repo
that uses threads.  It's mainly to ease integration of Unicorn code into
Mongrel, but may even be useful to someone today.  Like Unicorn, it only
runs on Unix-like systems.

I'm not planning on making any release packages for this myself.

Here's a snippet of the README:

-------------------------- 8< -------------------------
== Unicorn for the masochists that use threads

* An experimental fork of Unicorn for deployments where using threads
may make some sense: 3rd-party API calls, long-polling, Comet...

* This is primarily intended as a staging area for reintegrating
Unicorn code into Mongrel.

* Both processes and threads are used, each process spawns a
predetermined number of worker threads.  The total number of
concurrent clients is worker_processes * worker_threads.

=== Differences from Unicorn

* Log rotation happens immediately instead of being deferred to
happening in-between requests.  This means multiline log messages
can be split between log rotations.

* Threads are used.  Meaning all the headaches (and rare benefits)
of using them will be exposed to your application code.

=== Differences from Mongrel

* Worker threads are pre-spawned instead of being spawned for
every request.  This makes memory usage more predictable and should
theoretically perform better with native threads under Ruby 1.9.  Each
worker thread does non-blocking accept on shared sockets.

* Everything else that's different from Mongrel in Unicorn...
-------------------------- 8< -------------------------

-- 
Eric Wong

From luislavena at gmail.com  Sun Apr 26 20:32:01 2009
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 26 Apr 2009 21:32:01 -0300
Subject: [Mongrel-development] Mongrel, cross compilation,
	Echoe and rake-compiler
Message-ID: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>

Hello Guys, mainly Evan,

With the goal to move One-Click Ruby Installer to use MinGW (GCC)
compiler, I found there is no binary for mongrel for that platform.

Because of that, the migration for lot of folks will require install
the development toolkit, which I'm trying to avoid.

Being the maintainer of the Windows builds of Mongrel, been wanted to
upgrade it to use rake-compiler project.

rake-compiler has been out for a while, and several projects has been
migrated to it successfully, including ruby-ffi, johnson, nokogiri and
others.

Now, a few questions before I invest a lot of time with mongrel repository.

I'm working over "master" at fauna repository:

http://github.com/fauna/mongrel

My plan is the following:

Ensure both current and new One-Click works with Mongrel.
Ensure building binaries for it either native or cross platform works flawlessly

Now, I have a few blockers:

Dunno which branch is the proper one. last time I worked on 1.2
improving MinGW support and 1.1.5 got out without taking those
patches.

Echoe extension compilation is interfering with rake-compiler one, is
there a way to disable it?

Elliot Cable left a message when I first imported rake-compiler to GitHub:

http://github.com/luislavena/rake-compiler/commit/28e938cf837c6859197000cc647f84f92668f0b6#comments

Again, the goal of rake-compiler is not just simplify the compilation,
but also provide something that Echoe or Hoe doesn't: cross
compilation.

Well, I've shared my plan, what do you guys think?

Cheers,
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From evan at cloudbur.st  Sun Apr 26 21:12:55 2009
From: evan at cloudbur.st (Evan Weaver)
Date: Sun, 26 Apr 2009 18:12:55 -0700
Subject: [Mongrel-development] Mongrel, cross compilation,
	Echoe and 	rake-compiler
In-Reply-To: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
Message-ID: <b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>

I think that's a good plan. Echoe has some rudimentary
cross-compilation (used for JRuby), but not for Mingw. Your way is
better.

My plan is as so:

Gossamer + Rack launch script + some optimizations/bugfixes + Ruby 1.9
compat = more or less Mongrel 2.0.

This puts you in a tough spot, but it's probably best to branch off
Gossamer and let me forward-port whatever is missing. The 1.x branches
are effectively dead, except for a Ruby 1.9 compat update (v1.1.6).

I promise to get to this every weekend, and don't, so I'll stop
promising. I may be able to squeeze some time out of work to spend on
it.

Evan

On Sun, Apr 26, 2009 at 5:32 PM, Luis Lavena <luislavena at gmail.com> wrote:
> Hello Guys, mainly Evan,
>
> With the goal to move One-Click Ruby Installer to use MinGW (GCC)
> compiler, I found there is no binary for mongrel for that platform.
>
> Because of that, the migration for lot of folks will require install
> the development toolkit, which I'm trying to avoid.
>
> Being the maintainer of the Windows builds of Mongrel, been wanted to
> upgrade it to use rake-compiler project.
>
> rake-compiler has been out for a while, and several projects has been
> migrated to it successfully, including ruby-ffi, johnson, nokogiri and
> others.
>
> Now, a few questions before I invest a lot of time with mongrel repository.
>
> I'm working over "master" at fauna repository:
>
> http://github.com/fauna/mongrel
>
> My plan is the following:
>
> Ensure both current and new One-Click works with Mongrel.
> Ensure building binaries for it either native or cross platform works flawlessly
>
> Now, I have a few blockers:
>
> Dunno which branch is the proper one. last time I worked on 1.2
> improving MinGW support and 1.1.5 got out without taking those
> patches.
>
> Echoe extension compilation is interfering with rake-compiler one, is
> there a way to disable it?
>
> Elliot Cable left a message when I first imported rake-compiler to GitHub:
>
> http://github.com/luislavena/rake-compiler/commit/28e938cf837c6859197000cc647f84f92668f0b6#comments
>
> Again, the goal of rake-compiler is not just simplify the compilation,
> but also provide something that Echoe or Hoe doesn't: cross
> compilation.
>
> Well, I've shared my plan, what do you guys think?
>
> Cheers,
> --
> Luis Lavena
> AREA 17
> -
> Perfection in design is achieved not when there is nothing more to add,
> but rather when there is nothing more to take away.
> Antoine de Saint-Exup?ry
> _______________________________________________
> Mongrel-development mailing list
> Mongrel-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-development
>



-- 
Evan Weaver

From luislavena at gmail.com  Sun Apr 26 21:36:52 2009
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 26 Apr 2009 22:36:52 -0300
Subject: [Mongrel-development] Mongrel, cross compilation,
	Echoe and 	rake-compiler
In-Reply-To: <b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
Message-ID: <71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>

On Sun, Apr 26, 2009 at 10:12 PM, Evan Weaver <evan at cloudbur.st> wrote:
> I think that's a good plan. Echoe has some rudimentary
> cross-compilation (used for JRuby), but not for Mingw. Your way is
> better.
>

rake-compiler still doesn't support JRuby, but perhaps a JavaJarTask
is coming, but I'm not holding my breathe until I see these patckes
;-)

> My plan is as so:
>
> Gossamer + Rack launch script + some optimizations/bugfixes + Ruby 1.9
> compat = more or less Mongrel 2.0.
>

The work on this has already started? Gossamer is the codename?

> This puts you in a tough spot, but it's probably best to branch off
> Gossamer and let me forward-port whatever is missing. The 1.x branches
> are effectively dead, except for a Ruby 1.9 compat update (v1.1.6).
>

I've no problem working with bleeding edge stuff, as long I can find it :-)

> I promise to get to this every weekend, and don't, so I'll stop
> promising. I may be able to squeeze some time out of work to spend on
> it.
>

No rush, my only concern is ensure Mongrel itself works on the
upcoming One-Click Installer. Got all the details ironed to do a
release tonight, and when started to install in a sandbox found that
Mongrel wasn't working.

Anyhow, now I have a Mac so 3 way testing between Linux, OSX and
Windows is now possible form my side, so promise not break anything
:-)

Cheers,
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From normalperson at yhbt.net  Sun Apr 26 21:53:56 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 26 Apr 2009 18:53:56 -0700
Subject: [Mongrel-development] Mongrel, cross compilation,
	Echoe and	rake-compiler
In-Reply-To: <b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
Message-ID: <20090427015356.GA2692@dcvr.yhbt.net>

Evan Weaver <evan at cloudbur.st> wrote:
> My plan is as so:
> 
> Gossamer + Rack launch script + some optimizations/bugfixes + Ruby 1.9
> compat = more or less Mongrel 2.0.

Cool.  I'm pretty sure Unicorn and Gossamer are both 1.9-compatible (all
the tests manage to pass), but I don't have any real code running
on 1.9 yet (and nothing in production on 1.8, either, yet).

Let me know if there are any optimizations/bugfixes in particular I can
help with, too.

-- 
Eric Wong

From normalperson at yhbt.net  Sun Apr 26 21:59:47 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 26 Apr 2009 18:59:47 -0700
Subject: [Mongrel-development] [Mongrel]  Mongrel, cross compilation,
	Echoe and  rake-compiler
In-Reply-To: <71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
	<71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>
Message-ID: <20090427015947.GA15181@dcvr.yhbt.net>

Luis Lavena <luislavena at gmail.com> wrote:
> On Sun, Apr 26, 2009 at 10:12 PM, Evan Weaver <evan at cloudbur.st> wrote:
> > My plan is as so:
> >
> > Gossamer + Rack launch script + some optimizations/bugfixes + Ruby 1.9
> > compat = more or less Mongrel 2.0.
> 
> The work on this has already started? Gossamer is the codename?

Did you miss my earlier message posted to this list?

http://rubyforge.org/pipermail/mongrel-development/2009-April/000323.html

> > This puts you in a tough spot, but it's probably best to branch off
> > Gossamer and let me forward-port whatever is missing. The 1.x branches
> > are effectively dead, except for a Ruby 1.9 compat update (v1.1.6).
> 
> I've no problem working with bleeding edge stuff, as long I can find it :-)

It's a branch of Unicorn and in the same repositories:

	git://git.bogomips.org/unicorn.git
	http://git.bogomips.org/unicorn.git
	git://repo.or.cz/unicorn.git (mirror)
	http://repo.or.cz/r/unicorn.git (mirror)

Have fun!

-- 
Eric Wong

From evan at cloudbur.st  Sun Apr 26 22:25:17 2009
From: evan at cloudbur.st (Evan Weaver)
Date: Sun, 26 Apr 2009 19:25:17 -0700
Subject: [Mongrel-development] [Mongrel] Mongrel, cross compilation,
	Echoe 	and rake-compiler
In-Reply-To: <20090427015947.GA15181@dcvr.yhbt.net>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com> 
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com> 
	<71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com> 
	<20090427015947.GA15181@dcvr.yhbt.net>
Message-ID: <b6f68fc60904261925k75399d97y1ac3e9f5c132bd81@mail.gmail.com>

Should I import it into github/fauna and give everybody access? Or
where should the central repos be located.

Evan

On Sun, Apr 26, 2009 at 6:59 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Luis Lavena <luislavena at gmail.com> wrote:
>> On Sun, Apr 26, 2009 at 10:12 PM, Evan Weaver <evan at cloudbur.st> wrote:
>> > My plan is as so:
>> >
>> > Gossamer + Rack launch script + some optimizations/bugfixes + Ruby 1.9
>> > compat = more or less Mongrel 2.0.
>>
>> The work on this has already started? Gossamer is the codename?
>
> Did you miss my earlier message posted to this list?
>
> http://rubyforge.org/pipermail/mongrel-development/2009-April/000323.html
>
>> > This puts you in a tough spot, but it's probably best to branch off
>> > Gossamer and let me forward-port whatever is missing. The 1.x branches
>> > are effectively dead, except for a Ruby 1.9 compat update (v1.1.6).
>>
>> I've no problem working with bleeding edge stuff, as long I can find it :-)
>
> It's a branch of Unicorn and in the same repositories:
>
> ? ? ? ?git://git.bogomips.org/unicorn.git
> ? ? ? ?http://git.bogomips.org/unicorn.git
> ? ? ? ?git://repo.or.cz/unicorn.git (mirror)
> ? ? ? ?http://repo.or.cz/r/unicorn.git (mirror)
>
> Have fun!
>
> --
> Eric Wong
> _______________________________________________
> Mongrel-development mailing list
> Mongrel-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-development
>



-- 
Evan Weaver

From evan at cloudbur.st  Sun Apr 26 22:50:42 2009
From: evan at cloudbur.st (Evan Weaver)
Date: Sun, 26 Apr 2009 19:50:42 -0700
Subject: [Mongrel-development] [Mongrel]  Mongrel, cross compilation,
	Echoe 	and rake-compiler
In-Reply-To: <71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com> 
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com> 
	<71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>
Message-ID: <b6f68fc60904261950v6e3f0e43gb70bd6180a00b1a7@mail.gmail.com>

If you just want to get current Mongrel up to speed, branch from 1.1.5 I guess.

Evan

On Sun, Apr 26, 2009 at 6:36 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Sun, Apr 26, 2009 at 10:12 PM, Evan Weaver <evan at cloudbur.st> wrote:
>> I think that's a good plan. Echoe has some rudimentary
>> cross-compilation (used for JRuby), but not for Mingw. Your way is
>> better.
>>
>
> rake-compiler still doesn't support JRuby, but perhaps a JavaJarTask
> is coming, but I'm not holding my breathe until I see these patckes
> ;-)
>
>> My plan is as so:
>>
>> Gossamer + Rack launch script + some optimizations/bugfixes + Ruby 1.9
>> compat = more or less Mongrel 2.0.
>>
>
> The work on this has already started? Gossamer is the codename?
>
>> This puts you in a tough spot, but it's probably best to branch off
>> Gossamer and let me forward-port whatever is missing. The 1.x branches
>> are effectively dead, except for a Ruby 1.9 compat update (v1.1.6).
>>
>
> I've no problem working with bleeding edge stuff, as long I can find it :-)
>
>> I promise to get to this every weekend, and don't, so I'll stop
>> promising. I may be able to squeeze some time out of work to spend on
>> it.
>>
>
> No rush, my only concern is ensure Mongrel itself works on the
> upcoming One-Click Installer. Got all the details ironed to do a
> release tonight, and when started to install in a sandbox found that
> Mongrel wasn't working.
>
> Anyhow, now I have a Mac so 3 way testing between Linux, OSX and
> Windows is now possible form my side, so promise not break anything
> :-)
>
> Cheers,
> --
> Luis Lavena
> AREA 17
> -
> Perfection in design is achieved not when there is nothing more to add,
> but rather when there is nothing more to take away.
> Antoine de Saint-Exup?ry
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>



-- 
Evan Weaver

From luislavena at gmail.com  Sun Apr 26 23:16:38 2009
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 27 Apr 2009 00:16:38 -0300
Subject: [Mongrel-development] [Mongrel] Mongrel, cross compilation,
	Echoe 	and rake-compiler
In-Reply-To: <20090427015947.GA15181@dcvr.yhbt.net>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
	<71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>
	<20090427015947.GA15181@dcvr.yhbt.net>
Message-ID: <71166b3b0904262016u2f5a7bbeo844067deb68c7dc6@mail.gmail.com>

On Sun, Apr 26, 2009 at 10:59 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Luis Lavena <luislavena at gmail.com> wrote:
>> On Sun, Apr 26, 2009 at 10:12 PM, Evan Weaver <evan at cloudbur.st> wrote:
>> > My plan is as so:
>> >
>> > Gossamer + Rack launch script + some optimizations/bugfixes + Ruby 1.9
>> > compat = more or less Mongrel 2.0.
>>
>> The work on this has already started? Gossamer is the codename?
>
> Did you miss my earlier message posted to this list?
>
> http://rubyforge.org/pipermail/mongrel-development/2009-April/000323.html
>

Actually ignored for the simple sake that states *nix compatibility
only, which is not my case since I'm on Windows

>
> It's a branch of Unicorn and in the same repositories:
>
> ? ? ? ?git://git.bogomips.org/unicorn.git
> ? ? ? ?http://git.bogomips.org/unicorn.git
> ? ? ? ?git://repo.or.cz/unicorn.git (mirror)
> ? ? ? ?http://repo.or.cz/r/unicorn.git (mirror)
>
> Have fun!
>

Will take a look, keeping in mind that *must* work across all the
platforms, at least cleanly like Mongrel does.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From luislavena at gmail.com  Sun Apr 26 23:17:59 2009
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 27 Apr 2009 00:17:59 -0300
Subject: [Mongrel-development] [Mongrel] Mongrel, cross compilation,
	Echoe 	and rake-compiler
In-Reply-To: <b6f68fc60904261950v6e3f0e43gb70bd6180a00b1a7@mail.gmail.com>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
	<71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>
	<b6f68fc60904261950v6e3f0e43gb70bd6180a00b1a7@mail.gmail.com>
Message-ID: <71166b3b0904262017o512faf98v97fbb36951f01143@mail.gmail.com>

On Sun, Apr 26, 2009 at 11:50 PM, Evan Weaver <evan at cloudbur.st> wrote:
> If you just want to get current Mongrel up to speed, branch from 1.1.5 I guess.
>
> Evan
>

Then I'll base my work on stable_1-1.

Any advice on the Echoe state and workaround, or should I fork it and
add conditions about rake-compiler being defined?
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From evan at cloudbur.st  Sun Apr 26 23:33:10 2009
From: evan at cloudbur.st (Evan Weaver)
Date: Sun, 26 Apr 2009 20:33:10 -0700
Subject: [Mongrel-development] [Mongrel] Mongrel, cross compilation,
	Echoe 	and rake-compiler
In-Reply-To: <71166b3b0904262017o512faf98v97fbb36951f01143@mail.gmail.com>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com> 
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com> 
	<71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com> 
	<b6f68fc60904261950v6e3f0e43gb70bd6180a00b1a7@mail.gmail.com> 
	<71166b3b0904262017o512faf98v97fbb36951f01143@mail.gmail.com>
Message-ID: <b6f68fc60904262033p150a16a9tfefd1f82d938cd6e@mail.gmail.com>

I think the only Unix-specific thing is Gossamer is the forking...?

Echoe is the same as it ever was...not sure how to integrate
rake-compiler, or whether Echoe is still necessary, or what.

It looks like origin/stable_1-1 is what you want, although I'm not
quite sure what the diff against origin/rel_1-1-5 is about. It looks
like you already did some compiler work.

Wednesday I can work on integrating the Ruby 1.9 fixes...can you wait
until Thursday to do a release?

Evan

On Sun, Apr 26, 2009 at 8:17 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Sun, Apr 26, 2009 at 11:50 PM, Evan Weaver <evan at cloudbur.st> wrote:
>> If you just want to get current Mongrel up to speed, branch from 1.1.5 I guess.
>>
>> Evan
>>
>
> Then I'll base my work on stable_1-1.
>
> Any advice on the Echoe state and workaround, or should I fork it and
> add conditions about rake-compiler being defined?
> --
> Luis Lavena
> AREA 17
> -
> Perfection in design is achieved not when there is nothing more to add,
> but rather when there is nothing more to take away.
> Antoine de Saint-Exup?ry
> _______________________________________________
> Mongrel-development mailing list
> Mongrel-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-development
>



-- 
Evan Weaver

From normalperson at yhbt.net  Sun Apr 26 23:48:06 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 26 Apr 2009 20:48:06 -0700
Subject: [Mongrel-development] [Mongrel] Mongrel, cross compilation,
	Echoe  and rake-compiler
In-Reply-To: <71166b3b0904262016u2f5a7bbeo844067deb68c7dc6@mail.gmail.com>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
	<71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>
	<20090427015947.GA15181@dcvr.yhbt.net>
	<71166b3b0904262016u2f5a7bbeo844067deb68c7dc6@mail.gmail.com>
Message-ID: <20090427034806.GA15943@dcvr.yhbt.net>

Luis Lavena <luislavena at gmail.com> wrote:
> On Sun, Apr 26, 2009 at 10:59 PM, Eric Wong <normalperson at yhbt.net> wrote:
> > Luis Lavena <luislavena at gmail.com> wrote:
> >> On Sun, Apr 26, 2009 at 10:12 PM, Evan Weaver <evan at cloudbur.st> wrote:
> >> > My plan is as so:
> >> >
> >> > Gossamer + Rack launch script + some optimizations/bugfixes + Ruby 1.9
> >> > compat = more or less Mongrel 2.0.
> >>
> >> The work on this has already started? Gossamer is the codename?
> >
> > Did you miss my earlier message posted to this list?
> >
> > http://rubyforge.org/pipermail/mongrel-development/2009-April/000323.html
> >
> 
> Actually ignored for the simple sake that states *nix compatibility
> only, which is not my case since I'm on Windows

<snip>

> Will take a look, keeping in mind that *must* work across all the
> platforms, at least cleanly like Mongrel does.

Of course, this is why Unicorn itself is a separate package from
Mongrel.

I think the UNIX-only stuff is mainly confined to the HttpServer class
where the unportable stuff with forking, shared FDs, signals, pipes are.
That and the SocketHelper that can bind UNIX domain sockets.

The rest of it, mainly http_{request,response}.rb, is stripped-down from
Mongrel to only work with Rack and should be droppable into Mongrel.

The C/Ragel http11 parser interface has been simplified a lot with some
minor speed improvements.  It doesn't use any new functions so it should
be fine on Windows . The JRuby version will need to be updated to use
the simpler interface (or http_request to use the old interface).  I've
been planning on stealing (or writing) a pure-Ruby parser for Unicorn,
as well...

-- 
Eric Wong

From normalperson at yhbt.net  Mon Apr 27 04:20:31 2009
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 27 Apr 2009 01:20:31 -0700
Subject: [Mongrel-development] [Mongrel] Mongrel, cross compilation,
	Echoe  and rake-compiler
In-Reply-To: <b6f68fc60904261925k75399d97y1ac3e9f5c132bd81@mail.gmail.com>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
	<71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>
	<20090427015947.GA15181@dcvr.yhbt.net>
	<b6f68fc60904261925k75399d97y1ac3e9f5c132bd81@mail.gmail.com>
Message-ID: <20090427082030.GA21031@dcvr.yhbt.net>

Evan Weaver <evan at cloudbur.st> wrote:
> Should I import it into github/fauna and give everybody access? Or
> where should the central repos be located.

Sure, the more mirrors the better.  I won't be signing up for github,
though[1].  As long as we can all pull and/or send patches to each
other, things should be good.

How's git support in Rubyforge these days?  I haven't gotten around to
asking to get a project of mine converted, I suppose I could give it a
shot...

[1] - I'm just not comfortable relying on free-as-in-beer commercial
services for free-as-in-speech development.
-- 
Eric Wong

From luislavena at gmail.com  Mon Apr 27 07:53:00 2009
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 27 Apr 2009 08:53:00 -0300
Subject: [Mongrel-development] [Mongrel] Mongrel, cross compilation,
	Echoe 	and rake-compiler
In-Reply-To: <20090427082030.GA21031@dcvr.yhbt.net>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
	<71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>
	<20090427015947.GA15181@dcvr.yhbt.net>
	<b6f68fc60904261925k75399d97y1ac3e9f5c132bd81@mail.gmail.com>
	<20090427082030.GA21031@dcvr.yhbt.net>
Message-ID: <71166b3b0904270453w2b4535c8hddcf60c57d1ae10c@mail.gmail.com>

On Mon, Apr 27, 2009 at 5:20 AM, Eric Wong <normalperson at yhbt.net> wrote:
> Evan Weaver <evan at cloudbur.st> wrote:
>> Should I import it into github/fauna and give everybody access? Or
>> where should the central repos be located.
>
> Sure, the more mirrors the better. ?I won't be signing up for github,
> though[1]. ?As long as we can all pull and/or send patches to each
> other, things should be good.
>

That is the good part of Git.

> How's git support in Rubyforge these days? ?I haven't gotten around to
> asking to get a project of mine converted, I suppose I could give it a
> shot...

Good, rake-compiler uses RubyForge as sync.

> [1] - I'm just not comfortable relying on free-as-in-beer commercial
> services for free-as-in-speech development.

Well, everybody needs to eat and pay bills.
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From luislavena at gmail.com  Mon Apr 27 11:43:46 2009
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 27 Apr 2009 12:43:46 -0300
Subject: [Mongrel-development] [Mongrel] Mongrel, cross compilation,
	Echoe 	and rake-compiler
In-Reply-To: <b6f68fc60904262033p150a16a9tfefd1f82d938cd6e@mail.gmail.com>
References: <71166b3b0904261732j6d5c50fay3d05fdca7f4a6b6e@mail.gmail.com>
	<b6f68fc60904261812l5d63c2fco4e8cf08d04cee2b@mail.gmail.com>
	<71166b3b0904261836ua76ee21p35b46b999d02e2f8@mail.gmail.com>
	<b6f68fc60904261950v6e3f0e43gb70bd6180a00b1a7@mail.gmail.com>
	<71166b3b0904262017o512faf98v97fbb36951f01143@mail.gmail.com>
	<b6f68fc60904262033p150a16a9tfefd1f82d938cd6e@mail.gmail.com>
Message-ID: <71166b3b0904270843u17b9b9dcv21e70d821e3fb604@mail.gmail.com>

On Mon, Apr 27, 2009 at 12:33 AM, Evan Weaver <evan at cloudbur.st> wrote:
> I think the only Unix-specific thing is Gossamer is the forking...?
>
> Echoe is the same as it ever was...not sure how to integrate
> rake-compiler, or whether Echoe is still necessary, or what.
>
> It looks like origin/stable_1-1 is what you want, although I'm not
> quite sure what the diff against origin/rel_1-1-5 is about. It looks
> like you already did some compiler work.
>
> Wednesday I can work on integrating the Ruby 1.9 fixes...can you wait
> until Thursday to do a release?
>

Can wait until weekend if needed :-)

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry