Re: SOHO images and XEphem
Thank you! ?I've done what you suggested and all is fine now. ?Unfortunately there is no maintainer for XEphem within the MacPorts community, so it looks like the latest version(s) won't get pushed to existing XEphem users via MacPorts.
|
Re: SOHO images and XEphem
You are right in release 4.0.1 Brandon had not included ssh patches
in order
to integrate kindly the collaborative parts ...
The 4.1 actual official release is fully operative on soho, catalogs
and planets moons until 2040.
Just upgrade !
Serge.
On 23/09/2021 08:34, SpikeLightfoot
wrote:
I'm not sure what the latest state of XEphem is with respect to
retrieving SOHO images. ?The images are currently available via
https (e.g.?)
but XEphem fails to communicate with the server. ?In earlier
versions there was an OpenSSH patch that needed compiling. ?(I'm
in macOS V11.6 (Big Sur), XEphem 4.0.1 compiled through MacPorts)
_._,_._,_
--
Serge Montagnac + GPG Key 0xDF083D7B +
Nature, Not Human Activity, Rules the Climate.
|
I'm not sure what the latest state of XEphem is with respect to retrieving SOHO images. ?The images are currently available via https (e.g.?) but XEphem fails to communicate with the server. ?In earlier versions there was an OpenSSH patch that needed compiling. ?(I'm in macOS V11.6 (Big Sur), XEphem 4.0.1 compiled through MacPorts)
|
Re: XEphem in its natural environment
Am Donnerstag, 23. September 2021, 03:41:28 CEST schrieb Trane Francks: Screenshot of XEphem running in Arch Linux
Rick
The fedora rpm packages that I'm providing are available for PPC little endian - I think all the longish computational stuff should be way more fun on something larger. I'm thinking IBM Power. Will try one day. Cheers MH -- Mathias Homann Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann@... (email / XMPP) LinkedIn: telegram: keybase: gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
|
Re: XEphem in its natural environment
No laughter from me. I
always liked the classical UNIX and Linux desktop environments.
For a time, I used TWM on Slackware, although I eventually
settled on KDE. I always wanted to see a solid CDE port on
Linux, but that doesn't seem to have come to pass. Or if it did,
it flew under my radar. These days, I just use Linux on servers
without X11 or a desktop environment installed, so XEphem is
used on my MacBook Pro. As long as I'm on UNIX or Linux, I'm a
happy boy.
trane
//
// Trane Francks trane@...
Tokyo, Japan
// Practice random kindness and senseless acts of beauty.
On 2021/09/23 10:00, Rick Towns wrote:
toggle quoted message
Show quoted text
I just wanted to thank Elwood (yet again!) for building such an
awesome program, and also all the people working on the github
version.
I run Arch Linux and I use TWM as my X Window manager. I just
updated my copy of XEphem today to the latest build (4.10) and it
was super smooth! Thank you all so much for all your work and
keeping this important piece of software alive.
Here's a screenshot of my desktop (don't laugh!). Take care!
Rick
|
XEphem in its natural environment
I just wanted to thank Elwood (yet again!) for building such an
awesome program, and also all the people working on the github
version.
I run Arch Linux and I use TWM as my X Window manager. I just
updated my copy of XEphem today to the latest build (4.10) and it
was super smooth! Thank you all so much for all your work and
keeping this important piece of software alive.
Here's a screenshot of my desktop (don't laugh!). Take care!
Rick
|
My attempt to install from? ?AUR (Arch User Repository) on Manjaro GNU/Linux was unsuccessful.? This is unusual.? I tried on a laptop and a desktop, both failed.? I will try to compile by hand,?before long.? I cannot add meaningful?remarks, but thought it would be on-topic to mention this.
I didn't make sense of the error messages.??
? ?make[1]: Leaving directory '/home/uca/.cache/yay/xephem/src/XEphem-4.1.0/libz'
? ?==> ERROR: A failure occurred in build().
? ? ? ? Aborting...
zlib is installed.??
Alan Davis
On Tue, Sep 21, 2021 at 6:22 AM Serge Montagnac < obs.psr@...> wrote:
On 21/09/2021 12:22, Brandon Rhodes
wrote:
On Mon, Sep 20, 2021 at 12:46 PM Serge Montagnac
< obs.psr@...>
wrote:
( the 7th field containing 131 should terminate at
column 28 but was 1 space more to the right ...? so 3 more
offsets appeared ...)
I recommend you to put my uranus.2040 attached file into
your auxil directory (do not try editing the old bad one!)
…
For Brandon: could you be kind to commit the file
as soon as possible on the Git repos or do you prefer me
todo
a git pull request ?
Thank you for the updated Uranus file, Serge! Having
applied your patch to the "main" branch in the repository, I
now see several more moons of Uranus in the window. (And I'm
curious to learn how??ukasz scrolled out far enough to see
the wayward moons in his screenshot — my window doesn't
scroll out that far!)
--
? "When the Last Tree has been cut down, the Last Fish caught,
?? the Last
River poisoned, only then will we realize
?? that One Cannot Eat Money." (Native American Saying) ? “Into this Universe, and why not knowing,
? Nor whence, like water willy-nilly flowing;
? And out of it, as wind along the Waste;
? I know not whither, willy nilly blowing.”
?????? (Rubáiyát of Omar Khayyám )
|
On 21/09/2021 12:22, Brandon Rhodes
wrote:
On Mon, Sep 20, 2021 at 12:46 PM Serge Montagnac
< obs.psr@...>
wrote:
( the 7th field containing 131 should terminate at
column 28 but was 1 space more to the right ...? so 3 more
offsets appeared ...)
I recommend you to put my uranus.2040 attached file into
your auxil directory (do not try editing the old bad one!)
…
For Brandon: could you be kind to commit the file
as soon as possible on the Git repos or do you prefer me
todo
a git pull request ?
Thank you for the updated Uranus file, Serge! Having
applied your patch to the "main" branch in the repository, I
now see several more moons of Uranus in the window. (And I'm
curious to learn how??ukasz scrolled out far enough to see
the wayward moons in his screenshot — my window doesn't
scroll out that far!)
_._,_._,_
Thanks to you also for the site management,
... with the bad data he was unable to see Miranda, 2 degrees away
...? but the window of around 1.5 arc minute
(full zoom default) can be stretched in either height or width to
normally see the 5 moons.
?
We can also use the minimum 00:05 min field of SkyView and then use
the ROI/zoom around Uranus system, so far ... so good
XEphem lacks very few useful things !
Serge.
--
Serge Montagnac + GPG Key 0xDF083D7B +
Nature, Not Human Activity, Rules the Climate.
|
Thank you for the updated Uranus file, Serge! Having applied your patch to the "main" branch in the repository, I now see several more moons of Uranus in the window. (And
I'm curious to learn how??ukasz scrolled out far enough to see the wayward moons in his screenshot — my window doesn't scroll out that far!) Something ate my answer: It's not Uranus view - this is Sky View with increased magnitute limit to about 18 mag -- ?ukasz Sanocki
|
?ukasz, thank you for providing a diff! But I'm not able to test that update yet, because I can't download the file in the first place. The URL that my XEphem displays for
"GSC 2.3" in the Field Stars Setup window is:
But XEphem can't successfully download that, and when I try it in my browser I get an error "Objects found : 0 ,, Null Request". (But maybe the URL only works with POST,
not the GET that my browser would have tried?)
If you'll let me know how to get the URL working, I'll be happy to try out your patch. Thanks! This is correct, but full url is someting like in line 31: RA is RA in degrees :) DEC is DEC :) SR is "FOV" - is limited to 0.5 degree You have to set these params in GET request I've add &CAT=GSC23 at the end becouse default catalog is now 2.4.2. -- ?ukasz Sanocki AP-Media
|
On Tue, 21 Sep 2021, Brandon Rhodes wrote: Thank you for the updated Uranus file, Serge! Having applied your patch to the "main" branch in the repository, I now see several more moons of Uranus in the window. (And
I'm curious to learn how??ukasz scrolled out far enough to see the wayward moons in his screenshot — my window doesn't scroll out that far!)
-- ?ukasz Sanocki AP-Media
|
You can do things like:
ifeq ($(shell uname -s), Darwin)
? ? LIBS += -lssl
endif
Am I correct that this change would switch the project to requiring GNU Make,?since I don't think?"ifeq" is compatible with all "make" implementations?
Is everyone happy with that change? If so, I could try adjusting the Makefile. I had assumed we needed the Makefile to remain more "vanilla", since the Makefile has (commented out) stanzas for SVR4, Solaris, HP-UX, and AIX, several of which at least would be running traditional "make" binaries. I'm not up to date on how many folks these days on other UNIXes like working with their traditional binary tools, and how many install "gmake" as a supplement.
(Or do we probably have no AIX customers any more, and those comments could be removed and GNU tools now assumed?)
|
On Mon, Sep 20, 2021 at 5:59 PM ?ukasz 'e2rd' Sanocki < lukasz@...> wrote:
I needed some faint-star catalog (~20mag), so I played about gsc 2.3 and
found post by Piero Bradley about this:
/g/xephem/topic/new_csv_format_for_downloaded/18594592?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,40,18594592,previd=1442322036000000000,nextid=1413821172000000000&previd=1442322036000000000&nextid=1413821172000000000
Following this lead a modify gscnet.c to work again with GSC 2.3.
I'm not "github-talkative" so I attached diff file with favour to
Brandon to make a commit.
?ukasz, thank you for providing a diff! But I'm not able to test that update yet, because I can't download the file in the first place. The URL that my XEphem displays for "GSC 2.3" in the Field Stars Setup window is:
But XEphem can't successfully download that, and when I try it in my browser I get an error "Objects found : 0 ,, Null Request". (But maybe the URL only works with POST, not the GET that my browser would have tried?)
If you'll let me know how to get the URL working, I'll be happy to try out your patch. Thanks!
|
On Mon, Sep 20, 2021 at 12:46 PM Serge Montagnac < obs.psr@...> wrote:
( the 7th field containing 131 should terminate at column 28 but
was 1 space more to the right ...? so 3 more offsets appeared ...)
I recommend you to put my uranus.2040 attached file into your
auxil directory (do not try editing the old bad one!)
…
For Brandon: could you be kind to commit the file as soon
as possible on the Git repos or do you prefer me todo
a git pull request ?
Thank you for the updated Uranus file, Serge! Having applied your patch to the "main" branch in the repository, I now see several more moons of Uranus in the window. (And I'm curious to learn how??ukasz scrolled out far enough to see the wayward moons in his screenshot — my window doesn't scroll out that far!)
|
Good evening, The structure of this file is magic to me but it works, thanks! :) I needed some faint-star catalog (~20mag), so I played about gsc 2.3 and found post by Piero Bradley about this: /g/xephem/topic/new_csv_format_for_downloaded/18594592?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,40,18594592,previd=1442322036000000000,nextid=1413821172000000000&previd=1442322036000000000&nextid=1413821172000000000 Following this lead a modify gscnet.c to work again with GSC 2.3. I'm not "github-talkative" so I attached diff file with favour to Brandon to make a commit. W dniu 20.09.2021 o?18:46, Serge Montagnac pisze:
Good evening ?ukasz, ... and Brandon ?
I didn't not work to much to find the bloody thing ... I suspected the *line 1 of uranus.2040* again ...
( the 7th field containing 131 should terminate at column 28 but was 1 space more to the right ...? so 3 more offsets appeared ...)
I recommend you to put my uranus.2040 attached file into your auxil directory (do not try editing the old bad one!)
For the trouble, I join my check done on IMCCE planets service and the same in pdf with XEphem (your observation of 2021-09-14)
*For Brandon*: could you be kind to commit the file as soon as possible on the Git repos or do you prefer me todo
a git pull request ?
On 20/09/2021 15:02, Serge Montagnac wrote:
Hi ?ukasz,
I agree with you an I'll contact Valery Lainey for closer control of the data polynomes (we had some troubles with fortran tables formating ...)
We play with high precision ephemerids so ... ?
... give us 3 or 4 days.
Best regards,
Serge.
On 19/09/2021 23:03, ?ukasz 'e2rd' Sanocki wrote:
Hello
I think there is serious bug in Uranus moons data (code?). While Titania and Oberon positions seems to be accurate, then other 3 moons are in random place - especially Miranda is faar away from planet...
Look at attachement screenshot and photo taken by me at 14.09.2021 22:40 UT. For example stellarium shows correct data.
btw, I've updated debian package for Ubuntu/Debian
W dniu 14.09.2021 o?14:44, Martin Federspiel pisze:
Hi to everyone, who contributed to version 4.1.0, and a huge thank you! That updates XEphem significantly. The quality of the updated positions of the Galilean moons can be checked e.g. by comparing Christopher Go's series of images of a triple transit of Callisto, Ganymede, and Europa on Aug 15th, 2021 (see ) with XEphem. During the transit there was also an occultation of Europa by Ganymede and a partial eclipse of Europa by Ganymede a few minutes later. All that is well reproduced by XEphem 4.1.0, whereas earlier versions didn't get the mutual events well.
Since openssl support is now included in 4.1.0, I had to install libssl-dev on my Ubuntu 20.04 system to get 4.1.0 compiled.
Thanks again and best regards,
Martin Federspiel --
Serge Montagnac + GPG Key 0xDF083D7B +
Nature, Not Human Activity, Rules the Climate.
--
?ukasz Sanocki
|
Wonderful, thank you everybody.
toggle quoted message
Show quoted text
On 9/20/21 6:46 AM, Serge Montagnac wrote: Good evening ?ukasz, ... and Brandon ?
I didn't not work to much to find the bloody thing ... I suspected the *line 1 of uranus.2040* again ...
( the 7th field containing 131 should terminate at column 28 but was 1 space more to the right ...? so 3 more offsets appeared ...)
I recommend you to put my uranus.2040 attached file into your auxil directory (do not try editing the old bad one!)
For the trouble, I join my check done on IMCCE planets service and the same in pdf with XEphem (your observation of 2021-09-14)
*For Brandon*: could you be kind to commit the file as soon as possible on the Git repos or do you prefer me todo
a git pull request ?
On 20/09/2021 15:02, Serge Montagnac wrote:
Hi ?ukasz,
I agree with you an I'll contact Valery Lainey for closer control of the data polynomes (we had some troubles with fortran tables formating ...)
We play with high precision ephemerids so ... ?
... give us 3 or 4 days.
Best regards,
Serge.
On 19/09/2021 23:03, ?ukasz 'e2rd' Sanocki wrote:
Hello
I think there is serious bug in Uranus moons data (code?). While Titania and Oberon positions seems to be accurate, then other 3 moons are in random place - especially Miranda is faar away from planet...
Look at attachement screenshot and photo taken by me at 14.09.2021 22:40 UT. For example stellarium shows correct data.
btw, I've updated debian package for Ubuntu/Debian
W dniu 14.09.2021 o?14:44, Martin Federspiel pisze:
Hi to everyone, who contributed to version 4.1.0, and a huge thank you! That updates XEphem significantly. The quality of the updated positions of the Galilean moons can be checked e.g. by comparing Christopher Go's series of images of a triple transit of Callisto, Ganymede, and Europa on Aug 15th, 2021 (see ) with XEphem. During the transit there was also an occultation of Europa by Ganymede and a partial eclipse of Europa by Ganymede a few minutes later. All that is well reproduced by XEphem 4.1.0, whereas earlier versions didn't get the mutual events well.
Since openssl support is now included in 4.1.0, I had to install libssl-dev on my Ubuntu 20.04 system to get 4.1.0 compiled.
Thanks again and best regards,
Martin Federspiel --
Serge Montagnac + GPG Key 0xDF083D7B +
Nature, Not Human Activity, Rules the Climate.
|
Thanks Mathias ... read my message to the list and upgrade the
uranus.2040 data file.
Thanks for coop,
Serge
On 20/09/2021 18:44, Mathias Homann
wrote:
rpm packages for openSUSE Leap 15.2, 15.3 and Tumbleweed and for Fedora 32, 33
and rawhide have been built successfully and can be found on OBS:
cheers
MH
--
Serge Montagnac + GPG Key 0xDF083D7B +
Nature, Not Human Activity, Rules the Climate.
|
Good evening ?ukasz, ... and Brandon ?
I didn't not work to much to find the bloody thing ... I suspected
the line 1 of uranus.2040 again ...
( the 7th field containing 131 should terminate at column 28 but
was 1 space more to the right ...? so 3 more offsets appeared ...)
I recommend you to put my uranus.2040 attached file into your
auxil directory (do not try editing the old bad one!)
For the trouble, I join my check done on IMCCE planets service and
the same in pdf with XEphem (your observation of 2021-09-14)
For Brandon: could you be kind to commit the file as soon
as possible on the Git repos or do you prefer me todo
a git pull request ?
On 20/09/2021 15:02, Serge Montagnac wrote:
toggle quoted message
Show quoted text
Hi ?ukasz,
I agree with you an I'll contact Valery Lainey for closer control
of the data polynomes (we had some troubles with fortran tables
formating ...)
We play with high precision ephemerids so ... ?
... give us 3 or 4 days.
Best regards,
Serge.
On 19/09/2021 23:03, ?ukasz 'e2rd'
Sanocki wrote:
Hello
I think there is serious bug in Uranus moons data (code?). While
Titania and Oberon positions seems to be accurate, then other 3
moons are in random place - especially Miranda is faar away from
planet...
Look at attachement screenshot and photo taken by me at
14.09.2021 22:40 UT. For example stellarium shows correct data.
btw, I've updated debian package for Ubuntu/Debian
W dniu 14.09.2021 o?14:44, Martin Federspiel pisze:
Hi to everyone, who contributed to
version 4.1.0, and a huge thank you! That updates XEphem
significantly. The quality of the updated positions of the
Galilean moons can be checked e.g. by comparing Christopher
Go's series of images of a triple transit of Callisto,
Ganymede, and Europa on Aug 15th, 2021 (see )
with XEphem. During the transit there was also an occultation
of Europa by Ganymede and a partial eclipse of Europa by
Ganymede a few minutes later. All that is well reproduced by
XEphem 4.1.0, whereas earlier versions didn't get the mutual
events well.
Since openssl support is now included in 4.1.0, I had to
install libssl-dev on my Ubuntu 20.04 system to get 4.1.0
compiled.
Thanks again and best regards,
Martin Federspiel
--
Serge Montagnac + GPG Key 0xDF083D7B +
Nature, Not Human Activity, Rules the Climate.
|
rpm packages for openSUSE Leap 15.2, 15.3 and Tumbleweed and for Fedora 32, 33
and rawhide have been built successfully and can be found on OBS:
cheers
MH
|
Hi ?ukasz,
I agree with you an I'll contact Valery Lainey for closer control of
the data polynomes (we had some troubles with fortran tables
formating ...)
We play with high precision ephemerids so ... ?
... give us 3 or 4 days.
Best regards,
Serge.
On 19/09/2021 23:03, ?ukasz 'e2rd'
Sanocki wrote:
Hello
I think there is serious bug in Uranus moons data (code?). While
Titania and Oberon positions seems to be accurate, then other 3
moons are in random place - especially Miranda is faar away from
planet...
Look at attachement screenshot and photo taken by me at 14.09.2021
22:40 UT. For example stellarium shows correct data.
btw, I've updated debian package for Ubuntu/Debian
W dniu 14.09.2021 o?14:44, Martin Federspiel pisze:
Hi to everyone, who contributed to version
4.1.0, and a huge thank you! That updates XEphem significantly.
The quality of the updated positions of the Galilean moons can
be checked e.g. by comparing Christopher Go's series of images
of a triple transit of Callisto, Ganymede, and Europa on Aug
15th, 2021 (see
) with XEphem.
During the transit there was also an occultation of Europa by
Ganymede and a partial eclipse of Europa by Ganymede a few
minutes later. All that is well reproduced by XEphem 4.1.0,
whereas earlier versions didn't get the mutual events well.
Since openssl support is now included in 4.1.0, I had to install
libssl-dev on my Ubuntu 20.04 system to get 4.1.0 compiled.
Thanks again and best regards,
Martin Federspiel
--
Serge Montagnac + GPG Key 0xDF083D7B +
Nature, Not Human Activity, Rules the Climate.
|
Rick Towns
