Hello Ralf. Here is the code of 2.09.03: <a href="https://www.astro.

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

Hello Ralf,This are the changes in the version (<a href="https://www.

New version Swiss ephermeris code,about rstub/swephr

Comments (19)

rstub commented on August 26, 2024

@vreijs Sorry for the delay. I see there is meanwhile version 2.10 available. I guess it makes more sense to use that, right?

from swephr.

vreijs commented on August 26, 2024

Hello Ralf, Indeed best to take this newest version. I have gotten in the meantime a few 'new' computers and thus need to set up my environment again (and relearn it...).

…

On Sat, 1 May 2021 at 19:31, Ralf Stubner ***@***.***> wrote: @vreijs <https://github.com/vreijs> Sorry for the delay. I see there is meanwhile version 2.10 available. I guess it makes more sense to use that, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDLUFQ3PWK4P2H47YXCQJTTLQ3FXANCNFSM4RDCQV5A> .

from swephr.

rstub commented on August 26, 2024

Let me know if you have any questions. BTW, with v2.10 I have the following failures in the tests:

══ Failed tests ════════════════════════════════════════════════════════════════
── Failure (test-misc.R:22:5): deltat can be retrieved ─────────────────────────
swe_deltat(1234.567) not equal to 1.58738640540236.
1/1 mismatches
[1] 1.6 - 1.59 == 0.0103
── Failure (test-misc.R:29:5): deltat can be retrieved for vector ──────────────
swe_deltat(c(1234.567, 1234567)) not equal to c(1.5873864, 0.366039979375346).
2/2 mismatches (average diff: 0.0064)
[1] 1.598 - 1.587 == 0.0103
[2] 0.369 - 0.366 == 0.0025
── Failure (test-misc.R:72:5): version works ───────────────────────────────────
swe_version() not equal to "2.08".
1/1 mismatches
x[1]: "2.10"
y[1]: "2.08"
── Failure (test-misc.R:86:3): Determing ayanamsa using UT: ────────────────────
result$daya not equal to 24.99688.
1/1 mismatches
[1] 25 - 25 == -0.000115
── Failure (test-misc.R:94:3): Determing ayanamsa using ET: ────────────────────
result$daya not equal to 24.99688.
1/1 mismatches
[1] 25 - 25 == -0.000115

The first two differences are probably due to a deltaT update, right? The version change is also expected. Any idea about the last two changes?

from swephr.

vreijs commented on August 26, 2024

…

On Mon, 3 May 2021 at 09:20, Ralf Stubner ***@***.***> wrote: Let me know if you have any questions. BTW, with v2.10 I have the following failures in the tests: ══ Failed tests ════════════════════════════════════════════════════════════════ ── Failure (test-misc.R:22:5): deltat can be retrieved ───────────────────────── swe_deltat(1234.567) not equal to 1.58738640540236. 1/1 mismatches [1] 1.6 - 1.59 == 0.0103 ── Failure (test-misc.R:29:5): deltat can be retrieved for vector ────────────── swe_deltat(c(1234.567, 1234567)) not equal to c(1.5873864, 0.366039979375346). 2/2 mismatches (average diff: 0.0064) [1] 1.598 - 1.587 == 0.0103 [2] 0.369 - 0.366 == 0.0025 ── Failure (test-misc.R:72:5): version works ─────────────────────────────────── swe_version() not equal to "2.08". 1/1 mismatches x[1]: "2.10" y[1]: "2.08" ── Failure (test-misc.R:86:3): Determing ayanamsa using UT: ──────────────────── result$daya not equal to 24.99688. 1/1 mismatches [1] 25 - 25 == -0.000115 ── Failure (test-misc.R:94:3): Determing ayanamsa using ET: ──────────────────── result$daya not equal to 24.99688. 1/1 mismatches [1] 25 - 25 == -0.000115 The first two differences are probably due to a deltaT update, right? The version change is also expected. Any idea about the last two changes? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDLUFVAZ3ZGNB3G4NC3O2DTLZFEJANCNFSM4RDCQV5A> .

from swephr.

rstub commented on August 26, 2024

I meanwhile think what looked like deltaT was actually me testing without swephRdata. So probably no need to ask on the ML. Now I only need a proper fix for some new compiler warnings .... Victor Reijs ***@***.***> schrieb am Mo. 3. Mai 2021 um 22:50:

…

Hello Ralf, This are the changes in the version ( https://www.astro.com/swisseph/swisseph.htm#_Toc58931150): 2.08 13-jun-2019 update of Delta T and minor bug fixes 2.09 22-jul-2020 Improved Placidus houses, sidereal ephemerides, planetary magnitudes; minor bug fixes 2.10 10-dec-2020 NEW: planetary moons So no mention of changes in DeltaT for 2.09 and 2.10 (or it are minor bugfixes). If ther eis a chnage in DeltaT formula: I would expect that in DeltaT and UT related calculations there is a difference. Why Determing ayanamsa using ET:is different, I would not expect that.... So perhaps worth asking Swiss Ephemeris. I will do that. All the best, Victor On Mon, 3 May 2021 at 09:20, Ralf Stubner ***@***.***> wrote: > Let me know if you have any questions. BTW, with v2.10 I have the > following failures in the tests: > > ══ Failed tests ════════════════════════════════════════════════════════════════ > ── Failure (test-misc.R:22:5): deltat can be retrieved ───────────────────────── > swe_deltat(1234.567) not equal to 1.58738640540236. > 1/1 mismatches > [1] 1.6 - 1.59 == 0.0103 > ── Failure (test-misc.R:29:5): deltat can be retrieved for vector ────────────── > swe_deltat(c(1234.567, 1234567)) not equal to c(1.5873864, 0.366039979375346). > 2/2 mismatches (average diff: 0.0064) > [1] 1.598 - 1.587 == 0.0103 > [2] 0.369 - 0.366 == 0.0025 > ── Failure (test-misc.R:72:5): version works ─────────────────────────────────── > swe_version() not equal to "2.08". > 1/1 mismatches > x[1]: "2.10" > y[1]: "2.08" > ── Failure (test-misc.R:86:3): Determing ayanamsa using UT: ──────────────────── > result$daya not equal to 24.99688. > 1/1 mismatches > [1] 25 - 25 == -0.000115 > ── Failure (test-misc.R:94:3): Determing ayanamsa using ET: ──────────────────── > result$daya not equal to 24.99688. > 1/1 mismatches > [1] 25 - 25 == -0.000115 > > The first two differences are probably due to a deltaT update, right? The > version change is also expected. Any idea about the last two changes? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#59 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AEDLUFVAZ3ZGNB3G4NC3O2DTLZFEJANCNFSM4RDCQV5A> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGUIIS64B66D63SSOM5WWB3TL4EBVANCNFSM4RDCQV5A> .

from swephr.

vreijs commented on August 26, 2024

Did you already check if that indeed helped? I would have thought that DeltaT for such remote days would not depend on swephRdat. (DeltaT is a simple formula, which changes due to new historic analysis of eclipses...). Let me know if I need to retract my question to the SwiSS Ephemeris list. All the best, Victor

…

On Mon, 3 May 2021 at 22:54, Ralf Stubner ***@***.***> wrote: I meanwhile think what looked like deltaT was actually me testing without swephRdata. So probably no need to ask on the ML. Now I only need a proper fix for some new compiler warnings .... Victor Reijs ***@***.***> schrieb am Mo. 3. Mai 2021 um 22:50: > Hello Ralf, > > This are the changes in the version ( > https://www.astro.com/swisseph/swisseph.htm#_Toc58931150): > > 2.08 > > 13-jun-2019 > > update of Delta T and minor bug fixes > > 2.09 > > 22-jul-2020 > > Improved Placidus houses, sidereal ephemerides, planetary magnitudes; > minor > bug fixes > > 2.10 > > 10-dec-2020 > > NEW: planetary moons > > So no mention of changes in DeltaT for 2.09 and 2.10 (or it are minor > bugfixes). > If ther eis a chnage in DeltaT formula: I would expect that in DeltaT and > UT related calculations there is a difference. Why Determing ayanamsa > using > ET:is different, I would not expect that.... > > So perhaps worth asking Swiss Ephemeris. I will do that. > > All the best, > > Victor > > On Mon, 3 May 2021 at 09:20, Ralf Stubner ***@***.***> wrote: > > > Let me know if you have any questions. BTW, with v2.10 I have the > > following failures in the tests: > > > > ══ Failed tests > ════════════════════════════════════════════════════════════════ > > ── Failure (test-misc.R:22:5): deltat can be retrieved > ───────────────────────── > > swe_deltat(1234.567) not equal to 1.58738640540236. > > 1/1 mismatches > > [1] 1.6 - 1.59 == 0.0103 > > ── Failure (test-misc.R:29:5): deltat can be retrieved for vector > ────────────── > > swe_deltat(c(1234.567, 1234567)) not equal to c(1.5873864, > 0.366039979375346). > > 2/2 mismatches (average diff: 0.0064) > > [1] 1.598 - 1.587 == 0.0103 > > [2] 0.369 - 0.366 == 0.0025 > > ── Failure (test-misc.R:72:5): version works > ─────────────────────────────────── > > swe_version() not equal to "2.08". > > 1/1 mismatches > > x[1]: "2.10" > > y[1]: "2.08" > > ── Failure (test-misc.R:86:3): Determing ayanamsa using UT: > ──────────────────── > > result$daya not equal to 24.99688. > > 1/1 mismatches > > [1] 25 - 25 == -0.000115 > > ── Failure (test-misc.R:94:3): Determing ayanamsa using ET: > ──────────────────── > > result$daya not equal to 24.99688. > > 1/1 mismatches > > [1] 25 - 25 == -0.000115 > > > > The first two differences are probably due to a deltaT update, right? > The > > version change is also expected. Any idea about the last two changes? > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub > > <#59 (comment)>, or > > unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AEDLUFVAZ3ZGNB3G4NC3O2DTLZFEJANCNFSM4RDCQV5A > > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#59 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AGUIIS64B66D63SSOM5WWB3TL4EBVANCNFSM4RDCQV5A > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDLUFT6CQRAENUFM6HPRT3TL4EQDANCNFSM4RDCQV5A> .

from swephr.

vreijs commented on August 26, 2024

On Mon, 3 May 2021 at 22:54, Ralf Stubner ***@***.***> wrote: Now I only need a proper fix for some new compiler warnings ....

Should we also feed them back to Swiss Ephemeris, perhaps it are errors that could be removed by the authors in the future? All the best, Victor

from swephr.

rstub commented on August 26, 2024

I am not 100% sure, but the changes I introduced bring the deltaT tests without swephRdata in line with those with swephRdata installed: d7adf32
So I would like to do some more tests with this to make sure whether this comes from using version 2.10 or swephRdata being (not) present.

As for the compiler warnings:

     libswe/sweph.c:2306:37: warning: ‘%s’ directive writing up to 255 bytes into a region of size 240 [-Wformat-overflow=]
     libswe/sweph.c:2304:40: warning: ‘%s’ directive writing up to 255 bytes into a region of size 237 [-Wformat-overflow=]
     libswe/sweph.c:2302:41: warning: ‘%s’ directive writing up to 255 bytes into a region of size 236 [-Wformat-overflow=]
     libswe/sweph.c:2300:35: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 234 and 235 [-Wformat-overflow=]
     libswe/sweph.c:2298:34: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 235 and 236 [-Wformat-overflow=]
     libswe/sweph.c:2295:38: warning: ‘%s’ directive writing up to 255 bytes into a region of size between 231 and 240 [-Wformat-overflow=]

Yes, it would be helpful to get input from the SE developers. These come from a portion of the code ( https://github.com/rstub/swephR/blob/feature/v2.10/external/src/sweph.c#L2295-L2306) where a new string s is created based on a format and another string sp. Unfortunately, both s and sp have the same max length and could therefor lead to an overflow. I had tried to use snprintf instead of sprintf, but this gives a "truncation" warning. In my current PR, I try to forcefully truncate sp (cf a646c98) which works locally but not in the (new) CI (https://github.com/rstub/swephR/pull/60/checks?check_run_id=2494991210). One alternative would be to replace %s with something like %.200s, which again does work locally. I have not tried this on CI.

from swephr.

vreijs commented on August 26, 2024

On Tue, 4 May 2021 at 09:59, Ralf Stubner ***@***.***> wrote: I am not 100% sure, but the changes I introduced bring the deltaT tests without swephRdata in line with those with swephRdata installed: d7adf32 <d7adf32> So I would like to do some more tests with this to make sure whether this comes from using version 2.10 or swephRdata being (not) present.

We provide in R both swe_deltat and swe_deltat_ex (the last one is the recommended one)? I use in my excel swe_deltat_ex and for both 2.08 and 2.10 I get the same results at Dieter (of SE). I am using the internal ephemeris (no data files). Does the swe_deltat_ex provide errors when testing? Perhaps we should remove swe_deltat?

from swephr.

rstub commented on August 26, 2024

I do a difference with v2.08 depending on whether swephRdata is installed or not. I don't see such a difference for v2.10.

v2.08 w/o swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R1 R -q -f  swe-test.R 
> library(swephR)
> swe_version()
[1] "2.08"
> requireNamespace("swephRdata")
Loading required namespace: swephRdata
Failed with error:  ‘there is no package called ‘swephRdata’’
> swe_deltat(c(1234.567, 1234567))
[1] 1.587386 0.366040

v2.08 w/ swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R2 R -q -f  swe-test.R 
> library(swephR)
> swe_version()
[1] "2.08"
> requireNamespace("swephRdata")
> swe_deltat(c(1234.567, 1234567))
[1] 1.5976757 0.3685434

v2.10 w/o swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R3 R -q -f  swe-test.R 
> library(swephR)
> swe_version()
[1] "2.10"
> requireNamespace("swephRdata")
Loading required namespace: swephRdata
Failed with error:  ‘there is no package called ‘swephRdata’’
> swe_deltat(c(1234.567, 1234567))
[1] 1.5976757 0.3685434

v2.10 w/o swephRdata

ralf@barra:~/tmp$ R -q -f  swe-test.R 
> library(swephR)
> swe_version()
[1] "2.10"
> requireNamespace("swephRdata")
> swe_deltat(c(1234.567, 1234567))
[1] 1.5976757 0.3685434

What would be the expected behavior here?

BTW, thanks for forwarding the suggestion from the SE developers, which does indeed work, cf https://github.com/rstub/swephR/pull/60/checks?check_run_id=2502228436

from swephr.

vreijs commented on August 26, 2024

Hello Ralf, What if you look at swe_deltat_ex's output? That is a better function (I only use that in my Excel by the way and it gives the same results for 2.08 and 2.10)? I will build up my R environment and get to learn it again. So that I can better assist! What changes do the SE developers need to include in their code, so that in the future it will work? Are they all in: ea6546e All the best, Victor

…

On Tue, 4 May 2021 at 21:56, Ralf Stubner ***@***.***> wrote: I do a difference with v2.08 depending on whether swephRdata is installed or not. I don't see such a difference for v2.10. v2.08 w/o swephRdata ***@***.***:~/tmp$ R_LIBS_USER=~/tmp/R1 R -q -f swe-test.R > library(swephR) > swe_version() [1] "2.08" > requireNamespace("swephRdata") Loading required namespace: swephRdata Failed with error: ‘there is no package called ‘swephRdata’’ > swe_deltat(c(1234.567, 1234567)) [1] 1.587386 0.366040 v2.08 w/ swephRdata ***@***.***:~/tmp$ R_LIBS_USER=~/tmp/R2 R -q -f swe-test.R > library(swephR) > swe_version() [1] "2.08" > requireNamespace("swephRdata") > swe_deltat(c(1234.567, 1234567)) [1] 1.5976757 0.3685434 v2.10 w/o swephRdata ***@***.***:~/tmp$ R_LIBS_USER=~/tmp/R3 R -q -f swe-test.R > library(swephR) > swe_version() [1] "2.10" > requireNamespace("swephRdata") Loading required namespace: swephRdata Failed with error: ‘there is no package called ‘swephRdata’’ > swe_deltat(c(1234.567, 1234567)) [1] 1.5976757 0.3685434 v2.10 w/o swephRdata ***@***.***:~/tmp$ R -q -f swe-test.R > library(swephR) > swe_version() [1] "2.10" > requireNamespace("swephRdata") > swe_deltat(c(1234.567, 1234567)) [1] 1.5976757 0.3685434 What would be the expected behavior here? BTW, thanks for forwarding the suggestion from the SE developers, which does indeed work, cf https://github.com/rstub/swephR/pull/60/checks?check_run_id=2502228436 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDLUFST65ZL2CO42TBMSQDTMBGN5ANCNFSM4RDCQV5A> .

from swephr.

rstub commented on August 26, 2024

Using swe_deltat_ex in the four different environments one can learn more about what is going on.

v2.08 w/o swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R1 R -q -f  swe-test2.R 
> library(swephR)
> swe_version()
[1] "2.08"
> requireNamespace("swephRdata")
Loading required namespace: swephRdata
Failed with error:  ‘there is no package called ‘swephRdata’’
> swe_deltat_ex(c(1234.567, 1234567), 2)
$deltat
[1] 1.587386 0.366040

$serr
[1] "SwissEph file 'seplm48.se1' not found in PATH '/usr/local/lib/R/site-library/swephR/ephemeris/'"                       
[2] "SwissEph file 'seplm18.se1' not found in PATH '/usr/local/lib/R/site-library/swephR/ephemeris/' \nusing Moshier eph.; "

> swe_deltat_ex(c(1234.567, 1234567), 4)
$deltat
[1] 1.587386 0.366040

$serr
[1] "" ""

v2.08 w/ swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R2 R -q -f  swe-test2.R 
> library(swephR)
> swe_version()
[1] "2.08"
> requireNamespace("swephRdata")
> swe_deltat_ex(c(1234.567, 1234567), 2)
$deltat
[1] 1.5976757 0.3685434

$serr
[1] "" ""

> swe_deltat_ex(c(1234.567, 1234567), 4)
$deltat
[1] 1.587386 0.366040

$serr
[1] "" ""

v2.10 w/o swephRdata

ralf@barra:~/tmp$ R_LIBS_USER=~/tmp/R3 R -q -f  swe-test2.R 
> library(swephR)
> swe_version()
[1] "2.10"
> requireNamespace("swephRdata")
Loading required namespace: swephRdata
Failed with error:  ‘there is no package called ‘swephRdata’’
> swe_deltat_ex(c(1234.567, 1234567), 2)
$deltat
[1] 1.5976757 0.3685434

$serr
[1] "" ""

> swe_deltat_ex(c(1234.567, 1234567), 4)
$deltat
[1] 1.587386 0.366040

$serr
[1] "" ""

v2.10 w/ swephRdata

ralf@barra:~/tmp$ R -q -f  swe-test2.R 
> library(swephR)
> swe_version()
[1] "2.10"
> requireNamespace("swephRdata")
> swe_deltat_ex(c(1234.567, 1234567), 2)
$deltat
[1] 1.5976757 0.3685434

$serr
[1] "" ""

> swe_deltat_ex(c(1234.567, 1234567), 4)
$deltat
[1] 1.587386 0.366040

$serr
[1] "" ""

So it seems like v2.10 no longer needs the SE data files for making deltaT computations using SE instead of Moshier. Is that expected? Or am I misinterpreting things here?

ea6546e also contains the removal of my previous attempt at fixing the new issue. The best reference are allways the files in external/patch, in this case https://github.com/rstub/swephR/blob/ea6546eb004ff448cfac4951a9b3790222e884a0/external/patch/19_increase_buffer.diff.

BTW, thanks for telling me about v2.10.1. I will integrate this into this branch. Can you compile a list of changes since v2.08? I would like to add that to NEWS.md.

from swephr.

rstub commented on August 26, 2024

BTW, v2.10.1 brings in quite some changes, given that it is "only" a patch release:

two source files are no longer used (swepcalc.c and swepdate.c)
all other sources are now covered by AGPL and no longer GPL, even though LICENSE still refers to GPL

THe second point is no big issue for us, since swephR has always been covered by AGPL. But might be confusing for other users of the source code. Have the SE authors mentioned this change in any way?

from swephr.

rstub commented on August 26, 2024

Yet another BTW, the patch 19_increase_buffer.diff is part of version 2.10.01.

from swephr.

vreijs commented on August 26, 2024

Hallo Ralf, There was some small feedback not not negative. The reasoning is here (of Alois):

On Wed, Apr 21, 2021 at 1:17 PM Alois Treindl ***@***.***> wrote: We intend to change the licensing policy for Swiss Ephemeris from GPL 2.0

to AFGPLv3, starting from the next release, 2.10.1 and later.

See https://en.wikipedia.org/wiki/GNU_Affero_General_Public_License for a

description.

The change is intended to close a loophole in the GPL license. The old license allows a Swiss Ephemeris user to use our software, modify

it at will and run it on a server.

As long as he does not distribute his software (passes it on to others)

he is not obliged to make the source code

and his modifications available to anyone, including the authors of the

software.

Under AFGPL such a user must make his software source code available for

download also to users of his server.

That way, something is returned to the community. Others may profit from

his work, just as he profits from our work, for free.

With the dual licensing model of Swiss Ephemeris such a service provider

has still the option to purchase the professional license, which frees him from the obligation to make his source code available. Relating to: swepcalc.c and swepdate.c: Were they removed in 2.10.1? Or are they simply not used anymore? In that last case: should I mention to the SE authors that they should remove these two functions? So I understand the that size issue of s has been included in 2.10.1, correct? Great.

…

On Thu, 13 May 2021 at 17:36, Ralf Stubner ***@***.***> wrote: BTW, v2.10.1 brings in quite some changes, given that it is "only" a patch release: - two source files are no longer used (swepcalc.c and swepdate.c) - all other sources are now covered by AGPL and no longer GPL, even though LICENSE still refers to GPL THe second point is no big issue for us, since swephR has always been covered by AGPL. But might be confusing for other users of the source code. Have the SE authors mentioned this change in any way? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDLUFVV43T736IKAU2VMB3TNPWWNANCNFSM4RDCQV5A> .

from swephr.

vreijs commented on August 26, 2024

Hello Ralf, The changes from 2.08 to 2.10.1 can be seen here: https://www.astro.com/swisseph/swephprg.htm#_Toc71121304 I know that swe_ deltat does not handle the different ephemerises correctly, that is why they introduce swe_delta_ex. So in some way swe_deltat is buggy (and not recommended to be used anymore). BUT what I find strange is that even in 2.10 the deltaT changed when using a different ephemeris. I would have thought it would stay the same... II will query this with the SE authors.

…

On Thu, 13 May 2021 at 08:16, Ralf Stubner ***@***.***> wrote: Using swe_deltat_ex in the four different environments one can learn more about what is going on. v2.08 w/o swephRdata ***@***.***:~/tmp$ R_LIBS_USER=~/tmp/R1 R -q -f swe-test2.R > library(swephR) > swe_version() [1] "2.08" > requireNamespace("swephRdata") Loading required namespace: swephRdata Failed with error: ‘there is no package called ‘swephRdata’’ > swe_deltat_ex(c(1234.567, 1234567), 2) $deltat [1] 1.587386 0.366040 $serr [1] "SwissEph file 'seplm48.se1' not found in PATH '/usr/local/lib/R/site-library/swephR/ephemeris/'" [2] "SwissEph file 'seplm18.se1' not found in PATH '/usr/local/lib/R/site-library/swephR/ephemeris/' \nusing Moshier eph.; " > swe_deltat_ex(c(1234.567, 1234567), 4) $deltat [1] 1.587386 0.366040 $serr [1] "" "" v2.08 w/ swephRdata ***@***.***:~/tmp$ R_LIBS_USER=~/tmp/R2 R -q -f swe-test2.R > library(swephR) > swe_version() [1] "2.08" > requireNamespace("swephRdata") > swe_deltat_ex(c(1234.567, 1234567), 2) $deltat [1] 1.5976757 0.3685434 $serr [1] "" "" > swe_deltat_ex(c(1234.567, 1234567), 4) $deltat [1] 1.587386 0.366040 $serr [1] "" "" v2.10 w/o swephRdata ***@***.***:~/tmp$ R_LIBS_USER=~/tmp/R3 R -q -f swe-test2.R > library(swephR) > swe_version() [1] "2.10" > requireNamespace("swephRdata") Loading required namespace: swephRdata Failed with error: ‘there is no package called ‘swephRdata’’ > swe_deltat_ex(c(1234.567, 1234567), 2) $deltat [1] 1.5976757 0.3685434 $serr [1] "" "" > swe_deltat_ex(c(1234.567, 1234567), 4) $deltat [1] 1.587386 0.366040 $serr [1] "" "" v2.10 w/ swephRdata ***@***.***:~/tmp$ R -q -f swe-test2.R > library(swephR) > swe_version() [1] "2.10" > requireNamespace("swephRdata") > swe_deltat_ex(c(1234.567, 1234567), 2) $deltat [1] 1.5976757 0.3685434 $serr [1] "" "" > swe_deltat_ex(c(1234.567, 1234567), 4) $deltat [1] 1.587386 0.366040 $serr [1] "" "" So it seems like v2.10 no longer needs the SE data files for making deltaT computations using SE instead of Moshier. Is that expected? Or am I misinterpreting things here? ea6546e <ea6546e> also contains the removal of my previous attempt at fixing the new issue. The best reference are allways the files in external/patch, in this case https://github.com/rstub/swephR/blob/ea6546eb004ff448cfac4951a9b3790222e884a0/external/patch/19_increase_buffer.diff . BTW, thanks for telling me about v2.10.1. I will integrate this into this branch. Can you compile a list of changes since v2.08? I would like to add that to NEWS.md. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDLUFS2T5BY5SSZC4QWFPTTNNVCDANCNFSM4RDCQV5A> .

from swephr.

rstub commented on August 26, 2024

Hi Victor,

Concerning AGPL: Excellent! You could ask the SE authors to also update the LICENSE file in their distribution. For us this means we can get rid of the LICENSE file and just say "AGPL" in DESCRIPTION.

Concerning the two no longer used files: They are still part of the distribution (and are therefore still in external/src), but they are no longer needed for building the library. That's why I have deleted them from src/libswe. I see no need for the SE authors to take action, since there are other files in the distribution that are not needed to build the library.

I am curious to see what comes out of the deltaT discussion.

from swephr.

vreijs commented on August 26, 2024

Hello Ralf, Can you tell which precise file it is? Dieter of SE is asking. All the best, Victor

…

On Thu, 13 May 2021 at 20:14, Ralf Stubner ***@***.***> wrote: Hi Victor, Concerning AGPL: Excellent! You could ask the SE authors to also update the LICENSE file in their distribution. For us this means we can get rid of the LICENSE file and just say "AGPL" in DESCRIPTION. Concerning the two no longer used files: They are still part of the distribution (and are therefore still in external/src), but they are no longer needed for building the library. That's why I have deleted them from src/libswe. I see no need for the SE authors to take action, since there are other files in the distribution that are not needed to build the library. I am curious to see what comes out of the deltaT discussion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDLUFRWD7NNFN4S7BX4L6LTNQJJ3ANCNFSM4RDCQV5A> .

from swephr.

rstub commented on August 26, 2024

I am refering to the src/LICENSE file in the source distribution:

[ralf@barra: ~/devel/swephR/external] [feature/v2.10 ↑·1|…6⚑ 2] ✔
08:31 $ tar xfO swe_unix_src_2.10.01.tar.gz src/LICENSE | head -n 20
/* Copyright (C) 1997 - 2008 Astrodienst AG, Switzerland.  All rights reserved.

  License conditions
  ------------------

  This file is part of Swiss Ephemeris.

  Swiss Ephemeris is distributed with NO WARRANTY OF ANY KIND.  No author
  or distributor accepts any responsibility for the consequences of using it,
  or for whether it serves any particular purpose or works at all, unless he
  or she says so in writing.  

  Swiss Ephemeris is made available by its authors under a dual licensing
  system. The software developer, who uses any part of Swiss Ephemeris
  in his or her software, must choose between one of the two license models,
  which are
  a) GNU public license version 2 or later
  b) Swiss Ephemeris Professional License

  The choice must be made before the software developer distributes software

from swephr.

New version Swiss ephermeris code about swephr HOT 19 CLOSED

Comments (19)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent