[squeak-dev] Metacello

El mié, 02-09-2009 a las 16:50 -0700, Igor Stasenko escribió:
http://lists.gforge.inria.fr/pipermail/pharo-project/2009-August/012118.html

He doesn't want help.
--
Miguel Cobá
http://miguel.leugim.com.mx

On Wed, Sep 2, 2009 at 4:58 PM, Igor Stasenko<[hidden email]> wrote:

> nah, Chrome is a bit behind FF in functionality available (try
> rendering animated SVG's for instance)
> can't say anything about Safari
> And Firebug is a #1 tool for web-dev ;)

Sorry, I didn't mean to start a browser flame war :)  I just meant
"runs clamato better".  FF can't optimize recursive calls, which is
bad for clamato's PEG parser.

FWIW, I think the Web Inspector that Safari and Chrome share stacks up
pretty well against Firebug these days... especially valuable for
clamato is that you can set a displayName property on otherwie
anonymous functions, which is used by the debugger and profiler.

Avi

>>>>> "Avi" == Avi Bryant <[hidden email]> writes:

Avi> FWIW, I think the Web Inspector that Safari and Chrome share stacks up
Avi> pretty well against Firebug these days... especially valuable for
Avi> clamato is that you can set a displayName property on otherwie
Avi> anonymous functions, which is used by the debugger and profiler.

Yeah, the new web inspector is actually more friendly than Firebug was
for me.  They definitely took the competition and ran with it.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

2009/9/2 Miguel Enrique Cobá Martinez <[hidden email]>:
i think its not a wise to put own words in someone's mouth :)



--
Best regards,
Igor Stasenko AKA sig.

Miguel Enrique Cobá Martinez wrote: I have never seen the above email before.

Sake/Packages is documented.

To install

Installer install: 'Pacakges'.

Documentation is in the class comment

Keith

Germán Arduino wrote: This is an unfair comparison, Magritte is completed published work. Bob
is not yet to be completed. The email referenced above would make sense
to those who download the bob image or to those who logged in to the
public bob server to have a look around. I will leave you to discover in
good time the list of Lukas' contributions that have not been announced.

I emailed on the subject of Sake/Packages you reply with a complaint
about lack of documentation for Bob. They are not the same thing.
Sake/Packages has been available for a long while now and is reasonably
well documented via emails and in the class comment.

Installer install: 'Packages'.

see the class comment in the class Packages.

Keith

I am unsubscribing from squeak-dev

Keith

2009/9/3 Keith Hodges <[hidden email]>:
> I am unsubscribing from squeak-dev
>
> Keith
>
>

Opss, why?

I was just investing time on Installer and friends, and just writting
a mail asking about
errors and doubts......to try to understand the whole context of your tools.


--
=========================================================
Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
Arduino Software & Web Hosting   http://www.arduinosoftware.com
PasswordsPro  http://www.passwordspro.com
=========================================================

On 9/3/09 9:32 AM, "Keith Hodges" <[hidden email]> wrote:

> I am unsubscribing from squeak-dev
>
> Keith

My dear Keith:

We have fights and never understand what you try to do.

But always who come with wild ideas have cool reception.

Please , reconsider such bold thing.

Squeak is stronger each day, things moves on, and we need you.

Edgar

I was wondering the same thing!  

Ronald Spengler wrote

The other shoe drops! Has anyone tried running this on the same page
as the Lively Kernel?

On Wednesday, September 2, 2009, Igor Stasenko <siguctua@gmail.com> wrote:
> 2009/9/2 Avi Bryant <avi@dabbledb.com>:
>> On Wed, Sep 2, 2009 at 4:09 PM, Ian Trudel<ian.trudel@gmail.com> wrote:
>>
>>> His question sounded more like "I'd like to have Clamato and integrate
>>> to my very own website." Rather than playing around on http://clamato.net.
>>>
>>> Doesn't work on IE 7.0.5730.13 nor Opera 10.
>>
>> Yeah - those should work as deployment platforms, but I'm not that
>> motivated to make them work as development platforms.
>>
>>> Works on Firefox 3.5.2.
>>
>> Good. Chrome and Safari are better.
>
> nah, Chrome is a bit behind FF in functionality available (try
> rendering animated SVG's for instance)
> can't say anything about Safari
> And Firebug is a #1 tool for web-dev ;)
>
>>
>> Avi
>>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

--
Ron

Avi Bryant wrote:
You say "PEG" and I think "Ometa"![1] Are you using Ometa/JS for your
parsing?

frank

[1] http://tinlizzie.org/ometa/

>Ronald Spengler wrote:
>>
>> The other shoe drops! Has anyone tried running this on the same page
> > as the Lively Kernel?

I was delighted to hear of Avi's project!

A year ago last March (3/14/08!) I tried to interest a buddy (who read this list ;-) in doing a Smalltalk "skin" over the Lively Kernel as an April Fool's project for Smalltalk folks.

Sadly, other priorities intervened, but I think this is a wonderful distraction.  The new JS engines make it quite practical, and Avi's openness to including some wisdom from Newspeak (and I still think about E and Linda) certainly get me excited.

Rock on

        - Dan

The browser really is quite cool, I really like how easily you can navigate back and forth between different classes by the methods menu to follow code flow.  It's fun seeing new browsers like this, and the the Hopscotch browser from Newspeak and how they bring new points of view.  Nice work.

On Thu, Sep 3, 2009 at 6:49 AM, Frank
Shearar<[hidden email]> wrote:

> You say "PEG" and I think "Ometa"![1] Are you using Ometa/JS for your
> parsing?

No, I'm using a port of Lukas' PetitParser to Clamato.  I wanted it to
be self-hosting, rather than using a lot of underlying JS code (though
obviously there are some "primitives" written in JS).

Avi

Hi Avi, Clamato looks interesting.  I am curious about the roadmap;
the main driving objective propeling the work forward.  Truly a new
"Smalltalk dialect" running in the browser?  Or is Clamato's ultimate
goal more about wielding the browser via Javascript..?

Thanks,
  Chris


On Thu, Sep 3, 2009 at 1:31 PM, Avi Bryant<[hidden email]> wrote:

On Thu, Sep 3, 2009 at 8:18 PM, Chris Muller<[hidden email]> wrote:
> Hi Avi, Clamato looks interesting.  I am curious about the roadmap;
> the main driving objective propeling the work forward.  Truly a new
> "Smalltalk dialect" running in the browser?  Or is Clamato's ultimate
> goal more about wielding the browser via Javascript..?

I'm not sure I understand what you mean by "wielding the browser via
Javascript", but - for us, the main objective is to have a more
pleasant environment in which to write the client-side of web
applications.  A secondary use case might be to just use the web
browser as a development environment for code that was intended to run
on, say, V8 on the server.

Avi

I'm very much interested in this too.

Here's what I project from what I'm hearing...

1.  You like Smalltalk, so you want a language that is as much like it as possible... except for things you don't like, of course.  This also fits in with your "shop" that does a lot of other real Smalltalk work.

2.  You want to take advantage of engines like V8 that offer (a) ubiquity in browsers, and (b) escalating performance paid for by the few remaining profitable companies.

3.  This implies a very close mapping onto JavaScript semantics, but really only onto the subset that you need for the job.

This is very close to what I had in mind as the follow-on to the April Fools prank that never happened.


Since you've ventured to answer Chris's question, allow me to sneak a few more questions into the discussion...

What have you left out on purpose because you don't like it?

What have you left out that you would rather not leave out?

What have you changed that you would rather not?

What would you still like to change?

And two specific questions:

Why no return values from methods?

and why the @-sign on inst var references?

In case it wasn't clear before, I love your spunk in carrying this through to an actual artifact, for only then can any really meaningful criticism take place. My questions are all aimed at eliciting some of your experience and future aims (as I have some of my own in that space), from which to ponder ways in which I (and all of us) might contribute.

        - Dan

On Thu, Sep 3, 2009 at 9:19 PM, Dan Ingalls<[hidden email]> wrote:

> Here's what I project from what I'm hearing...
>
> 1.  You like Smalltalk, so you want a language that is as much like it as possible... except for things you don't like, of course.  This also fits in with your "shop" that does a lot of other real Smalltalk work.
>
> 2.  You want to take advantage of engines like V8 that offer (a) ubiquity in browsers, and (b) escalating performance paid for by the few remaining profitable companies.
>
> 3.  This implies a very close mapping onto JavaScript semantics, but really only onto the subset that you need for the job.

Dead on.

> What have you left out on purpose because you don't like it?
> What have you left out that you would rather not leave out?
> What have you changed that you would rather not?

It's easier for me to answer these by listing the major changes and
how I feel about each of them.

One change that I am happy with is getting rid of
#subclass:instanceVariableNames:... style class definitions. A Clamato
program can be represented entirely as a set of method definitions,
which is great from a tools perspective. This required a #superclass
method on the class side (which you override to inherit from anything
other than Object), and the @ syntax for instance variables.

I don't love the @ syntax, but it has at least two advantages.  One is
that, by essentially moving instance variable declarations into the
methods, you can easily add instance variables to classes in other
packages - Squeak has never had a good way to do this.  The other is
that methods can be parsed and compiled with no context - unlike in
Smalltalk, can identify instance variables vs. temps vs. globals
without knowing anything about the class you are compiling the method
for.  OTOH it's kind of ugly.

I *think* I like having left out explicit returns and implicitly
returning self, in favor of implcitly returning the value of the last
statement. It unifies methods and blocks in a way I find pleasing.
However, my hand was somewhat forced here by Javascript semantics.
The only way to implement them (that I can think of) would be to throw
an exception, which would get caught and rethrown at every level up
the stack frame until it found the right one.  I don't want to do this
to the poor VM.  I've provided a "self return: [:returnBlock | ...]"
primitive that provides this when you really need it, but I've found
it's rarely used.

I tried to leave out the cascade syntax, but found it was too useful
and had to put it back.

I dislike not having a proper metaclass hierarchy (class side methods
don't get inherited by subclasses), but I'm not sure I want to blindly
copy ST80 here either.  Newspeak has some interesting around
constructors but they're a tad heavyweight for my taste.

Using 0 based indexing keeps tripping me up.  That may go away.

There are currently no array literals.  This is obviously a bad thing,
I'm just not sure what form they would take.  Allowing JSON literals
is kinda appealing, and {} isn't doing too much yet.

There's no doesNotUnderstand:, which is a shame, but it's not worth
the performance hit to allow it.

> What would you still like to change?

I'm very intrigued by Newspeak's "no static state", and the way it
approaches namespaces.  I haven't felt any pain yet which I would need
that to resolve, but maybe that will come.

Mostly, though, I'm trying not to get sucked into large-scale language
design, and instead am looking for the smallest reasonable set of
changes I can make to Smalltalk that will let it thrive on top of
Javascript. So if I haven't already needed to make a change to get
this far, I probably won't make it.

I'm taking a more radical approach to the tooling.  I really, really
like the Caesar browser we've developed which treats each type of
browser (senders, implementor, hierarchy, etc) as simply a search that
returns a list of methods, and lifts its overall design (tabs +
location bar + forward/back buttons) from the web browser.  (It's also
been amazing to work with our web designer, Luke Andrews, on this,
especially as he's been learning Smalltalk to do it).

Avi

Hi, Avi -

>It's easier for me to answer these by listing the major changes and
>how I feel about each of them.

First of all, thanks for your great response.  It's exactly what I had hoped for.  Here are some comments interspersed...

>It's easier for me to answer these by listing the major changes and
>how I feel about each of them.
>
>One change that I am happy with is getting rid of
>#subclass:instanceVariableNames:... style class definitions. A Clamato
>program can be represented entirely as a set of method definitions,
>which is great from a tools perspective. This required a #superclass
>method on the class side (which you override to inherit from anything
>other than Object), and the @ syntax for instance variables.

I agree this is nice.  But why not allow that method to declare some instance variables, et voila.

>I don't love the @ syntax, but it has at least two advantages.  One is
>that, by essentially moving instance variable declarations into the
>methods, you can easily add instance variables to classes in other
>packages - Squeak has never had a good way to do this.  The other is
>that methods can be parsed and compiled with no context - unlike in
>Smalltalk, can identify instance variables vs. temps vs. globals
>without knowing anything about the class you are compiling the method
>for.  OTOH it's kind of ugly.

With all due respect, I agree ;-).

>I *think* I like having left out explicit returns and implicitly
>returning self, in favor of implcitly returning the value of the last
>statement. It unifies methods and blocks in a way I find pleasing.

Definitely worth some points.

>However, my hand was somewhat forced here by Javascript semantics.
>The only way to implement them (that I can think of) would be to throw
>an exception, which would get caught and rethrown at every level up
>the stack frame until it found the right one.  I don't want to do this
>to the poor VM.  I've provided a "self return: [:returnBlock | ...]"
>primitive that provides this when you really need it, but I've found
>it's rarely used.

I need to think about this some more and, more importantly, look at and write some code.  We do a lot of point and rectangle arithmetic which needs returns, as in

        var loc = m.bounds().center().plus(delta)
<==>
        loc = m bounds center addPt: delta

How would you go about this?

...and while we're on the topic of point arithmetic, it drives me nuts that JS won't let you add infix methods.  You can put them in the dictionary, but you can't call them.  What I've thought of is to use St's aggregated infix for non-number users of '+', so 'a + b' translates to  'a + b' for numbers and, eg, 'a &+ b' translates to 'a plus b' for points, dates and the like.

That at least gives us...

        loc = m bounds center &+ delta

I've thought of using '.' for this case, because it is so much less intrusive, as...

        loc = m bounds center .+ delta

>I tried to leave out the cascade syntax, but found it was too useful
>and had to put it back.

I love it!  I've always felt a bit sheepish about cascades, but I put them in because it was a pattern that we found useful in St72 and I wanted to preserve as much as possible of that convenience.

>I dislike not having a proper metaclass hierarchy (class side methods
>don't get inherited by subclasses), but I'm not sure I want to blindly
>copy ST80 here either.  Newspeak has some interesting around
>constructors but they're a tad heavyweight for my taste.

I agree about this.  Haven't missed it at all in the Lively work.  Yes, keep it light.

>Using 0 based indexing keeps tripping me up.  That may go away.

My thinking on that one is to take a deep breath and give up.
Of course I like 1-base better, but there are many more folks in the
world that would be thrown by changing to 1-base, and adoption has
would be nice.  More importantly, and again from my
three years of Lively work is that the more you treat arrays with
high level protocols (forEach, etc) the less it really matters.

>There are currently no array literals.  This is obviously a bad thing,
>I'm just not sure what form they would take.  Allowing JSON literals
>is kinda appealing, and {} isn't doing too much yet.

I agree.

>There's no doesNotUnderstand:, which is a shame, but it's not worth
>the performance hit to allow it.
>
>> What would you still like to change?
>
>I'm very intrigued by Newspeak's "no static state", and the way it
>approaches namespaces.  I haven't felt any pain yet which I would need
>that to resolve, but maybe that will come.

So far I'm pretty happy with our little name space hack that Robert Krahn did, especially since it includes on-demand loading.  [don't know if you've looked at it at all]

>Mostly, though, I'm trying not to get sucked into large-scale language
>design, and instead am looking for the smallest reasonable set of
>changes I can make to Smalltalk that will let it thrive on top of
>Javascript. So if I haven't already needed to make a change to get
>this far, I probably won't make it.

..a point of view I totally respect.

That said, though, are you open to a possible collaboration to put a bit more attention on making it the best it can be without making it significantly more complicated.

I'm still interested in my Lively April Fools prank, and it *could* have huge synergy with what you are doing if we agreed on the language.  You might find that an entire Lively Kernel running in Clamato was a nice reservoir to draw on.

>I'm taking a more radical approach to the tooling.  I really, really
>like the Caesar browser we've developed which treats each type of
>browser (senders, implementor, hierarchy, etc) as simply a search that
>returns a list of methods, and lifts its overall design (tabs +
>location bar + forward/back buttons) from the web browser.  (It's also
>been amazing to work with our web designer, Luke Andrews, on this,
>especially as he's been learning Smalltalk to do it).

I agree that this is cool, and I have great respect for the way you have included folks with decent aesthetics on your team.

Have you integrated this development environment with a repository (haven't gone through your code yet)?  We're very happy with our browser hookup that works with a local version of our repository by live WevDAV hookup.

Ciao
        - Dan

On Fri, Sep 4, 2009 at 11:53 AM, Dan Ingalls<[hidden email]> wrote:

> I need to think about this some more and, more importantly, look at and write some code.  We do a lot of point and rectangle arithmetic which needs returns, as in
>
>        var loc = m.bounds().center().plus(delta)
> <==>
>        loc = m bounds center addPt: delta
>
> How would you go about this?

I'm not sure I see the problem... let me clear up a possible point of
confusion.  It's not that methods don't have a return value, it's that
methods, like blocks, always return the value of their last statement
(instead of having explicit returns with ^ ).  Or am I missing what
you're asking?

> ...and while we're on the topic of point arithmetic, it drives me nuts that JS won't let you add infix methods.  You can put them in the dictionary, but you can't call them.  What I've thought of is to use St's aggregated infix for non-number users of '+', so 'a + b' translates to  'a + b' for numbers and, eg, 'a &+ b' translates to 'a plus b' for points, dates and the like.
>
> That at least gives us...
>
>        loc = m bounds center &+ delta
>
> I've thought of using '.' for this case, because it is so much less intrusive, as...
>
>        loc = m bounds center .+ delta

FWIW: in clamato,

         a + b

becomes

         a.$plus(b)

It sounds like you're trying to map smalltalk selectors to existing,
equivalent javascript method names, whereas I'm intentionally mangling
them (foo:bar: becomes _foo_bar_) to avoid clashes with any methods
that might already be there.  This means you need to explicitly wrap
any Javascript methods you might want to use in primitives.

> That said, though, are you open to a possible collaboration to put a bit more attention on making it the best it can be without making it significantly more complicated.

Absolutely.  I would be delighted to have more collaboration on this
(and honored, Dan, to have yours) - though of course I also reserve
the right to ignore any and all suggestions :)

> I'm still interested in my Lively April Fools prank, and it *could* have huge synergy with what you are doing if we agreed on the language.  You might find that an entire Lively Kernel running in Clamato was a nice reservoir to draw on.

Sure.  I don't know too much about what Lively requires of its
classes, but it can't be too hard to make this work.  Though I should
note that I personally am more interested in a DOM-based UI than in
canvas or SVG (the DOM is, of course, much more limiting, but it's
also more familiar to most users and that's important for adoption).

> Have you integrated this development environment with a repository (haven't gone through your code yet)?  We're very happy with our browser hookup that works with a local version of our repository by live WevDAV hookup.

Yes, we do what's probably the same thing - every time you save a
method, a new version of the file is saved over WebDAV.

Avi