SoC March 2007

soc@lists.squeakfoundation.org

28 participants
67 discussions

Who chooses students and projects?
by Damien Cassou 20 Mar '07

20 Mar '07

Hi, after having read the FAQ (http://code.google.com/support/bin/topic.py?topic=10442), I'm still not sure how students are choosen and how many projects are affected to squeak. Here is what I think: - the mentoring organization gives a mark to each student proposal - google review the marks and give a still undefined number of projects to squeak associated to one student. Am I right ? Can somebody explain us? -- Damien Cassou

4 7

Project proposal: Improving the testing workflow
by Damien Cassou 20 Mar '07

20 Mar '07

Hi, I would like to propose the following project for the Google Summer of Code. Can you please review it and give me feedback? Unit testing in Squeak Problematic ----------- SUnit has some important limitations like: - When a method is changed it is impossible to know which tests have to be run. All tests must be launched. - It is impossible to know if a method validate its tests or not. The developer must launch all tests and analyze the result. - The developer never knows if a method or a class is tested or not. - The framework has no Test entity. Thus, it's impossible to store its state for example (passing or failing). Current graphical interfaces have limitations too: - They never tell you what are the tests for the selected method. - They force you to create a TestCase class and browse to it when you want to write a test. - They do not help you running the tests often. Often, graphical interfaces use naming conventions to help you write tests. This is not a good solution and this does not allow for a lot of features. Problems to solve ----------------- - Linkage: it should be possible to know what tests must be run when a method is modified. This should not be annoying for the developer (no message box for example). The tests must NOT be run automatically. - Grouping: it should be possible to group the tests according to their meaning. For example, a developer should be able to group the networking tests or the database tests. Moreover, an automatic categorization can also be done: all failing tests, tests written by a given developer... - Launching: it should be possible to run a test or a test group rapidly and to see the result immediately. - Duration: an approximate duration of the selected test or group should be displayed in order to plan the test launching. - Model and test state: the graphical interface must display the model and test state (failing or passing) even without a specific request from the user. - Storage: the system must be able to save the links between the model and its tests so that developers of a same team can share information. Solution -------- In summer 2006, Karsten Kusche and I developed Dakar Testing to solve this problems. The work was appreciated and nominated at the ESUG Innovation Awards 2006 (http://www.esug.org/conferences/14thinternationalsmalltalkconference2006/in…). However, it has been done in Visual Works, it was a prototype changed a lot of time and the graphical interface was not portable at all. Some links about our previous work: - ESUG innovation award submission: http://damien.cassou.free.fr/stage_2006/esug06_inno_aw_dakartesting.pdf - A presentation made for ESUG: http://damien.cassou.free.fr/stage_2006/presentation/esug_presentation2.pdf - A French report of my work: http://damien.cassou.free.fr/stage_2006/rapport_stage_2006/main.pdf Proposed work ------------- I propose for this Google Summer of Code to rewrite Dakar Testing from scratch in Squeak and on top of the OmniBrowser framework. Related work ------------ Dakar Testing will be the base for this work. However, Stefan Reichhart work will be used too: http://smallwiki.unibe.ch/stefanreichhart/ Benefits for the community -------------------------- I think the current unit-testing workflow is to slow. It takes time to go from one browser to another, to search for a tests that verify a given method... Not having basic testing information like test state, test duration and associations is also a problem. In my opinion, a better framework and a better GUI will be a benefice for everybody: developers will write more tests and run them more often and users will get stabler systems. Development plan ---------------- End of June: the new framework will be finished and thoroughly tested End of July: the browser will have basic features, a new pane... End of August: every ideas will be implemented, a testing report tool to get global testing information will be finished -- Damien Cassou

3 4

Project proposal: Developing a package model
by Damien Cassou 20 Mar '07

20 Mar '07

Hi, I would like to propose the following project for the Google Summer of Code. Can you please review it and give me feedback? Developing a package model Squeak, as well as Visual Works, was not historically designed to be package-aware. It was designed with classes in mind and packages were added later as a new layer. This resulted in the following shortcomings: - No Package entity, instead there are strings. - No meta information for packages (comments will be really useful for example). - No simple API to access package content (class definitions, class extensions...). - No way to add instances variables to classes outside of the defining package. - No dependency mechanism which leads to very difficult deployment problems. - Each tool redefining the notion of package: browsers, SqueakMap, Monticello, Universes... - No refactoring support (renaming, moving a definition from a package to another...). The aim of this project will be to: - Create a new extensible model which contains meta information for packages. Each package will be able to define dependencies, recommended packages, comments... Each package will contain a set of class definitions, class extensions and class modifications. - Improve the current tools to support the new model. Identified risks ---------------- I will have to take care of not changing everything at once. The problem will be to devise a solution that can be implemented and released slowly. If this is not done correctly, the system will be too difficult to integrate into Squeak. The tools must be modified the right way to keep backward compatibility. Proposed development plan ------------------------- During all the project, I will take care of informing the community and asking for its wishes and feedback. I plan to release often and test a lot. Here is a possible development plan to realize this project: - Study SqueakMap, Monticello, PackageInfo and Alexandre Bergel work (http://wiki.squeak.org/squeak/5613) - Establish a model - Invent and implement a way to port current categories to the new package model - Change OmniBrowser Standard to support the new model - Enhance the packaging tools Benefits for the community -------------------------- The Squeak community really needs a packaging system. Tools should stop implementing things that must be in the system. Once Squeak will have a new packaging system, tools will be simpler, smaller and then will contain less bugs and more features. This system will help maintainers and will allow for a more modular Squeak. -- Damien Cassou

2 1

Meta remark
by stéphane ducasse 20 Mar '07

20 Mar '07

Hi I was thinking that the Soc subjects tries to really improve the situation of Squeak and that we pay attention to avoid projects that would be more research projects (I have plenty of them in my head). I did not check all the projects so far. Just the last email of matthew made me thought Mathew could your project be on improving the Squeak debugger instead of creating a new one? We spent quite some times with marcus and this is not easy (may be we were stupid and took the problems in the wrong way). So this is important as a mentor that you are already advanced and solid in the topic you propose and as far as I see in Peek this is not clear. At least our experience with events for debugging was that you have to be quite humble. But having a debugger that is at least as good as the one of VW would be good. I know that mathieu and damien were working on some extensions. For me if at the end of the summer our tools are better then I would be more than happy. Stef

2 1

Summer of Code: only 5 days left for the student applications
by Giovanni Corriga 19 Mar '07

19 Mar '07

Hi all, this is a friendly reminder to all the students interested in applying for the Google Summer of Code program. Remember that the deadline is Saturday 24th, 23:59 PST. This gives you a little more than 5 and 1/2 days for submitting your application. Giovanni

1 0

[Application] Peek viewer/debugger
by Matthew Fulmer 19 Mar '07

19 Mar '07

I put my application on the Swiki at: http://wiki.squeak.org/squeak/5965 I also included it below (in Swiki syntax). I will submit it to Google soon: ! Project Peek is an experimental viewing and debugging framework that attempts to generalize and extend the usefulness of the Smalltalk inspector and debugger tools. At the core of Peek is the ability to simulate and examine selected aspects of selected objects. This simulator will be based on the current Smalltalk debugger, but should handle arbitrary threads of execution. The key difference between the Squeak debugger and Peek will be that Peek is more reactive, transparent, and selective than the current tools: - transparent to the user: The user will enter a query into peek, and the system will continue running, and peek will examine existing and new objects that satisfy the query. The user does not need to manually open inspectors on certain objects; peek should do that for them. - reactive: When a message is sent anywhere in the system to an object that peek is watching, peek will intercept that message and begin simulating it and showing the user exactly what is being done internally. The user does not need to actively change the code by inserting self halt in a suspect method; instead, she can let peek reactively intercept messages to the object, then view what happens to them, either in slowed-down time, or in user time (aka single-stepping). When the user is no longer interested, he can disable the peek interception, and the system will run at normal speed. - selective: The user may not be interested in all properties of an object, or all messages sent to an object. The user will be able to filter out objects and messages she is not interested in in order to cut down on visual noise. Also, the user may not be interested in messages sent from the focus objects to the outside world; these messages can be sent without peek watching them and the user seeing them. This is the difference between "into" (send) and "over" (step) in the current squeak debugger. This could all be done using a textual interface similar to the existing Squeak tools, but peek will (eventually) use a more graphical interface, where each object (including messages) is represented by an on-screen icon, and pointers by a line between objects. This creates an active graph representing the interesting parts of the system. ! Schedule This is a rather large project, involving a near-realtime query system for the Squeak object memory, a selective debugger, and a new user interface. Therefore, I will focus on getting a useful product out fast, and save the killer UI for later. How can I do this? 1. A more fine-grained event producer Using the existing Debugger, I can create a framework that transforms very mundane Smalltalk events, such as a message sends, object creation, and garbage collection, into OBAnnouncements. This will require a bit of experimentation, as it will be all too easy to get into an infinite announcement loop with this. Also, it will have to be quite limited in focus, since the system would slow to a crawl if, for every message send, an announcement was created, broadcast, and processed. However, such a framework, once working, would allow anything imaginable to be debugged, logged, or whatnot, in a much more uniform manner than is possible with the current thread-oriented debugger. 2. A tool to use it. The most trivial use of such a framework would be a simple message logger. This will be the first tool created using the framework, as well as the method used to test the framework. The next step would be to recreate the Squeak debugger, inspector, and object explorer using this framework. Finally, I would tie it together into a message-logging debugger that will have a useful interface for creating event queries, as well as some useful pre-built queries. ! About Me My name is *Matthew Fulmer*, and I am a 21-year old college student at Arizona State University in Phoenix, USA. I am double-majoring in Computer Systems Engineering and Electrical Engineering, and will receive those two Bachelor's Degrees next December. I have been somewhat successfully organizing a documentation team to improve the state of Squeak documentation. We have focused almost exclusively on creating and categorizing Squeak tutorials. Although I have little experience in them, I am very interested in user interfaces and compilers. Due to my research at ASU, I have some experience in pattern recognition and signal processing. I created this project partly as an answer to the desire for a more introspective inspector, as expressed in the *Viewpoints NSF grant>http://www.viewpointsresearch.org/pdf/NSFproposal.pdf*. Although Smalltalk is better than most systems, it is still harder than necessary to examine and log the history of an object. I want to be able to see more deeply into the worlds we create inside the computer, and that is why I proposed the Peek framework. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

3 3

Let's start reviewing the proposals.
by Giovanni Corriga 19 Mar '07

19 Mar '07

Hi all, There are some proposal already, so we should start reviewing them. Here's a guide to how to use Google's web app (for mentors): http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-… Please note, and I have to stress this one, that *we should not score the proposals yet*, so we should just stick to reviews and comments for now. Once submissions are closed, all the mentors could meet in IRC for a collective review session. It's not really necessary, but it could be productive. Ciao, Giovanni

3 2

Student Applications
by bryce＠kampjes.demon.co.uk 19 Mar '07

19 Mar '07

It really helps if your application looks at what is required for the project and also provides some detail on why you have, or could quickly learn, the required skills. This really matters if you're not in the same town as the mentors or haven't been visible inside the Squeak community. If you don't personally know the mentors or haven't got a record of contributions unfortunately we'll have to judge on what you tell us rather than what you can actually do. It helps if you can provide some verifiable proof of what you're saying. If it's an Exupery project and you're new to Smalltalk some low-level code is useful even if it's not directly relevant. Any involvement with open source development would help. If you've done something for another project tell us, and provide links to some discussions in the mailing list you were involved with. Being able to work via electronic communication will be essential, involvement elsewhere demonstrates this. The key skills for Exupery are: * Test Driven Development - tests are a required part of the process * Smalltalk development (Exupery is written in Smalltalk) * Assembly, and possibly machine code (it's what's generated) * Debugging C and assembly * Slang (the language the VM is written in) * Smalltalk implementation I doubt that any student will have all of them. Learning is a key goal for this kind of project. The tests will help, we'll plan all Exupery projects so that they're deliverable in small pieces test by test. Also Squeak doesn't keep it's source in files. If you're going to suggest what resources you're going to use just say you'll use the standard community tools. SourceForge is not a good choice for Squeak version control. Bryce

1 0

Re: [Newbies] Re: Squeak - for a different Summer of Code!
by Giovanni Corriga 18 Mar '07

18 Mar '07

Il giorno dom, 18/03/2007 alle 20.46 +0100, Serge Stinckwich ha scritto: > > Some of my students are interested by some of the Squeak SOC project. > Do they need to directly contact the mentor ? Have them send their proposals to soc(a)lists.squeakfoundation.org , too. This way, students and mentors can start refining the proposals. Anyway, they should start submitting the application to Google; there's only six days until the submission deadline. Giovanni

1 0

Summer of code Application
by Pedro Del Gallego 18 Mar '07

18 Mar '07

Hi, I'm a student and i want apply to the Summer of code. I wrote an application. It would be nice to have some feedback from the community. Before i post in the official google webapp. Any comment or advices will be really appreciate I also attachment a copy in txt with this mail. Thanks. ---------------------------------------------------------------------------------------------------------------- Application ---------------------------------------------------------------------------------------------------------------- Name : Seaside and Sails URL idea : http://wiki.squeak.org/squeak/5952 Student : Pedro Del Gallego Vida. ----------------------------------- Seaside and Sails ----------------------------------- ========= Abstract : ========= This project will provide, by the end of the summer, a tool that bring a structure generation to Seaside. This piece of software enhance Seaside with generetors 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 The approach is the Structure generation vs the code generation. * one-step creation of components, 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 mehotd, - The database scheme * Easy creation of tests: using Sunit - unit tests - functional tests - performance tests * To easily connect to persistence layers, create the basic features for CRUD operation in the model. (probably using glorp) - basic find behavior. * 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 ========= 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 (·rd week) 4 Integrate Sunit with the Kernel framework to generate 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 ========= ---| |-- 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. Currently I combine my education in UGR with work in software company in Hamburg, Germany. My current duty is Ruby/Rails development. My graduate work in university is dedicated to applying Latente Semantic Indexing to natural languages processing. I also have extensive experience in the Linux-Tomcat-Java-Struts architecture, having written code for one of the biggest world car manufacturers , among other projects. 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. 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. Maybe, I will go for one week vacation, but I assume I would work on this project even on this vacation, so it would not interfere with project development much. -- ------------------------------------- Pedro Del Gallego Email : pedro.delgallego(a)gmail.com

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

SoC March 2007