doc: minor fixes

doc/doxygen/chapters/350_scheduling_policy_definition.doxy

@@ -52,7 +52,7 @@ useful functions include starpu_transfer_bandwidth(), starpu_transfer_latency(),
 starpu_transfer_predict(), ...
 One can also directly test the presence of a data handle with starpu_data_is_on_node(). Prefetches can be triggered by calling starpu_prefetch_task_input_for(). 
 starpu_get_prefetch_flag() is a convenient helper for checking the value of the 
-STARPU_PREFETCH environment variable.
+\ref STARPU_PREFETCH environment variable.
 
 Usual functions can be used on tasks, for instance one can use the following to
 get the data size for a task.
@@ -104,7 +104,7 @@ scheduler to implement what is between. A simple eager scheduler is for instance
 to make starpu_sched_policy::push_task push the task to a global list, and make
 starpu_sched_policy::pop_task pop from this list. A scheduler can also use
 starpu_push_local_task() to directly push tasks to a per-worker queue, and then
-starpu_does not even need to implement starpu_sched_policy::pop_task.
+starpu does not even need to implement starpu_sched_policy::pop_task.
 If there are no ready tasks within the scheduler, it can just return \c NULL, and
 the worker will sleep.
 
@@ -290,7 +290,7 @@ Scheduler :
         Modularized Scheduler, to store incoming tasks from StarPU. It can for
         instance be a global component at the top of the tree, or one component
         per worker at the bottom of the tree, or intermediate assemblies. The
-        important point is that the starpu_push_task() call at the top can not
+        important point is that the starpu_sched_component::push_task call at the top can not
         fail, so there has to be a storage component without threshold between
         the top of the tree and the first storage component with threshold, or
         the workers themselves.
@@ -450,7 +450,7 @@ struct starpu_sched_policy _starpu_sched_tree_eager_prefetching_policy =
 };
 \endcode
 
-Other modular scheduler examples can be seen in \c src/sched_policies/modular_*.c
+Other modular scheduler examples can be seen in <c>src/sched_policies/modular_*.c</c>
 
 For instance, \c modular-heft-prio needs performance models, decides
 memory nodes, uses prioritized fifos above and below, and decides the best
@@ -458,7 +458,7 @@ implementation.
 
 If unsure on the result of the modular scheduler construction, you can run a
 simple application with FxT enabled (see \ref GeneratingTracesWithFxT), and open
-trace.html in a web-browser.
+the generated file \c trace.html in a web-browser.
 
 \subsection WriteASchedulingComponent Writing a Scheduling Component
 
@@ -476,10 +476,10 @@ not implement the Push function.
 A Scheduling Component must implement all the functions of the Interface. It is
 so necessary to implement a Push function to instantiate a Scheduling Component.
 The implemented Push function is the "fingerprint" of a Scheduling Component.
-Depending on how functionalities or properties the programmer wants to give
-to the Scheduling Component he is implementing, it is possible to reimplement
+Depending on how functionalities or properties programmers want to give
+to the Scheduling Component they are implementing, it is possible to reimplement
 all the functions of the Interface. For example, a Flow-control Component
-reimplements the Pull and the Can_Push functions of the Interface, allowing him
+reimplements the Pull and the Can_Push functions of the Interface, allowing 
 to catch the generic recursive calls of these functions. The Pull function of
 a Flow-control Component can, for example, pop a task from the local storage
 queue of the Component, and give it to the calling Component which asks for it.
@@ -553,7 +553,7 @@ The idea is that while the application submits tasks, they are only pushed
 to a bag of tasks. When the application is finished with submitting tasks,
 it calls starpu_do_schedule() (or starpu_task_wait_for_all(), which calls
 starpu_do_schedule()), and the starpu_sched_policy::do_schedule method of the
-scheduler is called. This method calls _starpu_graph_compute_depths to compute
+scheduler is called. This method calls \c _starpu_graph_compute_depths() to compute
 the bottom-up ranks, and then uses these ranks to set priorities over tasks.
 
 It then has two priority queues, one for CPUs, and one for GPUs, and uses a dumb

doc/doxygen/chapters/370_online_performance_tools.doxy

@@ -494,7 +494,7 @@ application actually has a very good idea of the complexity of the algorithm,
 and just not the speed of the processor, etc.  The example in the directory
 <c>examples/pi</c> uses this to include the number of iterations in the base
 size. starpu_perfmodel::size_base should be used when the variance of the actual
-performance is known (i.e. bigger returned value is longer execution
+performance is known (i.e. bigger return value is longer execution
 time), and thus particularly useful for ::STARPU_REGRESSION_BASED or
 ::STARPU_NL_REGRESSION_BASED. starpu_perfmodel::footprint can be used when the
 variance of the actual performance is unknown (irregular performance behavior,

doc/doxygen/chapters/api/data_management.doxy

@@ -1,7 +1,7 @@
 /* StarPU --- Runtime system for heterogeneous multicore architectures.
  *
  * Copyright (C) 2011,2012,2017                           Inria
- * Copyright (C) 2010-2018                                CNRS
+ * Copyright (C) 2010-2019                                CNRS
  * Copyright (C) 2009-2011,2014-2017,2019                 Université de Bordeaux
  *
  * StarPU is free software; you can redistribute it and/or modify
@@ -243,7 +243,7 @@ block until the transfer is achieved, else the call will return immediately,
 after having just queued the request. In the latter case, the request will
 asynchronously wait for the completion of any task writing on the data.
 
-\fn int starpu_data_is_on_node(starpu_data_handle_t handle, int node)
+\fn unsigned starpu_data_is_on_node(starpu_data_handle_t handle, unsigned node)
 \ingroup API_Data_Management
 Check whether a valid copy of \p handle is currently available on memory node \p
 node .

doc/doxygen/chapters/api/scheduling_contexts.doxy

@@ -190,13 +190,13 @@ possible.
 
 \fn unsigned starpu_sched_ctx_get_workers_list(unsigned sched_ctx_id, int **workerids)
 \ingroup API_Scheduling_Contexts
-Return the list of workers in the array \p workerids, the returned value is the
+Return the list of workers in the array \p workerids, the return value is the
 number of workers. The user should free the \p workerids table after finishing
 using it (it is allocated inside the function with the proper size)
 
 \fn unsigned starpu_sched_ctx_get_workers_list_raw(unsigned sched_ctx_id, int **workerids)
 \ingroup API_Scheduling_Contexts
-Return the list of workers in the array \p workerids, the returned value is the
+Return the list of workers in the array \p workerids, the return value is the
 number of workers. This list is provided in raw order, i.e. not sorted by tree or list order,
 and the user should not free the \p workerids table.
 This function is thus much less costly than starpu_sched_ctx_get_workers_list().

doc/doxygen/chapters/api/workers.doxy

@@ -167,7 +167,7 @@ todo
 \fn unsigned starpu_worker_get_count(void)
 \ingroup API_Workers_Properties
 Return the number of workers (i.e. processing units executing StarPU
-tasks). The returned value should be at most \ref STARPU_NMAXWORKERS.
+tasks). The return value should be at most \ref STARPU_NMAXWORKERS.
 
 \fn int starpu_worker_get_count_by_type(enum starpu_worker_archtype type)
 \ingroup API_Workers_Properties
@@ -177,11 +177,11 @@ indicates that \p type is not valid otherwise.
 
 \fn unsigned starpu_cpu_worker_get_count(void)
 \ingroup API_Workers_Properties
-Return the number of CPUs controlled by StarPU. The returned value should be at most \ref STARPU_MAXCPUS.
+Return the number of CPUs controlled by StarPU. The return value should be at most \ref STARPU_MAXCPUS.
 
 \fn unsigned starpu_cuda_worker_get_count(void)
 \ingroup API_Workers_Properties
-Return the number of CUDA devices controlled by StarPU. The returned value should be at most \ref STARPU_MAXCUDADEVS.
+Return the number of CUDA devices controlled by StarPU. The return value should be at most \ref STARPU_MAXCUDADEVS.
 
 \fn unsigned starpu_mic_worker_get_count(void)
 \ingroup API_Workers_Properties
@@ -189,7 +189,7 @@ Return the number of MIC workers controlled by StarPU.
 
 \fn unsigned starpu_mic_device_get_count(void)
 \ingroup API_Workers_Properties
-Return the number of MIC devices controlled by StarPU. The returned value should be at most \ref STARPU_MAXMICDEVS.
+Return the number of MIC devices controlled by StarPU. The return value should be at most \ref STARPU_MAXMICDEVS.
 
 \fn unsigned starpu_mpi_ms_worker_get_count(void)
 \ingroup API_Workers_Properties
@@ -197,16 +197,16 @@ Return the number of MPI Master Slave workers controlled by StarPU.
 
 \fn unsigned starpu_scc_worker_get_count(void)
 \ingroup API_Workers_Properties
-Return the number of SCC devices controlled by StarPU. The returned value should be at most \ref STARPU_MAXSCCDEVS.
+Return the number of SCC devices controlled by StarPU. The return value should be at most \ref STARPU_MAXSCCDEVS.
 
 \fn unsigned starpu_opencl_worker_get_count(void)
 \ingroup API_Workers_Properties
-Return the number of OpenCL devices controlled by StarPU. The returned value should be at most \ref STARPU_MAXOPENCLDEVS.
+Return the number of OpenCL devices controlled by StarPU. The return value should be at most \ref STARPU_MAXOPENCLDEVS.
 
 \fn int starpu_worker_get_id(void)
 \ingroup API_Workers_Properties
 Return the identifier of the current worker, i.e the one associated to
-the calling thread. The returned value is either \c -1 if the current
+the calling thread. The return value is either \c -1 if the current
 context is not a StarPU worker (i.e. when called from the application
 outside a task or a callback), or an integer between \c 0 and
 starpu_worker_get_count() - \c 1.
@@ -214,13 +214,13 @@ starpu_worker_get_count() - \c 1.
 \fn unsigned starpu_worker_get_id_check(void)
 \ingroup API_Workers_Properties
 Similar to starpu_worker_get_id(), but abort when called from outside
-a worker (i.e. when starpu_worker_get_id() would return -1).
+a worker (i.e. when starpu_worker_get_id() would return \c -1).
 
 \fn unsigned starpu_worker_get_ids_by_type(enum starpu_worker_archtype type, int *workerids, unsigned maxsize)
 \ingroup API_Workers_Properties
 Get the list of identifiers of workers of \p type. Fill the array \p
 workerids with the identifiers of the \p workers. The argument \p
-maxsize indicates the size of the array \p workerids. The returned
+maxsize indicates the size of the array \p workerids. The return
 value gives the number of identifiers that were put in the array.
 <c>-ERANGE</c> is returned is \p maxsize is lower than the number of workers
 with the appropriate type: in that case, the array is filled with the
@@ -267,7 +267,7 @@ worker identifier is a value returned by the function
 starpu_worker_get_id()). The return value indicates the architecture
 of the worker: ::STARPU_CPU_WORKER for a CPU core,
 ::STARPU_CUDA_WORKER for a CUDA device, and ::STARPU_OPENCL_WORKER for
-a OpenCL device. The value returned for an invalid identifier is
+a OpenCL device. The return value for an invalid identifier is
 unspecified.
 
 \fn void starpu_worker_get_name(int id, char *dst, size_t maxlen)