Google hasn't announced their final selection yet for mentoring
organizations, but I'm operating under the assumption that we will be.
Given that, this is the time for people to start putting together
proposals for student projects. The window is only about a week long,
and is opens up in just a couple of days.
We've got mentoring volunteers from the JRuby, RoR, rubinius, ruby,
and Xruby communities, so don't feel constrained to any particular
field. On the other hand, projects that are liable to benefit the
largest possible group of users are certainly going to get some extra
karma.
If you're not a student, but have a great idea, feel free to toss it
out for discussion. Who knows, maybe someone will pick it up and run
with it.
It would be really neat to combine scintilla and irb to get a
lightweight drscheme-like environment optimised for iterative,
interactive development. It would need the following features:
1. A mathematica-like wrapper around irb, where each command/response
is an individual gui object, so that it would be easy to select
individual lines from the history (not essential, but it'd make the
gui more convenient to use)
2. The ability to copy an irb line to the scintilla pane
3. The ability to wipe the irb session and reload it from the
scintilla pane (this is the main requirement)
4. (optional) An SDL pane that was specialcased into irb, so that
people learning ruby could play around with graphics right from the
start (remembering my BBC Basic days)
Another option is to write a DrRuby atop the DrScheme engine
(someone's done a DrOcaml, for instance), but that's probably a lot
harder.
martin
···
On 3/14/07, pat eyler <pat.eyler@gmail.com> wrote:
If you're not a student, but have a great idea, feel free to toss it
out for discussion. Who knows, maybe someone will pick it up and run
with it.
I think Event Machine is very ripe ground for Summer of Code projects. It's already one of the coolest libraries out there for Ruby and the team has a lot of great ideas for making it even better.
One of their ideas is to build every protocol under the sun for it, so coders could just use EventMachine::HTTP or EventMachine::Telnet instead of having to work with the low-level plumbing. There's even been mention of getting DRb running on top of EventMachine, which would likely make it quite a bit more robust and scalable.
The team also has interest in providing mid-level protocol building frameworks. This would make it easier to add additional protocols. There are lots of interesting ideas to explore along this path to: protocol parser generators, DSLs for defining protocols, callback systems for reacting to protocol events, or even just generic event loops.
This project is very under loved and there's no reason it couldn't become the huge success POE is for Perl or Twisted is for Python. If you're remotely interested in networking, I say jump on their mailing list and bounce some ideas off of them.
James Edward Gray II
···
On Mar 13, 2007, at 8:47 PM, pat eyler wrote:
If you're not a student, but have a great idea, feel free to toss it
out for discussion. Who knows, maybe someone will pick it up and run
with it.
I'm new to Ruby and I've been researching to create a desktop app, and
what I've found so far is that there are many GUIs but each of them has
it's own way of doing things. I read some thread proposing a unified
"ruby-like" framework for GUI development, where the developer could
swap easily the GUI he wants to use (GTK, FOX, QT...) without changing
the application. This could be a good project and it will foster the
creation of more ruby desktop apps. Who knows, may be someone could
develop a rails-like stuff for desktop apps.
Unfortunately I won't have time to enter this program this year, but thought
I'd share the idea I was going to use if I could.
Ruby GUI toolkits have their fair share of issues. The general method to
dodging this is to distribute your application as a standalone web
application. My idea was to augment this with a "wrapper" GUI generator for
each of the big OS's. This GUI would be a simple, OS specific window, that
displayed the page. It would include a few simple menu choices, exit,
about, help, and provide ruby based callbacks to direct the application to
the proper page for each. This probably sounds very convoluted, and I'm
probably explaining it poorly. But if any student out there is interested,
I'd be willing to give a more thorough explanation.
···
On 3/13/07, pat eyler <pat.eyler@gmail.com> wrote:
Google hasn't announced their final selection yet for mentoring
organizations, but I'm operating under the assumption that we will be.
Given that, this is the time for people to start putting together
proposals for student projects. The window is only about a week long,
and is opens up in just a couple of days.
We've got mentoring volunteers from the JRuby, RoR, rubinius, ruby,
and Xruby communities, so don't feel constrained to any particular
field. On the other hand, projects that are liable to benefit the
largest possible group of users are certainly going to get some extra
karma.
If you're not a student, but have a great idea, feel free to toss it
out for discussion. Who knows, maybe someone will pick it up and run
with it.
I think a great project to put someone on is the "core" in Rubinius. This
is an area that is not really that hard but is nice and challenging. Other
areas could be unified test suites for the different implementations,
Rubinius's spec stuff would be a good place to start.
Anyone else agree?
···
On 3/13/07, Daniel Berger <djberg96@gmail.com> wrote:
pat eyler wrote:
<snip>
> If you're not a student, but have a great idea, feel free to toss it
> out for discussion. Who knows, maybe someone will pick it up and run
> with it.
Just a couple of idea
* A 'find' module that's more useful (i.e. options based on the
command line tool)
* Bench::Unit (i.e. a more formal benchmark suite)
Regards,
Dan
--
<JFH>
"Work hard to find something that fascinates you." - Richard Feynman
If you're not a student, but have a great idea, feel free to toss it
out for discussion. Who knows, maybe someone will pick it up and run
with it.
Just a couple of idea
* A 'find' module that's more useful (i.e. options based on the
command line tool)
* Bench::Unit (i.e. a more formal benchmark suite)
Along those lines:
1. A recorder that will capture a Watir script of a web application as someone uses it from IE (or Firewatir/Firefox)
2. Extend Ruby Inline to accept assembler on gcc-based systems (actually, it may already do that)
3. A built in load tester for Rails applications
4. A lightweight Ruby interpreter for distributed / embedded processing
On 3/14/07, James Edward Gray II <james@grayproductions.net> wrote:
On Mar 13, 2007, at 8:47 PM, pat eyler wrote:
> If you're not a student, but have a great idea, feel free to toss it
> out for discussion. Who knows, maybe someone will pick it up and run
> with it.
I think Event Machine is very ripe ground for Summer of Code
projects. It's already one of the coolest libraries out there for
Ruby and the team has a lot of great ideas for making it even better.
One of their ideas is to build every protocol under the sun for it,
so coders could just use EventMachine::HTTP or EventMachine::Telnet
instead of having to work with the low-level plumbing. There's even
been mention of getting DRb running on top of EventMachine, which
would likely make it quite a bit more robust and scalable.
The team also has interest in providing mid-level protocol building
frameworks. This would make it easier to add additional protocols.
There are lots of interesting ideas to explore along this path to:
protocol parser generators, DSLs for defining protocols, callback
systems for reacting to protocol events, or even just generic event
loops.
This project is very under loved and there's no reason it couldn't
become the huge success POE is for Perl or Twisted is for Python. If
you're remotely interested in networking, I say jump on their mailing
list and bounce some ideas off of them.
--
gnufied
-----------
There was only one Road; that it was like a great river: its springs
were at every doorstep, and every path was its tributary. http://people.inxsasia.com/~hemant
If you're not a student, but have a great idea, feel free to toss it
out for discussion. Who knows, maybe someone will pick it up and run
with it.
It would be really neat to combine scintilla and irb to get a
lightweight drscheme-like environment optimised for iterative,
interactive development. It would need the following features:
1. A mathematica-like wrapper around irb, where each command/response
is an individual gui object, so that it would be easy to select
individual lines from the history (not essential, but it'd make the
gui more convenient to use)
2. The ability to copy an irb line to the scintilla pane
3. The ability to wipe the irb session and reload it from the
scintilla pane (this is the main requirement)
4. (optional) An SDL pane that was specialcased into irb, so that
people learning ruby could play around with graphics right from the
start (remembering my BBC Basic days)
Another option is to write a DrRuby atop the DrScheme engine
(someone's done a DrOcaml, for instance), but that's probably a lot
harder.
martin
Scite is a bit like that, at least the version shipped with the Windows One-Click Installer. A DrRuby would be spectacular, though!
Another thing I'd like to see come out of Google Summer of Code would be (and this is somewhat language-independent) some tools like those described in "Generative Programming" -- tools that work at the syntactic and semantic level rather than at the surface syntax level. There are some core concepts just about all "modern" languages have -- integer and floating point and string data types, regular expressions, arrays and hashes, classes and objects and methods. A tool that could manipulate a graphical version of a program, such as a parse tree, and then reconstruct the source code from that is something I'd use daily.
···
On 3/14/07, pat eyler <pat.eyler@gmail.com> wrote:
where can I read up on Event Machine? My google-fu is not powerful
···
On 3/14/07, James Edward Gray II <james@grayproductions.net> wrote:
On Mar 13, 2007, at 8:47 PM, pat eyler wrote:
> If you're not a student, but have a great idea, feel free to toss it
> out for discussion. Who knows, maybe someone will pick it up and run
> with it.
I think Event Machine is very ripe ground for Summer of Code
projects. It's already one of the coolest libraries out there for
Ruby and the team has a lot of great ideas for making it even better.
One of their ideas is to build every protocol under the sun for it,
so coders could just use EventMachine::HTTP or EventMachine::Telnet
instead of having to work with the low-level plumbing. There's even
been mention of getting DRb running on top of EventMachine, which
would likely make it quite a bit more robust and scalable.
The team also has interest in providing mid-level protocol building
frameworks. This would make it easier to add additional protocols.
There are lots of interesting ideas to explore along this path to:
protocol parser generators, DSLs for defining protocols, callback
systems for reacting to protocol events, or even just generic event
loops.
This project is very under loved and there's no reason it couldn't
become the huge success POE is for Perl or Twisted is for Python. If
you're remotely interested in networking, I say jump on their mailing
list and bounce some ideas off of them.
I remember that in my research I found that the RIDE people dabbled in
it as a sister project (IIRC).
You can have a look there.
Unfortunately, GUI APIs are hard to get right. Very hard. I've done a
GUI toolkit for myself in uby lately (some exploratory programming,
prototyping a few ideas of mine) and I've spent more time thinking up
the API than coding.
And this was a throw-away prototype.
Which only I would ever use.
In the end I wanted to add a critical feature that was next on the
milestone list and found that I made such a fatal mistake in the API
that re-coding everything would be almost as easy as fixing everything
(I started with squares only, thinking that it'd be simple to modify
it to use other shapes, but used that assumption everywhere in the
code. I knew that fixing it everywhere would result in much more bugs
than good).
It's hard.
But you can try, and I'll look forward to hearing the results.
Aur
···
On 3/15/07, Nando Sanchez <rubynando@yahoo.com> wrote:
I'm new to Ruby and I've been researching to create a desktop app, and
what I've found so far is that there are many GUIs but each of them has
it's own way of doing things. I read some thread proposing a unified
"ruby-like" framework for GUI development, where the developer could
swap easily the GUI he wants to use (GTK, FOX, QT...) without changing
the application. This could be a good project and it will foster the
creation of more ruby desktop apps. Who knows, may be someone could
develop a rails-like stuff for desktop apps.
Ruby GUI toolkits have their fair share of issues. The general method to
dodging this is to distribute your application as a standalone web
application. My idea was to augment this with a "wrapper" GUI generator for
each of the big OS's. This GUI would be a simple, OS specific window, that
displayed the page. It would include a few simple menu choices, exit,
about, help, and provide ruby based callbacks to direct the application to
the proper page for each. This probably sounds very convoluted, and I'm
probably explaining it poorly. But if any student out there is interested,
I'd be willing to give a more thorough explanation.
[...]
I had a sort of similar idea based on XULrunner. It would be really nice to
be able to develop a desktop application with Rails and Firefox and deliver
it as executables for Mac, Windows, or Linux using XULrunner as a frontend.
It requires a few things to make it work, though:
1) app packaging for each platform
2) an extension to XULrunner to be able to run the ruby interpreter
directly (it shouldn't be two processes)
3) an URL handler extension to XULrunner so that URLs can be served
in-process without opening a network port, even one bound to localhost
4) the Ruby side of that URL handler
5) EXTRA CREDIT: some minimal obfuscation/encryption/compression for the
Ruby code to make pointy-haired bosses happier
===Tanner Burson===
--Greg
···
On Fri, Mar 16, 2007 at 04:48:45AM +0900, Tanner Burson wrote:
1. A recorder that will capture a Watir script of a web application as someone uses it from IE (or Firewatir/Firefox)
+1
I would be really interested in this, since I am just integrating FireWatir support into scRUBYt![1] - so far navigating to the page you wish to scrape is described manually, like:
#Construct the scraper here
stuff do
item_name "Logitech diNovo Edge ( 967685-0403 )"
price "$169.98"
end
OK, also this is thousand times easier than to do it by hand - however, if I could record user steps and spit out a script automatically instead of writing it by hand, it would be even much more cool!
On a similar note, I'd like to see someone look into creating an
abstract description format (e.g., in XML or YAML) for use by the
dozens of "documentation generators" I see listed on Wikipedia:
Most of these programs parse one or more languages, then present the
result in HTML (etc). Almost none of them are willing to output the
collected information in a machine-friendly format, let alone accept
such information from another source.
-r
···
At 12:14 AM +0900 3/15/07, M. Edward (Ed) Borasky wrote:
Another thing I'd like to see come out of Google Summer of Code
would be (and this is somewhat language-independent) some tools
like those described in "Generative Programming" -- tools that
work at the syntactic and semantic level rather than at the
surface syntax level. There are some core concepts just about
all "modern" languages have -- integer and floating point and
string data types, regular expressions, arrays and hashes,
classes and objects and methods. A tool that could manipulate a
graphical version of a program, such as a parse tree, and then
reconstruct the source code from that is something I'd use daily.
Nevermind, it's listed as EventMachine in rubyforge, one word...
···
On 3/14/07, Albert Ng <twinwing@gmail.com> wrote:
where can I read up on Event Machine? My google-fu is not powerful
On 3/14/07, James Edward Gray II < james@grayproductions.net> wrote:
>
> On Mar 13, 2007, at 8:47 PM, pat eyler wrote:
>
> > If you're not a student, but have a great idea, feel free to toss it
> > out for discussion. Who knows, maybe someone will pick it up and run
> > with it.
>
> I think Event Machine is very ripe ground for Summer of Code
> projects. It's already one of the coolest libraries out there for
> Ruby and the team has a lot of great ideas for making it even better.
>
> One of their ideas is to build every protocol under the sun for it,
> so coders could just use EventMachine::HTTP or EventMachine::Telnet
> instead of having to work with the low-level plumbing. There's even
> been mention of getting DRb running on top of EventMachine, which
> would likely make it quite a bit more robust and scalable.
>
> The team also has interest in providing mid-level protocol building
> frameworks. This would make it easier to add additional protocols.
> There are lots of interesting ideas to explore along this path to:
> protocol parser generators, DSLs for defining protocols, callback
> systems for reacting to protocol events, or even just generic event
> loops.
>
> This project is very under loved and there's no reason it couldn't
> become the huge success POE is for Perl or Twisted is for Python. If
> you're remotely interested in networking, I say jump on their mailing
> list and bounce some ideas off of them.
>
> James Edward Gray II
>
In theory, rdoc is supposed to output XML, but i've never gotten it to
work right...
···
On 3/14/07, Rich Morin <rdm@cfcl.com> wrote:
At 12:14 AM +0900 3/15/07, M. Edward (Ed) Borasky wrote:
> Another thing I'd like to see come out of Google Summer of Code
> would be (and this is somewhat language-independent) some tools
> like those described in "Generative Programming" -- tools that
> work at the syntactic and semantic level rather than at the
> surface syntax level. There are some core concepts just about
> all "modern" languages have -- integer and floating point and
> string data types, regular expressions, arrays and hashes,
> classes and objects and methods. A tool that could manipulate a
> graphical version of a program, such as a parse tree, and then
> reconstruct the source code from that is something I'd use daily.
On a similar note, I'd like to see someone look into creating an
abstract description format (e.g., in XML or YAML) for use by the
dozens of "documentation generators" I see listed on Wikipedia:
Most of these programs parse one or more languages, then present the
result in HTML (etc). Almost none of them are willing to output the
collected information in a machine-friendly format, let alone accept
such information from another source.
