October 2010 - Esug-list - lists.esug.org

Re: [Esug-list] Few thoughts about Google Summer of Code
by Damien Pollet Oct. 29, 2010

Oct. 29, 2010

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

1 0

Re: [Esug-list] Few thoughts about Google Summer of Code
by Steven Kelly Oct. 29, 2010

Oct. 29, 2010

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

1 0

Re: [Esug-list] Few thoughts about Google Summer of Code
by Steven Kelly Oct. 29, 2010

Oct. 29, 2010

> On 10/29/2010 12:48 PM, Geert Claes wrote: > >> It sure cares! If the VCS doesn't allow easy integration of code > >> with other kinds of assets (pictures, CSS, schemas expressed as > >> DDL, etc.) and with other people on the team who work on those > >> assets, developers _are_ going to complain. VCS and source code organization is something that has now become standard across all mainstream languages (i.e. Java and C# :->). Your source code should be saved in class files, in a directory structure that mirrors the package/namespace structure. Other assets are stored and versioned in a similar way. You can use any VCSs with any programming language; indeed, you may be more attached to a VCS than a language. You will use one VCS for a project, but you may use multiple languages. Similar things can be said for IDEs and VMs: you probably pick one and stick to it, although you use multiple languages. 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 Based on that, it's obvious Smalltalk is not going to succeed in a big way in the foreseeable future. What we need to look at are what areas we lose out on in 2), and could be changed to fit what everybody else is doing, without losing much in 4). To my mind, source code in class files and normal VCS would be doable in Smalltalk, without losing anything major. In contrast, image-based development is a major factor in our competitive advantage, allowing debugging, experimentation etc. It's hard to imagine image-based development with Eclipse or VisualStudio, and implementing Smalltalk on another existing VM is currently too hard, so I'll skip those and focus on the low-hanging fruit. Which Smalltalks (+/- add-on projects) have code in class files, interface with standard VCS, and yet still have an image-based, GUI IDE? And for those that don't, how hard would it be to get there? Steve

4 3

Re: [Esug-list] Few thoughts about Google Summer of Code
by 'Markus Rips' Oct. 29, 2010

Oct. 29, 2010

>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

1 0

Re: [Esug-list] Few thoughts about Google Summer of Code
by Steven Kelly Oct. 29, 2010

Oct. 29, 2010

Jan Vrany wrote: > > On 10/29/2010 01:36 PM, Steven Kelly wrote: > > > Which Smalltalks (+/- add-on projects) have code in class files, > > > interface with standard VCS > > Smalltalk/X supports CVS and SubVersion. > > > > and yet still have an image-based, GUI IDE? > > Smalltalk/X for instance :-) Thanks! But to return to my criteria: 1) what everybody else is using 2) what seems familiar to them 3) what is cool 4) what is good Even in the Smalltalk community, Smalltalk/X isn't 1). And looking at the web pages, with not even a single picture of the IDE or Smalltalk/X applications on the Products > Smalltalk/X pages, it may find itself in pretty big trouble on 3). That's a real shame, in an era when even one-person companies and research projects have smart videos showing off their products. Particularly since from what I hear, Smalltalk/X does pretty well on 4). Sorry if that sounds harsh - I do understand the other side of the coin, i.e. that there's hardly any money to be made by selling software development environments these days. Good luck to eXept with expecco, which I guess is what they focus on now. Steve

1 0

Re: [Esug-list] Few thoughts about Google Summer of Code
by Steven Kelly Oct. 29, 2010

Oct. 29, 2010

James Robertson wrote: > -- the not quite "standard" widgets in VisualWorks make him think > -- the "all in one windows" thing in Pharo and Squeak make him think I don't think these are the major issues these days. VW's widgets are close to standard widgets these days, and most other apps' widgets diverge from the standards anyway. Squeak will suffer far more, as its look is further from the standard (last time I looked). Most IDEs are very much "all in one window", so I think VW suffers more there. The single window of Pharo and Squeak feels odd to a VW user, not to a normal person :-). Of course Pharo and Squeak could do more to have a single big IDE window with fixed panes, rather than the multiple floating windows-within-a-window that they had last time I looked. Then again, the CodeBubbles demo has got people excited, and that's pretty close to a Smalltalk "multiple browser windows" model. http://www.cs.brown.edu/people/acb/codebubbles_site.htm Steve

1 0

Few thoughts about Google Summer of Code
by Dennis Schetinin Oct. 29, 2010

Oct. 29, 2010

… and observations …and questions … mostly inspired by GSoC Mentor Summit 1. 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. 2. 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. 3. 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… 4. 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/list. 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. 5. 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. 6. 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. 7. 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

2 1

Smalltalk is cool on Nabble :)
by Geert Claes Oct. 28, 2010

Oct. 28, 2010

http://forum.world.st/file/n3015547/SmalltalkIsCoolOnNabble.png -- View this message in context: http://forum.world.st/Smalltalk-is-cool-on-Nabble-tp3015547p3015547.html Sent from the ESUG mailing list archive at Nabble.com.

3 2

All known ESUG Slides on Slideshare
by Marcus Denker Oct. 28, 2010

Oct. 28, 2010

Hello, All known ESUG Slides (all 254) are now on SlideShare: http://www.slideshare.net/esug/slideshows or as pdf in the ESUG Archive: http://esug.org/data/ Up to 2000, we do not have many slides... so if somone has slides especially from early years, please send them. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

5 4

Looking for real-world Magma application
by Igor Stasenko Oct. 21, 2010

Oct. 21, 2010

Hello all, sorry for cross-posting. :) I'd like to ask you, if anyone could share either an image or installation with application, which using Magma OODB. I'd like to use it & test how changing different aspects of Magma internals could affect the performance. There's many tricks, which is known by Chris how to speed it up by cleverly fine-tuning various Magma options, like read strategy etc. But what i'd like is to see, is some setup, used by people, and by taking it, see how it could make run faster, without changing an application code. I remember, someone gave a talk @ ESUG, that they were using Magma for their application, but then forced to switch to another DB layer, because they had bad performance issues. It would be good, if you could give me the code, so i can run it and see if things could be improved. Its not a problem, if code is not open-source, we could sign an NDA, if this is necessary. I need something real, simply because benchmarks sometimes not representative. :) -- Best regards, Igor Stasenko AKA sig.

1 0