How to port amber 0.11 code w/o namespaces to 0.12?

[Oscar Nierstrasz]

Hi folks,

I am trying to get RoassalAmber to run in Amber 0.12. The problem is that the original code did not use namespaces, so the compiled JS files are missing this information. What is the right way to proceed?

- re-compile the st files with amberc? [didn't work I just got a mysterious 30330 error code]
- filein the st files one by one? [didn't work. JavaScript exception: TypeError: Cannot read property 'fn' of null]
- write a perl script to patch the JS files, adding the missing namespace information? [didn't try this yet]

There is a probably an easy way I have not thought of yet. Any hints are welcome.

Oscar

[Herby Vojčík]

Oscar Nierstrasz wrote:
> Hi folks,
>
> I am trying to get RoassalAmber to run in Amber 0.12. The problem is that the original code did not use namespaces, so the compiled JS files are missing this information. What is the right way to proceed?
>
> - re-compile the st files with amberc? [didn't work I just got a mysterious 30330 error code]

Recompile is the right way.

There's a "migration from 0.11" section in changelog, pasting:

* Migration from Amber 0.11.0

First, the loading of JavaScript files must be adapted. The custom loader has been replaced with
requirejs for loading files in the browser. New loader code is thouroughly
explained in [4].

After updating the loader part, `.st` files need to be recompiled
into new AMD `.js` files. During loader changes, a namespace was choosen and will be needed for recompilation.

Go to your directory with `.st` files and issue this from the shell:

```sh
<path-to-amber>/bin/amberc -l SUnit,Canvas -n <chosen-namespace> -D <path-f
or-compiled-js-files> *.st
```

In windows, use `\` as path separator, the rest is identical.

The `-l SUnit,Canvas` is just a general guess, if your code depends on more (or less) non-kernel packages from amber, list them here accordingly.

This migrate scenario only covers simple deployments with your project's code and amber.
If your project is more complicated, using libraries and packages from multiple sources,
it is hard to give general advices to migrate - you must do it library by library,
giving each location its own namespace, and `-L` option of `amberc`
comes handy when integrating; ask on the mailing list if problems arise.

[1] http://requirejs.org/
[2] http://bower.io/
[3] https://github.com/amber-smalltalk/brikz
[4] https://github.com/amber-smalltalk/amber/wiki/How-to-load-amber

> - filein the st files one by one? [didn't work. JavaScript exception: TypeError: Cannot read property 'fn' of null]
> - write a perl script to patch the JS files, adding the missing
namespace information? [didn't try this yet]
>
> There is a probably an easy way I have not thought of yet. Any hints are welcome.
>
> Oscar

Herby

[Nicolas Petton]

Hi guys,

I put it on the wiki here:
https://github.com/amber-smalltalk/amber/wiki/Migration-from-0.11-to-0.12

Cheers,
Nico

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

[Manfred Kröhnert]

Hi,

On Thu, Dec 5, 2013 at 8:35 PM, Oscar Nierstrasz <oscar.ni...@gmail.com> wrote:

Hi folks,

I am trying to get RoassalAmber to run in Amber 0.12. The problem is that the original code did not use namespaces, so the compiled JS files are missing this information. What is the right way to proceed?

- re-compile the st files with amberc? [didn't work I just got a mysterious 30330 error code]

did you get any further in recompiling Roassal on Amber for 0.12?

You have to keep in mind that it is currently important to specify the .st files in the correct order of their dependencies.

Or compile them one by one.

If you face compiler errors it would be nice if you could report them so we can take a look and fix them.

Best,

Manfred

[Oscar Nierstrasz]

Hi Folks,

I was away for some days and did not have a chance to look at this until now.

According to Pablo Estefó I should first compile Roassal-Amber-Extensions.st:


+ D=/Users/oscar/Desktop/amber-projects/roamber12
+ B=/Users/oscar/Desktop/amber-projects/roamber12/bin
+ R=/Users/oscar/Desktop/amber-projects/roamber12/projects/roamber
+ cd /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/st
+ /Users/oscar/Desktop/amber-projects/roamber12/bin/amberc -l SUnit -n roamber -D /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/js Roassal-Amber-Extensions.st
Importing: Roassal-Amber-Extensions.st

undefined:30330
throw anError;
^
Error:
+ exit


This is the same error message I have been getting all along though. Any idea what this means?

Roassal-Amber-Extensions.st is the file-out from the Amber 0.11 project.

https://github.com/pestefo/roamber/blob/master/projects/roamber/st/Roassal-Amber-Extensions.st

Oscar

> --
> 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 amber-lang+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Dave Mason]

My experience is that you need to compile with verbose mode ( amberc -v ...) which produces a ridiculous amount of output, but buried in there you will see the real problem with your code.

../Dave

../Dave

[Nicolas Petton]

Hi guys,

I think it's time to improve that :)

Without the verbose option on amberc should provide a decent output in
case of error.

https://github.com/amber-smalltalk/amber/issues/770

Nico

[Oscar Nierstrasz]

OK, turning on the -v flag to amberc helps a bit, but not much. I have no idea why the compiler is trying to send #methodsFor: to nil.

Is there a way to debug this interactively?

Cheers,
Oscar

oscar@macumba 3: q

+ D=/Users/oscar/Desktop/amber-projects/roamber12
+ B=/Users/oscar/Desktop/amber-projects/roamber12/bin
+ R=/Users/oscar/Desktop/amber-projects/roamber12/projects/roamber
+ cd /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/st

+ /Users/oscar/Desktop/amber-projects/roamber12/bin/amberc -v -l SUnit -n roamber -D /Users/oscar/Desktop/amber-projects/roamber12/projects/roamber/js Roassal-Amber-Extensions.st
Checking: Roassal-Amber-Extensions.st
Resolving: boot.js
...
Resolving: SUnit.js
Loading file: /Users/oscar/Desktop/amber-projects/roamber12/support/boot.js
...
Loading file: /Users/oscar/Desktop/amber-projects/roamber12/js/SUnit.js
Compiler loaded
Compiling collected .st files
Importing: Roassal-Amber-Extensions.st
Importer >> import:
BlockClosure >> whileFalse:
BlockClosure >> value
a block (in Importer >> import:)
Compiler >> evaluateExpression:
Compiler >> evaluateExpression:on:
DoIt >> xxxDoIt
BlockClosure >> value
a block (in DoIt >> xxxDoIt)
UndefinedObject >> doesNotUnderstand:
nil does not understand #methodsFor:

undefined:30330
throw anError;
^
Error:
+ exit

[Javier Pimás]

I once got a similar error (not sure if it's the same). My problem was I had

foo

   bar := 'something'

instead of

foo 

   | bar |

   bar := 'something'

Anyway, I found it by deleting changes by hand from the file (in your case Roassal-Amber-Extensions.st) until I detected the change which caused the error. If you try that, make sure not to delete the last ! of the file

Cheers,

Javier.

Lic. Javier Pimás
Ciudad de Buenos Aires

[Herby Vojčík]

Oscar Nierstrasz wrote:
> OK, turning on the -v flag to amberc helps a bit, but not much. I have no idea why the compiler is trying to send #methodsFor: to nil.

That's easy - it sends it to a class it tries to define extension
methods for. But, that class is not known. You missed some dependent
packages in -l (and then you may as well need to supply paths to find it
in -L).

It's nearly always about this. Fill in all dependencies in -l and it
works. Sometimes it does not help and there is really some problem in
code (most often unknown global used in code), but that is shown by -v
and you can fix it.

Herby

[Oscar Nierstrasz]

Thanks for the suggestion. I will try it.

But did something else change between 0.11 and 0.12? All these files compiled before. What is new that would cause them not to compile anymore? (That would help me to track down the problem too.)

Oscar

[Herby Vojčík]

Oscar Nierstrasz wrote:
> But did something else change between 0.11 and 0.12? All these files compiled before. What is new that would cause them not to compile anymore? (That would help me to track down the problem too.)

I don't really known when, I think it was earlier, but things that invalidated some old code I remember are two: first, free inline JS was banned (either the whole method is inline JS, or it is fully Smalltalk), and the second is stricter globals checks (you cannot compile a method that uses lowercase-started variable that is not known at compile time or listed among a few exceptions - that catches things Javier mentioned, and -v writes the details down in this case).

Otherwise, .st file should be compilable, IMO.

Herby

> Oscar

[Nicolas Petton]

Hi,

The .st files are compatible between 0.11 and 0.12.

Oscar, if the files you are trying to compile are opensource, I can give
it a try if you send me an email :)

Cheers,
Nico

Herby Vojčík writes:

[Oscar Nierstrasz]

-v did not give me any useful information. If there is a missing dependency, the compiler should report what it is looking for that it does not find!

I'll try to find out if there are other dependencies that are missing …

Oscar

[Nicolas Petton]

The CLI compiler could give better informations, I agree.
I created an issue here[1] in order to improve that.

[1] https://github.com/amber-smalltalk/amber/issues/770

Cheers,
Nico

[Herby Vojčík]

Oscar Nierstrasz wrote:
> -v did not give me any useful information. If there is a missing dependency, the compiler should report what it is looking for that it does not find!

The compiler did not know the semantics (though it may guess, like "when
I am trying to send #methodsFor: to nil, something's wrong - but even
then, it will not tell you the dependent package, just the class name
which it resolved to nil); importing chunk format just means running the
code blindly (creating the reader, which then reads the subsequent
chunkss itself; as is the case of methodsFor: creating method reader;
that code run blindly to create reader fails with methodsFor: sent to nil).

Extension methods are always at the end of the file, so look there to
find 'BlahBlah methodsFor: '*MyPackage'.

> I'll try to find out if there are other dependencies that are missing …
>
> Oscar

Herby

[Oscar Nierstrasz]

Thanks for all the pointers! I wrote a small utility to extract the dependencies between packages (fileouts) and now I am able to compile many (but not all) packages.

BTW, the dependency extraction utility might be useful to others:

http://smalltalkhub.com/#!/~onierstrasz/PackageSort

It is not very fancy. There is shell script that greps the .st files for the subclass: and methodsFor: declarations, and converts those into Smalltalk code that builds the dependency graph. It then tells you for each package (file out) which other packages it depends on. That's all you need to know to compile things in the right order.

Oscar

[Nicolas Petton]

Seems quite neat, thanks for sharing it!

Cheers,
Nico

Oscar Nierstrasz writes:

[Oscar Nierstrasz]

Ah, of course it does not look at the internal dependencies within methods to other classes.

I suspect with a couple of hours work this could be turned into a much more useful utility. If I have some "spare" time, I will see what I can do.

Oscar