Pushing Amber

One of the things which has won the hearts and minds of developers with node/npm is the way it resolves cross package dependencies in regards to dependencies having mutual sub-dependencies of different versions. That is something that I have a hard time imagining in the context of the smalltalk browser. How would you illustrate that whilst inspecting/debugging? "the method you are inspecting is of package.version.class.method" ? 

Shaun,

When you say "sub-dependencies of different versions" I assume that you are referring to method namespaces of some sort?

If so then Amber would need a namespace implementation and part of namespaces would be to add namespace features to all of the tools ... if you adapted/adopted the node/npm namespace approach then package.version.class.method (if that's the node/npm namespace naming scheme) would have to be part of the method signature...

Dale

----- Original Message -----
| From: "shaun gilchrist" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 10:00:01 AM
| Subject: Re: [amber-lang] Pushing Amber
|
| One of the things which has won the hearts and minds of developers
| with node/npm is the way it resolves cross package dependencies in
| regards to dependencies having mutual sub-dependencies of different
| versions. That is something that I have a hard time imagining in the
| context of the smalltalk browser. How would you illustrate that
| whilst inspecting/debugging? "the method you are inspecting is of
| package.version.class.method" ?
|
|
| On Wed, Jun 6, 2012 at 10:21 AM, Dale Henrichs < [hidden email]
| > wrote:
|
|
|
|
|
| ----- Original Message -----
| | From: "Herby Vojčík" < [hidden email] >
| | To: [hidden email]
|
| | Sent: Wednesday, June 6, 2012 3:47:55 AM
| | Subject: Re: [amber-lang] Pushing Amber
| |
|
| |
|
| | OK, so I have looked at npm more in-depth and I must say I
| | oversimplified some things - it is not the exactly right solution -
| | mainly because it stores dependencies inside package, creating tree
| | of
| | dependencies, but not including them if they already are upper -
| | relying
| | on the fact the node's require will process the file structure, so
| | they
| | are not usable as-is (they need server-side processing, at least
| | when
| | looking for them).
| |
| | But maybe there can be inspiration or reusing something similar.
| |
| | Herby
|
| Herby,
|
| Ah, so there'd need to be special-case code to adapt it for
| client-side use then:(
|
| If you are going to add dependencies to Amber packages, there are a
| number of moving parts that need to be coordinated ... disk format,
| package manager, dependency resolver and loader ...
|
| Dale
|
|

Hey again!

On 06/05/2012 08:02 PM, Dale Henrichs wrote:
> | From: "Göran Krampe"<[hidden email]>
> | Mmmm, well, although I am all *for* any and all solutions ;) (the
> | principle that we are too few to "stifle" any initiatives) I would
> | prefer a "package model" that is independent of server solution.
>
> I'm inclined to agree, but the implementation of a server-independent model is very much complicated by the disparity in the supporting infrastructure between Node and Pharo.

I am not sure I understand why it would have to be "very much
complicated". I am merely asking us to come up with a very simple model
of how a Package (do note that the class and concept is ALREADY there)
is decorated with meta data and how we load them from Amber.

> If you insist on being server-neutral, then your client-side model will be limited by the capabilities of the lowest common denominator.

Well, let me put it this way - if I write an Amber package called say
Deluxe-Collections then I would like to easily save and publish it on a
URL so that everyone can use it. In ONE WAY. I don't want to have to do
it in 5 different ways so that people using Node, Pharo, Rails or
whatever backend-extra-tools can use it. One way must be enough.

Yup. Someone already did some hack for local storage (and I have wanted
to do it myself) and one could easily imagine the Amber IDE publishing
packages straight up into the cloud somewhere, box.net or who knows.

Having something running on localhost serving files is NOT going to be a
prerequisite for long.

> | 2. Very simple. It should IMHO be limited to the very smallest needed
> | things, and not at all be aimed at the jungle of source code
> | management.
>
> Unfortunately, source code management is a jungle ... side-stepping source code management is an option, but your developers cannot side-step the issue so easily, they are making SCM decisions right now and have to have a working system ...

Sure, but mixing SCM with package management is IMHO not a good idea. MC
did it, but I still think it basically was a mistake. I want to be free
to use whatever SCM tools I like and then publish a package in ...
right, you guessed it - ONE WAY.

> I'm not familiar enough with javascript to know whether there is a well-accepted packaging model that already exists for javascript ...

There are several :). requirejs was mentioned, and yes, it is a good
tool, we use it at our customer - but it is not aimed at "global
packages" but rather "in project modules".

CommonJS has been mentioned too - it is a collection of specs IIUIC for
among other things, modules. But again, mainly in the sense of requirejs.

> IMHO, adopting/adapting the javascript model would be the best choice for Amber ...

I agree. We should try to use js "ways" when they fit. In this
particular case I am not sure I have yet seen what the "js way" is
though - npm is close, but... I need to look more.

> Reinventing the wheel is the most fun, but adapting/adopting an existing model gets the job done...

I am with you on this.

> |
> | 3. Have a working dependency model. But I think it should be along
> | the
> | "works in 90% of the cases, easily overridden for the other 10%".
> |
>
> In my experience, specifying the dependency is not the hard part ... resolving dependencies (finding the correct versions of the files),
 > honoring the dependencies (saving the files where they came from) and
loading the files (detecting dependency loops and version conflicts)
 > are the nasty bits, that make SCM a jungle.

Yes, and I have been involved in a LOT of discussions about this earlier
(SM), which is why I say 90%. I only would care for the simple cases and
plainly just barf when it fails.

Well, I know. I still think it could be made to "end there". I could
even imagine making 2) only support "by package URL", thus truly keeping
it simple.

> I don't have the bandwidth to invent another package management system:(
>
> My advice is to pick an existing system (javascript or smalltalk-based) and adapt it to Amber. I think that a javascript-based solution would give you traction with javascript developers and I think that could be an important selling point...

Sure, if there is one that fits.

> I do plan on continuing with amber-skeleton. amber-skeleton is using the current Amber client-side package model and I plan to continue to follow the Amber client-side package model where-ever it leads.

Good! I still think #1 above is already half way to the goal (common
model of meta data).

> Any changes you make to the package model must be coordinated with changes made to the development model ...
 > For example, you are using urls in your examples above, but you
haven't specified how the url will be translated to a specific file on disk

"translated"? A package is MyPackage.js. It is a file. It can be loaded
by Amber using a URL. How it is stored on that server is not of interest
here.

> or how you will be differentiating urls based on versions of the packages or ...

I will not differentiate. Perhaps I misunderstand you, but basically -
package A lists a dependency as a URL to say MyPackage.js. The URL has
no version or anything. Amber will fetch the contents of the URL (the
package file) and parse the start of it - thus getting all meta data
including the exact MyPackage version.

Now... if package B lists another URL as a dependency that load another
version of MyPackage then Amber will barf - "conflicting versions needed
for MyPackage!". And we are in the 10% barf land.

> In Metacello I have worked out answers to these questions and others ...

I know, but I still think Amber can have a small simple and still fairly
useful package model and resolver (albeit a trivial one) and still share
the metadata model with more ambitious systems.

> As I've said earlier, I think your best bet is to adopt/adapt an existing Smalltalk or Javascript model and live with it's particular quirks as a quirk-free dependency management system does not exits[1]:
>
>    Any sufficiently advanced dependency management system is
>    indistinguishable from Hell

Yup! A few years back I argued hard and long for keeping dependency
information outside of package files (so that one can change a dep
without creating a new version of a package) and a range of other
interesting arguments. These days I am also jaded and think that saying
"package == one file, metadata included, reachable by a single URL" is
good enough for 90% of the cases.

regards, Göran

Göran,

I guess I should just say that I am a member of the 10%....

I am not familiar with javascript-based development ... anything I bring to the table is based on 25+ years of Smalltalk development so I'm biased in the wrong direction:)

I encourage you to head in the best direction that you see fit ... but remember, you asked for my "take" and I gave it to you:).

My intention is to adapt my approach to whatever direction you decide to take ...

Dale

----- Original Message -----
| From: "Göran Krampe" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 6, 2012 4:45:56 PM
| Subject: Re: [amber-lang] Pushing Amber
|
| Hey again!
|
| On 06/05/2012 08:02 PM, Dale Henrichs wrote:
| > | From: "Göran Krampe"<[hidden email]>
| > | Mmmm, well, although I am all *for* any and all solutions ;) (the
| > | principle that we are too few to "stifle" any initiatives) I
| > | would
| > | prefer a "package model" that is independent of server solution.
| >
| > I'm inclined to agree, but the implementation of a
| > server-independent model is very much complicated by the disparity
| > in the supporting infrastructure between Node and Pharo.
|
| I am not sure I understand why it would have to be "very much
| complicated". I am merely asking us to come up with a very simple
| model
| of how a Package (do note that the class and concept is ALREADY
| there)
| is decorated with meta data and how we load them from Amber.
|
| > If you insist on being server-neutral, then your client-side model
| > will be limited by the capabilities of the lowest common
| > denominator.
|
| Well, let me put it this way - if I write an Amber package called say
| Deluxe-Collections then I would like to easily save and publish it on
| a
| URL so that everyone can use it. In ONE WAY. I don't want to have to
| do
| it in 5 different ways so that people using Node, Pharo, Rails or
| whatever backend-extra-tools can use it. One way must be enough.
|
| > Don't get me wrong, I am truly not disagreeing with this approach,
| > I'm just pointing out that developers with a desire for more
| > capabilities from the development model will be "forced to roll
| > their own" and for something as fundamental as the development
| > environment this might not be a great idea ...
| >
| > I'm definitely not suggesting that Metacello should be used in
| > Amber (Metacello is solving a different set of problems) ...
| > Metacello is a pragmatic choice on my part ... and will be the
| > quickest route to "rolling my own" dev environment for Amber ... I
| > plan using a Smalltalk-based server that already supports
| > Metacello for my Amber work, and with amber-skeleton, I'm well
| > along the way to having an integrated server/client development
| > environment that makes it real easy to share source code, the SCM
| > and package management.
| >
| >
| > | In fact, I would list a few properties that I would like:
| > |
| > | 1. Independent of server tech. :) Amber is already being used
| > | with
| > | non
| > | Smalltalk backends etc. And also with *no* backend.
| >
| > Are you talking about a _development environment_ that has no
| > backend?
|
| Yup. Someone already did some hack for local storage (and I have
| wanted
| to do it myself) and one could easily imagine the Amber IDE
| publishing
| packages straight up into the cloud somewhere, box.net or who knows.
|
| Having something running on localhost serving files is NOT going to
| be a
| prerequisite for long.
|
| > | 2. Very simple. It should IMHO be limited to the very smallest
| > | needed
| > | things, and not at all be aimed at the jungle of source code
| > | management.
| >
| > Unfortunately, source code management is a jungle ... side-stepping
| > source code management is an option, but your developers cannot
| > side-step the issue so easily, they are making SCM decisions right
| > now and have to have a working system ...
|
| Sure, but mixing SCM with package management is IMHO not a good idea.
| MC
| did it, but I still think it basically was a mistake. I want to be
| free
| to use whatever SCM tools I like and then publish a package in ...
| right, you guessed it - ONE WAY.
|
| > I'm not familiar enough with javascript to know whether there is a
| > well-accepted packaging model that already exists for javascript
| > ...
|
| There are several :). requirejs was mentioned, and yes, it is a good
| tool, we use it at our customer - but it is not aimed at "global
| packages" but rather "in project modules".
|
| CommonJS has been mentioned too - it is a collection of specs IIUIC
| for
| among other things, modules. But again, mainly in the sense of
| requirejs.
|
| > IMHO, adopting/adapting the javascript model would be the best
| > choice for Amber ...
|
| I agree. We should try to use js "ways" when they fit. In this
| particular case I am not sure I have yet seen what the "js way" is
| though - npm is close, but... I need to look more.
|
| > Reinventing the wheel is the most fun, but adapting/adopting an
| > existing model gets the job done...
|
| I am with you on this.
|
| > |
| > | 3. Have a working dependency model. But I think it should be
| > | along
| > | the
| > | "works in 90% of the cases, easily overridden for the other 10%".
| > |
| >
| > In my experience, specifying the dependency is not the hard part
| > ... resolving dependencies (finding the correct versions of the
| > files),
|  > honoring the dependencies (saving the files where they came from)
|  > and
| loading the files (detecting dependency loops and version conflicts)
|  > are the nasty bits, that make SCM a jungle.
|
| Yes, and I have been involved in a LOT of discussions about this
| earlier
| (SM), which is why I say 90%. I only would care for the simple cases
| and
| plainly just barf when it fails.
|
| > | Now, if we follow the above this could hopefully still work
| > | *together*
| > | with server side solutions. For example, one approach would be:
| > |
| > | 1. Establish a minimum set of package meta data, perhaps for the
| > | package
| > | called 'MyPackage' it could be:
| > |
| > | url ->  'http://wherever/MyPackage.js'.
| > | license ->  'http://wherever/License.txt'.
| > |   "best is probably a URL to the license text or the license text
| > |   itself"
| > | author ->  'Göran Krampe<[hidden email]>'.
| > | version ->  '1.24 alpha'                    "no specific rules"
| > | dependencies ->  {'OtherPackage'. 'OneMorePackage' ->  '1.01'}
| > |
| > | 2. Build a very simple dependency resolver. If we support:
| > | a) Dependency by package name  (Amber will try to find it)
| > | b) Dependency by package URL   (Amber will simply use URL)
| > | b) Dependency with criteria    (...sky is limit here)
| > |
| >
| > Göran, this is how Metacello started:)....3 years ago ... trust
| > me... it doesn't end there:)
|
| Well, I know. I still think it could be made to "end there". I could
| even imagine making 2) only support "by package URL", thus truly
| keeping
| it simple.
|
| > I don't have the bandwidth to invent another package management
| > system:(
| >
| > My advice is to pick an existing system (javascript or
| > smalltalk-based) and adapt it to Amber. I think that a
| > javascript-based solution would give you traction with javascript
| > developers and I think that could be an important selling point...
|
| Sure, if there is one that fits.
|
| > I do plan on continuing with amber-skeleton. amber-skeleton is
| > using the current Amber client-side package model and I plan to
| > continue to follow the Amber client-side package model where-ever
| > it leads.
|
| Good! I still think #1 above is already half way to the goal (common
| model of meta data).
|
| > Any changes you make to the package model must be coordinated with
| > changes made to the development model ...
|  > For example, you are using urls in your examples above, but you
| haven't specified how the url will be translated to a specific file
| on disk
|
| "translated"? A package is MyPackage.js. It is a file. It can be
| loaded
| by Amber using a URL. How it is stored on that server is not of
| interest
| here.
|
| > or how you will be differentiating urls based on versions of the
| > packages or ...
|
| I will not differentiate. Perhaps I misunderstand you, but basically
| -
| package A lists a dependency as a URL to say MyPackage.js. The URL
| has
| no version or anything. Amber will fetch the contents of the URL (the
| package file) and parse the start of it - thus getting all meta data
| including the exact MyPackage version.
|
| Now... if package B lists another URL as a dependency that load
| another
| version of MyPackage then Amber will barf - "conflicting versions
| needed
| for MyPackage!". And we are in the 10% barf land.
|
| > In Metacello I have worked out answers to these questions and
| > others ...
|
| I know, but I still think Amber can have a small simple and still
| fairly
| useful package model and resolver (albeit a trivial one) and still
| share
| the metadata model with more ambitious systems.
|
| > As I've said earlier, I think your best bet is to adopt/adapt an
| > existing Smalltalk or Javascript model and live with it's
| > particular quirks as a quirk-free dependency management system
| > does not exits[1]:
| >
| >    Any sufficiently advanced dependency management system is
| >    indistinguishable from Hell
|
| Yup! A few years back I argued hard and long for keeping dependency
| information outside of package files (so that one can change a dep
| without creating a new version of a package) and a range of other
| interesting arguments. These days I am also jaded and think that
| saying
| "package == one file, metadata included, reachable by a single URL"
| is
| good enough for 90% of the cases.
|
| regards, Göran
|

Hey!

On 06/07/2012 02:39 AM, Dale Henrichs wrote:
> Göran,
>
> I guess I should just say that I am a member of the 10%....

Perhaps it turns out we all are :)

> I am not familiar with javascript-based development ... anything I bring to the table is based on 25+ years of Smalltalk development so I'm biased in the wrong direction:)

I can only refer to 18 years of Smalltalk, and perhaps one year of
javascript. ;)

> I encourage you to head in the best direction that you see fit ... but remember, you asked for my "take" and I gave it to you:).

Yeah, I want your take. And others. And I am not decided yet - but we do
have Package class and it does have abilities to keep meta data in both
js and st. We have that today. We should use it.

And the next logical steps seems to be:

- What meta data do we want? Decide on it.

- What is the simplest way possibly to publish and load a package?

IMHO the simplest way to publish must be to just place it at a URL - we
can skip that step right now and just do it manually or whatever. And
the simplest way to load must be from Amber itself directly from the
URL, that must be trivial.

- What is then the simplest dependency resolver?

Well, I guess it must be having dependencies directly by URL (no
"finding" stuff) and then simply collect all dependencies recursively
and barf on any version conflict of the same package.

> My intention is to adapt my approach to whatever direction you decide to take ...
>
> Dale

Cool, and please yell if I am doing something that makes your life
harder - that is not my intention at all. I presume agreeing on metadata
is crucial, but if we do that then I can't see that having an Amber
client side simple resolver/loader is a bad thing?

Also finally, last night I discovered this and we should definitely take
a hard look at it:

        ender.no.de

Also, regarding requirejs etc, that is just one of several loaders, we
should probably not hardwire us against it. And also, it does not really
deal with the "higher level" of package distribution and discovery, but
rather "intra project" dependency loading etc.

regards, Göran

+1 for the debugger (with breakpoint - yes you can simulate it with self halt)

If you are looking for method-level versioning for Amber then checkout amber-skeleton[1]. It uses Cypress package format[2] to store Amber smalltalk source and Cypress gives you method level versioning in git ...

Dale

[1] https://github.com/dalehenrich/amber-skeleton
[2] https://github.com/CampSmalltalk/Cypress
----- Original Message -----
| From: "Zhijiang Han" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, June 26, 2012 11:06:16 AM
| Subject: Re: [amber-lang] Re: Pushing Amber
|
| +1 for the debugger (with breakpoint - yes you can simulate it with
| self halt)
| But it is all about productivity, specially to minimize the friction
| on worrying
| about the artifacts that you need to maintain while trying to solve a
| business
| problem.
|
|
|
| On to the debugger, I am not sure whether this is been reported /
| addresed
| but if Smalltalk exception were thrown during loadAmber, the debugger
| context
| does not correctly reflect the Smalltalk call stack (it only starts
| with the offending
| call, e.g. self halt, but does not show where the call is made in the
| Smalltalk
| code). I think it might have something to do with the way theContext
| was set
| in boot.js but was not able to make much progress beyond that. If
| someone
| could give me a pointer as to what it would take to fix it I would be
| glad to do so.
|
| As someone who did Smalltalk long time ago and just discovered amber,
| please excuse me if some or any of these topics have already been
| discussed.
| Some other random thoughts on improving productivity:
| 1. Refactoring browser (cannot live without it)
| 2. Server side Smalltalk and being able to deploy/debug server side
| code from the same IDE
| - Seamless client / server communication (i.e. I do not want to write
| additional code to move a class from client to server, or vice
| versa)
| 3. Objectized css with auto deploy / refresh (i.e. I do not want to
| write css in another IDE)
|
| 4. Version control from within IDE (there was a separate thread in
| which I suggested ENVY
| but I understand the need for a less radical approach so git is a
| natural choice - I could talk
| separately about why I prefer method level versioning).
|
|
| On Sunday, June 3, 2012 10:28:20 AM UTC-4, Janko Mivšek wrote:
|
|
|
| Very well said, Sebastian!
|
| On 01. 06. 2012 22:22, Sebastian Sastre wrote:
| > I personally would prefer sweetness over nerdness.
| >
| > What I mean is that I prefer not having any too technical fancyness
| > over
| > a great development experience that leads to a more qualified
| > creativity
| > process powered by amber.
| >
| > People hate IE for many reasons (that are ridiculously nerdy) and,
| > in
| > the other hand,love the WebKit tool for a reason. And I think amber
| > has
| > the chance to provide an even better experience for developing
| > software
| > than WebKit.
| >
| > But if we jump into specializations and complications that too few
| > people know about too soon, and maintain our attention out of this
| > idea
| > about rewarding creativity, I'm afraid that it will lead us into a
| > path
| > of compartmentalization instead of a sweet creative process which
| > would
| > be ironic because smalltalk was originally conceived to reward the
| > creative spirit.
| >
| > Now to illustrate my point in a practical way:
| > I totally can live without pragmas and traits, etc but having a
| > little
| > redesigned IDE and a stepping debugger will skyrocket productivity
| > and
| > what happens when you skyrocket productivity? you can do more apps
| > for
| > more clients. And what happens when you can do more apps for more
| > clients? quantity lead you to quality so you end up working better
| > and
| > with even better chances of doing great work.
| >
| > my 2 cents
| >
| > sebastian
| >
| >
| > Em quarta-feira, 30 de maio de 2012 11h47min23s UTC-3, nicolas
| > petton
| > escreveu:
| >
| >
| > Hi guys!
| >
| > I would really like to push Amber more. We have quite some
| > interesting
| > stuff. Here's some ideas/ongoing stuff
| >
| > - new imperative compiler from Herby (I have a new compiler
| > toolchain
| > inspired by Opal that reuses his ideas, I have to finish and
| > commit it)
| > - New website from John
| > - Better packages (with doc) from Göran?
| > - More doc
| > - Better IDE using Glamour?
| > - Coral integration? (I'm tired of the chunk format, and Pharo will
| > use
| > Coral in the future)
| > - Better client/server communication (I'd love to have a really
| > good
| > Pharo/Amber communication, and for example be able to browse Amber
| > from Pharo w/ Nautilus)
| > - Traits?
| > - Pragmas?
| > - other things...?
| >
| > Now pull requests are great, but I think we could improve the dev
| > process.
| >
| > So would some of you like to join the effort and help making
| > Amber better? Any suggestion about a better dev process?
| >
| > Cheers,
| > Nico
| >
| -- Janko Mivšek Aida/Web Smalltalk Web Application Server
| http://www.aidaweb.s
|

Regarding the reference ¨quirk¨ below, a quick fix