More everything into the octave namespace

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

More everything into the octave namespace

Carnë Draug
There's been a lot of stuff moved into the octave namespace.  Sounds
right to me that we move everything somewhere into the octave namespace.
Is that the plan?

If we are heading that way, I'd prefer if it was all done in one go
(upcoming Octave 4.2 release), instead of gradually.  Makes it easier
to have a package that supports both versions, specially if it involves
renaming functions (maintaing a package that supports old and new Octave
versions when such changes happen is a burden.  If I can limit it to
the Octave 4.0 -> 4.2 transition that would be better).

Should we start moving everything into namespaces?  And if so, what
should we leave in the octave namespace, and what goes into nested
namespaces?

The doxygen docs were updated recently so we can have a list of the
current existing classes [1].

Looking forward to start using octave::Array<T>.

Carnë

[1] http://octave.org/doxygen/4.1/annotated.html

Reply | Threaded
Open this post in threaded view
|

Re: More everything into the octave namespace

John W. Eaton
Administrator
On 08/11/2016 12:11 AM, Carnë Draug wrote:

> There's been a lot of stuff moved into the octave namespace.  Sounds
> right to me that we move everything somewhere into the octave namespace.
> Is that the plan?
>
> If we are heading that way, I'd prefer if it was all done in one go
> (upcoming Octave 4.2 release), instead of gradually.  Makes it easier
> to have a package that supports both versions, specially if it involves
> renaming functions (maintaing a package that supports old and new Octave
> versions when such changes happen is a burden.  If I can limit it to
> the Octave 4.0 -> 4.2 transition that would be better).
>
> Should we start moving everything into namespaces?  And if so, what
> should we leave in the octave namespace, and what goes into nested
> namespaces?
>
> The doxygen docs were updated recently so we can have a list of the
> current existing classes [1].
>
> Looking forward to start using octave::Array<T>.

Yes, the plan is to move things to namespaces.

I've been doing this incrementally because I want to change most names
that are of the form "octave_foo" to be "octave::foo" instead.  So it's
not as simple as just inserting "namespace octave {" at the top of every
file and "}" at the bottom.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: More everything into the octave namespace

Carnë Draug
On 15 August 2016 at 23:59, John W. Eaton <[hidden email]> wrote:

> On 08/11/2016 12:11 AM, Carnë Draug wrote:
>>
>> There's been a lot of stuff moved into the octave namespace.  Sounds
>> right to me that we move everything somewhere into the octave namespace.
>> Is that the plan?
>>
>> If we are heading that way, I'd prefer if it was all done in one go
>> (upcoming Octave 4.2 release), instead of gradually.  Makes it easier
>> to have a package that supports both versions, specially if it involves
>> renaming functions (maintaing a package that supports old and new Octave
>> versions when such changes happen is a burden.  If I can limit it to
>> the Octave 4.0 -> 4.2 transition that would be better).
>>
>> Should we start moving everything into namespaces?  And if so, what
>> should we leave in the octave namespace, and what goes into nested
>> namespaces?
>>
>> The doxygen docs were updated recently so we can have a list of the
>> current existing classes [1].
>>
>> Looking forward to start using octave::Array<T>.
>
>
> Yes, the plan is to move things to namespaces.
>
> I've been doing this incrementally because I want to change most names that
> are of the form "octave_foo" to be "octave::foo" instead.  So it's not as
> simple as just inserting "namespace octave {" at the top of every file and
> "}" at the bottom.
>

But that only applies to classes that are octave_foo.

Rik mentioned feature freeze the day after my original email so this
change won't go through to 4.4 anyway.  However, there's classes that
are new for Octave 4.2, and others that have changed since 4.0.  These
are the ones that could be moved right away.

For example, a lot of the classes in liboctave/numeric such as svd, qr, lu,
hess, chol, and qz have been templated.  People upgrading to 4.2 will have
to change their code to account for this.  If we don't put them in the right
namespace now, and if do it in Octave 4.4, people will have to be changing
their code again in 1 year (or whenever 4.4. comes out).

Same with the new classes in 4.2.  Better to get them in the right place
from the start than having to change them for 4.4.  That will be a bother
for us because we will need to keep backwards compatibility, and for our
users that need to change their code.

Reply | Threaded
Open this post in threaded view
|

Re: More everything into the octave namespace

John W. Eaton
Administrator


On August 16, 2016 9:19:13 AM EDT, "Carnë Draug" <[hidden email]> wrote:
>On 15 August 2016 at 23:59, John W. Eaton <[hidden email]> wrote:

>> I've been doing this incrementally because I want to change most
>names that
>> are of the form "octave_foo" to be "octave::foo" instead.  So it's
>not as
>> simple as just inserting "namespace octave {" at the top of every
>file and
>> "}" at the bottom.
>>
>
>But that only applies to classes that are octave_foo.

Yes.  The others are slightly easier to move, but I still want to try to provide typedefs or other means for backwards compatibility in most cases.  So it's not as simple as running sed on some source files.

>Rik mentioned feature freeze the day after my original email so this
>change won't go through to 4.4 anyway.  However, there's classes that
>are new for Octave 4.2, and others that have changed since 4.0.  These
>are the ones that could be moved right away.

OK, let's identify those classes and fix them now.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: More everything into the octave namespace

Carnë Draug
On 16 August 2016 at 15:24, John W. Eaton <[hidden email]> wrote:

>
> On August 16, 2016 9:19:13 AM EDT, "Carnë Draug" <[hidden email]> wrote:
>>
>> On 11 August 2016 at 05:11, Carnë Draug <[hidden email]> wrote:
>>>
>>> The doxygen docs were updated recently so we can have a list of the
>>> current existing classes [1].
>>> [...]
>>>
>>> [1] http://octave.org/doxygen/4.1/annotated.html
>
>>Rik mentioned feature freeze the day after my original email so this
>>change won't go through to 4.4 anyway.  However, there's classes that
>>are new for Octave 4.2, and others that have changed since 4.0.  These
>>are the ones that could be moved right away.
>
> OK, let's identify those classes and fix them now.
>

It's the diff between these two pages:

    http://octave.org/doxygen/4.0/annotated.html
    http://octave.org/doxygen/4.1/annotated.html

Here's what I did for future reference:

  $ wget -O 40classes http://octave.org/doxygen/4.0/annotated.html
  $ wget -O 41classes http://octave.org/doxygen/4.1/annotated.html
  $ grep -P '^<tr' 40classes | grep -Po
'(?<=target="_self">).+?(?=</a>)' | sort > 40-class-names
  $ grep -P '^<tr' 41classes | grep -Po
'(?<=target="_self">).+?(?=</a>)' | sort > 41-class-names
  $ diff --unified 40-class-names 41-class-names | grep '^+'
  +++ 41-class-names    2016-08-16 15:56:58.559609249 +0100
  +aepbalance
  +application
  +base_interrupt_manager
  +base_lexer
  +base_parser
  +base_text_renderer
  +base_tm
  +bp_type
  +ButtonGroup
  +CFile
  +child
  +child_list
  +child_list_rep
  +chol
  +complex_index_exception
  +cpu_time
  +cxsparse_defaults
  +cxsparse_defaults&lt; SparseComplexMatrix &gt;
  +cxsparse_defaults&lt; SparseMatrix &gt;
  +cxsparse_types
  +cxsparse_types&lt; SparseComplexMatrix &gt;
  +cxsparse_types&lt; SparseMatrix &gt;
  +delimited_stream
  +directory_path
  +dynamic_library
  +dynlib_rep
  +eealso
  +env
  +equiv
  +font
  +ft_text_renderer
  +gepbalance
  +gmtime
  +group
  +gui_application
  +hess
  +index_exception
  +interpreter
  +interrupt_handler
  +interrupt_manager
  +invalid_index
  +JVMArgs
  +lexer
  +light
  +localtime
  +lu
  +mach_info
  +marker
  +octave
  +octave_cmd_debug
  +octave_command_queue
  +octave_execution_exception
  +octave_getopt_options
  +ode
  +opengl_tesselator
  +opengl_texture
  +out_of_range
  +parser
  +password
  +patch_tesselator
  +posix_interrupt_manager
  +properties
  +properties
  +push_lexer
  +push_parser
  +qr
  +qrp
  +QTabWidget
  +resource_usage
  +schur
  +session_data
  +sigset_info
  +sparse_chol
  +sparse_chol_rep
  +sparse_lu
  +sparse_qr
  +sparse_qr_rep
  +string
  +strptime
  +svd
  +sys
  +tab_info
  +tab_widget
  +text_renderer
  +textscan
  +textscan_format_elt
  +textscan_format_list
  +texture_rep
  +time
  +trong
  +uibuttongroup
  +uname
  +vertex_data
  +vertex_data_rep

Grepping for "-" would show the classes that disappeared.

The problem with this approach is that:

  1 - it includes classes that are only used internally.
  2 - does not show the enclosing class for nested classes (for example,
    the new string class, is actually nested inside text_renderer which
    itself is a new class)

I think at this point they have be to be looked at manually.

Also, we need to decide in which namespace are putting each one of them.
I think you mentioned on IRC that we don't want to have too many namespace
and I agree.  So what namespaces will we have under octave? math, parser,
gui, graphics, interpreter?

Reply | Threaded
Open this post in threaded view
|

Re: More everything into the octave namespace

John W. Eaton
Administrator
On 08/16/2016 11:11 AM, Carnë Draug wrote:

> Grepping for "-" would show the classes that disappeared.
>
> The problem with this approach is that:
>
>   1 - it includes classes that are only used internally.
>   2 - does not show the enclosing class for nested classes (for example,
>     the new string class, is actually nested inside text_renderer which
>     itself is a new class)

Or classes that are already inside a namespace?

> I think at this point they have be to be looked at manually.

Right, but that's a good start.

> Also, we need to decide in which namespace are putting each one of them.
> I think you mentioned on IRC that we don't want to have too many namespace
> and I agree.  So what namespaces will we have under octave? math, parser,
> gui, graphics, interpreter?

So far, we have these namespaces inside the main octave namespace:

   build_env
   crypto
   math
   string
   sys

If we need more later we can add them.  But we should try to keep the
list small.

There are also a few more in the GUI and JIT compiler that I don't think
are part of the octave namespace.  Those should not cause trouble.  We
don't install header files from the GUI directory (yet) and the JIT
compiler doesn't really work so can't possibly have many (any?) users.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: More everything into the octave namespace

Carnë Draug
On 16 August 2016 at 16:35, John W. Eaton <[hidden email]> wrote:

> On 08/16/2016 11:11 AM, Carnë Draug wrote:
>
>> Grepping for "-" would show the classes that disappeared.
>>
>> The problem with this approach is that:
>>
>>   1 - it includes classes that are only used internally.
>>   2 - does not show the enclosing class for nested classes (for example,
>>     the new string class, is actually nested inside text_renderer which
>>     itself is a new class)
>
> Or classes that are already inside a namespace?

It does, but like in point 2, it does not show the enclosing namespace
that it is on. Which also causes issues with the call to "diff".

Reply | Threaded
Open this post in threaded view
|

Re: More everything into the octave namespace

chechu
In reply to this post by John W. Eaton
Good evening to everyone,

Those last days the first RC to 4.2 is being released. Maybe I got lost on the octave-mantainers list that summer.
We have tried to get the 4.2.0 version work as the previous ones and we are facing problems getting the JIT compiler to be enabled. As we have realised, there were changes on its behaviour, getting its infraestructure inside namespaces, as many other core parts.

Is it still posible to use the JIT compiler? We have tried with the MXE LLVM 3.3 and the newer LLVM 3.8 and both of them give the same errors at compilation time.

error: ‘octave_jit_octave’ has not been declared
 octave_jit_octave::err_nan_to_logical_conversion (void)
error: redefinition of ‘void err_nan_to_logical_conversion()’


That linux environment, config and dependencies works on 4.0.3 last stable release.
Maybe the JIT compiler is not usefull for more complicated executions as the Matlab JIT counterpart, but for us it was always enabled.
There is any prevision of when will it be reenabled? Or it will be depreciated?

Thanks in advance, regards,  chechugarriga