Skip to content
GitLab
Commit 1bb9836f authored by Roland Levillain's avatar Roland Levillain
Browse files

Move the Olena-NG components from trunk/ to branches/olena-ng/. 


trunk/ChangeLog

	Move the Olena-NG components elsewhere.

	* dynamic/,
	* extended/,
	* metalic/,
	* olena/,
	* static/:
	Remove directories.
	* configure.ac: Adjust.
	* Makefile.am (SUBDIRS): Remove metalic, extended, static, olena
	and dynamic.
	* TODO: Remove irrelevant entries.
	* NEWS: Add information on the 0.11 release.
	More on the upcoming 1.0 release.


branches/olena-ng/ChangeLog

	Move Milena out of the Olena-NG tree.

	* milena/: Remove directory.
	* configure.ac: Adjust.
	* Makefile.am (SUBDIRS): Remove milena.
	* TODO: Remove irrelevant entries.
	* NEWS: Add information on the 0.11 release.



git-svn-id: https://svn.lrde.epita.fr/svn/oln/trunk@1534 4aad255d-cdde-0310-9447-f3009e2ae8c0
parent e0d2422e
Hide whitespace changes
Inline Side-by-side
ChangeLog
View file @ 1bb9836f
2007-11-26 Roland Levillain <roland@lrde.epita.fr>
Move the Olena-NG components elsewhere.
* dynamic/,
* extended/,
* metalic/,
* olena/,
* static/:
Remove directories.
* configure.ac: Adjust.
* Makefile.am (SUBDIRS): Remove metalic, extended, static, olena
and dynamic.
* TODO: Remove irrelevant entries.
* NEWS: Add information on the 0.11 release.
More on the upcoming 1.0 release.
2007-11-23 Simon Nivault <simon.nivault@lrde.epita.fr>
Remove creation of makefile in tests/make.
......
Makefile.am
View file @ 1bb9836f
......@@ -2,4 +2,4 @@
ACLOCAL_AMFLAGS = -I build-aux
SUBDIRS = build-aux metalic extended static milena olena dynamic
SUBDIRS = build-aux milena
NEWS
View file @ 1bb9836f
Olena 1.0
* SCOOP 2 paradigm.
* Rewritten from scratch.
* First release of the Olena Platform with Milena as the
central library.
* Milena uses a simplified version of the SCOOP 2 paradigm, to
improve the speed of compilation and the ease of development
while still providing very good run-time performances.
Olena 0.11 February 21, 2007
* The whole Olena distribution compiles with the GNU C++
Compiler (G++) 4.0 and 4.1. The compatibility with previous
versions of the compiler has been broken.
* Revamp of Swilena.
The Swilena wrappers have been repaired, as they had become
incompatible with recent versions of SWIG, G++, Python and Ruby.
Moreover, a lot of small bugs have been fixed in Swilena.
The test suite of Rblena, the Ruby wrappers for Olena, has
been completed and is comparable to Pylena's (the Python
wrappers for Olena).
* Libtool.
The whole package uses GNU Libtool to handle libraries.
Swilena benefits this, and uses Libtool to create shared
libraries upon which SWIG wrappers are built.
* Miscellaneous corrections in Olena and Integre, as well as in
their test suites.
Olena 0.10 April 15, 2004
......
TODO
View file @ 1bb9836f
See also the TODO in oln-proto-1.0 and oln-proto-stl-style.
See also the TODOs in oln-proto-1.0 and oln-proto-stl-style.
* Clean up
......@@ -55,10 +55,8 @@ should be turned into these:
appropriate than OLN_INCLUDE_ONLY.)
** Update the address of the FSF in Copyright notices (write a script)
** Check dates for every copyright header
Use the repository of Olena 0.10 (and previous) and Olena proto-1.0 to
Use the repository of Olena 0.11 (and previous) and Olena proto-1.0 to
find when files have been created and modified. This task could be a
part of the code review process.
......@@ -71,7 +69,10 @@ of one or some of its components.
The tests should print nothing on the stantard output, nor on the
standard error.
** Add the UPGRADING file from oln-0.10 and complete it
** Add the UPGRADING file from Olena 0.11 and complete it
N.B.: This file is generated.
We might want to break the pseudo-compatibility with Olena 0.x, and
get rid of UPGRADING.
Local Variables:
......
configure.ac
View file @ 1bb9836f
......@@ -46,14 +46,6 @@ if test "$GXX" = yes && test -z "$TESTS_CXXFLAGS"; then
fi
## ----------------------------- ##
## Concept C++ compiler set up. ##
## ----------------------------- ##
AC_ARG_VAR([CONCEPTCXX], [Concept C++ compiler])
AC_CHECK_PROGS([CONCEPTCXX], [conceptg++ conceptc++])
## -------------- ##
## Dependencies. ##
## -------------- ##
......@@ -63,18 +55,6 @@ OLN_WITH_FREEIMAGEPLUS
AM_CONDITIONAL([FREEIMAGEPLUS], [test x$oln_have_freeimageplus = xyes])
## ------- ##
## Tests. ##
## ------- ##
AC_CONFIG_FILES([
metalic/tests/Makefile
extended/tests/Makefile
static/tests/Makefile
olena/tests/Makefile
])
## --------------- ##
## Configuration. ##
## --------------- ##
......@@ -85,26 +65,16 @@ AM_CONFIG_HEADER([config.h])
# Ask for the Makefile creations.
AC_CONFIG_FILES([
Makefile
metalic/Makefile
metalic/mlc/Makefile
extended/Makefile
extended/xtd/Makefile
static/Makefile
static/stc/Makefile
static/samples/Makefile
static/samples/mini-oln/Makefile
static/samples/mini-oln/concept-c++/Makefile
static/samples/mini-std/Makefile
static/samples/mini-std/cpp/Makefile
static/samples/mini-std/cpp2/Makefile
milena/Makefile
milena/doc/Makefile
olena/Makefile
olena/oln/Makefile
olena/img/Makefile
dynamic/Makefile
])
# FIXME: Should be performed through oln.m4 macros.
## ------- ##
## Tests. ##
## ------- ##
# FIXME: Should be performed through oln.m4 macros?
AC_CONFIG_FILES([
milena/tests/Makefile
milena/tests/norm/Makefile
......@@ -161,17 +131,5 @@ AC_CONFIG_FILES([
milena/tests/display/Makefile
milena/tests/labeling/Makefile
])
AC_CONFIG_FILES([
olena/tests/algorithms/Makefile
olena/tests/check/Makefile
olena/tests/check/defs
olena/tests/core/Makefile
olena/tests/io/Makefile
olena/tests/morphers/Makefile
olena/tests/sanity/Makefile
olena/tests/value/Makefile
])
AC_CONFIG_FILES([olena/tests/sanity/check],
[chmod +x olena/tests/sanity/check])
AC_OUTPUT
dynamic/ChangeLog deleted 100644 → 0
View file @ e0d2422e
2006-09-14 Roland Levillain <roland@lrde.epita.fr>
Equip Dynamic with a Makefile.
* Makefile.am: New file.
dynamic/Makefile.am deleted 100644 → 0
View file @ e0d2422e
## Process this file through Automake to create Makefile.in -*- Makefile -*-
EXTRA_DIST = doc/rough.txt
dynamic/doc/rough.txt deleted 100644 → 0
View file @ e0d2422e
-*- outline -*-
* forwords
** subject
dyn!
** intents
compile C++ static library components at run-time
safe compile time when dev cycle
** naming
lib: the static library concerned by users
dyn: the library we provide to ease the use of lib
* actors
** lib user in C++, thru dyn, without a dyn|lib interface
*** direct C++ user
writes a C++ program using a static library (lib) + use of dyn facilities
instead of direct use of lib contents
nota: can use both (FIXME: explain)
she does not want to write lib types (such as image2d<int> or more
complex ones); instead she write dyn::var, a more general type for
data. calling an algorithm is performed thru dyn,
e,g,. dyn::call("algo").
** lib user in C++, thru dyn, with a dyn|lib interface
*** C++ interface user
FIXME
** mix user in C++; so use both dyn and lib, but with a dyn|lib interface
** mix user in C++; so use both dyn and lib, but without a dyn|lib interface
** cmd line user (no interface created)
FIXME
** cmd line user (an interface has been created)
FIXME
** global administrator
*** lab admin
when used in a lab, it installs the lib (and optionally the interface
dyn|lib), creates a repository for binaries, chooses a policy to
manage the repository, allows clients to access this pool and perform
some tasks (for instance extend the binary pool thanks to a gui), and
manage the pool.
** individual administrator
use local pool so performs local operations
** lib developer
*** lib dev
she can modify some lib files so makes the interface and/or binaries
obsolete
** bin generator
can be explicit or not
can be thru a gui or not (so thru what?)
can be 1 generation or a package generation
** interface creator
pb!
* use cases
** parameterization
say:
where is the lib or entities within
where is/are the repository/ries
how to compile (g++? options?)
...
** ?
???
** direct lib use
we use dyn user in C++
*** type
alias or not
with qualifiers (const, *, &)
*** object
ex: c4
**** creation
With or without default value. Const or not. With alias ?
dyn::var v;
define a variable towards a mutable object
here, no object is associated with this variable
dyn::var v("vname");
// alternative writing:
dyn::var v = "vname";
same as above + the variable is named
define a variable that handles a constant object
dyn::val v
dyn::val v(cobj); \ these two lines are ambiguous because cobj may be
dyn::val v(name); / of type std::string so just looks like a var name
dyn::val v(cobj, name = "");
this is ambiguous...
**** deletion
deletion of the object designated by a dyn::var
assumption: the object was dynamically allocated
otherwise: what happens when:
int i;
dyn::var v = i;
dyn::delete_(v); // ?
rmk:
delete v; // ambiguous!!!
*** routine
**** procedure
**** (regular) method
regular means neither ctor, dtor, assignment, nor operator
***** alias
dyn::fun foo_2d("lib::foo<2d>");
***** call
we want, if possible, a unique way to call a procedure:
dyn::call(something)
we try to avoid if possible several calling routines:
dyn::cal(..) dyn::call2(..) dyn::call3(..)
hint: calling a procedure means there's a '(' and a ')' in the code
ex: foo() foo(3)
we want to pass as argument of a call either dyn::var's or lib objects
ex:
lib::obj o;
dyn::var v = o;
dyn::call("lib::foo(v)"); means we are in the dyn world
dyn::call("lib::foo(o)"); is impossible to handle
code sample:
namespace lib {
struct obj { void m() {} };
}
namespace dyn {
void call(std::string& txt) {
// impossible access to 'main::o'!
}
}
int main() {
lib::obj o;
dyn::call("o");
}
so (no choice!) we must have:
dyn::call("lib::foo", o);
and that's great because the user has not to create a dyn::var to
access to dyn::call
yet we want this couple of mechanisms to work:
dyn::call("lib::foo(i)"); // full txt
here the text embed parenthesis
and
dyn::call("lib::foo", i); // routine name + arg list
here the text does not
that's of prime importance to be able to disambiguate between
dyn::call("lib::bar()");
and
dyn::call("lib::bar");
in the arg list, we can have either dyn::var's or lib::obj's
question: why not have 2 different names for both operations?
ex:
dyn::run("lib::foo(i)");
dyn::run("i = read(lena), j = lib::foo(i), display(j)");
and
dyn::call("lib::foo", i);
with the latter, it's a single call
with the former, we can have several instructions and so we need
some parsing.
if we are ok with: dyn::run("lib::foo(i)")
we do some parsing that we can avoid (so that's not so good)
with: dyn::run("some txt to be parsed")
the inner variables (such as i and j in the example above) do not
exist elsewhere.
on one side:
// nothing here
dyn::run("i = read(lena), j = lib::foo(i), display(j)");
on the other side:
dyn::var i; //...
dyn::run("lib::foo(i)");
here 'i' refers to the variable
last, dyn::run has much more work to perform and many more capabilities than
dyn::call; both features cannot (should not) be confused.
conclusion :
we can have two different call features
dyn::var i("I"); //...
dyn::call("lib::foo(I)"); // 1st case
and
dyn::var i; //...
dyn::call("lib::foo", i); // 2nd case
explaination: we cannot have
dyn::var i;
dyn::call("lib::foo(i)");
because i is unknow (unaccessible) in dyn world.
when there is no argument, the ambiguity can be supressed with the
presence of parenthesis:
dyn::call("lib::bar()"); means: 1st case
and
dyn::call("lib::bar"); means: 2nd case
so what with the samples below?
lib::foo_2d(42);
dyn::call_fun("bar()");
dyn::assign_fun("sqrt(42)", result);
**** special method
special as the contrary of regular
dyn::ctor mk_image2d_int("image2d<int>");
var ima = mk_image2c_int(3, 3);
**** operator
-> sugar only
*** link between data abstraction class and the lib classes
**** conversion
dyn::var i = 5;
int j;
j = i; ?
dyn::convert_data_to(i, *j);
**** transparent usage in function call
int i = 5;
dyn::var j = 6;
dyn::fun power("power");
factor(i, j);
**** usage of reference or copy the data ?
we want to use
lib {
void sinc(int& a) {++a;}
}
int i = 0;
var v = i;
dyn::call("lib::sinc");
cout << i
instead of
int i = 0;
lib::inc(i);
cout << i
So, v should be a reference to i. (then, "var" is maybe not really appropriate)
Other really amiguous example :
int i = 1, j = 2;
var v = i;
var w = j;
v = w; !!not clear -> If v is a reference, why could we reassignate it ? If v is a copy, it means that i will be equal to 1 at the end, is it what we want ?
Possible issue : Split "var" into 2 cases : "var" for variable (copy data), "ref" for reference (do not copy data, just reference it)
Other issue : Keep "var" class, and add a hidden "ret" class. ret would be the return type of call, so that a var can receive a ret but not another var. Interest : "v = w" would be forbidden, but v = dyn::call("sinc") will still be avaible.
The main problem is to recognize tempory data which must not be stored by reference.
We recall that these two prototypes can't be used together:
<T> var(T)
<T> var(T&)
=>ambiguous
But this is allowed:
<T> var(T&)
<T> var(const T&) -> this handle temporary data (but not only, which is the problem !)
=> We stay on the idea that var is a reference, so we forbid var v = 5; (by using only var(T&) constructor which don't handle temporary data)
How to choose the right policy about the return type of the function ?
Use the operator,
+ some struct and sizeof...
Final decision (up to now !) :
Var is almost like a reference.
int i = 0;
var i_v = i;
after this line i_v has the same behavior than i.
Link everything thanks to pointer, even with copied data (dynamic allocation in this case).
probleme with destruction ? (use flag to specify wheter a var handle a temporary data or not)
var i = 4;
var j = i;
i = 3; //j = 3;
j and i represent the same data. So if i die we must not delete the data. But when j die too, the data has to be freed.
\ No newline at end of file
extended/ChangeLog deleted 100644 → 0
View file @ e0d2422e
2006-11-07 Thierry GERAUD <theo@tegucigalpa.lrde.epita.fr>
* xtd/vec.hh (L2_norm): New.
(include): Add cmath header.
2006-10-31 Roland Levillain <roland@lrde.epita.fr>
* tests/Makefile.am: Alter AM_CXXFLAGS instead of CXXFLAGS.
2006-10-27 Roland Levillain <roland@lrde.epita.fr>
Fix the distribution.
* xtd/Makefile.am (nobase_xtd_HEADERS): Add math/ops.hh.
2006-10-25 Thierry GERAUD <theo@tegucigalpa.lrde.epita.fr>
* xtd/math.hh (include): Move ops inclusion into...
* xtd/math/ops.hh: ... this new file.
2006-10-25 Thierry GERAUD <theo@tegucigalpa.lrde.epita.fr>
Update xtd bool op traits.
* xtd/builtin/traits.hh (bool): Fix partially.
* xtd/internal/opmacros.hh
(xtd_internal_decl_binary_logical_operator): New macro.
* xtd/math/logic.hh: Update.
2006-10-23 Thierry GERAUD <theo@tegucigalpa.lrde.epita.fr>
* xtd/vec.hh (ops): Move outside of class.
(vec_base_): New specialization for <4, T>.
(mk_vec): New overloading for 4 args.
2006-10-20 Thierry GERAUD <theo@tegucigalpa.lrde.epita.fr>
Add mutators and disable mutable facilities of other functions.
* xtd/mutator.hh: New.
* xtd/abstract/mutable_fun.hh: New.
* tests/accessor.cc: New.
* xtd/res.hh: Add comment.
* xtd/accessor.hh (xtd_decl_accessor): Disable mutable impl_op.
(xtd_decl_accessor): Add static check.
* xtd/abstract/open_nary_fun.hh (fun_operator_1): Disable mutable
impl of default_case_ and add commented mutable_res.
(open_nary_fun_<1,E>): Disable mutable version of operator().
* xtd/abstract/plain_nary_fun.hh
(plain_nary_fun_<1,E>): Disable mutable version of operator().
* xtd/abstract/plain_fun.hh: Add commented code for xtd_mutable_res.
* xtd/mfun.hh (m1fun_): Disable mutable version of impl_calc.
* xtd/Makefile.am: Update.
* tests/Makefile.am: Update.
2006-10-18 Thierry GERAUD <theo@tegucigalpa.lrde.epita.fr>
Make xtd unary functions support argument mutation.
* xtd/accessor.hh (xtd_decl_accessor): Add impl_op mutable version
to the accessor class.
* xtd/mfun.hh (impl_calc): Add mutable version to m1fun_<F>.
* xtd/abstract/open_nary_fun.hh (impl, operator): Add mutable versions
to open_nary_fun_<1, E>.
* xtd/abstract/plain_nary_fun.hh (operator): Add mutable version
to plain_nary_fun_<1, E>.
2006-10-18 Thierry GERAUD <theo@tegucigalpa.lrde.epita.fr>
* xtd/accessor.hh (xtd_decl_accessor): Fix typo in method access.
2006-10-16 Thierry GERAUD <theo@tegucigalpa.lrde.epita.fr>
* xtd/optraits.hh (get_trait_): Change mlc_is_found into mlc::is_ok_
so that mlc::undefined means 'not user-defined'.
2006-10-16 Thierry GERAUD <theo@tegucigalpa.lrde.epita.fr>
Enhance xtd traits mechanism so that set of traits can be defined.
* xtd/optraits.hh (from_set_traits_): New.
* xtd/traits.hh (set_traits_): New.
(from_set_traits_): New.
(set_trait_): New specialization.
2006-10-10 Thierry GERAUD <theo@tegucigalpa.lrde.epita.fr>
Add xtd accessors (pure functions based on accessor methods).
* xtd/accessor.hh: New.
* xtd/vec.hh (operator<<): Move outside of class.
(operator<<): New specializations for 'unsigned char' and