<p>I'm getting into scripting in Stellarium, and it's fairly similar to the scripting language used in a real Planetarium I used to work in, which used DigitalSky2, if memory serves. In the Planetarium I was able to write code "in real time" as such - meaning I could write one line and run it, like writing Python code into Terminal, and in doing so I was able to learn a lot about how it worked (and break it - all. the. time.)</p>

<p>This having to write a script, upload it and run the whole thing is less than efficient, and doesn't suit my learning-a-new-language style. Especially when I'm really just wanting to play around with the script, one line at a time, and see how I can best break it... I mean, tests its limitations! </p>

<p>Is there any way of doing this? Or is it a pipe dream I have to let go of for the time being?</p>

<p>Cheers!</p>

CC BY-SA 4.0
2020-03-23T14:51:48.370Z
This is natures way of telling you to read the manual !  Note as a programmer I'd suggest learning a new language by experiment with another API for a complex system is not a good idea.  You need to learn the language properly, independent of another complexity and then apply what you understand of the language to the API designed for it - it's a lot less problematic as you have two smaller problems to deal with rather than one huge one.  You can have confidence in your language knowledge so that you don't find yourself having to work out the source of a problem - language or API.
StephenG - Help Ukraine
CC BY-SA 4.0
2020-03-24T19:09:31.337Z
@barrycarter Perhaps you could clarify what "completely disagree" actually means : what do you think is a *good* way to approach learning a new language and new API at the same time ?
StephenG - Help Ukraine
CC BY-SA 4.0
2020-03-25T17:31:51.530Z
@barrycarter So no rationale, just your intuition at work.  My experience with bug fixing is that even experienced programmers will make assumptions about how they *think* things should work, generate bug reports and then you discover the problem is not properly learning the basics or reading the manual for the API properly.  A day of proper language study can avoid weeks of frustrating false bugs later.  If you feel it's disrespectful to give people constructive advice then that's *your* problem and I can't fix that.  Whatever "insult" you're reading into you remarks is not my problem.
StephenG - Help Ukraine
CC BY-SA 4.0
2020-04-16T04:20:44.743Z
Thank you both for your recommendations, on all fronts. I usually do a combo of reading the docs and experimenting with the code, which as far as my reasonably extensive programming experience shows me is a fairly common method. What I've been doing so far on this is what @barrycarter suggested - editing the one script and re-running it. I don't have a huge amount I want to do currently, just things like change the direction I'm pointing, the time, the FOV, etc. Small things to start with until I get a better basic understanding for the language.
user1153070
<software>
"Real time" Stellarium Scripting?
user1153070
# "Real time" Stellarium Scripting?

(Asked by: username_0 on 2020-03-23)

I'm getting into scripting in Stellarium, and it's fairly similar to the scripting language used in a real Planetarium I used to work in, which used DigitalSky2, if memory serves. In the Planetarium I was able to write code "in real time" as such - meaning I could write one line and run it, like writing Python code into Terminal, and in doing so I was able to learn a lot about how it worked (and break it - all. the. time.)

This having to write a script, upload it and run the whole thing is less than efficient, and doesn't suit my learning-a-new-language style. Especially when I'm really just wanting to play around with the script, one line at a time, and see how I can best break it... I mean, tests its limitations!

Is there any way of doing this? Or is it a pipe dream I have to let go of for the time being?

Cheers!

**Tags:** software
> **Comments:**
> **username_1**: This is natures way of telling you to read the manual !  Note as a programmer I'd suggest learning a new language by experiment with another API for a complex system is not a good idea.  You need to learn the language properly, independent of another complexity and then apply what you understand of the language to the API designed for it - it's a lot less problematic as you have two smaller problems to deal with rather than one huge one.  You can have confidence in your language knowledge so that you don't find yourself having to work out the source of a problem - language or API.  
> **username_1**: @barrycarter Perhaps you could clarify what "completely disagree" actually means : what do you think is a *good* way to approach learning a new language and new API at the same time ?  
> **username_1**: @barrycarter So no rationale, just your intuition at work.  My experience with bug fixing is that even experienced programmers will make assumptions about how they *think* things should work, generate bug reports and then you discover the problem is not properly learning the basics or reading the manual for the API properly.  A day of proper language study can avoid weeks of frustrating false bugs later.  If you feel it's disrespectful to give people constructive advice then that's *your* problem and I can't fix that.  Whatever "insult" you're reading into you remarks is not my problem.  
> **username_0**: Thank you both for your recommendations, on all fronts. I usually do a combo of reading the docs and experimenting with the code, which as far as my reasonably extensive programming experience shows me is a fairly common method. What I've been doing so far on this is what @barrycarter suggested - editing the one script and re-running it. I don't have a huge amount I want to do currently, just things like change the direction I'm pointing, the time, the FOV, etc. Small things to start with until I get a better basic understanding for the language.  

---

## 0 answers

