Good Practice discussion!
To whom it may concern,
I have released a library for string handling that should condensate many of your facilities into one, single, OO-designed class:
https://github.com/szaghi/StringiFor
It exposes only one type, string, and it already has many methods inspired by other, more rich, languages (Python, obviously). However, the library can be considered not fully stable, but almost stable.
The documentation is still poor, but almost all should be already clear.
I will adopt it intensively in the near feature (FoXy, FLAP, FOODIE, others).
Your suggestions are, as always, very welcome.
My best regards.
New features:
- Arbitrary preprocessor can now be specified (Issue #117, PR #129)
- CPP now used as default preprocessor instead of gfortran, as former is more widespread (note that this should not
change results of preprocessing) - Pages now ordered according to file-name (Issue #121, PR #122)
- Integration of Gitter sidecar
- Optionally print date documentation created in the page footer (PR #115)
- Can export graphs as SVG images and graphviz source (Issue #97)
- Single global switch now available to hide local variables, derived types, etc. within procedures (Issue #100)
- Support for coloured edges in graphs, which can make it easier to read large graphs (Issue #113)
Bug fixes:
\gin character literal no longer causes crash (Issue #136)- No longer interprets
concurrentindo concurrentas function call (Issue #131) - Header doesn't cover links to particular lines of source code in source file pages (Issue #132)
- Copying file trees now works on network file systems (Issue #128)
::now accepted in allusestatements (Issue #120, PR #123)deferrednow included in lists of type-bound procedure attributes- Correct handling of include paths with user's home directory specified by
~(Part of issue #134) - Correctly interprets output from preprocessors when running with Python 3 (PR #129)
- Can now copy file hierarchies deeper than 10 directories (PR #127)
- MathJax now works for both HTTP and HTTPS (PR #126)
I have created a skeleton page for list Group's member
Fortran-FOSS-Programmers/Fortran-FOSS-Programmers.github.io#5
I hope you like it.
See you soon.
P.S. @cmacmackin great!
Help Wanted for polymorphic arguments!
My dear, I have a trivial question to which I am not able to respond... I need your help
Let us suppose we an subroutine that among others accept 3 unlimited polymorphic dummies
subroutine foo(arg1, arg2, arg3, ...)
class(*), intent(in) :: arg1
class(*), intent(in) :: arg2
class(*), intent(in) :: arg3
...
end subroutine fooBefore using the arg# I have to check their type/class, right? so something like
subroutine foo(arg1, arg2, arg3, ...)
class(*), intent(in) :: arg1
class(*), intent(in) :: arg2
class(*), intent(in) :: arg3
...
select type(arg1)
type is(integer)
select type(arg2)
type is(integer)
select type(arg3)
type is(integer)
! do my integer stuff
end select
end select
end select
end subroutine fooThat is very verbose and error-prone. In the case I am sure that the combination of arg# is always uniform, namely they are ALL integers, reals, complexs... and I never fall into the case that one is real and others are integers, two are reals and the last is integer and similar etherogeneous cases, there is something smarter that I can do? I am confident that there is no other way to deal with unlimited polymorphic other than select type, but I prefer to listen this from your voice :smile:
Thank you far any comments!
select type statements.
select type blocks is the only way to do it. I don't find unlimited polymorphics to be especially useful, for this reason. At the end of the day, the issue here is that Fortran lacks generic programming facilities. Any attempt to replicate that functionality will be messy.
transfer workaround (I have studied FIAT even I still have not find the time to contribute to it) and I have to admit that you are right. In this case, I think I will go with the old overloading of generic names with a tons of foo_xxx. Thank you all for your help.
assumed rank arrays can help me to avoid code-duplication. I know that assumed rank arrays, e.g. real, intent(in) :: x(..) have been introduced for a better C-interop, but I am wonderding if they can help me. There are some cons in their usage? Copy-in-out? I never used them, something of you do this? Thanks in advance!
Universal Linux Package
@giacombum pointed out this interesing project
I know that @rouson @zbeekman and Co. have done a lot of work in packaging OpenCoarrays, maybe this project can be of any help for them and others.
My best regards.
One (bad) workaround could be to declare the deferred procedure into the abstract type with a lot of
optional arguments, but it seems too bad also for me :-)
@giacombum
To my knowledge ALL deferred TBP must be implemented in a valid concrete extension of an abstract type. So I think you have 2 alternatives:
Optionals abuse
The abstract interface must consider all the optional arguments...
module foo_t
type, abstract :: foo
contains
procedure(bar_interface), deferred :: bar
end type foo
abstract interface
subroutine bar_interface(self, arg1, arg2)
import :: foo
class(foo), intent(in) :: self
integer, intent(in), optional :: arg1
integer, intent(in), optional :: arg2(1:)
end subroutine bar_interface
end interface
end module foo_t
module foo_concretes
use foo_t
type, extends(foo) :: concrete1
contains
procedure :: bar => bar_concrete1
end type concrete1
type, extends(foo) :: concrete2
contains
procedure :: bar => bar_concrete2
end type concrete2
contains
subroutine bar_concrete1(self, arg1, arg2)
class(concrete1), intent(in) :: self
integer, intent(in), optional :: arg1
integer, intent(in), optional :: arg2(1:)
! use only arg1, arg2 is never used
end subroutine bar_concrete1
subroutine bar_concrete2(self, arg1, arg2)
class(concrete2), intent(in) :: self
integer, intent(in), optional :: arg1
integer, intent(in), optional :: arg2(1:)
! use only arg2, arg1 is never used
end subroutine bar_concrete2
end module foo_concretesIn the case the dummy arguments are many this approach is not concise, neither clear.
Avoid the deferred at all
This makes the abstrac less clear, the contract becomes not explicit, but the concretes are not polluted by never-used optionals
module foo_t
type, abstract :: foo
! for developers: rember to implement a concrete bar!
end type foo
end module foo_t
module foo_concretes
use foo_t
type, extends(foo) :: concrete1
contains
procedure :: bar => bar_concrete1
end type concrete1
type, extends(foo) :: concrete2
contains
procedure :: bar => bar_concrete2
end type concrete2
contains
subroutine bar_concrete1(self, arg1, arg2)
class(concrete1), intent(in) :: self
integer, intent(in) :: arg1
! use only arg1
end subroutine bar_concrete1
subroutine bar_concrete2(self, arg2)
class(concrete2), intent(in) :: self
integer, intent(in) :: arg2(1:)
! use only arg2
end subroutine bar_concrete2
end module foo_concretes@/all Dear all, do you have a VIM syntax file for Fortran supporting submodule related syntax?
In particular, let us consider the following snippet:
submodule (foo) bar
contains
module subroutine foo_bar
...
end subroutine foo_bar
endsubmodule barI want:
- highlight
submoduleandendsubmodule; - enable folding of
module subroutine/end subroutineandmodule function/end function.
Thank you in advance!
P.S. @giacombum I have not a particular preference for your question, it depends on how many arguments are optional.
@tomedunn I see that you have two different Fortran vim syntax. Which is the best among them? The update time is very close...
https://github.com/tomedunn/vim.modfortran => Aug 16, 2015
https://github.com/tomedunn/vim.fortran => Jul 11, 2015
module subroutine/end subroutine and module function/end function. Is it difficult to improve the folding? Anyhow thank you very much, now your vim.fortran is my preferred Fortran vim syntax :clap:
region.
vim.fortran. I have added the fortranModuleFunction and fortranModuleSubroutine regions for folding these constructs. I was unable to create a region for submodule/end submodule, the regex of vim is not intuitive at all! Indeed, I had few minutes to play with it, but the first saw vim regex really makes me afraid... The two folding regions addes seem to work, but feel free to discard my PR. Thank you again.
t. It reflects very well that the residual function can or cannot explicitely depend on time. If the concrete ODE has U_t=R(U(t)) than you will not pass t to the method %time_derivative, on the contrary if U_t=R(U(t), t)) you will pass t. So, the API is not unique, but the usefulness of having an abstract is tremendus. I am not so rigorous in exploiting abstract.
Dear All @/all , I have done some steps over with FoXy.
Presently, it has basic capabilities for parsing and emitting XML files (tags). Currently, there is only limited SAX-like facilities (nested tags can be searched/retrieved, but there is not a real tree-representation, all is done by string-parsing on the fly).
I would like to implement also (limited) DOM-like capabilities.
Are there experts on XML parsers and SAX-DOM "approaches"?
I need good feed to learn about well-established XML parsers. Currently, I have been mostly inspired by Python Yattag module that is (manly) a very easy (html/xml) tag emitter, but for FoXy I need to be inspired by more complete XML parsers.
I have not yet studied the other Fortran XML parsers available on the web, but I will do it soon. I am not sure if here there are the authors of those Fortran libraries, but in case your help is very appreciated.
My best regards.
OFF TOPIC
Not strictly related to Fortran, but @cmacmackin has published an interesting poster presentation about his research. There is also a more detailed report here. @cmacmackin can I suggest to you to open a gitter chat about Ice Shelves, maybe on the framework of ISOFT? My best compliments :clap:
Coarray and PETSc
Dear All,
I would like to know your opinions. We ( @francescosalvadore @andreadimascio and me) have started a new interesting Fortran project for solving PDE. The project is under the very-early-borning phase where we are trying to define the main design specifications, however we are already taking some strategic decisions for the future developments. In particular we are disccussing about the parallelization strategy: we would like to exploit PETSc to perform some critical computations. However, we would also like to adopt coarray (over MPI) for other stuffs.
Do you have any experience on using PETSc, in particular within coarray? @zbeekman @muellermichel @afanfa @rouson @nncarlson I think you are the most experienced in this parallel contest, do you have any advices on PETSc/Coarray mixing? There is a better library than PETSc already supporting Coarray?
Thank you @/all for your help.
