[Pharo-project] VM page in pharo book is outdated
Hi, Checking the pharo colaboractive book, I found that the VM building is old and it is not compatible anymore with our current process. Maybe "someone" (cough, cough, Mariano, cough, cough) could update it with better information? Cheers, Esteban pd: also... I'm a little worried about nobody noticing this before. That means people does not use pharo book? I think is a great way to share information, but maybe there is not much people aware of it... I know, there is a link in "external links" in main page and is top in "documentation"... I don't know if we can do it more visible or clear? ppd: I'd rearrange "pharo tools" section by adding subsections like: "Persistence", "Web", etc., today looks a little bit confusing, IMHO. pppd: yeah... today is my "stupid questions" day... :P
On Tue, Nov 29, 2011 at 10:12 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
Hi,
Checking the pharo colaboractive book, I found that the VM building is old and it is not compatible anymore with our current process. Maybe "someone" (cough, cough, Mariano, cough, cough) could update it with better information?
Cheers, Esteban
pd: also... I'm a little worried about nobody noticing this before. That means people does not use pharo book?
Last times I used Mariano's Blog :$
I think is a great way to share information, but maybe there is not much people aware of it... I know, there is a link in "external links" in main page and is top in "documentation"... I don't know if we can do it more visible or clear? ppd: I'd rearrange "pharo tools" section by adding subsections like: "Persistence", "Web", etc., today looks a little bit confusing, IMHO. pppd: yeah... today is my "stupid questions" day... :P
Hi Esteban. I DID notice that the book was "outdated". The thing is that we have to decide, as the Pharo community, if it is outdated or just another alternative. Eliot's way of building the VM is different than "our". We use ConfigurationOfCog + CMakeVMMaker + Git. Eliot uses another way. So what is documented in the pharo book is kind of Eliot way. We have to decide as a community what do we expect when building cog. Is ConfigurationOfCog + CMakeVMMaker + Git the OFFICIAL Pharo way of building the VM? If we do agree on this, then yes, we should update the book. Something different is if ConfigurationOfCog + CMakeVMMaker + Git is just ANOTHER way of bulding the VM, in which case I don't see as incorrect what is in the pharo book. What do you think? On Tue, Nov 29, 2011 at 10:12 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
Hi,
Checking the pharo colaboractive book, I found that the VM building is old and it is not compatible anymore with our current process. Maybe "someone" (cough, cough, Mariano, cough, cough) could update it with better information?
Cheers, Esteban
pd: also... I'm a little worried about nobody noticing this before. That means people does not use pharo book? I think is a great way to share information, but maybe there is not much people aware of it... I know, there is a link in "external links" in main page and is top in "documentation"... I don't know if we can do it more visible or clear? ppd: I'd rearrange "pharo tools" section by adding subsections like: "Persistence", "Web", etc., today looks a little bit confusing, IMHO. pppd: yeah... today is my "stupid questions" day... :P
-- Mariano http://marianopeck.wordpress.com
Hi Esteban. I DID notice that the book was "outdated". The thing is that we have to decide, as the Pharo community, if it is outdated or just another alternative. Eliot's way of building the VM is different than "our". We use ConfigurationOfCog + CMakeVMMaker + Git. Eliot uses another way. So what is documented in the pharo book is kind of Eliot way. We have to decide as a community what do we expect when building cog. Is ConfigurationOfCog + CMakeVMMaker + Git the OFFICIAL Pharo way of building the VM? If we do agree on this, then yes, we should update the book. Something different is if ConfigurationOfCog + CMakeVMMaker + Git is just ANOTHER way of bulding the VM, in which case I don't see as incorrect what is in the pharo book.
Guess my answer :) Why would we throw away the three months igor spent making sure that idiot like me can compile the VM without problems. And more important Git (which I hate for my article) is socially the way to go for the VM = message to cool C hackers yes you are welcome to clean and improve our VM (it deserves it and once of these days we will have to do something⦠because we are losing against simpler, nicer VM like lua (C-embedding, â¦.). JB is fighting to get the stack vm compiling on a funky micro pro and the VM dusty code is getting in our way. Stef
On Wed, Nov 30, 2011 at 6:51 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi Esteban. I DID notice that the book was "outdated". The thing is that we have to decide, as the Pharo community, if it is outdated or just another alternative. Eliot's way of building the VM is different than "our". We use ConfigurationOfCog + CMakeVMMaker + Git. Eliot uses another way. So what is documented in the pharo book is kind of Eliot way. We have to decide as a community what do we expect when building cog. Is ConfigurationOfCog + CMakeVMMaker + Git the OFFICIAL Pharo way of building the VM? Â If we do agree on this, then yes, we should update the book. Something different is if ConfigurationOfCog + CMakeVMMaker + Git is just ANOTHER way of bulding the VM, in which case I don't see as incorrect what is in the pharo book.
Guess my answer :) Why would we throw away the three months igor spent making sure that idiot like me can compile the VM without problems. And more important Git (which I hate for my article) is socially the way to go for the VM = message to cool C hackers yes you are welcome to clean and improve our VM (it deserves it and once of these days we will have to do something⦠because we are losing against simpler, nicer VM like lua (C-embedding, â¦.). JB is fighting to get the stack vm compiling on a funky micro pro and the VM dusty code is getting in our way.
+1 I would love to use Pharo to do more robotics/embedded stuff. For example, i would like to be able to connect C/C++ computer vision libraries like OpenCV with FFI/Alien. But this is still difficult to do that in Pharo. I don't have the energy and man-power to invest time in this direction. If i ask some students do to this work, i know that they will have a lot of difficulties and at end the experience will be not very funny. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
FFI isn't so much difficult as it is a little tedious and, more so, incomplete. Stef has said that a working FFI (callbacks and threads) for all platforms is a priority, and is using words like January - that would be NICE. I would also like to see a full set of signed/unsigned single, double and perhaps quad word arrays, as well as float and double arrays. The latter is truly missing; I have been very lucky hacking around it. One thing that is really a shame is that for any of my extended types, I have to tell FFI that they are void* :( At least that's the only way I currently know to get them to work. C++ libraries might be a problem. In one case, I was able to simply tell FFI about the mangled names, and all was well. If the library goes heavily into C++ features across its boundary, you might be better off writing a C-friendly wrapper around it. Remember that once you get inside the opening brace of even an extern "C" function, you can use C++ features to implement it. In particular, I have C callable functions that use string streams to generate output and templated array classes to access elements. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Serge Stinckwich [serge.stinckwich@gmail.com] +1 I would love to use Pharo to do more robotics/embedded stuff. For example, i would like to be able to connect C/C++ computer vision libraries like OpenCV with FFI/Alien. But this is still difficult to do that in Pharo. I don't have the energy and man-power to invest time in this direction. If i ask some students do to this work, i know that they will have a lot of difficulties and at end the experience will be not very funny. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
On Tue, Nov 29, 2011 at 10:51 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Hi Esteban. I DID notice that the book was "outdated". The thing is that we have to decide, as the Pharo community, if it is outdated or just another alternative. Eliot's way of building the VM is different than "our". We use ConfigurationOfCog + CMakeVMMaker + Git. Eliot uses another way. So what is documented in the pharo book is kind of Eliot way. We have to decide as a community what do we expect when building cog. Is ConfigurationOfCog + CMakeVMMaker + Git the OFFICIAL Pharo way of building the VM? If we do agree on this, then yes, we should update the book. Something different is if ConfigurationOfCog + CMakeVMMaker + Git is just ANOTHER way of bulding the VM, in which case I don't see as incorrect what is in the pharo book.
Guess my answer :) Why would we throw away the three months igor spent making sure that idiot like me can compile the VM without problems.
I know your answer. I would recommend that way also, but (answering to Esteban), I don't have such time. My effort is in writing as much as I can (for example, in the blog). I cannot do more right now, since I am getting inside the last year of my PhD. Apart from that, Stef took some of my posts and transform them into PBE2 chapters.... we don't have manpower to have to books talking about the same. So I would rather go in the effort of continuing such chapters. Is there someone willing to help?
And more important Git (which I hate for my article) is socially the way to go for the VM = message to cool C hackers yes you are welcome to clean and improve our VM (it deserves it and once of these days we will have to do something⦠because we are losing against simpler, nicer VM like lua (C-embedding, â¦.). JB is fighting to get the stack vm compiling on a funky micro pro and the VM dusty code is getting in our way.
Stef
-- Mariano http://marianopeck.wordpress.com
On Tue, Nov 29, 2011 at 10:12 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Checking the pharo colaboractive book, I found that the VM building is old and it is not compatible anymore with our current process. Maybe "someone" (cough, cough, Mariano, cough, cough) could update it with better information?
Cheers, Esteban
pd: also... I'm a little worried about nobody noticing this before. That means people does not use pharo book? I think is a great way to share information, but maybe there is not much people aware of it... I know, there is a link in "external links" in main page and is top in "documentation"... I don't know if we can do it more visible or clear? ppd: I'd rearrange "pharo tools" section by adding subsections like: "Persistence", "Web", etc., today looks a little bit confusing, IMHO. pppd: yeah... today is my "stupid questions" day... :P
There is the Pharo by Example book (Vol 1 and vol 2) and the Pharo Collaboractive book. I'm wondering if this is a kind of dispersion to have two books at the same time. What is the idea of Pharo Collaborative book ? More focused on Pharo applications ? a Pharo user manual ? Maybe some chapters maybe be shared between the two books. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
On Tue, Nov 29, 2011 at 10:12 PM, Serge Stinckwich < serge.stinckwich@gmail.com> wrote:
On Tue, Nov 29, 2011 at 10:12 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Checking the pharo colaboractive book, I found that the VM building is old and it is not compatible anymore with our current process. Maybe "someone" (cough, cough, Mariano, cough, cough) could update it with better information?
Cheers, Esteban
pd: also... I'm a little worried about nobody noticing this before. That means people does not use pharo book? I think is a great way to share information, but maybe there is not much people aware of it... I know, there is a link in "external links" in main page and is top in "documentation"... I don't know if we can do it more visible or clear? ppd: I'd rearrange "pharo tools" section by adding subsections like: "Persistence", "Web", etc., today looks a little bit confusing, IMHO. pppd: yeah... today is my "stupid questions" day... :P
There is the Pharo by Example book (Vol 1 and vol 2) and the Pharo Collaboractive book. I'm wondering if this is a kind of dispersion to have two books at the same time. What is the idea of Pharo Collaborative book ? More focused on Pharo applications ? a Pharo user manual ?
What about calling it PharoWiki?
Maybe some chapters maybe be shared between the two books.
Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
serge did you have a look at the draft of the ffi chapter? Stef On Nov 30, 2011, at 2:12 AM, Serge Stinckwich wrote:
On Tue, Nov 29, 2011 at 10:12 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Checking the pharo colaboractive book, I found that the VM building is old and it is not compatible anymore with our current process. Maybe "someone" (cough, cough, Mariano, cough, cough) could update it with better information?
Cheers, Esteban
pd: also... I'm a little worried about nobody noticing this before. That means people does not use pharo book? I think is a great way to share information, but maybe there is not much people aware of it... I know, there is a link in "external links" in main page and is top in "documentation"... I don't know if we can do it more visible or clear? ppd: I'd rearrange "pharo tools" section by adding subsections like: "Persistence", "Web", etc., today looks a little bit confusing, IMHO. pppd: yeah... today is my "stupid questions" day... :P
There is the Pharo by Example book (Vol 1 and vol 2) and the Pharo Collaboractive book. I'm wondering if this is a kind of dispersion to have two books at the same time. What is the idea of Pharo Collaborative book ? More focused on Pharo applications ? a Pharo user manual ?
Maybe some chapters maybe be shared between the two books.
Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Stef, Apologies if I am exploiting something you meant to send privately, but "draft of a chapter" on FFI?????!!!!!! :) :) :) I'm no expert, but I certainly like to see what is being written. It is difficult to imagine how I could fail to learn something from it. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, November 30, 2011 12:46 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] VM page in pharo book is outdated serge did you have a look at the draft of the ffi chapter? Stef On Nov 30, 2011, at 2:12 AM, Serge Stinckwich wrote:
On Tue, Nov 29, 2011 at 10:12 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Checking the pharo colaboractive book, I found that the VM building is old and it is not compatible anymore with our current process. Maybe "someone" (cough, cough, Mariano, cough, cough) could update it with better information?
Cheers, Esteban
pd: also... I'm a little worried about nobody noticing this before. That means people does not use pharo book? I think is a great way to share information, but maybe there is not much people aware of it... I know, there is a link in "external links" in main page and is top in "documentation"... I don't know if we can do it more visible or clear? ppd: I'd rearrange "pharo tools" section by adding subsections like: "Persistence", "Web", etc., today looks a little bit confusing, IMHO. pppd: yeah... today is my "stupid questions" day... :P
There is the Pharo by Example book (Vol 1 and vol 2) and the Pharo Collaboractive book. I'm wondering if this is a kind of dispersion to have two books at the same time. What is the idea of Pharo Collaborative book ? More focused on Pharo applications ? a Pharo user manual ?
Maybe some chapters maybe be shared between the two books.
Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
On 30 November 2011 18:56, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Stef,
Apologies if I am exploiting something you meant to send privately, but "draft of a chapter" on FFI?????!!!!!! :) :) :)
I'm no expert, but I certainly like to see what is being written. Â It is difficult to imagine how I could fail to learn something from it.
hmm, i seen a draft in my mailbox, but i cannot remember if i received privately or from public mailing list. And of course, there is no reason to keep it private: i think the more reviewers/readers it has, the better it will be.
Bill
-- Best regards, Igor Stasenko.
everything is public no secret https://gforge.inria.fr/scm/viewvc.php/?root=pharobooks just a lot of work â¦. and pain with english Stef On Nov 30, 2011, at 7:19 PM, Igor Stasenko wrote:
On 30 November 2011 18:56, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Stef,
Apologies if I am exploiting something you meant to send privately, but "draft of a chapter" on FFI?????!!!!!! :) :) :)
I'm no expert, but I certainly like to see what is being written. It is difficult to imagine how I could fail to learn something from it.
hmm, i seen a draft in my mailbox, but i cannot remember if i received privately or from public mailing list.
And of course, there is no reason to keep it private: i think the more reviewers/readers it has, the better it will be.
Bill
-- Best regards, Igor Stasenko.
Stef, Sig, Thanks for the preview! One thing that jumped out at me so far is the passing of strings by copy. Interestingly, I can't find an example (in my code where I would have sworn I had a few) of having an external library fill a string, but I know I have encountered it and wonder if/how Spock would handle it. This reminds me of Dolphin's default "pass by reference" (albeit in reverse) for external byte objects. In short, the Dolphin vm automatically passes the address of certain objects, and it often does what one wants. It also makes some things difficult to do. For example, one time I had to pass a COM interface pointer from one component to another, and to do it in Dolphin, I had to construct an intermediate byte object to hold the pointer, just so the vm would have a gratuitous level of indirection to remove in making the call. In fairness, I encountered very few such examples, but OA did ultimately express some regret over the decision. FWIW. A comment in the document asks about the available types, citing float, double and boolean. All good examples. We also need a full range of integer sizes (8, 16, 32, 64 bytes), signed and unsigned, and in array form. We need Float and double arrays too. Floats are sometimes used to save space (especially in multi-dimensional settings), and some researchers might care to use floats and doubles separately to look at roundoff error in computations. The real reason to have floats and doubles is that there are libraries that use both types. Another type that crops up is long double. So far, I can't say they have been critical to my work, but I have had to hack around appearances of them. The chapter shows the use of <primitive:module:> and states that it avoids the need to create instances. Very true, but I pose the question of whether we should encourage formal library (handle body) instances? The idea is that it provides some hope of being able to unload a library while the image is running. Whether that has any teeth is open for debate (I recall having trouble getting libraries to actually unload on a certain OS that will remain nameless<g>). In fairness to that OS, I do not recall the circumstances, but it sure seemed like yet another weirdness. Another advantage of placing the library name in one method is that it can be edited in one place. GSL has *thousands* of functions and hence thousands of wrapper methods. Tweaking every one would be ugly. Worse, ODBC goes by different names on Windows and Linux, and I doubt it is alone. There is a real role for #moduleName to test the OS and answer the appropriate string - something that can't be done with <primitive:module:>. Dolphin uses a class per library and a singleton instance of each; it "felt right," and Pharo's FFI will work that way. I subclass ExternalLibrary and do not specify a module name for each function call. Bottom line, if you get callbacks working, I'll play along regardless of small details :) Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, November 30, 2011 2:00 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] VM page in pharo book is outdated everything is public no secret https://gforge.inria.fr/scm/viewvc.php/?root=pharobooks just a lot of work â¦. and pain with english Stef On Nov 30, 2011, at 7:19 PM, Igor Stasenko wrote:
On 30 November 2011 18:56, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Stef,
Apologies if I am exploiting something you meant to send privately, but "draft of a chapter" on FFI?????!!!!!! :) :) :)
I'm no expert, but I certainly like to see what is being written. It is difficult to imagine how I could fail to learn something from it.
hmm, i seen a draft in my mailbox, but i cannot remember if i received privately or from public mailing list.
And of course, there is no reason to keep it private: i think the more reviewers/readers it has, the better it will be.
Bill
-- Best regards, Igor Stasenko.
Thanks for the comments. There are many things missing in the book yet, because we still don't have so many usage examples. We are trying to incorporate them as we get more usage experience. With the cairo wrapper and igor's help I got some experience, so I tried to put the learnt lessons in the book. If you find some example you would like to have, or some thing missing, just tell and we'll try to add it. Of course this is a work in progress, but igor's work on nativeboost is very complete. One last thing, as Igor told me one time, many people think that FFI is like rocket science, but that's not the case. I encourage people to try and start with it, because it's really easy and we are here to help. The base of the cairo wrapper took 1 afternoon, and the same happened with the X lib wrapper. Cheers, Javier On Wed, Nov 30, 2011 at 11:18 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>wrote:
Stef, Sig,
Thanks for the preview!
One thing that jumped out at me so far is the passing of strings by copy. Interestingly, I can't find an example (in my code where I would have sworn I had a few) of having an external library fill a string, but I know I have encountered it and wonder if/how Spock would handle it. This reminds me of Dolphin's default "pass by reference" (albeit in reverse) for external byte objects.
In short, the Dolphin vm automatically passes the address of certain objects, and it often does what one wants. It also makes some things difficult to do. For example, one time I had to pass a COM interface pointer from one component to another, and to do it in Dolphin, I had to construct an intermediate byte object to hold the pointer, just so the vm would have a gratuitous level of indirection to remove in making the call. In fairness, I encountered very few such examples, but OA did ultimately express some regret over the decision. FWIW.
A comment in the document asks about the available types, citing float, double and boolean. All good examples. We also need a full range of integer sizes (8, 16, 32, 64 bytes), signed and unsigned, and in array form. We need Float and double arrays too. Floats are sometimes used to save space (especially in multi-dimensional settings), and some researchers might care to use floats and doubles separately to look at roundoff error in computations. The real reason to have floats and doubles is that there are libraries that use both types.
Another type that crops up is long double. So far, I can't say they have been critical to my work, but I have had to hack around appearances of them.
The chapter shows the use of <primitive:module:> and states that it avoids the need to create instances. Very true, but I pose the question of whether we should encourage formal library (handle body) instances? The idea is that it provides some hope of being able to unload a library while the image is running. Whether that has any teeth is open for debate (I recall having trouble getting libraries to actually unload on a certain OS that will remain nameless<g>). In fairness to that OS, I do not recall the circumstances, but it sure seemed like yet another weirdness.
Another advantage of placing the library name in one method is that it can be edited in one place. GSL has *thousands* of functions and hence thousands of wrapper methods. Tweaking every one would be ugly. Worse, ODBC goes by different names on Windows and Linux, and I doubt it is alone. There is a real role for #moduleName to test the OS and answer the appropriate string - something that can't be done with <primitive:module:>.
Dolphin uses a class per library and a singleton instance of each; it "felt right," and Pharo's FFI will work that way. I subclass ExternalLibrary and do not specify a module name for each function call. Bottom line, if you get callbacks working, I'll play along regardless of small details :)
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, November 30, 2011 2:00 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] VM page in pharo book is outdated
everything is public no secret
https://gforge.inria.fr/scm/viewvc.php/?root=pharobooks
just a lot of work â¦. and pain with english
Stef
On Nov 30, 2011, at 7:19 PM, Igor Stasenko wrote:
On 30 November 2011 18:56, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Stef,
Apologies if I am exploiting something you meant to send privately, but "draft of a chapter" on FFI?????!!!!!! :) :) :)
I'm no expert, but I certainly like to see what is being written. It is difficult to imagine how I could fail to learn something from it.
hmm, i seen a draft in my mailbox, but i cannot remember if i received privately or from public mailing list.
And of course, there is no reason to keep it private: i think the more reviewers/readers it has, the better it will be.
Bill
-- Best regards, Igor Stasenko.
-- Lic. Javier Pimás Ciudad de Buenos Aires
participants (8)
-
Esteban Lorenzano -
Guillermo Polito -
Igor Stasenko -
Javier Pimás -
Mariano Martinez Peck -
Schwab,Wilhelm K -
Serge Stinckwich -
Stéphane Ducasse