@echoix The bot removed the manually added macOS label. Do you have any suggestion/idea how to prevent that?

@echoix The bot removed the manually added macOS label. Do you have any suggestion/idea how to prevent that?

#531 (comment) It is the sync labels. Its the same way that if a file isn't changed anymore, the label will be removed.

@echoix The bot removed the manually added macOS label. Do you have any suggestion/idea how to prevent that?

#531 (comment) It is the sync labels. Its the same way that if a file isn't changed anymore, the label will be removed.

Thanks! Thought so. Let's see if this evolve into a problem / proper PITA.

Once it is ran, we can always change it, I don't remember if it removes it again after another commit, or it is only the ones added before opening a PR that get removed.

Wouldn't it be better to avoid moving from degrees <-> radians? Something like this (I didn't test):

diff --git a/raster/r.horizon/main.c b/raster/r.horizon/main.c
index 0694658449..65c96092ce 100644
--- a/raster/r.horizon/main.c
+++ b/raster/r.horizon/main.c
@@ -790,6 +790,7 @@ void calculate_shadow(void)
     yp = ymin + yy0;
 
     angle = (single_direction * deg2rad) + pihalf;
+    printangle = single_direction;
 
     maxlength = fixedMaxLength;
     fprintf(fp, "azimuth,horizon_height\n");
@@ -843,7 +844,6 @@ void calculate_shadow(void)
         if (degreeOutput) {
             shadow_angle *= rad2deg;
         }
-        printangle = angle * rad2deg - 90.;
         if (printangle < 0.)
             printangle += 360;
         else if (printangle >= 360.)
@@ -862,6 +862,7 @@ void calculate_shadow(void)
         }
 
         angle += dfr_rad;
+        printangle += step;
 
         if (angle < 0.)
             angle += twopi;

Wouldn't it be better to avoid moving from degrees <-> radians? Something like this (I didn't test):

That's a very good suggestion, works fine!

Wouldn't it be better to avoid moving from degrees <-> radians? Something like this (I didn't test):

That's a very good suggestion, works fine!

I was too quick to evaluate. Unfortunately this doesn't work as it is. Too much arithmetic on angle and printangle. I haven't been able to come up with a solution without risk of breaking something. Reverted to my initial solution.

Wouldn't it be better to avoid moving from degrees <-> radians? Something like this (I didn't test):

That's a very good suggestion, works fine!

I was too quick to evaluate. Unfortunately this doesn't work as it is. Too much arithmetic on angle and printangle. I haven't been able to come up with a solution without risk of breaking something. Reverted to my initial solution.

You mean it's incorrect in terms of algorithm, or just that it doesn't help with the arm issue?

Wouldn't it be better to avoid moving from degrees <-> radians? Something like this (I didn't test):

That's a very good suggestion, works fine!

I was too quick to evaluate. Unfortunately this doesn't work as it is. Too much arithmetic on angle and printangle. I haven't been able to come up with a solution without risk of breaking something. Reverted to my initial solution.

You mean it's incorrect in terms of algorithm, or just that it doesn't help with the arm issue?

Yes, it not working at all, independent on architecture. The CI tests went all red.

This solution runs at least on my machine:

diff --git a/raster/r.horizon/main.c b/raster/r.horizon/main.c
index 0694658449..c07c08c78a 100644
--- a/raster/r.horizon/main.c
+++ b/raster/r.horizon/main.c
@@ -790,6 +790,7 @@ void calculate_shadow(void)
     yp = ymin + yy0;
 
     angle = (single_direction * deg2rad) + pihalf;
+    printangle = single_direction;
 
     maxlength = fixedMaxLength;
     fprintf(fp, "azimuth,horizon_height\n");
@@ -843,11 +844,6 @@ void calculate_shadow(void)
         if (degreeOutput) {
             shadow_angle *= rad2deg;
         }
-        printangle = angle * rad2deg - 90.;
-        if (printangle < 0.)
-            printangle += 360;
-        else if (printangle >= 360.)
-            printangle -= 360;
 
         if (compassOutput) {
             double tmpangle;
@@ -862,11 +858,17 @@ void calculate_shadow(void)
         }
 
         angle += dfr_rad;
+        printangle += step;
 
         if (angle < 0.)
             angle += twopi;
         else if (angle > twopi)
             angle -= twopi;
+
+        if (printangle < 0.)
+            printangle += 360;
+        else if (printangle > 360.)
+            printangle -= 360;
     } /* end of for loop over angles */
 }

This solution runs at least on my machine:

And now on mine too! Pushed.

Thanks! Shall we back port to 8.3?

Thanks! Shall we back port to 8.3?

I would say no, since it's not really a bug fix. But if you plan to backport #3395, it may be easier to backport this as well.

Thanks! Shall we back port to 8.3?

I would say no, since it's not really a bug fix.

I’d say it is a bug fix, at least for (apple) arm machines. The question is rather, is the fix safe enough? (It seems to me be the case).

Thanks! Shall we back port to 8.3?

I would say no, since it's not really a bug fix.

I’d say it is a bug fix, at least for (apple) arm machines. The question is rather, is the fix safe enough? (It seems to me be the case).

Yes, I believe it's safe.

Backported to 8.3 in 9150097