- Esug-list - lists.esug.org

Re: [Esug-list] Few thoughts about Google Summer of Code

by mkobetic＠cincom.com

"Paolo Bonzini"<bonzini(a)gnu.org> wrote: > For the VCS, I've always been surprised there's no git or svn backend > for Monticello. It wouldn't seem _too_ hard to have a directory per > package and replace each .mcz file with a commit in that directory. > > Alternatively, there's actually very little GST-specific code in > http://github.com/timfel/gitocello (a Squeak+Monticello <-> GST+git > bridge), so if someone wants to play with it... I played with this back in 2000, when VW didn't have it's own VCS yet. Some might remember a project called CVST (http://cvstproj.sourceforge.net/) Ultimately I stopped working on it, because VW got Store, and Squeak got Monticello shortly after, and each of the dialect specific VCSs had some interesting features that CVS (back then) couldn't provide (not easily at least). The communities clearly valued the additional capabilities that their solutions provided. I tried to push CVST as a cross-dialect solution, but there seemed to be little interest in that. Another significant hurdle was that each dialect has it's own fileout format. CVST allowed using SIF as well for that reason, but that's foreign to every dialect. Would you be happy to commit your sources to git in SIF? Anyway, one aspect that I liked about CVST was that the image could be treated as a sort of "fancy editor" for the working copy of your code in the working directory, which might appeal to newcomers from other languages too. It's not tied to CVS in any way, you could use svn or git with it just as well (Here are slides that talk a bit more about how it worked http://www.slideshare.net/mkobetic/01-stscvst) It would require some update to plug into current packaging structures (e.g. packages in VW, it was integrated with parcels back then), but that wouldn't be difficult. Some level of dialect specific tool integration would be needed (I wrote some for VW, but those would mostly be replaced by rather simple RB extensions), overall I would expect it to be much work. What I wonder about though, if we did bring it up to date (or came up with something completely new), would people actually use it ? Because if most would still stick to their Store, Monticello X, Envy, etc, presumably because of some cool feature that they'd miss, the "yet another VCS" would be just a waste of time. But maybe times have changed and we, Smalltalkers, are more likely to accept something like svn or git even if we have to give up some of the niceties of our home-brew solutions.

Oct. 29, 2010

Re: [Esug-list] Few thoughts about Google Summer of Code

by Paolo Bonzini

On 10/29/2010 03:27 PM, Damien Pollet wrote: >>> But comparing to Ruby, there is no standard UI in Ruby and this >>> not really annoying for the people, because they deploy their >>> application on the web. > > Yes, but Ruby has really nice bindings to at least GTK and Cocoa. > Applications developed using that look just like their C / ObjC > counterparts, they do not pop an image window, etc They're not used very much though. I see more Shoes than GTK with Ruby I think. There's also a price to pay---GNU Smalltalk has nice GTK+ bindings, but when they crash in the bowels of GtkTreeModel you're left alone in gdb. :) Paolo

Oct. 29, 2010

Re: [Esug-list] Few thoughts about Google Summer of Code

by Georg Heeg

Actually SeaBreeze does exactly what you propose here. For details see seabreeze.heeg.de. It is a UI Editor and framework on top of Seaside. Georg Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812 Tel. +49-3496-214328, Fax +49-3496-214712 -----Ursprüngliche Nachricht----- Von: esug-list-bounces(a)lists.esug.org [mailto:esug-list-bounces@lists.esug.org] Im Auftrag von Frank Shearar Gesendet: Freitag, 29. Oktober 2010 11:52 An: ESUG Mailing list Betreff: Re: [Esug-list] Few thoughts about Google Summer of Code On Fri, Oct 29, 2010 at 10:17 AM, Graham McLeod <mcleod(a)iafrica.com> wrote: > Hi Dennis, Geert, Adres, Serge and other commenters.. > > Doing good UI's is still quite hard and labour intensive - Seaside > provides a great framework, but we are still working pretty much at > the level of HTML / CSS concepts. I would like to see a layer > describing logical data structures e.g. List, Tree, Matrix, Document > (sequenced set of objects), Model (spatially arranged and possibly > connected objects) and a visual editor (or very high level DSL) that > allows composition of these into user interfaces with a publish / > subscribe event model and choice of suitable controls and widgets > based upon the logical data type. (this one is probably a bit too big > for a GSOC but may be tackled in pieces. ) Squeak uses ToolBuilder to describe UI elements - lists, buttons, code panes, menus, and the like. Has anyone considered writing a SeasideToolBuilder to generate HTML/CSS? frank > Hope some of this makes sense. > Welcome feedback and comments. > Best regards, > > Graham > > Dennis Schetinin wrote: > > and observations and questions mostly inspired by GSoC Mentor > Summit > > Mentor Summit was a great event! I didn't expect it to be THIS :) Very > pleasant and very hard for me: so many people, language and culture > shock > :) Great experience for me personally. Thank ESUG for choosing and > sending me there. > Bad news: Smalltalk is not popular. Well, it's not that new actually, > we know it. But I didn't manage to fix it :) Seriously: actually, it > looks like everybody knows Smalltalk (they know it existed I mean; few > knows it still exists), but it is treated like a black and white movie. People say "wow! > it's cool" and go to see Avatar. :( So developers don't take Smalltalk > seriously. We (Smalltalkers) know it's a mistake. But we have to show > that for others. And I found myself unable to do that there. I found > language and, more likely, culture barrier is too big to overcome. I > didn't manage to set up a two-way communication with others. So I listened mostly. > And I've heard many interesting ideas apparently, organizational > ideas mostly. I need some time to process them. So, for now I'll just > outline some directions Did we summarize our GSoC results? I thought > I've missed them, but apparently we didn't do it. At least I found > only this page > http://code.google.com/p/google-summer-of-code-2010-esug/downloads/lis > t. I didn't care much before, but now I think it is very important to > look closer at the projects we did within GSoC, understand where we > succeeded; where we failed; did we benefit and could we get more; make > some plans for the future... etc. > I think we should pay more attention to GSoC. It is very important for > our small society. Of course, we can't be sure smalltalkers will be > invited again next year. (One of the things I tried to understand at > summit but still I don't: how does Google select mentor > organizations?) But this work will be very helpful, useful, advantageous what ever. > We should be more serious about monitoring and controlling our projects. > Since money are involved here, we have a right to. That's money from > Google, but still. I think it should be a bit different from the way > free projects are evolved within Smalltalk society. Since we have such > opportunity we have to benefit as much as we can. > Smalltalk gives me competitive advantages. For that matter I don't > want to > :) but now I understand even better: we have to promote Smalltalk. I > know everybody knows that, but I still want to state it once again. > And promoting is not only about advertising and praising. We should be > more open. We should find a way to start some cooperative projects > with other societies/languages. I don't know how to do it. And it's > extremely hard for me as I believe in Smalltalk superiority :) But > still we have if we don't want Smalltalk to die. In general, it looks > like making Smalltalk more open should be our priority, and this is > one of the few ways to enhance prestige of Smalltalk among developers. > > -- > Dennis Schetinin > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > _______________________________________________ Esug-list mailing list Esug-list(a)lists.esug.org http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Oct. 29, 2010

Re: [Esug-list] Few thoughts about Google Summer of Code

by Damien Pollet

On Oct 29, 2010, at 14:29, Davorin Rusevljan wrote: > On Fri, Oct 29, 2010 at 2:23 PM, Paolo Bonzini <bonzini(a)gnu.org> wrote: >> On 10/29/2010 02:12 PM, Geert Claes wrote: >>> Sounds very interesting, what would the main advantages be of using a GIT >>> backend? >> >> It is what you use for other assets. So the Monticello git-backed repo >> could be simply a subtree of the project-wide repo. > > There would be also one trivial, but possibly important social aspect. > Some Smalltalk projects might be hosted on GitHub, and become visible > to larger audience. ...and benefit from github's issue tracker, from a VCS that handles branches in a way that actually makes sense, from any continuous integration tool that you can trigger on post-commit hooks, and so on. The hard point is how to fit in the file-based crowd, without imposing too many idiosyncrasies, but without loosing the power of smalltalk-specific tools. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 29, 2010

Re: [Esug-list] Few thoughts about Google Summer of Code

by Damien Pollet

On Oct 29, 2010, at 12:19, Serge Stinckwich wrote: > But comparing to Ruby, there is no standard UI in Ruby and this not > really annoying for the people, because they deploy their application > on the web. Yes, but Ruby has really nice bindings to at least GTK and Cocoa. Applications developed using that look just like their C / ObjC counterparts, they do not pop an image window, etc -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 29, 2010

Re: [Esug-list] Few thoughts about Google Summer of Code

by Steven Kelly

Davorin Rusevljan wrote: > Steven Kelly <stevek(a)metacase.com> wrote: > > People choose a programming environment based on (most important > > first): > > > > 1) what everybody else is using > > 2) what seems familiar to them > > 3) what is cool > > 4) what is good > > IMHO there is one criteria that comes in front of those. First > environment needs to be able to produce cool results. If environment > can do some others can not, people will be using it even if it > requires use of line editor. So being able to produce cool aps is our > priority zero. To some extent that intersects with 3), and I'd include it in 4) too: what you can produce, and how productive you are in doing it. I stand by my claim that 1) and 2) are more important in achieving mass success. 4) just helps guarantee a long life. Mind you, 1) should be rephrased to "what everybody else seems to be using", and a big score on 3) can outweigh a smaller difference on 1) and 2) over time: your message will get media coverage and some evaluators, helping to address 2) and 1) bit by bit. Steve

Oct. 29, 2010

Re: [Esug-list] Few thoughts about Google Summer of Code

by Davorin Rusevljan

On Fri, Oct 29, 2010 at 2:23 PM, Paolo Bonzini <bonzini(a)gnu.org> wrote: > On 10/29/2010 02:12 PM, Geert Claes wrote: >> Sounds very interesting, what would the main advantages be of using a GIT >> backend? > > It is what you use for other assets. So the Monticello git-backed repo > could be simply a subtree of the project-wide repo. There would be also one trivial, but possibly important social aspect. Some Smalltalk projects might be hosted on GitHub, and become visible to larger audience. Davorin Rusevljan http://www.cloud208.com/

Oct. 29, 2010

Re: [Esug-list] Few thoughts about Google Summer of Code

by Davorin Rusevljan

On Fri, Oct 29, 2010 at 1:36 PM, Steven Kelly <stevek(a)metacase.com> wrote: > People choose a programming environment based on (most important first): > > 1) what everybody else is using > 2) what seems familiar to them > 3) what is cool > 4) what is good IMHO there is one criteria that comes in front of those. First environment needs to be able to produce cool results. If environment can do some others can not, people will be using it even if it requires use of line editor. So being able to produce cool aps is our priority zero. Davorin Rusevljan http://www.cloud208.com/

Oct. 29, 2010

Re: [Esug-list] Few thoughts about Google Summer of Code

by Paolo Bonzini

On 10/29/2010 02:12 PM, Geert Claes wrote: >> ... For the VCS, I've always been surprised there's no git or svn backend >> for Monticello. It wouldn't seem _too_ hard to have a directory per >> package and replace each .mcz file with a commit in that directory. >> >> Alternatively, there's actually very little GST-specific code in >> http://github.com/timfel/gitocello (a Squeak+Monticello<-> GST+git >> bridge), so if someone wants to play with it... > > Sounds very interesting, what would the main advantages be of using a GIT > backend? It is what you use for other assets. So the Monticello git-backed repo could be simply a subtree of the project-wide repo. Paolo

Oct. 29, 2010

Re: [Esug-list] Few thoughts about Google Summer of Code

by 'Markus Rips'

>Squeak uses ToolBuilder to describe UI elements - lists, buttons, code >panes, menus, and the like. Has anyone considered writing a >SeasideToolBuilder to generate HTML/CSS? > >frank Hi Frank seaBreeze is such a tool for seaside. If someone is interested, have a look at: http://seabreeze.heeg.de/ Markus ________________________________ Markus Rips * Senior Consultant / certified Scrum Master * markus.rips(a)heeg.de phone: +49 231 9 75 99 24 * fax: +49 231 9 75 99 20 Georg Heeg eK Dortmund Handelsregister: Amtsgericht Dortmund A 12812

Oct. 29, 2010