Smalltalk › Amber Smalltalk

More compiler inconsistency with unknown globals

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Tom Rake

More compiler inconsistency with unknown globals

I compiled a method two ways and got an error one way and not the other.

I just compiled cli/AmberCli,st as part of pull request #622 with

grunt amberc:amber_cli

Next I opened cli/index.html which now opens a browser. In the class FileServer there is a the method require:

require: aModuleString

"call to the require function"

^require value: aModuleString

I did my recompile monkey act and added a space inside the comment. At this point I got an errorUnknownVariable on require. This is another (un)known global issue, grunt amberc ignored the known global while the IDE compiler caught it.

As for require: this is really a node require() request. So I will rewrite the method as:

require: aModuleString

"call to the require function"

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

Herby Vojčík

Re: More compiler inconsistency with unknown globals

Any global except well-known ones must exist to be accepted. So, inside browser method with require global cannot be compiled, but fro,m cli it can (since cli is node-based and node defines require).

Herby

Thomas Rake wrote:

> I compiled a method two ways and got an error one way and not the other.
>
> I just compiled cli/AmberCli,st as part of pull request #622 with
> grunt amberc:amber_cli
>
> Next I opened cli/index.html which now opens a browser. In the class
> FileServer there is a the method require:
>
> require: aModuleString
> "call to the require function"
> ^require value: aModuleString
>
>
> I did my recompile monkey act and added a space inside the comment. At
> this point I got an errorUnknownVariable on require. This is another
> (un)known global issue, grunt amberc ignored the known global while
> the IDE compiler caught it.
>
> As for require: this is really a node require() request. So I will
> rewrite the method as:
>
> require: aModuleString
> "call

to the require function"
> <return require(aModuleString);>
>
> --
> 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.

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

Tom Rake

Re: More compiler inconsistency with unknown globals

In reply to this post by Tom Rake

It seems these topics are mixed in my mind so I want to explain how I got to pull request #622 and I believe with a little work I can build a stand along node version of the FileServer outside of the Cli.

https://github.com/amber-smalltalk/amber/pull/622

I think the compiler should covert amber source to .js files and that being browser based or node based is a matter for a subsequent linkage resolution. Smalltalk avoided these issues with "the image" where all symbols could be resolved. With javascript as our target we need to address the "assembly language" like issues of declared and external symbols if we want to have softrware modules.

I have been "javascript methodizing" basically <return require(aSymbol);> any node globals. This allows those globals to be accessed inside amber and still compile in the Browser IDE. Typically by a self require:'aString' in the amber code.

On Saturday, August 24, 2013 7:04:37 PM UTC-4, Thomas Rake wrote:

I compiled a method two ways and got an error one way and not the other.

I just compiled cli/AmberCli,st as part of pull request #622 with
grunt amberc:amber_cli

Next I opened cli/index.html which now opens a browser. In the class FileServer there is a the method require:

require: aModuleString
"call to the require function"
^require value: aModuleString

I did my recompile monkey act and added a space inside the comment. At this point I got an errorUnknownVariable on require. This is another (un)known global issue, grunt amberc ignored the known global while the IDE compiler caught it.

As for require: this is really a node require() request. So I will rewrite the method as:

require: aModuleString
"call to the require function"
<return require(aModuleString);>

Herby Vojčík

Re: More compiler inconsistency with unknown globals

You should not make things this complex. There is an API for telling
amber that a certain global is well-known. Just tell it that require is
fine, in index.html's ready function, for example.

There should be methods somewhere in Smalltalk class, Manfred should
know more.

So it's just a matter of adding

smalltalk._theApiTellingThisIsKnownGlobal_("require");

to ready function in amber loader.

Thomas Rake wrote:

> It seems these topics are mixed in my mind so I want to explain how I
> got to pull request #622 and I believe with a little work I can build
> a stand along node version of the FileServer outside of the Cli.
>
> https://github.com/amber-smalltalk/amber/pull/622
>
> I think the compiler should covert amber source to .js files and that
> being browser based or node based is a matter for a subsequent linkage
> resolution. Smalltalk avoided these issues with "the image" where all
> symbols could be resolved. With javascript as our target we need to
> address

the "assembly language" like issues of declared and external

> symbols if we want to have softrware modules.
>
> I have been "javascript methodizing" basically <return
> require(aSymbol);> any node globals. This allows those globals to be
> accessed inside amber and still compile in the Browser IDE. Typically
> by a self require:'aString' in the amber code.
>
>
> On Saturday, August 24, 2013 7:04:37 PM UTC-4, Thomas Rake wrote:
>
> I compiled a method two ways and got an error one way and not the
> other.
>
> I just compiled cli/AmberCli,st as part of pull request #622 with
> grunt amberc:amber_cli
>
> Next I opened cli/index.html which now opens a browser. In the
> class FileServer there is a the method require:
>
> require: aModuleString
> "call to the require function"
> ^require value: aModuleString
>
>
> I did my recompile monkey act and added a space inside the
> comment. At this point I got an errorUnknownVariable on requ

ire.

> This is another (un)known global issue, grunt amberc ignored the
> known global while the IDE compiler caught it.
>
> As for require: this is really a node require() request. So I will
> rewrite the method as:
>
> require: aModuleString
> "call to the require function"
> <return require(aModuleString);>
>
> --
> 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.

Manfred Kröhnert

Re: More compiler inconsistency with unknown globals

Yes,

there are methods defined on the Smalltalk object.

They are called #addGlobalJsVariable: and #deleteGlobalJsVariable:.

Also see the reference on the issue tracker.

Best,

Manfred

On Sun, Aug 25, 2013 at 5:29 PM, Herby Vojčík <[hidden email]> wrote:

You should not make things this complex. There is an API for telling amber that a certain global is well-known. Just tell it that require is fine, in index.html's ready function, for example.

There should be methods somewhere in Smalltalk class, Manfred should know more.

So it's just a matter of adding

smalltalk._theApiTellingThisIsKnownGlobal_("require");

to ready function in amber loader.

Thomas Rake wrote:

It seems these topics are mixed in my mind so I want to explain how I
got to pull request #622 and I believe with a little work I can build
a stand along node version of the FileServer outside of the Cli.

https://github.com/amber-smalltalk/amber/pull/622

I think the compiler should covert amber source to .js files and that
being browser based or node based is a matter for a subsequent linkage
resolution. Smalltalk avoided these issues with "the image" where all
symbols could be resolved. With javascript as our target we need to
address

the "assembly language" like issues of declared and external

symbols if we want to have softrware modules.

I have been "javascript methodizing" basically <return
require(aSymbol);> any node globals. This allows those globals to be
accessed inside amber and still compile in the Browser IDE. Typically
by a self require:'aString' in the amber code.

On Saturday, August 24, 2013 7:04:37 PM UTC-4, Thomas Rake wrote:

I compiled a method two ways and got an error one way and not the
other.

I just compiled cli/AmberCli,st as part of pull request #622 with
grunt amberc:amber_cli

Next I opened cli/index.html which now opens a browser. In the
class FileServer there is a the method require:

require: aModuleString
"call to the require function"
^require value: aModuleString

I did my recompile monkey act and added a space inside the
comment. At this point I got an errorUnknownVariable on requ

ire.

This is another (un)known global issue, grunt amberc ignored the
known global while the IDE compiler caught it.

As for require: this is really a node require() request. So I will
rewrite the method as:

require: aModuleString
"call to the require function"
<return require(aModuleString);>

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

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