Archive for the ‘GSoC’ Category

StrongRuby : gradual typing for Duby.

Abstract :

 

Static and dynamic type systems have well-known strengths and weaknesses. Statically typed programming languages incorporate a built-in static type system. Every legal program must successfully typecheck according to the rules of the type system.

 

Gradual typing provides the benefits of both static and dynamic checking in a single language by allowing the programmer to control whether a portion of the program is type checked at compile-time or run-time by adding or removing type annotations on variables. , that have no effect on the dynamic semantics of the language.

 

The complete proposal here : strongruby.pdf

GSoC 2007 Accepted.

My Ruby proposal Cover the core of Ruby with Rspec was accepted. I think its gone to be a great summer for me, working and learning with really intelligent people, and with a cool language and framework.

——————————————————————————————————–

Dear Applicant,

Congratulations! This email is being sent to inform you that your
application was accepted to take part in the Summer of Code. Please
check your student home page in the SoC web application at
http://code.google.com/soc/student_home.html to determine which of
your applications was accepted.

Over the next few days, you will be added to a special members only
Google Group
(http://groups.google.com/group/google-summer-of-code-students-list).
Please take a moment to browse the archive before posting.  We prefer
most of the program discussion to take place on the program discussion
list.  However, the students list is a private place for communication
about subjects where our student participants prefer to not
communicate the matter more widely.  You can find more information
about the program mailing lists here:
http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-program-mailing-lists

Your mentoring organization may also set up similar mailing lists for
you and your cohorts so that they may interact with you on your
project. You should not wait for them; please feel free to contact
your mentor and let them know you are ready to start engaging with
your new project community.

You should also get into the habit of visiting your student home page
on a semi-regular basis, as we will track status, payments, paperwork
and take final surveys from this page.

If you have questions regarding payment, please wait until you see a
message from Leslie Hawthorn detailing what we will need from
you. This will take a few days as we button up the web application and
make sure all the students are properly assigned to the proper groups.

If you cannot take part for some reason, please email us at
gsoc@google.com as soon as possible so that we can allocate your slot
to another student.

Other questions and concerns should be send to gsoc@google.com

Thanks for taking part; we’re very excited to see what the Summer will bring!

Congratulations once again,

The Google Summer of Code Progam Administration Team

GSoC : Seaside and Sails : A generation code tool

=== Abstract ===

This proposal will provide, by the end of the summer, a tool that bring a structure generation to Seaside. This piece of software enhance Seaside with generators tools, commands and conventions that help programmers to develop CRUD-style web applications in Seaside in a much faster approach. Other of the goals of this project is create an extensible code generator that provide the infrastructure to develop custom generator easily

Create, retrieve, update and delete (CRUD) are the four basic functions of persistent storage, a major part of nearly all computer software. Also Each letter in the acronym can be mapped to a standard SQL statement. CRUD forms the basis of most dynamic websites in that they generally have data and function that:

* C reate new records (INSERT)
* R ead existing records (SELECT)
* U pdate existing records (UPDATE)
* D elete existing records (DELETE)

While you’re developing web applications, especially those which are mainly providing you with a simple interface to data in a database. Scaffolding is a proccess that generate the basic classes to create a CRUD-style web.

When creating or editing an entry, Sails scaffold will do all the hard work of form generation and handling for you, and will even provide clever form generation, (via extensibility).

This tool provides a model and its views, as starting point to development, which allows you to see add, delete, show and list the model data. Also the scaffolding process will generate test methods.

Other frameworks scaffolding creates text files that, when run, create the actual class. Sails shouldn’t create a script, but instead create the class immediately.

=== Why scaffolding ? ===

1) Scaffolding provides clear directions : Offer step-by-step directions to develop just what developer must do in order to meet the expectations for the learning activity

2) Scaffolding clarifies purpose : Why are we doing this? Scaffolding keeps purpose and motivation in the forefront.

3) Scaffolding keeps students on task : By providing a pathway or route for the learner,

4) Scaffolding offers assessment to clarify expectations :From the very start, scaffolded lessons provide examples of quality work done by others.

5) Scaffolding reduces uncertainty, surprise and disappointment :

7) Scaffolding delivers efficiency : If done well, a scaffolded templates should nearly scream with efficiency.

=== What make scaffolding and the order command for us ? ===

* One-step creation of components using a template, including models and views. (probably using Magritte)
– The model
– The view with the four basic operation method. Create/read/update/delete (CRUD), list and style method,
– The database scheme

* Easy creation of tests: using Sunit
– unit tests
– functional tests
– performance tests

* Easily connect to persistence layers, create the basic features for CRUD operation in the model. (probably using glorp)

* Help int the deploy application generating a set of commands that :
– Start the server. // WAKom startOn: 9090.
– Register the application // registerAsApplication:
– ….

* Only database Configuration of this tool will be necessary. Code convention over code configuration.

=== Benefits for The Seaside Community ===

Seaside will be powered by a structure code generation. It will accelerate the development cycle, supporting generation for models, views, test, and allowing the user to design and implement custom generators.

While a new framework has a shallow learning curve for Java, JSP, PHP, Python guys, Seaside is much, much different. Structure generation drastically lowers the learning curve by teaching the conventions through code instead of documentation.

=== Development plan : ===

The next planning describe the different milestones of the project. will probably vary during development.

1 Research (1st week)
* Identify the best practices, code conventions and structure convention of a Seaside application
* Identify the common manual task in a Seaside development cycle
* Identify Smalltalk idioms
* Define the commons action in all the task (create a class, define methods, …)

2 Implement the kernel classes, with only basic features. (2nd week)

3 Integrate Magritte with the kernel of the framework to generate the views (3rd week)

4 Integrate Sunit with the Kernel framework to generte unit test (4th week)

5 Implements connectors to the database. (Using glorp) (5th week)

6 implements helpers to deploy the application (6th week)

7 Adding Generator class loaders.(6th week)

8 Implementation of user intefaces (commands for the workspace) (7th week)

9 Extensive testing (Unit Testing)(8th week)

10 Documentation and tutorial. (8th week)

=== Basics generators class hierarchy ===

The next hierarchy is a first approach and must be take like a sketch not like a final version,it will be improve or refactoring. Its represent the object hierarchy.

–|
|– BaseGenerator
| |
| |– ApplicationGenerator
| | |
| | |– seasideAppGenerator
| |
| |– TaskGenerator
| | |
| | |– ModelGenerator
| | |
| | |– ViewGenerator
| | |
| | |– TestGenerator
| |
| |–
| |
|
|– scriptsDeployGenerators
|
|–
|
|– gen // a command line (workspace) for the generators.

=== Related programming techniques : ===

* Reflection.
* Metaprogramming.
* Structure code generation.

=== Related frameworks: ====

* SUnit
* Magritte

=== About me: ===

I am 28 y.o., and I am 5th year student of Computer Science at Universidad de Granada, Spain. I’ll graduate in about 9 month. My interests are virtual machines, web technologies, object-oriented systems, functional languages and many other things.

I work in software company in Hamburg, Germany. My current duty is Ruby/Rails development. My graduate work in university is dedicated to applying Latent Semantic Indexing to natural languages processing.

I also have extensive experience in the Linux-Tomcat-Java-Struts architecture.

My relevant skills include proficiency in C, Java, Lisp, Ruby the standard GNU development tools (gcc, automake, etc.), Java tools (Xdoclet, ant, maven), CVS/SVN, and a host of other smaller languages and tools. I’ve been involved in the open source community for a while. I help to build and configurate http://javahispano.net Gforge (sourceforge) site for the Java spanish spoken community.

=== Motivation and interests: ===

Why I want to take part in it… I’ll be honest. I saw Seaside at the first time, when I read a post ‘on smalltalk blog’ comparing Rails vs Seaside a month ago. I was surprise about this new way to develop web application. And I liked it.

In my first year in the university I have gone to a ground OOP course using Smalltalk.

I spend the last year working with rails. I wrote custom generators and rake task for my employer. I love ruby/rails tools, like rails_generators system or rake, and the way they reduce the time i spend in front of the IDE.

So, I think, I can do this task.

=== Available time: ===

In the beginning of the project (to the end of June), I will be somewhat limited by school – our semester ends by the end of May, followed by one month reserved for exams. During that time, I will spend some time learning and doing exams, so I cannot commit myself into this project fully during June. But I am sure I will be able to find time. After that, I will have 2 months holiday that I plan spending fully for the project.

GSoC : Port Rails Active Support to Seaside

Seaside Active Support is a set of libraries that are shared by all Seaside components. Active Support also extends some of Squeak base image classes in interesting and useful ways.

Seaside ActiveSupport is a port of Rails’ ActiveSupport library. Includes sync with the Chronos-ST library.

Rails ActiveSupport is the unsung hero of Rails. Much of what makes Rails code beautiful and powerful is implemented in ActiveSupport

Active Support is a collection of utility classes and standard library extensions that will be useful for Seaside developers. All the additions will be implement in a bundle that make Seaside code a step closer to natural language. Active Support gives us common way to solve common problems. It’s contextual standardization.

The main idea behind the active support api desing is to remain close to natural language. The minimize the learning curve.

Some examples :

“Peanut Butter” starts_with ‘Peanut’ // => True
“1985-03-13” toTime // => Wed Mar 13 00:00:00 UTC 1985
2 days ago from_now // => Sun Mar 13 00:34:55 -0800 2007
Time.days_in_month(2) // => 28
Time.now + 3.days + 12.hours

Set of new features :

* Enumerations and Arrays
– Keys
– diff
– reverseMerge
– classMethods
– date
– sum
– to_s_db :

* String Extensions
– StartsEndWith
– conversion
– iterators
– access

* Extensions to Numbers
– date
– EvenOdd

* Time and Date Extensions using Chronos-ST library
– calculation

* Extension to Smalltalk Symbols

=== Development plan : ===

The methodology will be Test driven development.

0) before the project : learn Squeak idiomatics.

1) Identify an external using the Seaside and the Squeak mailing list and the Active Supports Rails docuemtation. And document their behavior. (Using Sunit) (1st week)

2) Discuss the pros and cons of the different techniches (1st week) –
– A set of wrapper class
– Meta programming
– Extends methods

2) Enumerations and Arrays (2nd week)

3) String Extensions (3rd week)

4) Extensions to Numbers (4th week)

5) Time and Date Extensions, integrate Chronos-st (6th week)

6) Extension to Smalltalk Symbols (7th weeek)

=== Benefits to the Community ===

Having a package that simplifies the creation of Seaside-based web applications will help lower the barriers to entry for new Seaside developers and will be helpful in advertising Seaside and Squeak. It may also highlight possible areas of improvement for Seaside and Squeak.

Seaside Active support can bee, also useful, for Squeak developer that works out of Seaside.

=== Related frameworks : ===

* Chronos-ST library.

=== About me: ===

…….=== Motivation and interests: ===

Why I want to take part in it… I’ll be honest. I saw Seaside at the first time, when I read a post ‘on smalltalk blog’ comparing Rails vs Seaside a month ago. I was surprise about this new way to develop web application. And I liked it.

In my first year in the university I have gone to a ground OOP course using Smalltalk.

So, I think, I can do this task.

=== Available time: ===

GSoC 2007 : Ruby Code Browser.

molerubybrowser.pdf

[update] : I update the proposal, in order to apply again this year.

Ruby developers use intensely metaprogramming techniques, to create domain specific languages, to develop frameworks or to do a little bit of ruby magic. The ruby browser describe in this paper is a tool that help developers to inspect their classes

The goal of this projects is create an interactive graphical user interface of the irb-console with some extras features that allow a easy way to inspect (run-time introspection) the state of the objects.

The projects don’t pretend replace the irb console, the goal is integrate it in a graphical enhancement environment.

The ruby browser is directly inspired on the Squeak Browser, a graphical interface that allow to navigate throw all the classes and objects inside of the Squeak virtual machine.

When I’m writing a program in Smalltalk, I start a Workspace. Type in some code and evaluate it and open it up in an Inspector. As the program grows, I start refactoring the code in the Workspace into classes and inspecting it. At this point, I have an inspector open on some object. I can go in and modify or add methods in the class and evaluate them in the Inspector. I can open up inspectors on the results of those method calls, and so on… Is the same as we can do in Ruby with the irb with a non graphical, non intuitive console.

=== Functionality : ===

The ruby browser main features are :

——- Image paradigm
* Serializing the objects.
* Replicate the load “image” concept,
* Replicate the Save “image” concept.

——- Introspection
* Show all the classes already loaded in the console.
* Navigate throw the classes or modules.
* Add/remove methods and attributes to a class on the fly.
* Track the list of instances of a class
* View the list method of a live object.
* View the code of a method from a live object.
* Inspect an instance state.
* Show the hierarchy of class.

——- Evaluation
* evaluate code in a irb integrated console

=== Benefits to the Community ===

Static vs. Dynamic is missing some points. One of those points is interactivity. If we can inspect faster and easiest our code, we can interact and modify the objects and their definitions at runtime you gain a huge productivity boost.

Also whit a GUI enhancement irb console reduce the learn curve, for those who already don’t know object oriented programming. Thy can have a graphical representation of the object that they created in the console.

=== Development plan ===
….

=== Related gems : ===

* Ruby2ruby : ruby2ruby

=== About me: ===
…..

=== Available time: ===
…..

=== References : ===
http://www.notarianni.org/index.php/2005/09/17/object_orientation_enlightenment

GSoC 2007 : Cover the core of Ruby with RSpec

There are a number of Ruby implementations available today. The “standard” implementation is the original C-language-based implementation, written by Yukihiro Matsumoto, and now maintained by him and a number of contributors. In the last year, emerge different Ruby Virtual Machine (VM), YARV, Rubinius, JRuby, Gardens Point Ruby .NET, XRuby or cardinal are some good examples among others [1]. The goal of this proposal is create a common set of specification (using rspec) for the Ruby core, that verify the correct and same behavior of the different virtual machines and implementation. I would like the specs be usable for any virtual machine implementation or implementation.

The goal in writing a spec is to describe the expected behavior from the objects. Each specification should describe one facet of the behavior. Specs should prefer clarity and understanding over any other principle.

This projects do not start from the scratch, there is a important code base from the rubinius project that i could reuse. All the code that i develop will be directly compatible with the rspec code base of rubinius.

Test Driven Development (TDD) has you define the behavior of your system by writing small tests that precisely define some small piece of your system’s behavior. Then you implement that behavior.

* language is for specs that describe language-level constructs.
* core is for specs for any of the built-in classes in Ruby. These are documented at http://ruby-doc.org/core.

I have wrote the first time about this a in the ruby-talk mailing list. Looking for some feedback from the community.

=== The ruby core set : ===

* language : assignament, class, expression, method, operators, variables. exception.

* core library : array, proc, bignum, hash, range, binding, integer, regexp, class, io, signal, comparable, kernel , sprintf, marshal, string,dir, matchdata, struct, enumerable, math, symbol, errno, method, threadgroup, exception, module, thread, false, nil, time, file, numeric , true, objectspace, unboundmethod, fixnum, object, float, process.

* core/literals :numbers, string, block, hash, regexp, symbol.

=== Benefits to the Community ===

The goal would be to have a single specification that different ruby implementations can check against it. If the community have a well defined and reusable specification to check against it.

I also think that this project could provide great value for the implementors of other ruby implementations – having a single source against which all rubies can be verified.

=== Development plan ===

0) Before start the projects. Improve my skills reading the rspec mailing list. Read specs code form open source projects that already use rspec.

1) Identify/define the core in the Ruby implementation. And document their behavior.
– Discuss in each vm or implementation mailing list, what primitives, structures and libraries must been in the core of ruby.
– Discuss in the ruby-core mailing list the correct behavior.

2) Extract the initial code from the rubinius rspec code base.

3) Create a easy rake task to develop that allow one command testing.

3) Write the rspec for language.

4) Write specs for core/literals.

5) Write spec for the rest of the core.

6) Write documentation.

=== Related frameworks : ===

* Rspec
* Rubinius rspec code base.

=== About me: ===

I am 28 y.o., and I am 5th year student of Computer Science at Universidad de Granada, Spain. I’ll graduate in about 9 month. My interests are virtual machines, web technologies, object-oriented systems, functional languages and many other things.

I work in software company in Hamburg, Germany. My current duty is Ruby/Rails development. My graduate work in university is dedicated to applying Latent Semantic Indexing to natural languages processing.

I also have extensive experience in the Linux-Tomcat-Java-Struts architecture.

My relevant skills include proficiency in C, Java, Lisp, Ruby the standard GNU development tools (gcc, automake, etc.), Java tools (Xdoclet, ant, maven), CVS/SVN, and a host of other smaller languages and tools. I’ve been involved in the open source community for a while. I help to build and configurate http://javahispano.net Gforge (sourceforge) site for the Java spanish spoken community.

I’ve been working with a rspec last month, to test the core of the application of my employer.

=== Motivation and interests: ===

I have been involved in language design and in the implementation of a virtual machine for acadimic propose. I think with this project i obtain a more deeply knowledge about the conceptual design of real language.

So, I think, I can do this task.

=== Available time: ===

In the beginning of the project (to the end of June), I will be somewhat limited by school – our semester ends by the end of May, followed by one month reserved for exams. During that time, I will spend some time learning and doing exams, so I cannot commit myself into this project fully during June. But I am sure I will be able to find time. After that, I will have 2 months holiday that I plan spending fully for the project.

Reference :

1 : http://headius.com/rubyspec/index.php/Ruby_Implementations
2 : http://eigenclass.org/hiki.rb?ruby+internals+guide