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.blogspot.com - Thoughts about computer technologies


_______________________________________________
help-smalltalk mailing list
[hidden email]
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
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

In data 29 settembre 2006 alle ore 11:27:34, Paolo Bonzini  
<[hidden email]> 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.blogspot.com - Thoughts about computer technologies


_______________________________________________
help-smalltalk mailing list
[hidden email]
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
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

In data 29 settembre 2006 alle ore 11:52:55, Paolo Bonzini
<[hidden email]> ha scritto:

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.blogspot.com - Thoughts about computer technologies


_______________________________________________
help-smalltalk mailing list
[hidden email]
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 <[hidden email]> 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
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Luca Bruno wrote:
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.

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
[hidden email]
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. <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
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 9/29/06, Mike Anderson <[hidden email]> wrote: 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
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 9/29/06, Paolo Bonzini <[hidden email]> 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
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Bram Neijt wrote:
>> 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?

Here's my entry!

http://www.friendofthepigeon.co.uk/wordpress/?p=39

>> 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).

C to Smalltalk is really quite do-able for simple libraries (my
interface to Cairo is an example of sorts). It gets quite hairy for
things like Gtk+ where you encounter some ugly #IFDEFs.

I keep meaning to find some time to look at Sport, which is supposed to
do this sort of thing, I think.

Regards,

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
Hmm, having got over my initial wave of nausea, you may have a point
about Class >> #name:extend: (why not #name:extends: though?). I'm not
so sure about Method being stuck in there, though.

I do think that #subclass: should remain the preferred way to create
classes, though. It's standard Smalltalk (in so far as such a thing
exists), and it illustrates a few fundamental Smalltalk concepts very
nicely, specifically: everything is an object, including classes, and
everything is done by sending messages to objects. Realizing that
classes were created by sending a message to another class was one of my
"Wow!" moments when learning Smalltalk.

I was warming to the first one. It looks like you're sending a block as
a message, which is odd, but not too odd. To think of a method body as a
block is very natural. Unfortunately, I've realized that it gives you no
opportunity to name the parameters. I suppose you could have:

String >> [ join: aCollectionOfStrings
    "Join the elements of aCollectionOfStrings, in order, with myself."
]

I don't think that the #methodsFor: case works so well. There's less
justification for having a special-case block:

String methodsFor: 'text processing' [
  [ split: aSubString
    "Create a collection of my sub strings delimited by aSubString."
  ].
  [ join: aCollectionOfStrings
    "Join the elements of aCollectionOfStrings, in order, with myself."
  ]
]

Personally, I wouldn't mind declaring the category for each method:

String methodFor: 'examples' body: [ join: aCollectionOfStrings
    "Join the elements of aCollectionOfStrings, in order, with myself."
]

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Hmm, having got over my initial wave of nausea, you may have a point
> about Class >> #name:extend: (why not #name:extends: though?).
Just because it's been a while since I touched Java.  :-P

It might as well be

    String subclass: #MyString [
       Method for: 'category' [
          body
       ]
    ]
> I'm not so sure about Method being stuck in there, though.
>  
I should point this out again: if I get to implement this, it will be
completely optional to use it.  More on this later. Uuuhm, yes, I missed that.

To continue with my Java-ish example, class extension would be declared,
if we pick #name:extends:, as

Class name: String [
    "This has set the scope of the method declarations."
    Method for: 'extensions' [
        join: aCollectionOfStrings
           "Join the elements of aCollectionOfStrings, in order, with
myself."
           ^self inject: aCollectionOfStrings into: [ :a : b | a, b ]
    ]
]

Or maybe, if we pick #subclass:, as

String extensions [
    Method for: 'extensions' [
        join: aCollectionOfStrings
            "Join the elements of aCollectionOfStrings, in order, with
myself."
            ^self inject: aCollectionOfStrings into: [ :a : b | a, b ]
    ]
]

or also

Method on: String for: 'extensions' [
    join: aCollectionOfStrings
        "Join the elements of aCollectionOfStrings, in order, with myself."
        ^self inject: aCollectionOfStrings into: [ :a : b | a, b ]
]


> I don't think that the #methodsFor: case works so well. There's less
> justification for having a special-case block:
>  
The justification is just to provide a familiar syntax to people that
have prejudice. :-)  If the mountain does not go to Mohammed, ...
> Personally, I wouldn't mind declaring the category for each method:
>
> String methodFor: 'examples' body: [ join: aCollectionOfStrings
>     "Join the elements of aCollectionOfStrings, in order, with myself."
> ]
>  
Yes, and that's about the same as the above "Method" syntax.  I don't
have a "body:" because anyway this has to be special cased in the parser
-- it's not a block anyway, it's just reusing the [ ] tokens, the same
as { } are used for scoping many different things in C/C++/Java.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
I've posted a cropped version. You lose some of the colours, though. I'm
going to try re-drawing her in a horizontal position.

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:

No argument with anything you said, except:

- ^self inject: aCollectionOfStrings into: [ :a : b | a, b ]
+ ^aCollectionOfStrings fold: [ :a : b | a, self, b ]

was what I meant :-) (like perl's join).

>> I don't think that the #methodsFor: case works so well. There's less
>> justification for having a special-case block:
>>  
>
> The justification is just to provide a familiar syntax to people that
> have prejudice. :-)  If the mountain does not go to Mohammed, ...

Well, yes, but with the method body it makes some kind of sense, because
the [] enclose valid code. It grates a bit more for the methodsFor: case
is all. Would you separate the method declarations with periods?

Your quotation is backwards, by the way  (-:

A method declaration is *very* similar to a block, though. For a list of
methods, it would make more sense (to me at least) to re-use {}.

Anyway, these are minor niggles.

I don't think it's wise to point to C/C++ as good examples BTW ;-)

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Mike Anderson wrote:
[...]
> I was warming to the first one. It looks like you're sending a block as
> a message, which is odd, but not too odd. To think of a method body as a
> block is very natural. Unfortunately, I've realized that it gives you no
> opportunity to name the parameters. I suppose you could have:

I may be missing something, but given that blocks *do* have named parameters,
and that you can figure out how many parameters a message has from looking at
the name, is there anything wrong with:

String addMethod: #join: doing: [ :aCollectionOfStrings |
        ...code here...
].

and:

String addMethod: #replace:with: doing: [ :source :dest |
        ...code here...
].

Admittedly, this doesn't give you the traditional "replace: source with: dest"
syntax, but it does avoid having to invent anything too alien.

Also, I will point out that Smalltalk is not, traditionally, a decent
scripting language. The syntax is designed for small chunks of code floating
in a huge sea of an image and doesn't lend itself well to serialising (hence
this discussion). So you may find it clearer to invent an entirely new syntax
for reading in big chunks of code, that's not based on reading and executing
single statements. How about something along the lines of:

String
- join: aCollectionOfStrings
        ...code here...

- replace: source with: dest
        ...code here...

Indented lines are the code body, a line by itself specifies a class, lines
beginning with - define a method, lines beginning with + define a class method...

--
+- David Given --McQ-+ "Gaping from its single obling socket was
|  [hidden email]    | scintillating, many fauceted scarlet emerald..."
| ([hidden email]) | --- Jim Theis, _The Eye of Argon_ (spelling
+- www.cowlark.com --+ original)



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> String addMethod: #replace:with: doing: [ :source :dest |
> ...code here...
> ].
>
> Admittedly, this doesn't give you the traditional "replace: source with: dest"
> syntax, but it does avoid having to invent anything too alien.
>  
The point is exactly that it is ok to...
> invent an entirely new syntax
> for reading in big chunks of code, that's not based on reading and executing
> single statements.
>  
:-)
> String
> - join: aCollectionOfStrings
> ...code here...
>
> - replace: source with: dest
> ...code here...
>  
I already saw this somewhere, didn't I? :-)


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

David Given wrote:
You're quite right, but I think that that declaration is no more
readable than a C function signature, whereas the traditional Smalltalk
signature is much more readable. Also, with the entire method definition
in square brackets, it looks the same as the contents of a method
browser in any other Smalltalk, examples in books, etc.

Regards,

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> You're quite right, but I think that that declaration is no more
> readable than a C function signature, whereas the traditional Smalltalk
> signature is much more readable. Also, with the entire method definition
> in square brackets, it looks the same as the contents of a method
> browser in any other Smalltalk, examples in books, etc.
>  
Yes, you made a very important point.  We need something that pleases
the multitude of programmers (the mountain), but that is not too
different from traditional Smalltalk (Mohammed).  So yes, my quotation
was backwards because I never remember the right one :-) but it made
this point more clear that way. :-)

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
[...]
>> String
>> - join: aCollectionOfStrings
>>     ...code here...
>>
>> - replace: source with: dest
>>     ...code here...
>>  
> I already saw this somewhere, didn't I? :-)

Hey, it only seems fair --- Objective C stole Smalltalk's syntax, and now
we're stealing it back!

--
+- David Given --McQ-+ "Gaping from its single obling socket was
|  [hidden email]    | scintillating, many fauceted scarlet emerald..."
| ([hidden email]) | --- Jim Theis, _The Eye of Argon_ (spelling
+- www.cowlark.com --+ original)



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk