Few thoughts about Google Summer of Code
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
On Fri, Oct 29, 2010 at 2:23 PM, Paolo Bonzini bonzini@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/
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@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@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@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
SergeStinckwich wrote:
So if we have a Smalltalk text pane with a VI or emacs bindings, they
will be happy ? ;-)
If I had VI key bindings when I started using Squeak, it would have eased my
adoption greatly - it was really hard for me to give up the power and
efficiency of doing everything without taking my fingers off the keyboard.
One of the answers I got was that because good Smalltalk methods are short,
you don't need them - ha ha. So we have our own religion, too :) In
actuality, this just makes the dramatic productivity increase the key
bindings offer less.
But here's the joke - the SVI project provides VI bindings. Here's another,
Lukas showed a git interface at ESUG. A third? The GTK bindings mentioned
were originally in Squeak, but there was no interest (per steph).
To me, the primary issue is an inability to use and improve the things that
we already have because:
- I can't understand the intention of code - no tests and documentation
- I don't know they exist - no central place/process which includes the
above
It seems the pattern is:
- work on something awesome
- let it disappear into squeaksource, because no one can find it, or figure
out how to use it - 5 years later, have someone else do the same awesome thing from scratch
- repeat step 2
my 2c
Sean
View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p3019449.html
Sent from the ESUG mailing list archive at Nabble.com.
Georg Heeg wrote:
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.
I just find the SeaBreeze Cincom software license agreement is just a bit of
an awkward hurdle although I do like some concepts SeaBreeze and WebVelocity
are addressing. The seabreeze.heeg.de website also really needs an
up-to-date look and feel.
View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p3019590.html
Sent from the ESUG mailing list archive at Nabble.com.
James is quite right here ... but there are many more hurdles and all
these new potential users must be persuaded to come over these hurdles
and be happy with it.
-
e.g. even in Eclipse you're sticked to the editor - nobody complains
about it (one may write an additional plug-in) so this hurdle can be
accepted - if the editor is attractive and gives you real power. In the
area of editors in all those Smalltalk systems I noticed an improvement
in the look-and-feel area - BUT they still do not offer additional helps
like showing all possible methods for an object. In all (Smalltalk-)
systems is the way to navigate to another class very long, that drives
me mad. -
the source code management problem seem to be a big hurdle. systems
like svn, git, cvs are seen as open systems and are well known here.
Nearly all ST systems have their own system (which are often far
superior than the other ones). Source code exchange between all
Smalltalk systems is worse ! Java, C and all that stuff would not be so
attractive if the users have so many problems to switch from one
Java-IDE to another Javae-IDE, or one C-compiler to another. -
the language itselfs is getting old. Missing standard namespaces,
missing interface specifications (etc) seems to stand for old languages.
The missing of interface specification is the worst one and I do not
understand the community, that nobody insist on adding this to Smalltalk. -
Smalltalk systems are not well suited for multiprocessor,
multithreading area ... -
delivering process is more difficult than with other languages ...
-
we have problems getting access to successes in other languages. Out
of the box it is difficult to interact with Java or .NET world. -
even with the often propagated better productivity we are forced (due
to the point above) to reinvent the world instead of being able to use
already available software components.
Considering all these hurdles - and then ask newcomers why should they
use Smalltalk IDE xyz instead of Eclipse or VisualStudio (and both are
available for more or less free and not copyright dialog and no runtime
license problems).
Am 29.10.2010 12:14, schrieb James Robertson:
I'm not sure that's the case. I used that line a lot when I was the Smalltalk Evangelist at Cincom, and it's true - up to a point. However, the prospective developer who looks at the tools from a personal use standpoint cares. So
-- 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 those are complete showstoppers, but they are hurdles - and they are additional hurdles the Smalltalk community doesn't need. Consider that we already present two big hurdles that we require people to get past:
-- The prospective user can't use his favorite editor
-- The prospective user can't use his favorite source code control tools
the UI hurdle is something that could be dealt with (and yes, I recognize the difficulties). The last two are just there. Given that, the additional UI level one should be considered more seriously
I would like to try a browser that keeps track of the code navigation I
have had to make so far to get where I am, something that relieves me
from having to remember the graph traversal of the code. Does this exist?
On 10/30/2010 12:29 AM, Marten Feldtmann wrote:
James is quite right here ... but there are many more hurdles and all
these new potential users must be persuaded to come over these hurdles
and be happy with it.
-
e.g. even in Eclipse you're sticked to the editor - nobody complains
about it (one may write an additional plug-in) so this hurdle can be
accepted - if the editor is attractive and gives you real power. In the
area of editors in all those Smalltalk systems I noticed an improvement
in the look-and-feel area - BUT they still do not offer additional helps
like showing all possible methods for an object. In all (Smalltalk-)
systems is the way to navigate to another class very long, that drives
me mad. -
the source code management problem seem to be a big hurdle. systems
like svn, git, cvs are seen as open systems and are well known here.
Nearly all ST systems have their own system (which are often far
superior than the other ones). Source code exchange between all
Smalltalk systems is worse ! Java, C and all that stuff would not be so
attractive if the users have so many problems to switch from one
Java-IDE to another Javae-IDE, or one C-compiler to another. -
the language itselfs is getting old. Missing standard namespaces,
missing interface specifications (etc) seems to stand for old languages.
The missing of interface specification is the worst one and I do not
understand the community, that nobody insist on adding this to Smalltalk. -
Smalltalk systems are not well suited for multiprocessor,
multithreading area ... -
delivering process is more difficult than with other languages ...
-
we have problems getting access to successes in other languages. Out
of the box it is difficult to interact with Java or .NET world. -
even with the often propagated better productivity we are forced (due
to the point above) to reinvent the world instead of being able to use
already available software components.
Considering all these hurdles - and then ask newcomers why should they
use Smalltalk IDE xyz instead of Eclipse or VisualStudio (and both are
available for more or less free and not copyright dialog and no runtime
license problems).
Am 29.10.2010 12:14, schrieb James Robertson:
I'm not sure that's the case. I used that line a lot when I was the
Smalltalk Evangelist at Cincom, and it's true - up to a point.
However, the prospective developer who looks at the tools from a
personal use standpoint cares. So
-- 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 those are complete showstoppers, but they are hurdles -
and they are additional hurdles the Smalltalk community doesn't need.
Consider that we already present two big hurdles that we require
people to get past:
-- The prospective user can't use his favorite editor
-- The prospective user can't use his favorite source code control tools
the UI hurdle is something that could be dealt with (and yes, I
recognize the difficulties). The last two are just there. Given that,
the additional UI level one should be considered more seriously
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
That sounds exactly like the TrailBlazer browser in VisualAge.
Best regards,
Peter Hugosson-Miller
On Sat, October 30, 2010 09:35, Andres Valloud wrote:
I would like to try a browser that keeps track of the code navigation I
have had to make so far to get where I am, something that relieves me
from having to remember the graph traversal of the code. Does this exist?
Andres,
On Oct 30, 2010, at 12:35 AM, Andres Valloud wrote:
I would like to try a browser that keeps track of the code navigation I have had to make so far to get where I am, something that relieves me from having to remember the graph traversal of the code. Does this exist?
In Newspeak, the Hopscotch browser maintains a history of everywhere you've been, which is always one click away - which means any class, object, workspace etc. is at most two clicks away at all times. I'm not sure if this is what you meant
While I'm on the topic of Newspeak, here are some observations that are perhaps relevant to this thread. Be aware that I am engaged in shameless self promotion.
a. Newspeak has a syntax. So:
b You can edit Newspeak in whatever editor you want. The IDE runs in an image in the classic Smalltalk way, but also saves each class you modify in a file automatically.
c. The IDE has integrated support for source control. Currently this uses a svn-Monticello integration, but the next phase will phase out Monticello and work directly with mercurial, git or svn.
Furthermore
e. Newspeak introduced the Alien FFI, which allows us to use the rest of the world's software. Case in point: we recently needed to talk to some software over https. Squeak does not support this natively, and requires a plugin, which is by its own documentation unstable. We just call out to libCurl.
f. Using said aliens, we support a portable native GUI. Looks great on a modern Windows machine. We could support mac as well, if we had more resources. But, as Andres implies, this is fighting the last war. Hence:
g. We are getting close to running the exact same GUI in a browser.
h. As far as deployment goes, we can deploy apps independent of the IDE - either via the browser or as executables (on Windows) or, in principle, anything else. That is because the language actually supports modularity.
Some of these features need more work to reach full maturity. This could happen sooner if we got more volunteers. While the Smalltalk community might be a good source of such volunteers, I recognize it isn't happening.
So, what am I doing wrong? Newspeak is open source, it runs Squeak Smalltalk as well as Newspeak, and provides a very Smalltalk-like experience for those who want it, while addressing many of the issues that have been brought up in this thread. Even so, very few Smalltalkers are interested in working with Newspeak.
On 10/30/2010 12:29 AM, Marten Feldtmann wrote:
James is quite right here ... but there are many more hurdles and all
these new potential users must be persuaded to come over these hurdles
and be happy with it.
-
e.g. even in Eclipse you're sticked to the editor - nobody complains
about it (one may write an additional plug-in) so this hurdle can be
accepted - if the editor is attractive and gives you real power. In the
area of editors in all those Smalltalk systems I noticed an improvement
in the look-and-feel area - BUT they still do not offer additional helps
like showing all possible methods for an object. In all (Smalltalk-)
systems is the way to navigate to another class very long, that drives
me mad. -
the source code management problem seem to be a big hurdle. systems
like svn, git, cvs are seen as open systems and are well known here.
Nearly all ST systems have their own system (which are often far
superior than the other ones). Source code exchange between all
Smalltalk systems is worse ! Java, C and all that stuff would not be so
attractive if the users have so many problems to switch from one
Java-IDE to another Javae-IDE, or one C-compiler to another. -
the language itselfs is getting old. Missing standard namespaces,
missing interface specifications (etc) seems to stand for old languages.
The missing of interface specification is the worst one and I do not
understand the community, that nobody insist on adding this to Smalltalk. -
Smalltalk systems are not well suited for multiprocessor,
multithreading area ... -
delivering process is more difficult than with other languages ...
-
we have problems getting access to successes in other languages. Out
of the box it is difficult to interact with Java or .NET world. -
even with the often propagated better productivity we are forced (due
to the point above) to reinvent the world instead of being able to use
already available software components.
Considering all these hurdles - and then ask newcomers why should they
use Smalltalk IDE xyz instead of Eclipse or VisualStudio (and both are
available for more or less free and not copyright dialog and no runtime
license problems).
Am 29.10.2010 12:14, schrieb James Robertson:
I'm not sure that's the case. I used that line a lot when I was the
Smalltalk Evangelist at Cincom, and it's true - up to a point.
However, the prospective developer who looks at the tools from a
personal use standpoint cares. So
-- 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 those are complete showstoppers, but they are hurdles -
and they are additional hurdles the Smalltalk community doesn't need.
Consider that we already present two big hurdles that we require
people to get past:
-- The prospective user can't use his favorite editor
-- The prospective user can't use his favorite source code control tools
the UI hurdle is something that could be dealt with (and yes, I
recognize the difficulties). The last two are just there. Given that,
the additional UI level one should be considered more seriously
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Cheers, Gilad
On 10/30/2010 11:17 AM, Gilad Bracha wrote:
So, what am I doing wrong? Newspeak is open source, it runs Squeak
Smalltalk as well as Newspeak, and provides a very Smalltalk-like
experience for those who want it, while addressing many of the issues
that have been brought up in this thread. Even so, very few
Smalltalkers are interested in working with Newspeak.
I've honestly been tempted many times to see what it means to port GNU
Smalltalk to Newspeak the same way Squeak runs on top of it. Time is
unfortunately always a problem.
Paolo