@milancurcic 's datetime-fortran is now part of Homebrew
$ brew update
$ brew install datetime-fortran:zap: :shipit:
brew update
brew install FORD || brew upgrade FORDGood 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: