Forum: Ruby [ANN] snailgun-1.0.2

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Brian C. (Guest)
on 2009-05-21 14:21
New experimental project:

Snailgun accelerates the startup of Ruby applications which require
large numbers of libraries. It's especially beneficial for TDD with
Rails apps, since the overhead of loading all the Rails libraries is
essentially eliminated.

Works only on Linux/BSD systems.

For more info see:
http://github.com/candlerb/snailgun
Roger P. (Guest)
on 2009-05-21 15:45
> Works only on Linux/BSD systems.
>
> For more info see:
> http://github.com/candlerb/snailgun

I assume it just loads the libs then forks off processes on demand?
Nice.  You kind of could make a windows compat one--it would just have
to start a process in the background (on deck) each time it's run,
something like that.
Nice.
-=r
Brian C. (Guest)
on 2009-05-21 16:09
Roger P. wrote:
> I assume it just loads the libs then forks off processes on demand?
> Nice.  You kind of could make a windows compat one--it would just have
> to start a process in the background (on deck) each time it's run,
> something like that.

As well as fork(), I am passing open file descriptors for
stdin/stdout/stderr across a Unix domain socket. So if there were a
Windows version, I don't think it would have very much in common with
this one :-)
Roger P. (Guest)
on 2009-05-21 16:32
> As well as fork(), I am passing open file descriptors for
> stdin/stdout/stderr across a Unix domain socket. So if there were a
> Windows version, I don't think it would have very much in common with
> this one :-)

Interesting.  I suppose TCP sockets would work with doze...
-=r
Brian C. (Guest)
on 2009-05-21 16:56
Roger P. wrote:
> Interesting.  I suppose TCP sockets would work with doze...

But you can't pass a file descriptor across a TCP socket - so you would
have to proxy (and multiplex) stdin, stdout and stderr across the socket
as well. It would become a sort of remote ruby shell service, in which
case it should probably use an existing remote shell protocol like rsh
or ssh, so at least the client side is standard.

It's probably doable, but would be a lot more complex than snailgun.
Ryan D. (Guest)
on 2009-05-21 22:17
(Received via mailing list)
On May 21, 2009, at 04:45 , Roger P. wrote:

>
>> Works only on Linux/BSD systems.
>>
>> For more info see:
>> http://github.com/candlerb/snailgun
>
> I assume it just loads the libs then forks off processes on demand?
> Nice.  You kind of could make a windows compat one--it would just have
> to start a process in the background (on deck) each time it's run,
> something like that.

I'm sure Brian would be happy to accept patches.
Ryan D. (Guest)
on 2009-05-21 22:18
(Received via mailing list)
On May 21, 2009, at 03:21 , Brian C. wrote:

> http://github.com/candlerb/snailgun
this looks great and could save my team a lot of time collectively.
when will it become a real gem?
Brian C. (Guest)
on 2009-05-21 23:34
Ryan D. wrote:
> this looks great and could save my team a lot of time collectively.
> when will it become a real gem?

What's a "real gem"? Do you mean one hosted on rubyforge?
Ben B. (Guest)
on 2009-05-21 23:57
(Received via mailing list)
On Thu, May 21, 2009 at 12:34 PM, Brian C. 
<removed_email_address@domain.invalid>
wrote:
> What's a "real gem"? Do you mean one hosted on rubyforge?

I can't speak for Ryan but that's my definition.  This would be huge for
me too.

Ben
Brian C. (Guest)
on 2009-05-22 00:18
Ben B. wrote:
> I can't speak for Ryan but that's my definition.  This would be huge for
> me too.

I only had to type "gem sources -a http://gems.github.com" as a one-off,
and that didn't seem like a big stumbling block to me. But since it
matters to people, I've now requested a rubyforge project.
Ben B. (Guest)
on 2009-05-22 00:38
(Received via mailing list)
On Thu, May 21, 2009 at 1:18 PM, Brian C. <removed_email_address@domain.invalid>
wrote:
> I only had to type "gem sources -a http://gems.github.com" as a one-off,
> and that didn't seem like a big stumbling block to me. But since it
> matters to people, I've now requested a rubyforge project.

It's not big, no, but it's still a stumbling block.  Also, I don't
want to have to figure out or remember your username to install your
gem, I just want to be able to say gem install snailgun.

Ben
Ryan D. (Guest)
on 2009-05-22 02:26
(Received via mailing list)
On May 21, 2009, at 12:56 , Ben B. wrote:

> On Thu, May 21, 2009 at 12:34 PM, Brian C.
> <removed_email_address@domain.invalid> wrote:
>> What's a "real gem"? Do you mean one hosted on rubyforge?
>
> I can't speak for Ryan but that's my definition.  This would be huge
> for me too.

Ben, do you happen to approve project proposals as well as news? If
not, why not? I can poke at tom if it'll help.

Once this becomes a real gem, I'm gonna work on getting an autotest
plugin working for it and out the door. We need this.
Ryan D. (Guest)
on 2009-05-22 02:27
(Received via mailing list)
On May 21, 2009, at 13:18 , Brian C. wrote:

> Ben B. wrote:
>> I can't speak for Ryan but that's my definition.  This would be
>> huge for
>> me too.
>
> I only had to type "gem sources -a http://gems.github.com" as a one-
> off,
> and that didn't seem like a big stumbling block to me. But since it
> matters to people, I've now requested a rubyforge project.

Alternatively, we can make you an honorary seattle.rb member. :)
Ben B. (Guest)
on 2009-05-22 02:40
(Received via mailing list)
On Thu, May 21, 2009 at 3:25 PM, Ryan D. <removed_email_address@domain.invalid>
wrote:
> Ben, do you happen to approve project proposals as well as news? If not, why
> not? I can poke at tom if it'll help.

Funny you should ask.  Tom mailed me the other day about that topic.
I'm not sure where we are with it right now; I'll check in with him.

> Once this becomes a real gem, I'm gonna work on getting an autotest plugin
> working for it and out the door. We need this.

And I, in turn, need that autotest plugin.  Desperately.

Ben
Brian C. (Guest)
on 2009-05-22 11:36
Ben B. wrote:
>> Once this becomes a real gem, I'm gonna work on getting an autotest plugin
>> working for it and out the door. We need this.
>
> And I, in turn, need that autotest plugin.  Desperately.

Actually, the package already includes an autotest plugin (it's called
"fautotest"). I just forgot to mention it in the README :-)

The rubyforge project was approved last night and I just copied the gem
to the files area, but it still isn't available using 'gem install'.
Perhaps someone who understands gems and/or rubyforge more than me can
have a look into it. This is the first application I've packaged as a
gem.

Regards,

Brian.
Brian C. (Guest)
on 2009-05-22 11:52
It's available on rubyforge now. (I just needed to add the rubyforge
project name into the gemspec)
Robert D. (Guest)
on 2009-05-22 15:44
(Received via mailing list)
On Thu, May 21, 2009 at 12:21 PM, Brian C. 
<removed_email_address@domain.invalid>
wrote:
> New experimental project:
Oh I almost  missed the pun, great name, Brian.
R.



--
Toutes les grandes personnes ont d’abord été des enfants, mais peu
d’entre elles s’en souviennent.

All adults have been children first, but not many remember.

[Antoine de Saint-Exupéry]
Christopher D. (Guest)
on 2009-05-22 19:44
(Received via mailing list)
On Thu, May 21, 2009 at 5:32 AM, Roger P. <removed_email_address@domain.invalid>
wrote:
>> As well as fork(), I am passing open file descriptors for
>> stdin/stdout/stderr across a Unix domain socket. So if there were a
>> Windows version, I don't think it would have very much in common with
>> this one :-)
>
> Interesting.  I suppose TCP sockets would work with doze...

It looks like you could do something similar leveraging the
win32-process gem using Process.create which allows you to send
stdin/stdout/stderr, but I'm guessing that the code will look
significantly different (and have different dependencies) than the
Linux, etc., one, so it might be better to have a different
implementation with a shared public API.
This topic is locked and can not be replied to.