Please provide more documentation

[sundraw]

I am using this solution successfully within the functionality demonstrated in the code samples. However, whenever I am trying to use a different function, e.g. swe_rise_trans or swe_revjul, I am unable to figure out the signature. Whatever I try, I get a 'Wrong parameter count' error message. Could you please provide some information or sample code regarding the use of different other functions? Swiss Ephemeris documentation doesn't seem to be helpful as PHP function signatures are substantially different.

[AstroSign-Dev]

Has nothing to do with this php-sweph, but it is a good site for documentation about sweph http://www.th-mack.de/download/swisseph-doc/swisseph/SwissEph.html#swe_rise_trans-double-int-java.lang.StringBuffer-int-int-double:A-double-double-swisseph.DblObj-java.lang.StringBuffer- maybe this gives you some hints about usage

[sundraw]

Thank you but I am quite familiar with Swiss Ephemeris docs, I am using them for many years, and I used Swiss Ephemeris successfully, both its C and Java versions. But with this extension, I am truly puzzled. I cannot even use a simple function like swe_revjul. Whatever I try, I get a 'Wrong parameter count' error.

[AstroSign-Dev]

I tried it and both Julian functions worked for me, swe_julday() and swe_revju(). I looked into the good documented source code and found that:

****/

double CALL_CONV swe_julday(int year, int month, int day, double hour, int gregflag) { double jd; double u,u0,u1,u2; u = year; if (month < 3) u -=1; u0 = u + 4712.0; u1 = month + 1.0; if (u1 < 4) u1 += 12.0; jd = floor(u0*365.25)

• floor(30.6*u1+0.000001)
• day + hour/24.0 - 63.5; if (gregflag == SE_GREG_CAL) { u2 = floor(fabs(u) / 100) - floor(fabs(u) / 400); if (u < 0.0) u2 = -u2; jd = jd - u2 + 2;
  if ((u < 0.0) && (u/100 == floor(u/100)) && (u/400 != floor(u/400))) jd -=1; } return jd; }

/* swe_revjul **** swe_revjul() is the inverse function to swe_julday(), see the description there. Arguments are julian day number, calendar flag (0=julian, 1=gregorian) return values are the calendar day, month, year and the hour of the day with decimal fraction (0 .. 23.999999).

Be aware the we use astronomical year numbering for the years before Christ, not the historical year numbering. Astronomical years are done with negative numbers, historical years with indicators BC or BCE (before common era). Year 0 (astronomical) = 1 BC historical year year -1 (astronomical) = 2 BC historical year year -234 (astronomical) = 235 BC historical year etc.

Original author Mark Pottenger, Los Angeles. with bug fix for year < -4711 16-aug-88 Alois Treindl *****/

Then I tried it and succeeded with this example: $jul_ut = 2458904.89479; echo "<br>swe_julday: " . swe_julday(2020,2,25,9.4749599955976,1); echo "<br>swe_revju:<pre>"; print_r(swe_revjul($jul_ut,1)); echo "</pre>";

which gave the following output: swe_julday: 2458904.89479 swe_revju: Array ( [year] => 2020 [month] => 2 [day] => 25 [hour] => 9.4749599955976 )

[sundraw]

Maybe something is wrong with my setup then... I am working on a Laravel app, and whenever I try to call swe_revjul with only two parameters, like you did, I am having a 502 Bad Gateway.

[AstroSign-Dev]

maybe inspecting php-fpm.log file may give you a hint: /usr/local/var/log/php-fpm.log

[sundraw]

Thank you, will have a look

[aloistr]

I propose to document each function directly in sweph.c just on top of the declaration. In a terse and consistent manner.

1. C declaration of the function, copied from programmer's docu
2. Input parameter of php function, using the same parameter names
3. Return value in case of success, with associative array key names if there is an associative array returned.
4. Same for case of failure. For existing functions, array key names have already been chosen. They are not always consistent, eg sometimes rc, sometimes retval for return values. In principle, the variable names of the C Programmer's docu should be used.

the advantage of documenting directly in the code is that it becomes trivial to keep docu in sync with code. If there is a style for automatic docu creation, like pod in Perl, it should be used.

[aloistr]

I have experimented with adding function docu in 'pod' style. Pod is the Perl documentation tool. Output in html looks like this:

source code looks like this, it is simply a C comment / ... / with pod format inside, on top of each function:

/* =pod

=head1 function swe_calc_ut (tjd_ut, ipl, iflag)

calculate position of planet ipl with time in Universal Time UT

=head2 Parameters

tjd_ut, ipl, iflag

=head2 return array

[0..5] position and speed vector xx ['serr'] optional error message ['rc'] return flag, < 0 in case of error

=head2 C declaration

int swe_calc_ut ( double tjd_ut, int ipl, int iflag, double xx, char serr);

=cut */

The output is created with

perldoc sweph.c

or, for html format

pod2html sweph.c > docu.html

[aloistr]

I created a branch docu_test with a few functions documented in this style.

[kevindecapite]

Very good. I have time set aside this afternoon & evening (PDT) to work on this. Thank you for getting things started.

[aloistr]

It's kind of funny, to use a Perl tool, to embed/extract documentation from a C program which creates a PHP extension. Only old foxes come up with ideas like that.

And for those older guys who use vi for program editing, like me, vi folding features to hide the pod sections are used. I had not been familiar with this folding code before, saw it the first time in
cyjoelchen /php-sweph/sweph.c and liked it immediately.

[aloistr]

Is in the works

[kevindecapite]

I like having the auto-generation syntax available. PHP has tools for this as well, but I'm not sure they would work in a c context. And don't despair, I use vi myself although admittedly I am not necessarily a spring chicken anymore either.

[aloistr]

I looked at phpdoc and tried, but had no sucess with using them on php-sweph. One can only pass a directory name as parameter, not a file name. phpdoc then digests the .php files in that directory.

As I prefer inline docu in sweph.c itself, that is not an option.

By the way, I do find the use of the filename sweph.c for the php interface a suboptimal choice, as sweph.c is an important file name in SE itself.

Can it be changed to phpsweph.c or something like that?

The sweph.so library name should also have a different name, to relate it clearly to php.

Or would that require a complete renaming of the repo?

Am 18.07.2021 um 08:31 schrieb Kevin DeCapite @.***>:

 I like having the auto-generation syntax available. PHP has tools for this as well, but I'm not sure they would work in a c context. And don't despair, I use vi myself although admittedly I am not necessarily a spring chicken anymore either.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

[kevindecapite]

I would be surprised if there wasn't a way to rename it. I tried building a few times by renaming the file and changing the following on L48 in config.m4:

PHP_NEW_EXTENSION(sweph, phpsweph.c, $ext_shared)

It built but did not install as an extension properly. I will continue to look into it.

I agree that using sweph.c is almost misleading, and have to double-check when opening the file to make sure I'm considering the correct one. That said, by convention, PHP extensions typically don't contain the acronym "php" in them.

Either way, a change like this would not require changing the name of the repo.

[aloistr]

The answer may be here https://www.zend.com/generating-php-extension-skeleton

Php prefix is discouraged, ok.

How about swephp.c instead of sweph.c

Then php_sweph.h must become php_swephp.h and all internal references must change.

The library will probably become swephp.so and /etc/php.ini must be updated.

This will justify a major release number change for php-sweph

That name php-sweph remains unchanged.

Am 18.07.2021 um 09:12 schrieb Kevin DeCapite @.***>:

 I would be surprised if there wasn't a way to rename it. I tried building a few times by renaming the file and changing the following on L48 in config.m4:

PHP_NEW_EXTENSION(sweph, phpsweph.c, $ext_shared) It built but did not install as an extension properly. I will continue to look into it.

I agree that using sweph.c is almost misleading, and have to double-check when opening the file to make sure I'm considering the correct one. That said, by convention, PHP extensions typically don't contain the acronym "php" in them.

Either way, a change like this would not require changing the name of the repo.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

[aloistr]

I created a branch (from master) where I renamed sweph to swephp

Required many changes in config.ma and the files swephp.c and php_swephp.h

The library now generated by make is named swephp.so

Please review this branch. If you agree, we will have to find a way to merge this

Am 18.07.2021 um 09:50 schrieb @.***:

 The answer may be here https://www.zend.com/generating-php-extension-skeleton

Php prefix is discouraged, ok.

How about swephp.c instead of sweph.c

Then php_sweph.h must become php_swephp.h and all internal references must change.

The library will probably become swephp.so and /etc/php.ini must be updated.

This will justify a major release number change for php-sweph

That name php-sweph remains unchanged.

Am 18.07.2021 um 09:12 schrieb Kevin DeCapite @.***>:

 I would be surprised if there wasn't a way to rename it. I tried building a few times by renaming the file and changing the following on L48 in config.m4:

PHP_NEW_EXTENSION(sweph, phpsweph.c, $ext_shared) It built but did not install as an extension properly. I will continue to look into it.

I agree that using sweph.c is almost misleading, and have to double-check when opening the file to make sure I'm considering the correct one. That said, by convention, PHP extensions typically don't contain the acronym "php" in them.

Either way, a change like this would not require changing the name of the repo.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.