Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
first try at killing GRAS -- does not compile yet
authorMartin Quinson <martin.quinson@loria.fr>
Thu, 22 Nov 2012 14:33:49 +0000 (15:33 +0100)
committerMartin Quinson <martin.quinson@loria.fr>
Thu, 22 Nov 2012 14:33:49 +0000 (15:33 +0100)
318 files changed:
buildtools/Cmake/CompleteInFiles.cmake
buildtools/Cmake/DefinePackages.cmake
buildtools/Cmake/Distrib.cmake
buildtools/Cmake/MaintainerMode.cmake
buildtools/Cmake/MakeExe.cmake
buildtools/Cmake/MakeLib.cmake
buildtools/Cmake/PrintArgs.cmake
buildtools/Cmake/Supernovae.cmake
buildtools/Cmake/UnitTesting.cmake
buildtools/Cmake/src/simgrid.nsi.in
buildtools/Cmake/test_prog/prog_GRAS_ARCH.c [deleted file]
buildtools/Cmake/test_prog/prog_GRAS_CHECK_STRUCT_COMPACTION.c [deleted file]
doc/gras_comm.png [deleted file]
doc/gtut-files/01-bones.c [deleted file]
doc/gtut-files/01-bones.output [deleted file]
doc/gtut-files/02-simple.c [deleted file]
doc/gtut-files/02-simple.output [deleted file]
doc/gtut-files/03-args.c [deleted file]
doc/gtut-files/03-args.output [deleted file]
doc/gtut-files/03-args.xml [deleted file]
doc/gtut-files/04-callback.c [deleted file]
doc/gtut-files/04-callback.output [deleted file]
doc/gtut-files/05-globals.c [deleted file]
doc/gtut-files/05-globals.output [deleted file]
doc/gtut-files/06-logs.c [deleted file]
doc/gtut-files/06-logs.output [deleted file]
doc/gtut-files/06-logs.output.error [deleted file]
doc/gtut-files/06-logs.output.fmt [deleted file]
doc/gtut-files/06-logs.output.fmt-bt [deleted file]
doc/gtut-files/06-logs.output.verbose [deleted file]
doc/gtut-files/07-timers.c [deleted file]
doc/gtut-files/07-timers.output [deleted file]
doc/gtut-files/08-exceptions.c [deleted file]
doc/gtut-files/08-exceptions.output [deleted file]
doc/gtut-files/09-datatype-dump.c [deleted file]
doc/gtut-files/09-simpledata.c [deleted file]
doc/gtut-files/09-simpledata.output [deleted file]
doc/gtut-files/10-rpc.c [deleted file]
doc/gtut-files/10-rpc.output [deleted file]
doc/gtut-files/11-explicitwait.c [deleted file]
doc/gtut-files/11-explicitwait.output [deleted file]
doc/gtut-files/11-explicitwait.xml [deleted file]
doc/gtut-files/Makefile [deleted file]
doc/gtut-files/README [deleted file]
doc/gtut-files/gtut-howto-design.doc [deleted file]
doc/gtut-files/gtut-howto.doc [deleted file]
doc/gtut-files/gtut-introduction.doc [deleted file]
doc/gtut-files/gtut-main.doc [deleted file]
doc/gtut-files/gtut-platform-3nodes.xml [deleted file]
doc/gtut-files/gtut-platform.xml [deleted file]
doc/gtut-files/gtut-tour-00-install.doc [deleted file]
doc/gtut-files/gtut-tour-01-bones.doc [deleted file]
doc/gtut-files/gtut-tour-02-simple.doc [deleted file]
doc/gtut-files/gtut-tour-03-args.doc [deleted file]
doc/gtut-files/gtut-tour-04-callback.doc [deleted file]
doc/gtut-files/gtut-tour-05-globals.doc [deleted file]
doc/gtut-files/gtut-tour-06-logs.doc [deleted file]
doc/gtut-files/gtut-tour-07-timers.doc [deleted file]
doc/gtut-files/gtut-tour-08-exceptions.doc [deleted file]
doc/gtut-files/gtut-tour-09-simpledata.doc [deleted file]
doc/gtut-files/gtut-tour-10-rpc.doc [deleted file]
doc/gtut-files/gtut-tour-11-explicitwait.doc [deleted file]
doc/gtut-files/gtut-tour-12-staticstruct.doc [deleted file]
doc/gtut-files/gtut-tour-13-pointers.doc [deleted file]
doc/gtut-files/gtut-tour-14-dynar.doc [deleted file]
doc/gtut-files/gtut-tour-15-manualdatadef.doc [deleted file]
doc/gtut-files/gtut-tour-16-exchangecb.doc [deleted file]
doc/gtut-files/gtut-tour-recap-messages.doc [deleted file]
doc/gtut-files/gtut-tour.doc [deleted file]
doc/gtut-files/test.xml [deleted file]
doc/ref_guide/doxygen/module-gras.doc [deleted file]
examples/amok/alnem/alnem.c [deleted file]
examples/amok/alnem/alnem_builder.c [deleted file]
examples/amok/alnem/alnem_deployment.txt [deleted file]
examples/amok/alnem/deploy_WAN3.txt [deleted file]
examples/amok/alnem/interference.dat [deleted file]
examples/amok/bandwidth/CMakeLists.txt [deleted file]
examples/amok/bandwidth/bandwidth.c [deleted file]
examples/amok/bandwidth/bandwidth.xml [deleted file]
examples/amok/bandwidth/bandwidth_rl.tesh [deleted file]
examples/amok/bandwidth/bandwidth_sg_32.tesh [deleted file]
examples/amok/bandwidth/bandwidth_sg_64.tesh [deleted file]
examples/amok/saturate/CMakeLists.txt [deleted file]
examples/amok/saturate/env.c [deleted file]
examples/amok/saturate/medium_deployment.xml [deleted file]
examples/amok/saturate/saturate.c [deleted file]
examples/amok/saturate/saturate.xml [deleted file]
examples/amok/saturate/saturate_rl.tesh [deleted file]
examples/amok/saturate/saturate_sg_32.tesh [deleted file]
examples/amok/saturate/saturate_sg_64.tesh [deleted file]
examples/gras/all2all/CMakeLists.txt [deleted file]
examples/gras/all2all/all2all.c [deleted file]
examples/gras/all2all/all2all.xml [deleted file]
examples/gras/all2all/make_deployment.pl [deleted file]
examples/gras/all2all/run.sh [deleted file]
examples/gras/all2all/test_rl.tesh [deleted file]
examples/gras/all2all/test_sg_32.tesh [deleted file]
examples/gras/all2all/test_sg_64.tesh [deleted file]
examples/gras/chrono/CMakeLists.txt [deleted file]
examples/gras/chrono/chrono.c [deleted file]
examples/gras/chrono/chrono.xml [deleted file]
examples/gras/chrono/chrono2.c [deleted file]
examples/gras/chrono/test_rl.tesh [deleted file]
examples/gras/chrono/test_sg_32.tesh [deleted file]
examples/gras/chrono/test_sg_64.tesh [deleted file]
examples/gras/console/CMakeLists.txt [deleted file]
examples/gras/console/gras_platform_script.lua [deleted file]
examples/gras/console/ping.h [deleted file]
examples/gras/console/ping_client.c [deleted file]
examples/gras/console/ping_common.c [deleted file]
examples/gras/console/ping_generator.lua [deleted file]
examples/gras/console/ping_server.c [deleted file]
examples/gras/mmrpc/CMakeLists.txt [deleted file]
examples/gras/mmrpc/mmrpc.c [deleted file]
examples/gras/mmrpc/mmrpc.h [deleted file]
examples/gras/mmrpc/mmrpc.xml [deleted file]
examples/gras/mmrpc/mmrpc_client.c [deleted file]
examples/gras/mmrpc/mmrpc_common.c [deleted file]
examples/gras/mmrpc/mmrpc_server.c [deleted file]
examples/gras/mmrpc/test_rl.tesh [deleted file]
examples/gras/mmrpc/test_sg_32.tesh [deleted file]
examples/gras/mmrpc/test_sg_64.tesh [deleted file]
examples/gras/mutual_exclusion/simple_token/CMakeLists.txt [deleted file]
examples/gras/mutual_exclusion/simple_token/make_deployment.pl [deleted file]
examples/gras/mutual_exclusion/simple_token/run.sh [deleted file]
examples/gras/mutual_exclusion/simple_token/simple_token.c [deleted file]
examples/gras/mutual_exclusion/simple_token/simple_token.xml [deleted file]
examples/gras/mutual_exclusion/simple_token/test_rl.tesh [deleted file]
examples/gras/mutual_exclusion/simple_token/test_sg_32.tesh [deleted file]
examples/gras/mutual_exclusion/simple_token/test_sg_64.tesh [deleted file]
examples/gras/p2p/can/can.c [deleted file]
examples/gras/p2p/can/can.xml [deleted file]
examples/gras/p2p/can/can_tests.c [deleted file]
examples/gras/p2p/can/test_rl.in [deleted file]
examples/gras/p2p/can/test_sg.in [deleted file]
examples/gras/p2p/can/types.h [deleted file]
examples/gras/p2p/chord/chord.c [deleted file]
examples/gras/p2p/chord/chord.xml [deleted file]
examples/gras/p2p/chord/test_rl.in [deleted file]
examples/gras/p2p/chord/test_sg.in [deleted file]
examples/gras/ping/CMakeLists.txt [deleted file]
examples/gras/ping/ping.h [deleted file]
examples/gras/ping/ping.xml [deleted file]
examples/gras/ping/ping_client.c [deleted file]
examples/gras/ping/ping_common.c [deleted file]
examples/gras/ping/ping_server.c [deleted file]
examples/gras/ping/test_rl.tesh [deleted file]
examples/gras/ping/test_sg_32.tesh [deleted file]
examples/gras/ping/test_sg_64.tesh [deleted file]
examples/gras/pmm/CMakeLists.txt [deleted file]
examples/gras/pmm/make_deployment.pl [deleted file]
examples/gras/pmm/pmm.c [deleted file]
examples/gras/pmm/pmm.xml [deleted file]
examples/gras/pmm/test_rl.tesh [deleted file]
examples/gras/pmm/test_sg_32.tesh [deleted file]
examples/gras/pmm/test_sg_64.tesh [deleted file]
examples/gras/properties/CMakeLists.txt [deleted file]
examples/gras/properties/properties.c [deleted file]
examples/gras/properties/properties.xml [deleted file]
examples/gras/properties/test_rl.tesh [deleted file]
examples/gras/properties/test_sg.tesh [deleted file]
examples/gras/replay/do_simulation.pl [deleted file]
examples/gras/replay/replay.c [deleted file]
examples/gras/replay/replay.xml [deleted file]
examples/gras/replay/workload.h [deleted file]
examples/gras/replay/xbt_workload.c [deleted file]
examples/gras/rpc/CMakeLists.txt [deleted file]
examples/gras/rpc/rpc.c [deleted file]
examples/gras/rpc/rpc.xml [deleted file]
examples/gras/rpc/test_rl.tesh [deleted file]
examples/gras/rpc/test_sg_32.tesh [deleted file]
examples/gras/rpc/test_sg_64.tesh [deleted file]
examples/gras/spawn/CMakeLists.txt [deleted file]
examples/gras/spawn/spawn.c [deleted file]
examples/gras/spawn/spawn.h [deleted file]
examples/gras/spawn/spawn.xml [deleted file]
examples/gras/spawn/test_rl.tesh [deleted file]
examples/gras/spawn/test_sg_32.tesh [deleted file]
examples/gras/spawn/test_sg_64.tesh [deleted file]
examples/gras/synchro/CMakeLists.txt [deleted file]
examples/gras/synchro/philosopher.c [deleted file]
examples/gras/synchro/synchro.xml [deleted file]
examples/gras/synchro/test_rl.tesh [deleted file]
examples/gras/synchro/test_sg_32.tesh [deleted file]
examples/gras/synchro/test_sg_64.tesh [deleted file]
examples/gras/tests.mk [deleted file]
examples/gras/timer/CMakeLists.txt [deleted file]
examples/gras/timer/test_rl.tesh [deleted file]
examples/gras/timer/test_sg_32.tesh [deleted file]
examples/gras/timer/test_sg_64.tesh [deleted file]
examples/gras/timer/timer.c [deleted file]
examples/gras/timer/timer.xml [deleted file]
examples/platforms/content/storage_content.txt
examples/temps-gras-stub.mk [deleted file]
include/amok/bandwidth.h [deleted file]
include/amok/base.h [deleted file]
include/amok/peermanagement.h [deleted file]
include/gras.h [deleted file]
include/gras/emul.h [deleted file]
include/gras/messages.h [deleted file]
include/gras/module.h [deleted file]
include/gras/process.h [deleted file]
include/gras/timer.h [deleted file]
include/gras/transport.h [deleted file]
include/gras/virtu.h [deleted file]
include/xbt/socket.h [deleted file]
include/xbt/time.h [deleted file]
include/xbt/virtu.h
src/amok/Bandwidth/bandwidth.c [deleted file]
src/amok/Bandwidth/bandwidth_private.h [deleted file]
src/amok/Bandwidth/saturate.c [deleted file]
src/amok/PeerManagement/peermanagement.c [deleted file]
src/amok/amok_base.c [deleted file]
src/amok/amok_modinter.h [deleted file]
src/gras/Msg/gras_msg_exchange.c [deleted file]
src/gras/Msg/gras_msg_listener.c [deleted file]
src/gras/Msg/gras_msg_mod.c [deleted file]
src/gras/Msg/gras_msg_types.c [deleted file]
src/gras/Msg/msg_interface.h [deleted file]
src/gras/Msg/msg_private.h [deleted file]
src/gras/Msg/rl_msg.c [deleted file]
src/gras/Msg/rpc.c [deleted file]
src/gras/Msg/sg_msg.c [deleted file]
src/gras/Msg/timer.c [deleted file]
src/gras/Transport/README [deleted file]
src/gras/Transport/rl_transport.c [deleted file]
src/gras/Transport/sg_transport.c [deleted file]
src/gras/Transport/transport.c [deleted file]
src/gras/Transport/transport_interface.h [deleted file]
src/gras/Transport/transport_plugin_file.c [deleted file]
src/gras/Transport/transport_plugin_sg.c [deleted file]
src/gras/Transport/transport_private.h [deleted file]
src/gras/Virtu/gras_module.c [deleted file]
src/gras/Virtu/process.c [deleted file]
src/gras/Virtu/rl_dns.c [deleted file]
src/gras/Virtu/rl_emul.c [deleted file]
src/gras/Virtu/rl_process.c [deleted file]
src/gras/Virtu/sg_dns.c [deleted file]
src/gras/Virtu/sg_emul.c [deleted file]
src/gras/Virtu/sg_process.c [deleted file]
src/gras/Virtu/virtu_interface.h [deleted file]
src/gras/Virtu/virtu_private.h [deleted file]
src/gras/Virtu/virtu_rl.h [deleted file]
src/gras/Virtu/virtu_sg.h [deleted file]
src/gras/gras.c [deleted file]
src/gras/rl_stubs.c [deleted file]
src/smpi/smpi_base.c
src/surf/surf.c
src/xbt/datadesc/cbps.c [deleted file]
src/xbt/datadesc/datadesc.c [deleted file]
src/xbt/datadesc/datadesc_interface.h [deleted file]
src/xbt/datadesc/datadesc_private.h [deleted file]
src/xbt/datadesc/ddt_convert.c [deleted file]
src/xbt/datadesc/ddt_create.c [deleted file]
src/xbt/datadesc/ddt_exchange.c [deleted file]
src/xbt/datadesc/ddt_parse.c [deleted file]
src/xbt/datadesc/ddt_parse.yy.c [deleted file]
src/xbt/datadesc/ddt_parse.yy.h [deleted file]
src/xbt/datadesc/ddt_parse.yy.l [deleted file]
src/xbt/ex.c
src/xbt/log.c
src/xbt/xbt_log_layout_format.c
src/xbt/xbt_log_layout_simple.c
src/xbt/xbt_queue.c
src/xbt/xbt_rl_time.c [deleted file]
src/xbt/xbt_sg_time.c [deleted file]
src/xbt/xbt_socket.c [deleted file]
src/xbt/xbt_socket_private.h [deleted file]
src/xbt/xbt_trp_plugin_tcp.c [deleted file]
src/xbt/xbt_virtu.c
teshsuite/gras/CMakeLists.txt [deleted file]
teshsuite/gras/README [deleted file]
teshsuite/gras/datadesc/CMakeLists.txt [deleted file]
teshsuite/gras/datadesc/datadesc.big32_8_4 [deleted file]
teshsuite/gras/datadesc/datadesc.big64 [deleted file]
teshsuite/gras/datadesc/datadesc.little32_4 [deleted file]
teshsuite/gras/datadesc/datadesc.little64 [deleted file]
teshsuite/gras/datadesc/datadesc.tesh [deleted file]
teshsuite/gras/datadesc/datadesc_mem.tesh [deleted file]
teshsuite/gras/datadesc/datadesc_r_big32_8_4.tesh [deleted file]
teshsuite/gras/datadesc/datadesc_r_little32_4.tesh [deleted file]
teshsuite/gras/datadesc/datadesc_r_little64.tesh [deleted file]
teshsuite/gras/datadesc/datadesc_rw.tesh [deleted file]
teshsuite/gras/datadesc/datadesc_structs.c [deleted file]
teshsuite/gras/datadesc/datadesc_usage.c [deleted file]
teshsuite/gras/datadesc/mk_datadesc_structs.pl [deleted file]
teshsuite/gras/empty_main/CMakeLists.txt [deleted file]
teshsuite/gras/empty_main/empty_main.c [deleted file]
teshsuite/gras/empty_main/empty_main.xml [deleted file]
teshsuite/gras/empty_main/test_rl.tesh [deleted file]
teshsuite/gras/empty_main/test_sg.tesh [deleted file]
teshsuite/gras/gras.tesh [deleted file]
teshsuite/gras/msg_handle/CMakeLists.txt [deleted file]
teshsuite/gras/msg_handle/msg_handle.c [deleted file]
teshsuite/gras/msg_handle/msg_handle.xml [deleted file]
teshsuite/gras/msg_handle/test_rl.tesh [deleted file]
teshsuite/gras/msg_handle/test_sg_32.tesh [deleted file]
teshsuite/gras/msg_handle/test_sg_64.tesh [deleted file]
teshsuite/gras/numerous_rpc/CMakeLists.txt [deleted file]
teshsuite/gras/numerous_rpc/numerous_rpc.c [deleted file]
teshsuite/gras/numerous_rpc/numerous_rpc.xml [deleted file]
teshsuite/gras/small_sleep/CMakeLists.txt [deleted file]
teshsuite/gras/small_sleep/small_sleep.c [deleted file]
teshsuite/gras/small_sleep/small_sleep.xml [deleted file]
teshsuite/gras/small_sleep/test_sg_32.tesh [deleted file]
teshsuite/gras/small_sleep/test_sg_64.tesh [deleted file]
teshsuite/xbt/log_large_test.c
tools/gras/CMakeLists.txt [deleted file]
tools/gras/gras_stub_generator.h [deleted file]
tools/gras/s_smx_process_t [deleted file]
tools/gras/s_smx_simcall_t [deleted file]
tools/gras/struct_diff.c [deleted file]
tools/gras/stub_generator.bpf [deleted file]
tools/gras/stub_generator.bpr [deleted file]
tools/gras/stub_generator.c [deleted file]
tools/gras/stub_generator4borland.mak [deleted file]
tools/gras/unix_stub_generator.c [deleted file]
tools/gras/windows_stub_generator.c [deleted file]

index dcf4074..82f8524 100644 (file)
@@ -469,143 +469,6 @@ if(EXISTS ${CMAKE_HOME_DIRECTORY}/.git/ AND NOT WIN32)
   endif()
 endif()
 
-###################################
-## SimGrid and GRAS specific checks
-##
-
-IF(NOT CMAKE_CROSSCOMPILING)
-  # Check architecture signature begin
-  try_run(RUN_GRAS_VAR COMPILE_GRAS_VAR
-    ${CMAKE_BINARY_DIR}
-    ${CMAKE_HOME_DIRECTORY}/buildtools/Cmake/test_prog/prog_GRAS_ARCH.c
-    RUN_OUTPUT_VARIABLE var1
-    )
-  if(BIGENDIAN)
-    set(val_big "B${var1}")
-    set(GRAS_BIGENDIAN 1)
-  else()
-    set(val_big "l${var1}")
-    set(GRAS_BIGENDIAN 0)
-  endif()
-
-  # The syntax of this magic string is given in src/xbt/datadesc/ddt_convert.c
-  # It kinda matches the values that the xbt_arch_desc_t structure can take
-
-  # Basically, the syntax is one char l or B for endianness (little or Big)
-  #   then there is a bunch of blocks separated by _.
-  # C block is for char, I block for integers, P block for pointers and
-  #   D block for floating points
-  # For each block there is an amount of chuncks separated by :, each of
-  #   them describing a data size. For example there is only one chunk
-  #   in the char block, because no architecture provide several sizes
-  #   of chars. In integer block, there is 4 chunks: "short int", "int",
-  #   "long int", "long long int". There is 2 pointer chunks for data
-  #   pointers and pointers on functions (thanks to the AMD64 madness).
-  #   Thee two floating points chuncks are for "float" and "double".
-  # Each chunk is of the form datasize/minimal_alignment_size
-
-  # These informations are used to convert a data stream from one
-  #    formalism to another. Only the GRAS_ARCH is transfered in the
-  #    stream, and it it of cruxial importance to keep these detection
-  #    information here synchronized with the data hardcoded in the
-  #    source in src/xbt/datadesc/ddt_convert.c
-
-  # If you add something here (like a previously unknown architecture),
-  #    please add it to the source code too.
-  # Please do not modify stuff here since it'd break the GRAS protocol.
-  #     If you really need to change stuff, please also bump
-  #    GRAS_PROTOCOL_VERSION in src/gras/Msg/msg_interface.h
-
-  SET(GRAS_THISARCH "none")
-
-  if(val_big MATCHES "l_C:1/1:_I:2/1:4/1:4/1:8/1:_P:4/1:4/1:_D:4/1:8/1:")
-    #gras_arch=0; gras_size=32; gras_arch_name=little32_1;
-    SET(GRAS_ARCH_32_BITS 1)
-    SET(GRAS_THISARCH 0)
-  endif()
-  if(val_big MATCHES "l_C:1/1:_I:2/2:4/2:4/2:8/2:_P:4/2:4/2:_D:4/2:8/2:")
-    #gras_arch=1; gras_size=32; gras_arch_name=little32_2;
-    SET(GRAS_ARCH_32_BITS 1)
-    SET(GRAS_THISARCH 1)
-  endif()
-  if(val_big MATCHES "l_C:1/1:_I:2/2:4/4:4/4:8/4:_P:4/4:4/4:_D:4/4:8/4:")
-    #gras_arch=2; gras_size=32; gras_arch_name=little32_4;
-    SET(GRAS_ARCH_32_BITS 1)
-    SET(GRAS_THISARCH 2)
-  endif()
-  if(val_big MATCHES "l_C:1/1:_I:2/2:4/4:4/4:8/8:_P:4/4:4/4:_D:4/4:8/8:")
-    #gras_arch=3; gras_size=32; gras_arch_name=little32_8;
-    SET(GRAS_ARCH_32_BITS 1)
-    SET(GRAS_THISARCH 3)
-  endif()
-  if(val_big MATCHES "l_C:1/1:_I:2/2:4/4:8/8:8/8:_P:8/8:8/8:_D:4/4:8/8:")
-    #gras_arch=4; gras_size=64; gras_arch_name=little64;
-    SET(GRAS_ARCH_32_BITS 0)
-    SET(GRAS_THISARCH 4)
-  endif()
-  if(val_big MATCHES "l_C:1/1:_I:2/2:4/4:4/4:8/8:_P:8/8:8/8:_D:4/4:8/8:")
-    #gras_arch=5; gras_size=64; gras_arch_name=little64_2;
-    SET(GRAS_ARCH_32_BITS 0)
-    SET(GRAS_THISARCH 5)
-  endif()
-
-  if(val_big MATCHES "B_C:1/1:_I:2/2:4/4:4/4:8/8:_P:4/4:4/4:_D:4/4:8/8:")
-    #gras_arch=6; gras_size=32; gras_arch_name=big32_8;
-    SET(GRAS_ARCH_32_BITS 1)
-    SET(GRAS_THISARCH 6)
-  endif()
-  if(val_big MATCHES "B_C:1/1:_I:2/2:4/4:4/4:8/8:_P:4/4:4/4:_D:4/4:8/4:")
-    #gras_arch=7; gras_size=32; gras_arch_name=big32_8_4;
-    SET(GRAS_ARCH_32_BITS 1)
-    SET(GRAS_THISARCH 7)
-  endif()
-  if(val_big MATCHES "B_C:1/1:_I:2/2:4/4:4/4:8/4:_P:4/4:4/4:_D:4/4:8/4:")
-    #gras_arch=8; gras_size=32; gras_arch_name=big32_4;
-    SET(GRAS_ARCH_32_BITS 1)
-    SET(GRAS_THISARCH 8)
-  endif()
-  if(val_big MATCHES "B_C:1/1:_I:2/2:4/2:4/2:8/2:_P:4/2:4/2:_D:4/2:8/2:")
-    #gras_arch=9; gras_size=32; gras_arch_name=big32_2;
-    SET(GRAS_ARCH_32_BITS 1)
-    SET(GRAS_THISARCH 9)
-  endif()
-  if(val_big MATCHES "B_C:1/1:_I:2/2:4/4:8/8:8/8:_P:8/8:8/8:_D:4/4:8/8:")
-    #gras_arch=10; gras_size=64; gras_arch_name=big64;
-    SET(GRAS_ARCH_32_BITS 0)
-    SET(GRAS_THISARCH 10)
-  endif()
-  if(val_big MATCHES "B_C:1/1:_I:2/2:4/4:8/8:8/8:_P:8/8:8/8:_D:4/4:8/4:")
-    #gras_arch=11; gras_size=64; gras_arch_name=big64_8_4;
-    SET(GRAS_ARCH_32_BITS 0)
-    SET(GRAS_THISARCH 11)
-  endif()
-
-  if(GRAS_THISARCH MATCHES "none")
-    message(STATUS "architecture: ${val_big}")
-    message(FATAL_ERROR "GRAS_THISARCH is empty: '${GRAS_THISARCH}'")
-  endif()
-
-  # Check architecture signature end
-  try_run(RUN_GRAS_VAR COMPILE_GRAS_VAR
-    ${CMAKE_BINARY_DIR}
-    ${CMAKE_HOME_DIRECTORY}/buildtools/Cmake/test_prog/prog_GRAS_CHECK_STRUCT_COMPACTION.c
-    RUN_OUTPUT_VARIABLE var2
-    )
-  separate_arguments(var2)
-  foreach(var_tmp ${var2})
-    set(${var_tmp} 1)
-  endforeach(var_tmp ${var2})
-
-  # Check for [SIZEOF_MAX]
-  try_run(RUN_SM_VAR COMPILE_SM_VAR
-    ${CMAKE_BINARY_DIR}
-    ${CMAKE_HOME_DIRECTORY}/buildtools/Cmake/test_prog/prog_max_size.c
-    RUN_OUTPUT_VARIABLE var3
-    )
-  message(STATUS "SIZEOF_MAX ${var3}")
-  SET(SIZEOF_MAX ${var3})
-ENDIF()
-
 #--------------------------------------------------------------------------------------------------
 
 set(makecontext_CPPFLAGS_2 "")
@@ -940,7 +803,6 @@ set(generated_files_to_clean
   ${CMAKE_BINARY_DIR}/bin/simgrid_update_xml
   ${CMAKE_BINARY_DIR}/examples/smpi/tracing/smpi_traced.trace
   ${CMAKE_BINARY_DIR}/src/supernovae_sg.c
-  ${CMAKE_BINARY_DIR}/src/supernovae_gras.c
   ${CMAKE_BINARY_DIR}/src/supernovae_smpi.c
   )
 
index da375fb..83ac2b1 100644 (file)
@@ -3,11 +3,6 @@
 set(EXTRA_DIST
   src/amok/Bandwidth/bandwidth_private.h
   src/amok/amok_modinter.h
-  src/gras/Transport/transport_interface.h
-  src/gras/Virtu/virtu_interface.h
-  src/gras/Virtu/virtu_private.h
-  src/gras/Virtu/virtu_rl.h
-  src/gras/Virtu/virtu_sg.h
   src/include/mc/datatypes.h
   src/include/mc/mc.h
   src/include/simgrid/platf_interface.h
@@ -67,8 +62,6 @@ set(EXTRA_DIST
   src/xbt/backtrace_dummy.c
   src/xbt/backtrace_linux.c
   src/xbt/backtrace_windows.c
-  src/xbt/datadesc/ddt_parse.yy.h
-  src/xbt/datadesc/ddt_parse.yy.l
   src/xbt/dict_private.h
   src/xbt/ex_interface.h
   src/xbt/fifo_private.h
@@ -92,7 +85,6 @@ set(EXTRA_DIST
   src/xbt/mmalloc/mmtrace.awk
   src/xbt/mmalloc/mrealloc.c
   src/xbt/setset_private.h
-  tools/gras/gras_stub_generator.h
   tools/tesh/run_context.h
   tools/tesh/tesh.h
   )
@@ -133,16 +125,6 @@ else()
   )
 endif()
 
-set(GRAS_RL_SRC
-  ${XBT_RL_SRC}
-  src/gras/Msg/rl_msg.c
-  src/gras/Transport/rl_transport.c
-  src/gras/Virtu/rl_dns.c
-  src/gras/Virtu/rl_emul.c
-  src/gras/Virtu/rl_process.c
-  src/gras/rl_stubs.c
-  src/xbt/xbt_os_thread.c
-  )
 
 set(XBT_SRC
   src/gras_modinter.h
@@ -151,15 +133,6 @@ set(XBT_SRC
   src/xbt/automaton/automatonparse_promela.c
   src/xbt/config.c
   src/xbt/cunit.c
-  src/xbt/datadesc/cbps.c
-  src/xbt/datadesc/datadesc.c
-  src/xbt/datadesc/datadesc_interface.h
-  src/xbt/datadesc/datadesc_private.h
-  src/xbt/datadesc/ddt_convert.c
-  src/xbt/datadesc/ddt_create.c
-  src/xbt/datadesc/ddt_exchange.c
-  src/xbt/datadesc/ddt_parse.c
-  src/xbt/datadesc/ddt_parse.yy.c
   src/xbt/dict.c
   src/xbt/dict_cursor.c
   src/xbt/dict_elm.c
@@ -188,12 +161,9 @@ set(XBT_SRC
   src/xbt/xbt_queue.c
   src/xbt/xbt_replay.c
   src/xbt/xbt_sha.c
-  src/xbt/xbt_socket.c
-  src/xbt/xbt_socket_private.h
   src/xbt/xbt_str.c
   src/xbt/xbt_strbuff.c
   src/xbt/xbt_synchro.c
-  src/xbt/xbt_trp_plugin_tcp.c
   src/xbt/xbt_virtu.c
   src/xbt_modinter.h
   )
@@ -331,40 +301,6 @@ else()
     )
 endif()
 
-set(GRAS_COMMON_SRC
-  src/gras/Msg/gras_msg_exchange.c
-  src/gras/Msg/gras_msg_listener.c
-  src/gras/Msg/gras_msg_mod.c
-  src/gras/Msg/gras_msg_types.c
-  src/gras/Msg/msg_interface.h
-  src/gras/Msg/msg_private.h
-  src/gras/Msg/rpc.c
-  src/gras/Msg/timer.c
-  src/gras/Transport/transport.c
-  src/gras/Transport/transport_plugin_file.c
-  src/gras/Transport/transport_private.h
-  src/gras/Virtu/gras_module.c
-  src/gras/Virtu/process.c
-  src/gras/gras.c
-  )
-
-set(GRAS_SG_SRC
-  ${XBT_SG_SRC}
-  src/gras/Msg/sg_msg.c
-  src/gras/Transport/sg_transport.c
-  src/gras/Transport/transport_plugin_sg.c
-  src/gras/Virtu/sg_dns.c
-  src/gras/Virtu/sg_emul.c
-  src/gras/Virtu/sg_process.c
-  )
-
-set(AMOK_SRC
-  src/amok/Bandwidth/bandwidth.c
-  src/amok/Bandwidth/saturate.c
-  src/amok/PeerManagement/peermanagement.c
-  src/amok/amok_base.c
-  )
-
 set(BINDINGS_SRC
   src/bindings/bindings_global.c
   src/bindings/lua/lua_private.h
@@ -429,14 +365,6 @@ set(MC_SRC
 set(headers_to_install
   include/amok/bandwidth.h
   include/amok/peermanagement.h
-  include/gras.h
-  include/gras/emul.h
-  include/gras/messages.h
-  include/gras/module.h
-  include/gras/process.h
-  include/gras/timer.h
-  include/gras/transport.h
-  include/gras/virtu.h
   include/instr/instr.h
   include/msg/datatypes.h
   include/msg/msg.h
@@ -459,7 +387,6 @@ set(headers_to_install
   include/xbt/automaton.h
   include/xbt/config.h
   include/xbt/cunit.h
-  include/xbt/datadesc.h
   include/xbt/dict.h
   include/xbt/dynar.h
   include/xbt/ex.h
@@ -484,7 +411,6 @@ set(headers_to_install
   include/xbt/replay.h
   include/xbt/set.h
   include/xbt/setset.h
-  include/xbt/socket.h
   include/xbt/str.h
   include/xbt/strbuff.h
   include/xbt/swag.h
@@ -543,10 +469,7 @@ endif()
 
 ### Simgrid Lib sources
 set(simgrid_sources
-  ${AMOK_SRC}
   ${BINDINGS_SRC}
-  ${GRAS_COMMON_SRC}
-  ${GRAS_SG_SRC}
   ${GTNETS_USED}
   ${JEDULE_SRC}
   ${MSG_SRC}
@@ -581,14 +504,6 @@ if(WIN32)
     )
 endif()
 
-### Gras Lib sources
-set(gras_sources
-  ${AMOK_SRC}
-  ${GRAS_COMMON_SRC}
-  ${GRAS_RL_SRC}
-  ${XBT_SRC}
-  )
-
 if(${HAVE_LUA})
   set(simgrid_sources
     ${simgrid_sources}
@@ -605,7 +520,6 @@ set(DOC_SOURCES
   doc/amok_bw_sat.png
   doc/amok_bw_test.png
   doc/AS_hierarchy.png
-  doc/gras_comm.png
   doc/sg_thread_model.fig
   doc/simix.fig
   doc/surf_nutshell.fig
@@ -746,7 +660,6 @@ set(REF_GUIDE_SOURCES
   doc/ref_guide/doxygen/header.html
   doc/ref_guide/doxygen/main.doc
   doc/ref_guide/doxygen/module-amok.doc
-  doc/ref_guide/doxygen/module-gras.doc
   doc/ref_guide/doxygen/module-msg.doc
   doc/ref_guide/doxygen/module-sd.doc
   doc/ref_guide/doxygen/module-simix.doc
@@ -847,18 +760,6 @@ set(txt_files
 set(EXAMPLES_CMAKEFILES_TXT
   examples/amok/bandwidth/CMakeLists.txt
   examples/amok/saturate/CMakeLists.txt
-  examples/gras/all2all/CMakeLists.txt
-  examples/gras/chrono/CMakeLists.txt
-  examples/gras/console/CMakeLists.txt
-  examples/gras/mmrpc/CMakeLists.txt
-  examples/gras/mutual_exclusion/simple_token/CMakeLists.txt
-  examples/gras/ping/CMakeLists.txt
-  examples/gras/pmm/CMakeLists.txt
-  examples/gras/properties/CMakeLists.txt
-  examples/gras/rpc/CMakeLists.txt
-  examples/gras/spawn/CMakeLists.txt
-  examples/gras/synchro/CMakeLists.txt
-  examples/gras/timer/CMakeLists.txt
   examples/lua/CMakeLists.txt
   examples/msg/CMakeLists.txt
   examples/msg/actions/CMakeLists.txt
@@ -897,11 +798,6 @@ set(EXAMPLES_CMAKEFILES_TXT
 
 set(TESHSUITE_CMAKEFILES_TXT
   teshsuite/CMakeLists.txt
-  teshsuite/gras/CMakeLists.txt
-  teshsuite/gras/datadesc/CMakeLists.txt
-  teshsuite/gras/empty_main/CMakeLists.txt
-  teshsuite/gras/msg_handle/CMakeLists.txt
-  teshsuite/gras/small_sleep/CMakeLists.txt
   teshsuite/msg/CMakeLists.txt
   teshsuite/msg/trace/CMakeLists.txt
   teshsuite/simdag/CMakeLists.txt
@@ -922,7 +818,6 @@ set(TESHSUITE_CMAKEFILES_TXT
 set(TOOLS_CMAKEFILES_TXT
   tools/CMakeLists.txt
   tools/graphicator/CMakeLists.txt
-  tools/gras/CMakeLists.txt
   tools/tesh/CMakeLists.txt
   )
 
@@ -976,11 +871,8 @@ set(CMAKE_SOURCE_FILES
   buildtools/Cmake/Scripts/update_tesh.pl
   buildtools/Cmake/Supernovae.cmake
   buildtools/Cmake/UnitTesting.cmake
-  buildtools/Cmake/src/gras_config.h.in
   buildtools/Cmake/src/simgrid.nsi.in
   buildtools/Cmake/test_prog/prog_AC_CHECK_MCSC.c
-  buildtools/Cmake/test_prog/prog_GRAS_ARCH.c
-  buildtools/Cmake/test_prog/prog_GRAS_CHECK_STRUCT_COMPACTION.c
   buildtools/Cmake/test_prog/prog_getline.c
   buildtools/Cmake/test_prog/prog_max_size.c
   buildtools/Cmake/test_prog/prog_mutex_timedlock.c
@@ -1036,7 +928,6 @@ set(PLATFORMS_EXAMPLES
   )
 
 set(generated_src_files
-  ${CMAKE_HOME_DIRECTORY}/src/xbt/datadesc/ddt_parse.yy.c
   src/xbt/automaton/automaton_lexer.yy.c
   src/xbt/automaton/parserPromela.tab.cacc
   src/xbt/automaton/parserPromela.tab.hacc
index 5e3e0c2..99baeb9 100644 (file)
@@ -70,11 +70,8 @@ add_custom_target(simgrid_update_xml ALL
   COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_HOME_DIRECTORY}/tools/simgrid_update_xml.pl ${CMAKE_BINARY_DIR}/bin/simgrid_update_xml
   )
 
-install(PROGRAMS ${CMAKE_BINARY_DIR}/bin/gras_stub_generator
-  DESTINATION $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/bin/)
-
 # libraries
-install(TARGETS simgrid gras
+install(TARGETS simgrid 
   DESTINATION $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/)
 
 if(enable_smpi)
@@ -135,7 +132,6 @@ endif()
 add_custom_target(uninstall
   COMMAND ${CMAKE_COMMAND} -E  remove_directory ${CMAKE_INSTALL_PREFIX}/doc/simgrid
   COMMAND ${CMAKE_COMMAND} -E  echo "uninstall doc ok"
-  COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/lib/libgras*
   COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/lib/libsimgrid*
   COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/lib/libsmpi*
   COMMAND ${CMAKE_COMMAND} -E   remove -f ${CMAKE_INSTALL_PREFIX}/lib/lua/5.1/simgrid*
@@ -147,11 +143,9 @@ add_custom_target(uninstall
   COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/bin/tesh
   COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/bin/simgrid-colorizer
   COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/bin/simgrid_update_xml
-  COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/bin/gras_stub_generator
   COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/bin/graphicator
   COMMAND ${CMAKE_COMMAND} -E  echo "uninstall bin ok"
   COMMAND ${CMAKE_COMMAND} -E  remove_directory ${CMAKE_INSTALL_PREFIX}/include/amok
-  COMMAND ${CMAKE_COMMAND} -E  remove_directory ${CMAKE_INSTALL_PREFIX}/include/gras
   COMMAND ${CMAKE_COMMAND} -E  remove_directory ${CMAKE_INSTALL_PREFIX}/include/instr
   COMMAND ${CMAKE_COMMAND} -E  remove_directory ${CMAKE_INSTALL_PREFIX}/include/msg
   COMMAND ${CMAKE_COMMAND} -E  remove_directory ${CMAKE_INSTALL_PREFIX}/include/simdag
@@ -162,7 +156,6 @@ add_custom_target(uninstall
   COMMAND ${CMAKE_COMMAND} -E  remove_directory ${CMAKE_INSTALL_PREFIX}/include/mc
   COMMAND ${CMAKE_COMMAND} -E  remove_directory ${CMAKE_INSTALL_PREFIX}/include/simgrid
   COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/include/simgrid_config.h
-  COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/include/gras.h
   COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/include/xbt.h
   COMMAND ${CMAKE_COMMAND} -E  echo "uninstall include ok"
   COMMAND ${CMAKE_COMMAND} -E  remove -f ${CMAKE_INSTALL_PREFIX}/share/man/man1/simgrid_update_xml.1
@@ -191,9 +184,6 @@ set(source_to_pack
   ${source_of_generated_headers}
   ${AMOK_SRC}
   ${BINDINGS_SRC}
-  ${GRAS_COMMON_SRC}
-  ${GRAS_RL_SRC}
-  ${GRAS_SG_SRC}
   ${GTNETS_SRC}
   ${JEDULE_SRC}
   ${LUA_SRC}
@@ -388,7 +378,6 @@ add_custom_target(maintainer-clean
   )
 
 add_custom_target(supernovae-clean
-  COMMAND ${CMAKE_COMMAND} -E remove -f src/supernovae_gras.c
   COMMAND ${CMAKE_COMMAND} -E remove -f src/supernovae_sg.c
   COMMAND ${CMAKE_COMMAND} -E remove -f src/supernovae_smpi.c
   WORKING_DIRECTORY "${CMAKE_HOME_DIRECTORY}"
index be667ea..985d093 100644 (file)
@@ -86,12 +86,10 @@ if(enable_maintainer_mode AND NOT WIN32)
       ${CMAKE_HOME_DIRECTORY}/src/simdag/dax_dtd.h
       ${CMAKE_HOME_DIRECTORY}/src/surf/simgrid_dtd.c
       ${CMAKE_HOME_DIRECTORY}/src/xbt/graphxml.c
-      ${CMAKE_HOME_DIRECTORY}/src/xbt/datadesc/ddt_parse.yy.c
       ${CMAKE_HOME_DIRECTORY}/src/simdag/dax_dtd.c
 
       DEPENDS  ${CMAKE_HOME_DIRECTORY}/src/surf/simgrid.dtd
       ${CMAKE_HOME_DIRECTORY}/src/xbt/graphxml.dtd
-      ${CMAKE_HOME_DIRECTORY}/src/xbt/datadesc/ddt_parse.yy.l
       ${CMAKE_HOME_DIRECTORY}/src/simdag/dax.dtd
 
       #${CMAKE_HOME_DIRECTORY}/src/surf/simgrid_dtd.l: ${CMAKE_HOME_DIRECTORY}/src/surf/simgrid.dtd
@@ -151,10 +149,6 @@ if(enable_maintainer_mode AND NOT WIN32)
       COMMAND ${SED_EXE} -i ${string11} src/xbt/graphxml.c
       COMMAND ${CMAKE_COMMAND} -E echo "xbt/graphxml.c"
 
-      # src/xbt/datadesc/ddt_parse.yy.c: src/xbt/datadesc/ddt_parse.yy.l
-      COMMAND ${FLEX_EXE} -o src/xbt/datadesc/ddt_parse.yy.c -Pxbt_ddt_parse_ --noline src/xbt/datadesc/ddt_parse.yy.l
-      COMMAND ${CMAKE_COMMAND} -E echo "xbt/datadesc/ddt_parse.yy.c"
-
       #simdag/dax_dtd.c: simdag/dax_dtd.l
       COMMAND ${CMAKE_COMMAND} -E remove -f ${CMAKE_HOME_DIRECTORY}/src/simdag/dax_dtd.c
       COMMAND ${SED_EXE} -i ${string12} src/simdag/dax_dtd.l
@@ -173,7 +167,6 @@ if(enable_maintainer_mode AND NOT WIN32)
       ${CMAKE_HOME_DIRECTORY}/src/simdag/dax_dtd.h
       ${CMAKE_HOME_DIRECTORY}/src/surf/simgrid_dtd.c
       ${CMAKE_HOME_DIRECTORY}/src/xbt/graphxml.c
-      ${CMAKE_HOME_DIRECTORY}/src/xbt/datadesc/ddt_parse.yy.c
       ${CMAKE_HOME_DIRECTORY}/src/simdag/dax_dtd.c
       )
 
index cde9e16..8c1c4f7 100644 (file)
@@ -7,22 +7,15 @@ add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/lua)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/msg)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/xbt)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/gras)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/tools)
 ##################################################################
 
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/tools/gras)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/tools/tesh)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/tools/graphicator/)
 
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/testsuite/xbt)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/testsuite/surf)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/xbt)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/gras/datadesc)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/gras/msg_handle)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/gras/empty_main)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/gras/small_sleep)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/gras/numerous_rpc)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/simdag)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/simdag/network)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/simdag/network/p2p)
@@ -38,18 +31,6 @@ add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/smpi/mpich-test/pt2pt)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/msg)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/teshsuite/msg/trace)
 
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/ping)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/rpc)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/spawn)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/timer)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/chrono)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/mutual_exclusion/simple_token)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/mmrpc)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/all2all)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/pmm)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/synchro)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/properties)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/gras/console)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/msg/properties)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/msg/actions)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/msg/migration)
@@ -74,9 +55,6 @@ add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/msg/mc)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/msg/gtnets)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/msg/ns3)
 
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/amok/bandwidth)
-add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/amok/saturate)
-
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/simdag)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/simdag/dax)
 add_subdirectory(${CMAKE_HOME_DIRECTORY}/examples/simdag/goal)
index b848846..92ebff7 100644 (file)
@@ -11,9 +11,6 @@ include(${CMAKE_HOME_DIRECTORY}/buildtools/Cmake/Supernovae.cmake)
 add_library(simgrid SHARED ${simgrid_sources})
 set_target_properties(simgrid PROPERTIES VERSION ${libsimgrid_version})
 
-add_library(gras SHARED ${gras_sources})
-set_target_properties(gras PROPERTIES VERSION ${libgras_version})
-
 if(enable_lib_static)
   add_library(simgrid_static STATIC ${simgrid_sources})
 endif()
@@ -26,7 +23,6 @@ if(enable_smpi)
   endif()
 endif()
 
-add_dependencies(gras maintainer_files)
 add_dependencies(simgrid maintainer_files)
 
 # if supernovaeing, we need some depends to make sure that the source gets generated
@@ -35,7 +31,6 @@ if (enable_supernovae)
   if(enable_lib_static)
     add_dependencies(simgrid_static ${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_sg.c)
   endif()
-  add_dependencies(gras ${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_gras.c)
 
   if(enable_smpi)
     add_dependencies(smpi ${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_smpi.c)
@@ -45,25 +40,6 @@ if (enable_supernovae)
   endif()
 endif()
 
-# Compute the dependencies of GRAS
-##################################
-set(GRAS_DEP "-lm -pthread")
-
-if(HAVE_POSIX_GETTIME)
-  SET(GRAS_DEP "${GRAS_DEP} -lrt")
-endif()
-
-# the following is probably unneed since it kills the previous
-# GRAS_DEP (and is thus probably invalid).
-# My guess is that pthread is never true [Mt]
-# FIXME: KILLME if we get a working windows with that?
-if(with_context MATCHES windows)
-  if(pthread)
-    SET(GRAS_DEP "msg")
-  endif()
-endif()
-target_link_libraries(gras     ${GRAS_DEP})
-
 # Compute the dependencies of SimGrid
 #####################################
 set(SIMGRID_DEP "-lm -lpcre")
index 2af50ae..861388f 100644 (file)
@@ -11,9 +11,6 @@ if(enable_print_message)
   message("need_vasprintf ..............: ${simgrid_need_vasprintf}")
   message("PREFER_PORTABLE_SNPRINTF ....: ${PREFER_PORTABLE_SNPRINTF}")
   message("HAVE_VA_COPY ................: ${HAVE_VA_COPY}")
-  message("GRAS_BIGENDIAN ..............: ${GRAS_BIGENDIAN}")
-  message("GRAS_ARCH val ...............: ${val_big}")
-  message("GRAS_ARCH_32_BITS ...........: ${GRAS_ARCH_32_BITS}")
   message("PRINTF_NULL_WORKING .........: ${PRINTF_NULL_WORKING}")
   message("")
   message("\#define pth_skaddr_makecontext(skaddr,sksize) (${makecontext_addr})")
@@ -74,7 +71,7 @@ if(enable_print_message)
   message("")
 endif()
 
-message("\nConfiguration of package `simgrid' on arch (=${GRAS_THISARCH}):")
+message("\nConfiguration of package `simgrid':")
 message("        BUILDNAME ...........: ${BUILDNAME}")
 message("        SITE ................: ${SITE}")
 message("        Release .............: simgrid-${release_version}")
@@ -116,7 +113,6 @@ message("        Graphviz mode .......: ${HAVE_GRAPHVIZ}")
 message("        Mallocators .........: ${enable_mallocators}")
 message("")
 message("        Simgrid dependencies : ${SIMGRID_DEP}")
-message("        Gras dependencies ...: ${GRAS_DEP}")
 message("        Smpi dependencies ...: ${SMPI_DEP}")
 message("")
 message("        INSTALL_PREFIX ......: ${CMAKE_INSTALL_PREFIX}")
index ec68d3c..f56228a 100644 (file)
@@ -6,16 +6,10 @@
 set(simgrid_fragile_sources
   src/simdag/sd_daxloader.c
   src/surf/surfxml_parse.c
-  src/xbt/datadesc/ddt_parse.yy.c
   src/xbt/graphxml_parse.c
   src/xbt/mmalloc/mm.c
   ${GTNETS_USED}
   )
-set(gras_fragile_sources
-  src/xbt/datadesc/ddt_parse.yy.c
-  src/xbt/graphxml_parse.c
-  src/xbt/mmalloc/mm.c
-  )
 
 #####################################################
 ### END OF CONFIGURATION, NO NEED TO READ FURTHER ###
@@ -27,8 +21,6 @@ if (enable_supernovae) # I need supernovae
   # supernovae files are generated. I promise
   set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_sg.c
     PROPERTIES GENERATED true)
-  set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_gras.c
-    PROPERTIES GENERATED true)
   set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_smpi.c
     PROPERTIES GENERATED true)
 
@@ -40,13 +32,6 @@ if (enable_supernovae) # I need supernovae
     COMMENT "Generating supernovae_sg.c"
     )
 
-  ADD_CUSTOM_COMMAND(
-    OUTPUT   ${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_gras.c
-    DEPENDS  ${CMAKE_HOME_DIRECTORY}/src/mk_supernovae.pl ${gras_sources}
-    COMMAND  perl ${CMAKE_HOME_DIRECTORY}/src/mk_supernovae.pl --out=${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_gras.c '--fragile=${gras_fragile_sources}'    '${gras_sources}'
-    WORKING_DIRECTORY ${CMAKE_HOME_DIRECTORY}
-    COMMENT "Generating supernovae_gras.c"
-    )
 
   ADD_CUSTOM_COMMAND(
     OUTPUT   ${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_smpi.c
@@ -61,10 +46,6 @@ if (enable_supernovae) # I need supernovae
     ${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_sg.c
     ${simgrid_fragile_sources})
 
-  set(gras_sources
-    ${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_gras.c
-    ${gras_fragile_sources})
-
   set(SMPI_SRC
     ${CMAKE_CURRENT_BINARY_DIR}/src/supernovae_smpi.c)
 
index 746596e..62fb68a 100644 (file)
@@ -58,9 +58,9 @@ add_executable(testall ${TEST_UNITS})
 
 ### Add definitions for compile
 if(NOT WIN32)
-  target_link_libraries(testall gras m)
+  target_link_libraries(testall simgrid m)
 else()
-  target_link_libraries(testall gras)
+  target_link_libraries(testall simgrid)
 endif()
 
 add_dependencies(testall ${TEST_UNITS})
\ No newline at end of file
index bb18c71..ff66d55 100644 (file)
@@ -47,14 +47,12 @@ Section "Libraries and Headers" LibSection
        # install lib\r
        CreateDirectory $INSTDIR\lib\r
        setOutPath $INSTDIR\lib\r
-       file lib\libgras.dll\r
        file lib\libsimgrid.dll\r
        file lib\libsimgrid.def\r
        \r
        #install headers\r
        CreateDirectory  $INSTDIR\include\r
        setOutPath $INSTDIR\include\r
-       file @CMAKE_HOME_DIRECTORY@\include\gras.h \r
        file @CMAKE_HOME_DIRECTORY@\include\xbt.h\r
        file include\simgrid_config.h\r
        \r
@@ -95,7 +93,6 @@ Section "Libraries and Headers" LibSection
        file @CMAKE_HOME_DIRECTORY@\include\xbt\parmap.h\r
        file @CMAKE_HOME_DIRECTORY@\include\xbt\automaton.h\r
        file @CMAKE_HOME_DIRECTORY@\include\xbt\automatonparse_promela.h\r
-       file @CMAKE_HOME_DIRECTORY@\include\xbt\datadesc.h\r
        file @CMAKE_HOME_DIRECTORY@\include\xbt\socket.h\r
        file @CMAKE_HOME_DIRECTORY@\include\xbt\file_stat.h\r
     file @CMAKE_HOME_DIRECTORY@\include\xbt\xbt_os_thread.h\r
@@ -131,21 +128,6 @@ Section "Libraries and Headers" LibSection
        file @CMAKE_HOME_DIRECTORY@\include\surf\simgrid_dtd.h\r
        file @CMAKE_HOME_DIRECTORY@\include\surf\surf_routing.h\r
        \r
-       CreateDirectory  $INSTDIR\include\gras\r
-       setOutPath $INSTDIR\include\gras\r
-       file @CMAKE_HOME_DIRECTORY@\include\gras\transport.h\r
-       file @CMAKE_HOME_DIRECTORY@\include\gras\virtu.h\r
-       file @CMAKE_HOME_DIRECTORY@\include\gras\emul.h\r
-       file @CMAKE_HOME_DIRECTORY@\include\gras\process.h\r
-       file @CMAKE_HOME_DIRECTORY@\include\gras\module.h\r
-       file @CMAKE_HOME_DIRECTORY@\include\gras\messages.h\r
-       file @CMAKE_HOME_DIRECTORY@\include\gras\timer.h\r
-       \r
-       CreateDirectory  $INSTDIR\include\amok\r
-       setOutPath $INSTDIR\include\amok\r
-       file @CMAKE_HOME_DIRECTORY@\include\amok\peermanagement.h\r
-       file @CMAKE_HOME_DIRECTORY@\include\amok\bandwidth.h\r
-       \r
        CreateDirectory  $INSTDIR\include\instr\r
        setOutPath $INSTDIR\include\instr\r
        file @CMAKE_HOME_DIRECTORY@\include\instr\instr.h\r
@@ -256,14 +238,14 @@ section
 # default section end\r
 sectionEnd\r
 \r
-LangString DESC_LibSection             ${LANG_ENGLISH} "Install Simgrid and gras libraries with associated headers."\r
+LangString DESC_LibSection             ${LANG_ENGLISH} "Install Simgrid libraries with associated headers."\r
 LangString DESC_BinSection             ${LANG_ENGLISH} "Install some useful tools for Simgrid."\r
 LangString DESC_DocSection             ${LANG_ENGLISH} "Generated (doxygen) documentation."\r
 LangString DESC_ExamplesSection ${LANG_ENGLISH} "Simgrid's HelloWorld example and some classical platforms."\r
 LangString DESC_PCRESection    ${LANG_ENGLISH} "Install the PCRE and PCREPOSIX libraries for SimGrid."\r
 LangString DESC_JAVASection    ${LANG_ENGLISH} "Install the Java binding and examples."\r
 \r
-LangString DESC_LibSection             ${LANG_FRENCH}  "Installer les librairies Simgrid et Gras et leurs EntĂȘtes."\r
+LangString DESC_LibSection             ${LANG_FRENCH}  "Installer les librairies Simgrid et leurs EntĂȘtes."\r
 LangString DESC_BinSection             ${LANG_FRENCH}  "Installer les outils optionnels."\r
 LangString DESC_DocSection             ${LANG_FRENCH}  "Installer la documentation."\r
 LangString DESC_ExamplesSection ${LANG_FRENCH}         "Installer un exemple 'HelloWorld' et des fichiers de plate-formes types."\r
@@ -287,7 +269,6 @@ section "Uninstall"
        delete $INSTDIR\uninstaller@BIN_EXE@\r
 \r
        # delete installed libs\r
-       delete $INSTDIR\lib\libgras.dll\r
        delete $INSTDIR\lib\libsimgrid.dll\r
        delete $INSTDIR\lib\libsimgrid.def\r
 \r
@@ -302,7 +283,6 @@ section "Uninstall"
        delete $INSTDIR\bin\tesh\r
        \r
        # delete installed headers\r
-       delete $INSTDIR\include\gras.h \r
        delete $INSTDIR\include\xbt.h\r
        delete $INSTDIR\include\simgrid_config.h\r
        delete $INSTDIR\include\xbt\misc.h\r
@@ -358,16 +338,6 @@ section "Uninstall"
        delete $INSTDIR\include\surf\surfxml_parse.h\r
        delete $INSTDIR\include\surf\simgrid_dtd.h\r
        delete $INSTDIR\include\surf\surf_routing.h\r
-       delete $INSTDIR\include\gras\datadesc.h\r
-       delete $INSTDIR\include\gras\transport.h\r
-       delete $INSTDIR\include\gras\virtu.h\r
-       delete $INSTDIR\include\gras\emul.h\r
-       delete $INSTDIR\include\gras\process.h\r
-       delete $INSTDIR\include\gras\module.h\r
-       delete $INSTDIR\include\gras\messages.h\r
-       delete $INSTDIR\include\gras\timer.h\r
-       delete $INSTDIR\include\amok\peermanagement.h\r
-       delete $INSTDIR\include\amok\bandwidth.h\r
        delete $INSTDIR\include\instr\instr.h\r
                \r
        # delete EXTRA FILES\r
@@ -382,8 +352,6 @@ section "Uninstall"
        RMDir  "$INSTDIR\lib"\r
        RMDir  "$INSTDIR\include\simix"\r
        RMDir  "$INSTDIR\include\instr"\r
-       RMDir  "$INSTDIR\include\amok"\r
-       RMDir  "$INSTDIR\include\gras"\r
        RMDir  "$INSTDIR\include\surf"\r
        RMDir  "$INSTDIR\include\smpi"\r
        RMDir  "$INSTDIR\include\simdag"\r
diff --git a/buildtools/Cmake/test_prog/prog_GRAS_ARCH.c b/buildtools/Cmake/test_prog/prog_GRAS_ARCH.c
deleted file mode 100644 (file)
index 00b6dff..0000000
+++ /dev/null
@@ -1,80 +0,0 @@
-//This programme check size of datatypes 
-
-/* Copyright (c) 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
- * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <sys/types.h>
-#include <stdio.h>
-
-int main(void)
-{
-
-  int c = sizeof(char);
-  int si = sizeof(short int);
-  int i = sizeof(int);
-  int li = sizeof(long int);
-  int lli = sizeof(long long int);
-  int f = sizeof(float);
-  int v = sizeof(void *);
-  int vv = sizeof(void (*)(void));
-  /*printf("char : %d\n",c);
-     printf("short int : %d\n",si);
-     printf("int : %d\n",i);
-     printf("long int : %d\n",li);
-     printf("long long int : %d\n",lli);
-     printf("float : %d\n",f);
-     printf("void * : %d\n",v);
-     printf("void (*) (void) : %d\n",vv); */
-
-  struct s0 {
-    char c0;
-    char i0;
-  };
-  struct s1 {
-    char c1;
-    short int i1;
-  };
-  struct s2 {
-    char c2;
-    int i2;
-  };
-  struct s3 {
-    char c3;
-    long int i3;
-  };
-  struct s4 {
-    char c4;
-    long long int i4;
-  };
-  struct s5 {
-    char c5;
-    double i5;
-  };
-  struct s6 {
-    char c6;
-    void *i6;
-  };
-  int res0 = sizeof(struct s0) - sizeof(char);
-  int res1 = sizeof(struct s1) - sizeof(short int);
-  int res2 = sizeof(struct s2) - sizeof(int);
-  int res3 = sizeof(struct s3) - sizeof(long int);
-  int res4 = sizeof(struct s4) - sizeof(long long int);
-  int res5 = sizeof(struct s5) - sizeof(double);
-  int res6 = sizeof(struct s6) - sizeof(void *);
-  /*printf("struct-char : %d\n",res0);
-     printf("struct-short int : %d\n",res1);      
-     printf("struct-int : %d\n",res2);    
-     printf("struct-long int : %d\n",res3);       
-     printf("struct-long long int : %d\n",res4);  
-     printf("struct-double : %d\n",res5); 
-     printf("struct-void * : %d\n",res6); */
-
-  printf
-      ("_C:%d/%d:_I:%d/%d:%d/%d:%d/%d:%d/%d:_P:%d/%d:%d/%d:_D:4/%d:8/%d:",
-       c, res0, si, res1, i, res2, li, res3, lli, res4, v, res6, vv, res6,
-       f, res5);
-  return 1;
-}
diff --git a/buildtools/Cmake/test_prog/prog_GRAS_CHECK_STRUCT_COMPACTION.c b/buildtools/Cmake/test_prog/prog_GRAS_CHECK_STRUCT_COMPACTION.c
deleted file mode 100644 (file)
index 865eeaf..0000000
+++ /dev/null
@@ -1,72 +0,0 @@
-/* Copyright (c) 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
- * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <sys/types.h>
-#include <stddef.h>             /* offsetof() */
-#include <stdio.h>
-
-int main(void)
-{
-
-  struct s0 {
-    char c0;
-    double d0;
-  };
-  struct s1 {
-    double d1;
-    int i1;
-    char c1;
-  };
-  struct s2 {
-    double d2;
-    int i2;
-    char c2[6];
-  };
-  struct s3 {
-    double d3;
-    int a3;
-    int b3;
-  };
-
-  int gras_struct_packed;
-  int gras_struct_compact;
-  int gras_array_straddle_struct;
-  int gras_compact_struct;
-
-  if (sizeof(struct s0) == sizeof(double) + sizeof(char)) {
-    gras_struct_packed = 1;
-  } else {
-    gras_struct_packed = 0;
-  }
-  if (offsetof(struct s1, c1) == sizeof(double) + sizeof(int)) {
-    gras_struct_compact = 1;
-  } else {
-    gras_struct_compact = 0;
-  }
-  if (offsetof(struct s2, c2) == sizeof(double) + sizeof(int)) {
-    gras_array_straddle_struct = 1;
-  } else {
-    gras_array_straddle_struct = 0;
-  }
-  if (offsetof(struct s3, b3) == sizeof(double) + sizeof(int)) {
-    gras_compact_struct = 1;
-  } else {
-    gras_compact_struct = 0;
-  }
-
-
-  if (gras_struct_packed == 0 && gras_struct_compact == 1)
-    printf("GRAS_STRUCT_COMPACT ");
-
-  if (gras_array_straddle_struct == 1)
-    printf("GRAS_ARRAY_STRADDLE_STRUCT ");
-
-  if (gras_compact_struct == 1)
-    printf("GRAS_COMPACT_STRUCT ");
-
-  return 1;
-
-}
diff --git a/doc/gras_comm.png b/doc/gras_comm.png
deleted file mode 100644 (file)
index 00d54a1..0000000
Binary files a/doc/gras_comm.png and /dev/null differ
diff --git a/doc/gtut-files/01-bones.c b/doc/gtut-files/01-bones.c
deleted file mode 100644 (file)
index 97fea93..0000000
+++ /dev/null
@@ -1,27 +0,0 @@
-/* Copyright (c) 2006, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <gras.h>
-
-int client(int argc, char *argv[])
-{
-  gras_init(&argc, argv);
-
-  /* Your own code for the client process */
-
-  gras_exit();
-  return 0;
-}
-
-int server(int argc, char *argv[])
-{
-  gras_init(&argc, argv);
-
-  /* Your own code for the server process */
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/01-bones.output b/doc/gtut-files/01-bones.output
deleted file mode 100644 (file)
index 1257295..0000000
+++ /dev/null
@@ -1,9 +0,0 @@
-$ ./test_client
-[arthur:client:(28729) 0.000011] [gras/INFO] Exiting GRAS
-$ ./test_server
-[arthur:server:(28733) 0.000012] [gras/INFO] Exiting GRAS
-$
-$ ./test_simulator platform.xml test.xml
-[Jacquelin:server:(1) 0.000000] [gras/INFO] Exiting GRAS
-[Boivin:client:(2) 0.000000] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/02-simple.c b/doc/gtut-files/02-simple.c
deleted file mode 100644 (file)
index 269414c..0000000
+++ /dev/null
@@ -1,51 +0,0 @@
-/* Copyright (c) 2006, 2007, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <stdio.h>
-#include <gras.h>
-
-int server(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toclient;       /* socket used to write to the client */
-
-  gras_init(&argc, argv);
-
-  gras_msgtype_declare("hello", NULL);
-  mysock = gras_socket_server(12345);
-
-  gras_msg_wait(60, "hello", &toclient, NULL /* no payload */ );
-
-  fprintf(stderr, "Cool, we received the message from %s:%d.\n",
-          gras_socket_peer_name(toclient),
-          gras_socket_peer_port(toclient));
-
-  gras_exit();
-  return 0;
-}
-
-int client(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toserver;       /* socket used to write to the server */
-
-  gras_init(&argc, argv);
-
-  gras_msgtype_declare("hello", NULL);
-  mysock = gras_socket_server_range(1024, 10000, 0, 0);
-
-  fprintf(stderr, "Client ready; listening on %d\n",
-          gras_socket_my_port(mysock));
-
-  gras_os_sleep(1.5);           /* sleep 1 second and half */
-  toserver = gras_socket_client("Jacquelin", 12345);
-
-  gras_msg_send(toserver, "hello", NULL);
-  fprintf(stderr, "That's it, we sent the data to the server\n");
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/02-simple.output b/doc/gtut-files/02-simple.output
deleted file mode 100644 (file)
index 7b961ea..0000000
+++ /dev/null
@@ -1,7 +0,0 @@
-$ ./test_simulator platform.xml test.xml
-Client ready; listening on 1024
-That's it, we sent the data to the server
-[Boivin:client:(2) 0.000000] [gras/INFO] Exiting GRAS
-Cool, we received the message from Boivin:1024.
-[Jacquelin:server:(1) 0.000000] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/03-args.c b/doc/gtut-files/03-args.c
deleted file mode 100644 (file)
index 06d6f1a..0000000
+++ /dev/null
@@ -1,52 +0,0 @@
-/* Copyright (c) 2006, 2007, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <stdio.h>
-#include <gras.h>
-
-int server(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toclient;       /* socket used to write to the client */
-
-  gras_init(&argc, argv);
-
-  gras_msgtype_declare("hello", NULL);
-  mysock = gras_socket_server(atoi(argv[1]));
-
-  gras_msg_wait(60, "hello", &toclient, NULL /* no payload */ );
-
-  fprintf(stderr, "Cool, we received the message from %s:%d.\n",
-          gras_socket_peer_name(toclient),
-          gras_socket_peer_port(toclient));
-
-  gras_exit();
-  return 0;
-}
-
-int client(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toserver;       /* socket used to write to the server */
-
-  gras_init(&argc, argv);
-
-  gras_msgtype_declare("hello", NULL);
-  mysock = gras_socket_server_range(1024, 10000, 0, 0);
-
-  fprintf(stderr, "Client ready; listening on %d\n",
-          gras_socket_my_port(mysock));
-
-  gras_os_sleep(1.5);           /* sleep 1 second and half */
-  toserver = gras_socket_client(argv[1], atoi(argv[2]));
-
-  gras_msg_send(toserver, "hello", NULL);
-  fprintf(stderr, "That's it, we sent the data to the server on %s\n",
-          gras_socket_peer_name(toserver));
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/03-args.output b/doc/gtut-files/03-args.output
deleted file mode 100644 (file)
index 498ea45..0000000
+++ /dev/null
@@ -1,14 +0,0 @@
-$ ./test_server 12345 & ./test_client 127.0.0.1 12345
-Client ready; listening on 1024
-That's it, we sent the data to the server on 127.0.0.1
-[arthur:client:(27443) 0.000018] [gras/INFO] Exiting GRAS
-Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27441) 0.000012] [gras/INFO] Exiting GRAS
-$
-$ ./test_simulator platform.xml test.xml
-Client ready; listening on 1024
-That's it, we sent the data to the server on Jacquelin
-[Boivin:client:(2) 0.000000] [gras/INFO] Exiting GRAS
-Cool, we received the message from Boivin:1024.
-[Jacquelin:server:(1) 0.000000] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/03-args.xml b/doc/gtut-files/03-args.xml
deleted file mode 100644 (file)
index b8ad263..0000000
+++ /dev/null
@@ -1,12 +0,0 @@
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
-<platform version="3">
-  <process host="Jacquelin" function="server">
-    <argument value="12345"/>
-  </process>
-  <process host="Boivin" function="client">
-    <argument value="Jacquelin"/>
-    <argument value="12345"/>
-  </process>
-</platform>
-
diff --git a/doc/gtut-files/04-callback.c b/doc/gtut-files/04-callback.c
deleted file mode 100644 (file)
index 1e4c45f..0000000
+++ /dev/null
@@ -1,58 +0,0 @@
-/* Copyright (c) 2006, 2007, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <stdio.h>
-#include <gras.h>
-
-int server_hello_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  gras_socket_t client = gras_msg_cb_ctx_from(ctx);
-
-  fprintf(stderr, "Cool, we received the message from %s:%d.\n",
-          gras_socket_peer_name(client), gras_socket_peer_port(client));
-
-  return 0;
-}                               /* end_of_callback */
-
-int server(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-
-  gras_init(&argc, argv);
-
-  gras_msgtype_declare("hello", NULL);
-  mysock = gras_socket_server(atoi(argv[1]));
-
-  gras_cb_register("hello", &server_hello_cb);
-  gras_msg_handle(60);
-
-  gras_exit();
-  return 0;
-}
-
-int client(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toserver;       /* socket used to write to the server */
-
-  gras_init(&argc, argv);
-
-  gras_msgtype_declare("hello", NULL);
-  mysock = gras_socket_server_range(1024, 10000, 0, 0);
-
-  fprintf(stderr, "Client ready; listening on %d\n",
-          gras_socket_my_port(mysock));
-
-  gras_os_sleep(1.5);           /* sleep 1 second and half */
-  toserver = gras_socket_client(argv[1], atoi(argv[2]));
-
-  gras_msg_send(toserver, "hello", NULL);
-  fprintf(stderr, "That's it, we sent the data to the server on %s\n",
-          gras_socket_peer_name(toserver));
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/04-callback.output b/doc/gtut-files/04-callback.output
deleted file mode 100644 (file)
index 880ab77..0000000
+++ /dev/null
@@ -1,14 +0,0 @@
-$ ./test_server 23451 & ./test_client 127.0.0.1 23451
-Client ready; listening on 1024
-That's it, we sent the data to the server on 127.0.0.1
-[arthur:client:(27507) 0.000019] [gras/INFO] Exiting GRAS
-Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27505) 0.000013] [gras/INFO] Exiting GRAS
-$
-$ ./test_simulator platform.xml test.xml
-Client ready; listening on 1024
-That's it, we sent the data to the server on Jacquelin
-[Boivin:client:(2) 0.000000] [gras/INFO] Exiting GRAS
-Cool, we received the message from Boivin:1024.
-[Jacquelin:server:(1) 0.000000] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/05-globals.c b/doc/gtut-files/05-globals.c
deleted file mode 100644 (file)
index 4751176..0000000
+++ /dev/null
@@ -1,92 +0,0 @@
-/* Copyright (c) 2006, 2007, 2009, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <stdio.h>
-#include <gras.h>
-
-typedef struct {
-  int killed;
-} server_data_t;
-
-
-int server_kill_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  gras_socket_t client = gras_msg_cb_ctx_from(ctx);
-  server_data_t *globals = (server_data_t *) gras_userdata_get();
-
-  fprintf(stderr, "Argh, killed by %s:%d! Bye folks...\n",
-          gras_socket_peer_name(client), gras_socket_peer_port(client));
-
-  globals->killed = 1;
-
-  return 0;
-}                               /* end_of_kill_callback */
-
-int server_hello_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  gras_socket_t client = gras_msg_cb_ctx_from(ctx);
-
-  fprintf(stderr, "Cool, we received the message from %s:%d.\n",
-          gras_socket_peer_name(client), gras_socket_peer_port(client));
-
-  return 0;
-}                               /* end_of_hello_callback */
-
-int server(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  server_data_t *globals;
-
-  gras_init(&argc, argv);
-
-  globals = gras_userdata_new(server_data_t);
-  globals->killed = 0;
-
-  gras_msgtype_declare("hello", NULL);
-  gras_msgtype_declare("kill", NULL);
-  mysock = gras_socket_server(atoi(argv[1]));
-
-  gras_cb_register("hello", &server_hello_cb);
-  gras_cb_register("kill", &server_kill_cb);
-
-  while (!globals->killed) {
-    gras_msg_handle(-1);        /* blocking */
-  }
-
-  gras_exit();
-  return 0;
-}
-
-int client(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toserver;       /* socket used to write to the server */
-
-  gras_init(&argc, argv);
-
-  gras_msgtype_declare("hello", NULL);
-  gras_msgtype_declare("kill", NULL);
-  mysock = gras_socket_server_range(1024, 10000, 0, 0);
-
-  fprintf(stderr, "Client ready; listening on %d\n",
-          gras_socket_my_port(mysock));
-
-  gras_os_sleep(1.5);           /* sleep 1 second and half */
-  toserver = gras_socket_client(argv[1], atoi(argv[2]));
-
-  gras_msg_send(toserver, "hello", NULL);
-  fprintf(stderr,
-          "we sent the data to the server on %s. Let's do it again for fun\n",
-          gras_socket_peer_name(toserver));
-  gras_msg_send(toserver, "hello", NULL);
-
-  fprintf(stderr, "Ok. Enough. Have a rest, and then kill the server\n");
-  gras_os_sleep(5);             /* sleep 1 second and half */
-  gras_msg_send(toserver, "kill", NULL);
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/05-globals.output b/doc/gtut-files/05-globals.output
deleted file mode 100644 (file)
index 6ed9de7..0000000
+++ /dev/null
@@ -1,20 +0,0 @@
-$ ./test_server 12345 & ./test_client 127.0.0.1 12345
-Client ready; listening on 1024
-we sent the data to the server on 127.0.0.1. Let's do it again for fun
-Ok. Enough. Have a rest, and then kill the server
-Cool, we received the message from 127.0.0.1:1024.
-Cool, we received the message from 127.0.0.1:1024.
-[arthur:client:(28822) 0.000027] [gras/INFO] Exiting GRAS
-Argh, killed by 127.0.0.1:1024! Bye folks...
-[arthur:server:(28820) 0.000013] [gras/INFO] Exiting GRAS
-$
-$ ./test_simulator platform.xml test.xml
-Client ready; listening on 1024
-we sent the data to the server on Jacquelin. Let's do it again for fun
-Cool, we received the message from Boivin:1024.
-Ok. Enough. Have a rest, and then kill the server
-Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 0.000000] [gras/INFO] Exiting GRAS
-Argh, killed by Boivin:1024! Bye folks...
-[Jacquelin:server:(1) 0.000000] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/06-logs.c b/doc/gtut-files/06-logs.c
deleted file mode 100644 (file)
index 6de6602..0000000
+++ /dev/null
@@ -1,91 +0,0 @@
-/* Copyright (c) 2006, 2007, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <gras.h>
-
-XBT_LOG_NEW_DEFAULT_CATEGORY(test, "My little example");
-
-typedef struct {
-  int killed;
-} server_data_t;
-
-
-int server_kill_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  gras_socket_t client = gras_msg_cb_ctx_from(ctx);
-  server_data_t *globals = (server_data_t *) gras_userdata_get();
-
-  XBT_CRITICAL("Argh, killed by %s:%d! Bye folks...",
-            gras_socket_peer_name(client), gras_socket_peer_port(client));
-
-  globals->killed = 1;
-
-  return 0;
-}                               /* end_of_kill_callback */
-
-int server_hello_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  gras_socket_t client = gras_msg_cb_ctx_from(ctx);
-
-  XBT_INFO("Cool, we received the message from %s:%d.",
-        gras_socket_peer_name(client), gras_socket_peer_port(client));
-
-  return 0;
-}                               /* end_of_hello_callback */
-
-int server(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  server_data_t *globals;
-
-  gras_init(&argc, argv);
-
-  globals = gras_userdata_new(server_data_t *);
-  globals->killed = 0;
-
-  gras_msgtype_declare("hello", NULL);
-  gras_msgtype_declare("kill", NULL);
-  mysock = gras_socket_server(atoi(argv[1]));
-
-  gras_cb_register("hello", &server_hello_cb);
-  gras_cb_register("kill", &server_kill_cb);
-
-  while (!globals->killed) {
-    gras_msg_handle(-1);        /* blocking */
-  }
-
-  gras_exit();
-  return 0;
-}
-
-int client(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toserver;       /* socket used to write to the server */
-
-  gras_init(&argc, argv);
-
-  gras_msgtype_declare("hello", NULL);
-  gras_msgtype_declare("kill", NULL);
-  mysock = gras_socket_server_range(1024, 10000, 0, 0);
-
-  XBT_VERB("Client ready; listening on %d", gras_socket_my_port(mysock));
-
-  gras_os_sleep(1.5);           /* sleep 1 second and half */
-  toserver = gras_socket_client(argv[1], atoi(argv[2]));
-
-  gras_msg_send(toserver, "hello", NULL);
-  XBT_INFO("we sent the data to the server on %s. Let's do it again for fun",
-        gras_socket_peer_name(toserver));
-  gras_msg_send(toserver, "hello", NULL);
-
-  XBT_INFO("Ok. Enough. Have a rest, and then kill the server");
-  gras_os_sleep(5);             /* sleep 1 second and half */
-  gras_msg_send(toserver, "kill", NULL);
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/06-logs.output b/doc/gtut-files/06-logs.output
deleted file mode 100644 (file)
index 97565d1..0000000
+++ /dev/null
@@ -1,18 +0,0 @@
-$ ./test_server 12345 & ./test_client 127.0.0.1 12345
-[arthur:client:(27755) 0.000016] [test/INFO] we sent the data to the server on 127.0.0.1. Let's do it again for fun
-[arthur:client:(27755) 0.000148] [test/INFO] Ok. Enough. Have a rest, and then kill the server
-[arthur:client:(27755) 5.000415] [gras/INFO] Exiting GRAS
-[arthur:server:(27752) 0.000010] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27752) 0.000409] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27752) 5.001363] test.c:15: [test/CRITICAL] Argh, killed by 127.0.0.1:1024! Bye folks...
-[arthur:server:(27752) 5.001409] [gras/INFO] Exiting GRAS
-$
-$ ./test_simulator platform.xml test.xml
-[Boivin:client:(2) 0.000000] [test/INFO] we sent the data to the server on Jacquelin. Let's do it again for fun
-[Jacquelin:server:(1) 0.000000] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 0.000537] [test/INFO] Ok. Enough. Have a rest, and then kill the server
-[Jacquelin:server:(1) 0.000537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 5.001074] [gras/INFO] Exiting GRAS
-[Jacquelin:server:(1) 5.001074] test.c:15: [test/CRITICAL] Argh, killed by Boivin:1024! Bye folks...
-[Jacquelin:server:(1) 5.001074] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/06-logs.output.error b/doc/gtut-files/06-logs.output.error
deleted file mode 100644 (file)
index 3052af8..0000000
+++ /dev/null
@@ -1,6 +0,0 @@
-$ ./test_server 12345 --log=root.thres:error & ./test_client 127.0.0.1 12345 --log=root.thres:error
-[arthur:server:(27705) 0.000024] test.c:15: [test/CRITICAL] Argh, killed by 127.0.0.1:1024! Bye folks...
-$
-$ ./test_simulator platform.xml test.xml --log=root.thres:error
-[Jacquelin:server:(1) 0.000000] test.c:15: [test/CRITICAL] Argh, killed by Boivin:1024! Bye folks...
-$
diff --git a/doc/gtut-files/06-logs.output.fmt b/doc/gtut-files/06-logs.output.fmt
deleted file mode 100644 (file)
index 712efb2..0000000
+++ /dev/null
@@ -1,18 +0,0 @@
-$ ./test_server 12345 --log=test.fmt:%m%n & ./test_client 127.0.0.1 12345 --log=test.fmt:%m%n
-Cool, we received the message from 127.0.0.1:1024.
-nCool, we received the message from 127.0.0.1:1024.
-nArgh, killed by 127.0.0.1:1024! Bye folks...
-n[arthur:server:(27630) 0.000011] [gras/INFO] Exiting GRAS
-we sent the data to the server on 127.0.0.1. Let's do it again for fun
-Ok. Enough. Have a rest, and then kill the server
-[arthur:client:(27634) 0.000019] [gras/INFO] Exiting GRAS
-$
-$ ./test_simulator platform.xml test.xml --log=test.fmt:%m%n
-we sent the data to the server on Jacquelin. Let's do it again for fun
-Cool, we received the message from Boivin:1024.
-Ok. Enough. Have a rest, and then kill the server
-Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 0.000000] [gras/INFO] Exiting GRAS
-Argh, killed by Boivin:1024! Bye folks...
-[Jacquelin:server:(1) 0.000000] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/06-logs.output.fmt-bt b/doc/gtut-files/06-logs.output.fmt-bt
deleted file mode 100644 (file)
index cebafc3..0000000
+++ /dev/null
@@ -1,4 +0,0 @@
-$ ./test_server 12345 --log=test.fmt:"[%r] %m%n%b%n%n" & ./test_client 127.0.0.1 12345 --log=test.fmt:"[%r] %m%n%b%n%n"
-$
-$ ./test_simulator platform.xml test.xml --log=test.fmt:[%r]%m%n%b%n%n
-$
diff --git a/doc/gtut-files/06-logs.output.verbose b/doc/gtut-files/06-logs.output.verbose
deleted file mode 100644 (file)
index 42a8db8..0000000
+++ /dev/null
@@ -1,20 +0,0 @@
-$ ./test_server 12345 --log=test.thres:verbose & ./test_client 127.0.0.1 12345 --log=test.thres:verbose
-[arthur:client:(27681) 0.000012] test.c:65: [test/VERBOSE] Client ready; listening on 1024
-[arthur:client:(27681) 1.500865] [test/INFO] we sent the data to the server on 127.0.0.1. Let's do it again for fun
-[arthur:client:(27681) 1.500972] [test/INFO] Ok. Enough. Have a rest, and then kill the server
-[arthur:client:(27681) 6.501225] [gras/INFO] Exiting GRAS
-[arthur:server:(27677) 0.000015] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27677) 0.000144] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27677) 5.000244] test.c:15: [test/CRITICAL] Argh, killed by 127.0.0.1:1024! Bye folks...
-[arthur:server:(27677) 5.000296] [gras/INFO] Exiting GRAS
-$
-$ ./test_simulator platform.xml test.xml --log=test.thres:verbose
-[Boivin:client:(2) 0.000000] test.c:65: [test/VERBOSE] Client ready; listening on 1024
-[Boivin:client:(2) 1.500552] [test/INFO] we sent the data to the server on Jacquelin. Let's do it again for fun
-[Jacquelin:server:(1) 1.500552] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 1.501089] [test/INFO] Ok. Enough. Have a rest, and then kill the server
-[Jacquelin:server:(1) 1.501089] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 6.501626] [gras/INFO] Exiting GRAS
-[Jacquelin:server:(1) 6.501626] test.c:15: [test/CRITICAL] Argh, killed by Boivin:1024! Bye folks...
-[Jacquelin:server:(1) 6.501626] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/07-timers.c b/doc/gtut-files/07-timers.c
deleted file mode 100644 (file)
index 202f76c..0000000
+++ /dev/null
@@ -1,124 +0,0 @@
-/* Copyright (c) 2006, 2007, 2009, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <gras.h>
-
-XBT_LOG_NEW_DEFAULT_CATEGORY(test, "My little example");
-
-/* *********************** Server *********************** */
-typedef struct {
-  int killed;
-} server_data_t;
-
-int server_kill_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  gras_socket_t client = gras_msg_cb_ctx_from(ctx);
-  server_data_t *globals = (server_data_t *) gras_userdata_get();
-
-  XBT_CRITICAL("Argh, killed by %s:%d! Bye folks...",
-            gras_socket_peer_name(client), gras_socket_peer_port(client));
-
-  globals->killed = 1;
-
-  return 0;
-}                               /* end_of_kill_callback */
-
-int server_hello_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  gras_socket_t client = gras_msg_cb_ctx_from(ctx);
-
-  XBT_INFO("Cool, we received the message from %s:%d.",
-        gras_socket_peer_name(client), gras_socket_peer_port(client));
-
-  return 0;
-}                               /* end_of_hello_callback */
-
-int server(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  server_data_t *globals;
-
-  gras_init(&argc, argv);
-
-  globals = gras_userdata_new(server_data_t *);
-  globals->killed = 0;
-
-  gras_msgtype_declare("hello", NULL);
-  gras_msgtype_declare("kill", NULL);
-  mysock = gras_socket_server(atoi(argv[1]));
-
-  gras_cb_register("hello", &server_hello_cb);
-  gras_cb_register("kill", &server_kill_cb);
-
-  while (!globals->killed) {
-    gras_msg_handle(60);
-  }
-
-  gras_exit();
-  return 0;
-}
-
-/* *********************** Client *********************** */
-/* client_data */
-typedef struct {
-  gras_socket_t toserver;
-  int done;
-} client_data_t;
-
-
-void client_do_hello(void)
-{
-  client_data_t *globals = (client_data_t *) gras_userdata_get();
-
-  gras_msg_send(globals->toserver, "hello", NULL);
-  XBT_INFO("Hello sent to server");
-}                               /* end_of_client_do_hello */
-
-void client_do_stop(void)
-{
-  client_data_t *globals = (client_data_t *) gras_userdata_get();
-
-  gras_msg_send(globals->toserver, "kill", NULL);
-  XBT_INFO("Kill sent to server");
-
-  gras_timer_cancel_repeat(0.5, client_do_hello);
-
-  globals->done = 1;
-  XBT_INFO("Break the client's while loop");
-}                               /* end_of_client_do_stop */
-
-int client(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  client_data_t *globals;
-
-  gras_init(&argc, argv);
-
-  gras_msgtype_declare("hello", NULL);
-  gras_msgtype_declare("kill", NULL);
-  mysock = gras_socket_server_range(1024, 10000, 0, 0);
-
-  XBT_VERB("Client ready; listening on %d", gras_socket_my_port(mysock));
-
-  globals = gras_userdata_new(client_data_t *);
-  globals->done = 0;
-
-  gras_os_sleep(1.5);           /* sleep 1 second and half */
-  globals->toserver = gras_socket_client(argv[1], atoi(argv[2]));
-
-  XBT_INFO("Programming the repetitive action with a frequency of 0.5 sec");
-  gras_timer_repeat(0.5, client_do_hello);
-
-  XBT_INFO("Programming the delayed action in 5 secs");
-  gras_timer_delay(5, client_do_stop);
-
-  while (!globals->done) {
-    gras_msg_handle(60);
-  }
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/07-timers.output b/doc/gtut-files/07-timers.output
deleted file mode 100644 (file)
index d71db4c..0000000
+++ /dev/null
@@ -1,56 +0,0 @@
-$ ./test_server 12345 & ./test_client 127.0.0.1 12345
-[arthur:client:(27825) 0.000016] [test/INFO] Programming the repetitive action with a frequency of 0.5 sec
-[arthur:client:(27825) 0.000125] [test/INFO] Programming the delayed action in 5 secs
-[arthur:client:(27825) 0.500685] [test/INFO] Hello sent to server
-[arthur:client:(27825) 1.000855] [test/INFO] Hello sent to server
-[arthur:client:(27825) 1.501094] [test/INFO] Hello sent to server
-[arthur:client:(27825) 2.001261] [test/INFO] Hello sent to server
-[arthur:client:(27825) 2.501446] [test/INFO] Hello sent to server
-[arthur:client:(27825) 3.001591] [test/INFO] Hello sent to server
-[arthur:client:(27825) 3.501798] [test/INFO] Hello sent to server
-[arthur:client:(27825) 4.002111] [test/INFO] Hello sent to server
-[arthur:client:(27825) 4.502264] [test/INFO] Hello sent to server
-[arthur:client:(27825) 5.000513] [test/INFO] Kill sent to server
-[arthur:client:(27825) 5.000562] [test/INFO] Break the client's while loop
-[arthur:client:(27825) 5.000594] [gras/INFO] Exiting GRAS
-[arthur:server:(27821) 0.000014] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27821) 0.500134] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27821) 1.000349] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27821) 1.500519] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27821) 2.000788] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27821) 2.500996] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27821) 3.001083] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27821) 3.501370] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27821) 4.001514] [test/INFO] Cool, we received the message from 127.0.0.1:1024.
-[arthur:server:(27821) 4.499772] test.c:15: [test/CRITICAL] Argh, killed by 127.0.0.1:1024! Bye folks...
-[arthur:server:(27821) 4.499823] [gras/INFO] Exiting GRAS
-$
-$ ./test_simulator platform.xml test.xml
-[Boivin:client:(2) 0.000000] [test/INFO] Programming the repetitive action with a frequency of 0.5 sec
-[Boivin:client:(2) 0.000000] [test/INFO] Programming the delayed action in 5 secs
-[Boivin:client:(2) 0.500537] [test/INFO] Hello sent to server
-[Jacquelin:server:(1) 0.500537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 1.000537] [test/INFO] Hello sent to server
-[Jacquelin:server:(1) 1.000537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 1.500537] [test/INFO] Hello sent to server
-[Jacquelin:server:(1) 1.500537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 2.000537] [test/INFO] Hello sent to server
-[Jacquelin:server:(1) 2.000537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 2.500537] [test/INFO] Hello sent to server
-[Jacquelin:server:(1) 2.500537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 3.000537] [test/INFO] Hello sent to server
-[Jacquelin:server:(1) 3.000537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 3.500537] [test/INFO] Hello sent to server
-[Jacquelin:server:(1) 3.500537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 4.000537] [test/INFO] Hello sent to server
-[Jacquelin:server:(1) 4.000537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 4.500537] [test/INFO] Hello sent to server
-[Jacquelin:server:(1) 4.500537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 5.000537] [test/INFO] Hello sent to server
-[Jacquelin:server:(1) 5.000537] [test/INFO] Cool, we received the message from Boivin:1024.
-[Boivin:client:(2) 5.001074] [test/INFO] Kill sent to server
-[Boivin:client:(2) 5.001074] [test/INFO] Break the client's while loop
-[Boivin:client:(2) 5.001074] [gras/INFO] Exiting GRAS
-[Jacquelin:server:(1) 5.001074] test.c:15: [test/CRITICAL] Argh, killed by Boivin:1024! Bye folks...
-[Jacquelin:server:(1) 5.001074] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/08-exceptions.c b/doc/gtut-files/08-exceptions.c
deleted file mode 100644 (file)
index d419342..0000000
+++ /dev/null
@@ -1,98 +0,0 @@
-/* Copyright (c) 2006, 2007, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <gras.h>
-
-XBT_LOG_NEW_DEFAULT_CATEGORY(test, "My little example");
-
-typedef struct {
-  int killed;
-} server_data_t;
-
-
-int server_kill_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  gras_socket_t client = gras_msg_cb_ctx_from(ctx);
-  server_data_t *globals = (server_data_t *) gras_userdata_get();
-
-  XBT_CRITICAL("Argh, killed by %s:%d! Bye folks, I'm out of here...",
-            gras_socket_peer_name(client), gras_socket_peer_port(client));
-
-  globals->killed = 1;
-
-  return 0;
-}                               /* end_of_kill_callback */
-
-int server(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  server_data_t *globals;
-
-  gras_init(&argc, argv);
-
-  globals = gras_userdata_new(server_data_t *);
-  globals->killed = 0;
-
-  gras_msgtype_declare("kill", NULL);
-  gras_cb_register("kill", &server_kill_cb);
-
-  if (argc > 1 && !strcmp(argv[1], "--cheat")) {
-    mysock = gras_socket_server(9999);
-    XBT_INFO("Hi! hi! I'm not in the search range, but in 9999...");
-  } else {
-    mysock = gras_socket_server((rand() % 10) + 3000);
-    XBT_INFO("Ok, I'm hidden on port %d. Hope for the best.",
-          gras_socket_my_port(mysock));
-  }
-
-  while (!globals->killed) {
-    gras_msg_handle(-1);        /* blocking */
-  }
-
-  gras_exit();
-  return 0;
-}
-
-int client(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toserver;       /* socket used to write to the server */
-  int found;                    /* whether we found peer */
-  int port;                     /* where we think that the server is */
-  xbt_ex_t e;
-
-  gras_init(&argc, argv);
-
-  gras_msgtype_declare("kill", NULL);
-  mysock = gras_socket_server_range(1024, 10000, 0, 0);
-
-  XBT_VERB("Run little server, run. I'll get you. (sleep 1.5 sec)");
-  gras_os_sleep(1.5);
-
-  for (port = 3000, found = 0; port < 3010 && !found; port++) {
-    TRY {
-      toserver = gras_socket_client(argv[1], port);
-      gras_msg_send(toserver, "kill", NULL);
-      gras_socket_close(toserver);
-      found = 1;
-      XBT_INFO("Yeah! I found the server on %d! It's eradicated by now.",
-            port);
-    }
-    CATCH(e) {
-      xbt_ex_free(e);
-    }
-    if (!found)
-      XBT_INFO("Damn, the server is not on %d", port);
-  }                             /* end_of_loop */
-
-  if (!found)
-    THROWF(not_found_error, 0,
-           "Damn, I failed to find the server! I cannot survive this humilliation.");
-
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/08-exceptions.output b/doc/gtut-files/08-exceptions.output
deleted file mode 100644 (file)
index 3da7114..0000000
+++ /dev/null
@@ -1,35 +0,0 @@
-$ ./test_server & ./test_client 127.0.0.1 
-[arthur:client:(27889) 0.000013] [test/INFO] Damn, the server is not on 3000
-[arthur:client:(27889) 0.000729] [test/INFO] Yeah! I found the server on 3001! It's eradicated by now.
-[arthur:client:(27889) 0.000767] [gras/INFO] Exiting GRAS
-[arthur:server:(27886) 0.000013] [test/INFO] Ok, I'm hidden on port 3001. Hope for the best.
-[arthur:server:(27886) 1.500772] test.c:15: [test/CRITICAL] Argh, killed by 127.0.0.1:1024! Bye folks, I'm out of here...
-[arthur:server:(27886) 1.500819] [gras/INFO] Exiting GRAS
-$
-$ ./test_server --cheat & ./test_client 127.0.0.1 
-[arthur:client:(27901) 0.000014] [test/INFO] Damn, the server is not on 3000
-[arthur:client:(27901) 0.000240] [test/INFO] Damn, the server is not on 3001
-[arthur:client:(27901) 0.000386] [test/INFO] Damn, the server is not on 3002
-[arthur:client:(27901) 0.000532] [test/INFO] Damn, the server is not on 3003
-[arthur:client:(27901) 0.000671] [test/INFO] Damn, the server is not on 3004
-[arthur:client:(27901) 0.000815] [test/INFO] Damn, the server is not on 3005
-[arthur:client:(27901) 0.000960] [test/INFO] Damn, the server is not on 3006
-[arthur:client:(27901) 0.001100] [test/INFO] Damn, the server is not on 3007
-[arthur:client:(27901) 0.001257] [test/INFO] Damn, the server is not on 3008
-[arthur:client:(27901) 0.001396] [test/INFO] Damn, the server is not on 3009
-** SimGrid: UNCAUGHT EXCEPTION received on arthur(27901): category: not found; value: 0
-** Damn, I failed to find the server! I cannot survive this humilliation.
-** Thrown by client() in this process
-[arthur:client:(27901) 0.001475] xbt/ex.c:113: [xbt_ex/CRITICAL] Damn, I failed to find the server! I cannot survive this humilliation.
-
-**   In client() at /home/mquinson/Code/simgrid-git/doc/gtut-files/test.c:80
-$ killall test_server
-[arthur:server:(27897) 0.000014] [test/INFO] Hi! hi! I'm not in the search range, but in 9999...
-$
-$ ./test_simulator platform.xml test.xml
-[Jacquelin:server:(1) 0.000000] [test/INFO] Ok, I'm hidden on port 3000. Hope for the best.
-[Boivin:client:(2) 1.500552] [test/INFO] Yeah! I found the server on 3000! It's eradicated by now.
-[Boivin:client:(2) 1.500552] [gras/INFO] Exiting GRAS
-[Jacquelin:server:(1) 1.500552] test.c:15: [test/CRITICAL] Argh, killed by Boivin:1024! Bye folks, I'm out of here...
-[Jacquelin:server:(1) 1.500552] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/09-datatype-dump.c b/doc/gtut-files/09-datatype-dump.c
deleted file mode 100644 (file)
index 8124064..0000000
+++ /dev/null
@@ -1,29 +0,0 @@
-/* Copyright (c) 2006, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <gras.h>
-#include <stdio.h>
-
-/* We must set this to make logging mecanism happy */
-extern const char *_gras_procname;
-
-/* This is a private data of gras/Datadesc we want to explore */
-xbt_set_t gras_datadesc_set_local = NULL;
-
-int main(int argc, char *argv[])
-{
-  xbt_set_elm_t elm;
-  xbt_set_cursor_t cursor;
-  gras_init(&argc, argv);
-
-  xbt_set_foreach(gras_datadesc_set_local, cursor, elm) {
-    printf("%s\n", elm->name);
-  }
-
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/09-simpledata.c b/doc/gtut-files/09-simpledata.c
deleted file mode 100644 (file)
index 29c24c0..0000000
+++ /dev/null
@@ -1,102 +0,0 @@
-/* Copyright (c) 2006, 2007, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <gras.h>
-
-XBT_LOG_NEW_DEFAULT_CATEGORY(test, "My little example");
-
-typedef struct {
-  int killed;
-} server_data_t;
-
-
-int server_kill_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  double delay = *(double *) payload;
-  gras_socket_t client = gras_msg_cb_ctx_from(ctx);
-  server_data_t *globals = (server_data_t *) gras_userdata_get();
-
-  XBT_CRITICAL("Argh, %s:%d gave me %.2f seconds before suicide!",
-            gras_socket_peer_name(client), gras_socket_peer_port(client),
-            delay);
-  gras_os_sleep(delay);
-  XBT_CRITICAL("Bye folks...");
-
-
-  globals->killed = 1;
-
-  return 0;
-}                               /* end_of_kill_callback */
-
-int server_hello_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  char *msg = *(char **) payload;
-  gras_socket_t client = gras_msg_cb_ctx_from(ctx);
-
-  XBT_INFO("Cool, we received a message from %s:%d. Here it is: \"%s\"",
-        gras_socket_peer_name(client), gras_socket_peer_port(client), msg);
-
-  return 0;
-}                               /* end_of_hello_callback */
-
-void message_declaration(void)
-{
-  gras_msgtype_declare("kill", gras_datadesc_by_name("double"));
-  gras_msgtype_declare("hello", gras_datadesc_by_name("string"));
-}
-
-
-int server(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  server_data_t *globals;
-
-  gras_init(&argc, argv);
-
-  globals = gras_userdata_new(server_data_t *);
-  globals->killed = 0;
-
-  message_declaration();
-  mysock = gras_socket_server(atoi(argv[1]));
-
-  gras_cb_register("hello", &server_hello_cb);
-  gras_cb_register("kill", &server_kill_cb);
-
-  while (!globals->killed) {
-    gras_msg_handle(-1);        /* blocking */
-  }
-
-  gras_exit();
-  return 0;
-}
-
-int client(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toserver;       /* socket used to write to the server */
-
-  gras_init(&argc, argv);
-
-  message_declaration();
-  mysock = gras_socket_server_range(1024, 10000, 0, 0);
-
-  XBT_VERB("Client ready; listening on %d", gras_socket_my_port(mysock));
-
-  gras_os_sleep(1.5);           /* sleep 1 second and half */
-  toserver = gras_socket_client(argv[1], atoi(argv[2]));
-
-  char *hello_payload = "Nice to meet you";
-  gras_msg_send(toserver, "hello", &hello_payload);
-  XBT_INFO("we sent the hello to the server on %s.",
-        gras_socket_peer_name(toserver));
-
-  double kill_payload = 0.5;
-  gras_msg_send(toserver, "kill", &kill_payload);
-  XBT_INFO("Gave the server more 0.5 second to live");
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/09-simpledata.output b/doc/gtut-files/09-simpledata.output
deleted file mode 100644 (file)
index 2465493..0000000
+++ /dev/null
@@ -1,18 +0,0 @@
-$ ./test_server 12345 & ./test_client 127.0.0.1 12345
-[arthur:client:(27970) 0.000025] [test/INFO] we sent the hello to the server on 127.0.0.1.
-[arthur:client:(27970) 0.000124] [test/INFO] Gave the server more 0.5 second to live
-[arthur:client:(27970) 0.000152] [gras/INFO] Exiting GRAS
-[arthur:server:(27967) 0.000013] [test/INFO] Cool, we received a message from 127.0.0.1:1024. Here it is: "Nice to meet you"
-[arthur:server:(27967) 0.000105] test.c:16: [test/CRITICAL] Argh, 127.0.0.1:1024 gave me 0.50 seconds before suicide!
-[arthur:server:(27967) 0.500236] test.c:18: [test/CRITICAL] Bye folks...
-[arthur:server:(27967) 0.500303] [gras/INFO] Exiting GRAS
-$
-$ ./test_simulator platform.xml test.xml
-[Boivin:client:(2) 0.000000] [test/INFO] we sent the hello to the server on Jacquelin.
-[Jacquelin:server:(1) 0.000000] [test/INFO] Cool, we received a message from Boivin:1024. Here it is: "Nice to meet you"
-[Boivin:client:(2) 0.000539] [test/INFO] Gave the server more 0.5 second to live
-[Boivin:client:(2) 0.000539] [gras/INFO] Exiting GRAS
-[Jacquelin:server:(1) 0.000539] test.c:16: [test/CRITICAL] Argh, Boivin:1024 gave me 0.50 seconds before suicide!
-[Jacquelin:server:(1) 0.500539] test.c:18: [test/CRITICAL] Bye folks...
-[Jacquelin:server:(1) 0.500539] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/10-rpc.c b/doc/gtut-files/10-rpc.c
deleted file mode 100644 (file)
index bc01cbf..0000000
+++ /dev/null
@@ -1,146 +0,0 @@
-/* Copyright (c) 2006, 2007, 2009, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <stdlib.h>
-#include <gras.h>
-
-XBT_LOG_NEW_DEFAULT_CATEGORY(test, "My little example");
-
-typedef struct {
-  int done;
-} server_data_t;
-int server_done_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  server_data_t *globals = (server_data_t *) gras_userdata_get();
-  globals->done = 1;
-  XBT_INFO("Server done");
-
-  return 0;
-}                               /* end_of_done_callback */
-
-void message_declaration(void)
-{
-  gras_msgtype_declare_rpc("convert a2i", gras_datadesc_by_name("string"),
-                           gras_datadesc_by_name("long"));
-  gras_msgtype_declare_rpc("convert i2a", gras_datadesc_by_name("long"),
-                           gras_datadesc_by_name("string"));
-
-  /* the other message allowing the client to stop the server after use */
-  gras_msgtype_declare("done", NULL);
-}
-
-int server_convert_i2a_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  long data = *(long *) payload;
-  char *result;
-  char *p;
-
-  XBT_INFO("Convert %ld to string", data);
-  result = bprintf("%ld", data);
-  XBT_INFO("%ld converted to string: %s", data, result);
-
-  gras_msg_rpcreturn(60, ctx, &result);
-  free(result);
-  return 0;
-}                               /* end_of_convert_callback */
-
-int server_convert_a2i_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  char *string = *(char **) payload;
-  long result;
-  char *p;
-
-  XBT_INFO("Convert %s to long", string);
-  result = strtol(string, &p, 10);
-
-  if (*p != '\0')
-    THROWF(arg_error, 0,
-           "Error while converting %s: this does not seem to be a valid number (problem at '%s')",
-           string, p);
-
-  gras_msg_rpcreturn(60, ctx, &result);
-  return 0;
-}                               /* end_of_convert_callback */
-
-
-int server(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  server_data_t *globals;
-
-  gras_init(&argc, argv);
-
-  globals = gras_userdata_new(server_data_t *);
-  globals->done = 0;
-
-  message_declaration();
-  mysock = gras_socket_server(atoi(argv[1]));
-
-  gras_cb_register("convert a2i", &server_convert_a2i_cb);
-  gras_cb_register("convert i2a", &server_convert_i2a_cb);
-  gras_cb_register("done", &server_done_cb);
-
-  while (!globals->done) {
-    gras_msg_handle(-1);        /* blocking */
-  }
-
-  gras_exit();
-  return 0;
-}
-
-int client(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toserver;       /* socket used to write to the server */
-
-  gras_init(&argc, argv);
-
-  message_declaration();
-  mysock = gras_socket_server_range(1024, 10000, 0, 0);
-
-  XBT_VERB("Client ready; listening on %d", gras_socket_my_port(mysock));
-
-  gras_os_sleep(1.5);           /* sleep 1 second and half */
-  toserver = gras_socket_client(argv[1], atoi(argv[2]));
-
-  long long_to_convert = 4321;
-  char *string_result;
-  XBT_INFO("Ask to convert %ld", long_to_convert);
-  gras_msg_rpccall(toserver, 60, "convert i2a", &long_to_convert,
-                   &string_result);
-  XBT_INFO("The server says that %ld is equal to \"%s\".", long_to_convert,
-        string_result);
-  free(string_result);
-
-  char *string_to_convert = "1234";
-  long long_result;
-  XBT_INFO("Ask to convert %s", string_to_convert);
-  gras_msg_rpccall(toserver, 60, "convert a2i", &string_to_convert,
-                   &long_result);
-  XBT_INFO("The server says that \"%s\" is equal to %d.", string_to_convert,
-        long_result);
-
-  xbt_ex_t e;
-  string_to_convert = "azerty";
-  TRY {
-    gras_msg_rpccall(toserver, 60, "convert a2i", &string_to_convert,
-                     &long_result);
-  }
-  CATCH(e) {
-    XBT_INFO
-        ("The server refuses to convert %s. Here is the received exception:",
-         string_to_convert);
-    xbt_ex_display(&e);
-    xbt_ex_free(e);
-    XBT_INFO("Again, previous exception was excepted");
-  }
-
-  gras_msg_send(toserver, "done", NULL);
-  XBT_INFO("Stopped the server");
-
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/10-rpc.output b/doc/gtut-files/10-rpc.output
deleted file mode 100644 (file)
index e77826b..0000000
+++ /dev/null
@@ -1,80 +0,0 @@
-$ ./test_server & ./test_client 127.0.0.1 
-[arthur:server:(12832) 0.000013] [test/INFO] Convert 4321 to string
-[arthur:server:(12832) 0.000128] [test/INFO] 4321 converted to string: 4321
-[arthur:server:(12832) 0.003889] [test/INFO] Convert 1234 to long
-[arthur:server:(12832) 0.008356] [test/INFO] Convert azerty to long
-[arthur:server:(12832) 0.053995] [gras_msg/INFO] Propagate local exception ('Error while converting azerty: this does not seem to be a valid number (problem at 'azerty')') from 'convert a2i' RPC cb back to 127.0.0.1:1024
-** SimGrid: UNCAUGHT EXCEPTION received on arthur(12832): category: invalid_arg; value: 0
-** Error while converting azerty: this does not seem to be a valid number (problem at 'azerty')
-** Thrown by server() in this process
-[arthur:server:(12832) 0.054088] xbt/ex.c:113: [xbt_ex/CRITICAL] Error while converting azerty: this does not seem to be a valid number (problem at 'azerty')
-
-**   In server_convert_a2i_cb() at /home/mquinson/Code/simgrid-git/doc/gtut-files/test.c:48
-**   In gras_msg_handle() at /home/mquinson/Code/simgrid-git/src/gras/Msg/gras_msg_exchange.c:400
-**   In server() at /home/mquinson/Code/simgrid-git/doc/gtut-files/test.c:71
-[arthur:server:(12832) 0.055022] [test/INFO] Server done
-[arthur:server:(12832) 0.055063] [gras/INFO] Exiting GRAS
-[arthur:client:(12837) 0.000025] [test/INFO] Ask to convert 4321
-[arthur:client:(12837) 0.004416] [test/INFO] The server says that 4321 is equal to "4321".
-[arthur:client:(12837) 0.004468] [test/INFO] Ask to convert 1234
-[arthur:client:(12837) 0.008930] [test/INFO] The server says that "1234" is equal to 1234.
-[arthur:client:(12837) 0.055412] [test/INFO] The server refuses to convert azerty. Here is the received exception:
-** SimGrid: UNCAUGHT EXCEPTION received on arthur(12837): category: invalid_arg; value: 0
-** Error while converting azerty: this does not seem to be a valid number (problem at 'azerty')
-** Thrown by server() on host arthur(12832)
-[arthur:client:(12837) 0.055505] xbt/ex.c:113: [xbt_ex/CRITICAL] Error while converting azerty: this does not seem to be a valid number (problem at 'azerty')
-
-**   In server_convert_a2i_cb() at /home/mquinson/Code/simgrid-git/doc/gtut-files/test.c:48
-**   In gras_msg_handle() at /home/mquinson/Code/simgrid-git/src/gras/Msg/gras_msg_exchange.c:400
-**   In server() at /home/mquinson/Code/simgrid-git/doc/gtut-files/test.c:71
-[arthur:client:(12837) 0.055564] [test/INFO] Again, previous exception was excepted
-[arthur:client:(12837) 0.056367] [test/INFO] Stopped the server
-[arthur:client:(12837) 0.056404] [gras/INFO] Exiting GRAS
-$
-$ killall test_server
-$
-$ ./test_simulator platform.xml test.xml
-[Boivin:client:(2) 0.000000] [test/INFO] Ask to convert 4321
-[Jacquelin:server:(1) 0.000538] [test/INFO] Convert 4321 to string
-[Jacquelin:server:(1) 0.000538] [test/INFO] 4321 converted to string: 4321
-[Boivin:client:(2) 0.001077] [test/INFO] The server says that 4321 is equal to "4321".
-[Boivin:client:(2) 0.001077] [test/INFO] Ask to convert 1234
-[Jacquelin:server:(1) 0.001615] [test/INFO] Convert 1234 to long
-[Boivin:client:(2) 0.002153] [test/INFO] The server says that "1234" is equal to 1234.
-[Jacquelin:server:(1) 0.002692] [test/INFO] Convert azerty to long
-[Jacquelin:server:(1) 0.002692] [gras_msg/INFO] Propagate local exception ('Error while converting azerty: this does not seem to be a valid number (problem at 'azerty')') from 'convert a2i' RPC cb back to Boivin:1024
-** SimGrid: UNCAUGHT EXCEPTION received on Jacquelin(1): category: invalid_arg; value: 0
-** Error while converting azerty: this does not seem to be a valid number (problem at 'azerty')
-** Thrown by server() in this process
-[Jacquelin:server:(1) 0.002692] xbt/ex.c:113: [xbt_ex/CRITICAL] Error while converting azerty: this does not seem to be a valid number (problem at 'azerty')
-
-**   In server_convert_a2i_cb() at /home/mquinson/Code/simgrid-git/doc/gtut-files/test.c:48
-**   In gras_msg_handle() at /home/mquinson/Code/simgrid-git/src/gras/Msg/gras_msg_exchange.c:400
-**   In server() at /home/mquinson/Code/simgrid-git/doc/gtut-files/test.c:71
-**   In xbt_ctx_sysv_stop() at /home/mquinson/Code/simgrid-git/src/xbt/xbt_context_sysv.c:257
-**   In makecontext() at ??:0
-**   In update_actions_state() at /home/mquinson/Code/simgrid-git/src/surf/surf_timer.c:108
-**   In surf_solve() at /home/mquinson/Code/simgrid-git/src/surf/surf.c:543
-**   In SIMIX_solve() at /home/mquinson/Code/simgrid-git/src/simix/smx_global.c:347
-**   In gras_main() at /home/mquinson/Code/simgrid-git/src/gras/Virtu/sg_process.c:222
-[Boivin:client:(2) 0.003490] [test/INFO] The server refuses to convert azerty. Here is the received exception:
-** SimGrid: UNCAUGHT EXCEPTION received on Boivin(2): category: invalid_arg; value: 0
-** Error while converting azerty: this does not seem to be a valid number (problem at 'azerty')
-** Thrown by server() on host Jacquelin(1)
-[Boivin:client:(2) 0.003490] xbt/ex.c:113: [xbt_ex/CRITICAL] Error while converting azerty: this does not seem to be a valid number (problem at 'azerty')
-
-**   In server_convert_a2i_cb() at /home/mquinson/Code/simgrid-git/doc/gtut-files/test.c:48
-**   In gras_msg_handle() at /home/mquinson/Code/simgrid-git/src/gras/Msg/gras_msg_exchange.c:400
-**   In server() at /home/mquinson/Code/simgrid-git/doc/gtut-files/test.c:71
-**   In xbt_ctx_sysv_stop() at /home/mquinson/Code/simgrid-git/src/xbt/xbt_context_sysv.c:257
-**   In makecontext() at ??:0
-**   In update_actions_state() at /home/mquinson/Code/simgrid-git/src/surf/surf_timer.c:108
-**   In surf_solve() at /home/mquinson/Code/simgrid-git/src/surf/surf.c:543
-**   In SIMIX_solve() at /home/mquinson/Code/simgrid-git/src/simix/smx_global.c:347
-**   In gras_main() at /home/mquinson/Code/simgrid-git/src/gras/Virtu/sg_process.c:222
-[Boivin:client:(2) 0.003490] [test/INFO] Again, previous exception was excepted
-[Boivin:client:(2) 0.004027] [test/INFO] Stopped the server
-[Boivin:client:(2) 0.004027] [gras/INFO] Exiting GRAS
-[Jacquelin:server:(1) 0.004027] [test/INFO] Server done
-[Jacquelin:server:(1) 0.004027] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/11-explicitwait.c b/doc/gtut-files/11-explicitwait.c
deleted file mode 100644 (file)
index f13c7e9..0000000
+++ /dev/null
@@ -1,123 +0,0 @@
-/* Copyright (c) 2007, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <stdlib.h>
-#include <gras.h>
-
-XBT_LOG_NEW_DEFAULT_CATEGORY(test, "My little example");
-
-void message_declaration(void)
-{
-  gras_msgtype_declare("request", NULL);
-  gras_msgtype_declare("grant", NULL);
-  gras_msgtype_declare("release", NULL);
-}
-
-typedef struct {
-  int process_in_CS;
-  xbt_dynar_t waiting_queue;
-} server_data_t;
-
-int server_request_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  server_data_t *globals = (server_data_t *) gras_userdata_get();
-  gras_socket_t s = gras_msg_cb_ctx_from(ctx);
-
-  if (globals->process_in_CS) {
-    xbt_dynar_push(globals->waiting_queue, &s);
-    XBT_INFO("put %s:%d in waiting queue", gras_socket_peer_name(s),
-          gras_socket_peer_port(s));
-  } else {
-    globals->process_in_CS = 1;
-    XBT_INFO("grant %s:%d since nobody wanted it", gras_socket_peer_name(s),
-          gras_socket_peer_port(s));
-    gras_msg_send(s, "grant", NULL);
-  }
-  return 0;
-}                               /* end_of_request_callback */
-
-int server_release_cb(gras_msg_cb_ctx_t ctx, void *payload)
-{
-  server_data_t *globals = (server_data_t *) gras_userdata_get();
-
-  if (!xbt_dynar_is_empty(globals->waiting_queue)) {
-    gras_socket_t s;
-    xbt_dynar_pop(globals->waiting_queue, &s);
-
-    XBT_INFO("grant %s:%d since token released", gras_socket_peer_name(s),
-          gras_socket_peer_port(s));
-    gras_msg_send(s, "grant", NULL);
-  } else {
-    globals->process_in_CS = 0;
-  }
-
-  return 0;
-}                               /* end_of_release_callback */
-
-int server(int argc, char *argv[])
-{
-  gras_socket_t mysock;         /* socket on which I listen */
-  server_data_t *globals;
-  int i;
-
-  gras_init(&argc, argv);
-  mysock = gras_socket_server(atoi(argv[1]));
-
-  globals = gras_userdata_new(server_data_t);
-  globals->process_in_CS = 0;
-  globals->waiting_queue =
-      xbt_dynar_new(sizeof(gras_socket_t),
-                    NULL /* not closing sockets */ );
-
-  message_declaration();
-  gras_cb_register("request", &server_request_cb);
-  gras_cb_register("release", &server_release_cb);
-
-  for (i = 0; i < 20; i++)      /* 5 requests of each process, 2 processes, 2 messages per request */
-    gras_msg_handle(-1);
-
-  gras_exit();
-  return 0;
-}                               /* end_of_server */
-
-void lock(gras_socket_t toserver)
-{
-  gras_msg_send(toserver, "request", NULL);
-  gras_msg_wait(-1, "grant", NULL, NULL);
-  XBT_INFO("Granted by server");
-}                               /* end_of_lock */
-
-void unlock(gras_socket_t toserver)
-{
-  XBT_INFO("Release the token");
-  gras_msg_send(toserver, "release", NULL);
-}                               /* end_of_unlock */
-
-int client(int argc, char *argv[])
-{
-  int i;
-  gras_socket_t mysock;         /* socket on which I listen */
-  gras_socket_t toserver;       /* socket used to write to the server */
-
-  gras_init(&argc, argv);
-
-  mysock = gras_socket_server_range(1024, 10000, 0, 0);
-
-  XBT_VERB("Client ready; listening on %d", gras_socket_my_port(mysock));
-
-  gras_os_sleep(1.5);           /* sleep 1 second and half */
-  message_declaration();
-  toserver = gras_socket_client(argv[1], atoi(argv[2]));
-
-  for (i = 0; i < 5; i++) {
-    gras_os_sleep(0.1);
-    lock(toserver);
-    gras_os_sleep(0.1);
-    unlock(toserver);
-  }
-  gras_exit();
-  return 0;
-}
diff --git a/doc/gtut-files/11-explicitwait.output b/doc/gtut-files/11-explicitwait.output
deleted file mode 100644 (file)
index 5f24d07..0000000
+++ /dev/null
@@ -1,89 +0,0 @@
-$ ./test_server & ./test_client 127.0.0.1 12345 & ./test_client 127.0.0.1 12345 
-[arthur:server:(28159) 0.000023] [test/INFO] grant 127.0.0.1:1024 since nobody wanted it
-[arthur:client:(28160) 0.000013] [test/INFO] Granted by server
-[arthur:server:(28159) 0.014750] [test/INFO] put 127.0.0.1:1025 in waiting queue
-[arthur:client:(28160) 0.100254] [test/INFO] Release the token
-[arthur:server:(28159) 0.100950] [test/INFO] grant 127.0.0.1:1025 since token released
-[arthur:client:(28162) 0.000014] [test/INFO] Granted by server
-[arthur:server:(28159) 0.201146] [test/INFO] put 127.0.0.1:1024 in waiting queue
-[arthur:client:(28162) 0.100169] [test/INFO] Release the token
-[arthur:server:(28159) 0.201593] [test/INFO] grant 127.0.0.1:1024 since token released
-[arthur:client:(28160) 0.201472] [test/INFO] Granted by server
-[arthur:client:(28160) 0.301560] [test/INFO] Release the token
-[arthur:server:(28159) 0.302114] [test/INFO] put 127.0.0.1:1025 in waiting queue
-[arthur:server:(28159) 0.302172] [test/INFO] grant 127.0.0.1:1025 since token released
-[arthur:client:(28162) 0.201166] [test/INFO] Granted by server
-[arthur:server:(28159) 0.402342] [test/INFO] put 127.0.0.1:1024 in waiting queue
-[arthur:client:(28162) 0.301265] [test/INFO] Release the token
-[arthur:server:(28159) 0.402687] [test/INFO] grant 127.0.0.1:1024 since token released
-[arthur:client:(28160) 0.402605] [test/INFO] Granted by server
-[arthur:server:(28159) 0.503013] [test/INFO] put 127.0.0.1:1025 in waiting queue
-[arthur:client:(28160) 0.502739] [test/INFO] Release the token
-[arthur:server:(28159) 0.503260] [test/INFO] grant 127.0.0.1:1025 since token released
-[arthur:client:(28162) 0.402236] [test/INFO] Granted by server
-[arthur:server:(28159) 0.603517] [test/INFO] put 127.0.0.1:1024 in waiting queue
-[arthur:client:(28162) 0.502304] [test/INFO] Release the token
-[arthur:server:(28159) 0.603699] [test/INFO] grant 127.0.0.1:1024 since token released
-[arthur:client:(28160) 0.603564] [test/INFO] Granted by server
-[arthur:client:(28160) 0.703651] [test/INFO] Release the token
-[arthur:server:(28159) 0.704098] [test/INFO] put 127.0.0.1:1025 in waiting queue
-[arthur:server:(28159) 0.704146] [test/INFO] grant 127.0.0.1:1025 since token released
-[arthur:client:(28162) 0.603133] [test/INFO] Granted by server
-[arthur:server:(28159) 0.804385] [test/INFO] put 127.0.0.1:1024 in waiting queue
-[arthur:client:(28162) 0.703226] [test/INFO] Release the token
-[arthur:server:(28159) 0.804647] [test/INFO] grant 127.0.0.1:1024 since token released
-[arthur:client:(28160) 0.804530] [test/INFO] Granted by server
-[arthur:client:(28160) 0.904608] [test/INFO] Release the token
-[arthur:server:(28159) 0.905011] [test/INFO] put 127.0.0.1:1025 in waiting queue
-[arthur:client:(28160) 0.904749] [gras/INFO] Exiting GRAS
-[arthur:server:(28159) 0.905159] [test/INFO] grant 127.0.0.1:1025 since token released
-[arthur:client:(28162) 0.804870] [test/INFO] Granted by server
-[arthur:client:(28162) 0.905010] [test/INFO] Release the token
-[arthur:client:(28162) 0.905181] [gras/INFO] Exiting GRAS
-[arthur:server:(28159) 1.007620] [gras/INFO] Exiting GRAS
-$
-$
-$ ./test_simulator platform-3nodes.xml test.xml
-[Jacquelin:server:(1) 0.000000] [test/INFO] grant Boivin:1024 since nobody wanted it
-[Jacquelin:server:(1) 0.000537] [test/INFO] put Geoff:1024 in waiting queue
-[Boivin:client:(2) 0.000537] [test/INFO] Granted by server
-[Boivin:client:(2) 0.100537] [test/INFO] Release the token
-[Jacquelin:server:(1) 0.101074] [test/INFO] grant Geoff:1024 since token released
-[Geoff:client:(3) 0.101264] [test/INFO] Granted by server
-[Geoff:client:(3) 0.201264] [test/INFO] Release the token
-[Jacquelin:server:(1) 0.201611] [test/INFO] put Boivin:1024 in waiting queue
-[Jacquelin:server:(1) 0.201801] [test/INFO] grant Boivin:1024 since token released
-[Boivin:client:(2) 0.202338] [test/INFO] Granted by server
-[Jacquelin:server:(1) 0.301991] [test/INFO] put Geoff:1024 in waiting queue
-[Boivin:client:(2) 0.302338] [test/INFO] Release the token
-[Jacquelin:server:(1) 0.302875] [test/INFO] grant Geoff:1024 since token released
-[Geoff:client:(3) 0.303065] [test/INFO] Granted by server
-[Geoff:client:(3) 0.403065] [test/INFO] Release the token
-[Jacquelin:server:(1) 0.403412] [test/INFO] put Boivin:1024 in waiting queue
-[Jacquelin:server:(1) 0.403602] [test/INFO] grant Boivin:1024 since token released
-[Boivin:client:(2) 0.404139] [test/INFO] Granted by server
-[Jacquelin:server:(1) 0.503792] [test/INFO] put Geoff:1024 in waiting queue
-[Boivin:client:(2) 0.504139] [test/INFO] Release the token
-[Jacquelin:server:(1) 0.504675] [test/INFO] grant Geoff:1024 since token released
-[Geoff:client:(3) 0.504865] [test/INFO] Granted by server
-[Geoff:client:(3) 0.604865] [test/INFO] Release the token
-[Jacquelin:server:(1) 0.605212] [test/INFO] put Boivin:1024 in waiting queue
-[Jacquelin:server:(1) 0.605402] [test/INFO] grant Boivin:1024 since token released
-[Boivin:client:(2) 0.605939] [test/INFO] Granted by server
-[Jacquelin:server:(1) 0.705592] [test/INFO] put Geoff:1024 in waiting queue
-[Boivin:client:(2) 0.705939] [test/INFO] Release the token
-[Jacquelin:server:(1) 0.706476] [test/INFO] grant Geoff:1024 since token released
-[Geoff:client:(3) 0.706666] [test/INFO] Granted by server
-[Geoff:client:(3) 0.806666] [test/INFO] Release the token
-[Jacquelin:server:(1) 0.807013] [test/INFO] put Boivin:1024 in waiting queue
-[Jacquelin:server:(1) 0.807203] [test/INFO] grant Boivin:1024 since token released
-[Boivin:client:(2) 0.807740] [test/INFO] Granted by server
-[Jacquelin:server:(1) 0.907393] [test/INFO] put Geoff:1024 in waiting queue
-[Boivin:client:(2) 0.907740] [test/INFO] Release the token
-[Boivin:client:(2) 0.908277] [gras/INFO] Exiting GRAS
-[Jacquelin:server:(1) 0.908277] [test/INFO] grant Geoff:1024 since token released
-[Geoff:client:(3) 0.908467] [test/INFO] Granted by server
-[Geoff:client:(3) 1.008467] [test/INFO] Release the token
-[Geoff:client:(3) 1.008657] [gras/INFO] Exiting GRAS
-[Jacquelin:server:(1) 1.008657] [gras/INFO] Exiting GRAS
-$
diff --git a/doc/gtut-files/11-explicitwait.xml b/doc/gtut-files/11-explicitwait.xml
deleted file mode 100644 (file)
index bb94d69..0000000
+++ /dev/null
@@ -1,16 +0,0 @@
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
-<platform version="3">
-  <process host="Jacquelin" function="server">
-    <argument value="12345"/>
-  </process>
-  <process host="Boivin" function="client">
-    <argument value="Jacquelin"/>
-    <argument value="12345"/>
-  </process>
-  <process host="Geoff" function="client">
-    <argument value="Jacquelin"/>
-    <argument value="12345"/>
-  </process>
-</platform>
-
diff --git a/doc/gtut-files/Makefile b/doc/gtut-files/Makefile
deleted file mode 100644 (file)
index 6b602ef..0000000
+++ /dev/null
@@ -1,331 +0,0 @@
-# This works mainly on my box for now
-export LD_LIBRARY_PATH=$(GRAS_ROOT)/lib
-GRAS_STUB_GENERATOR=$(GRAS_ROOT)/bin/gras_stub_generator
-
-all: 01-bones.output 02-simple.output 03-args.output 04-callback.output \
-     05-globals.output 06-logs.output 07-timers.output 08-exceptions.output \
-     09-simpledata.output 10-rpc.output 11-explicitwait.output
-
-veryclean: clean
-       rm *.output*
-
-# Lesson 01: simple bones of project
-########################################
-
-01-bones.output: 01-bones_client 01-bones_server 01-bones_simulator
-       echo '$$ ./test_client'                           > $@ 
-       ./01-bones_client                                 >> $@ 2>&1
-       echo '$$ ./test_server'                          >> $@
-       ./01-bones_server                                 >> $@ 2>&1
-       echo '$$'                                        >> $@ 
-       echo '$$ ./test_simulator platform.xml test.xml' >> $@ 
-       ./01-bones_simulator gtut-platform.xml test.xml   >> $@ 2>&1
-       echo '$$'                                        >> $@ 
-
-01-bones_client 01-bones_server 01-bones_simulator: _01-bones_client.c _01-bones_server.c _01-bones_simulator.c
-       make -f 01-bones.mk
-
-_01-bones_client.c _01-bones_server.c _01-bones_simulator.c: 01-bones.c test.xml
-       $(GRAS_STUB_GENERATOR) 01-bones test.xml >/dev/null
-
-clean::
-       if [ -e 01-bones.mk ] ; then make -f 01-bones.mk clean; fi
-       rm -f _01-bones_client.c _01-bones_server.c _01-bones_simulator.c 01-bones.trace 01-bones.mk
-
-# Lesson 02: simple message exchange
-########################################
-
-02-simple.output: 02-simple_client 02-simple_server 02-simple_simulator
-       echo '$$ ./test_simulator platform.xml test.xml'  > $@
-       ./02-simple_simulator gtut-platform.xml test.xml  >> $@ 2>&1
-       echo '$$'                                        >> $@ 
-
-02-simple_client 02-simple_server 02-simple_simulator: _02-simple_client.c _02-simple_server.c _02-simple_simulator.c
-       make -f 02-simple.mk
-
-_02-simple_client.c _02-simple_server.c _02-simple_simulator.c: 02-simple.c test.xml
-       $(GRAS_STUB_GENERATOR) 02-simple test.xml >/dev/null
-
-clean::
-       if [ -e 02-simple.mk ] ; then make -f 02-simple.mk clean; fi
-       rm -f _02-simple_client.c _02-simple_server.c _02-simple_simulator.c 02-simple.trace 02-simple.mk
-
-# Lesson 03: passing args to processes
-########################################
-
-03-args.output: 03-args_client 03-args_server 03-args_simulator
-       echo '$$ ./test_server 12345 & ./test_client 127.0.0.1 12345'  > $@ 
-       ./03-args_server 12345                                         >> $@ 2>&1&
-       ./03-args_client 127.0.0.1 12345                               >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml'              >> $@
-       ./03-args_simulator gtut-platform.xml 03-args.xml               >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-       killall 03-args_server 03-args_client 2>/dev/null || true
-
-03-args_client 03-args_server 03-args_simulator: _03-args_client.c _03-args_server.c _03-args_simulator.c
-       make -f 03-args.mk
-
-_03-args_client.c _03-args_server.c _03-args_simulator.c: 03-args.c 03-args.xml
-       $(GRAS_STUB_GENERATOR) 03-args 03-args.xml >/dev/null
-
-clean::
-       if [ -e 03-args.mk ] ; then make -f 03-args.mk clean; fi
-       rm -f _03-args_client.c _03-args_server.c _03-args_simulator.c 03-args.trace 03-args.mk
-
-# Lesson 4: callbacks
-########################################
-
-04-callback.output: 04-callback_client 04-callback_server 04-callback_simulator
-       echo '$$ ./test_server 23451 & ./test_client 127.0.0.1 23451'  > $@ 
-       ./04-callback_server 23451                                     >> $@ 2>&1&
-       ./04-callback_client 127.0.0.1 23451                           >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml'              >> $@
-       ./04-callback_simulator gtut-platform.xml 03-args.xml           >> $@ 2>&1
-       echo '$$'                                                     >> $@
-       killall 04-callback_server 04-callback_client 2>/dev/null || true
-
-04-callback_client 04-callback_server 04-callback_simulator: _04-callback_client.c _04-callback_server.c _04-callback_simulator.c
-       make -f 04-callback.mk
-
-_04-callback_client.c _04-callback_server.c _04-callback_simulator.c: 04-callback.c 03-args.xml
-       $(GRAS_STUB_GENERATOR) 04-callback 03-args.xml >/dev/null
-
-clean::
-       if [ -e 04-callback.mk ] ; then make -f 04-callback.mk clean; fi
-       rm -f _04-callback_client.c _04-callback_server.c _04-callback_simulator.c 04-callback.trace 04-callback.mk
-
-# Lesson 5: globals
-########################################
-
-05-globals.output: 05-globals_client 05-globals_server 05-globals_simulator
-       echo '$$ ./test_server 12345 & ./test_client 127.0.0.1 12345'  > $@ 
-       ./05-globals_server 12345                                      >> $@ 2>&1&
-       ./05-globals_client 127.0.0.1 12345                            >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml'              >> $@
-       ./05-globals_simulator gtut-platform.xml 03-args.xml            >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-       killall 05-globals_server 05-globals_client 2>/dev/null || true
-
-05-globals_client 05-globals_server 05-globals_simulator: _05-globals_client.c _05-globals_server.c _05-globals_simulator.c
-       make -f 05-globals.mk
-
-_05-globals_client.c _05-globals_server.c _05-globals_simulator.c: 05-globals.c 03-args.xml
-       $(GRAS_STUB_GENERATOR) 05-globals 03-args.xml >/dev/null
-
-clean::
-       if [ -e 05-globals.mk ] ; then make -f 05-globals.mk clean; fi
-       rm -f _05-globals_client.c _05-globals_server.c _05-globals_simulator.c 05-globals.trace 05-globals.mk
-
-# Lesson 6: logs
-########################################
-
-06-logs.output: 06-logs_client 06-logs_server 06-logs_simulator \
-        06-logs.output.fmt 06-logs.output.fmt-bt 06-logs.output.verbose 06-logs.output.error
-       echo '$$ ./test_server 12345 & ./test_client 127.0.0.1 12345'  > $@ 
-       ./06-logs_server 12345                             2>&1 |sed s/06-logs/test/  >> $@ 2>&1&
-       ./06-logs_client 127.0.0.1 12345                   2>&1 |sed s/06-logs/test/  >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml'              >> $@
-       ./06-logs_simulator gtut-platform.xml 03-args.xml   2>&1 |sed s/06-logs/test/  >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-       killall 06-logs_server 06-logs_client 2>/dev/null || true
-
-06-logs.output.fmt: 06-logs_client 06-logs_server 06-logs_simulator 
-       echo '$$ ./test_server 12345 --log=test.fmt:%m%n & ./test_client 127.0.0.1 12345 --log=test.fmt:%m%n'  > $@
-       ./06-logs_server 12345  --log=test.fmt:%m%nn          2>&1 |sed s/06-logs/test/  >> $@ 2>&1&
-       ./06-logs_client 127.0.0.1 12345 --log=test.fmt:%m%n 2>&1 |sed s/06-logs/test/  >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml --log=test.fmt:%m%n'              >> $@
-       ./06-logs_simulator gtut-platform.xml 03-args.xml  --log=test.fmt:%m%n 2>&1 |sed s/06-logs/test/  >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-       killall 06-logs_server 06-logs_client 2>/dev/null || true
-
-06-logs.output.fmt-bt: 06-logs_client 06-logs_server 06-logs_simulator 
-       echo '$$ ./test_server 12345 --log=test.fmt:"[%r] %m%n%b%n%n" & ./test_client 127.0.0.1 12345 --log=test.fmt:"[%r] %m%n%b%n%n"'  > $@
-       ./06-logs_server 12345  --log=test.fmt:[%r]%m%n%b%n%n          2>&1 |sed s/06-logs/test/  >> $@ 2>&1&
-       ./06-logs_client 127.0.0.1 12345 --log=test.fmt:[%r]%m%n%b%n%n 2>&1 |sed s/06-logs/test/  >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml --log=test.fmt:[%r]%m%n%b%n%n'              >> $@
-       ./06-logs_simulator gtut-platform.xml 03-args.xml  --log=test.fmt:[%r]%m%n%b%n%n 2>&1 |sed s/06-logs/test/  >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-       killall 06-logs_server 06-logs_client 2>/dev/null || true
-
-06-logs.output.verbose: 06-logs_client 06-logs_server 06-logs_simulator
-       echo '$$ ./test_server 12345 --log=test.thres:verbose & ./test_client 127.0.0.1 12345 --log=test.thres:verbose'  > $@
-       ./06-logs_server 12345 --log=test.thres:verbose                            2>&1 |sed s/06-logs/test/  >> $@ 2>&1&
-       ./06-logs_client 127.0.0.1 12345 --log=test.thres:verbose                  2>&1 |sed s/06-logs/test/  >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml --log=test.thres:verbose'              >> $@
-       ./06-logs_simulator gtut-platform.xml 03-args.xml --log=test.thres:verbose  2>&1 |sed s/06-logs/test/  >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-       killall 06-logs_server 06-logs_client 2>/dev/null || true
-
-06-logs.output.error: 06-logs_client 06-logs_server 06-logs_simulator
-       echo '$$ ./test_server 12345 --log=root.thres:error & ./test_client 127.0.0.1 12345 --log=root.thres:error'  > $@
-       ./06-logs_server 12345 --log=root.thres:error                            2>&1 |sed s/06-logs/test/  >> $@ 2>&1&
-       ./06-logs_client 127.0.0.1 12345 --log=root.thres:error                  2>&1 |sed s/06-logs/test/  >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml --log=root.thres:error'              >> $@
-       ./06-logs_simulator gtut-platform.xml 03-args.xml --log=root.thres:error  2>&1 |sed s/06-logs/test/  >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-       killall 06-logs_server 06-logs_client 2>/dev/null || true
-
-
-06-logs_client 06-logs_server 06-logs_simulator: _06-logs_client.c _06-logs_server.c _06-logs_simulator.c
-       make -f 06-logs.mk
-
-_06-logs_client.c _06-logs_server.c _06-logs_simulator.c: 06-logs.c 03-args.xml
-       $(GRAS_STUB_GENERATOR) 06-logs 03-args.xml >/dev/null
-
-clean::
-       if [ -e 06-logs.mk ] ; then make -f 06-logs.mk clean; fi
-       rm -f _06-logs_client.c _06-logs_server.c _06-logs_simulator.c 06-logs.trace 06-logs.mk
-
-
-# Lesson 7: timers
-########################################
-
-07-timers.output: 07-timers_client 07-timers_server 07-timers_simulator
-       echo '$$ ./test_server 12345 & ./test_client 127.0.0.1 12345'  > $@ 
-       ./07-timers_server 12345                             2>&1 |sed s/07-timers/test/  >> $@ 2>&1&
-       ./07-timers_client 127.0.0.1 12345                   2>&1 |sed s/07-timers/test/  >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml'              >> $@
-       ./07-timers_simulator gtut-platform.xml 03-args.xml   2>&1 |sed s/07-timers/test/  >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-       killall 07-timers_server 07-timers_client 2>/dev/null || true
-
-07-timers_client 07-timers_server 07-timers_simulator: _07-timers_client.c _07-timers_server.c _07-timers_simulator.c
-       make -f 07-timers.mk
-
-_07-timers_client.c _07-timers_server.c _07-timers_simulator.c: 07-timers.c 03-args.xml
-       $(GRAS_STUB_GENERATOR) 07-timers 03-args.xml >/dev/null
-
-clean::
-       if [ -e 07-timers.mk ] ; then make -f 07-timers.mk clean; fi
-       rm -f _07-timers_client.c _07-timers_server.c _07-timers_simulator.c 07-timers.trace 07-timers.mk
-
-# Lesson 8: exceptions
-########################################
-
-08-exceptions.output: 08-exceptions_client 08-exceptions_server 08-exceptions_simulator
-       echo '$$ ./test_server & ./test_client 127.0.0.1 '             > $@
-       ./08-exceptions_server                                   2>&1 |sed s/08-exceptions/test/  >> $@ 2>&1&
-       ./08-exceptions_client 127.0.0.1                         2>&1 |sed s/08-exceptions/test/  >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_server --cheat & ./test_client 127.0.0.1 '    >> $@
-       ./08-exceptions_server --cheat                           2>&1 |sed s/08-exceptions/test/  >> $@ 2>&1&
-       ./08-exceptions_client 127.0.0.1                         2>&1 |sed s/08-exceptions/test/  >> $@ 2>&1
-       sleep 1
-       echo '$$ killall test_server'                                 >> $@
-       killall 08-exceptions_server 08-exceptions_client 2>/dev/null || true
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml'              >> $@
-       ./08-exceptions_simulator gtut-platform.xml 03-args.xml   2>&1 |sed s/08-exceptions/test/  >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-
-08-exceptions_client 08-exceptions_server 08-exceptions_simulator: _08-exceptions_client.c _08-exceptions_server.c _08-exceptions_simulator.c
-       make -f 08-exceptions.mk
-
-_08-exceptions_client.c _08-exceptions_server.c _08-exceptions_simulator.c: 08-exceptions.c 03-args.xml
-       $(GRAS_STUB_GENERATOR) 08-exceptions 03-args.xml >/dev/null
-
-clean::
-       if [ -e 08-exceptions.mk ] ; then make -f 08-exceptions.mk clean; fi
-       rm -f _08-exceptions_client.c _08-exceptions_server.c _08-exceptions_simulator.c 08-exceptions.trace 08-exceptions.mk 08-exceptions.output
-
-# Lesson 9: simple data exchange
-########################################
-09-datatype-dump: 09-datatype-dump.c
-       gcc -I$(GRAS_ROOT)/include -lgras -L$(GRAS_ROOT)/lib $^ -o $@ 
-
-clean::
-       rm -f 09-datatype-dump.o 09-datatype-dump
-
-09-simpledata.output: 09-simpledata_client 09-simpledata_server 09-simpledata_simulator
-       echo '$$ ./test_server 12345 & ./test_client 127.0.0.1 12345'  > $@ 
-       ./09-simpledata_server 12345                             2>&1 |sed s/09-simpledata/test/  >> $@ 2>&1&
-       ./09-simpledata_client 127.0.0.1 12345                   2>&1 |sed s/09-simpledata/test/  >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml'              >> $@
-       ./09-simpledata_simulator gtut-platform.xml 03-args.xml   2>&1 |sed s/09-simpledata/test/  >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-       killall 09-simpledata_server 09-simpledata_client 2>/dev/null || true
-
-09-simpledata_client 09-simpledata_server 09-simpledata_simulator: _09-simpledata_client.c _09-simpledata_server.c _09-simpledata_simulator.c
-       make -f 09-simpledata.mk
-
-_09-simpledata_client.c _09-simpledata_server.c _09-simpledata_simulator.c: 09-simpledata.c 03-args.xml
-       $(GRAS_STUB_GENERATOR) 09-simpledata 03-args.xml >/dev/null
-
-clean::
-       if [ -e 09-simpledata.mk ] ; then make -f 09-simpledata.mk clean; fi
-       rm -f _09-simpledata_client.c _09-simpledata_server.c _09-simpledata_simulator.c 09-simpledata.trace 09-simpledata.mk
-
-# Lesson 10: RPC
-########################################
-10-rpc.output: 10-rpc_client 10-rpc_server 10-rpc_simulator
-       echo '$$ ./test_server & ./test_client 127.0.0.1 '             > $@
-       ./10-rpc_server 12345                             2>&1 |sed s/10-rpc/test/  >> $@ 2>&1&
-       ./10-rpc_client 127.0.0.1 12345                   2>&1 |sed s/10-rpc/test/  >> $@ 2>&1
-       sleep 1
-       echo '$$'                                                     >> $@
-       echo '$$ killall test_server'                                 >> $@
-       killall 10-rpc_server 10-rpc_client 2>/dev/null || true
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform.xml test.xml'              >> $@
-       ./10-rpc_simulator gtut-platform.xml 03-args.xml   2>&1 |sed s/10-rpc/test/  >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-
-10-rpc_client 10-rpc_server 10-rpc_simulator: _10-rpc_client.c _10-rpc_server.c _10-rpc_simulator.c
-       make -f 10-rpc.mk
-
-_10-rpc_client.c _10-rpc_server.c _10-rpc_simulator.c: 10-rpc.c 03-args.xml
-       $(GRAS_STUB_GENERATOR) 10-rpc 03-args.xml >/dev/null
-
-clean::
-       if [ -e 10-rpc.mk ] ; then make -f 10-rpc.mk clean; fi
-       rm -f _10-rpc_client.c _10-rpc_server.c _10-rpc_simulator.c 10-rpc.trace 10-rpc.mk
-
-
-# Lesson 11: Explicit wait
-########################################
-11-explicitwait.output: 11-explicitwait_client 11-explicitwait_server 11-explicitwait_simulator
-       (echo '$$ ./test_server & ./test_client 127.0.0.1 12345 & ./test_client 127.0.0.1 12345 '; \
-        ./11-explicitwait_client 127.0.0.1 12345            & \
-        ./11-explicitwait_client 127.0.0.1 12345            & \
-        ./11-explicitwait_server 12345                        \
-       ) 2>&1 | sed s/11-explicitwait/test/ > $@
-       sleep 1
-       echo '$$'                                                     >> $@
-       killall 11-explicitwait_server 11-explicitwait_client 2>/dev/null || true
-       echo '$$'                                                     >> $@
-       echo '$$ ./test_simulator platform-3nodes.xml test.xml'              >> $@
-       ./11-explicitwait_simulator gtut-platform-3nodes.xml 11-explicitwait.xml   2>&1 |sed s/11-explicitwait/test/  >> $@ 2>&1
-       echo '$$'                                                     >> $@ 
-
-11-explicitwait_client 11-explicitwait_server 11-explicitwait_simulator: _11-explicitwait_client.c _11-explicitwait_server.c _11-explicitwait_simulator.c
-       make -f 11-explicitwait.mk
-
-_11-explicitwait_client.c _11-explicitwait_server.c _11-explicitwait_simulator.c: 11-explicitwait.c 03-args.xml
-       $(GRAS_STUB_GENERATOR) 11-explicitwait 03-args.xml >/dev/null
-
-clean::
-       if [ -e 11-explicitwait.mk ] ; then make -f 11-explicitwait.mk clean; fi
-       rm -f _11-explicitwait_client.c _11-explicitwait_server.c _11-explicitwait_simulator.c 11-explicitwait.trace 11-explicitwait.mk
-
-
diff --git a/doc/gtut-files/README b/doc/gtut-files/README
deleted file mode 100644 (file)
index df4eff4..0000000
+++ /dev/null
@@ -1,4 +0,0 @@
-You shouldn't muck with these files unless you know what you are doing. They
-are used for the GRAS tutorial.
-
-Mt.
diff --git a/doc/gtut-files/gtut-howto-design.doc b/doc/gtut-files/gtut-howto-design.doc
deleted file mode 100644 (file)
index 715d850..0000000
+++ /dev/null
@@ -1,179 +0,0 @@
-/** @defgroup GRAS_howto_design HOWTO design a GRAS application
-    @ingroup GRAS_howto HOWTOs
-
-This page tries to give some hints on how to design a GRAS application. The
-provided model and functionnalities are somehow different from the other
-existing solutions (nammly, MPI), and this page tries to give you the feeling
-of the GRAS philosophy. You may also want to (re)read the \ref GRAS_tut_intro.
-
-As an example, you may have a look at \ref GRAS_tut_tour_explicitwait_use,
-which somehow follows the guidelines given here.
-
-\section GRAS_howto_design_toc Table of content
-  - \ref GRAS_howto_design_what
-  - \ref GRAS_howto_design_design
-    - \ref GRAS_howto_design_design_api
-    - \ref GRAS_howto_design_design_processes
-    - \ref GRAS_howto_design_design_protocol
-      - \ref GRAS_howto_design_design_protocol_msg
-      - \ref GRAS_howto_design_design_protocol_cb
-  - \ref GRAS_howto_design_implem
-    - \ref GRAS_howto_design_implem_cb
-    - \ref GRAS_howto_design_implem_api
-    - \ref GRAS_howto_design_implem_init
-  - \ref GRAS_howto_design_test
-    - \ref GRAS_howto_design_test_sim
-    - \ref GRAS_howto_design_test_local
-    - \ref GRAS_howto_design_test_dist
-
-\section GRAS_howto_design_what What is a GRAS application
-
-As explained in \ref GRAS_tut_intro, you should see a GRAS application as a
-distributed service. There is two main parts:
- - a user API, composed of regular functions offering services to the users
- - a set of nodes (or processes, or agents, name them as you want)
-   collaborating and exchanging messages to achieve the requested service on
-   behalf of the user.
-
-It is naturally possible to not follow this split, and let the users of your
-service directly sending messages by themselves. Nevertheless, this
-encapsulation is a good thing because distributed computing is a bit hard to
-achieve. You may thus not want to force your users to go into this tricky
-part. Instead, shield them with a regular C API.
-
-If you are the only user of the code you develop, I'd advice you to still
-follow this approach. But do as you prefer, of course.
-
-\section GRAS_howto_design_design The design phase
-
-\subsection GRAS_howto_design_design_api Specify the user API
-
-These will be the entry points of your system, and you should think twice
-about their syntax and semantic.
-
-\subsection GRAS_howto_design_design_processes Identify the types of processes in your application
-
-Note that we are not speaking about the amount of processes in your
-application, but rather on the type of processes. The amount of distinct
-roles.
-
-Depending on your application, there may be only one type (for example in a
-peer-to-peer system), two types of processes (for example in a client/server
-system), three types of processes (for example if you add a forwarder to a
-client/server system), or maybe much more.
-
-\subsection GRAS_howto_design_design_protocol Design an application-level protocol
-
-During this phase, you should try to sketch your application before
-implementing it.  You should sketch temporal execution of the application. I
-personnaly prefer to do so graphically on a blackboard, drawing comic strips
-of the several steps of the algorithm under specific conditions. Ask
-yourself questions as "What gets exchanged between who when the user request
-this?", "How to react when this condition occures?" and "What is the initial
-state of the system?"
-
-Here are some important points to identify in your future application during
-the design phase:
-
-\subsubsection GRAS_howto_design_design_protocol_msg Message types
-
-The most important point to design a GRAS protocol is to identify the
-different type of messages that can be exchanged in your system, and the
-datatype of their payload. Doing so, remember that GRAS messages are
-strongly typed. They are formed by a so-called message type (identified by
-its name) and a type description describing what kind of data you can
-include in the message. The message type is a qualitative information
-"someone asked you to run that function" while the payload is the
-quantitative information (the arguments to the function).
-
-A rule of thumb: <b>A given message type have only one semantic meaning, and
-one syntaxic payload datatype</b>. If you don't do so, you have a problem.
-
-   - If the same message type may have two semantic value depending on some
-     fields of the payload, I'd say that you used MPI too much before. You
-     should use the full power of the GRAS messaging functions by using
-     several message types. It will simplify your code and yield better
-     performance.
-
-   - You shouldn't have a given message type with differing payload
-     datatypes. It is possible to do so (using gras_datadesc_ref_generic()),
-     but it's quite painful, and is rarely what you really want. Are you
-     sure you don't want to split these messages in two separate types?
-
-\subsubsection GRAS_howto_design_design_protocol_cb Message callbacks
-
-Also sketch what your processes should do when they get the given message.
-These action will constitute the message callbacks during the
-implementation. But you should first go through a design phase of the
-application level-protocol, were these action remain simplistic. Also
-identify the process-wide globals needed to write the callbacks (even if it
-can be later).
-
-
-\section GRAS_howto_design_implem The implementation phase
-
-\subsection GRAS_howto_design_implem_cb Write your callbacks
-
-Most of the time, you will find tons of specific cases you didn't thought
-about in the design phase, and going from a code sketch to an actual
-implementation is often quite difficult.
-
-You will probably need some process-wide globals to store some state of your
-processes. See \ref GRAS_tut_tour_globals on need.
-
-\subsection GRAS_howto_design_implem_api Implement your user-API
-
-If your protocol was wisely designed, writting the user API should be quite
-easy.
-
-\subsection GRAS_howto_design_implem_init Implement the initialization code
-
-You must write some initialization code for all the process kinds of your
-application.
-
-You may want to turn your code into a clean GRAS library by using the adhoc
-mecanism, but unfortunately, it's not documented yet. Worse, there is two
-such systems for now, one of them being deprecated. Check the \ref AMOK_pm
-implementation to see how to use the new system. Naturally, this is only
-optional.
-
-\section GRAS_howto_design_test The test phase
-
-Testing software is important to check that it works. But in a distributed
-setting, this is mandatory.
-
-\subsection GRAS_howto_design_test_sim Test it on the simulator
-
-In addition to all the good old bugs you find in a classical C program
-(memory corruption, logical errors, etc), distributed computing introduce
-subtil ways to get things wrong. Actually, this is why I wrote GRAS: to get
-able to test my code on simulator before using it in distributed settings.
-
-The simulator is a nicely controled environment. You can rerun the same code
-in the exact same condition as often as you want to reproduce a bug. You can
-run the simulator in a debugger such as valgrind or gdb to debug all
-processes at once. You can cheat and have global variables (to check global
-invariants or such). You can test your code on platform you don't have
-access to in the real life, or in condition which almost never occur (such
-as having 80% of the nodes stopping at the same time).
-
-Use all these possibilities, and test your code throughfully in the
-simulator. You may find it boring, but when you'll go to the next steps,
-you'll dream of going back into the comfort of the simulator.
-
-\subsection GRAS_howto_design_test_local Test it locally
-
-Once it works in the simulator, test it in real-life, but will all processes
-on the same host. Even if the GRAS API is made to make the simulator as
-close to the real life as possible, you often discover new and exciting bugs
-when going outside of the simulator. Fix'em all before going further.
-
-If you find you've found a discrepency between both implementation of GRAS,
-please drop us a mail. That would be a bug.
-
-\subsection GRAS_howto_design_test_dist Test it in a distributed setting
-
-You are now ready for the big jump...
-
-
-*/
diff --git a/doc/gtut-files/gtut-howto.doc b/doc/gtut-files/gtut-howto.doc
deleted file mode 100644 (file)
index f849375..0000000
+++ /dev/null
@@ -1,11 +0,0 @@
-/** @defgroup GRAS_howto HOWTOs
-    @ingroup GRAS_tut
-
-This page tries to explain how to use the GRAS framework. It does not focus
-on specific functionalities (which are detailed in the initiatic tour), but
-rather on global aspects. Here is the list of existing howtos for now:
-
- - \ref GRAS_howto_design
- - I plan to write a document on how to debug a GRAS application, one day.
-
-*/
diff --git a/doc/gtut-files/gtut-introduction.doc b/doc/gtut-files/gtut-introduction.doc
deleted file mode 100644 (file)
index 6659aaf..0000000
+++ /dev/null
@@ -1,403 +0,0 @@
-/** @defgroup GRAS_tut_intro What is GRAS
-    @ingroup GRAS_tut
-
-\htmlinclude .gtut-introduction.doc.toc
-
-\section GRAS_tut_intro_toc What will you find here
-
- - The section \ref GRAS_tut_intro_what explains what the GRAS framework and how it
-   relates to other existing solutions.
- - The section \ref GRAS_tut_intro_model presents somehow formaly the programmation
-   model used in GRAS.
-
-\section GRAS_tut_intro_further Further readings
-
-After this page, you may find these one interesting:
-\ref GRAS_howto_design. If you're new to GRAS, you may want to read the
-initiatic tour first, begining with \ref GRAS_tut_tour_install or
-\ref GRAS_tut_tour_setup.
-
-<hr>
-
-\section GRAS_tut_intro_what What is GRAS
-
-GRAS is a framework to implement and study distributed algorithms. It
-provides a simple communication API to allow several processes to
-interoperate through the exchange of messages. This is quite classical, and
-GRAS differs from the other existing messaging API by several points:
-
-  - \ref GRAS_tut_intro_what_2ways
-  - \ref GRAS_tut_intro_what_dist
-  - \ref GRAS_tut_intro_what_grid
-  - \ref GRAS_tut_intro_what_target
-  - \ref GRAS_tut_intro_what_simple
-
-We now detail each of these points.
-
-\subsection GRAS_tut_intro_what_2ways GRAS allows you to run both in simulation mode and on real platforms
-
-We wrote two implementations of the interface: the first one is built on top
-of the SimGrid simulator, allowing you to run your application in a
-controled environment, which reveals precious to debug and study algorithms.
-Everyone who tried to run even simple tests on more than 100 real machines
-will consider a simulator as a nirvana.
-
-The experiments can be reproduced in the exact same conditions (which is
-somehow hard in real settings), allowing for example to reproduce a bug as
-many times as you want while debugging. You can also test your algorithm
-under experimental conditions which you couldn't achieve on a real platform
-(like a network topology and/or size you do don't have access to). Under
-some conditions, SimGrid simulations are also much faster than real
-executions, allowing you to run more experiments in less time.
-
-Once you assessed the quality of your algorithm in the simulator, you can
-deploy it on real platforms using the second implementation of the library.
-Usually, taking an algorithm out of a simulator implies an almost complete
-rewrite. There is no need to modify your program for this in GRAS. You don't
-even need to recompile it, but simply to relink your program it against the
-right library.
-
-GRAS applications running on real hardware deliver high performance.
-The sequential parts of your code are not mediated by GRAS or slowed down
-anyhow. The communications use advanced data exchange and conversion
-mecanism ensuring that you are likely to get performance at least comparable
-to other communication solutions (FIXME: cite the paper once it gets
-accepted).
-
-GRAS applications are portable on several operating systems (Linux, MacOS X,
-Solaris, IRIX, AIX and soon Windows) and several processor architectures
-(x86, amd64, ppc, sparc, etc). Moreover, GRAS processes can interoperate
-efficiently even when deployed on differing material. You can for example
-have a process deployed on ppc/MacOS X interacting transparently with
-another one deployed on alpha/Linux.
-
-The simulation mode of GRAS is called usually SG (for SimGrid) while the in
-situ execution mode is called RL (for Real Life).
-
-\subsection GRAS_tut_intro_what_dist GRAS was designed for distributed computing, not parallel computing
-
-In GRAS, you build your algorithm as a set of independent processes
-interacting through messages. This is the well known MPMD model (multiple
-program, multiple data). It contrasts to the SPMD model (simple program,
-multiple data) and communications solutions such as MPI or PVM, where you
-build an uniq program with conditionnals here and there specifying what each
-processes should do (something like "If I'm process number 0, then send data
-to the others, else get the data sent to me").
-
-None of these models are inherently better than the other, and there is a
-plenty of algorithms betterly expressed in the SPMD paradigm. If your
-program falls into that category, then GRAS may not be the right tool for
-you. We think however that most non-sequential algorithms can be expressed
-gracefully in a MPMD way where some are really difficult to express in a
-SPMD way.
-
-There is no parallelism in GRAS, and it is discouraged to introduce threads
-in GRAS (althrough it should be possible in some months). This is an explict
-choice since threads are so hard to use (see the section \ref
-GRAS_tut_intro_what_simple below). The framework itself do use threads to
-achieve good performances, but I don't want to impose this to users (FIXME:
-actually, GRAS is not multi-threaded yet internally, but I plan to do so
-really soon).
-
-\subsection GRAS_tut_intro_what_grid GRAS was designed for large scale computing
-
-Another difference to the MPI communication libraries is that GRAS was not
-designed for static small-sized platforms such as clusters, but to dynamic
-larger-scale platforms such as grids. That is why GRAS do include static
-membership solutions such as the MPI channels. Support for fault-tolerance
-is also provided through the timeouts on communication primitives and
-through an exception mecanism.
-
-GRAS also comes with a sister library called AMOK containing several usefull
-building block for large scale network aware applications. The most
-proheminent one allows to assess the network availabilities through active
-testing, just like the classical NWS tool in the grid research community. We
-are actively working on a network topology discovery mecanism and a
-distributed locking solution. Some other modules are planned, such as
-reliable broacasting in open environments.
-
-\subsection GRAS_tut_intro_what_target GRAS targets at applicative overlay rather than end-user application
-
-The application class targeted by GRAS is constituted of so called overlays.
-They do not constitute a complete application by themselves, but can be seen
-as a "distributed library", a thing offering offering a service to another
-application through a set of physically distributed entities. An example of
-such overlay could be a monitoring system allowing you to retrieve the
-available bandwidth between two remote hosts. It could be used in a
-network-aware parallel matrix multiplication library assigning more work to
-well interconnected nodes. I wouldn't advice to build a physical or
-biological compututation program on top of GRAS, even if it would be
-possible in theory.
-
-In other words, GRAS is not a grid middleware in the common understanding of
-the world, but rather a tool to constitute the building bricks of such a
-middleware. GRAS is thus a sort of "underware" ;)
-
-\subsection GRAS_tut_intro_what_simple GRAS tries to remain simple to use
-
-A lot of effort was put into the framework so that it remains simple to the
-users. For example, you can exchange structured data (any kind of C data
-structure) just by passing its address, and the framework will create the
-exact same structure on the receiver side.
-
-There is no threads like the pthread ones in GRAS, and it is not planned to
-introduce this in the future. This is an explicit choice since I consider
-multi-threading as too complicated for usual users. There is too much
-non-determinism, too many race conditions, and too few language-level
-constructs to keep yourself from screwing up. This idea is well expressed
-by John Ousterhout in <i>Why Threads Are a Bad Idea (for most purposes)</i>,
-published at USENIX'96. See section \ref GRAS_tut_intro_what_dist for
-platform performance consideration.
-
-For the user code, I plan to allow the co-existance of several "gras
-processes" within the same regular unix process. The communication semantic
-will still be message-oriented, even if implemented using the shared memory
-for efficiency.
-
-Likewise, there is no interuption mecanism in GRAS which could break the
-user code execution flow. When you write a function, you can be absolutely
-sure that nothing will happen between each lines of it. This assumption
-considerably simplify the code written in GRAS. The main use of of
-interruptions in a distributed application is to timeout communications when
-they fail. GRAS communication calls allow to setup a timeout value, and
-handle it internally (see below).
-
-The only interruption mecanism used is constituted by exceptions, just like
-in C++ or Java (but implemented directly in C). They are propagated from the
-point where they are raised to a point where they will be trapped, if any,
-or abort the execution when not trapped. You can still be certain that
-nothing will happen between two lines of your code, but the second line may
-never be executed if the first one raises an exception ;)
-
-This exception mecanism was introduced because without it, user code has to
-be loaded by tons of non-functional code to check whether an operation was
-properly performed or whether you have to pass the error condition to your
-caller.
-
-<hr>
-
-\section GRAS_tut_intro_model The model provided by GRAS
-
-From a more formal point of view, GRAS overlays (=applications) can be seen
-as a set of state machines mainly interacting with messages. Because of the
-distributed setting of overlays, the internal state of each process cannot
-be accessed or modified directly by other processes. Even when it would be
-possible pratically (like in SG), it is forbidden by the model. This makes
-it difficult to gain a complete knowledge on the global system state. This
-global system state can still be defined by agregating the states of each
-processes, but this remains theoretical and impratical because of the
-probable combinatorial explosion.
-
- - \ref GRAS_tut_intro_model_events
- - \ref GRAS_tut_intro_model_commmodel
- - \ref GRAS_tut_intro_model_timing_policy
- - \ref GRAS_tut_intro_model_exception
- - \ref GRAS_tut_intro_model_rpc
-
-\subsection GRAS_tut_intro_model_events Event types
-
-Two main types of events may change the internal state of a given process:
-
- - <b>Incomming messages</b>. Messages are somehow strongly typed: a message
-   type is described by its name (a string), and the C datatype of its
-   payload. Any message of the same type will convey the same datatype, but
-   of course the actual content of the payload may change from message to
-   message of the same type.\n
-   \n
-   Processes may attach <b>callback functions</b> to the arrival of messages
-   of a given type. They describe the action to achieve to handle the
-   messages during the transition associated to this event.\n
-   \n
-   Incoming messages are not handled as soon as they arrive, but only when
-   the process declares to be ready to accept incoming events (using \ref
-   gras_msg_handle or related functions). It ensures that the treatment of a
-   given message won't run in parallel to any other callback, so that
-   process globals (its state) can be accessed and modified without
-   locking.\n
-   \n
-   Messages received when the process is not ready to consume them are
-   queued, and will be processed in order in the subsequent calls to \ref
-   gras_msg_handle.\n
-   \n
-   Processes can also wait explicitely for incoming messages matching some
-   given criterions (using \ref gras_msg_wait). Any messages received before the
-   one matching the criterions will be added to the incoming messages'
-   queue for further use. This may breaks the message delivery order.
-   Moreover, there is no restriction on when this can be done. So, a
-   callback to a given message can consume messages of other types. There is
-   also no restriction on the criterion: you can specify a function in charge
-   of examinating the messages either incoming or already in the queue and
-   decide based on their meta-data (sender and message type) or their actual
-   content whether they match your criterions.\n
-   \n
-   It is even possible to program processes so that they only explicitely
-   wait for messages without using \ref gras_msg_handle to accept messages
-   and start the callbacks associated to them. GRAS thus supports both the
-   pure event-based programming model and the more classical message passing
-   model.\n
-
- - <b>Internal timers</b>. There is two types of timers: delayed actions and
-   repetitive actions. The former happen only once when the delay expires
-   while the second happen regularly each time that a period expires.\n
-   \n
-   Like incoming messages, timer treatments are not prehemptive. Ie, the
-   function attached to a given timer will not start as soon as the period
-   expires, but only when the process declares to be ready to accept
-   incoming events. This also done in the \ref gras_msg_handle function, and
-   expired timers are prioritaire with regard to incoming messages.
-
-Messages are sent using the \ref gras_msg_send function. You should specify
-the receiver, the message type and the actual payload. This operation can
-happen at any time of your program. Message sending is not considered as a
-process state change, but rather as a reaction to an incoming event. It
-changes the state of another process, though. Trying to send messages to
-yourself will deadlock (althrough it may change in the future).
-
-\subsection GRAS_tut_intro_model_commmodel Communication model
-
-Send operations are <b>as synchronous as possible pratically</b>. They block
-the process until the message actually gets delivered to the receiving
-process. An acknoledgment is awaited in SG, and we consider the fact that RL
-does not the same as a bug to be fixed one day. We thus have an <b>1-port model
-in emission</b>. This limitation allows the framework to signal error condition
-to the user code in the section which asked for the transmission, without
-having to rely on an interuption mecanism to signal errors asynchronously.
-This communication model is not completely synchronous in that sense that the
-receiver cannot be sure that the acknoledgment has been delivered (this is the
-classical byzantin generals problem). Pratically, the acknoledgment is so small
-that there is a good probability that the message where delivered. If you need
-more guaranty, you will need to implement better solutions in the user space.
-
-As in SimGrid v3.3, receive operations are done in a separated thread, but they
-are done sequentially by this thread. The model is thus <b>1-port in
-reception</b>, but something like 2-port in general. Moreover, the messages not
-matching the criterion in explicite receive (see for example \ref
-gras_msg_wait) are queued for further use. Thanks to this specific
-thread, the emission and reception are completely decorelated. Ie, the
-main thread can perfectly send a message while the listener is
-receiving something. We thus have a classical <b>1-port model</b>.
-
-Here is a graphical representation of a scenario involving two processes A and
-B.  Both are naturally composed of two threads: the one running user code, and
-the listener in charge of listening incoming messages from the network. Both
-processes also have a queue for the communication between the two threads, even
-if only the queue of process B is depicted in the graph.
-
-The experimental scenario is as follows: <ul>
-
-<li>Process A sends a first message (depicted in red) with gras_msg_send(), do
-    some more computation, and then send another message (depicted in
-    yellow). Then, this process handles any incoming message with
-    gras_msg_handle(). Since no message is already queued in process A at this
-    point, this is a blocking call until the third message (depicted in
-    magenta) arrives from the other process.</li>
-
-<li>On its side, the process B explicitely wait for the second message with
-    gras_msg_wait(), do some computation with it, and then call
-    gras_msg_handle() to handle any incoming message. This will pop the red
-    message from the queue, and start the callback attached to that kind of
-    messages. This callback sends back a new message (depicted in magenta) back
-    to process A.</li>
-</ul>
-
-<img src="gras_comm.png">
-
-This figure is a bit dense, and there is several point to detail here:<ul>
-
-<li>The timings associated to a given data exchange are detailed for the first
-message. The time (1) corresponds to the network latency. That is the time to
-reach the machine on which B is running from the machine running on A. The time
-(2) is mainly given by the network bandwidth. This is the time for all bytes of
-the messages to travel from one machine to the other. Please note that the
-models used by SimGrid are a bit more complicated to keep realistic, as
-explained in <a href="http://www.loria.fr/~quinson/blog/2010/06/28/Tutorial_at_HPCS/">the
-slides of the HPCS'10</a>, but this not that important here. The time (3) is mainly
-found in the SG version and not in RL (and that's a bug). This is the time to
-make sure that message were received on machine B. In real life, some buffering
-at system and network level may give the illusion to machine A that the message
-were already received before it's actually delivered to the listener of machine
-B (this would reduce the time (3)). To circumvent this, machine B should send a
-little acknoledgment message when it's done, but this is not implemented yet.</li>
-
-<li>As you can see on the figure, sending is blocking until the message is
-received by the listener on the other side, but the main thread of the receiver
-side is not involved in this operation. Sender will get released from its send
-even if the main thread of receiver is occuped elsewhere.</li>
-
-<li>Incomming messages not matching the expectations of a gras_msg_wait() (such
-as the red one) are queued for further use. The next message receiving
-operation will explore this queue in order, and if empty, block on the
-network. The order of unexpected messages and subsequent ones is thus preserved
-from the receiver point of view.</li>
-
-<li>gras_msg_wait() and gras_msg_handle() accept timeouts as argument to
-specify how long you are willing to wait at most for incoming messages. These
-were ignored here to not complexify the example any further. It is worth
-mentionning that the send operation cannot be timeouted. The existance of the
-listener should make it useless.</li>
-
-</ul>
-
-\subsection GRAS_tut_intro_model_timing_policy Timing policy
-
-All communication primitives allow 3 timout policies: one can only poll for
-incoming events (using timeout=0), wait endlessly for the communication to
-be performed (using timeout<0) or specify a maximal delay to wait for the
-communication to proceed (using timeout>0, being a number of seconds).
-
-Again, this describes the targeted model. The current implementation does
-not allow to specify a delay for the outgoing communication. In SG, the
-delay is then hardcoded to 60 seconds while outgoing communication wait for
-ever to proceed in RL.
-
-Another timing policy we plan to implement in the future is "adaptative
-timeouts", where the timeout is computed automatically by the framework
-according to performance of previous communications. This was demonstrated
-for example in the NWS tool.
-
-\subsection GRAS_tut_intro_model_exception Error handling through exceptions
-
-As explained in section \ref GRAS_tut_intro_what_simple, any function may
-raise exceptions breaking their execution. No support is provided by the
-framework to ensure that the internal state remains consistent when
-exceptions are raised. Changing this would imply that we are able to
-checkpoint the internal state to provide a transaction service, which seems
-quite difficult to achieve efficiently.
-
-\subsection GRAS_tut_intro_model_rpc RPC messaging
-
-In addition to the one-way messages described above, GRAS supports RPC
-communication. Using this, a client process asks for the execution of a
-callback on a server process. RPC types are close to regular message types:
-they are described by a type (a string), a payload type for the request, but
-in addition, they also have a payload type for the answer from the server to
-the client.
-
-RPC can be either synchronous (the function blocks until an answer is
-received) or asynchronous (you send the request and wait later for the
-anwer). They accept the same timing policies than regular messages.
-
-If the callback raises an exception on the server side, this exception will
-be trapped by the framework on the server side, sent back to the client
-side, and revived on the client side. So, if the client calls a RPC which
-raises an error, it will have to deal with the exception itself. No
-provision is given concerning the state consistency on the server side when
-an exception arise. The <tt>host</tt> fields of the exception structure
-indicates the name of the host on which it was raised.
-
-The callback performing the treatment associated to a RPC can perform any
-kind of communication itself, including RPC. In the case where A calls a RPC
-on B, leading to B calling a RPC on C (ie, A->B->C), if an exception is
-raised on C, it will be forwarded back to A. The <tt>host</tt> field will
-indicate C.
-
-<hr>
-
-\section GRAS_tut_intro_next What's next?
-
-Now that you know what GRAS is and the communication model used, it is time
-to move to the \ref GRAS_tut_tour section. There, you will build
-incrementally a full-featured GRAS application demonstrating most of the
-aspects of the framework.
-
-*/
diff --git a/doc/gtut-files/gtut-main.doc b/doc/gtut-files/gtut-main.doc
deleted file mode 100644 (file)
index c916ece..0000000
+++ /dev/null
@@ -1,50 +0,0 @@
-/**
-@addtogroup GRAS_tut
-
-This section constitutes a tutorial to the GRAS programming environment.
-
- - \ref GRAS_tut_intro :\n
-   This section details what GRAS is, and what are the target application
-   class. It also formalize somehow the communication model used in GRAS.\n
-   If you are new to the system and want to start using the tool as quickly
-   as possible and learn by trying things out instead of reading a lenghty
-   manual, you might want to start from next section directly.
-   - \ref GRAS_tut_intro_what
-   - \ref GRAS_tut_intro_model
-
- - \ref GRAS_tut_tour :\n
-   This section aims at turning new-comers into GRAS power user. It briefly
-   explains how to install the framework and setup your own projects. Then,
-   an example distributed application is builded incrementaly to show the
-   several aspects of the framework.
-   - Part 1: Bases
-     - \ref GRAS_tut_tour_install
-     - \ref GRAS_tut_tour_setup
-   - Part 2: Message passing
-     - \ref GRAS_tut_tour_simpleexchange
-     - \ref GRAS_tut_tour_args
-     - \ref GRAS_tut_tour_callbacks
-     - \ref GRAS_tut_tour_globals
-     - \ref GRAS_tut_tour_logs
-     - \ref GRAS_tut_tour_timers
-     - \ref GRAS_tut_tour_exceptions
-     - \ref GRAS_tut_tour_simpledata
-     - \ref GRAS_tut_tour_rpc
-     - \ref GRAS_tut_tour_explicitwait
-     - \ref GRAS_tut_tour_message_recaping
-   - Part 3: Data description
-     - \ref GRAS_tut_tour_staticstruct
-     - \ref GRAS_tut_tour_pointers
-     - \ref GRAS_tut_tour_dynar
-     - \ref GRAS_tut_tour_manualdatadef
-     - \ref GRAS_tut_tour_exchangecb
-   - Part 4: Advanced topics (TODO)
-
- - \ref GRAS_howto :\n
-   This section contains some self-contained document explaining one
-   aspect of the framework which would be hard to integrate in the
-   suite of lessons composing the tutorial.
-    - \ref GRAS_howto_design
-
-*/
-
diff --git a/doc/gtut-files/gtut-platform-3nodes.xml b/doc/gtut-files/gtut-platform-3nodes.xml
deleted file mode 100644 (file)
index ccc44c5..0000000
+++ /dev/null
@@ -1,23 +0,0 @@
-<?xml version='1.0'?>
- <!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
- <platform version="3">
- <AS  id="AS0"  routing="Full">
-   <host id="Jacquelin" power="137333000"/>
-   <host id="Boivin"    power="98095000"/>
-   <host id="Geoff"     power="42917000"/>
-   
-   <link id="1" bandwidth="3430125"  latency="0.000536941"/>
-   <link id="2" bandwidth="11618875" latency="0.00018998"/>
-   <link id="3" bandwidth="10314625" latency="0.006932556"/>
-     
-   <route src="Jacquelin" dst="Boivin">   <link_ctn id="1"/></route>
-   <route src="Boivin"    dst="Jacquelin"><link_ctn id="1"/></route>
-   <route src="Jacquelin" dst="Geoff">    <link_ctn id="2"/></route>
-   <route src="Geoff"     dst="Jacquelin"><link_ctn id="2"/></route>
-   <route src="Geoff"  dst="Boivin">      <link_ctn id="3"/></route>
-   <route src="Boivin" dst="Geoff">       <link_ctn id="3"/></route>
- </AS>
- </platform>
diff --git a/doc/gtut-files/gtut-platform.xml b/doc/gtut-files/gtut-platform.xml
deleted file mode 100644 (file)
index 7164bbb..0000000
+++ /dev/null
@@ -1,12 +0,0 @@
-<?xml version='1.0'?>
- <!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
- <platform version="3">
- <AS  id="AS0"  routing="Full">
-   <host id="Jacquelin" power="137333000"/>
-   <host id="Boivin" power="98095000"/>
-   <link id="1" bandwidth="3430125" latency="0.000536941"/>
-   <route src="Jacquelin" dst="Boivin"><link_ctn id="1"/></route>
-   <route src="Boivin" dst="Jacquelin"><link_ctn id="1"/></route>
- </AS>
- </platform>
diff --git a/doc/gtut-files/gtut-tour-00-install.doc b/doc/gtut-files/gtut-tour-00-install.doc
deleted file mode 100644 (file)
index 675fc3d..0000000
+++ /dev/null
@@ -1,16 +0,0 @@
-
-/**
-@page GRAS_tut_tour_install Lesson 0: Installing GRAS
-
-Since GRAS is technically part of the SimGrid project, you have to install
-SimGrid to install GRAS. Doing so is explained in the relevant FAQ section
-(\ref install).
-
-Newcommers should install the stable release from the tarball, since the
-snapshots may suffer from (additionnal;) stability issues. Only go for the
-git if you really need features not present in the stable releases yet (or
-if you plan to help us improving the tool, what is always welcomed).
-
-Proceed to \ref GRAS_tut_tour_setup.
-
-*/
diff --git a/doc/gtut-files/gtut-tour-01-bones.doc b/doc/gtut-files/gtut-tour-01-bones.doc
deleted file mode 100644 (file)
index 04963f3..0000000
+++ /dev/null
@@ -1,204 +0,0 @@
-
-/**
-@page GRAS_tut_tour_setup Lesson 1: Setting up your own project
-
-\section GRAS_tut_tour_setup_toc Table of Contents
- - \ref GRAS_tut_tour_setup_C
- - \ref GRAS_tut_tour_setup_plat
- - \ref GRAS_tut_tour_setup_deploy
- - \ref GRAS_tut_tour_setup_glue
- - \ref GRAS_tut_tour_setup_make
- - \ref GRAS_tut_tour_setup_start
-
-<hr>
-
-Any GRAS project should be constituted of at least 3 files, and possibly
-much more.
-
-  - <tt>&lt;project&gt;.c</tt>: A source file providing the source code of your
-    processes.
-
-  - <tt>&lt;platform&gt;.xml</tt>: A platform description file. It describes
-    the virtual platform you want to run your application onto following the
-    SurfXML formatting so that the simulator can parse it. This file is only
-    needed in SG, and you don't need any to run on real platforms (of
-    course). The simplest is to use one of the pre-existing one.
-
-  - <tt>&lt;project&gt;.xml</tt>: A deployment file. It describes which of
-    your processes to start, on which machine and with which arguments.
-
-  - A makefile is often needed, too, even if it's not mandatory.
-
-If we start a project called <tt>test</tt>, we have to write 3 files:
-<tt>test.c</tt>, <tt>platform.xml</tt> and <tt>test.xml</tt>
-
-\section GRAS_tut_tour_setup_C The C source file
-
-Let's look at the C source file first. It should contain one main function
-for each type of processes in your overlay. Let's assume that you want to
-code a simple client/server communication. For this, the source file should
-read as:
-
-\verbatim #include <gras.h>
-
-int client(int argc, char *argv[]) {
-  ...
-}
-
-int server(int argc, char *argv[]) {
-  ...
-}
-\endverbatim
-
-Note that each of the processes's main function have the exact same
-prototype of the classical <tt>main()</tt> function in C.
-
-This is on purpose, each of them can assume this role when running in RL.
-But you shouldn't write a main() function yourself since all processes will
-run as threads within the same regular process in simulation mode. That is
-why the real <tt>main</tt> function of GRAS programs are generated
-automatically. This will be detailled in time (section \ref
-GRAS_tut_tour_setup_glue), but for now just note the similarity between the
-"main" functions you have to write for each processes and a "real main"
-function.
-
-Then, each process must initialize the GRAS framework at the beginning (with
-\ref gras_init) and should finalize it at the end (with \ref gras_exit).
-
-You should pass to \ref gras_init the <tt>argc</tt> and <tt>argv</tt> you
-received in your "main" function so that the users of your application can
-pass some configuration flags to the framework.
-
-It is not enough to have one of the processes initializing the framework
-since in RL, each of them will run on a different host. If you use some AMOK
-modules, you have to initialize them in each process too.
-
-The source file then reads: \include 01-bones.c
-
-That's it. You have a working GRAS application with two processes. They
-don't do anything useful, but that's a beginning. Let's see how to bring
-them to life.
-
-\section GRAS_tut_tour_setup_plat The platform file
-
-The platform file is used by the simulator to know about the existing hosts
-and their interactions. Its exact syntax is at the same time very simple and
-a bit beyond the topic of this document. Here is a very simple example
-describin two hosts named <i>Jacquelin</i> and <i>Boivin</i> and how they
-are interconnected.
-
-\include gtut-platform.xml
-
-At this point, you should not try to write your own platform file, but use
-one of the existing ones. There is a few of them in the examples/msg
-directory of the project. The only information we need from those files are
-the names of the existing hosts. It will be mandatory to write the
-deployment file.
-
-\section GRAS_tut_tour_setup_deploy The deployment file
-
-This file explains which of your processes should be started on the
-different hosts. It is mainly used in simulation. In real life, you will
-have to start your processes manually (see below). We we dream of a system
-able to apply a deployment file in real life and TakTuk may be the right
-tool for this, but this is still to be done.
-
-Here is an example of such file, describing that a <tt>server</tt> process
-must be started onto the <tt>Jacquelin</tt> host and a <tt>client</tt>
-process must be started on the <tt>Boivin</tt> host.
-
-\include test.xml
-
-Actually, you should write such a file also if you only plan to use GRAS in
-RL since this file is also used to glue your code to GRAS, as explained in
-the next section.
-
-\section GRAS_tut_tour_setup_glue Glueing things together
-
-As explained above, you shouldn't write any real <tt>main</tt> function
-since its content depends on whether you run in RL ou in SG. Instead, you
-use a tool <tt>gras_stub_generator</tt> to get the proper glue around your
-code generated. If you installed SimGrid in a regular place, this program is
-now in your path. Its source resides in the tools/gras/ directory of the
-archive, if you wonder.
-
-Here is the calling syntax:
-\verbatim gras_stub_generator <project_name> <deployment_file.xml>\endverbatim
-
-It parses the deployment file (called <tt>test.xml</tt> in our example),
-searching for all the kind of processes you have in your project. It
-then generates the following C files:
-
- - a <tt>_&lt;project_name&gt;_&lt;process_kind&gt;.c</tt> file for each process kind you
-   have.\n
-   They are used to launch your project in real life. They
-   contain a main() in charge of initializing the GRAS infrastructure and
-   launching your code afterward.
- - a <tt>_&lt;project_name&gt;_simulator.c</tt> file.\n
-   This file is suited to the simulation mode. It contains a main()
-   function initializing the simulator and launching your project within.
- - a <tt>&lt;project_name&gt;.mk</tt> file.\n
-   This is a makefile to regenerate any files on need. See next section.
-
-In our example, we will thus obtain <tt>_test_server.c</tt>,
-<tt>_test_client.c</tt>, <tt>_test_simulator.c</tt> and <tt>test.mk</tt>.
-
-There is a pitfall: no verification is made on your actual source code, so
-if you have a typo on the process name in the deployment file, the generated
-code will be wrong, and the linker will spit error messages at you. Also
-remember that those names are in fact C function names, so they are
-case-sensitive.
-
-\section GRAS_tut_tour_setup_make A typical Makefile
-
-Now, we want to compile all the source files to build the actual binaries.
-It can be done manually, but it is much more convenient to use a makefile.
-Fortunately, gras_stub_generator generates a makefile for you under the name
-<tt>&lt;project&gt;.mk</tt>. This file is sufficient for now. To compile our test
-application, just type:
-\verbatim make -f test.mk \endverbatim
-
-You may want to rename this file to Makefile so that typing <tt>make</tt>
-without argument becomes sufficient. In any case, do not edit this file
-without renaming it, or your changes will get overwritten at the next glue
-generation.
-
-If you already have a Makefile (or a Makefile.am for automake users), you
-can also add the following chunk at the end of your file:
-\verbatim NAME=your_project_name
- PROCESSES=list of processes type in your project
-
- $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.xml
-        path/to/gras_stub_generator $(NAME) $(NAME)_deployment.xml >/dev/null
-\endverbatim
-
-A simpler solution in our example would be to add:
-\verbatim _test_client.c _test_server.c _test_simulator.c: test.c test.xml
-        path/to/gras_stub_generator test test.xml >/dev/null
-\endverbatim
-
-\section GRAS_tut_tour_setup_start Actually running the processes
-
-There is nothing to know to start your processes in RL. Simply call the
-generated binaries, and that's it. To start the simulation, simply call:
-\verbatim ./<project>_simulator platform.xml deployment.xml\endverbatim
-
-If you have an error message similar to
-\verbatim
-./<project>_simulator: error while loading shared libraries: libsimgrid.so.2: cannot open shared object file: No such file or directory
-\endverbatim
-it simply means that the dynamic linker of you system fails to find
-the simgrid library. The easiest way to solve this is to declare a
-LD_LIBRARY_PATH shell variable pointing to the directory where your
-library lives (that's /opt/simgrid/lib on my machine because I passed
---prefix=/opt/simgrid to the configure script).
-
-Here is an example of execution: \include 01-bones.output
-
-That's it. You are done with this lesson and can now write, build and
-execute GRAS applications as long as they don't do anything ;) Move
-to the next lessons to add some flesh on these bones.
-
-Go to \ref GRAS_tut_tour_simpleexchange
-
-*/
diff --git a/doc/gtut-files/gtut-tour-02-simple.doc b/doc/gtut-files/gtut-tour-02-simple.doc
deleted file mode 100644 (file)
index 16cfee8..0000000
+++ /dev/null
@@ -1,124 +0,0 @@
-
-/**
-@page GRAS_tut_tour_simpleexchange Lesson 2: Exchanging simple messages
-
-\section GRAS_tut_tour_simpleexchange_toc Table of Contents
- - \ref GRAS_tut_tour_simpleexchange_msgtype
- - \ref GRAS_tut_tour_simpleexchange_socks
- - \ref GRAS_tut_tour_simpleexchange_exchange
- - \ref GRAS_tut_tour_simpleexchange_recaping
-
-<hr>
-
-\section GRAS_tut_tour_simpleexchange_msgtype Declaring the messages to be exchanged
-
-We will now see how to exchange messages between hosts. As explained in
-section \ref GRAS_tut_intro_model, every GRAS message is (strongly) typed. A
-message type is described by its name and the datatype of the data it can
-convey. Each process which may exchange a given type of message should
-declare it before sending or receiving it. If the description used by the
-sender doesn't match the one used by the receiver, you'll get into trouble.
-Fortunately, such discrepency will be detected in SG.
-
-We won't convey any payload in this lesson, so we just have to give the name
-of message to declare them:
-\dontinclude 02-simple.c
-\skip gras_msgtype_declare
-\until gras_msgtype_declare
-
-Remember that all processes should declare the message types they use.
-
-\section GRAS_tut_tour_simpleexchange_socks Identifying peers you want to communicate with
-
-Then, you need to specify with who you want to communicate. This is done
-by opening sockets. GRAS sockets are loosely inspirated by the regular BSD
-sockets, but with several simplifications.
-
-If you want to eventually receive messages, you have to open a so-called
-<i>server socket</i>. Actually, any GRAS process should open a server socket
-since it will allows to identify it uniquely in the system. A socket is
-defined by an host name and a port number (just like with BSD sockets).
-
-Since server socket are on the current host, opening a socket to receive
-messages on the port 12345 is as easy as:
-\skip gras_socket_server
-\until gras_socket_server
-
-Hardcoding port numbers that way may lead to difficulties on RL (at least)
-since at most one process can listen on a given port. So, if you can, prefer
-the \ref gras_socket_server_range, which picks a working port from a range
-of value. Of course, if you want your processes to find each others, at
-least one port must be hardcoded in the system. Then, any other processes
-contact the one listening on that port, which acts as a coordinator.
-
-Our client should also open a server socket, but the picked port don't
-matter, so we use:
-\skip gras_socket_server
-\until gras_socket_server
-
-It will select a port between 1024 (ports below 1024 are reserved under
-UNIX) and 10000. You can safely ignore the two last arguments for now and
-pass 0.
-
-So, you now know how to create sockets allowing to receive messages. To send
-messages, you have to create a so-called <i>client socket</i>. For this, use
-\ref gras_socket_client with the hostname and the port of the process you
-want to contact as arguments. Our client should simply do:
-
-\dontinclude 02-simple.c
-\skip socket_client
-\until socket_client
-
-The corresponding server socket must be opened before any client socket can
-connect to it. It is thus safe to add a little delay before creating the
-client socket. But you cannot use the classical sleep() function for this,
-or you will delay the simulator in SG, not your processes. Use \ref
-gras_os_sleep instead.
-
-\section GRAS_tut_tour_simpleexchange_exchange Actually exchanging messages
-
-GRAS offers a plenty of ways to communicate. The simple one is to use \ref
-gras_msg_send on the sender side, and \ref gras_msg_wait on the receiver side.
-
-\ref gras_msg_send expects 3 arguments: the socket on which to send the
-message, the message type (described by its name), and a pointer to the actual content of the
-message. Since we don't have any payload, this becomes:
-
-\dontinclude 02-simple.c
-\skip msg_send
-\until msg_send
-
-\ref gras_msg_wait accepts 4 arguments. The first one is the delay you are
-disposed to wait for messages, while the the type of message you are
-expecting. Then come output arguments. The third argument should be the
-address of a gras_socket_t variable which will indicate who wrote the
-message you received while the last argument is where to put the payload.
-
-Since our server is willing to wait up to 60 seconds for a message, the
-following will do it:
-\dontinclude 02-simple.c
-\skip msg_wait
-\until msg_wait
-
-\section GRAS_tut_tour_simpleexchange_recaping Recaping everything together
-
-Here is the complete code of this example. Note the use of the functions
-\ref xbt_socket_my_port, \ref xbt_socket_peer_name and \ref
-xbt_socket_peer_port to retrieve information about who you are connected to.
-
-\include 02-simple.c
-
-Here is the output of the simulator. Note that \ref xbt_socket_peer_port
-actually returns the port number of the <i>server</i> of the peer. This may
-sound a bit strange to BSD experts, but it is actually really useful: you
-can store this value, and contact your peer afterward passing this number to
-\ref gras_socket_client .
-\include 02-simple.output
-
-Here we are, you now know how to exchange messages between peers. There is
-still a large room for improvement, such as adding payload to messages. But
-there some little things you should know before we speak of payloads.
-
-Go to \ref GRAS_tut_tour_args
-
-*/
diff --git a/doc/gtut-files/gtut-tour-03-args.doc b/doc/gtut-files/gtut-tour-03-args.doc
deleted file mode 100644 (file)
index 3e13e0d..0000000
+++ /dev/null
@@ -1,49 +0,0 @@
-
-/**
-@page GRAS_tut_tour_args Lesson 3: Passing arguments to the processes (in SG)
-
-\section GRAS_tut_tour_args_toc Table of Contents
- - \ref GRAS_tut_tour_args_use
- - \ref GRAS_tut_tour_args_sg
- - \ref GRAS_tut_tour_args_recap
-
-<hr>
-
-The most problematic issue with the code of previous lesson is that it does
-not work in RL since we hardcoded the server hostname in the client code. We
-will thus learn you how to pass arguments to your processes to overcome this
-situation.
-
-\section GRAS_tut_tour_args_use Using command line arguments from user code
-
-In RL, the situation is quite simple: we just have to use the command line
-arguments as we would do in a usual C program. In the server, only change
-concern the opennong of the master socket:
-\dontinclude 03-args.c
-\skip gras_socket_server
-\until gras_socket_server
-
-In the client, we only need to change the way we open the client socket:
-\skip gras_socket_client
-\until gras_socket_client
-
-The rest of the program remains inchanged.
-
-\section GRAS_tut_tour_args_sg Passing command line arguments in deployment files
-
-At this point, the problem is to pass arguments to the processes in SG.
-Fortunately, it is quite simple. You just have to edit your deployment file
-so that it reads: \include 03-args.xml
-The syntax should be self-explanatory at this point.
-
-\section GRAS_tut_tour_args_recap Recaping everything together
-
-The whole program now reads:
-\include 03-args.c
-
-And here is the output:
-\include 03-args.output
-
-Go to \ref GRAS_tut_tour_callbacks
-
-*/
diff --git a/doc/gtut-files/gtut-tour-04-callback.doc b/doc/gtut-files/gtut-tour-04-callback.doc
deleted file mode 100644 (file)
index c217ff5..0000000
+++ /dev/null
@@ -1,81 +0,0 @@
-
-/**
-@page GRAS_tut_tour_callbacks Lesson 4: Attaching callbacks to messages
-
-\section GRAS_tut_tour_callbacks_toc Table of Contents
- - \ref GRAS_tut_tour_callbacks_declare
- - \ref GRAS_tut_tour_callbacks_attach
- - \ref GRAS_tut_tour_callbacks_handle
- - \ref GRAS_tut_tour_callback_recap
-
-<hr>
-
-Our program is well and good, but if we had to write a longer program,
-explicitely waiting for messages of a given type would not be really
-practical. To add some more dynamism, what we want to do is to attach
-callbacks to the several messages types, and tell GRAS that we are ready to
-deal with new messages. That's what we will do now.
-
-\section GRAS_tut_tour_callbacks_declare Declaring callbacks
-
-First of all, we define the callback we want to attach to the arrival of the
-"hello" message on the server. Its signature is fixed: it accepts two
-arguments of relative types <tt>gras_msg_cb_ctx_t ctx</tt> and <tt>void
-*</tt>. The first one is a working context we should pass to GRAS when
-speaking about the message we are handling while the second is the payload.
-The callback returns an integer being its error code, just like the "main()"
-function. Here is the actual code of our callback:
-
-\dontinclude 04-callback.c
-\skip gras_msg_cb_ctx_t
-\until end_of_callback
-
-\section GRAS_tut_tour_callbacks_attach Attaching callbacks
-
-Then, we have to change the server code to use this callback instead of
-gras_msg_wait. This simply done by a construct like the following:
-
-\skip cb_register
-\until cb_register
-
-\section GRAS_tut_tour_callbacks_handle Handling incoming messages
-
-Once the callback is declared and attached, the server simply has to call
-\ref gras_msg_handle to tell GRAS it's ready to handle for incoming
-messages. The only argument is the maximum delay we are disposed to wait for
-a message. If the delay is negative, the process will block until a message
-arrives. With delay=0, the process just polls for already arrived messages,
-but do not wait at all if none arrived yet. If the delay is greater than 0,
-the process will wait for at most that amount of seconds. If a message
-arrives in the meanwhile, it won't even wait that long.
-
-Sometimes, you want to handle all messages arriving in a given period
-without really knowing how much messages will come (this is often the case
-during the initialization phase of an algorithm). In that case, use \ref
-gras_msg_handleall . It has the same prototype than \ref gras_msg_handle,
-but waits exactly the passed delay, dealing with all the messages arriving
-in the meanwhile.
-
-We have no such needs in our example, so the code simply reads:
-\skip handle
-\until handle
-
-\section GRAS_tut_tour_callback_recap Recaping everything together
-
-The whole program now reads:
-\include 04-callback.c
-
-And here is the output (unchanged wrt previous version):
-\include 04-callback.output
-
-Our little example turns slowly to a quite advanced GRAS program. It entails
-most of the mecanism most program will use.
-
-There is one last thing you should know about callbacks: you can stack them,
-ie attach several callbacks to the same message. GRAS will pass it to the
-lastly attached first, and if the returned error code is not 0, it will pass
-it also to the next one, and so on. I'm not sure there is any sensible use
-of this feature, but it's possible ;)
-
-Go to \ref GRAS_tut_tour_globals
-*/
diff --git a/doc/gtut-files/gtut-tour-05-globals.doc b/doc/gtut-files/gtut-tour-05-globals.doc
deleted file mode 100644 (file)
index da702fd..0000000
+++ /dev/null
@@ -1,112 +0,0 @@
-/**
-@page GRAS_tut_tour_globals Lesson 5: Using globals in processes
-
-\section GRAS_tut_tour_globals_toc Table of Contents
- - \ref GRAS_tut_tour_globals_intro
- - \ref GRAS_tut_tour_globals_use
- - \ref GRAS_tut_tour_callback_pitfall
- - \ref GRAS_tut_tour_callback_recap
-
-<hr>
-
-\section GRAS_tut_tour_globals_intro Introduction
-
-Callbacks are great to express your processes as state machines, but they
-pose another problem: callbacks don't have acces to the variable declared
-within the scope of the process' main function (of course). You should
-however resist to the temptation to declare globals outside of the scope of
-the functions, or you won't be able to use more than one process of each
-type in the simulation. Remember, all gras processes run as thread
-within the same naming space in SG so your globals will be shared between
-the several instances of your process, leading to bad problems.
-
-Instead, you you have to put all globals in a structure, and let GRAS handle
-it with the gras_userdata_* functions (there is only 3 of them ;).
-
-\section GRAS_tut_tour_globals_use Putting globals into action
-
-We will now modify the example to add a "kill" message, and let the server
-loop on incoming messages until it gets such a message. We only need a
-boolean, so the structure is quite simple:
-\dontinclude 05-globals.c
-\skip struct
-\until server_data
-
-Then, we need to create this structure in the process main function. We
-could use either gras_userdata_new() or gras_userdata_set(). The former is an
-helper macro mallocing the space needed by the structure and passing it to
-gras using the latter function. If you go for gras_userdata_set(), you
-should pass it a pointer to your data you want to retrieve afterward.
-
-\dontinclude 05-globals.c
-\skip userdata_new
-\until userdata_new
-
-BEWARE, the gras_userdata_new expects the pointed type, not the
-pointer type. As you can see, in our example, you should pass
-server_data_t to the macro, even if the global variable is later
-defined as being of type server_data_t*.
-
-Once you declared a global that way, retriving this (for example in a
-callback) is really easy:
-\dontinclude 05-globals.c
-\skip userdata_get
-\until userdata_get
-
-We can now write the callback, which simply retrive the globals and change
-the value of the <tt>kileld</tt> field.
-\dontinclude 05-globals.c
-\skip kill_cb
-\until end_of_kill_callback
-
-And we replace the single gras_msg_handle() of the server main function by a
-loop:
-\skip while
-\until }
-
-Please note that in our example, only one process creates a global
-structure. But this is naturally completely ok to have several
-processes creating their globals this way. Each of these globals will
-be separated, so process A cannot access globals defined by process B.
-Maybe this implies that the name "globals" is a bit misleading. It
-should be "process state" or something similar.
-
-\section GRAS_tut_tour_callback_pitfall Common pitfall of globals
-
-There is an error that I do myself every other day using globals in GRAS.
-This is to write something like:
-\verbatim int server(int argc, char *argv[]) {
-  server_data_t globals=gras_user_new(server_data_t);
-  /* other variable definition */
-
-  gras_init(&argc, argv);
-
-  /* rest of the code */
-}\endverbatim
-
-The problem is that you call gras_userdata_new() before gras_init(). Doing so,
-embarass GRAS since it does not have its internal buffer initialized yet,
-and cannot store your data anywhere. That is why doing so triggers an error
-at run time.
-
-Also, as noted above, the gras_userdata_new expects the pointed type,
-not the pointer type. As you can see, in our example, you should pass
-server_data_t to the macro, even if the global variable is later
-defined as being of type server_data_t*.
-
-
-\section GRAS_tut_tour_callback_recap Recaping everything together
-
-The whole program now reads:
-\include 05-globals.c
-
-And here is the output (unchanged wrt previous version):
-\include 05-globals.output
-
-That's it, we're done. We have a server able to handle any number of
-messages, which the client can stop remotely properly. That's already
-something, hu?
-
-Go to \ref GRAS_tut_tour_logs
-
-*/
diff --git a/doc/gtut-files/gtut-tour-06-logs.doc b/doc/gtut-files/gtut-tour-06-logs.doc
deleted file mode 100644 (file)
index f8b72a9..0000000
+++ /dev/null
@@ -1,136 +0,0 @@
-/**
-@page GRAS_tut_tour_logs Lesson 6: Logging informations properly
-
-\section GRAS_tut_tour_logs_toc Table of Contents
- - \ref GRAS_tut_tour_logs_intro
- - \ref GRAS_tut_tour_logs_practice
- - \ref GRAS_tut_tour_logs_recap
- - \ref GRAS_tut_tour_logs_config
-   - \ref GRAS_tut_tour_logs_config_prio
-   - \ref GRAS_tut_tour_logs_config_layout
-
-<hr>
-
-\section GRAS_tut_tour_logs_intro Introduction
-
-Let's have another look at the output of the program we came up with in
-lesson 5:
-\include 05-globals.output
-
-It is a bit difficult to read, isn't it? Indeed, it is hard to identify
-which process printed which line. It would be possible to add [server] in
-any messages comming from the server and do the same for every process
-running. Idealy, we would also add the location at which the message was
-generated (using __FILE__ and __LINE__) to help debuging, as well as a
-timestamping so that we can still reorder the messages in RL when they get
-intermixed (yeah, it happen, and there is not much to do against it).
-At the end, each time we would like to print a little "hello" debugging
-message, we would have to write 3 lines of arguments to fprintf, which is
-not that practical.
-
-That is why there is a support for proper logging in GRAS. Technically
-speaking, it is not part of GRAS but of XBT, which is the toolbox on which
-the whole SimGrid library is built, but that's the same for us.
-
-This logging library follows the spirit of another one called log4j, which
-is more or less the reference in the domain. The original version is for
-Java, as the name implies, and there was reimplementation for Python
-(log4py), C/C++ (log4c) and so on. Since one of the credo of the GRAS
-framework is that we don't want any external dependency to ease the
-deployment in grid settings, we reimplemented a version of our own.
-
-One of the strong idea of log4j is that log events get structured to give
-the user a fine control at run time of what gets displayed and what don't.
-For that, <i>log event</i> are produced into <i>log channels</i> at a given
-<i>log priority</i>. Then, you can select the minimal priority an event
-should have on a given channel to get displayed.
-
-Then, to keep things managable even when the number of channels increase,
-the channels form a tree and properties get inherited from parent channel to
-childs. Have a look at the existing channels in SimGrid: \ref XBT_log_cats.
-You see that for example, the <tt>gras</tt> channel have 5 subchannels (at
-time of writing): <tt>gras_ddt</tt>, <tt>gras_msg</tt>, <tt>gras_timer</tt>,
-<tt>gras_trp</tt> and <tt>gras_virtu</tt>. If you open or close the
-<tt>gras</tt> channel, it automatically affects all those subchannels (and
-their respective subchannels too). Finally, channels are not just open or
-closed, but filter messages below a given priority (as we said). The
-priorities are defined by type #e_xbt_log_priority_t.
-
-That is all you really need to know about the logs before diving into
-practice. If you want more information on that topic, refer to the \ref
-XBT_log section, which contains much more information than this page.
-
-\section GRAS_tut_tour_logs_practice Putting logs into action
-
-Enough with theory, let's change our example so that it uses proper
-loggings. The first thing to do is to add a new channel in the existing
-hierarchy. There is 4 macros to create log channels, depending on the kind
-of channel we want:
-- XBT_LOG_NEW_CATEGORY(MyCat,desc); Create a new root
-- XBT_LOG_NEW_SUBCATEGORY(MyCat, ParentCat,desc); Create a new category being child of the category ParentCat
-- XBT_LOG_NEW_DEFAULT_CATEGORY(MyCat,desc); Like XBT_LOG_NEW_CATEGORY, but the new category is the default one in this file
-- XBT_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, ParentCat,desc); Like XBT_LOG_NEW_SUBCATEGORY, but the new category is the default one in this file
-
-What we want here is a root category (it does not belong to any existing
-channel, for sure), and we want it to be the default one in our file (of
-course, it's the only one).
-\dontinclude 06-logs.c
-\skip XBT_LOG
-\until XBT_LOG
-
-Then, we change any call to fprintf to one of the logging macros. There is a
-plenty of them, called &lt;priority&gt;&lt;nb args&gt;, such as #XBT_DEBUG,
-which produces a debuging log event onto the default category. Here is a
-list of the existing macros: #XBT_DEBUG, #XBT_VERB, #XBT_INFO, #XBT_WARN,
-#XBT_ERROR and #XBT_CRITICAL.
-
-Note also that there is no need to add a '\\n' at the end of your format
-line, it gets automatically added.
-
-\section GRAS_tut_tour_logs_recap Recapping everything together
-
-Once we changed any fprintf of our code to some of these macros, the program
-may read:
-\include 06-logs.c
-
-And the output now looks better:
-\include 06-logs.output
-
-\section GRAS_tut_tour_logs_config The user side: configuring logs at run time
-
-\subsection GRAS_tut_tour_logs_config_prio Choosing what gets displayed
-
-Once we changed our program to use proper logging, it is naturally possible
-to choose at run time what we want to see. For example, if we want more
-details about our code, we should pass <tt>--log=test.thres:verbose</tt>
-on the command line of our programs to change the <tt>thres</tt>old.
-Note that a VERBOSE line appears on client side:
-\include 06-logs.output.verbose
-
-On the contrary, if we want to reduce the amount of logging, we may want to
-do pass <tt>--log=test.thres:error</tt>:
-
-\subsection GRAS_tut_tour_logs_config_layout Choosing how things get displayed
-
-As with SimGrid 3.3, it is also possible to change how each and every
-message get displayed from the command line without even recompiling
-your code. This is done by changing the <tt>fmt</tt> field of the
-category you want to change. The value of this field is somehow
-similar to printf's format strings, with several existing specifiers.
-
-For example, if you just want the message you passed to the macro
-without any decoration about the host which raised it, its pid and
-everything, just pass <tt>--log=test.fmt:%m</tt>:
-\include 06-logs.output.fmt
-
-For debuging purpose, you can even ask to get the backtrace at each
-execution point:
-\include 06-logs.output.fmt-bt
-
-
-Again, you should refer to the \ref XBT_log section for more information on
-how to configure the logs. Or you can proceed with the next lesson, of
-course.
-
-Go to \ref GRAS_tut_tour_timers
-*/
diff --git a/doc/gtut-files/gtut-tour-07-timers.doc b/doc/gtut-files/gtut-tour-07-timers.doc
deleted file mode 100644 (file)
index 7d45e04..0000000
+++ /dev/null
@@ -1,99 +0,0 @@
-/**
-@page GRAS_tut_tour_timers Lesson 7: Using internal timers
-
-\section GRAS_tut_tour_timers_toc Table of Contents
- - \ref GRAS_tut_tour_timers_intro
- - \ref GRAS_tut_tour_timers_use
- - \ref GRAS_tut_tour_timers_recap
-
-<hr>
-
-\section GRAS_tut_tour_timers_intro Introduction
-
-The messaging primitives we saw until now allow the processes to react to
-external events. This is good, but sometimes, you want the same action to be
-done periodically. Think of a system based on a group of processes. If you
-want to give some adaptability to this system, you shouldn't hardcode the
-memberships but have the members send a message to a coordinator to register
-to the system.
-
-This add some dynamism to your system since new members can join at any
-time. To have a process leaving the system, you can imagine an "unregister"
-message symetric to the "register" one. But how will you deal with failures?
-What if a process leaves without being given the ability to inform the
-coordinator?
-
-One solution is to have the members re-register periodically, so that the
-coordinator can detect the processes which didn't do so since a while, and
-dismiss them.
-
-To implement this in GRAS, we need some more functions: gras_timer_repeat()
-allows to specify a periodic action and gras_timer_delay() allows to get an
-action done once a given delay expires. gras_timer_cancel_delay() and
-gras_timer_cancel_repeat() allow to remove already declared timers. Actions
-must be function without argument nor result (<tt>void my_action(void){
-... }</tt>).
-
-It is important to note that timers are not prehemptive. They will not start
-as soon as they are ready. Instead, they get served when you go into
-gras_msg_handle() (and they are served before incoming messages). This is
-because allowing timers to run in parallel to the callbacks would add
-parallelism to the user code, which would have to protect data with mutexes.
-This is a level of complexity I really don't want for user code. If you
-really need several running entities, simply run several processes (see \ref
-GRAS_tut_intro_model for more details).
-
-\section GRAS_tut_tour_timers_use Putting timers into action
-
-We will change the client of our example so that it send an hello message
-every half second to the server. Then we will add a delayed action scheduled
-5 seconds later in charge of stopping every processes. For this to work, we
-first need to add a global to the server too, containing the socket binded
-onto the server (to send messages) and a boolean indicating whether we are
-done or not, just like we did on the server side in \ref
-GRAS_tut_tour_globals. Here is the resulting global structure:
-\dontinclude 07-timers.c
-\skip client_data
-\until client_data_t
-
-Then, we define the repetitive action in charge of sending messages to the
-server:
-
-\skip client_do_hello
-\until end_of_client_do_hello
-
-This timer is installed the following way. You simply tell the action to
-schedule and its periodicity.
-\skip gras_timer_repeat
-\until gras_timer_repeat
-
-Desinstalling this is not harder. You tell the action to unschedule, and the
-periodicity at which it was desinstalled (so that the same action can be
-scheduled at different intervals, and each of them be desinstallable
-separately).
-\dontinclude 07-timers.c
-\skip gras_timer_cancel_repeat
-\until gras_timer_cancel_repeat
-
-Then comes the delayed action in charge of stopping everything, which should
-be self-explanatory at this point. It could be cancelled before its
-expiration using gras_timer_cancel_delay(), which accepts exactly the same
-kind of arguments than gras_timer_cancel_repeat().
-\dontinclude 07-timers.c
-\skip client_do_stop
-\until end_of_client_do_stop
-
-Finally, we should change the client main function to adapt to these
-modifications, as you can see in the recapping below.
-
-\section GRAS_tut_tour_timers_recap Recapping everything together
-
-The program now reads:
-\include 07-timers.c
-
-Which produces the expected output:
-\include 07-timers.output
-
-Go to \ref GRAS_tut_tour_exceptions
-
-*/
diff --git a/doc/gtut-files/gtut-tour-08-exceptions.doc b/doc/gtut-files/gtut-tour-08-exceptions.doc
deleted file mode 100644 (file)
index d330b00..0000000
+++ /dev/null
@@ -1,152 +0,0 @@
-/**
-@page GRAS_tut_tour_exceptions Lesson 8: Handling errors through exceptions
-
-\section GRAS_tut_tour_exceptions_toc Table of Contents
- - \ref GRAS_tut_tour_exceptions_intro
- - \ref GRAS_tut_tour_exceptions_use
- - \ref GRAS_tut_tour_exceptions_recap
-
-<hr>
-
-\section GRAS_tut_tour_exceptions_intro Introduction
-
-Exceptions are a great mecanism to deal with error exception, everyone knows
-that.
-
-Without exceptions, you have to rely on returning a value indicating whether
-the function call were right or not, and check the return values of every
-single function you call. If there is one point in the calling sequence
-where your forgot this check, the chain is broken and caller won't notice
-the issue. In practice, dealing with error without exceptions loads user
-code with *tons* of those stupid checks and you loose your functional code
-in the middle of that miasm.
-
-With them, you simply write your code. If you want to deal with errors (ie,
-you actually know how to react to errors at this point of your code), you
-write a catching block. If you don't, you don't. And exceptions flow through
-from trowing point to catching point without bothering you.
-
-At this point, you may be a bit surprised by the previous paragraphs.
-SimGrid and GRAS are written in C, and everybody knows that there is no
-exception in C but only in C++, Java and such. This is true, exceptions are
-not part of the C language, but this is such a great tool that we
-implemented an exception mecanism as part of the SimGrid library (with
-setjmp and longjmp, for the curious).
-
-Being "home-grown" make our exception mecanic both stronger and weaker at
-the same time. First it is weaker because, well, we are more limitated
-within the library as we are than if we could change the compiler itself to
-add some extra checks here and specific treatment there. But it is also a
-advantage for us, since the exception mecanism is perfectly fitted to the
-distributed settings of GRAS processes. They can easily propagate on the
-net, as we will see in the next lesson (\ref GRAS_tut_tour_rpc) and contain
-information about the host on which they were thrown (#xbt_ex_t) along with
-the thrown point in the source code.
-
-The syntax of XBT exceptions should not sound unfamilliar to most of you.
-You throw them using the #THROW and #THROWF macros. They take 2 arguments:
-an error category (of type #xbt_errcat_t) and an error "value" (an integer;
-pratically, this is often left to 0 in my own code). #THROWF also takes a
-message string as extra argument which is a printf-like format string with
-its own arguments. So, you may have something like the following:
-\verbatim THROWF(system_error, 0, "Cannot connect to %s:%d because of %s", hostname, port, reason);\endverbatim
-
-Then, you simply add a #TRY/#CATCH block around your code:
-\verbatim TRY{
-  /* your code */
-}
-CATCH(e) {
-  /* error handling code */
-} \endverbatim
-
-Another strange thing is that you should actually free the memory allocated
-to the exception with xbt_ex_fres() if you manage to deal with them. There
-is a bit more than this on the picture (#TRY_CLEANUP blocks, for example), and
-you should check the section \ref XBT_ex for more details.
-
-You should be <b>very carfull</b> when using the exceptions. They work great
-when used correctly, but there is a few golden rules you should never break.
-Moreover, the error messages and symptom can get <b>really crude</b> when
-misusing the exceptions.
-
- - <b>Do not move out of a TRY block with a return, a break or any other
-   kind of jump. NEVER. EVER.</b>. This is the most tempting error, and this
-   drives the system nuts. You will probably segfault in the next exception
-   raising, far away from where you incidentally typed <tt>return</tt>
-   (this is because there is some cleanups to do at the end of a TRY block,
-   you cannot just leave it).
- - <b>Play safe with variables modified in the TRY block</b>. You may want
-   to mark them as <tt>volatile</tt>, which is a modifier (just like
-   <tt>const</tt>) indicating that the value of the denoted variable may get
-   changed by external parts of the program during the run. This is the case
-   when your data gets modified by an exception raising function, I guess.
-
-So, as you can see, you don't want to include large sections of your program
-in TRY blocks. If you do so, it's quite sure that one day, you'll do a break
-or a return within this block. And believe me, finding such typos is a real
-pain.
-
-If you are suspecting this kind of error, I made a little script for you:
-check <tt>tools/xbt_exception_checker</tt> from the CVS. Given a set of C
-files, it extracts the TRY blocks and display them on the standard output so
-that you can grep for <tt>return</tt>, <tt>break</tt> and such forbidden
-words.
-
-\section GRAS_tut_tour_exceptions_use Putting exceptions into action
-
-Okay. I hope those little warnings didn't discourage you from using the
-exceptions, because they really are a nice mecanism. We will now change a
-bit our program to take advantage of them. The only issue is that when a
-program run properly, it usually don't raise any exception. We could protect
-the calls we already have with exception handling, but it wouldn't be really
-exciting since we know this code does not throw any exception under the
-condition we use (actually, most of the GRAS functions may throw exception
-on problem).
-
-Instead, we will code a little game between the client and the server. We
-won't tell the client the exact port on which the server listen, and it will
-have to find from itself. For this, it will try to open socket and send the
-kill message to each ports of the search range. If it manage to close the
-socket after sending the message without being interrupted by an exception,
-it can assume that it killed the server and stop searching.
-\dontinclude 08-exceptions.c
-\skip port=3000
-\until end_of_loop
-
-To make the game a bit more fun (and to show you what an exception actually
-look like when it's not catched), we add a potential command line argument
-to the server, asking it to cheat and to not open its port within the search
-range but elsewhere:
-\dontinclude 08-exceptions.c
-\skip strcmp
-\until gras_socket_my_port
-\until }
-
-Then, when the client detects that it didn't manage to find&destroy the
-server, it throws a suicide exception (sorry for the bad jokes):
-\skip if(!found)
-\until THROW
-
-\section GRAS_tut_tour_exceptions_recap Recapping everything together
-
-Here is the output produced by this new program. Note that when the program
-bails out because of an uncatched exception, it displays its backtrace just
-like a JVM would do (ok, it'a a bit cruder than the one of the JVM, but
-anyway). For each function frame of the calling stack, it displays the
-function name and its location in the source files (if it manage to retrieve
-it). Don't be jalous, you can display such stacks wherever you want with
-xbt_backtrace_display() ;)
-
-Unfortunately, this feature is only offered under Linux for now since I have
-no idea of how to retrieve the call stack of the current process under the
-other operating systems. But help is always welcome in this area too ;)
-
-\include 08-exceptions.output
-
-The complete program reads:
-\include 08-exceptions.c
-
-
-Go to \ref GRAS_tut_tour_simpledata
-
-*/
diff --git a/doc/gtut-files/gtut-tour-09-simpledata.doc b/doc/gtut-files/gtut-tour-09-simpledata.doc
deleted file mode 100644 (file)
index 7a39aec..0000000
+++ /dev/null
@@ -1,265 +0,0 @@
-/**
-@page GRAS_tut_tour_simpledata Lesson 9: Exchanging simple data
-
-\section GRAS_tut_tour_simpledata_toc Table of Contents
- - \ref GRAS_tut_tour_simpledata_intro
-   - \ref GRAS_tut_tour_simpledata_intro_conv
-   - \ref GRAS_tut_tour_simpledata_intro_gras
-   - \ref GRAS_tut_tour_simpledata_use
- - \ref GRAS_tut_tour_simpledata_example
- - \ref GRAS_tut_tour_simpledata_recap
-
-<hr>
-
-\section GRAS_tut_tour_simpledata_intro Introduction
-
-Until now, we only exchanged "empty" messages, ie messages with no data
-attached. Simply receiving the message was a sufficient information for the
-receiver to proceed. There is a similarity between them and procedures not
-accepting any argument in the sequential setting. For example, our "kill"
-message can be seen as a distributed version of the <tt>exit()</tt> system
-call, simply stopping the process receiving this call.
-
-Of course, this is not enough for most applications and it is now time to
-see how to attach some arbitrary data to our messages. In the GRAS parlance,
-we will add a <i>payload</i> to the messages. Reusing the similarity between
-message exchanges and procedure calls, we will now add arguments to our
-calls.
-
-Passing arguments in a distributed setting such as GRAS is a bit more
-complicated than when performing a local call.  The messaging layer must be
-aware of the type of data you want to send and be able to actually send them
-remotely, serializing them on sender side and deserializing them on the
-other side. Of course, GRAS can do so for you.
-
-\subsection GRAS_tut_tour_simpledata_intro_conv Data conversion issues on heterogeneous platforms
-
-The platforms targeted by GRAS complicate the data transfers since the
-machines may well be heterogeneous. You may want to exchange data between a
-regular x86 machine (Intel and assimilated) and amd64 machine or even a ppc
-machine (Mac).
-
-The first problem comes from the fact that C datatypes are not always of the
-same size depending on the processor. On 32 bits machines (such as x86 and
-some ppc), they are stored on 4 bytes where they are stored on 8 bytes on 64
-bits machines (such as amd64).
-
-Then, a second problem comes from the fact that datatypes are not
-represented the same way on these architectures. amd64 and x86 are called
-little-endian architectures (as opposed to big-endian architectures like
-ppc) because they store the bytes of a given integer in a right-to-left way.
-For example, the number 16909060 is written Ox01020304 in hexadecimal base.
-On big endian machines, it will be stored as for bytes ordered that way:
-01.02.03.04. On little-endian machines, it will be stored as 04.03.02.01, ie
-bytes are in reverse order.
-
-A third problem comes from the so-called padding bytes. They come from the
-fact that it is for example much more efficient for the processor to load a
-4-bytes long data (such as an float) if it is aligned on a 4-bytes boundary,
-ie if its first byte is placed in a region of the memory which address is a
-multiple of 4. If it is not the case, the bus needs 2 cycles to retrieve the
-data.  That is why the compiler makes sure that any data declared in your
-program are aligned in memory. When manipulating structures, it means that
-the compiler may introduce some "spaces" between your fields to make sure
-that each of them is aligned on the right boundary. Then, the boundaries
-vary according to the aligned data. Most of the time, the alignment for a
-data type is the data size (2 bytes for shorts which are 2-bytes long and so
-on), but not always ;) And this all this was too easy, those values are not
-only processor dependent, but also compiler and OS dependent. For example,
-doubles (eight bytes) are 8-byte aligned on Windows and 4-byte aligned on
-Linux... Let's take an example:
-
-\verbatim struct MixedData{
-   char    data_1;
-   short   data_2;
-   char    data_3;
-   int     data_4;
-};\endverbatim
-
-One would say that the size of this structure should be 8 bytes long on x86
-(1+2+1+4), but in fact, it is 12 bytes long. To ensure that data_2 is
-2-aligned, one unused byte is added between data_1 and data_2 and 3 bytes
-are wasted between data_3 and data_4 to make sure that this integer is
-4-bytes aligned. Those bytes added by the compiler are called padding bytes.
-Some of them may be added at the end of the structure to make sure that the
-total size fulfill some criterions. On ARM machines, any structure size must
-be a multiple of 4, leading a structure containing two chars to be 4 bytes
-long instead of 2.
-
-\subsection GRAS_tut_tour_simpledata_intro_gras Dealing with hardware heterogeneity in GRAS
-
-All this certainly sounds scary and getting the things right can easily turn
-into a nightmare if you want to do so yourself. Lukily, GRAS converts your
-data seamlessly in heterogeneous exchanges. This is not really a revolution
-since most high-level data exchange solution do so. For this, most solutions
-convert any data to be exchanged from the sender representation into their
-own format on the sender side and convert it to the receiver representation
-on the other side. Sun RPC (used in NFS file systems) for example use the
-XDR representation for this.  When exchanging data between homogeneous
-hosts, this is a clear waste of time since no conversion at all is needed,
-but it is easier to implement. To deal with N kind of hardware architecture,
-you only have to implement 2*N conversion schema (from any arch into the
-exchange format, and from the exchange format into any arch).
-
-In GRAS, we prefered performance over ease of implementation, and data won't
-get converted when it's not needed. Instead, data are sent in the sender
-representation and it is then the responsability of the receiver process to
-convert it on need. To deal with N architectures, there is N^2 conversion
-schema (from any arch to any arch). Nevertheless, GRAS known 9 different
-architectures, allowing it to run on almost any existing computer: Linux
-(x86, ia64, amd64, alpha, sparc, hppa and PPC), Solaris (Sparc and x86), Mac
-OSX, IRIX and AIX. The conversion mecanism also work with the Windows
-conventions, but other issues are still to be solved on this arch.
-
-This approach, along with careful optimization, allows GRAS to offer very
-competitive performance. It is faster than CORBA, not speaking from web
-services which suffer badly from their textual data representation (XML).
-
-\subsection GRAS_tut_tour_simpledata_use Actually exchanging data in GRAS messages
-
-As stated above, all this conversion issues are dealed automatically by GRAS
-and there is very few thing you should do yourself to get it working.
-Simply, when you declare a message type with gras_msgtype_declare(), you
-should provide a description of the payload data type as last argument. GRAS
-will serialize the data, send it on the socket, convert it on need and
-deserialize it for you automatically.
-
-That means that any given message type can only convey a payload of a
-predefined type. You cannot have a message type sometimes conveying an
-integer and sometimes conveying a double.  But in practice, this limitation
-is not very hard to live with. Comparing message exchanges to procedure
-calls again, you cannot have the same procedure accepting arbitrary argument
-types. What you have in Java, for example, is several functions of the same
-name accepting differing argument types, which is a bit different. In C, you
-can also trick the limitation by using <tt>void*</tt> arguments. And
-actually, you can do the same kind of tricks in GRAS, but this is really
-premature at this point of the tutorial. It is the subject of \ref
-GRAS_tut_tour_exchangecb.
-
-Another limitation is that you can only convey one argument per message in
-GRAS. We when that way in GRAS mainly because otherwise, gras_msg_send() and
-the like would have to accept a variating number of parameters. It is
-possible in C, but this reveals rather cumbersome since the compiler do not
-check the number of arguments in any way, and the symptom on error is often
-a segfault. Try passing too few parameters to printf with regard to the
-format string if you want an example. Moreover, since you can convey
-structures, it is easy to overcome this limitation: if you want several
-arguments, simply pack them into a structure before doing so.
-
-There is absolutely no limitation on the type of data you can exchange in
-GRAS. If you can build a C representation of your data, you can exchange it
-with GRAS. More precisely, you can exchange scalars, structures,
-enumerations, arrays (both static and dynamic), pointers, and even things
-like chained list of structures. It is even possible to exchange graphs of
-structures containing cycles between members.
-
-Actually, the main difficulty is to describe the data to be exchanged to
-GRAS. This will be addressed in subsequent tutorial lessons, and we will
-focus on exchanging data that GRAS already knows. Here is a list of such
-data:
-
- - char
- - short int
- - int
- - long int
- - long long int
-
-For all these types, there is three variant: signed, unsigned and the
-version where it is not specified. For example, "signed char", "char" and
-"unsigned char" are all GRAS predefined datatype. The use of the unqualified
-variant ("char") is not encouraged since you may gain some trouble
-sometimes. On hppa, chars are unsigned by default where they are signed by
-default on most archs. Use unqualified variant at your own risk ;)
-
- - float
- - double
- - data and function pointers (on some arch, both types are not of the same
-   size)
-
-You also have some more advanced types:
-
- - string (which are null-terminated char*, as usual in the libc)
- - #xbt_ex_t (the exception types in GRAS, which can get automatically exchanged
-   over the network and are thus predefined)
- - #xbt_peer_t (a datatype describing a peer. There is a plenty of situation
-   in which you want to exchange data of this type, so this is also predefined)
-
-\section GRAS_tut_tour_simpledata_example Back to our example
-
-We will now modify our example to add some data to the "hello" and the
-"kill" messages. "hello" will convey a string being displayed in the logs
-while "kill" will convey an double indicating the number of seconds to wait
-before dying.
-
-The first thing is to modify the message declarations to specify that they
-convey a payload. Of course, all nodes have to agree on message definitions,
-and it would be very bad if the sender and the receiver would not agree on
-the payload data type. GRAS checks for such discrepencies in the simulator
-and dies loudly when something goes wrong. But in RL, GRAS do not check for
-such things, and you are likely to get a segfault rather painful to debug.
-To avoid such mistakes, it is a good habit to declare a function common to
-any nodes declaring the message types involved in your application. Most of
-the time, callbacks can't get declared in the same function since they
-differ from node types to node types (the server attach 2 callbacks where
-the client don't attach any). Here is the message declaring function in our
-case:
-
-\dontinclude 09-simpledata.c
-\skip message_declaration(void)
-\until }
-
-It is very similar to what we had previously, we simply retrieve the
-#xbt_datadesc_type_t definitions of double and string and use them as payload
-type of our messages.
-
-The next step is to change our calls to gras_msg_send() to pass the data to
-send. The rule is that you should put the data into a variable and then pass
-the address of this variable. It makes no difference whether the type
-happens to be a pointer (as char*) or a scalar (as double). Just give
-gras_msg_send the address of the variable, it will do the things right.
-
-\skip hello_payload
-\until Gave
-
-Then, we have to retrieve the sent data from the callbacks. The syntax for
-this is a bit crude, but at least it is very systematic so you don't have to
-think too much about this. The <tt>payload</tt> argument of callbacks is
-declared as <tt>void*</tt> and you can consider that it is the address of
-the variable passed during the send. Ok, it got serialized, exchanged over
-the network, converted and deserialized, but really, you can consider that
-it's the exact copy of your variable. So, to retrieve the content, you have
-to cast the <tt>void*</tt> pointer to a pointer on your datatype, and then
-derefence it.
-
-So, it you want to retrieve a double, you have to cast the pointer using
-<tt>(double*)</tt>, and then dereference the obtained pointer by adding a
-star before the cast. This is what we do here:
-
-\dontinclude 09-simpledata.c
-\skip server_kill_cb
-\until delay
-
-Again, it makes no difference whether the type happens to be a pointer or a
-scalar. You simply end up with more stars in the cast for pointers:
-
-\skip server_hello_cb
-\until char**
-
-That's it, you know how to exchange data between nodes. It's really simple
-with GRAS, even if it's a nightmare to do so portably without it...
-
-\section GRAS_tut_tour_simpledata_recap Recapping everything together
-
-The program now reads:
-\include 09-simpledata.c
-
-Which produces the following output:
-\include 09-simpledata.output
-
-Now that you know how to exchange simple data along with messages, you can
-proceed to the last lesson of the message exchanging part (\ref
-GRAS_tut_tour_rpc) or jump to \ref GRAS_tut_tour_staticstruct to learn more
-on data definition and see how to attach more complicated payloads to your
-messages.
-
-*/
diff --git a/doc/gtut-files/gtut-tour-10-rpc.doc b/doc/gtut-files/gtut-tour-10-rpc.doc
deleted file mode 100644 (file)
index 46c962b..0000000
+++ /dev/null
@@ -1,104 +0,0 @@
-/**
-@page GRAS_tut_tour_rpc Lesson 10: Remote Procedure Calling (RPC)
-
-\section GRAS_tut_tour_rpc_toc Table of Contents
- - \ref GRAS_tut_tour_rpc_intro
- - \ref GRAS_tut_tour_rpc_use
-   - \ref GRAS_tut_tour_rpc_use_declare
-   - \ref GRAS_tut_tour_rpc_use_i2a_cb
-   - \ref GRAS_tut_tour_rpc_use_a2i_cb
-   - \ref GRAS_tut_tour_rpc_use_rest
- - \ref GRAS_tut_tour_rpc_recap
-
-<hr>
-
-\section GRAS_tut_tour_rpc_intro Introduction
-
-So far, we saw how to send messages from one host to another, but quite
-often, we need a two-way message exchange: a "client" sends a request to a
-"server", and the server returns a result after doing some sort of
-computation. This design is often refered to as "Remote Procedure Call" or
-RPC for short.
-
-It is naturally possible to build RPC exchanges using only one-way messages,
-as the ones we used in GRAS so far, but it's a bit awkward (specially when
-the server wants to return a value to the client in a remote function call).
-That is why GRAS provide a support for RPC, as we will now detail.
-
-\section GRAS_tut_tour_rpc_use Putting rpc into action
-
-We will build a simple RPC where clients use a remote server to convert
-strings into numbers and vice-versa (ie, changing between "1234" and 1234).
-To achieve its duty, the server will simply use the strtol function in one
-direction. In the other direction, we will use bprintf(). This is a sprintf()
-version allocating the needed room before doing the conversion. Its
-portability is discutable, but SimGrid declares this function when it cannot
-be found on the host architecture, so you can use it peacefully.
-
-\subsection GRAS_tut_tour_rpc_use_declare Declaring the RPC
-
-To declare a RPC message, we should simply use gras_msgtype_declare_rpc().
-Compared to gras_msgtype_declare() that we use to declare one-way messages,
-this function accepts one extra argument: the datatype of the answer
-message. In our example, we accept one string in input, and a long in
-output for the a2i conversion (a=char 2=to i=integer), and the contrary in
-the other direction.
-
-\dontinclude 10-rpc.c
-\skip gras_msgtype_declare_rpc
-\until long
-\until string
-
-\subsection GRAS_tut_tour_rpc_use_i2a_cb Declaring a simple RPC callback: the integer to string conversion
-
-RPC callbacks are very close to "regular" ones. The only difference is that
-they must call gras_msg_rpcreturn() at some point to return their result to
-the caller. This function accepts 3 arguments: First the timeout to use when
-sending back the result (we must use callbacks when doing network
-communication to avoid deadlocks and such issues). The second argument is
-the callback context that the callback got as first argument. It denotes how
-to reach the caller and such. The last argument is a pointer to a variable
-containing the result to pass to the caller.
-
-Having the callee explicitly returning data to the caller allows to free
-data that were allocated to do the job asked by the client, as in this
-example.
-
-\skip server_convert_i2a_cb
-\until end_of_convert_callback
-
-\subsection GRAS_tut_tour_rpc_use_a2i_cb RPC and exceptions: the string to integer conversion
-
-When converting strings into integer, we must deal with the possibility that
-the provided string is not a number. This is done very easily by raising an
-exception in the RPC callback. This exception will get captured by the
-middleware running the callback on the server side, sent accross the network
-to the client side, and revived here. In short, exceptions raised on callee
-side get passed automagically to the caller.
-
-\skip server_convert_a2i_cb
-\until end_of_convert_callback
-
-\subsection GRAS_tut_tour_rpc_use_rest The rest of the story
-
-The rest of the story is not really exciting. The server and the client are
-very classical compared to what we saw so far. We simply have a specific
-message "done" to stop the server when the client is done using it.
-
-This may also be the first time you see the xbt_ex_display() function, which
-allows to display an exception as if it were not catched without killing the
-process.
-
-\section GRAS_tut_tour_rpc_recap Recapping everything together
-
-The program now reads:
-\include 10-rpc.c
-
-Which produces the expected output:
-\include 10-rpc.output
-
-Now, you know how to send messages, attach callbacks and do RPCs. The next
-lesson will learn you the last missing part of the messaging library:
-\ref GRAS_tut_tour_explicitwait
-
-*/
diff --git a/doc/gtut-files/gtut-tour-11-explicitwait.doc b/doc/gtut-files/gtut-tour-11-explicitwait.doc
deleted file mode 100644 (file)
index 3960164..0000000
+++ /dev/null
@@ -1,152 +0,0 @@
-/**
-@page GRAS_tut_tour_explicitwait Lesson 11: Explicitely waiting for messages
-
-\section GRAS_tut_tour_explicitwait_toc Table of Contents
- - \ref GRAS_tut_tour_explicitwait_intro
- - \ref GRAS_tut_tour_explicitwait_use
-   - \ref GRAS_tut_tour_explicitwait_algo
-   - \ref GRAS_tut_tour_explicitwait_code
-     - \ref GRAS_tut_tour_explicitwait_code_msg
-     - \ref GRAS_tut_tour_explicitwait_code_cb
-     - \ref GRAS_tut_tour_explicitwait_code_api
-     - \ref GRAS_tut_tour_explicitwait_code_smain
-     - \ref GRAS_tut_tour_explicitwait_code_cmain
- - \ref GRAS_tut_tour_explicitwait_recap
-
-<hr>
-
-\section GRAS_tut_tour_explicitwait_intro Introduction
-
-The messaging primitive we have seen so far are somehow limited on the
-receiver side. You have to attach a callback to a message type, and then go
-into an infinite loop. Sometimes, you want to block your execution until a
-message of a given type arrives. This often occures when you want to deal
-with synchronization problems.
-
-As an example, we will study a simple centralized algorithm for mutual
-exclusion. In short, when the client wants to enter the critical section
-(CS), it sends a specific message to the server, and waits for the server to
-answer back with another message. While the client is "locked" waiting for
-the message, nothing else should occure for it (no callback or timer should
-be served).
-
-The simplest interface to explicit message waiting allows you to specify the
-message type you are willing to accept (using gras_msg_wait()). But you can
-also specify a list of accepted message types (using gras_msg_wait_or()), or
-even provide your own message filters to decide precisly the kind of message
-you are waiting for (for example depending on message content -- this is
-done using gras_msg_wait_ext()).
-
-Any message received not matching your expectation will be queued for
-further use. Ie, they will be stored in memory and are candidates for the
-next gras_msg_handle() or gras_msg_wait().
-
-\section GRAS_tut_tour_explicitwait_use Example: mutual exclusion with centralized coordinator
-
-\subsection GRAS_tut_tour_explicitwait_algo GRAS modelization of the algorithm
-
-This section naturally provides an example of how to use gras_msg_wait(),
-but it can also be seen as an example of the guidelines provided in
-\ref GRAS_howto_design.
-
-So, here are the caracteristics of our example:
-
-There is two types of processes:
- - several <i>clients</i> which want to enter a critical section
- - a <i>server</i>, which grants clients to enter the CS when no other
-   process is already in it.
-
-There is three kind of messages in the system:
- - <i>request</i> (from clients to server) to ask for the permission to enter the CS
- - <i>release</i> (from clients to server) to express that they exited the CS
- - <i>grant</i> (from server to clients) to allow the given process to enter the CS
-
-The server has 2 callbacks attached:
- - When it gets a <i>request</i>, it checks whether their is already a process in
-   the CS. If yes, it adds the requester into a FIFO list. If not, it sends
-   a <i>grant</i> message to the asking client.
- - When it gets a <i>release</i>, it checks whether there is some waiting
-   processes in the waiting queue. If yes, it dequeues the first one and
-   send a <i>grant</i> message to it. If no, it notes that the CS is free.
-
-The server has two private data (for the callbacks to work):
- - a boolean indicating whether there is a process in the CS already
- - a waiting queue (#xbt_dynar_t is quite natural to code this).
-
-The client interface is composed of two functions:
- - lock(), which tries to get the grant from the server to enter the CS.
-   This is where explicit waiting comes into the game. This function sends a
-   <i>request</i> to the server, and blocks until the server issues a
-   <i>grant</i> back.
- - unlock(), which informs the server that we exited the CS (by sending a
-   <i>release</i> message)
-
-\subsection GRAS_tut_tour_explicitwait_code The code step-by-step
-
-\subsubsection GRAS_tut_tour_explicitwait_code_msg a) Messages declaration
-
-First of all, we should have a function declaring all used messages. As said
-before, this should be in a separate function so that it can be shared
-between all process kinds and avoid code dupplication which may result in
-definition discrepency.
-
-Here, there is no payload attached to the messages.
-
-\dontinclude 11-explicitwait.c
-\skip message_declaration
-\until }
-
-\subsubsection GRAS_tut_tour_explicitwait_code_cb b) Defining private data and callbacks of the server
-
-Then, we define the callbacks that should be invoqued on the server side
-when some messages are received, as previously. For this, we also have to
-declare a structure for the private data of the server.
-
-\skip typedef
-\until end_of_release_callback
-
-\subsubsection GRAS_tut_tour_explicitwait_code_api c) Client-side API
-
-Now, we define the functions that the client must call to use the service.
-Note that this is where the explicit wait feature is used.
-
-\skip lock
-\until end_of_unlock
-
-\subsubsection GRAS_tut_tour_explicitwait_code_smain d) Server-side initialization
-
-The core of our distributed service is implemented (protocol, actions on
-server side, and accessing function on client side). We should now
-initialize the server and let it wait for incoming messages.
-
-Defining when to stop the server can become tricky. The simplest solution is
-to never let the server stop. It simply runs forever. But the simulator will
-raise an error at the end, so I won't do so here to keep the output clean.
-Another solution would be to deal with client membership properly: clients
-registers, use the service and quit afterward. When no client use the
-service, the server stops. This would be a bit difficult to implement
-(actually, there is an AMOK module to do so simply: \ref AMOK_pm).
-Here, we will just hardcode that the clients ask 5 times for the token, and
-that there is two clients. This clearly simplify the problem.
-
-\dontinclude 11-explicitwait.c
-\skip gras_userdata_new
-\until gras_msg_handle
-
-\subsubsection GRAS_tut_tour_explicitwait_code_cmain e) Client-side use
-
-And now, the client is <b>really</b> simple to write:
-
-\skip message_declaration
-\until }
-
-\section GRAS_tut_tour_explicitwait_recap Recapping everything together
-
-The program now reads:
-\include 11-explicitwait.c
-
-Which produces the expected output:
-\include 11-explicitwait.output
-
-
-*/
diff --git a/doc/gtut-files/gtut-tour-12-staticstruct.doc b/doc/gtut-files/gtut-tour-12-staticstruct.doc
deleted file mode 100644 (file)
index 1327b78..0000000
+++ /dev/null
@@ -1,26 +0,0 @@
-/**
-@page GRAS_tut_tour_staticstruct Lesson 12: Defining static structures (TODO)
-
-\section GRAS_tut_tour_staticstruct_toc Table of Contents
- - \ref GRAS_tut_tour_staticstruct_intro
- - \ref GRAS_tut_tour_staticstruct_use
- - \ref GRAS_tut_tour_staticstruct_recap
-
-<hr>
-
-\section GRAS_tut_tour_staticstruct_intro Introduction
-
-
-\section GRAS_tut_tour_staticstruct_use Defining static structure to GRAS
-
-
-\section GRAS_tut_tour_staticstruct_recap Recapping everything together
-
-The program now reads:
-include 11-staticstruct.c
-
-Which produces the expected output:
-include 11-staticstruct.output
-
-
-*/
diff --git a/doc/gtut-files/gtut-tour-13-pointers.doc b/doc/gtut-files/gtut-tour-13-pointers.doc
deleted file mode 100644 (file)
index d58f5e6..0000000
+++ /dev/null
@@ -1,100 +0,0 @@
-/**
-@page GRAS_tut_tour_pointers Lesson 13: Defining structure containing pointers (TODO)
-
-This lesson is a bit different from the other ones. It aims at explaining
-several features of the automatic datadesc parsing. Since it would be a bit
-long otherwise, the lesson is organized as a FAQ, with little examples of
-how to do things.
-
-\section GRAS_tut_tour_pointers_toc Table of Contents
- - \ref GRAS_tut_tour_pointers_intro
- - \ref GRAS_tut_tour_pointers_use
- - \ref GRAS_tut_tour_pointers_recap
- - \ref GRAS_tut_tour_pointers_cste
-
-<hr>
-\section GRAS_tut_tour_pointers_intro Introduction to pointers in datadesc
-\section GRAS_tut_tour_pointers_use Using pointers in datadesc
-\section GRAS_tut_tour_pointers_recap Recapping everything
-
-
-\section GRAS_tut_tour_pointers_cste How to have constants in parsed structures?
-
-You can use gras_datadesc_set_const() to explain GRAS about the value of
-your \#define'd constants.
-
-\verbatim
-#define SIZE 12
-GRAS_DEFINE_TYPE(array,struct array {
-  int data[SIZE];
-};);
-
-void declare_ddt() {
-  gras_datadesc_type_t ddt;
-
-  gras_datadesc_set_const("SIZE",SIZE); /* Set it before */
-  gras_datadesc_by_symbol(array);
-}
-\endverbatim
-
-
-*/
-
-    and the this example do use structures as payload,
-    so we have to declare it to GRAS. Hopefully, this can be done easily by enclosing
-    the structure declaration within a \ref GRAS_DEFINE_TYPE macro call. It will then copy this
-    declaration into an hidden string variable, which can be automatically parsed at
-    run time. Of course, the declaration is also copied unmodified by this macro, so that it
-    gets parsed by the compiler also.
-
-    There is some semantic that GRAS cannot guess alone and you need to  <i>annotate</i>
-    your declaration to add some. For example, the ctn pointer can be a reference to an
-    object or a whole array (in which case you also has to specify its size). This is done
-    with the GRAS_ANNOTE call. It is removed from the text passed to the compiler, but it helps
-    GRAS getting some information about the semantic of your data. Here, it says that \a ctn is an
-    array, which size is the result of the operation \a rows * \a cols (with \a rows and \a cols
-    being the other fields of the structure).
-
-    Please note that this annotation mechanism is not as robust and cool as this example seems to
-    imply. If you want to use it yourself, you'd better use the exact right syntax, which is
-    detailed in the \ref GRAS_dd section.
-
-    \skip GRAS_DEFINE_TYPE
-    \until matrix_t
-
-
-
-#define COLS 16
-#define MAX_ROUTESET 10
-#define MAX_LEAFSET COLS
-
-GRAS_DEFINE_TYPE(gras_row_t,
-struct gras_row_t {
-  int which_row;
-  int row[COLS][MAX_ROUTESET];
-};)
-
-typedef struct gras_row_t gras_row_t;
-
-GRAS_DEFINE_TYPE(gras_welcome_msg_t,
-struct gras_welcome_msg_t {
-  int id;
-  double time_sent;
-
-  int row_count;
-  gras_row_t *rows GRAS_ANNOTE(size,row_count);
-
-  int leaves[MAX_LEAFSET];
-};)
-
-void declare_ddt(void) {
-  gras_datadesc_type_t ddt;
-
-  gras_datadesc_set_const("COLS",COLS);
-  gras_datadesc_set_const("MAX_ROUTESET",MAX_ROUTESET);
-  gras_datadesc_set_const("MAX_LEAFSET",MAX_LEAFSET);
-
-  gras_datadesc_by_symbol(gras_row_t); /* Parse it before */
-  ddt=gras_datadesc_ref("welcome_msg_t*",gras_datadesc_by_symbol(gras_welcome_msg_t));
-  gras_msgtype_declare("welcome",ddt);
-}
diff --git a/doc/gtut-files/gtut-tour-14-dynar.doc b/doc/gtut-files/gtut-tour-14-dynar.doc
deleted file mode 100644 (file)
index 2c6c97d..0000000
+++ /dev/null
@@ -1,26 +0,0 @@
-/**
-@page GRAS_tut_tour_dynar Lesson 14: Exchanging aggregate datatypes such as dynar (TODO)
-
-\section GRAS_tut_tour_dynar_toc Table of Contents
- - \ref GRAS_tut_tour_dynar_intro
- - \ref GRAS_tut_tour_dynar_use
- - \ref GRAS_tut_tour_dynar_recap
-
-<hr>
-
-\section GRAS_tut_tour_dynar_intro Introduction
-
-
-\section GRAS_tut_tour_dynar_use Defining structure containing dynars
-
-
-\section GRAS_tut_tour_dynar_recap Recapping everything together
-
-The program now reads:
-include 13-dynar.c
-
-Which produces the expected output:
-include 13-dynar.output
-
-
-*/
diff --git a/doc/gtut-files/gtut-tour-15-manualdatadef.doc b/doc/gtut-files/gtut-tour-15-manualdatadef.doc
deleted file mode 100644 (file)
index 7a685b5..0000000
+++ /dev/null
@@ -1,26 +0,0 @@
-/**
-@page GRAS_tut_tour_manualdatadef Lesson 15: Manual data definition (TODO)
-
-\section GRAS_tut_tour_manualdatadef_toc Table of Contents
- - \ref GRAS_tut_tour_manualdatadef_intro
- - \ref GRAS_tut_tour_manualdatadef_use
- - \ref GRAS_tut_tour_manualdatadef_recap
-
-<hr>
-
-\section GRAS_tut_tour_manualdatadef_intro Introduction
-
-
-\section GRAS_tut_tour_manualdatadef_use Defining data manually
-
-
-\section GRAS_tut_tour_manualdatadef_recap Recapping everything together
-
-The program now reads:
-include 14-manualdatadef.c
-
-Which produces the expected output:
-include 14-manualdatadef.output
-
-
-*/
diff --git a/doc/gtut-files/gtut-tour-16-exchangecb.doc b/doc/gtut-files/gtut-tour-16-exchangecb.doc
deleted file mode 100644 (file)
index 5f3801b..0000000
+++ /dev/null
@@ -1,26 +0,0 @@
-/**
-@page GRAS_tut_tour_exchangecb Lesson 16: Advanced topics on data definition (TODO)
-
-\section GRAS_tut_tour_exchangecb_toc Table of Contents
- - \ref GRAS_tut_tour_exchangecb_intro
- - \ref GRAS_tut_tour_exchangecb_use
- - \ref GRAS_tut_tour_exchangecb_recap
-
-<hr>
-
-\section GRAS_tut_tour_exchangecb_intro Introduction
-
-
-\section GRAS_tut_tour_exchangecb_use Using exchange callbacks
-
-
-\section GRAS_tut_tour_exchangecb_recap Recapping everything together
-
-The program now reads:
-include 15-exchangecb.c
-
-Which produces the expected output:
-include 15-exchangecb.output
-
-
-*/
diff --git a/doc/gtut-files/gtut-tour-recap-messages.doc b/doc/gtut-files/gtut-tour-recap-messages.doc
deleted file mode 100644 (file)
index 0794ddc..0000000
+++ /dev/null
@@ -1,200 +0,0 @@
-/**
-@page GRAS_tut_tour_message_recaping Recaping the GRAS messaging system (ongoing)
-
-\section GRAS_tut_tour_message_recaping_toc Table of Contents
- - \ref GRAS_tut_tour_message_recaping_intro
- - \ref GRAS_tut_tour_message_recaping_rpc
-   - \ref GRAS_tut_tour_message_recaping_rpc1
-   - \ref GRAS_tut_tour_message_recaping_rpc2
-   - \ref GRAS_tut_tour_message_recaping_rpc3
-   - \ref GRAS_tut_tour_message_recaping_rpc4
-   - \ref GRAS_tut_tour_message_recaping_rpc5
-   - \ref GRAS_tut_tour_message_recaping_rpc_aside1
-   - \ref GRAS_tut_tour_message_recaping_rpc_aside2
-   - \ref GRAS_tut_tour_message_recaping_rpc_aside3
- - \ref GRAS_tut_tour_message_recaping_sync
-
-<hr>
-
-This is the end of the first big part of this tutorial. At this point, you
-know pretty much everything about message passing in GRAS. In second big
-part, you will learn how to describe data to the middleware in order to
-convey your own structures in messages instead of the predefined scalar
-types. But for now, it is time to recap what we have seen so far.
-
-\section GRAS_tut_tour_message_recaping_intro Message passing compared to procedure call
-
-In GRAS, you pass message to get remote component to achieve some work for
-you. In some sense, this is very similar to the good old procedure
-abstraction: you call some procedure to get <i>it</i> doing some work for
-you. Looking closer at this good old abstraction, we notice 4 call semantics:
-
- - <tt>void procedure(void)</tt> this is a procedure accepting no argument
-   and returning no result (<b>type 1</b>).
- - <tt>void procedure2(int i)</tt> this is a procedure accepting an
-   argument, but returning no result (<b>type 2</b>).
- - <tt>int function(void)</tt> this is a function accepting no argument, but
-   returning a result (<b>type 3</b>).
- - <tt>int function(int i)</tt> this is a function accepting an argument,
-   and returning a result (<b>type 4</b>).
-
-The whole story of the GRAS message passing subsystem is to allow to
-reproduce these call semantics in a distributed setting. That being said, We
-must also note that some messages exchanged using GRAS do not intend to
-mimic these semantics, but instead to help the syncronisation between
-distributed processes. When exchanged from peer A to peer B, they don't mean
-that A requests a service from B, but rather that A gives an information (a
-signal) to B. It could be for example that A reached a specific point of its
-computation, and that B can proceed with its own (this syncronisation schema
-being a simple rendez-vous). These messages are covered in the next part of
-this recapping (\ref GRAS_tut_tour_message_recaping_sync).
-
-To return on the call semantics described above, there is a big difference
-between the types T1 and T2 on one side and the types T3 and T4 on the other
-side. In the second case, the caller do wait for an answer from the callee
-side. In a distributed setting, you have to exchange one extra message in
-that case. That is why T1;T2 (sometimes refered as <i>one-way messages</i>)
-are treated quite differently in GRAS from T3;T4.
-
-\section GRAS_tut_tour_message_recaping_rpc Remote Procedure Call in GRAS
-
-Mimicing the same call semantic in a distributed setting is the goal of the
-RPC systems. To do so in GRAS, you must do the following actions:
-
-\subsection GRAS_tut_tour_message_recaping_rpc1 1. Declaring a datatype
-
-If you want that your messages convey complex datatypes and not only scalar,
-you have to do it first. Learning how to do so is the subject of the second
-part of this tutorial. For now, simply observe that this is the same thing
-than doing a <tt>typedef</tt> in your code before using this type:
-\verbatim typedef struct {
-  int a;
-  char b;
-} *mytype;\endverbatim
-
-\subsection GRAS_tut_tour_message_recaping_rpc2 2. Declaring a message type
-
-This is very similar to forward procedure declarations in your sequential
-code:
-\verbatim int myfunction(mytype myarg);\endverbatim
-More formally it comes down to associating a data type to a given
-symbol name. For example, in \ref GRAS_tut_tour_simpledata, we specified
-that the message <tt>"kill"</tt> conveyed a double as payload.
-
-Doing so depends on whether you have a one-way message (ie, type 1 or 2) or
-not. One-way messages are declared with gras_msgtype_declare() while RPC
-messages are declared with gras_msgtype_declare_rpc()
-
-\subsection GRAS_tut_tour_message_recaping_rpc3 3. Declaring message callbacks
-
-If the message is intended to be a work request one (and not a
-syncronization one as detailed below), you then want to attach some code to
-execute when a process receives the given request. In other words, you want
-to attach a callback to the message. Of course, you usualy don't want to do
-so on every nodes, but only on "servers" or "workers" or such. First of all,
-you need to declare the callback itself. This function that will be executed
-on request incoming must follow a very specific prototype (the same
-regardless of the call semantic):
-
-\verbatim
-int callback_name(gras_msg_cb_ctx_t context, void *payload) \endverbatim
-
-The first argument (of type #gras_msg_cb_ctx_t) is an opaque structure
-describing the callback context: who sent you the message (which you can
-find back using gras_msg_cb_ctx_from()), whether it's a one-way call or not,
-and so on. GRAS functions altering the call (such as gras_msg_rpcreturn(),
-used to return the result to the caller) require this context as argument.
-
-The second argument is a pointer to where the message payload is stored. In
-the T1 and T3 semantics (ie, when the message had no payload), this second
-argument is NULL. If not, the first line of your callback will probably
-retrieve the payload and store it in a variable of yours. The semantic for
-this is very systematic, if not elegant: If your payload is of type TOTO,
-<tt>payload</tt> is a pointer to a TOTO variable. So, cast it properly (add
-<tt>(TOTO*)</tt> in front of it), and dereference it (add a star right
-before the cast). For example:
-
-\verbatim
-TOTO myvariable = *(TOTO*) payload; \endverbatim
-
-This becomes even uglier if the conveyed type is a pointer itself, but you
-must stick to the rule anyway:
-
-\verbatim
-int **myvariable = *(int ** *) payload; \endverbatim
-
-If your message is of semantic T3 or T4 (ie, it returns a value to the
-caller), then you must use the function gras_msg_rpcreturn() to do so. It
-takes three arguments:
-  - a timeout to use (so that the server don't get frozen if the client is
-    unresponsive)
-  - the message context (the variable ctx of type #gras_msg_cb_ctx_t you got
-    as argument of the callback)
-  - a pointer to the data to send back.
-After it returned the result this way, you should free any data you
-mallocated in your callback (including the data you returned to the caller:
-GRAS made a copy of it during the call to gras_msg_rpcreturn()).
-
-The callback is expected to return 0 if ok, as detailed in
-\ref GRAS_tut_tour_message_recaping_rpc_aside1.
-
-\subsection GRAS_tut_tour_message_recaping_rpc4 4. Attaching callbacks to the messages
-
-To attach a given callback to a given message, you simply use
-gras_cb_register(). If you even want to de-register a callback, use
-gras_cb_unregister().
-
-\subsection GRAS_tut_tour_message_recaping_rpc5 5. Send your message from the client
-
-Again, sending messages depend on the semantic call. If you have a one-way
-message, you should call gras_msg_send() while RPC calls are sent with
-gras_msg_rpccall(). The main difference between them is that you have an
-extra argument for RPC, to specify where to store the result.
-
-It is also possible to call RPC asyncronously: you send the request (using
-gras_msg_rpc_async_call()), do some other computation. And then later, you
-wait for the answer of your RPC (using gras_msg_rpc_async_wait()).
-
-\subsection GRAS_tut_tour_message_recaping_rpc_aside1 Aside: stacking callbacks
-
-The callback is expected to return 0 if everything went well, which is the
-same semantic than the "main()" function. You can also build stacks of
-callbacks. It is perfectly valid to register several callbacks to a given
-message. When a message arrives, it is passed to the firstly-registered
-callback. If the callback returns 0, it means that it consumed the message,
-which is discarded. If the callback returns 1 (or any other "true" value),
-the message is passed to the next callback of the stack, and so on. At the
-end, if no callback returned 0, an exception is raised.
-
-This mecanism can for example be used to introduce dupplication and replay.
-You add a callback simply in charge of storing the message in a database,
-and since it returns 1, the message is then passed to the "real" callback.
-To be perfectly honest, I never had use of this functionnality myself, but I
-feel it could be useful in some cases...
-
-\subsection GRAS_tut_tour_message_recaping_rpc_aside2 Aside: Exceptions and callbacks
-
-One of the parts I'm the most proud of in GRAS is this one: imagine you have
-a rpc callback executing on a remote server. If this callback raises an
-exception, it will be propagated on the network back to the client, and
-revived there. So, the client will get automatically any exception raised by
-the server. Cool, isn't it? Afterward, simply refer to the <tt>host</tt>
-field of the #xbt_ex_t to retrieve the machine on which it was initialy
-raised.
-
-In case you wonder about the exceptions I'm speaking about (after all,
-SimGrid is in C ANSI, and there is usually no exception mecanism in C ANSI),
-you may want to refer to the section \ref XBT_ex. Note that exception can be
-troublesome to use (mainly because the compiler won't catch your mistakes on
-this).
-
-\subsection GRAS_tut_tour_message_recaping_rpc_aside3 Aside: Symbol versionning (TODO)
-
-This section covers a point not explicited elsewhere in the documentation.
-It may be seen as a bit hardcore, and you should probably skip it the first
-time you read the tutorial.
-
-\section GRAS_tut_tour_message_recaping_sync Syncronization messages in GRAS (TODO)
-
-*/
-
diff --git a/doc/gtut-files/gtut-tour.doc b/doc/gtut-files/gtut-tour.doc
deleted file mode 100644 (file)
index 949d8ea..0000000
+++ /dev/null
@@ -1,168 +0,0 @@
-/** @defgroup GRAS_tut_tour Initiatic tour
-    @ingroup GRAS_tut
-
-During this tour, you will learn all you need to write your own GRAS
-applications, from the installation of the framework to the use of (almost)
-all features available in GRAS.
-
-    \htmlonly <!--
-      DOXYGEN_NAVBAR_CHILD "0: Installing"=GRAS_tut_tour_install.html
-      DOXYGEN_NAVBAR_CHILD "1: Setup a project"=GRAS_tut_tour_setup.html
-      DOXYGEN_NAVBAR_CHILD "2: Simple messaging"=GRAS_tut_tour_simpleexchange.html
-      DOXYGEN_NAVBAR_CHILD "3: Process args"=GRAS_tut_tour_args.html
-      DOXYGEN_NAVBAR_CHILD "4: Callbacks"=GRAS_tut_tour_callbacks.html
-      DOXYGEN_NAVBAR_CHILD "5: Globals"=GRAS_tut_tour_globals.html
-      DOXYGEN_NAVBAR_CHILD "6: Logs"=GRAS_tut_tour_logs.html
-      DOXYGEN_NAVBAR_CHILD "7: Timers"=GRAS_tut_tour_timers.html
-      DOXYGEN_NAVBAR_CHILD "8: Exceptions"=GRAS_tut_tour_exceptions.html
-      DOXYGEN_NAVBAR_CHILD "9: Data exchange"=GRAS_tut_tour_simpledata.html
-      DOXYGEN_NAVBAR_CHILD "10: RPC"=GRAS_tut_tour_rpc.html
-      DOXYGEN_NAVBAR_CHILD "11: Explicit wait"=GRAS_tut_tour_explicitwait.html
-      DOXYGEN_NAVBAR_CHILD "Recapping part 1"=GRAS_tut_tour_message_recaping.html
-      DOXYGEN_NAVBAR_CHILD "12: Static data definition"=GRAS_tut_tour_staticstruct.html
-      DOXYGEN_NAVBAR_CHILD "13: Pointers definition"=GRAS_tut_tour_pointers.html
-      DOXYGEN_NAVBAR_CHILD "14: Dynars definition"=GRAS_tut_tour_dynar.html
-      DOXYGEN_NAVBAR_CHILD "15: Manual data definition"=GRAS_tut_tour_manualdatadef.html
-      DOXYGEN_NAVBAR_CHILD "16: Advanced data definition"=GRAS_tut_tour_exchangecb.html
-    --> \endhtmlonly
-
-<b>Part 1: Bases</b>
-
- - \ref GRAS_tut_tour_install
-
- - \ref GRAS_tut_tour_setup
-    - \ref GRAS_tut_tour_setup_C
-    - \ref GRAS_tut_tour_setup_plat
-    - \ref GRAS_tut_tour_setup_deploy
-    - \ref GRAS_tut_tour_setup_glue
-    - \ref GRAS_tut_tour_setup_make
-    - \ref GRAS_tut_tour_setup_start
-
-<b>Part 2: Message passing</b>
-
- - \ref GRAS_tut_tour_simpleexchange
-    - \ref GRAS_tut_tour_simpleexchange_msgtype
-    - \ref GRAS_tut_tour_simpleexchange_socks
-    - \ref GRAS_tut_tour_simpleexchange_exchange
-    - \ref GRAS_tut_tour_simpleexchange_recaping
-
- - \ref GRAS_tut_tour_args
-    - \ref GRAS_tut_tour_args_use
-    - \ref GRAS_tut_tour_args_sg
-    - \ref GRAS_tut_tour_args_recap
-
- - \ref GRAS_tut_tour_callbacks
-    - \ref GRAS_tut_tour_callbacks_declare
-    - \ref GRAS_tut_tour_callbacks_attach
-    - \ref GRAS_tut_tour_callbacks_handle
-    - \ref GRAS_tut_tour_callback_recap
-
- - \ref GRAS_tut_tour_globals
-    - \ref GRAS_tut_tour_globals_intro
-    - \ref GRAS_tut_tour_globals_use
-    - \ref GRAS_tut_tour_callback_pitfall
-    - \ref GRAS_tut_tour_callback_recap
-
- - \ref GRAS_tut_tour_logs
-    - \ref GRAS_tut_tour_logs_intro
-    - \ref GRAS_tut_tour_logs_practice
-    - \ref GRAS_tut_tour_logs_recap
-    - \ref GRAS_tut_tour_logs_config
-      - \ref GRAS_tut_tour_logs_config_prio
-      - \ref GRAS_tut_tour_logs_config_layout
-
- - \ref GRAS_tut_tour_timers
-    - \ref GRAS_tut_tour_timers_intro
-    - \ref GRAS_tut_tour_timers_use
-    - \ref GRAS_tut_tour_timers_recap
-
- - \ref GRAS_tut_tour_exceptions
-    - \ref GRAS_tut_tour_exceptions_intro
-    - \ref GRAS_tut_tour_exceptions_use
-    - \ref GRAS_tut_tour_exceptions_recap
-
- - \ref GRAS_tut_tour_simpledata
-    - \ref GRAS_tut_tour_simpledata_intro
-      - \ref GRAS_tut_tour_simpledata_intro_conv
-      - \ref GRAS_tut_tour_simpledata_intro_gras
-      - \ref GRAS_tut_tour_simpledata_use
-    - \ref GRAS_tut_tour_simpledata_example
-    - \ref GRAS_tut_tour_simpledata_recap
-
- - \ref GRAS_tut_tour_rpc
-    - \ref GRAS_tut_tour_rpc_intro
-    - \ref GRAS_tut_tour_rpc_use
-      - \ref GRAS_tut_tour_rpc_use_declare
-      - \ref GRAS_tut_tour_rpc_use_i2a_cb
-      - \ref GRAS_tut_tour_rpc_use_a2i_cb
-      - \ref GRAS_tut_tour_rpc_use_rest
-    - \ref GRAS_tut_tour_rpc_recap
-
- - \ref GRAS_tut_tour_explicitwait
-    - \ref GRAS_tut_tour_explicitwait_intro
-    - \ref GRAS_tut_tour_explicitwait_use
-      - \ref GRAS_tut_tour_explicitwait_algo
-      - \ref GRAS_tut_tour_explicitwait_code
-        - \ref GRAS_tut_tour_explicitwait_code_msg
-        - \ref GRAS_tut_tour_explicitwait_code_cb
-        - \ref GRAS_tut_tour_explicitwait_code_api
-        - \ref GRAS_tut_tour_explicitwait_code_smain
-        - \ref GRAS_tut_tour_explicitwait_code_cmain
-    - \ref GRAS_tut_tour_explicitwait_recap
-
- - \ref GRAS_tut_tour_message_recaping
-    - \ref GRAS_tut_tour_message_recaping_intro
-    - \ref GRAS_tut_tour_message_recaping_rpc
-      - \ref GRAS_tut_tour_message_recaping_rpc1
-      - \ref GRAS_tut_tour_message_recaping_rpc2
-      - \ref GRAS_tut_tour_message_recaping_rpc3
-      - \ref GRAS_tut_tour_message_recaping_rpc4
-      - \ref GRAS_tut_tour_message_recaping_rpc5
-      - \ref GRAS_tut_tour_message_recaping_rpc_aside1
-      - \ref GRAS_tut_tour_message_recaping_rpc_aside2
-      - \ref GRAS_tut_tour_message_recaping_rpc_aside3
-    - \ref GRAS_tut_tour_message_recaping_sync
-
-<b>Part 3: Data description</b>
-
- - \ref GRAS_tut_tour_staticstruct
-    - \ref GRAS_tut_tour_staticstruct_intro
-    - \ref GRAS_tut_tour_staticstruct_use
-    - \ref GRAS_tut_tour_staticstruct_recap
-
- - \ref GRAS_tut_tour_pointers
-    - \ref GRAS_tut_tour_pointers_intro
-    - \ref GRAS_tut_tour_pointers_use
-    - \ref GRAS_tut_tour_pointers_recap
-    - \ref GRAS_tut_tour_pointers_cste
-
- - \ref GRAS_tut_tour_dynar
-    - \ref GRAS_tut_tour_dynar_intro
-    - \ref GRAS_tut_tour_dynar_use
-    - \ref GRAS_tut_tour_dynar_recap
-
- - \ref GRAS_tut_tour_manualdatadef
-    - \ref GRAS_tut_tour_manualdatadef_intro
-    - \ref GRAS_tut_tour_manualdatadef_use
-    - \ref GRAS_tut_tour_manualdatadef_recap
-
- - \ref GRAS_tut_tour_exchangecb
-    - \ref GRAS_tut_tour_exchangecb_intro
-    - \ref GRAS_tut_tour_exchangecb_use
-    - \ref GRAS_tut_tour_exchangecb_recap
-
-<b>Part 4: Advanced topics</b>
-
-Unfortunately, the tour is not terminated yet, but I already know the kind
-of missi^W lessons I want to add:
-
-   - Computation virtualization
-   - Splitting in several files (logs, datadesc)
-   - Debugging GRAS programs
-   - Doing proper GRAS modules
-
-<hr>
-
-
-
-*/
diff --git a/doc/gtut-files/test.xml b/doc/gtut-files/test.xml
deleted file mode 100644 (file)
index 2aaa6f8..0000000
+++ /dev/null
@@ -1,7 +0,0 @@
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
-<platform version="3">
-  <process host="Jacquelin" function="server" />
-  <process host="Boivin" function="client" />
-</platform>
-
diff --git a/doc/ref_guide/doxygen/module-gras.doc b/doc/ref_guide/doxygen/module-gras.doc
deleted file mode 100644 (file)
index 7b8d028..0000000
+++ /dev/null
@@ -1,71 +0,0 @@
-/** \addtogroup GRAS_API
-
-    \section GRAS_funct GRAS offers the following functionnalities
-     - <b>\ref GRAS_comm</b>: Exchanging messages between peers
-       - \ref GRAS_dd : any data which may transit on the network must be
-         described beforehand so that GRAS can handle the platform
-         heterogeneity and convert them if needed.
-       - \ref GRAS_sock : this is how to open a communication channel to
-         other processes, and retrive information about them.
-       - \ref GRAS_msg : communications are message oriented. You have to
-         describe all possible messages and their payload beforehand, and
-         can then attach callbacks to the arrival of a given kind of message.
-       - \ref GRAS_timer : this is how to program repetitive and delayed
-         tasks, not unlike cron(8) and at(1). This cannot be used to timeout
-         a function (like setitimer(2) or signal(2) games could do).
-     - <b>\ref GRAS_run</b>: Running both on top of the simulator and on
-       top of real platforms, and portability support.
-       - \ref GRAS_virtu : You naturally don't want to call the
-          gettimeofday(2) function in simulation mode since it would give
-          you the time on the host running the simulation, not the time in
-          the simulated world (you are belonging to).\n
-         This a system call virtualization layer, which also acts as a
-          portability layer.
-       - \ref GRAS_globals : The use of globals is forbidden since the
-         "processes" are threads in simulation mode. \n
-        This is how to let GRAS handle your globals properly.
-       - \ref GRAS_emul : Support to emulate code excution (ie, reporting
-         execution time into the simulator and having code sections specific
-         to simulation or to real mode).
-
-
-    @{ */
-       /** @defgroup GRAS_comm    Communication facilities */
-       /** @defgroup GRAS_run     Virtualization */
-
-/** @} */
-#####################################################################
-/** @addtogroup GRAS_comm
-
-   Here are the communication facilities. GRAS allows you to exchange
-   <i>messages</i> on <i>sockets</i> (which can be seen as pipes between
-   processes). On reception, messages start <i>callbacks</i> (that's the
-   default communication mode, not the only one). All messages of a given
-   type convey the same kind of data, and you have to describe it
-   beforehand.
-
-   Timers are also seen as a mean of communication (with yourself). It
-   allows you to run a repetitive task ("do this every N second until I tell
-   you to stop"), or to deffer a treatment ("do this in 3 sec").
-
-    @{ */
-       /** @defgroup GRAS_dd      Data description      */
-       /** @defgroup GRAS_sock    Sockets               */
-       /** @defgroup GRAS_msg     Messages              */
-       /** @defgroup GRAS_timer   Timers                */
-
-/** @} */
-#####################################################################
-/** @addtogroup GRAS_run
-
-   Virtualization facilities allow your code to run both on top of the simulator or in real setting.
-
-    @{ */
-
-       /** @defgroup GRAS_globals Globals               */
-       /** @defgroup GRAS_emul    Emulation support */
-       /** @defgroup GRAS_virtu   Syscalls              */
-
-/** @} */
-
-
diff --git a/examples/amok/alnem/alnem.c b/examples/amok/alnem/alnem.c
deleted file mode 100644 (file)
index 9bcb87f..0000000
+++ /dev/null
@@ -1,240 +0,0 @@
-/* ALNeM itself                                                             */
-
-/* Copyright (c) 2005, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
- * under the terms of the license (GNU LGPL) which comes with this package. */
-
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <signal.h>
-#include <time.h>
-
-#include <gras.h>
-
-#include <tbx_graph.h>          /* alvin's graph toolbox (+ reconstruction algorithm) */
-
-/* **********************************************************************
- * Sensor code
- * **********************************************************************/
-
-/* Global private data */
-typedef struct {
-  gras_sock_t *sock;
-} sensor_data_t;
-
-/* Function prototypes */
-int sensor(int argc, char *argv[]);
-
-int sensor(int argc, char *argv[])
-{
-  xbt_error_t errcode;
-  sensor_data_t *g = gras_userdata_new(sensor_data_t);
-
-  if ((errcode = gras_sock_server_open(4000, 4000, &(g->sock)))) {
-    fprintf(stderr,
-            "Sensor: Error %s encountered while opening the server socket\n",
-            xbt_error_name(errcode));
-    return 1;
-  }
-
-  if (grasbw_register_messages()) {
-    gras_sock_close(g->sock);
-    return 1;
-  }
-
-  while (1) {
-    if ((errcode = gras_msg_handle(3600.0)) && errcode != timeout_error) {
-      fprintf(stderr, "Sensor: Error '%s' while handling message\n",
-              xbt_error_name(errcode));
-    }
-  }
-
-  gras_sleep(5, 0);
-  return gras_sock_close(g->sock);
-}
-
-/* **********************************************************************
- * Maestro code
- * **********************************************************************/
-
-/* Global private data */
-typedef struct {
-  gras_sock_t *sock;
-} maestro_data_t;
-
-/* Function prototypes */
-int maestro(int argc, char *argv[]);
-
-#define MAXHOSTS 100
-
-#define INTERF(graph,table,a,u,b,v) INTERFERENCE(table,\
-                                                TBX_Graph_nodeSearch(graph,a),\
-                                                TBX_Graph_nodeSearch(graph,u),\
-                                                TBX_Graph_nodeSearch(graph,b),\
-                                                TBX_Graph_nodeSearch(graph,v))
-
-int maestro(int argc, char *argv[])
-{
-  int bufSize = 32 * 1024;
-  int expSize = 1024 * 1024;
-  int msgSize = expSize;
-  int satSize = msgSize * 100;
-  double dummy, beginSim;
-  xbt_error_t errcode;
-  maestro_data_t *g = gras_userdata_new(maestro_data_t);
-
-  double bw[MAXHOSTS][MAXHOSTS];
-  double bw_sat[MAXHOSTS][MAXHOSTS];
-
-  int a, b, c, d, begin;
-
-  TBX_Graph_t graph = TBX_Graph_newGraph("Essai", 0, NULL);     /* a dummy graph containing all hosts */
-  TBX_FIFO_t host_fifo = TBX_FIFO_newFIFO();
-  TBX_InterfTable_t interf = NULL;      /* the measured interferences */
-  TBX_Graph_t builded_graph = NULL;     /* the graph builded from the interferences */
-
-  /* basics setups */
-  if (argc > MAXHOSTS) {
-    fprintf(stderr,
-            "You gave more than %d sensors for this experiment. Increase the MAX HOSTS constant in alnem code to be bigger than this number.\n",
-            argc);
-    return 1;
-  }
-
-  if ((errcode = gras_sock_server_open(4000, 5000, &(g->sock)))) {
-    fprintf(stderr,
-            "MAESTRO: Error %s encountered while opening the server socket\n",
-            xbt_error_name(errcode));
-    return 1;
-  }
-
-  if (grasbw_register_messages()) {
-    gras_sock_close(g->sock);
-    return 1;
-  }
-
-  for (a = 1; a < argc; a++) {
-    TBX_FIFO_insert(host_fifo, TBX_Graph_newNode(graph, argv[a], NULL));
-  }
-  TBX_Graph_fixNodeNumbering(graph);
-  interf = TBX_Graph_newInterfTable(host_fifo);
-  TBX_Graph_graphInterfTableInit(graph, interf);
-
-  /* measure the bandwidths */
-  begin = time(NULL);
-  beginSim = gras_time();
-  for (a = 1; a < argc; a++) {
-    for (b = 1; b < argc; b++) {
-      int test = 0;
-
-      if (a == b)
-        continue;
-      fprintf(stderr, "BW XP(%s %s)=", argv[a], argv[b]);
-      while ((errcode =
-              grasbw_request(argv[a], 4000, argv[b], 4000, bufSize,
-                             expSize, msgSize, &dummy, &(bw[a][b])))
-             && (errcode == timeout_error)) {
-        test++;
-        if (test == 10) {
-          fprintf(stderr, "MAESTRO: 10 Timeouts; giving up\n");
-          return 1;
-        }
-      }
-      if (errcode) {
-        fprintf(stderr,
-                "MAESTRO: Error %s encountered while doing the test\n",
-                xbt_error_name(errcode));
-        return 1;
-      }
-      fprintf(stderr, "%f Mb/s in %f sec\n", bw[a][b], dummy);
-    }
-  }
-  fprintf(stderr, "Did all BW tests in %ld sec (%.2f simulated sec)\n",
-          time(NULL) - begin, gras_time() - beginSim);
-
-  /* saturation tests */
-  for (a = 1; a < argc; a++) {
-    for (b = 1; b < argc; b++) {
-      for (c = 1; c < argc; c++) {
-        INTERF(graph, interf, argv[a], argv[c], argv[b], argv[c]) = 1;
-      }
-    }
-  }
-
-  for (a = 1; a < argc; a++) {
-    for (b = 1; b < argc; b++) {
-      if (a == b)
-        continue;
-
-      if ((errcode =
-           grasbw_saturate_start(argv[a], 4000, argv[b], 4000, satSize,
-                                 360000000))) {
-        fprintf(stderr,
-                "MAESTRO: Error %s encountered while starting saturation\n",
-                xbt_error_name(errcode));
-        return -1;
-      }
-      gras_sleep(1, 0);
-
-      begin = time(NULL);
-      beginSim = gras_time();
-      for (c = 1; c < argc; c++) {
-        if (a == c || b == c)
-          continue;
-
-        for (d = 1; d < argc; d++) {
-          if (a == d || b == d || c == d)
-            continue;
-
-          if ((errcode =
-               grasbw_request(argv[c], 4000, argv[d], 4000, bufSize,
-                              expSize, msgSize, &dummy,
-                              &(bw_sat[c][d])))) {
-            fprintf(stderr, "MAESTRO: Error %s encountered in test\n",
-                    xbt_error_name(errcode));
-            return 1;
-          }
-          fprintf(stderr,
-                  "MAESTRO[%.2f sec]: SATURATED BW XP(%s %s // %s %s) => %f (%f vs %f)%s\n",
-                  gras_time(), argv[c], argv[d], argv[a], argv[b],
-                  bw_sat[c][d] / bw[c][d], bw[c][d], bw_sat[c][d],
-                  (bw_sat[c][d] / bw[c][d] <
-                   0.75) ? " THERE IS SOME INTERFERENCE !!!" : "");
-          INTERF(graph, interf, argv[c], argv[d], argv[a], argv[b]) =
-              (bw_sat[c][d] / bw[c][d] < 0.75) ? 1 : 0;
-        }
-      }
-
-      if ((errcode = grasbw_saturate_stop(argv[a], 4000, argv[b], 4000))) {
-        fprintf(stderr,
-                "MAESTRO: Error %s encountered while stopping saturation\n",
-                xbt_error_name(errcode));
-        return -1;
-      }
-      fprintf(stderr,
-              "Did an iteration on saturation pair in %ld sec (%.2f simulated sec)\n",
-              time(NULL) - begin, gras_time() - beginSim);
-    }
-  }
-
-  /* reconstruct the graph */
-  TBX_Graph_interferenceTableDump(interf);
-  TBX_Graph_interferenceTableSave(interf, "interference.dat");
-  begin = time(NULL);
-  fprintf(stderr, "MAESTRO: Reconstruct the graph... ");
-  builded_graph = TBX_Graph_exploreInterference(interf);
-  TBX_Graph_exportToGraphViz(builded_graph, "toto.dot");
-  fprintf(stderr, "done (took %d sec)", (int) time(NULL));
-
-  /* end */
-  TBX_Graph_freeGraph(graph, NULL, NULL, NULL);
-  TBX_Graph_freeGraph(builded_graph, NULL, NULL, NULL);
-  TBX_Graph_freeInterfTable(interf);
-
-  gras_sleep(5, 0);
-  exit(0);                      /* FIXME: There is a bug in MSG preventing me from terminating this server properly */
-  return gras_sock_close(g->sock);
-}
diff --git a/examples/amok/alnem/alnem_builder.c b/examples/amok/alnem/alnem_builder.c
deleted file mode 100644 (file)
index 26341f1..0000000
+++ /dev/null
@@ -1,38 +0,0 @@
-/* ALNeM builder. Take an interference matrix as argument,                  */
-/*  and reconstruct the corresponding graph itself                          */
-
-/* Copyright (c) 2005, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
- * under the terms of the license (GNU LGPL) which comes with this package. */
-
-
-#include <stdio.h>
-#include <stdlib.h>
-
-#include <tbx_graph.h>          /* alvin's graph toolbox (+ reconstruction algorithm) */
-
-int main(int argc, char *argv[])
-{
-  TBX_Graph_t graph;            /* a dummy graph containing all hosts */
-  TBX_FIFO_t host_fifo;
-  TBX_InterfTable_t interf;     /* the measured interferences */
-  TBX_Graph_t builded_graph;    /* the graph builded from the interferences */
-
-  if (argc != 2) {
-    fprintf(stderr, "alnem_builder: USAGE:\n");
-    fprintf(stderr, "  alnem_builder interference_file\n");
-    exit(1);
-  }
-
-  if (TBX_Graph_interferenceTableRead
-      (argv[1], &graph, &interf, &host_fifo)) {
-    fprintf(stderr, "Can't read the interference data, aborting\n");
-    exit(1);
-  }
-
-  builded_graph = TBX_Graph_exploreInterference(interf);
-  TBX_Graph_exportToGraphViz(builded_graph, "toto.dot");
-  return 0;
-}
diff --git a/examples/amok/alnem/alnem_deployment.txt b/examples/amok/alnem/alnem_deployment.txt
deleted file mode 100644 (file)
index 963935a..0000000
+++ /dev/null
@@ -1,5 +0,0 @@
-A sensor
-B sensor
-C sensor
-D sensor
-Master maestro A B C D
diff --git a/examples/amok/alnem/deploy_WAN3.txt b/examples/amok/alnem/deploy_WAN3.txt
deleted file mode 100644 (file)
index 6a88ba6..0000000
+++ /dev/null
@@ -1,34 +0,0 @@
-61 sensor
-62 sensor
-63 sensor
-69 sensor
-70 sensor
-77 sensor
-81 sensor
-83 sensor
-85 sensor
-87 sensor
-88 sensor
-95 sensor
-98 sensor
-107 sensor
-109 sensor
-111 sensor
-112 sensor
-121 sensor
-124 sensor
-125 sensor
-131 sensor
-145 sensor
-150 sensor
-156 sensor
-157 sensor
-162 sensor
-165 sensor
-168 sensor
-169 sensor
-170 sensor
-175 sensor
-177 sensor
-178 sensor
-109 maestro 61 62 63 69 70 77 81 83 85 98 107 109 111 112 121 124 125 131 145 150 156 157 162 165 168 169 170 175 177 178
diff --git a/examples/amok/alnem/interference.dat b/examples/amok/alnem/interference.dat
deleted file mode 100644 (file)
index c2fdc05..0000000
+++ /dev/null
@@ -1,30 +0,0 @@
-INTERFERENCE GRAPH DUMPED TO FILE. DO NOT EDIT, EVEN TO ADD OR REMOVE A SPACE !!
-4
-A
-B
-C
-D
-1 1 
-1 1 
-1 0 
-1 1 
-1 0 
-1 1 
-1 1 
-1 1 
-1 0 
-1 1 
-1 0 
-1 1 
-1 1 
-0 1 
-1 1 
-0 1 
-1 1 
-1 1 
-1 1 
-0 1 
-1 1 
-0 1 
-1 1 
-1 1 
diff --git a/examples/amok/bandwidth/CMakeLists.txt b/examples/amok/bandwidth/CMakeLists.txt
deleted file mode 100644 (file)
index 5d657fd..0000000
+++ /dev/null
@@ -1,55 +0,0 @@
-cmake_minimum_required(VERSION 2.6)
-
-set_source_files_properties(
-  ${CMAKE_CURRENT_BINARY_DIR}/_bandwidth_simulator.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_bandwidth_maestro.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_bandwidth_sensor.c
-  PROPERTIES GENERATED true
-  )
-
-set(EXECUTABLE_OUTPUT_PATH "${CMAKE_CURRENT_BINARY_DIR}")
-add_executable(bandwidth_simulator ${CMAKE_CURRENT_BINARY_DIR}/_bandwidth_simulator.c ${CMAKE_CURRENT_SOURCE_DIR}/bandwidth.c)
-add_executable(bandwidth_maestro   ${CMAKE_CURRENT_BINARY_DIR}/_bandwidth_maestro.c ${CMAKE_CURRENT_SOURCE_DIR}/bandwidth.c)
-add_executable(bandwidth_sensor    ${CMAKE_CURRENT_BINARY_DIR}/_bandwidth_sensor.c ${CMAKE_CURRENT_SOURCE_DIR}/bandwidth.c)
-
-add_custom_command(
-  OUTPUT       ${CMAKE_CURRENT_BINARY_DIR}/_bandwidth_simulator.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_bandwidth_maestro.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_bandwidth_sensor.c
-  DEPENDS gras_stub_generator ${CMAKE_CURRENT_SOURCE_DIR}/bandwidth.xml
-  COMMAND ${CMAKE_BINARY_DIR}/bin/gras_stub_generator bandwidth ${CMAKE_CURRENT_SOURCE_DIR}/bandwidth.xml
-  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
-  )
-
-### Add definitions for compile
-if(NOT WIN32)
-  target_link_libraries(bandwidth_simulator simgrid pthread m)
-  target_link_libraries(bandwidth_maestro gras pthread m)
-  target_link_libraries(bandwidth_sensor gras pthread m)
-else()
-  target_link_libraries(bandwidth_simulator simgrid)
-  target_link_libraries(bandwidth_maestro gras)
-  target_link_libraries(bandwidth_sensor gras)
-endif()
-
-set(tesh_files
-  ${tesh_files}
-  ${CMAKE_CURRENT_SOURCE_DIR}/bandwidth_rl.tesh
-  ${CMAKE_CURRENT_SOURCE_DIR}/bandwidth_sg_32.tesh
-  ${CMAKE_CURRENT_SOURCE_DIR}/bandwidth_sg_64.tesh
-  PARENT_SCOPE
-  )
-set(xml_files
-  ${xml_files}
-  ${CMAKE_CURRENT_SOURCE_DIR}/bandwidth.xml
-  PARENT_SCOPE
-  )
-set(examples_src
-  ${examples_src}
-  ${CMAKE_CURRENT_SOURCE_DIR}/bandwidth.c
-  PARENT_SCOPE
-  )
-set(bin_files
-  ${bin_files}
-  PARENT_SCOPE
-  )
diff --git a/examples/amok/bandwidth/bandwidth.c b/examples/amok/bandwidth/bandwidth.c
deleted file mode 100644 (file)
index 8df320a..0000000
+++ /dev/null
@@ -1,138 +0,0 @@
-/* bandwidth - bandwidth test demo of GRAS features                         */
-
-/* Copyright (c) 2005, 2006, 2007, 2008, 2009, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
- * under the terms of the license (GNU LGPL) which comes with this package. */
-
-
-#include "gras.h"
-#include "amok/bandwidth.h"
-#include "amok/peermanagement.h"
-
-XBT_LOG_NEW_DEFAULT_CATEGORY(Bandwidth,
-                             "Messages specific to this example");
-
-/* **********************************************************************
- * Sensor code
- * **********************************************************************/
-
-static xbt_socket_t try_gras_socket_client_from_string(const char *host)
-{
-  volatile xbt_socket_t sock = NULL;
-  xbt_ex_t e;
-  TRY {
-    sock = gras_socket_client_from_string(host);
-  }
-  CATCH(e) {
-    xbt_ex_free(e);
-  }
-  return sock;
-}
-
-/* Function prototypes */
-int sensor(int argc, char *argv[]);
-
-int sensor(int argc, char *argv[])
-{
-  xbt_socket_t mysock;
-  xbt_socket_t master = NULL;
-  int connection_try = 10;
-
-  gras_init(&argc, argv);
-  amok_bw_init();
-  amok_pm_init();
-
-  mysock = gras_socket_server_range(3000, 9999, 0, 0);
-  XBT_INFO("Sensor starting (on port %d)", gras_os_myport());
-  while (connection_try > 0 &&
-         !(master = try_gras_socket_client_from_string(argv[1]))) {
-    connection_try--;
-    gras_os_sleep(0.5);       /* let the master get ready */
-  }
-
-  amok_pm_group_join(master, "bandwidth");
-  amok_pm_mainloop(60);
-
-  gras_socket_close(mysock);
-  gras_socket_close(master);
-  gras_exit();
-  return 0;
-}
-
-/* **********************************************************************
- * Maestro code
- * **********************************************************************/
-
-/* Function prototypes */
-int maestro(int argc, char *argv[]);
-
-int maestro(int argc, char *argv[])
-{
-  double sec, bw;
-  int buf_size = 32 * 1024;
-  int msg_size = 512 * 1024;
-  int msg_amount = 1;
-  double min_duration = 1;
-
-  xbt_socket_t peer;
-  xbt_socket_t mysock;
-  xbt_peer_t h1, h2, h_temp;
-  xbt_dynar_t group;
-
-  gras_init(&argc, argv);
-  amok_bw_init();
-  amok_pm_init();
-
-  XBT_INFO("Maestro starting");
-  if (argc != 2) {
-    XBT_ERROR("Usage: maestro port\n");
-    return 1;
-  }
-  mysock = gras_socket_server(atoi(argv[1]));
-  group = amok_pm_group_new("bandwidth");
-  XBT_INFO("Wait for peers for 5 sec");
-  gras_msg_handleall(5);        /* friends, we're ready. Come and play */
-
-  if (xbt_dynar_length(group) < 2) {
-    amok_pm_group_shutdown("bandwidth");
-    xbt_die("Not enough peers arrived. Expected 2 got %ld",
-            xbt_dynar_length(group));
-  }
-  h1 = *(xbt_peer_t *) xbt_dynar_get_ptr(group, 0);
-  h2 = *(xbt_peer_t *) xbt_dynar_get_ptr(group, 1);
-  /* sort peers in right order to keep output right */
-  if (strcmp(h1->name, h2->name) < 0 || h1->port > h2->port) {
-    h_temp = h1;
-    h1 = h2;
-    h2 = h_temp;
-  }
-
-  XBT_INFO("Contact %s:%d", h1->name, h1->port);
-  peer = gras_socket_client(h1->name, h1->port);
-
-  XBT_INFO("Test the BW between me and one of the sensors");
-  amok_bw_test(peer, buf_size, msg_size, msg_amount, min_duration, &sec,
-               &bw);
-  XBT_INFO
-      ("Experience between me and %s:%d (initially %d msgs of %d bytes, maybe modified to fill the pipe at least %.1fs) took %f sec, achieving %f kb/s",
-       h1->name, h1->port, msg_amount, msg_size, min_duration, sec,
-       ((double) bw) / 1024.0);
-
-  XBT_INFO("Test the BW between %s:%d and %s:%d", h1->name, h1->port,
-        h2->name, h2->port);
-  amok_bw_request(h1->name, h1->port, h2->name, h2->port, buf_size,
-                  msg_size, msg_amount, min_duration, &sec, &bw);
-  XBT_INFO
-      ("Experience between %s:%d and %s:%d took took %f sec, achieving %f kb/s",
-       h1->name, h1->port, h2->name, h2->port, sec,
-       ((double) bw) / 1024.0);
-
-  /* Game is over, friends */
-  amok_pm_group_shutdown("bandwidth");
-
-  gras_socket_close(mysock);
-  gras_exit();
-  return 0;
-}
diff --git a/examples/amok/bandwidth/bandwidth.xml b/examples/amok/bandwidth/bandwidth.xml
deleted file mode 100644 (file)
index 777aa91..0000000
+++ /dev/null
@@ -1,13 +0,0 @@
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
-<platform version="3">
-  <process host="Tremblay" function="sensor">
-     <argument value="Ginette:4000"/>       <!-- maestro -->
-  </process>
-  <process host="Jupiter" function="sensor">
-     <argument value="Ginette:4000"/>       <!-- maestro -->
-  </process>
-  <process host="Ginette" function="maestro">
-     <argument value="4000"/>   <!-- my port -->
-  </process>
-</platform>
diff --git a/examples/amok/bandwidth/bandwidth_rl.tesh b/examples/amok/bandwidth/bandwidth_rl.tesh
deleted file mode 100755 (executable)
index 34bb825..0000000
+++ /dev/null
@@ -1,14 +0,0 @@
-! timeout 20
-& $SG_TEST_ENV bandwidth/bandwidth_sensor$EXEEXT 127.0.0.1:6000 "--log=root.fmt=%P:%t%e%m%n"
-> sensor:main Sensor starting (on port 3000)
-
-! timeout 20
-& $SG_TEST_ENV bandwidth/bandwidth_sensor$EXEEXT 127.0.0.1:6000 "--log=root.fmt=%P:%t%e%m%n"
-> sensor:main Sensor starting (on port 3001)
-
-! timeout 20
-& $SG_TEST_ENV bandwidth/bandwidth_maestro$EXEEXT 6000 "--log=root.fmt=%P:%t%e%m%n"
-> maestro:main Maestro starting
-> maestro:main Wait for peers for 5 sec
-> maestro:main Contact 127.0.0.1:3000
-> maestro:main Test the BW between me and one of the sensors
diff --git a/examples/amok/bandwidth/bandwidth_sg_32.tesh b/examples/amok/bandwidth/bandwidth_sg_32.tesh
deleted file mode 100644 (file)
index 4f06b3f..0000000
+++ /dev/null
@@ -1,13 +0,0 @@
-$ $SG_TEST_EXENV bandwidth/bandwidth_simulator${EXEEXT} ${srcdir:=.}/../msg/small_platform.xml ${srcdir:=.}/bandwidth/bandwidth.xml
-> [Ginette:maestro:(3) 0.000000] [Bandwidth/INFO] Maestro starting
-> [Tremblay:sensor:(1) 0.000156] [Bandwidth/INFO] Sensor starting (on port 3000)
-> [Ginette:maestro:(3) 0.000156] [Bandwidth/INFO] Wait for peers for 5 sec
-> [Jupiter:sensor:(2) 0.000156] [Bandwidth/INFO] Sensor starting (on port 3000)
-> [Ginette:maestro:(3) 5.000156] [Bandwidth/INFO] Contact Tremblay:3000
-> [Ginette:maestro:(3) 5.000312] [Bandwidth/INFO] Test the BW between me and one of the sensors
-> [Ginette:maestro:(3) 7.091301] [Bandwidth/INFO] Experience between me and Tremblay:3000 (initially 1 msgs of 524288 bytes, maybe modified to fill the pipe at least 1.0s) took 1.090703 sec, achieving 7489.460506 kb/s
-> [Ginette:maestro:(3) 7.091301] [Bandwidth/INFO] Test the BW between Tremblay:3000 and Jupiter:3000
-> [Ginette:maestro:(3) 9.249120] [Bandwidth/INFO] Experience between Tremblay:3000 and Jupiter:3000 took took 1.089859 sec, achieving 6296.831079 kb/s
-> [Ginette:maestro:(3) 9.291095] [gras/INFO] Exiting GRAS
-> [Jupiter:sensor:(2) 9.291095] [gras/INFO] Exiting GRAS
-> [Tremblay:sensor:(1) 10.249120] [gras/INFO] Exiting GRAS
diff --git a/examples/amok/bandwidth/bandwidth_sg_64.tesh b/examples/amok/bandwidth/bandwidth_sg_64.tesh
deleted file mode 100644 (file)
index 15b1bab..0000000
+++ /dev/null
@@ -1,13 +0,0 @@
-$ $SG_TEST_EXENV bandwidth/bandwidth_simulator${EXEEXT} ${srcdir:=.}/../msg/small_platform.xml ${srcdir:=.}/bandwidth/bandwidth.xml
-> [Ginette:maestro:(3) 0.000000] [Bandwidth/INFO] Maestro starting
-> [Tremblay:sensor:(1) 0.000156] [Bandwidth/INFO] Sensor starting (on port 3000)
-> [Ginette:maestro:(3) 0.000156] [Bandwidth/INFO] Wait for peers for 5 sec
-> [Jupiter:sensor:(2) 0.000156] [Bandwidth/INFO] Sensor starting (on port 3000)
-> [Ginette:maestro:(3) 5.000156] [Bandwidth/INFO] Contact Tremblay:3000
-> [Ginette:maestro:(3) 5.000312] [Bandwidth/INFO] Test the BW between me and one of the sensors
-> [Ginette:maestro:(3) 7.091307] [Bandwidth/INFO] Experience between me and Tremblay:3000 (initially 1 msgs of 524288 bytes, maybe modified to fill the pipe at least 1.0s) took 1.090703 sec, achieving 7489.460506 kb/s
-> [Ginette:maestro:(3) 7.091307] [Bandwidth/INFO] Test the BW between Tremblay:3000 and Jupiter:3000
-> [Ginette:maestro:(3) 9.249135] [Bandwidth/INFO] Experience between Tremblay:3000 and Jupiter:3000 took took 1.089859 sec, achieving 6296.831079 kb/s
-> [Ginette:maestro:(3) 9.291110] [gras/INFO] Exiting GRAS
-> [Jupiter:sensor:(2) 9.291110] [gras/INFO] Exiting GRAS
-> [Tremblay:sensor:(1) 10.249135] [gras/INFO] Exiting GRAS
diff --git a/examples/amok/saturate/CMakeLists.txt b/examples/amok/saturate/CMakeLists.txt
deleted file mode 100644 (file)
index aec9f8c..0000000
+++ /dev/null
@@ -1,56 +0,0 @@
-cmake_minimum_required(VERSION 2.6)
-
-set_source_files_properties(
-  ${CMAKE_CURRENT_BINARY_DIR}/_saturate_simulator.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_saturate_maestro.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_saturate_sensor.c
-  PROPERTIES GENERATED true
-  )
-
-set(EXECUTABLE_OUTPUT_PATH "${CMAKE_CURRENT_BINARY_DIR}")
-add_executable(saturate_simulator ${CMAKE_CURRENT_BINARY_DIR}/_saturate_simulator.c ${CMAKE_CURRENT_SOURCE_DIR}/saturate.c)
-add_executable(saturate_maestro   ${CMAKE_CURRENT_BINARY_DIR}/_saturate_maestro.c ${CMAKE_CURRENT_SOURCE_DIR}/saturate.c)
-add_executable(saturate_sensor    ${CMAKE_CURRENT_BINARY_DIR}/_saturate_sensor.c ${CMAKE_CURRENT_SOURCE_DIR}/saturate.c)
-
-add_custom_command(
-  OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/_saturate_simulator.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_saturate_maestro.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_saturate_sensor.c
-  DEPENDS gras_stub_generator ${CMAKE_CURRENT_SOURCE_DIR}/saturate.xml
-  COMMAND ${CMAKE_BINARY_DIR}/bin/gras_stub_generator saturate ${CMAKE_CURRENT_SOURCE_DIR}/saturate.xml
-  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
-  )
-
-### Add definitions for compile
-if(NOT WIN32)
-  target_link_libraries(saturate_simulator simgrid pthread m)
-  target_link_libraries(saturate_maestro gras pthread m)
-  target_link_libraries(saturate_sensor gras pthread m)
-else()
-  target_link_libraries(saturate_simulator simgrid)
-  target_link_libraries(saturate_maestro gras)
-  target_link_libraries(saturate_sensor gras)
-endif()
-
-set(tesh_files
-  ${tesh_files}
-  ${CMAKE_CURRENT_SOURCE_DIR}/saturate_rl.tesh
-  ${CMAKE_CURRENT_SOURCE_DIR}/saturate_sg_32.tesh
-  ${CMAKE_CURRENT_SOURCE_DIR}/saturate_sg_64.tesh
-  PARENT_SCOPE
-  )
-set(xml_files
-  ${xml_files}
-  ${CMAKE_CURRENT_SOURCE_DIR}/saturate.xml
-  PARENT_SCOPE
-  )
-set(examples_src
-  ${examples_src}
-  ${CMAKE_CURRENT_SOURCE_DIR}/env.c
-  ${CMAKE_CURRENT_SOURCE_DIR}/saturate.c
-  PARENT_SCOPE
-  )
-set(bin_files
-  ${bin_files}
-  PARENT_SCOPE
-  )
diff --git a/examples/amok/saturate/env.c b/examples/amok/saturate/env.c
deleted file mode 100644 (file)
index fc87222..0000000
+++ /dev/null
@@ -1,148 +0,0 @@
-/* saturate - link saturation demo of AMOK features                         */
-
-/* Copyright (c) 2006, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
- * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <signal.h>
-#include <time.h>
-
-#include "gras.h"
-#include "amok/bandwidth.h"
-#include "amok/hostmanagement.h"
-
-XBT_LOG_NEW_DEFAULT_CATEGORY(saturate,
-                             "Messages specific to this example");
-
-static void env_hosttohost_bw(int argc, char *argv[])
-{
-
-  /* where are the sensors */
-  xbt_dynar_t hosts = xbt_dynar_new(sizeof(xbt_host_t), &free_host);
-  int nb_hosts;
-
-  /* results */
-  double sec, bw;
-
-  /* iterators */
-  int i;
-  xbt_host_t h1;
-
-  xbt_socket_t peer;           /* socket to sensor */
-
-  /* wait to ensure that all server sockets are there before starting the experiment */
-  gras_os_sleep(0.5);
-
-  /* Get the sensor location from argc/argv */
-  for (i = 1; i < argc - 1; i += 2) {
-    xbt_host_t host = xbt_new(s_xbt_host_t, 1);
-    host->name = strdup(argv[i]);
-    host->port = atoi(argv[i + 1]);
-    XBT_INFO("New sensor: %s:%d", host->name, host->port);
-    xbt_dynar_push(hosts, &host);
-  }
-  nb_hosts = xbt_dynar_length(hosts);
-
-  XBT_INFO(">>> start Test1: ENV end to end mesurements");
-
-  xbt_dynar_foreach(hosts, i, h1) {
-    peer = gras_socket_client(h1->name, h1->port);
-    amok_bw_test(peer, buf_size, exp_size, msg_size, min_duration, &sec,
-                 &bw);
-    XBT_INFO
-        ("Bandwidth between me and %s:%d (%d bytes in msgs of %d bytes) took %f sec, achieving %.3f kb/s",
-         h1->name, h1->port, exp_size, msg_size, sec,
-         ((double) bw) / 1024.0);
-  }
-
-  xbt_dynar_map(hosts, kill_buddy_dynar);
-  xbt_dynar_free(&hosts);
-
-}
-
-/********************************************************************************************/
-static void env_Pairwisehost_bw(int argc, char *argv[])
-{
-  /* where are the sensors */
-  xbt_dynar_t hosts = xbt_dynar_new(sizeof(xbt_host_t), &free_host);
-  int nb_hosts;
-
-  /* getting the name of maestro for the saturation and the concurrent bandwidth measurements  */
-  char *host_test = argv[0];
-
-  /* results */
-  double sec, bw;
-
-  /* iterators */
-  int i, j;
-  xbt_host_t h1, h2;
-
-  /* socket to sensor */
-  xbt_socket_t peer;
-
-  /* wait to ensure that all server sockets are there before starting the experiment */
-  gras_os_sleep(0.5);
-
-  XBT_INFO(">>>>>< le maestro est: %s ", argv[0]);
-  /* Get the sensor location from argc/argv */
-  for (i = 1; i < argc - 1; i += 2) {
-    xbt_host_t host = xbt_new(s_xbt_host_t, 1);
-    host->name = strdup(argv[i]);
-    host->port = atoi(argv[i + 1]);
-    XBT_INFO("New sensor: %s:%d", host->name, host->port);
-    xbt_dynar_push(hosts, &host);
-  }
-  nb_hosts = xbt_dynar_length(hosts);
-
-  XBT_INFO(">>> start Test2: ENV pairwise host bandwidth mesurements");
-  xbt_dynar_foreach(hosts, i, h1) {
-
-    TRY {
-      amok_bw_saturate_start(h1->name, h1->port, host_test, h1->port,   //"Ginette"
-                             msg_size, 120);    // sturation of the link with msg_size to compute a concurent bandwidth MA //MB
-    }
-    CATCH_ANONYMOUS {
-      RETHROWF("Cannot ask hosts to saturate the link: %s");
-    }
-    // gras_os_sleep(1.0);
-
-    xbt_dynar_foreach(hosts, j, h2) {
-      if (i == j)
-        continue;
-
-      peer = gras_socket_client(h2->name, h2->port);
-      amok_bw_test(peer, buf_size, exp_size, msg_size, min_duration, &sec,
-                   &bw);
-      XBT_INFO
-          ("Bandwidth between me and %s // measurement between me and %s (%d bytes in msgs of %d bytes) took %f sec, achieving %.3f kb/s",
-           h2->name, h1->name, exp_size, msg_size, sec,
-           ((double) bw) / 1024.0);
-
-    }
-    amok_bw_saturate_stop(h1->name, h1->port, NULL, NULL);
-  }
-  xbt_dynar_map(hosts, kill_buddy_dynar);
-  xbt_dynar_free(&hosts);
-
-}
-
-int maestro(int argc, char *argv[])
-{
-
-  gras_init(&argc, argv);
-  amok_bw_init();
-  amok_hm_init();
-
-  gras_socket_server(3333);     /* only so that messages from the transport layer in gras identify us */
-
-  //env_Pairwisehost_bw(argc,argv);
-  //env_hosttohost_bw(argc,argv);
-
-  gras_exit();
-  return 0;
-
-}
diff --git a/examples/amok/saturate/medium_deployment.xml b/examples/amok/saturate/medium_deployment.xml
deleted file mode 100644 (file)
index 7c1146b..0000000
+++ /dev/null
@@ -1,90 +0,0 @@
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
-<platform version="3">
-  <process host="Apple" function="maestro">
-     <argument value="Anne_Marie:4000"/>
-     <argument value="Audy:4000"/>
-     <argument value="Verville:4000"/>
-     <argument value="St_Jean:4000"/>
-     <argument value="PERL:4000"/>
-     <argument value="Charron:4000"/>
-     <argument value="April:4000"/>
-     <argument value="Jocelyne:4000"/>
-     <argument value="Gosselin:4000"/>
-     <argument value="Raymond:4000"/>
-     <argument value="Owen:4000"/>
-     <argument value="St_Antoine:4000"/>
-     <argument value="Gregory:4000"/>
-     <argument value="SunOS:4000"/>
-     <argument value="Laurendeau:4000"/>
-     <argument value="Nelligan:4000"/>
-     <argument value="Lepage:4000"/>
-     <argument value="Jacques_Cartier:4000"/>
-     <argument value="Domey:4000"/>
-     <argument value="Olivier:4000"/>
-     <argument value="Jeannine:4000"/>
-  </process>
-  <process host="Anne_Marie" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Audy" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Verville" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="St_Jean" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="PERL" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Charron" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="April" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Jocelyne" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Gosselin" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Raymond" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Owen" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="St_Antoine" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Gregory" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="SunOS" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Laurendeau" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Nelligan" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Lepage" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Jacques_Cartier" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Domey" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Olivier" function="sensor">
-     <argument value="4000"/>
-  </process>
-  <process host="Jeannine" function="sensor">
-     <argument value="4000"/>
-  </process>
-</platform>
diff --git a/examples/amok/saturate/saturate.c b/examples/amok/saturate/saturate.c
deleted file mode 100644 (file)
index fde8bfc..0000000
+++ /dev/null
@@ -1,285 +0,0 @@
-/* saturate - link saturation demo of AMOK features                         */
-
-/* Copyright (c) 2005, 2006, 2007, 2008, 2009, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
-/* This program is free software; you can redistribute it and/or modify it
- * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <signal.h>
-#include <time.h>
-
-#include "xbt/peer.h"
-#include "gras.h"
-#include "amok/bandwidth.h"
-#include "amok/peermanagement.h"
-
-XBT_LOG_NEW_DEFAULT_CATEGORY(saturate,
-                             "Messages specific to this example");
-
-/* **********************************************************************
- * Sensor code
- * **********************************************************************/
-
-/* Function prototypes */
-int sensor(int argc, char *argv[]);
-
-int sensor(int argc, char *argv[])
-{
-  xbt_socket_t mysock;
-  xbt_socket_t master;
-
-  gras_init(&argc, argv);
-  amok_bw_init();
-  amok_pm_init();
-
-  mysock = gras_socket_server_range(3000, 9999, 0, 0);
-  XBT_INFO("Sensor starting (on port %d)", gras_os_myport());
-  gras_os_sleep(2);             /* let the master get ready */
-  master = gras_socket_client_from_string(argv[1]);
-
-  amok_pm_group_join(master, "saturate");
-  amok_pm_mainloop(600);
-
-  gras_socket_close(mysock);
-  gras_socket_close(master);
-  gras_exit();
-  return 0;
-}
-
-/* **********************************************************************
- * Maestro code
- * **********************************************************************/
-
-/* Function prototypes */
-int maestro(int argc, char *argv[]);
-
-/* XP setups */
-const int buf_size = 0;
-const int msg_size = 50 * 1024;
-const int msg_amount = 2;
-const int sat_size = 1024 * 1024 * 10;
-const double min_duration = 1;
-
-static double XP(const char *bw1, const char *bw2,
-                 const char *sat1, const char *sat2)
-{
-
-  double sec, bw, sec_sat, bw_sat;
-
-  gras_os_sleep(5.0);           /* wait for the sensors to show up */
-  /* Test BW without saturation */
-  amok_bw_request(bw1, 4000, bw2, 4000,
-                  buf_size, msg_size, msg_amount, min_duration, &sec, &bw);
-  XBT_INFO("BW(%s,%s) => %f sec, achieving %f Mb/s",
-        bw1, bw2, sec, (bw / 1024.0 / 1024.0));
-
-
-  /* Test BW with saturation */
-  amok_bw_saturate_start(sat1, 4000, sat2, 4000, sat_size, 60);
-  gras_os_sleep(1.0);           /* let it start */
-
-  amok_bw_request(bw1, 4000, bw2, 4000,
-                  buf_size, msg_size, msg_amount, min_duration, &sec_sat,
-                  &bw_sat);
-  XBT_INFO("BW(%s,%s//%s,%s) => %f sec, achieving %f Mb/s", bw1, bw2, sat1,
-        sat2, sec, bw / 1024.0 / 1024.0);
-
-  amok_bw_saturate_stop(sat1, 4000, NULL, NULL);
-
-  if (bw_sat / bw < 0.7) {
-    XBT_INFO("THERE IS SOME INTERFERENCE !!!");
-  }
-  if (bw / bw_sat < 0.7) {
-    XBT_INFO("THERE IS SOME INTERFERENCE (and I'm an idiot) !!!");
-  }
-  return bw_sat / bw;
-}
-
-static void kill_buddy(char *name, int port)
-{
-  xbt_socket_t sock = gras_socket_client(name, port);
-  gras_msg_send(sock, "kill", NULL);
-  gras_socket_close(sock);
-}
-
-static void kill_buddy_dynar(void *b)
-{
-  xbt_peer_t buddy = *(xbt_peer_t *) b;
-  kill_buddy(buddy->name, buddy->port);
-}
-
-static void free_peer(void *d)
-{
-  xbt_peer_t h = *(xbt_peer_t *) d;
-  free(h->name);
-  free(h);
-}
-
-static void simple_saturation(int argc, char *argv[])
-{
-  xbt_ex_t e;
-
-  /* where are the sensors */
-  xbt_dynar_t peers;
-  xbt_peer_t h1, h2;
-  /* results */
-  double duration, bw;
-
-  /* Init the group */
-  peers = amok_pm_group_new("saturate");
-  /* wait for dudes */
-  gras_msg_handleall(5);
-
-  /* Stop all sensors but two of them */
-  while (xbt_dynar_length(peers) > 2) {
-    xbt_dynar_pop(peers, &h1);
-    amok_pm_kill_hp(h1->name, h1->port);
-    xbt_peer_free(h1);
-  }
-
-  /* get 2 friends */
-  xbt_dynar_get_cpy(peers, 0, &h1);
-  xbt_dynar_get_cpy(peers, 1, &h2);
-
-  /* Start saturation */
-  XBT_INFO("Start saturation between %s:%d and %s:%d",
-        h1->name, h1->port, h2->name, h2->port);
-
-  amok_bw_saturate_start(h1->name, h1->port, h2->name, h2->port, 0,     /* Be a nice boy, compute msg_size yourself */
-                         30 /* 5 sec timeout */ );
-
-  /* Stop it after a while */
-  XBT_INFO("Have a rest");
-  gras_os_sleep(1);
-  TRY {
-    XBT_INFO("Stop the saturation");
-    amok_bw_saturate_stop(h1->name, h1->port, &duration, &bw);
-  }
-  CATCH(e) {
-    XBT_INFO("Ooops, stoping the saturation raised an exception");
-    xbt_ex_free(e);
-  }
-  XBT_INFO("Saturation took %.2fsec, achieving %fb/s", duration, bw);
-
-  /* Game is over, friends */
-  amok_pm_group_shutdown("saturate");
-}
-
-/********************************************************************************************/
-static void full_fledged_saturation(int argc, char *argv[])
-{
-  double time1 = 5.0, bw1 = 5.0;        // 0.5 for test
-  /* timers */
-  double begin_simulated;
-  int begin;
-
-  /* where are the sensors */
-  xbt_dynar_t peers;
-  int nb_peers;
-
-  /* results */
-  double *bw;
-  double *bw_sat;
-
-  /* iterators */
-  unsigned int i, j, k, l;
-  xbt_peer_t h1, h2, h3, h4;
-
-  /* Init the group */
-  peers = amok_pm_group_new("saturate");
-  /* wait 4 dudes */
-  gras_msg_handle(60);
-  gras_msg_handle(60);
-  gras_msg_handle(60);
-  gras_msg_handle(60);
-  nb_peers = xbt_dynar_length(peers);
-
-  XBT_INFO("Let's go for the bw_matrix");
-
-  /* Do the test without saturation */
-  begin = time(NULL);
-  begin_simulated = gras_os_time();
-
-  bw = amok_bw_matrix(peers, buf_size, msg_size, msg_amount, min_duration);
-
-  XBT_INFO("Did all BW tests in %ld sec (%.2f simulated(?) sec)",
-        (long int) (time(NULL) - begin), gras_os_time() - begin_simulated);
-
-  /* Do the test with saturation */
-  bw_sat = xbt_new(double, nb_peers * nb_peers);
-  xbt_dynar_foreach(peers, i, h1) {
-    xbt_dynar_foreach(peers, j, h2) {
-      if (i == j)
-        continue;
-
-      TRY {
-        amok_bw_saturate_start(h1->name, h1->port, h2->name, h2->port, 0,       /* Be nice, compute msg_size yourself */
-                               0 /* no timeout */ );
-      }
-      CATCH_ANONYMOUS {
-        RETHROWF("Cannot ask peers to saturate the link: %s");
-      }
-      gras_os_sleep(5);
-
-      begin = time(NULL);
-      begin_simulated = gras_os_time();
-      xbt_dynar_foreach(peers, k, h3) {
-        if (i == k || j == k)
-          continue;
-
-        xbt_dynar_foreach(peers, l, h4) {
-          double ratio;
-          if (i == l || j == l || k == l)
-            continue;
-
-          XBT_VERB("TEST %s %s // %s %s",
-                h1->name, h2->name, h3->name, h4->name);
-          amok_bw_request(h3->name, h3->port, h4->name, h4->port,
-                          buf_size, msg_size, msg_amount, min_duration,
-                          NULL, &(bw_sat[k * nb_peers + l]));
-
-          ratio = bw_sat[k * nb_peers + l] / bw[k * nb_peers + l];
-          XBT_INFO("SATURATED BW XP(%s %s // %s %s) => %f (%f vs %f)%s",
-                h1->name, h2->name, h3->name, h4->name,
-                ratio,
-                bw[k * nb_peers + l], bw_sat[k * nb_peers + l],
-                ratio < 0.7 ? " THERE IS SOME INTERFERENCE !!!" : "");
-        }
-      }
-      amok_bw_saturate_stop(h1->name, h1->port, &time1, &bw1);
-
-      XBT_INFO
-          ("Did an iteration on saturation pair in %ld sec (%.2f simulated sec)",
-           (long int) (time(NULL) - begin),
-           gras_os_time() - begin_simulated);
-      XBT_INFO
-          ("the duration of the experiment >>>>> %.3f sec (%.3f bandwidth)",
-           time1, bw1);
-    }
-  }
-  free(bw_sat);
-  free(bw);
-  /* Game is over, friends */
-  amok_pm_group_shutdown("saturate");
-}
-
-
-int maestro(int argc, char *argv[])
-{
-
-  gras_init(&argc, argv);
-  amok_bw_init();
-  amok_pm_init();
-
-  gras_socket_server(atoi(argv[1]));
-
-  simple_saturation(argc, argv);
-  //full_fledged_saturation(argc, argv);  
-
-  gras_exit();
-  return 0;
-
-}
diff --git a/examples/amok/saturate/saturate.xml b/examples/amok/saturate/saturate.xml
deleted file mode 100644 (file)
index 965663e..0000000
+++ /dev/null
@@ -1,12 +0,0 @@
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
-<platform version="3">
-
-  <process host="Tremblay" function="sensor">  <argument value="Bourassa:4000"/> </process>
-  <process host="Jupiter"  function="sensor">  <argument value="Bourassa:4000"/> </process>
-  <process host="Fafard"   function="sensor">  <argument value="Bourassa:4000"/> </process>
-  <process host="Ginette"  function="sensor">  <argument value="Bourassa:4000"/> </process>
-
-  <process host="Bourassa" function="maestro"> <argument value="4000"/>          </process>
-
-</platform>
diff --git a/examples/amok/saturate/saturate_rl.tesh b/examples/amok/saturate/saturate_rl.tesh
deleted file mode 100755 (executable)
index f9d57d2..0000000
+++ /dev/null
@@ -1,14 +0,0 @@
-! timeout 20
-& $SG_TEST_ENV saturate/saturate_sensor$EXEEXT 127.0.0.1:3333 "--log=root.fmt=%P:%t%e%m%n"
-
-! timeout 20
-& $SG_TEST_ENV saturate/saturate_sensor$EXEEXT 127.0.0.1:3333 "--log=root.fmt=%P:%t%e%m%n"
-
-! timeout 20
-& $SG_TEST_ENV saturate/saturate_sensor$EXEEXT 127.0.0.1:3333 "--log=root.fmt=%P:%t%e%m%n"
-
-! timeout 20
-& $SG_TEST_ENV saturate/saturate_sensor$EXEEXT 127.0.0.1:3333 "--log=root.fmt=%P:%t%e%m%n"
-
-! timeout 20
-& $SG_TEST_ENV saturate/saturate_maestro$EXEEXT 3333 "--log=root.fmt=%P:%t%e%m%n"
diff --git a/examples/amok/saturate/saturate_sg_32.tesh b/examples/amok/saturate/saturate_sg_32.tesh
deleted file mode 100644 (file)
index df0b549..0000000
+++ /dev/null
@@ -1,17 +0,0 @@
-$ $SG_TEST_EXENV saturate/saturate_simulator${EXEEXT} ${srcdir:=.}/../msg/small_platform.xml ${srcdir:=.}/saturate/saturate.xml
-> [Tremblay:sensor:(1) 0.000156] [saturate/INFO] Sensor starting (on port 3000)
-> [Ginette:sensor:(4) 0.000156] [saturate/INFO] Sensor starting (on port 3000)
-> [Fafard:sensor:(3) 0.000156] [saturate/INFO] Sensor starting (on port 3000)
-> [Jupiter:sensor:(2) 0.000156] [saturate/INFO] Sensor starting (on port 3000)
-> [Jupiter:sensor:(2) 5.035848] [gras/INFO] Exiting GRAS
-> [Bourassa:maestro:(5) 5.041416] [saturate/INFO] Start saturation between Tremblay:3000 and Ginette:3000
-> [Fafard:sensor:(3) 5.041416] [gras/INFO] Exiting GRAS
-> [Bourassa:maestro:(5) 5.082248] [saturate/INFO] Have a rest
-> [Bourassa:maestro:(5) 6.082248] [saturate/INFO] Stop the saturation
-> [Tremblay:sensor:(1) 7.200171] [amok_bw_sat/INFO] Saturation(Tremblay:3000->Ginette:3000) started
-> [Tremblay:sensor:(1) 13.188984] [amok_bw_sat/INFO] Saturation from Tremblay:3000 to Ginette:3000 stopped by Bourassa:4000
-> [Bourassa:maestro:(5) 13.209324] [saturate/INFO] Saturation took 5.99sec, achieving 1280588.867148b/s
-> [Tremblay:sensor:(1) 13.229816] [gras/INFO] Exiting GRAS
-> [Bourassa:maestro:(5) 13.242860] [gras/INFO] Exiting GRAS
-> [Ginette:sensor:(4) 73.188984] [amok_bw_sat/INFO] Saturation comming from Tremblay:3000 stopped on Ginette:3000
-> [Ginette:sensor:(4) 73.188984] [gras/INFO] Exiting GRAS
diff --git a/examples/amok/saturate/saturate_sg_64.tesh b/examples/amok/saturate/saturate_sg_64.tesh
deleted file mode 100644 (file)
index ea4ee30..0000000
+++ /dev/null
@@ -1,17 +0,0 @@
-$ $SG_TEST_EXENV saturate/saturate_simulator${EXEEXT} ${srcdir:=.}/../msg/small_platform.xml ${srcdir:=.}/saturate/saturate.xml
-> [Tremblay:sensor:(1) 0.000156] [saturate/INFO] Sensor starting (on port 3000)
-> [Ginette:sensor:(4) 0.000156] [saturate/INFO] Sensor starting (on port 3000)
-> [Fafard:sensor:(3) 0.000156] [saturate/INFO] Sensor starting (on port 3000)
-> [Jupiter:sensor:(2) 0.000156] [saturate/INFO] Sensor starting (on port 3000)
-> [Jupiter:sensor:(2) 5.035848] [gras/INFO] Exiting GRAS
-> [Bourassa:maestro:(5) 5.041416] [saturate/INFO] Start saturation between Tremblay:3000 and Ginette:3000
-> [Fafard:sensor:(3) 5.041416] [gras/INFO] Exiting GRAS
-> [Bourassa:maestro:(5) 5.082248] [saturate/INFO] Have a rest
-> [Bourassa:maestro:(5) 6.082248] [saturate/INFO] Stop the saturation
-> [Tremblay:sensor:(1) 7.200177] [amok_bw_sat/INFO] Saturation(Tremblay:3000->Ginette:3000) started
-> [Tremblay:sensor:(1) 13.188990] [amok_bw_sat/INFO] Saturation from Tremblay:3000 to Ginette:3000 stopped by Bourassa:4000
-> [Bourassa:maestro:(5) 13.209330] [saturate/INFO] Saturation took 5.99sec, achieving 1280588.867148b/s
-> [Tremblay:sensor:(1) 13.229822] [gras/INFO] Exiting GRAS
-> [Bourassa:maestro:(5) 13.242866] [gras/INFO] Exiting GRAS
-> [Ginette:sensor:(4) 73.188990] [amok_bw_sat/INFO] Saturation comming from Tremblay:3000 stopped on Ginette:3000
-> [Ginette:sensor:(4) 73.188990] [gras/INFO] Exiting GRAS
diff --git a/examples/gras/all2all/CMakeLists.txt b/examples/gras/all2all/CMakeLists.txt
deleted file mode 100644 (file)
index 18b5c1d..0000000
+++ /dev/null
@@ -1,57 +0,0 @@
-cmake_minimum_required(VERSION 2.6)
-
-set_source_files_properties(
-  ${CMAKE_CURRENT_BINARY_DIR}/_all2all_simulator.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_all2all_sender.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_all2all_receiver.c
-  PROPERTIES GENERATED true
-  )
-
-set(EXECUTABLE_OUTPUT_PATH "${CMAKE_CURRENT_BINARY_DIR}")
-add_executable(all2all_simulator ${CMAKE_CURRENT_BINARY_DIR}/_all2all_simulator.c ${CMAKE_CURRENT_SOURCE_DIR}/all2all.c)
-add_executable(all2all_sender    ${CMAKE_CURRENT_BINARY_DIR}/_all2all_sender.c ${CMAKE_CURRENT_SOURCE_DIR}/all2all.c)
-add_executable(all2all_receiver  ${CMAKE_CURRENT_BINARY_DIR}/_all2all_receiver.c ${CMAKE_CURRENT_SOURCE_DIR}/all2all.c)
-
-add_custom_command(
-  OUTPUT       ${CMAKE_CURRENT_BINARY_DIR}/_all2all_simulator.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_all2all_sender.c
-  ${CMAKE_CURRENT_BINARY_DIR}/_all2all_receiver.c
-  DEPENDS gras_stub_generator ${CMAKE_CURRENT_SOURCE_DIR}/all2all.xml
-  COMMAND ${CMAKE_BINARY_DIR}/bin/gras_stub_generator all2all ${CMAKE_CURRENT_SOURCE_DIR}/all2all.xml
-  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
-  )
-
-### Add definitions for compile
-if(NOT WIN32)
-  target_link_libraries(all2all_simulator simgrid pthread m)
-  target_link_libraries(all2all_sender gras pthread m)
-  target_link_libraries(all2all_receiver gras pthread m)
-else()
-  target_link_libraries(all2all_simulator simgrid)
-  target_link_libraries(all2all_sender gras)
-  target_link_libraries(all2all_receiver gras)
-endif()
-
-set(tesh_files
-  ${tesh_files}
-  ${CMAKE_CURRENT_SOURCE_DIR}/test_rl.tesh
-  ${CMAKE_CURRENT_SOURCE_DIR}/test_sg_32.tesh
-  ${CMAKE_CURRENT_SOURCE_DIR}/test_sg_64.tesh
-  PARENT_SCOPE
-  )
-set(xml_files
-  ${xml_files}
-  ${CMAKE_CURRENT_SOURCE_DIR}/all2all.xml
-  PARENT_SCOPE
-  )
-set(examples_src
-  ${examples_src}
-  ${CMAKE_CURRENT_SOURCE_DIR}/all2all.c
-  PARENT_SCOPE
-  )
-set(bin_files
-  ${bin_files}
-  ${CMAKE_CURRENT_SOURCE_DIR}/make_deployment.pl
-  ${CMAKE_CURRENT_SOURCE_DIR}/run.sh
-  PARENT_SCOPE
-  )
diff --git a/examples/gras/all2all/all2all.c b/examples/gras/all2all/all2all.c
deleted file mode 100644 (file)
index 7872303..0000000
+++ /dev/null
@@ -1,146 +0,0 @@
-/* ALL2ALL - all2all of GRAS features                                       */
-
-/* Copyright (c) 2006, 2007, 2009, 2010. The SimGrid Team.
- * All rights reserved.                                                     */
-
- /* This program is free software; you can redistribute it and/or modify it
-  * under the terms of the license (GNU LGPL) which comes with this package. */
-
-#include "gras.h"
-#include "xbt/ex.h"
-
-XBT_LOG_NEW_DEFAULT_CATEGORY(all2all, "Messages specific to this example");
-
-/* register data which may be sent (common to client and server) */
-static void register_messages(void)
-{
-}
-
-/* Function prototypes */
-int receiver(int argc, char *argv[]);
-int sender(int argc, char *argv[]);
-
-
-/* **********************************************************************
- * Receiver code
- * **********************************************************************/
-int receiver(int argc, char *argv[])
-{
-
-  int myport;                   /* port on which I receive stuff */
-  int todo;                     /* amount of messages I should get */
-  char *data;                   /* message content */
-
-  xbt_socket_t mysock;         /* socket on which other people contact me */
-  xbt_socket_t expeditor;      /* to notice who wrote me */
-
-  /* Init the GRAS infrastructure and declare my globals */
-  gras_init(&argc, argv);
-
-  /* Get my settings from the command line */
-  myport = atoi(argv[1]);
-  todo = atoi(argv[2]);
-
-  /* Register the known messages */
-  gras_msgtype_declare("data", xbt_datadesc_by_name("string"));
-
-  /* Create my master socket */
-  mysock = gras_socket_server(myport);
-
-  /* Get the data */
-  XBT_INFO("Listening on port %d (expecting %d messages)",
-        xbt_socket_my_port(mysock), todo);
-  while (todo > 0) {
-    gras_msg_wait(60 /* wait up to one minute */ ,
-                  "data", &expeditor, &data);
-    todo--;
-    free(data);
-
-    XBT_INFO("Got Data from %s:%d (still %d to go)",
-          xbt_socket_peer_name(expeditor),
-          xbt_socket_peer_port(expeditor), todo);
-
-  }
-
-  /* Free the allocated resources, and shut GRAS down */
-  gras_socket_close(mysock);
-
-  gras_exit();
-  return 0;
-}                               /* end_of_receiver */
-
-/* **********************************************************************
- * Sender code
- * **********************************************************************/
-
-int sender(int argc, char *argv[])
-{
-
-  unsigned int iter;            /* iterator */
-  char *data;                   /* data exchanged */
-  int datasize;                 /* size of message */
-  xbt_peer_t h;                 /* iterator */
-  int connected = 0;
-
-  volatile xbt_socket_t peer = NULL;    /* socket to node */
-
-
-  /* xbt_dynar for peers */
-  xbt_dynar_t peers =
-      xbt_dynar_new(sizeof(xbt_peer_t), &xbt_peer_free_voidp);
-
-  /* Init the GRAS infrastructure and declare my globals */
-  gras_init(&argc, argv);
-
-  /* Get the node location from argc/argv */
-  for (iter = 1; iter < argc - 1; iter++) {
-    xbt_peer_t peer = xbt_peer_from_string(argv[iter]);
-    xbt_dynar_push(peers, &peer);
-  }
-
-  datasize = atoi(argv[argc - 1]);
-
-  data = (char *) malloc(datasize + 1); // allocation of datasize octets
-  memset(data, 32, datasize);
-  data[datasize] = '\0';
-
-  XBT_INFO("Launch current node");
-
-  /* Register the known messages */
-  gras_msgtype_declare("data", xbt_datadesc_by_name("string"));
-
-
-  /* write to the receivers */
-  xbt_dynar_foreach(peers, iter, h) {
-    connected = 0;
-    while (!connected) {
-      xbt_ex_t e;
-      TRY {
-        peer = gras_socket_client(h->name, h->port);
-        connected = 1;
-      }
-      CATCH(e) {
-        if (e.category != system_error  /*in RL */
-            && e.category != mismatch_error /*in SG */ )
-          RETHROW;
-        xbt_ex_free(e);
-        gras_os_sleep(0.01);
-      }
-    }
-    gras_msg_send(peer, "data", &data);
-    if (gras_if_SG()) {
-      XBT_INFO("  Sent Data from %s to %s", gras_os_myname(), h->name);
-    } else {
-      XBT_INFO("  Sent Data");
-    }
-
-    gras_socket_close(peer);
-  }
-
-  /* Free the allocated resources, and shut GRAS down */
-  free(data);
-  xbt_dynar_free(&peers);
-
-  gras_exit();
-  return 0;
-}                               /* end_of_sender */
diff --git a/examples/gras/all2all/all2all.xml b/examples/gras/all2all/all2all.xml
deleted file mode 100644 (file)
index 0eed86f..0000000
+++ /dev/null
@@ -1,74 +0,0 @@
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
-<platform version="3">
-  <!-- For each host, we have a sender and a receiver (because we use a
-       1-port model and still don't want any deadlocks neither synchronization
-       delays).
-       Sender arguments = receiver peer + Message size as last argument (in byte)
-       Receiver arguments: amount of incoming messages expected -->
-
-
-  <process host="Tremblay" function="sender">
-     <argument value="Jupiter:4000"/>
-     <argument value="Fafard:4000"/> 
-     <argument value="Ginette:4000"/> 
-     <argument value="Bourassa:4000"/> 
-     <argument value="512"/>
-  </process>
-  <process host="Tremblay" function="receiver">
-     <argument value="4000"/>
-     <argument value="4"/>  
-  </process>
-
-
-  <process host="Jupiter" function="sender">
-     <argument value="Tremblay:4000"/> 
-     <argument value="Fafard:4000"/> 
-     <argument value="Ginette:4000"/> 
-     <argument value="Bourassa:4000"/> 
-     <argument value="512"/>
-  </process>
-  <process host="Jupiter" function="receiver">
-     <argument value="4000"/>
-     <argument value="4"/>
-  </pr