Packages brainstorming for Amber 1.0

Hi guys,

There's been some discussion about packages on Github, and I'd like to move it here.

Basically, packages as they are today as well as Amber's loader (in js/amber.js) don't work.
They are complicated to use, undocumented, and not flexible enough.
Also, they need some cleanup.

An idea would be to split the concept of package from class category.

As an example, the Kernel package would contain all Kernel-* class categories.

Then, when it comes to paths and commtting, I'd like to add something similar to require.js using one manifest JSON file per package.
The JSON file would describe the version of the package, it's relative commit paths for Smalltalk and JavaScript files, and a possible documentation of the package.

It could look like this:

{
        "name": "Kernel",
        "version": "1.1",
        "files": [ "Kernel-Objects", "Kernel-Classes", ... ],
        "paths": {
                "js": "kernel/js",
                "st": "kernel/st"
        },
        "dependencies": [ "MyOtherPackage" ],
        "documentation": "This is a cool package because..."
}

Then loadAmber() would make it easy to load packages and/or individual files (not packaged).

Cheers,
Nico

Hi Nico,
To be honest I am quite comfortable with the current packaging architecture. It makes easy to reference different versions of amber and make swift deployment. By the way one killer feature of amber/smalltalk is ease of development of SPA - Single Page Applications.

Anyway I have two separate web pages for each single page application.
One page for development and another page for production.

The two pages are including the necessary CSS and third party JS files.
The difference is in referencing amber.js file and the script to startup amber IDE versus amber application.

For the development page I have something like that:

<script src="/amber/amber-V0.2/js/amber.js" type="text/javascript"></script>
<script type="text/javascript">
 loadAmber({
  files: ['amber-projects/kidville/js/KVPartyMan.js',
        'amber-projects/kidville/js/Cookie.js',
        'amber-projects/kidville/js/Bootstrap.js',
        'amber-projects/kidville/js/JQGridV0a.js',
        'amber/amber-master/projects/bootstrap/js/Knockout.js'
        ],
      prefix: '../..',
      ready: function() {
       $(function () {
        smalltalk.Browser._open();
        smalltalk.Knockout._prepare();
        smalltalk.Navbar._partyManager_('#navbar_content');
       });
      }
    });
</script>

For the production page - published for the client - I have something like that:

  <script src="/amber/amber-V0.2/js/amber_KV_PartyManV0a.js" type="text/javascript"></script>
  <script type="text/javascript">
    $(document).ready(function(){
      smalltalk.Knockout._prepare();
      smalltalk.Navbar._partyManager_('#navbar_content');
    });
  </script>

When packages of the development page are committed the production amber file - amber_KV_PartyManV0a.js - gets created/updated - see my note in thread "Ways to develop webapp that uses amber".

My folder structure is set up to maintain different amber versions and easily switch between them.
Relative to server root directory it looks like that:
  amber
    amber-V0.1
      js
    amber-V0.2
      js
  amber-projects
      project1
        js
        st
      project2
        js
        st

I wonder if there is better approach than that.
Will the new packaging you are thinking about fit with this development cycle?
Cheers,
 laci

Nicolas Petton wrote:
> Hi guys,
>
> There's been some discussion about packages on Github, and I'd like to move it here.
>
> Basically, packages as they are today as well as Amber's loader (in js/amber.js) don't work.
> They are complicated to use, undocumented, and not flexible enough.

With the addition of paths and multiple sources, I would not say it is
not flexible enough.

> Also, they need some cleanup.
>
> An idea would be to split the concept of package from class category.
>
> As an example, the Kernel package would contain all Kernel-* class categories.
Sorry for being too conservative, but this can be optimized by
concatenation. Even automatically. All Kernel-* to Kernel, etc.
I fear it gets too complicated and it will load slow. You must get the
manifest and after that get the js file.

If you want the big change, rather embrace AMD completely:

// maybe some details are wrong, but:
define(["MyOtherPackage"], function (MyOtherPackage) {
   // the contents of the package file
});

and use require.js. They, at least, can do it fast (load async, run
whenever all dependencies are present).

> Cheers,
> Nico

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Hi!

My proposal for a new loader evolved from the actual one is here:
https://github.com/amber-smalltalk/amber/wiki/On-Loader2.

If there is need for bigger, more revolutionary change, that I would
embrace AMD and put require.js in (but I don't see all the pitfalls it
can bring).

Herby

Nicolas Petton wrote:
> Hi guys,
>
> There's been some discussion about packages on Github, and I'd like to move it here.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

The question is also to know if we want to split packages from class categories. If not (I don't know yet, I'm just thinking out loud), then your proposal looks good to me :)

Nico


On Mar 6, 2013, at 12:16 PM, Herby Vojčík <[hidden email]> wrote:

--
Nicolas Petton
http://www.nicolas-petton.fr

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Nicolas Petton wrote:
> The question is also to know if we want to split packages from class
> categories. If not (I don't know yet, I'm just thinking out loud),
> then your proposal looks good to me :)

I can imagine Kernel.js or Kernel.all.js generated with code that finds
out path (this is hard in case of $.ajax, but easy in case of <script>),
and inserts <script>s for all subpackages into <head> at the beginning,
so they are executed before anything other. I don't know for sure, but
from what I know the execution is in DOM order and I can get ahead in
execution queue by inserting <script> up. Well, it slows page load, but
if it was in some kind of descriptive manifest, it would anyway.

Kernel.all.js can be concatenation, too; but the indirect one from above
need no change unless you add/delete subpackage.

Herby

P.S.: But it is probably others who should say if they see spitting
categories (as in IDE and probably also in FS*) from packages (as items
in loader) beneficial.

* It would be scary to have all Kernel-* in one .st file, so I think
they are still planned to store by-category.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

When we are at the brainstorming, it is really a bit orthogonal to the
actual adoption of require.js or not, but I would like to see .js files
as we know them wrapped. Something like:

```js
define('amber:IDE', ['amber:', 'amber:Canvas', ... other deps], function
(smalltalk) { // no need to name others, won't be used
     var nil = smalltalk.nil,
         $val = function () { /* what now is _st */ },
         $ctx = smalltalk.withContext; // saves space, higher readability
         // eventually bind this ^^^ if needed

     // The code which is now in .js, verbatim

     return ...the package...;
});
```

This is the AMD syntax. It is good syntax per se, even without
require.js or other third-party loader. We can write loader that defines
`define` and uses dependency information for full async loading,
respecting amber specifics, ourselves (I am _not_ talking about full AMD
conformance, just our syntax, nothing more; or write resolve plugin for
require.js, use our loader syntax and just use it to set up require.js,
because the syntax is conforming).

What is main plus of this for me (I pondered it some time already) is
that there is no more any use of global `smalltalk` (it is a passed
dependency) nor globals `nil` and `_st` (derived from the passed
`smalltalk` dependency). That said, boot.js can just define the
Smalltalk class, but do nothing, and another file which plays the role
of 'amber:' should instantiate, initialize and return it. I already said
in the past I would like to make Smalltalk instances non-global, this
could really help to achieve it.*

Herby

*But since the loader API can stay unchanged, it could probably be done
after release as well. I would maybe add it to 0.12 goals (Nico are you
sure there will be 1.0 after 0.10? I believe more in a few more 0.even
versions).

Nicolas Petton wrote:
> Hi guys,
>
> There's been some discussion about packages on Github, and I'd like
> to move it here.
>
> Cheers, Nico

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

On Mar 6, 2013, at 2:03 PM, Herby Vojčík <[hidden email]> wrote:

> Nico are you sure there will be 1.0 after 0.10?


Depends: If we release more often, then yes, we can have a few more releases before 1.0.

Nico

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.