Community sprint

Hello,
i'm creating a simple homepage (from an HTML template :P),
i'm not a good  
graphic but i think updates must be done in order to gain
people.

An about page: what's smalltalk, what's GNU smalltalk, its
features,  
purposes and objectives.
A community page: simply describe the mailing list and how
to contribute  
to GNU smalltalk trough code and bug reporting
Screenshots page of blox-tk and gtk environments
Comparisong between existing smalltalk versions
A CVS page describing how to fetch smalltalk and make diffs.

The logo: the smalltalk baloon with the gnu on it

Why i'm going to leave Squeak:
1) License problems with distributions
2) It's not friendly for scripting as GST is
3) C interfacing is made easier in GST (i was creating
SqueakGTK for  
instance, i don't i'm indeed to continue it)
4) People would install GST instead of Squeak to run your
smalltalk  
application (just ask)

What are my dreams:
1) Have a good set of libraries
2) Create scalable and portable applications in smalltalk
(GST is the  
unique choice at the moment)

This smalltalk implementation is currently unknown, but it
can be really  
important if we gain community... just this.

-- 
http://lethalman.blogsp
ot.com - Thoughts about computer technologies


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Screenshots page of blox-tk and gtk environments
> Comparisong between existing smalltalk versions
> A CVS page describing how to fetch smalltalk and make
diffs.
Just link to savannah.
> The logo: the smalltalk baloon with the gnu on it
I'm no graphic expert either, but it seems a bit weird  
> What are my dreams:
> 1) Have a good set of libraries
> 2) Create scalable and portable applications in
smalltalk (GST is the 
> unique choice at the moment)
3) Have a decent and appealing scripting syntax -- no
file-outs.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

In data 29 settembre 2006 alle ore 11:27:34, Paolo Bonzini  
<paolo.bonzinilu.unisi.ch> ha scritto:

>
>> Screenshots page of blox-tk and gtk environments
>> Comparisong between existing smalltalk versions
>> A CVS page describing how to fetch smalltalk and
make diffs.
> Just link to savannah.

I think an introduction in the homepage itself should be
more friendly.

>> The logo: the smalltalk baloon with the gnu on it
> I'm no graphic expert either, but it seems a bit weird 


Me too, however discuss about this :P

>> What are my dreams:
>> 1) Have a good set of libraries
>> 2) Create scalable and portable applications in
smalltalk (GST is the  
>> unique choice at the moment)
> 3) Have a decent and appealing scripting syntax -- no
file-outs.
>

In what sense? You mean all that code for creating classes
and methods  
should be reinvented for scripting?
Aren't file outs important for bringing out packages?

Bye.

-- 
http://lethalman.blogsp
ot.com - Thoughts about computer technologies


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

>>> What are my dreams:
>>> 1) Have a good set of libraries
>>> 2) Create scalable and portable applications in
smalltalk (GST is 
>>> the unique choice at the moment)
>> 3) Have a decent and appealing scripting syntax --
no file-outs.
>>
> In what sense? You mean all that code for creating
classes and methods 
> should be reinvented for scripting?
> Aren't file outs important for bringing out packages?
Class name: #Number extend: #Object [
    Method [
        isNumber
            ^true
    ]
]

or something like that.  No "exclamation-mark
separated" file-outs.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

In data 29 settembre 2006 alle ore 11:52:55, Paolo Bonzini
<paolo.bonzinilu.unisi.ch> ha scritto:

>
>>>> What are my dreams:
>>>> 1) Have a good set of libraries
>>>> 2) Create scalable and portable
applications in smalltalk (GST is the  
>>>> unique choice at the moment)
>>> 3) Have a decent and appealing scripting syntax
-- no file-outs.
>>>
>> In what sense? You mean all that code for creating
classes and methods  
>> should be reinvented for scripting?
>> Aren't file outs important for bringing out
packages?
> Class name: #Number extend: #Object [
>     Method [
>         isNumber
>             ^true
>     ]
> ]
>
> or something like that.  No "exclamation-mark
separated" file-outs.
>
> Paolo

That would change the syntax... maybe something like this
would be
reproducible in a smalltalk-like way:

Object subclass: #Foo
	instanceVariableNames: 'a'
	instanceMethods: {
#'initialize-release' -> {
	'initialize
		a := ''foo'''
}.
#'accessing' -> {
	'a
		^a'
}}
	...
!

Logically, using a string is not the best way to define a
method (using
#compile:category: in this case) but can be a useful thing
at the
beginning.

Also, i see in Squeak that #new calls #initialize, i don't
see this
behavior here, what about?

And the homepage? I can continue mine, hoping it'll be
enough good to you
all 

-- 
http://lethalman.blogsp
ot.com - Thoughts about computer technologies


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi Luca,

I'm actually doing much of the same at smalltalk.infosnel.nl
:-D

On 9/29/06, Luca Bruno <lethalman88gmail.com> wrote:
> Hello,
> i'm creating a simple homepage (from an HTML template
:P), i'm not a good
> graphic but i think updates must be done in order to
gain people.
Right. However, I find most community sites and wiki systems
tend to
become chaotic: you are looking at the views of various
people and
they might be contradicting. This is why I choose a static
system with
user comments and a forum. More interaction may come as
needed 

>
> An about page: what's smalltalk, what's GNU smalltalk,
its features,
> purposes and objectives.
> A community page: simply describe the mailing list and
how to contribute
> to GNU smalltalk trough code and bug reporting
http://smalltalk.infosnel.nl/byExample/development.php
. This is
uncanny! (if that is how you write that word)

> Screenshots page of blox-tk and gtk environments
Good idea, haven't done that yet. And more examples would be
good.

> Comparisong between existing smalltalk versions
Smalltalk.org does a good job at this, I think.

> A CVS page describing how to fetch smalltalk and make
diffs.
Don't forget to mention the development page at savannah.

>
> The logo: the smalltalk baloon with the gnu on it
Haha, I had the same problem! Posted about it a week or so
ago. I've
created a cartoon speech balloon with the gnu in it.
However, I'm just
the fan site. The actual "GNU Smalltalk logo"
should be done by
developer's choice. Maybe start a competition?


> What are my dreams:
> 1) Have a good set of libraries
Same here. However, I think the C-bindings should be placed
at the
background more, simply for portability: writing things in
smalltalk
will make it more portable. I would love a kind of GTKmm
like
extension layer written in Smalltalk, keeping library
dependencies to
a minimal. Maybe even a C to Smalltalk translator or
compiler (like
the compilers for CLI and .NET).

> 2) Create scalable and portable applications in
smalltalk (GST is the
> unique choice at the moment)
Yes, I'm trying to get GNU Smalltalk to become _the_ cross
platform
GTK GUI based application system.

>
> This smalltalk implementation is currently unknown, but
it can be really
> important if we gain community... just this.
I do not think it is an unkown implementation. Smalltalk is
simply not
really present at the moment.

To get the livelyhood we need to create applications the
people can
use! At the moment, I know of only one "user"
application: Bottom
feeder. And this is written in Visual Smalltalk!


Hope to see your logo soon,
  Bram


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Luca Bruno wrote:
> In data 29 settembre 2006 alle ore 11:52:55, Paolo
Bonzini
> <paolo.bonzinilu.unisi.ch> ha scritto:
> 
>>
>>>>> What are my dreams:
>>>>> 1) Have a good set of libraries
>>>>> 2) Create scalable and portable
applications in smalltalk (GST is
>>>>> the  unique choice at the moment)
>>>>
>>>> 3) Have a decent and appealing scripting
syntax -- no file-outs.
>>>>
>>> In what sense? You mean all that code for
creating classes and
>>> methods  should be reinvented for scripting?
>>> Aren't file outs important for bringing out
packages?
>>
>> Class name: #Number extend: #Object [
>>     Method [
>>         isNumber
>>             ^true
>>     ]
>> ]
>>
>> or something like that.  No "exclamation-mark
separated" file-outs.
>>
>> Paolo

There's a horrible java-smell coming off that :-b

> That would change the syntax

Bear in mind that the syntax is already 'changed' by
#methodsFor:, which
switches from 'interpreter' mode to 'method compilation'
mode.

>... maybe something like this would be
> reproducible in a smalltalk-like way:
> 
> Object subclass: #Foo
>     instanceVariableNames: 'a'
>     instanceMethods: {
> #'initialize-release' -> {
>     'initialize
>         a := ''foo'''
> }.
> #'accessing' -> {
>     'a
>         ^a'
> }}
>     ...
> !
> 
> Logically, using a string is not the best way to define
a method (using
> #compile:category: in this case) but can be a useful
thing at the
> beginning.

Doubling-up of the quotes around strings gets annoying very
quickly.

Also, that syntax suggests that the methods of a class have
to be
declared when the class itself is declared, but one of the
ways in which
Smalltalk wins big is that you can add/change methods in
already-declared classes (and change their declaration, but
I don't find
the need to do that so often).

I actually quite like the file-out format (maybe it's just
that I've
done a lot of coding in it), although it is a shame that it
makes the
exclamation mark unavailable for selectors. My suggestions
for
improvements are simply to add the following convenience
methods which
simply save some typing:

Class >> #subclass:
Class >> #subclass:instVarNames:
Class >> #subclass:instVarNames:classVarNames:

and remove the "don't use this" comment in
Behavior >> #methods.

Writing this, I did wonder if it would be nice for #>>
itself to switch
to method compilation mode for one method only if the method
is not
already present:

String >> #asThingumy !
	^self shouldNotImplement.
!

String >> #asBob !
	^self subclassResponsibility.
!

> Also, i see in Squeak that #new calls #initialize, i
don't see this
> behavior here, what about?

I thought that got added a while back. Did it not make it to
the stable
series?

Regards,

Mike


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

>>> Class name: #Number extend: #Object [
>>>     Method [
>>>         isNumber
>>>             ^true
>>>     ]
>>> ]
>>>       
> There's a horrible java-smell coming off that :-b
>   
Unfortunately I must agree that there is.  But I'm afraid
that it is 
what people want.  Smalltalk has been sending messages to
create classes 
for 25 years, but people still prefer language that don't. 
I'm afraid 
we need syntactic sugar for them.

I'm open to suggestion on the design of this, though.
> Also, that syntax suggests that the methods of a class
have to be
> declared when the class itself is declared, but one of
the ways in which
> Smalltalk wins big is that you can add/change methods
in
> already-declared classes (and change their declaration,
but I don't find
> the need to do that so often).
>   
I think Luca's example (and my Java-smelling example) could
be extended 
pretty easily (though in Luca's case, the doubling of string
quotes is 
just wrong).
> I actually quite like the file-out format (maybe it's
just that I've
> done a lot of coding in it),
Me too, for that matters.
> Writing this, I did wonder if it would be nice for
#>> itself to switch
> to method compilation mode for one method only if the
method is not
> already present:
>
> String >> #asThingumy !
> 	^self shouldNotImplement.
> !
>
> String >> #asBob !
> 	^self subclassResponsibility.
> !
>   
<weird-idea>
Hmmmm... what about replacing the bang???

String >> #asThingumy [
   ^self shouldNotImplement
]

and

String methodsFor: 'foo' [
]

??
</weird-idea>
>> Also, i see in Squeak that #new calls #initialize,
i don't see this
>> behavior here, what about?
>>     
> I thought that got added a while back. Did it not make
it to the stable
> series?
>   
No, it was never added.  I have to understand the 
backwards-compatibility implications of that change...

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 9/29/06, Mike Anderson <gnu-smalltalkgingerbread.plus.com> wrote:
> Luca Bruno wrote:
> > In data 29 settembre 2006 alle ore 11:52:55, Paolo
Bonzini
> > <paolo.bonzinilu.unisi.ch> ha scritto:
> >>>> 3) Have a decent and appealing
scripting syntax -- no file-outs.
> >>>>
> >>> In what sense? You mean all that code for
creating classes and
> >>> methods  should be reinvented for
scripting?
> >>> Aren't file outs important for bringing
out packages?
> >>
> >> Class name: #Number extend: #Object [
> >>     Method [
> >>         isNumber
> >>             ^true
> >>     ]
> >> ]
> >>
> >> or something like that.  No
"exclamation-mark separated" file-outs.
>
> There's a horrible java-smell coming off that :-b
Not only that, I think this is weird. One of the big
advantages the
"new" scripting languages try to show you is that
it has one keyword
for ending  ("end") and you don't need more. Also,
I hate the whole
"We need opening and closing markers" that comes
with XML syntax. I
would rather see smalltalk go the other way: making more use
of
newline and indentation, like python does. (Although
indentation is
not really the best way to go).

Also, the methodsFor, allows you to open a section with a
comment,
allowing you to catagorize your methods: I think we simply
must save
this feature.

Bram


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 9/29/06, Paolo Bonzini <paolo.bonzinilu.unisi.ch> wrote:
> Unfortunately I must agree that there is.  But I'm
afraid that it is
> what people want.  Smalltalk has been sending messages
to create classes
> for 25 years, but people still prefer language that
don't.  I'm afraid
> we need syntactic sugar for them.

I'm don't want to start any flaming here, but I'm totally
thinking in
the oposite direction. I don't think people want a different
syntax.
When I got interested into Smalltalk, I was _only_ repelled
by the
following:
- I could not find any simple example on the internet,
appart from hello world.
- There are little or no usable programs out there, and I
couldn't
find any done with GNU Smalltalk.
- Everybody seemed to be stuck to their image, saying: look
what I can
do, this is great.
- There are allot of different smalltalks out there, and
every one has
a different syntax, so you have to choose a platform before
even
learning anything.


The only thing that will make me hate or love smalltalk is
the ability
to solve my problems. My problems currently are:
- Having to build an installer if you have multiple files. I
would
like to see .jar like packages so I can have a single
"executable" and
keep my files in it. Preferrable, having it's own protable
filesystem
if needed. ( I would love GNU Smalltalk to become a kind of
virtual
mini computer you can run, ideally using hardware
virtuallization in
the future.)
- Have a portable system: being able to give my program to
users of
other platforms, without having to test on them.
- Having a standard library that can already do handy
things:
splitting up strings, regular expressions, scanning data,
multi-platform file system abstraction, etc.
- Security possiblilities: Being able to isolate parts of
your code
for security reasons. This will allow you to download
plugins and
untrusted code and still use it in your program. (I like the
Ruby
safe-mode system)

My 2 cents,
  Bram


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk