The proposals tend to fall into several categories, and there are some proposals that are very similar. There are in fact five proposals (from four people) that propose adding a module to Seaside to make it like Ruby on Rails. I think that this topic has the biggest potential to make an impact. Seaside is powerful, but it is not easy to learn for people who do not already know Smalltalk well. If there was a "Seaside on Sails" that was as easy to learn as Ruby on Rails, Seaside (and Squeak) could really take off.
It looks to me like these proposals are being overlooked by the mentors, perhaps because none of us are web developers or have used Ruby on Rails. I haven't use it either, but I have read the documentation and I can see why it has made such a big impact. I'd love to see Squeak capture some of that market. So, I urge mentors to read these proposals and to vote on them.
There are a lot of tool-oriented proposals. I tend to like them, but other mentors do, too, so I won't say much about them.
There are a couple of proposals to make something like "rake" for Squeak. I don't understand these. I've built several large systems in Smalltalk and never felt the need for make. I don't know rake, and when I read the proposals I feel like I am missing something. Could someone explain why we need something like this?
-Ralph
Hi Ralph,
On Mar 29, 2007, at 9:17 AM, Ralph Johnson wrote:
The proposals tend to fall into several categories, and there are some proposals that are very similar. There are in fact five proposals (from four people) that propose adding a module to Seaside to make it like Ruby on Rails. I think that this topic has the biggest potential to make an impact. Seaside is powerful, but it is not easy to learn for people who do not already know Smalltalk well. If there was a "Seaside on Sails" that was as easy to learn as Ruby on Rails, Seaside (and Squeak) could really take off.
It looks to me like these proposals are being overlooked by the mentors, perhaps because none of us are web developers or have used Ruby on Rails. I haven't use it either, but I have read the documentation and I can see why it has made such a big impact. I'd love to see Squeak capture some of that market. So, I urge mentors to read these proposals and to vote on them.
I am familiar with Ruby on Rails (I used it to mock up a couple of social-sharing microcontent sites with tagging and AJAX-y goodness), but I'm not really giving them intense attention, simply because this is a very obvious set of improvements to make, and RoR has enough documentation that it's been enough to point students to the Seaside components and documented information (scattered in blog posts and mailing list comments, mostly) corresponding with particular features of Rails.
The real issue (if there really is one) is that the mentors aren't Seaside experts who've been using it in production for a long time. Basically half of those guys are on the DabbleDB project, and then there's Todd working with an old client of theirs, and the NetStyles.ch group. Seaside doesn't feel like something we have a strong link to its pulse, the direction it's going.
There are a lot of tool-oriented proposals. I tend to like them, but other mentors do, too, so I won't say much about them.
Yes, they're obvious as well, and the only main desire is that the tools for Squeak start to really integrate to the point that we won't have a reason to fork on basic functionality again.
There are a couple of proposals to make something like "rake" for Squeak. I don't understand these. I've built several large systems in Smalltalk and never felt the need for make. I don't know rake, and when I read the proposals I feel like I am missing something. Could someone explain why we need something like this?
I came up with this idea, and it does require some justification, since Squeak is not file-based and code is not "built" but either installed or not.
Martin Fowler explained the essence of Rake pretty well here: http://www.martinfowler.com/articles/rake.html
To summarize, Sake would be an object-oriented domain language for tasks and dependencies, minus the script-oriented, life-within-one- invocation nature of Rake itself. Rake is more expressive and easier to work with than either Make or Ant (or SCons, python's dialect), on its own.
If we had Sake, then building Squeak VMs might be more easily done in it rather than Makefiles. This might offer a lot of integration benefits. The other issue is that building Squeak systems (images) declaratively using the Installer tool could be entirely automated without having to write custom procedural scripts. But mainly, the idea is that you could place a simple UI on this language which would show you the tasks and dependencies and even, say, give simple color- coded indication of which tasks have fallen out of date due to external changes or code changes or whatever.
It's entirely possible that class-side #initialize methods could benefit from this, but that's relatively debatable. I've seen enough #initialize methods and preambles and postscripts to see a dependency- tracking pattern in them, and a DSL for it might be a reasonable solution.
The configuration issue, providing a flexible language for specifying, detecting, and adjusting/merging configurations, would be a big benefit above the Preferences system that Squeak currently has, but I am unsure if it makes sense yet to compare these two things, and think a student might be able to explore this reasonably well.
The benefits might be vague and unknown right now, but Sake would be unprecedented as a kind of entity (persistent, object-oriented build system within a live environment), so I can't just assert its usefulness without having the legwork done to make it available. I think it would at least be worth an undergraduate paper publication.
-- -Brian http://briantrice.com
I like sake and this is not a build for Smalltalk. I asked lukas to be part of the mentors for the web related topics.
Stef
On 29 mars 07, at 20:00, Brian Rice wrote:
Hi Ralph,
On Mar 29, 2007, at 9:17 AM, Ralph Johnson wrote:
The proposals tend to fall into several categories, and there are some proposals that are very similar. There are in fact five proposals (from four people) that propose adding a module to Seaside to make it like Ruby on Rails. I think that this topic has the biggest potential to make an impact. Seaside is powerful, but it is not easy to learn for people who do not already know Smalltalk well. If there was a "Seaside on Sails" that was as easy to learn as Ruby on Rails, Seaside (and Squeak) could really take off.
It looks to me like these proposals are being overlooked by the mentors, perhaps because none of us are web developers or have used Ruby on Rails. I haven't use it either, but I have read the documentation and I can see why it has made such a big impact. I'd love to see Squeak capture some of that market. So, I urge mentors to read these proposals and to vote on them.
I am familiar with Ruby on Rails (I used it to mock up a couple of social-sharing microcontent sites with tagging and AJAX-y goodness), but I'm not really giving them intense attention, simply because this is a very obvious set of improvements to make, and RoR has enough documentation that it's been enough to point students to the Seaside components and documented information (scattered in blog posts and mailing list comments, mostly) corresponding with particular features of Rails.
The real issue (if there really is one) is that the mentors aren't Seaside experts who've been using it in production for a long time. Basically half of those guys are on the DabbleDB project, and then there's Todd working with an old client of theirs, and the NetStyles.ch group. Seaside doesn't feel like something we have a strong link to its pulse, the direction it's going.
There are a lot of tool-oriented proposals. I tend to like them, but other mentors do, too, so I won't say much about them.
Yes, they're obvious as well, and the only main desire is that the tools for Squeak start to really integrate to the point that we won't have a reason to fork on basic functionality again.
There are a couple of proposals to make something like "rake" for Squeak. I don't understand these. I've built several large systems in Smalltalk and never felt the need for make. I don't know rake, and when I read the proposals I feel like I am missing something. Could someone explain why we need something like this?
I came up with this idea, and it does require some justification, since Squeak is not file-based and code is not "built" but either installed or not.
Martin Fowler explained the essence of Rake pretty well here: http://www.martinfowler.com/articles/rake.html
To summarize, Sake would be an object-oriented domain language for tasks and dependencies, minus the script-oriented, life-within-one- invocation nature of Rake itself. Rake is more expressive and easier to work with than either Make or Ant (or SCons, python's dialect), on its own.
If we had Sake, then building Squeak VMs might be more easily done in it rather than Makefiles. This might offer a lot of integration benefits. The other issue is that building Squeak systems (images) declaratively using the Installer tool could be entirely automated without having to write custom procedural scripts. But mainly, the idea is that you could place a simple UI on this language which would show you the tasks and dependencies and even, say, give simple color-coded indication of which tasks have fallen out of date due to external changes or code changes or whatever.
It's entirely possible that class-side #initialize methods could benefit from this, but that's relatively debatable. I've seen enough #initialize methods and preambles and postscripts to see a dependency-tracking pattern in them, and a DSL for it might be a reasonable solution.
The configuration issue, providing a flexible language for specifying, detecting, and adjusting/merging configurations, would be a big benefit above the Preferences system that Squeak currently has, but I am unsure if it makes sense yet to compare these two things, and think a student might be able to explore this reasonably well.
The benefits might be vague and unknown right now, but Sake would be unprecedented as a kind of entity (persistent, object-oriented build system within a live environment), so I can't just assert its usefulness without having the legwork done to make it available. I think it would at least be worth an undergraduate paper publication.
-- -Brian http://briantrice.com
Soc mailing list Soc@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/soc
I have read the Ruby on Rails book in a study group and built a trivial application with it just to see. I suspect I still have it installed on this machine somewhere or other. I also work in Seaside every day and have experience with other frameworks like WebObjects and the whole J2EE nightmare.
So I think I have a pretty good idea where Seaside falls short - mostly it is on the persistence layer.
Where can I access the proposals?
-Todd Blanchard
On Mar 29, 2007, at 9:17 AM, Ralph Johnson wrote:
The proposals tend to fall into several categories, and there are some proposals that are very similar. There are in fact five proposals (from four people) that propose adding a module to Seaside to make it like Ruby on Rails. I think that this topic has the biggest potential to make an impact. Seaside is powerful, but it is not easy to learn for people who do not already know Smalltalk well. If there was a "Seaside on Sails" that was as easy to learn as Ruby on Rails, Seaside (and Squeak) could really take off.
It looks to me like these proposals are being overlooked by the mentors, perhaps because none of us are web developers or have used Ruby on Rails. I haven't use it either, but I have read the documentation and I can see why it has made such a big impact. I'd love to see Squeak capture some of that market. So, I urge mentors to read these proposals and to vote on them.
There are a lot of tool-oriented proposals. I tend to like them, but other mentors do, too, so I won't say much about them.
There are a couple of proposals to make something like "rake" for Squeak. I don't understand these. I've built several large systems in Smalltalk and never felt the need for make. I don't know rake, and when I read the proposals I feel like I am missing something. Could someone explain why we need something like this?
-Ralph _______________________________________________ Soc mailing list Soc@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/soc
Nevermind - I've figured out how to access the (truly awful constantly timing out) application.
On Mar 29, 2007, at 6:44 PM, Todd Blanchard wrote:
I have read the Ruby on Rails book in a study group and built a trivial application with it just to see. I suspect I still have it installed on this machine somewhere or other. I also work in Seaside every day and have experience with other frameworks like WebObjects and the whole J2EE nightmare.
So I think I have a pretty good idea where Seaside falls short - mostly it is on the persistence layer.
Where can I access the proposals?
-Todd Blanchard
On Mar 29, 2007, at 9:17 AM, Ralph Johnson wrote:
The proposals tend to fall into several categories, and there are some proposals that are very similar. There are in fact five proposals (from four people) that propose adding a module to Seaside to make it like Ruby on Rails. I think that this topic has the biggest potential to make an impact. Seaside is powerful, but it is not easy to learn for people who do not already know Smalltalk well. If there was a "Seaside on Sails" that was as easy to learn as Ruby on Rails, Seaside (and Squeak) could really take off.
It looks to me like these proposals are being overlooked by the mentors, perhaps because none of us are web developers or have used Ruby on Rails. I haven't use it either, but I have read the documentation and I can see why it has made such a big impact. I'd love to see Squeak capture some of that market. So, I urge mentors to read these proposals and to vote on them.
There are a lot of tool-oriented proposals. I tend to like them, but other mentors do, too, so I won't say much about them.
There are a couple of proposals to make something like "rake" for Squeak. I don't understand these. I've built several large systems in Smalltalk and never felt the need for make. I don't know rake, and when I read the proposals I feel like I am missing something. Could someone explain why we need something like this?
-Ralph _______________________________________________ Soc mailing list Soc@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/soc
Soc mailing list Soc@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/soc
Il giorno gio, 29/03/2007 alle 11.17 -0500, Ralph Johnson ha scritto:
The proposals tend to fall into several categories, and there are some proposals that are very similar. There are in fact five proposals (from four people) that propose adding a module to Seaside to make it like Ruby on Rails. I think that this topic has the biggest potential to make an impact. Seaside is powerful, but it is not easy to learn for people who do not already know Smalltalk well. If there was a "Seaside on Sails" that was as easy to learn as Ruby on Rails, Seaside (and Squeak) could really take off.
It looks to me like these proposals are being overlooked by the mentors, perhaps because none of us are web developers or have used Ruby on Rails. I haven't use it either, but I have read the documentation and I can see why it has made such a big impact. I'd love to see Squeak capture some of that market. So, I urge mentors to read these proposals and to vote on them.
The Sails idea was proposed by Stef; I hijacked it and gave it a more detailed form. I have some experience with Rails, so I can be mentoring the students who apply for the Sails projects.
Giovanni
I'm getting the feeling from reading the comments on the proposals to build HTML viewer widgets that the other mentors don't quite understand the point of the project. Since I proposed it, allow me to explain.
I wrote a modern HTML/XHTML/CSS parser with associated DOM which can be found at: http://www.squeaksource.com/htmlcssparser
It is used to implement http://badpage.net - a web page standards checker. It produces an decorated DOM that models HTML/XHTML. The decorations are the CSS rules - it can match CSS selectors to DOM nodes.
So the really hard work of handling 'wild' HTML and CSS is done. All the project seeks to do is build renderer using a Morphic widget hierarchy that implements the CSS box model layout and visually represents the DOM.
There are probably adequate Morphic widgets already available to do most of this, I think a table widget might need to be implemented. The student will need to implement builder to build/configure the morphs.
Key skills are - builder pattern, GUI development experience (any GUI, really). Parsing is not necessary and we are not trying to build a whole browser.
-Todd Blanchard
So the really hard work of handling 'wild' HTML and CSS is done. All the project seeks to do is build renderer using a Morphic widget hierarchy that implements the CSS box model layout and visually represents the DOM.
I don't think it's a realistic project. Even if you have a ready-made css-annotated parse-tree the whole rendering thing is very non-trivial. Mozilla, Apple, Opera and Microsoft have spent thousands of man years into that, and all of these browsers have major flaws. This cannot just be the thing that they used the wrong language: also the Smalltalk WithStyle XHTML rendering engine and its predecessors are far from being perfect. I think that company also spent a significant amount of time and there are a lot of very smart people involved. This is nothing a student can do during a summer.
Just my cents, Lukas
We will have to agree to disagree - compared to building a good package system, I don't think it is significantly harder.
On Mar 30, 2007, at 2:54 PM, Lukas Renggli wrote:
So the really hard work of handling 'wild' HTML and CSS is done. All the project seeks to do is build renderer using a Morphic widget hierarchy that implements the CSS box model layout and visually represents the DOM.
I don't think it's a realistic project. Even if you have a ready-made css-annotated parse-tree the whole rendering thing is very non-trivial. Mozilla, Apple, Opera and Microsoft have spent thousands of man years into that, and all of these browsers have major flaws. This cannot just be the thing that they used the wrong language: also the Smalltalk WithStyle XHTML rendering engine and its predecessors are far from being perfect. I think that company also spent a significant amount of time and there are a lot of very smart people involved. This is nothing a student can do during a summer.
Just my cents, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Soc mailing list Soc@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/soc
We will have to agree to disagree - compared to building a good package system, I don't think it is significantly harder.
No problem. I owe you a drink when the rendering engine passes this test:
http://www.webstandards.org/action/acid2/guide/
On 31 mars 07, at 01:30, Todd Blanchard wrote:
We will have to agree to disagree - compared to building a good package system, I don't think it is significantly harder.
The point is to build on top of MC or MC2 (adding bytecode loading) :)
Stef
On Mar 30, 2007, at 2:54 PM, Lukas Renggli wrote:
So the really hard work of handling 'wild' HTML and CSS is done. All the project seeks to do is build renderer using a Morphic widget hierarchy that implements the CSS box model layout and visually represents the DOM.
I don't think it's a realistic project. Even if you have a ready-made css-annotated parse-tree the whole rendering thing is very non-trivial. Mozilla, Apple, Opera and Microsoft have spent thousands of man years into that, and all of these browsers have major flaws. This cannot just be the thing that they used the wrong language: also the Smalltalk WithStyle XHTML rendering engine and its predecessors are far from being perfect. I think that company also spent a significant amount of time and there are a lot of very smart people involved. This is nothing a student can do during a summer.
Just my cents, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Soc mailing list Soc@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/soc
Soc mailing list Soc@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/soc
Ok this is good that you explain it.
On 30 mars 07, at 22:19, Todd Blanchard wrote:
I'm getting the feeling from reading the comments on the proposals to build HTML viewer widgets that the other mentors don't quite understand the point of the project. Since I proposed it, allow me to explain.
I wrote a modern HTML/XHTML/CSS parser with associated DOM which can be found at: http://www.squeaksource.com/htmlcssparser
It is used to implement http://badpage.net - a web page standards checker. It produces an decorated DOM that models HTML/XHTML. The decorations are the CSS rules - it can match CSS selectors to DOM nodes.
So the really hard work of handling 'wild' HTML and CSS is done. All the project seeks to do is build renderer using a Morphic widget hierarchy that implements the CSS box model layout and visually represents the DOM.
There are probably adequate Morphic widgets already available to do most of this, I think a table widget might need to be implemented. The student will need to implement builder to build/configure the morphs.
Key skills are - builder pattern, GUI development experience (any GUI, really). Parsing is not necessary and we are not trying to build a whole browser.
-Todd Blanchard _______________________________________________ Soc mailing list Soc@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/soc
soc@lists.squeakfoundation.org
-
Brian Rice -
Giovanni Corriga -
Lukas Renggli -
Ralph Johnson -
stephane ducasse -
Todd Blanchard