Hello Marc & Bruno,
I'd like to start integrating your stdlib code into Tachyon and testing it out with the primitives we have. However, this might require some (fairly minor?) refactorings.
If you have time, could you come by the lab today or tomorrow afternoon so I can tell you what I have in mind and discuss integration into the Tachyon runtime?
- Maxime
Afficher les réponses par date
On 2011-02-03, at 12:12 , chevalma@iro.umontreal.ca wrote:
Hello Marc & Bruno,
I'd like to start integrating your stdlib code into Tachyon and testing it out with the primitives we have. However, this might require some (fairly minor?) refactorings.
If you have time, could you come by the lab today or tomorrow afternoon so I can tell you what I have in mind and discuss integration into the Tachyon runtime?
I'm available today until 3:30 or tomorrow all afternoon. What works best for you?
-b
Whenever works for you :) Sooner is probably better.
- Maxime
On 2011-02-03, at 12:12 , chevalma@iro.umontreal.ca wrote:
Hello Marc & Bruno,
I'd like to start integrating your stdlib code into Tachyon and testing it out with the primitives we have. However, this might require some (fairly minor?) refactorings.
If you have time, could you come by the lab today or tomorrow afternoon so I can tell you what I have in mind and discuss integration into the Tachyon runtime?
I'm available today until 3:30 or tomorrow all afternoon. What works best for you?
-b_______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
I just spoke to Marc about the refactorings. He suggests keeping the array/string methods global, and then assigning them on the Array/String prototype object. We could then hide the global methods (make them invisible to the user) with Tachyon-specific annotations. This would make it possible to guarantee that these methods are always accessible, even if the user redefines them on the prototype object. It could also make it possible to make them call each other statically, if the said methods need to call one another.
I think we might also perhaps want to add some kind of global variable that only exists when compilation occurs under Tachyon. This would allow the array and string implementations to use conditional tests (eg: if (TACHYON_JSVM !== undefined)) to change their implementation depending on whether they're running on V8 or Tachyon.
- Maxime
Whenever works for you :) Sooner is probably better.
- Maxime
On 2011-02-03, at 12:12 , chevalma@iro.umontreal.ca wrote:
Hello Marc & Bruno,
I'd like to start integrating your stdlib code into Tachyon and testing it out with the primitives we have. However, this might require some (fairly minor?) refactorings.
If you have time, could you come by the lab today or tomorrow afternoon so I can tell you what I have in mind and discuss integration into the Tachyon runtime?
I'm available today until 3:30 or tomorrow all afternoon. What works best for you?
-b_______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
On 2011-02-03, at 3:37 PM, chevalma@iro.umontreal.ca wrote:
I just spoke to Marc about the refactorings. He suggests keeping the array/string methods global, and then assigning them on the Array/String prototype object. We could then hide the global methods (make them invisible to the user) with Tachyon-specific annotations. This would make it possible to guarantee that these methods are always accessible, even if the user redefines them on the prototype object.
I suggest using a "global" annotation to indicate which names are to be exported to the global object. For example:
"tachyon global: Array" "tachyon global: String"
function Array() { ... } // added to global object function String() { ... } // added to global object
function foo(x) { ... } // not added to global object, but available for static linking
Question: how does another module know that foo is available for static linking? Must we add another annotation to import statically linkable names? Such as:
"tachyon import: foo(x)"
It could also make it possible to make them call each other statically, if the said methods need to call one another.
Yes, that would allow writing modular runtime code that doesn't suffer from the slowness of accessing the methods through the prototype chain.
I think we might also perhaps want to add some kind of global variable that only exists when compilation occurs under Tachyon. This would allow the array and string implementations to use conditional tests (eg: if (TACHYON_JSVM !== undefined)) to change their implementation depending on whether they're running on V8 or Tachyon.
That sounds like a C "#ifdef", but at run time. It's kind of dirty, but I guess we can use it until we find something cleaner.
Marc
I suggest using a "global" annotation to indicate which names are to be exported to the global object. For example:
"tachyon global: Array" "tachyon global: String"
function Array() { ... } // added to global object function String() { ... } // added to global object
function foo(x) { ... } // not added to global object, but available for static linking
We already have a "tachyon:static" annotation that goes inside the functions (the ECMA standard provides for such annotations). This annotation currently does not eliminate global visibility, but we could simply make it do that.
Question: how does another module know that foo is available for static linking? Must we add another annotation to import statically linkable names? Such as:
Currently, you declare a function static, and it becomes available for linking with everywhere in the Tachyon code. Global lookups of that name in the Tachyon code will link with that function.
That sounds like a C "#ifdef", but at run time. It's kind of dirty, but I guess we can use it until we find something cleaner.
If we make the variable a static definition using my system, the constant propagation should get rid of the branches in the compiled code.
- Maxime
On 2011-02-03, at 16:01 , Marc Feeley wrote:
On 2011-02-03, at 3:37 PM, chevalma@iro.umontreal.ca wrote:
I just spoke to Marc about the refactorings. He suggests keeping the array/string methods global, and then assigning them on the Array/String prototype object. We could then hide the global methods (make them invisible to the user) with Tachyon-specific annotations. This would make it possible to guarantee that these methods are always accessible, even if the user redefines them on the prototype object.
I suggest using a "global" annotation to indicate which names are to be exported to the global object. For example:
"tachyon global: Array" "tachyon global: String"
function Array() { ... } // added to global object function String() { ... } // added to global object
function foo(x) { ... } // not added to global object, but available for static linking
Question: how does another module know that foo is available for static linking? Must we add another annotation to import statically linkable names? Such as:
"tachyon import: foo(x)"
It could also make it possible to make them call each other statically, if the said methods need to call one another.
Yes, that would allow writing modular runtime code that doesn't suffer from the slowness of accessing the methods through the prototype chain.
For Strings, there are some cases where one method calls another. However, because 'this' is used explicitly, then the current implementation would go through the prototype chain. Should I rewrite them to be global functions that take an explicit 'this' parameter, and maybe use a wrapper method that gets assigned to the prototype then? I don't like adding an extra function call, but there may be a way to fix that using inlining annotations.
Bruno
Don't add an extra parameter for the this argument. You can use apply to circumvent this issue, or iir.call if you know the number of arguments is fixed.
- Maxime
On 2011-02-03, at 16:01 , Marc Feeley wrote:
On 2011-02-03, at 3:37 PM, chevalma@iro.umontreal.ca wrote:
I just spoke to Marc about the refactorings. He suggests keeping the array/string methods global, and then assigning them on the Array/String prototype object. We could then hide the global methods (make them invisible to the user) with Tachyon-specific annotations. This would make it possible to guarantee that these methods are always accessible, even if the user redefines them on the prototype object.
I suggest using a "global" annotation to indicate which names are to be exported to the global object. For example:
"tachyon global: Array" "tachyon global: String"
function Array() { ... } // added to global object function String() { ... } // added to global object
function foo(x) { ... } // not added to global object, but available for static linking
Question: how does another module know that foo is available for static linking? Must we add another annotation to import statically linkable names? Such as:
"tachyon import: foo(x)"
It could also make it possible to make them call each other statically, if the said methods need to call one another.
Yes, that would allow writing modular runtime code that doesn't suffer from the slowness of accessing the methods through the prototype chain.
For Strings, there are some cases where one method calls another. However, because 'this' is used explicitly, then the current implementation would go through the prototype chain. Should I rewrite them to be global functions that take an explicit 'this' parameter, and maybe use a wrapper method that gets assigned to the prototype then? I don't like adding an extra function call, but there may be a way to fix that using inlining annotations.
Bruno_______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
On 2011-02-03, at 17:20 , chevalma@iro.umontreal.ca wrote:
Don't add an extra parameter for the this argument. You can use apply to circumvent this issue,
Doesn't that mean I will be forced to create a new array for the parameters though? Maybe we eventually such uses of apply could be optimized, but it sounds trickier to do than inlining the static call to me...
or iir.call if you know the number of arguments is fixed.
Most of these methods are not using inline IR, so that won't work.
Bruno
- Maxime
On 2011-02-03, at 16:01 , Marc Feeley wrote:
On 2011-02-03, at 3:37 PM, chevalma@iro.umontreal.ca wrote:
I just spoke to Marc about the refactorings. He suggests keeping the array/string methods global, and then assigning them on the Array/String prototype object. We could then hide the global methods (make them invisible to the user) with Tachyon-specific annotations. This would make it possible to guarantee that these methods are always accessible, even if the user redefines them on the prototype object.
I suggest using a "global" annotation to indicate which names are to be exported to the global object. For example:
"tachyon global: Array" "tachyon global: String"
function Array() { ... } // added to global object function String() { ... } // added to global object
function foo(x) { ... } // not added to global object, but available for static linking
Question: how does another module know that foo is available for static linking? Must we add another annotation to import statically linkable names? Such as:
"tachyon import: foo(x)"
It could also make it possible to make them call each other statically, if the said methods need to call one another.
Yes, that would allow writing modular runtime code that doesn't suffer from the slowness of accessing the methods through the prototype chain.
For Strings, there are some cases where one method calls another. However, because 'this' is used explicitly, then the current implementation would go through the prototype chain. Should I rewrite them to be global functions that take an explicit 'this' parameter, and maybe use a wrapper method that gets assigned to the prototype then? I don't like adding an extra function call, but there may be a way to fix that using inlining annotations.
Bruno_______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
If string methods call one another, need the this argument, and are used-exposed, you could do it by simply calling them through "this."
Otherwise, if they aren't visible for the user, and don't really need to be accessible through String.prototype. I guess you could simply pass the string argument explicitly.
As far as not using inline IR, I would try not to use it everywhere, but we technically can use it wherever we see fit in our own library code.
- Maxime
On 2011-02-03, at 17:20 , chevalma@iro.umontreal.ca wrote:
Don't add an extra parameter for the this argument. You can use apply to circumvent this issue,
Doesn't that mean I will be forced to create a new array for the parameters though? Maybe we eventually such uses of apply could be optimized, but it sounds trickier to do than inlining the static call to me...
or iir.call if you know the number of arguments is fixed.
Most of these methods are not using inline IR, so that won't work.
Bruno
- Maxime
On 2011-02-03, at 16:01 , Marc Feeley wrote:
On 2011-02-03, at 3:37 PM, chevalma@iro.umontreal.ca wrote:
I just spoke to Marc about the refactorings. He suggests keeping the array/string methods global, and then assigning them on the Array/String prototype object. We could then hide the global methods (make them invisible to the user) with Tachyon-specific annotations. This would make it possible to guarantee that these methods are always accessible, even if the user redefines them on the prototype object.
I suggest using a "global" annotation to indicate which names are to be exported to the global object. For example:
"tachyon global: Array" "tachyon global: String"
function Array() { ... } // added to global object function String() { ... } // added to global object
function foo(x) { ... } // not added to global object, but available for static linking
Question: how does another module know that foo is available for static linking? Must we add another annotation to import statically linkable names? Such as:
"tachyon import: foo(x)"
It could also make it possible to make them call each other statically, if the said methods need to call one another.
Yes, that would allow writing modular runtime code that doesn't suffer from the slowness of accessing the methods through the prototype chain.
For Strings, there are some cases where one method calls another. However, because 'this' is used explicitly, then the current implementation would go through the prototype chain. Should I rewrite them to be global functions that take an explicit 'this' parameter, and maybe use a wrapper method that gets assigned to the prototype then? I don't like adding an extra function call, but there may be a way to fix that using inlining annotations.
Bruno_______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
On 2011-02-03, at 17:45 , chevalma@iro.umontreal.ca wrote:
If string methods call one another, need the this argument, and are used-exposed, you could do it by simply calling them through "this."
Otherwise, if they aren't visible for the user, and don't really need to be accessible through String.prototype. I guess you could simply pass the string argument explicitly.
I only use 'this' when the method needs to be assigned to the String prototype of course. I'll keep the code as it is for now, but it'd be trivial to refactor it if we need to extract the bits of shared functionality.
As far as not using inline IR, I would try not to use it everywhere, but we technically can use it wherever we see fit in our own library code.
Not sure I'd like to implement String.prototype.split using IIR :)
Bruno
- Maxime
On 2011-02-03, at 17:20 , chevalma@iro.umontreal.ca wrote:
Don't add an extra parameter for the this argument. You can use apply to circumvent this issue,
Doesn't that mean I will be forced to create a new array for the parameters though? Maybe we eventually such uses of apply could be optimized, but it sounds trickier to do than inlining the static call to me...
or iir.call if you know the number of arguments is fixed.
Most of these methods are not using inline IR, so that won't work.
Bruno
- Maxime
On 2011-02-03, at 16:01 , Marc Feeley wrote:
On 2011-02-03, at 3:37 PM, chevalma@iro.umontreal.ca wrote:
I just spoke to Marc about the refactorings. He suggests keeping the array/string methods global, and then assigning them on the Array/String prototype object. We could then hide the global methods (make them invisible to the user) with Tachyon-specific annotations. This would make it possible to guarantee that these methods are always accessible, even if the user redefines them on the prototype object.
I suggest using a "global" annotation to indicate which names are to be exported to the global object. For example:
"tachyon global: Array" "tachyon global: String"
function Array() { ... } // added to global object function String() { ... } // added to global object
function foo(x) { ... } // not added to global object, but available for static linking
Question: how does another module know that foo is available for static linking? Must we add another annotation to import statically linkable names? Such as:
"tachyon import: foo(x)"
It could also make it possible to make them call each other statically, if the said methods need to call one another.
Yes, that would allow writing modular runtime code that doesn't suffer from the slowness of accessing the methods through the prototype chain.
For Strings, there are some cases where one method calls another. However, because 'this' is used explicitly, then the current implementation would go through the prototype chain. Should I rewrite them to be global functions that take an explicit 'this' parameter, and maybe use a wrapper method that gets assigned to the prototype then? I don't like adding an extra function call, but there may be a way to fix that using inlining annotations.
Bruno
Not sure I'd like to implement String.prototype.split using IIR :)
Just to clarify, using some bits of IIR doesn't mean you lose access to arrays and all the other JavaScript goodness.
- Maxime
Bruno
- Maxime
On 2011-02-03, at 17:20 , chevalma@iro.umontreal.ca wrote:
Don't add an extra parameter for the this argument. You can use apply to circumvent this issue,
Doesn't that mean I will be forced to create a new array for the parameters though? Maybe we eventually such uses of apply could be optimized, but it sounds trickier to do than inlining the static call to me...
or iir.call if you know the number of arguments is fixed.
Most of these methods are not using inline IR, so that won't work.
Bruno
- Maxime
On 2011-02-03, at 16:01 , Marc Feeley wrote:
On 2011-02-03, at 3:37 PM, chevalma@iro.umontreal.ca wrote:
> I just spoke to Marc about the refactorings. He suggests keeping > the > array/string methods global, and then assigning them on the > Array/String > prototype object. We could then hide the global methods (make them > invisible to the user) with Tachyon-specific annotations. This > would > make > it possible to guarantee that these methods are always accessible, > even > if > the user redefines them on the prototype object.
I suggest using a "global" annotation to indicate which names are to be exported to the global object. For example:
"tachyon global: Array" "tachyon global: String"
function Array() { ... } // added to global object function String() { ... } // added to global object
function foo(x) { ... } // not added to global object, but available for static linking
Question: how does another module know that foo is available for static linking? Must we add another annotation to import statically linkable names? Such as:
"tachyon import: foo(x)"
> It could also make it > possible to make them call each other statically, if the said > methods > need > to call one another.
Yes, that would allow writing modular runtime code that doesn't suffer from the slowness of accessing the methods through the prototype chain.
For Strings, there are some cases where one method calls another. However, because 'this' is used explicitly, then the current implementation would go through the prototype chain. Should I rewrite them to be global functions that take an explicit 'this' parameter, and maybe use a wrapper method that gets assigned to the prototype then? I don't like adding an extra function call, but there may be a way to fix that using inlining annotations.
Bruno
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list