Compiler internals

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiler internals

Siemen Baader
Hi list,

I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc.

Specifically, I want:

    aBlockClosure 
        smalltalkSource    "gives [ :bar |  bar * 2 ] "
        smalltalkSource: '[ :foo | foo + 42 ]'  " sets & recompiles the source"

I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM?

    aBlockClosure scope  "some sort of dictionary that lets us access the bound variables"

Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem?

Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated?

I see that Compiler >> compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks not compiled directly?

The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first.

best,
Siemen


----

Siemen Baader
PhD Fellow

Department of Computer Science
Aarhus University
Aabogade 34
DK-8200 Aarhus N

office: ADA 125
email: [hidden email]
phone: +45 60 65 70 79




--
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/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Compiler internals

Herby Vojčík
BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.

Herby

Siemen Baader wrote:

> Hi list,
>
> I am constructing smalltalk expressions and saving them into an object
> using Blocks in a Domain Specific Language. Later, I want to revise
> the content of these Blocks, so I'm trying to modify the compiler to
> access and revise the smalltalk source of existing BlockClosure
> objects. But I don't have enough of a big picture of the compiler
> architecture -- the IR, AST and the Compiler-Interpreter packages etc.
>
> Specifically, I want:
>
> aBlockClosure
> smalltalkSource "gives [ :bar | bar * 2 ] "
> smalltalkSource: '[ :foo | foo + 42 ]' " sets & recompiles the source"
>
> I guess this also requires us to have access to the closed-over local
> variables in the BlockClosure, right? Is this possible with the VM?
>
> aBlockClosure scope "some sort of dictionary t
hat lets us access the

> bound variables"
>
> Could anyone explain the compiler's design for me and point out where
> to look to make the specific modifications to solve my problem?
>
> Does BlockClosure hold runtime references to the local and instance
> variables that are bound when it is evaluated?
>
> I see that Compiler >> compileExpression uses the DoIt class and adds
> a new method to it to encapsulate the current expression in a block.
> Isn't that a detour / why are blocks not compiled directly?
>
> The class Compiler is a good starting point. What do you think of
> putting the high-level documentation and links to the relevant
> background references into the Compiler class documentation text? I
> could do that if somebody helps me to understand it first.
>
> best,
> Siemen
>
>
> ----
>
> Siemen Baader
> PhD Fellow
>
> Department of Computer Science
> Aarhus University
> Aabogade 34
> DK-8200 Aarhus N
>
> office: ADA 125
> email: [hidden email] <mailto:[hidden email]
.dk>

> phone: +45 60 65 70 79
>
>
>
>
> --
> 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]
> <mailto:[hidden email]>.
> For more options, visit https://groups.google.com/d/optout.

--
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/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Compiler internals

Siemen Baader
Hi Herby,

On 07 Apr 2014, at 15:07, Herby Vojčík <[hidden email]> wrote:

> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.

I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there.

Any pointers to how to do it, anyone?

best,
Siemen

>
> Herby
>
> Siemen Baader wrote:
>> Hi list,
>>
>> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc.
>>
>> Specifically, I want:
>>
>> aBlockClosure
>> smalltalkSource "gives [ :bar | bar * 2 ] "
>> smalltalkSource: '[ :foo | foo + 42 ]' " sets & recompiles the source"
>>
>> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM?
>>
>> aBlockClosure scope "some sort of dictionary t
> hat lets us access the
>> bound variables"
>>
>> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem?
>>
>> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated?
>>
>> I see that Compiler >> compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks not compiled directly?
>>
>> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first.
>>
>> best,
>> Siemen
>>
>>
>> ----
>>
>> Siemen Baader
>> PhD Fellow
>>
>> Department of Computer Science
>> Aarhus University
>> Aabogade 34
>> DK-8200 Aarhus N
>>
>> office: ADA 125
>> email: [hidden email] <mailto:[hidden email]
> .dk>
>> phone: +45 60 65 70 79
>>
>>
>>
>>
>> --
>> 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] <mailto:[hidden email]>.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/d/optout.

--
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/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Compiler internals

Herby Vojčík

Siemen Baader wrote:
> Hi Herby,
>
> On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]>  wrote:
>
>> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.
>
> I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there.

It is not. All methods and blocks are clear, just JS functions, nothing more.
They add context themselves when run.

> Any pointers to how to do it, anyone?
>
> best,
> Siemen
>
>> Herby
>>
>> Siemen Baader wrote:
>>> Hi list,
>>>
>>> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don
't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc.

>>>
>>> Specifically, I want:
>>>
>>> aBlockClosure
>>> smalltalkSource "gives [ :bar | bar * 2 ] "
>>> smalltalkSource: '[ :foo | foo + 42 ]' " sets&  recompiles the source"
>>>
>>> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM?
>>>
>>> aBlockClosure scope "some sort of dictionary t
>> hat lets us access the
>>> bound variables"
>>>
>>> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem?
>>>
>>> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated?
>>>
>>> I see that Compiler>>  compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks
 not compiled directly?

>>>
>>> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first.
>>>
>>> best,
>>> Siemen
>>>
>>>
>>> ----
>>>
>>> Siemen Baader
>>> PhD Fellow
>>>
>>> Department of Computer Science
>>> Aarhus University
>>> Aabogade 34
>>> DK-8200 Aarhus N
>>>
>>> office: ADA 125
>>> email: [hidden email]<mailto:[hidden email]
>> .dk>
>>> phone: +45 60 65 70 79
>>>
>>>
>>>
>>>
>>> --
>>> 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]<mailto:[hidden email]>.
>>> For more options, visit https://groups.google.com/d/optout.
>> --
>> 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/d/optout.
>

--
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/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Compiler internals

Clément Béra
The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure.


A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes.


2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>:

Siemen Baader wrote:
Hi Herby,

On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]>  wrote:

BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.

I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there.

It is not. All methods and blocks are clear, just JS functions, nothing more.
They add context themselves when run.


Any pointers to how to do it, anyone?

best,
Siemen

Herby

Siemen Baader wrote:
Hi list,

I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don
't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc.

Specifically, I want:

aBlockClosure
smalltalkSource "gives [ :bar | bar * 2 ] "
smalltalkSource: '[ :foo | foo + 42 ]' " sets&  recompiles the source"


I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM?

aBlockClosure scope "some sort of dictionary t
hat lets us access the
bound variables"

Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem?

Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated?

I see that Compiler>>  compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks
not compiled directly?

The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first.

best,
Siemen


----

Siemen Baader
PhD Fellow

Department of Computer Science
Aarhus University
Aabogade 34
DK-8200 Aarhus N

office: ADA 125
email: [hidden email]<mailto:[hidden email]
.dk>
phone: <a href="tel:%2B45%2060%2065%2070%2079" value="+4560657079" target="_blank">+45 60 65 70 79




--
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]<mailto:[hidden email]>.
For more options, visit https://groups.google.com/d/optout.
--
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/d/optout.


--
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/d/optout.

--
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/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Compiler internals

Siemen Baader

On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote:

The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure.


A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes.

Thanks! I will go digging some more, this is definitely helpful!

-- Siemen



2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>:

Siemen Baader wrote:
Hi Herby,

On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]>  wrote:

BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.

I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there.

It is not. All methods and blocks are clear, just JS functions, nothing more.
They add context themselves when run.


Any pointers to how to do it, anyone?

best,
Siemen

Herby

Siemen Baader wrote:
Hi list,

I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don
't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc.

Specifically, I want:

aBlockClosure
smalltalkSource "gives [ :bar | bar * 2 ] "
smalltalkSource: '[ :foo | foo + 42 ]' " sets&  recompiles the source"


I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM?

aBlockClosure scope "some sort of dictionary t
hat lets us access the
bound variables"

Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem?

Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated?

I see that Compiler>>  compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks
not compiled directly?

The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first.

best,
Siemen


----

Siemen Baader
PhD Fellow

Department of Computer Science
Aarhus University
Aabogade 34
DK-8200 Aarhus N

office: ADA 125
email: [hidden email]<mailto:[hidden email]
.dk>
phone: <a href="tel:%2B45%2060%2065%2070%2079" value="+4560657079" target="_blank">+45 60 65 70 79




--
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]<mailto:[hidden email]>.
For more options, visit https://groups.google.com/d/optout.
--
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/d/optout.


--
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/d/optout.


--
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/d/optout.

--
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/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Compiler internals

Nicolas Petton
Hi!

I wrote a blog post about the new compiler some time ago. It doesn't go
too much into details but it may help anyway:
http://nicolas-petton.fr/blog/amber-compiler.html

Cheers,
Nico


Siemen Baader writes:

> On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote:
>
>> The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure.
>>
>> http://clementbera.files.wordpress.com/2013/05/screen-shot-2013-05-28-at-10-22-46-am.png
>>
>> A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes.
>
> Thanks! I will go digging some more, this is definitely helpful!
>
> -- Siemen
>
>>
>>
>> 2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>:
>>
>> Siemen Baader wrote:
>> Hi Herby,
>>
>> On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]>  wrote:
>>
>> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.
>>
>> I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there.
>>
>> It is not. All methods and blocks are clear, just JS functions, nothing more.
>> They add context themselves when run.
>>
>>
>> Any pointers to how to do it, anyone?
>>
>> best,
>> Siemen
>>
>> Herby
>>
>> Siemen Baader wrote:
>> Hi list,
>>
>> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don
>> 't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc.
>>
>> Specifically, I want:
>>
>> aBlockClosure
>> smalltalkSource "gives [ :bar | bar * 2 ] "
>> smalltalkSource: '[ :foo | foo + 42 ]' " sets&  recompiles the source"
>>
>>
>> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM?
>>
>> aBlockClosure scope "some sort of dictionary t
>> hat lets us access the
>> bound variables"
>>
>> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem?
>>
>> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated?
>>
>> I see that Compiler>>  compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks
>> not compiled directly?
>>
>> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first.
>>
>> best,
>> Siemen
>>
>>
>> ----
>>
>> Siemen Baader
>> PhD Fellow
>>
>> Department of Computer Science
>> Aarhus University
>> Aabogade 34
>> DK-8200 Aarhus N
>>
>> office: ADA 125
>> email: [hidden email]<mailto:[hidden email]
>> .dk>
>> phone: +45 60 65 70 79
>>
>>
>>
>>
>> --
>> 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]<mailto:[hidden email]>.
>> For more options, visit https://groups.google.com/d/optout.
>> --
>> 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/d/optout.
>>
>>
>> --
>> 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/d/optout.
>>
>>
>> --
>> 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/d/optout.


--
Nicolas Petton
http://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/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Compiler internals

Siemen Baader
Hi Nicolas,

thanks - that looks very promising! I will have a look and see if I can make the modification I need.

Would it be a good idea to put a link to this blog post into the Compiler class documentation?

cheers,
Siemen


On 08 Apr 2014, at 10:36, Nicolas Petton <[hidden email]> wrote:

> Hi!
>
> I wrote a blog post about the new compiler some time ago. It doesn't go
> too much into details but it may help anyway:
> http://nicolas-petton.fr/blog/amber-compiler.html
>
> Cheers,
> Nico
>
>
> Siemen Baader writes:
>
>> On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote:
>>
>>> The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure.
>>>
>>> http://clementbera.files.wordpress.com/2013/05/screen-shot-2013-05-28-at-10-22-46-am.png
>>>
>>> A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes.
>>
>> Thanks! I will go digging some more, this is definitely helpful!
>>
>> -- Siemen
>>
>>>
>>>
>>> 2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>:
>>>
>>> Siemen Baader wrote:
>>> Hi Herby,
>>>
>>> On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]>  wrote:
>>>
>>> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.
>>>
>>> I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there.
>>>
>>> It is not. All methods and blocks are clear, just JS functions, nothing more.
>>> They add context themselves when run.
>>>
>>>
>>> Any pointers to how to do it, anyone?
>>>
>>> best,
>>> Siemen
>>>
>>> Herby
>>>
>>> Siemen Baader wrote:
>>> Hi list,
>>>
>>> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don
>>> 't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc.
>>>
>>> Specifically, I want:
>>>
>>> aBlockClosure
>>> smalltalkSource "gives [ :bar | bar * 2 ] "
>>> smalltalkSource: '[ :foo | foo + 42 ]' " sets&  recompiles the source"
>>>
>>>
>>> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM?
>>>
>>> aBlockClosure scope "some sort of dictionary t
>>> hat lets us access the
>>> bound variables"
>>>
>>> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem?
>>>
>>> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated?
>>>
>>> I see that Compiler>>  compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks
>>> not compiled directly?
>>>
>>> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first.
>>>
>>> best,
>>> Siemen
>>>
>>>
>>> ----
>>>
>>> Siemen Baader
>>> PhD Fellow
>>>
>>> Department of Computer Science
>>> Aarhus University
>>> Aabogade 34
>>> DK-8200 Aarhus N
>>>
>>> office: ADA 125
>>> email: [hidden email]<mailto:[hidden email]
>>> .dk>
>>> phone: +45 60 65 70 79
>>>
>>>
>>>
>>>
>>> --
>>> 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]<mailto:[hidden email]>.
>>> For more options, visit https://groups.google.com/d/optout.
>>> --
>>> 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/d/optout.
>>>
>>>
>>> --
>>> 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/d/optout.
>>>
>>>
>>> --
>>> 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/d/optout.
>
>
> --
> Nicolas Petton
> http://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/d/optout.

--
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/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Compiler internals

Nicolas Petton

Siemen Baader writes:

> Hi Nicolas,
>
> thanks - that looks very promising! I will have a look and see if I can make the modification I need.
>
> Would it be a good idea to put a link to this blog post into the
> Compiler class documentation?

Maybe an even better idea would be to make a documentation page out of
it?

Cheers,
Nico

>
> cheers,
> Siemen
>
>
> On 08 Apr 2014, at 10:36, Nicolas Petton <[hidden email]> wrote:
>
>> Hi!
>>
>> I wrote a blog post about the new compiler some time ago. It doesn't go
>> too much into details but it may help anyway:
>> http://nicolas-petton.fr/blog/amber-compiler.html
>>
>> Cheers,
>> Nico
>>
>>
>> Siemen Baader writes:
>>
>>> On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote:
>>>
>>>> The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure.
>>>>
>>>> http://clementbera.files.wordpress.com/2013/05/screen-shot-2013-05-28-at-10-22-46-am.png
>>>>
>>>> A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes.
>>>
>>> Thanks! I will go digging some more, this is definitely helpful!
>>>
>>> -- Siemen
>>>
>>>>
>>>>
>>>> 2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>:
>>>>
>>>> Siemen Baader wrote:
>>>> Hi Herby,
>>>>
>>>> On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]>  wrote:
>>>>
>>>> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.
>>>>
>>>> I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there.
>>>>
>>>> It is not. All methods and blocks are clear, just JS functions, nothing more.
>>>> They add context themselves when run.
>>>>
>>>>
>>>> Any pointers to how to do it, anyone?
>>>>
>>>> best,
>>>> Siemen
>>>>
>>>> Herby
>>>>
>>>> Siemen Baader wrote:
>>>> Hi list,
>>>>
>>>> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don
>>>> 't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc.
>>>>
>>>> Specifically, I want:
>>>>
>>>> aBlockClosure
>>>> smalltalkSource "gives [ :bar | bar * 2 ] "
>>>> smalltalkSource: '[ :foo | foo + 42 ]' " sets&  recompiles the source"
>>>>
>>>>
>>>> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM?
>>>>
>>>> aBlockClosure scope "some sort of dictionary t
>>>> hat lets us access the
>>>> bound variables"
>>>>
>>>> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem?
>>>>
>>>> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated?
>>>>
>>>> I see that Compiler>>  compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks
>>>> not compiled directly?
>>>>
>>>> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first.
>>>>
>>>> best,
>>>> Siemen
>>>>
>>>>
>>>> ----
>>>>
>>>> Siemen Baader
>>>> PhD Fellow
>>>>
>>>> Department of Computer Science
>>>> Aarhus University
>>>> Aabogade 34
>>>> DK-8200 Aarhus N
>>>>
>>>> office: ADA 125
>>>> email: [hidden email]<mailto:[hidden email]
>>>> .dk>
>>>> phone: +45 60 65 70 79
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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]<mailto:[hidden email]>.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>> --
>>>> 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/d/optout.
>>>>
>>>>
>>>> --
>>>> 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/d/optout.
>>>>
>>>>
>>>> --
>>>> 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/d/optout.
>>
>>
>> --
>> Nicolas Petton
>> http://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/d/optout.


--
Nicolas Petton
http://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/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Compiler internals

Siemen Baader

On 08 Apr 2014, at 14:51, Nicolas Petton <[hidden email]> wrote:


Siemen Baader writes:

Hi Nicolas,

thanks - that looks very promising! I will have a look and see if I can make the modification I need. 

Would it be a good idea to put a link to this blog post into the
Compiler class documentation?

Maybe an even better idea would be to make a documentation page out of
it?

Yes, that is a good idea! I would like to do it once I get the things working - I guess this will be a good test case for the documentation as well ;)

best,
Siemen


Cheers,
Nico


cheers,
Siemen


On 08 Apr 2014, at 10:36, Nicolas Petton <[hidden email]> wrote:

Hi!

I wrote a blog post about the new compiler some time ago. It doesn't go
too much into details but it may help anyway:
http://nicolas-petton.fr/blog/amber-compiler.html

Cheers,
Nico


Siemen Baader writes:

On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote:

The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure.

http://clementbera.files.wordpress.com/2013/05/screen-shot-2013-05-28-at-10-22-46-am.png

A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes.

Thanks! I will go digging some more, this is definitely helpful!

-- Siemen



2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>:

Siemen Baader wrote:
Hi Herby,

On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]>  wrote:

BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.

I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there.

It is not. All methods and blocks are clear, just JS functions, nothing more.
They add context themselves when run.


Any pointers to how to do it, anyone?

best,
Siemen

Herby

Siemen Baader wrote:
Hi list,

I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don
't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc.

Specifically, I want:

aBlockClosure
smalltalkSource "gives [ :bar | bar * 2 ] "
smalltalkSource: '[ :foo | foo + 42 ]' " sets&  recompiles the source"


I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM?

aBlockClosure scope "some sort of dictionary t
hat lets us access the
bound variables"

Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem?

Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated?

I see that Compiler>>  compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks
not compiled directly?

The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first.

best,
Siemen


----

Siemen Baader
PhD Fellow

Department of Computer Science
Aarhus University
Aabogade 34
DK-8200 Aarhus N

office: ADA 125
email: [hidden email]<mailto:[hidden email]
.dk>
phone: +45 60 65 70 79




-- 
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]<mailto:[hidden email]>.
For more options, visit https://groups.google.com/d/optout.
-- 
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/d/optout.


-- 
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/d/optout.


-- 
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/d/optout.


-- 
Nicolas Petton
http://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/d/optout.


-- 
Nicolas Petton
http://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/d/optout.

--
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/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Compiler internals

Nicolas Petton

Siemen Baader writes:

> On 08 Apr 2014, at 14:51, Nicolas Petton <[hidden email]> wrote:
>
>>

> Yes, that is a good idea! I would like to do it once I get the things
> working - I guess this will be a good test case for the documentation
> as well ;)

The new repo for the documentation is here:
https://github.com/amber-smalltalk/amber-documentation

Cheers,
Nico

>
> best,
> Siemen
>
>>
>> Cheers,
>> Nico
>>
>>>
>>> cheers,
>>> Siemen
>>>
>>>
>>> On 08 Apr 2014, at 10:36, Nicolas Petton <[hidden email]> wrote:
>>>
>>>> Hi!
>>>>
>>>> I wrote a blog post about the new compiler some time ago. It doesn't go
>>>> too much into details but it may help anyway:
>>>> http://nicolas-petton.fr/blog/amber-compiler.html
>>>>
>>>> Cheers,
>>>> Nico
>>>>
>>>>
>>>> Siemen Baader writes:
>>>>
>>>>> On 07 Apr 2014, at 16:18, Clément Bera <[hidden email]> wrote:
>>>>>
>>>>>> The overall compiler architecture looks like the one of Pharo, but it spits out jaavscript instead of byte code, See the figure.
>>>>>>
>>>>>> http://clementbera.files.wordpress.com/2013/05/screen-shot-2013-05-28-at-10-22-46-am.png
>>>>>>
>>>>>> A javascript parser parse the smalltalk code and returns the AST, then the SemanticAnalyser analyses variables to get their scopes (basically to know for each var if it is a class, a temporary, an outer scope variable, ... ) (see LexicalScope and ScopeVar) , then the IRASTTranslator converts the AST to IRNodes. The IRNodes are an abstract representation of javascript. Here the compiler does a few optimizations: inlining conditions (ifTrue:,ifNil:), inlining closures to javascript function (I think not all the closures can be inlined do to javascript poor support for non local return) and inlining assignment. Lastly the IRJSTranslator spits out javascript out of the IRNodes.
>>>>>
>>>>> Thanks! I will go digging some more, this is definitely helpful!
>>>>>
>>>>> -- Siemen
>>>>>
>>>>>>
>>>>>>
>>>>>> 2014-04-07 6:47 GMT-07:00 Herby Vojčík <[hidden email]>:
>>>>>>
>>>>>> Siemen Baader wrote:
>>>>>> Hi Herby,
>>>>>>
>>>>>> On 07 Apr 2014, at 15:07, Herby Vojčík<[hidden email]>  wrote:
>>>>>>
>>>>>> BTW, BlockClosure wraps JavaScript function. So any JS function is a BlockClosure. You would need to specifically distiguish ones compiled by a Smalltalk compiler.
>>>>>>
>>>>>> I know, but I'm OK with that for my use case. Is there an object in the prototype chain that says 'this is a specific Amber BlockClosure'? If so, I could just add a lookup method there.
>>>>>>
>>>>>> It is not. All methods and blocks are clear, just JS functions, nothing more.
>>>>>> They add context themselves when run.
>>>>>>
>>>>>>
>>>>>> Any pointers to how to do it, anyone?
>>>>>>
>>>>>> best,
>>>>>> Siemen
>>>>>>
>>>>>> Herby
>>>>>>
>>>>>> Siemen Baader wrote:
>>>>>> Hi list,
>>>>>>
>>>>>> I am constructing smalltalk expressions and saving them into an object using Blocks in a Domain Specific Language. Later, I want to revise the content of these Blocks, so I'm trying to modify the compiler to access and revise the smalltalk source of existing BlockClosure objects. But I don
>>>>>> 't have enough of a big picture of the compiler architecture -- the IR, AST and the Compiler-Interpreter packages etc.
>>>>>>
>>>>>> Specifically, I want:
>>>>>>
>>>>>> aBlockClosure
>>>>>> smalltalkSource "gives [ :bar | bar * 2 ] "
>>>>>> smalltalkSource: '[ :foo | foo + 42 ]' " sets&  recompiles the source"
>>>>>>
>>>>>>
>>>>>> I guess this also requires us to have access to the closed-over local variables in the BlockClosure, right? Is this possible with the VM?
>>>>>>
>>>>>> aBlockClosure scope "some sort of dictionary t
>>>>>> hat lets us access the
>>>>>> bound variables"
>>>>>>
>>>>>> Could anyone explain the compiler's design for me and point out where to look to make the specific modifications to solve my problem?
>>>>>>
>>>>>> Does BlockClosure hold runtime references to the local and instance variables that are bound when it is evaluated?
>>>>>>
>>>>>> I see that Compiler>>  compileExpression uses the DoIt class and adds a new method to it to encapsulate the current expression in a block. Isn't that a detour / why are blocks
>>>>>> not compiled directly?
>>>>>>
>>>>>> The class Compiler is a good starting point. What do you think of putting the high-level documentation and links to the relevant background references into the Compiler class documentation text? I could do that if somebody helps me to understand it first.
>>>>>>
>>>>>> best,
>>>>>> Siemen
>>>>>>
>>>>>>
>>>>>> ----
>>>>>>
>>>>>> Siemen Baader
>>>>>> PhD Fellow
>>>>>>
>>>>>> Department of Computer Science
>>>>>> Aarhus University
>>>>>> Aabogade 34
>>>>>> DK-8200 Aarhus N
>>>>>>
>>>>>> office: ADA 125
>>>>>> email: [hidden email]<mailto:[hidden email]
>>>>>> .dk>
>>>>>> phone: +45 60 65 70 79
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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]<mailto:[hidden email]>.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>> --
>>>>>> 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/d/optout.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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/d/optout.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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/d/optout.
>>>>
>>>>
>>>> --
>>>> Nicolas Petton
>>>> http://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/d/optout.
>>
>>
>> --
>> Nicolas Petton
>> http://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/d/optout.


--
Nicolas Petton
http://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/d/optout.