Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
Activity
• Nov 14 2019 20:49
letmaik opened #39
• Oct 25 2019 09:35

szaghi on master

update submodules update travis config (compare)

• Oct 25 2019 09:30

szaghi on master

update submodules (compare)

• Oct 25 2019 09:19

szaghi on master

update submodules update travis config (compare)

• Oct 21 2019 06:34
rakowsk commented #7
• Oct 20 2019 16:09
• Oct 20 2019 16:09
rakowsk commented #7
• Oct 12 2019 17:49
ShatrovOA commented #38
• Oct 11 2019 15:25
szaghi labeled #38
• Oct 11 2019 15:25
szaghi assigned #38
• Oct 11 2019 15:25
szaghi commented #38
• Oct 11 2019 13:52
ShatrovOA edited #38
• Oct 11 2019 13:44
ShatrovOA opened #38
• Sep 19 2019 11:19
szaghi commented #7
• Sep 19 2019 11:08

szaghi on master

Fix parsing bug issue#7 The me… update travis config Merge branch 'release/0.1.0' (compare)

• Sep 19 2019 11:06

szaghi on fix-parsing-bug-issue#7

• Sep 19 2019 07:54

szaghi on fix-parsing-bug-issue#7

• Sep 19 2019 07:52
szaghi commented #7
• Sep 19 2019 07:51
szaghi labeled #7
• Sep 19 2019 07:51
szaghi assigned #7
Giacomo Rossi
@giacombum
I see this git repo and immediately I think to the best practices repo... maybe in the future, when the guideline is complete...
Damian Rouson
@rouson
This message was deleted
Stefano Zaghi
@szaghi
@giacombum I know gitbook... as you said we are too far to a minimal document (we are discussing only the second guiddline :smile: ) but I will keep it in my mind, thanks
Neil Carlson
@nncarlson
Workflow / best practices for automatic documentation generation (FORD)
@cmacmackin recently added support for #include in his FORD tool and I'm setting about now learning how to use it in one of my small projects. I have big questions though on what I should do with the resulting documentation. I know many of you here use it and I'm hoping to get some advice (and if not I'll be poking about in your repos to see if I can discover what you do). Some questions:
• Should I include the doc in the git repo (the docs are completely rewritten each time FORD is run I gather), or do I treat it just as temporary data to be moved elsewhere (but where? web page, wiki?)
• Should I use github's funky gh-pages branch as the place to permanently archive the doc? Anybody using gh-pages?
• Related to the above is what are good ways to provide the entry point to the doc?
• CMake magic to generate a "doc" target using FORD. Care to share?
Izaak "Zaak" Beekman
@zbeekman

@nncarlson Interesting questions!

I am of the persuasion that the generated documentation should not be checked into your VCS system, since it is an asset that is built by the build system from the sources. My preferred place to put the docs is the gh-pages branch of your projects github repo.

For JSON-Fortran we use some "black magic" that I came up with that includes:

The entry point to the documentation can be links on the README.md and wiki if one exists, and publicizing the URL in any user manual, or project website, etc.

Neil Carlson
@nncarlson
Thank you @zbeekman! I'll be taking a careful look at what you are doing in JSON-Fortran. My gut feeling was that the generated docs don't belong under VCS but wasn't sure what else to do with it.
Izaak "Zaak" Beekman
@zbeekman
I think the auto-deploy with Travis-CI (and only when tests pass, and build succeeds) is pretty slick, but it was a real PITA to figure out. I hope looking at my code will help get you started with much less headache.
Stefano Zaghi
@szaghi
@nncarlson I am sorry for my delay (I have to remember to close my Gitter icon tray app...). I can only suggest to follow @zbeekman suggestion: I have adopted @zbeekman 's scripts for all my FOSS projects for (auto)deplying doc on gh-pages, they works very well! @zbeekman is a wise man!
Izaak "Zaak" Beekman
@zbeekman
FORD 4.5.1 is now available through the Homebrew package manager for OS X
$brew update$ brew upgrade ford
For those who already have it installed this way. For others first get Homebrew at http://brew.sh then:
$brew update$ brew install ford
Izaak "Zaak" Beekman
@zbeekman
If you would like to see @milancurcic's datetime-fortran library added to the Homebrew package manager, please head over to its Github page and star, watch and/or fork it. It is only about two each shy of being "popular" enough to be added to homebrew:
$brew audit --online --strict datetime-fortran ==> brew style datetime-fortran 1 file inspected, no offenses detected ==> audit problems datetime-fortran: * GitHub repository not notable enough (<10 forks, <10 watchers and <20 stars) Error: 1 problem in 1 formula Izaak "Zaak" Beekman @zbeekman We're there... just sorting out some residual packaging stuff then I'll be submitting a Homebrew PR with the Formula... stay tuned Izaak "Zaak" Beekman @zbeekman OpenCoarrays 1.3.0 has been released. Stefano Zaghi @szaghi @zbeekman @milancurcic can I suggest to promote datetime-fortran on google group CLF? OpenCoarrays rocks! Milan Curcic @milancurcic @szaghi I started a datetime thread on CLF about a year ago (turned into a long discussion :smile: ). Just type datetime in the group's search bar and it will come up. Feel free to post in that same thread. Milan Curcic @milancurcic Stefano Zaghi @szaghi @milancurcic Oh sorry, I had missed it! Stefano Zaghi @szaghi My congratulations to @cmacmackin for his first research result https://cmacmackin.github.io/graphs-at-last.html , you must show us more details soon :smile: Chris MacMackin @cmacmackin Awe, thanks @szaghi! There was really no need to mention that! :blush: Izaak "Zaak" Beekman @zbeekman :tada: Milan Curcic @milancurcic @cmacmackin Amazing stuff, keep it up!! Izaak "Zaak" Beekman @zbeekman @milancurcic 's datetime-fortran is now part of Homebrew $ brew update
\$ brew install datetime-fortran

:zap: :shipit:

Milan Curcic
@milancurcic
Bam! THank you @zbeekman, great job as always!!
Izaak "Zaak" Beekman
@zbeekman
Also, http://opencoarrays.org has a new look and gitter.im sidecar integration. Go check it out!
Chris MacMackin
@cmacmackin
Hi all. I've finally gotten around to doing the work needed to get FIAT to a point where I feel I can collaborate with others. As such, I've created a new gitter chatroom for it: https://gitter.im/Fortran-FOSS-Programmers/FIAT. Everyone is invited to join that room and put across their suggestions, questions, and (if you are really eager) volunteer your time to work on it.
Chris MacMackin
@cmacmackin
I've put out a new minor release of FORD, with a number of bugfixes. Since no one from this group reported the bugs I'm guessing you haven't been experiencing any problems, but just thought I'd let you know.
Izaak "Zaak" Beekman
@zbeekman
great, I'll try to get a Homebrew PR in soon
Izaak "Zaak" Beekman
@zbeekman
FORD 4.5.2 available through Homebrew:
brew update
brew install FORD || brew upgrade FORD
Stefano Zaghi
@szaghi
FLAP v1.0.0 is out. It is NOT backward compatible. See you soon.
Chris MacMackin
@cmacmackin
I've put out a new release of FORD on PyPI. No exciting new features, but a bunch of fixes to bugs which I'm amazed I haven't caught before now.
Chris MacMackin
@cmacmackin
[Sigh...] Turns out there was another bug in FORD, this one due to a misunderstanding of the Fortran standard on my part. I've just released v4.5.4 to fix it.
Izaak "Zaak" Beekman
@zbeekman
Only three things are garaunteed in life: death, taxes and software bugs! Major props for fixing it so quickly!
Chris MacMackin
@cmacmackin
Unfortunately, software bugs have to be faced more than once and don't have the benefit of funding research grants.
Stefano Zaghi
@szaghi
Hi all, I am sorry for my long silence but these are very busy days... I would like to introduce a new member @MichaelSiehl : he is a very experienced Fortraner, very active on google group CLF where many of you already know him; he is now developing some great examples (on github) on how exploit CAF to achieve MPMD codes... not to be said it is a great effort! I hope that Michael will start very soon to develop an interesting example-program directly under the behalf of the group on how achieve MPMD by means of CAF and F03/08 OOP; I am very interested on this topic, I hope many of you will join us. @cmacmackin I am quite freezed with FIAT: I have to complete some works at my institute that prevent me to complete my contribute about octree... @milancurcic @rouson @zbeekman the occurrence of the open-call into my institute has blocked me to complete the 2D/3D tests of FOODIE into Fermi cluster: I am sorry, but very soon I will complete it (good news are that FOODIE now compiles with IBM XLF available on Fermi). For all other: I will soon update our Good Practice discussion!
Stefano Zaghi
@szaghi

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:

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.

Chris MacMackin
@cmacmackin
I've made a new release of FORD. This includes manyhh bug fixes and a selection of new features. Some of these new features were contributed by others via pull requests, so I would like to thank those involved.
From the changelog:

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:

• \g in character literal no longer causes crash (Issue #136)
• No longer interprets concurrent in do concurrent as 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 all use statements (Issue #120, PR #123)
• deferred now 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)
Stefano Zaghi
@szaghi
Dear all,

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!

Stefano Zaghi
@szaghi

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 foo

Before 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 foo

That 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:

Tom Dunn
@tomedunn
I think I would just write a separate subroutine for each type of argument and then overload a generic subroutine to call them all via the same subroutine. It doesn't allow you to reuse the code between the subroutines but it does allow you to get rid of the nested select type statements.
Stefano Zaghi
@szaghi
Hi @tomedunn thank you for your help. Yes, generic name and dynamic dispatch was my first approach, but then I come to unlimited polymorphic just to avoi to write tons of foo_real_64, foo_real_32, foo_integer_32... where only few statements differ (again error-prone). Indeed I have written a pre-processor just for this case, but I have write a piece of code with a minimum dependency for easy-sharing and adding a pre-processor dependency is not a viable approach. Anyhow thank you very much!
Chris MacMackin
@cmacmackin
The nested 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.
Stefano Zaghi
@szaghi
@cmacmackin Thanks, I should know this, but I was hoping to have missed something... I know that you prefer 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.
Stefano Zaghi
@szaghi
@cmacmackin @tomedunn @zbeekman and all, sorry to bother you again. Lefting the unlimited polymorphic approach, I am now wondering if the 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!
Stefano Zaghi
@szaghi

Universal Linux Package

@giacombum pointed out this interesing project

http://snapcraft.io/

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.