Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
this test does not exist anymore
[simgrid.git] / doc / doxygen / bindings.doc
index 25721cc..d89e426 100644 (file)
@@ -1,11 +1,8 @@
 /*! \page bindings Bindings
 
-\section MSG_Ruby Ruby Binding
-Check online for our specific [Simgrid-Ruby documentation](http://simgrid.gforge.inria.fr/documentation.html).
-
 \section MSG_Java Java Binding
 Simgrid-java is a java API that let you use [Simgrid](http://simgrid.gforge.inria.fr/)
-MSG API in your favorite language (java). Without it, you would be forced to
+MSG and SURF API in your favorite language (java). Without it, you would be forced to
 use C or one of the other bindings provided.
 
 MSG was the first distributed programming environment provided within SimGrid.
@@ -16,19 +13,20 @@ The javadoc is accessible [here](javadoc/index.html)
 
 \subsection bindings_binding_Java_jMSG_who Who should use this (and who shouldn't)
 You should use MSG if you want to study some heuristics for a given problem you
-don't really want to implement. SimGrid-java let you use MSG while coding in
-Java. So if your need is MSG + Java, you're in the right section!
+don't really want to implement. SimGrid-java let you use MSG and SURF while coding in
+Java. So if your need is MSG + Java (+ SURF), you're in the right section!
 
-\subsection SimGrid-java Usage overview 
+\subsection SimGrid-java Usage overview
 
-To make a long story short, it's a JNI binding, so it implies that:
-- Most of the MSG and SimGrid documentation about behavioral aspects applies
-  directly to what you are programming. 
-- MSG data structures are mapped to Java objects. So it means that from the
+To make a long story short, it's a JNI binding for MSG and a SWIG binding for SURF,
+so it implies that:
+- Most of the MSG/SURF and SimGrid documentation about behavioral aspects applies
+  directly to what you are programming.
+- MSG/SURF data structures are mapped to Java objects. So it means that from the
   syntax point of view, you have to know how those objects are. Fortunately,
   we have generated the Javadoc for those objects. So take a look at it
 
-Finally, it implies also that your program can crash for 3 main reasons: 
+Finally, it implies also that your program can crash for 3 main reasons:
 - Your Java part is not good: you'll have a good old java exception thrown,
   and hence you should be able to correct it by yourself.
 - Our java part is not good: you'll also have a java exception thrown, but
@@ -38,7 +36,7 @@ Finally, it implies also that your program can crash for 3 main reasons:
   you should read carefully MSG samples and/or documentation.
 - Something has crashed in the C part. Okay, here comes the tricky thing.
 
-C crashes mainly for 2 reasons: 
+C crashes mainly for 2 reasons:
 - When something goes wrong in your simulation, sometimes the C part stops
   because you used SimGrid incorrectly, and JNI bindings are not fond of that.
   It means that you'll have something that looks ugly, but you should be able
@@ -54,12 +52,12 @@ To use java with Simgrid you have to install some dependencies:
 - Java JDK packages, such as `openjdk7` or `sun-java6-jdk` (with `libgcj10-dev` or another
   version of gcj). For maximal performance and scalability, use a coroutine-enabled JVM (see
   \ref bindings_binding_java_coroutines).
+
 Then build Simgrid with the Java bindings enabled:
 ~~~~{.sh}
 cmake -Denable_java=ON .
 ~~~~
+
 If cmake complains that **jni could not be found**, you need to tell it where
 JNI header files are located. the following command should tell you:
 
@@ -83,7 +81,7 @@ $ cmake .
 \subsubsection bindings_binding_java_use How to use Simgrid-java
 
 To execute the examples you need to add the path where you installed
-the generated `libSG_java` and `libsimgrid` libraries
+the generated `libsimgrid-java` and `libsimgrid` libraries
 into the `LD_LIBRARY_PATH`.
 
 Be careful on Mac, this variable is called `DYLD_LIBRARY_PATH` and not
@@ -93,7 +91,7 @@ Be careful on Mac, this variable is called `DYLD_LIBRARY_PATH` and not
 $ export SIMGRID_ROOT="$HOME/Install/simgrid/" # change it to the path where you installed the SimGrid library
 $ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$SIMGRID_ROOT/lib
 $ cd examples
-$ java -cp .:../simgrid.jar basic/BasicTest platform.xml basic/basicDeployment.xml
+$ java -classpath .:../simgrid.jar basic/BasicTest platform.xml basic/basicDeployment.xml
 ~~~~
 
 If you want to make these settings permanent even after a reboot, you
@@ -111,7 +109,7 @@ context factory itself remains a bit experimental so far.
 \subsubsection  bindings_java_coro_install Getting a mlvm JVM
 
 You need to get a patched JVM from [here](http://ssw.jku.at/General/Staff/LS/coro/)
-(many thanks to Lukas Stadler for this work!). 
+(many thanks to Lukas Stadler for this work!).
 
 You can either get a prebuilt binary, or recompile your own JVM. Make
 sure to get a coro-simple version, as we don't need to serialize nor
@@ -123,17 +121,17 @@ Finally, if you're really stuck, you can get the version compiled by
 Jonathan Rouzaud-Cornabas from his web page. This version is known to
 work with SimGrid for sure!
 http://graal.ens-lyon.fr/~jrouzaud/files/corosimple-linux-amd64-20120914.tgz
+
  -# Install mercurial and some dependencies
 ~~~~{.sh}
 sudo apt-get install mercurial ksh libfreetype6-dev libcups2-dev libasound2-dev gawk openjdk-7-jdk libxext-dev libxrender-dev libxtst-dev
 # Grab the forest extension: we need to source-install it
-hg clone https://bitbucket.org/gxti/hgforest hgforest \endverbatim
+hg clone https://bitbucket.org/gxti/hgforest hgforest
 ~~~~
  -# Configure the mercurial extensions: Edit ~/.hgrc and paste the
     following lines. Don't forget to change the /path/to/forest.py to
-    point to where you just downloaded the source. 
-    
+    point to where you just downloaded the source.
+
     Forest extension is needed to download the openjdk source code and
     patches while the mq line is needed to apply the patches. The
     username is needed at the step "preparing the sources", not sure why.
@@ -160,27 +158,27 @@ bash patches/make/link-patch-dirs.sh sources patches
 ls -i patches/hotspot/series sources/hotspot/.hg/patches/series
 # It should display something like the following.
 # (note that both file share the same inode number)
-#  9707849 patches/hotspot/series  
+#  9707849 patches/hotspot/series
 #  9707849 sources/hotspot/.hg/patches/series
 
-
-# Specify what to compile. 
-export davinci=$(pwd) guards="buildable testable coro-simple"
+# Specify what to compile.
+export davinci=${pwd} guards="buildable testable coro-simple"
 # Apply the patches
-sh patches/make/each-patch-repo.sh hg qselect --reapply $guards '$(sh $davinci/patches/make/current-release.sh)'
+sh patches/make/each-patch-repo.sh hg qselect --reapply $guards `sh $davinci/patches/make/current-release.sh`
 # Check that it understood that you want the patch applied:
-grep GLOBAL_GUARDS patches/make/* -r
+grep -r GLOBAL_GUARDS patches/make/
 # this should display something like the following (maybe amonst other unrelated lines)
 # GLOBAL_GUARDS=buildable testable coro-simple
 # If this does not work, edit patches/make/Makefile,
-#   manually coro-simple to GLOBAL_GUARDS and then 
+#   manually coro-simple to GLOBAL_GUARDS and then
 #   rerun the patches/make/each-patch-repo.sh script as earlier
 
 
 # Finish the setup
-(cd patches/make; make setup && make force && make && make FORCE_VERSIONS=1 && echo "Sources are properly setup")
+cd patches/make;
+make setup && make force && make && make FORCE_VERSIONS=1 && echo "Sources are properly setup"
 # If this last command failed, check your mercurial config within ~/.hgrc (see above)
-~~~~       
+~~~~
  -# Compile it all
 ~~~~{.sh}
 unset LD_LIBRARY_PATH
@@ -203,16 +201,16 @@ factory if your JVM support it, so you will just need to execute your
 simulation with the correct JVM. The selected context factory gets
 displayed automatically.
 ~~~~{.sh}
-export LD_LIBRARY_PATH=/path/to/simgrid.so:/path/to/libSG_java.so
+export LD_LIBRARY_PATH=/path/to/simgrid.so:/path/to/libsimgrid-java.so
 cd examples
-$PATH_TO_COROUTINE_JVM/java -cp .:../simgrid.jar masterslave.Masterslave masterslave/ masterslaveDeployment.xml platform.xml
+$PATH_TO_COROUTINE_JVM/java -classpath .:../simgrid.jar masterslave.Masterslave masterslave/ masterslaveDeployment.xml platform.xml
 ~~~~
 
 Note that you may have to adjust the "coro.stacksPerThread"
 configuration option to run large simulations. The default is 100 and
 you want to increase it to run more processes.
 ~~~~{.sh}
-$ $PATH_TO_COROUTINE_JVM/java -Dcoro.stacksPerThread=$STACKS_NUMBER -cp .:../simgrid.jar basic/BasicTest platform.xml basic/basicDeployment.xml
+$ $PATH_TO_COROUTINE_JVM/java -Dcoro.stacksPerThread=$STACKS_NUMBER -classpath .:../simgrid.jar basic/BasicTest platform.xml basic/basicDeployment.xml
 ~~~~
 
 If you reach the point where the creation of new simulated processes
@@ -228,7 +226,7 @@ process can manage (by default, this limit is often at 65535). Since
 the JVM needs a few dozen of such maps on its own (three maps per
 dynamic library -- check `/proc/the_pid/maps` if you don't believe it),
 this is enough to create over 30,000 simulated processes. But to go
-futher, that limit must be modified. 
+futher, that limit must be modified.
 
 If you want to make this change permanent on your machine, edit your
 `/etc/sysctl.conf` file. Otherwise, you have to redo it by calling
@@ -236,12 +234,6 @@ sysctl after each reboot.
 
 \section bindings_binding_lua Lua Binding
 
-Most of Simgrid modules require a  good level in C programming, since simgrid is used to be as standard C library.
- Sometime users prefer using some kind of “easy scripts” or a language easier to code with, for their works,
- which avoid dealing with C errors, and sometime an important  gain of time.
-Besides Java Binding, Lua  and Ruby bindings are available since version 3.4 of Simgrid
-for MSG Module, and we are currenlty working on bindings for other modules.
-
 \subsection bindings_binding_lua_about What is lua ?
 Lua is a lightweight, reflective, imperative and functional programming language,
  designed as a scripting language with extensible semantics as a primary goal (see official web site <a href="http://www.lua.org">here</a>).
@@ -251,234 +243,5 @@ it combines procedural features with powerful data description facilities,
  by using a simple, yet powerful, mechanism of tables.
 Lua has a relatively simple C API compared to other scripting languages,
 and accordingly it provides a robust, easy to use it.
-\subsubsection bindings_binding_lua_simgrid How to use lua in Simgrid ?
-Actually, the use of lua in Simgrid is quite simple, you have just to follow the same steps as coding with C in Simgird :
-  - Coding functions coresponding to each process
-  - loading the platforme/deployment XML file that describe the environment of simulation
-  - and … Running the Simulation.
-
-\dontinclude lua/masterslave/master.lua
-\subsection bindings_binding_lua_example_master_slave Master/Slave Example
-
- \li Master Code
- \until end_of_master
-we mainly  use   simgrid.Task.new(task_name,computation_size,communication_size) to create our MSG Task,
-        then simgrid.Task.send(task,alias) to send it.
-we use also simgrid.Task.name(task), to get the task's name.
-
-\dontinclude lua/masterslave/slave.lua
-\li Slave Code
-\until end_of_slave
-Here, we see the use of simgrid.Task.recv(alias) to receive a task with a specific alias,
-this function return directly the task recevied.
-
-\dontinclude lua/masterslave/master_slave.lua
-\li Set Environmenet and run application
-\until end-of-master-slave
-
-\subsection bindings_binding_lua_example_data Exchanging Data
-You can also exchange data between Process using lua. for that, you have to deal with lua task as a table,
-since lua is based itself on a mechanism of tables,
-so you can exchange any kind of data (tables, matrix, strings,…) between process via tasks.
-
-\li Sender process
-\verbatim
-  task = simgrid.Task.new("data_task",task_comp,task_comm);
-  task['matrix'] = my_matrix;
-  task['table'] = my_table;
-  task['message'] = "Hello from (Lua || Simgrid ) !! "
-  …
-  simgrid.Task.send(task,alias)
-\endverbatim
-       After creating task, we associate to it various kind of data with a specific key (string in this case)
-       to distinguish between data variables. The receiver will use this key to access easily to datas.
-
-
-\li Receiver processe
-\verbatim
-  task = simgrid.Task.recv(alias);
-  sender_matrix = task['matrix'];
-  sender_table = task['table'];
-  sender_message = task['message']
-  ...
-\endverbatim
-       Note that in lua, both sender and receiver share the same lua task.
-       So that the receiver could joint data directly on the received task without sending it back.
-       You can find  a complet example (matrix multiplication case) in the file example/lua/mult_matrix.lua.
-
-
-\subsection bindings_binding_lua_example_bypass Bypass XML
-       maybe you wonder if there is a way to bypass the XML files,
-        and describe your platform directly from the code, with lua bindings it's Possible !! how ?
-       We provide some additional (tricky?) functions in lua that allows you to set up your own platform without using the XML files
-     ( this can be useful for large platforms, so a simple for loop will avoid you to deal with an annoying XML File ;) )
-
-
-\li set Routing mode
-\verbatim
-   simgrid.AS.new{id="AS0",mode="Full"};
-\endverbatim
-
-\li set Hosts
-\verbatim
-  simgrid.Host.new{id="Tremblay",power=98095000};
-  simgrid.Host.new{id="Jupiter",power=76296000};
-  simgrid.Host.new{id="Fafard",power=76296000};
-  simgrid.Host.new{id="Ginette",power=48492000};
-  simgrid.Host.new{id="Bourassa",power=48492000};
-\endverbatim
-  we use simgrid.Host.new{id=id_host,power=power_host} to instanciate our hosts.
-
-\li set Links
-\verbatim
-  for i=0,11 do
-    simgrid.Link.new{id=i,bandwidth=252750+ i*768,latency=0.000270544+i*0.087};    --  some crazy values ;)
-  end
-\endverbatim
-  we used simgrid.Link.new{id=link_id,bandwidth=bw,latency=lat} with a simple for loop to create all links we need (much easier than XML hein ?)
-
-\li set Routes
-\verbatim
--- simgrid.Route.new(src_id,des_id,links_nb,links_list)
-   simgrid.Route.new("Tremblay","Jupiter",1,{"1"});
-   simgrid.Route.new("Tremblay","Fafard",6,{"0","1","2","3","4","8"});
-   simgrid.Route.new("Tremblay","Ginette",3,{"3","4","5"});
-   simgrid.Route.new("Tremblay","Bourassa",7,{"0","1","3","2","4","6","7"});
-
-   simgrid.Route.new("Jupiter","Tremblay",1,{"1"});
-   simgrid.Route.new("Jupiter","Fafard",7,{"0","1","2","3","4","8","9"});
-   simgrid.Route.new("Jupiter","Ginette",4,{"3","4","5","9"});
-   simgrid.Route.new("Jupiter","Bourassa",8,{"0","1","2","3","4","6","7","9"});
-   ...
-\endverbatim
-  for each host you have to specify which route to choose to access to the rest of hosts connected in the grid.
-
-\li Save platform
-\verbatim
-  simgrid.register_platform();
-\endverbatim
-Don't forget to register your platform, that SURF callbacks starts their work ;)
-
-\li set application
-\verbatim
-   simgrid.Host.setFunction("Tremblay","Master",4,{"20","550000000","1000000","4"});
-   simgrid.Host.setFunction("Bourassa","Slave",1,{"0"});
-   simgrid.Host.setFunction("Jupiter","Slave",1,{"1"});
-   simgrid.Host.setFunction("Fafard","Slave",1,{"2"});
-   simgrid.Host.setFunction("Ginette","Slave",1,{"3"});
-\endverbatim
-  you don't  need to use a deployment XML file, thanks to  simgrid.Host.setFunction(host_id,function,args_number,args_list)
-  you can associate functions for each host with arguments if needed .
-
-\li
-\verbatim
-   simgrid.register_application();
-\endverbatim
-Yes, Here too you have to register your application before running the simulation.
-
-the full example is distributed in the file examples/lua/master_slave_bypass.lua
-
-\subsection MSG_ex_master_slave_lua Master/slave Lua application
-
-Simulation of a master-slave application using lua bindings    
-- \ref MSG_ext_ms_master_lua
-- \ref MSG_ext_ms_slave_lua
-- \ref MSG_ext_ms_core_lua
-- \ref MSG_ext_ms_helping
-- \ref MSG_ext_ms_application
-- \ref MSG_ext_ms_platform
-
-
-     
-\subsubsection MSG_ext_ms_master_lua Master code
-
-as described in the C native master/Slave example, this function has to be assigned to a msg_process_t that will behave as the master.
-
-Lua style arguments (...) in for the master are interpreted as:
-- the number of tasks to distribute
-- the computation size of each task
-- the size of the files associated to each task
-- a list of host that will accept those tasks.
-
-Tasks are dumbly sent in a round-robin style.
-\dontinclude lua/masterslave/master.lua
-\skip Dispatch the tasks
-\until Done sending
-\until end
-
-
-\subsubsection MSG_ext_ms_slave_lua Slave code
-
-This function has to be assigned to a #msg_process_t that has to behave as a slave.
-This function keeps waiting for tasks and executes them as it receives them.
-\dontinclude lua/masterslave/slave.lua
-\until end_of_slave
-\subsubsection MSG_ext_ms_core_lua Simulation core
-
-in this section the core of the simulation which start by including the simgrid lib for bindings
-: <i>require "simgrid" </i>
-
--# Simulation settings : <i>simgrid.platform</i> creates a realistic
-   environment
--# Application deployment : create the processes on the right locations with
-    <i>simgrid.application</i>
--# The simulation is run with <i>simgrid.run</i>
-
-Its arguments are:
-- <i>platform_file</i>: the name of a file containing an valid surfxml platform description.( first command line argument)
-- <i>application_file</i>: the name of a file containing a valid surfxml application description ( second commande line argument )
-\dontinclude lua/masterslave/master_slave.lua
-\skip platform
-\until run
-
-
-\subsection MSG_ex_master_slave_lua_bypass Master/slave Bypass Lua application
-
-Simulation of a master-slave application using lua bindings, Bypassing the XML parser
-- \ref MSG_ext_ms_bp_master_lua
-- \ref MSG_ext_ms_bp_slave_lua
-- \ref MSG_ext_ms_bp_core_lua
-
-      
-
-\subsubsection MSG_ext_ms_bp_master_lua Master code
-
-as described in the C native master/Slave example, this function has to be assigned to a msg_process_t that will behave as the master.
-
-Lua style arguments (...) in for the master are interpreted as:
-- the number of tasks to distribute
-- the computation size of each task
-- the size of the files associated to each task
-- a list of host that will accept those tasks.
-
-Tasks are dumbly sent in a round-robin style.
-
-\dontinclude lua/console/master.lua
-\until end_of_master
-
-\subsubsection MSG_ext_ms_bp_slave_lua Slave code
-
-This function has to be assigned to a #msg_process_t that has to behave as a slave.
-This function keeps waiting for tasks and executes them as it receives them.
-
-\dontinclude lua/console/slave.lua
-\until end_of_slave
-
-\subsubsection MSG_ext_ms_bp_core_lua Simulation core
-
-in this section the core of the simulation which start by including the simgrid lib for bindings, then create the resources we need to set up our environment bypassing the XML parser.
-: <i>require "simgrid" </i>
-
--# Hosts : <i>simgrid.Host.new</i> instanciate a new host with an id, and power.
--# Links : <i>simgrid.Link.new</i> instanictae a new link that will require an id, bandwith and latency values.
--# Route : <i>simgrid.Route.new</i> define a route between two hosts specifying the links to use.
--# Simulation settings : <i>simgrid.register_platform();</i> register own platform without using the XML SURF parser.
-
-we can also bypass the XML deployment file, and associate functions for each of defined hosts.
-- <i>simgrid.Host.setFunction</i>: associate a function to a host, specifying arguments if needed.
-- <i>simgrid.register_application()</i>: saving the deployment settings before running the simualtion.
-
-\include lua/console/master_slave_bypass.lua
-
 
  */