I'm trying to make a calendar script work in GIMP 2.10
Have already replaced occurence of NORMAL-MODE with LAYER-MODE_NORMAL-LEGACY
and BACKGROUND-FILL with FILL-BACKGROUND

Now when I run Filters/Render/Calendar... it gives me following error:
Error: ( : 1) atom->string: needs 1 argument(s)

I have no idea what it wants to tell me by that ... what to change where.
Is there anyone around who can help?

I attach the original script [sg-calendar.scm] ( working in GIMP 2.8.x) and my trial to make it work in 2.10
as far as I have it now [sg-calendar210.scm].

Any help very appreciated
nelo

Tried both versions.

I don't get that error, but a different one:

Error: Procedure execution of gimp-image-lower-layer failed: Layer cannot be lowered more.

This only when trying to create a full year.
When trying to create one single month, it runs.

This is the same error I get when running 'Wills Animation Merge' script in Gimp 2.10. The script works in Gimp 2.88.
Maybe there are other scripts throwing this error message?
I would be very interested in a solution.
Obviously Gimp 2.10 is processing scheme differently

It seems to work on a Windows 7 32 bit version but it produces above mentioned error on my Linux 64 bit system. If only I knew how to find the position in the script that causes this.

Sprinkle the code with calls to gimp-message and see which one prints last, then by dichotomy you'll quickly find out.

These scripts wouldn't work for me using gimp 2.8.22 on windows 10 64bit until I replaced the text shown below with numbers

I replaced
LAYER-MODE-NORMAL-LEGACY with the number 0
FILL-BACKGROUND with the number 1
FILL-TRANSPARENT with the number 3

edit there are two FILL-BACKGROUND to replace

Hello Steve,
thanks for your reply.
Tried that version, too. But didn't make a difference

Hello Ofnuts,
Thanks for pointing me to the gim-message stuff which I didn#t know before. I'm sure it'll help me locate errors.

If you write it in Python, and you start Gimp from the Terminal, you get row numbers where the error occurs via stderr (probably); at least in the Gimp version I use (2.6-ish). That doesn't happen with the Scheme interpreter?
(Personally, I refuse to have anything to do with Scheme code, so I wouldn't know.)
Example (I temporarily destroyed my working code):

Thanks for your reply.
No the Scheme interpreter doesn't do this. There is a message window in GIMP if errors occur.
Normally if you have for example NORMAL-MODE instead of LAYER-MODE-NORMAL-LEGACY (which is to be used in GIMP 2.10) it tells you about NORMAL-MODE ... so I can check the code, search which procedure goes with it, check the procedure-browser how to do it and so on. But with mentioned error message ? There's no "atom", no "string" in the code and I don't know enough SCHEME to see the error.
I might have found the place where things go wrong ( using gimp-message to narrow it down). Now I have to learn why and how to correct.

I encountered this error from within a python script a good while ago - I cannot really remember what on earth it was - but it was a pain to track down. And yes I used gimp_message to narrow down the possibilities. Best of luck.

When I find buggy scheme scripts I find it faster to rewrite them in Python

About everything is an atom in Scheme (except lists). Here the error would be some implicit conversion of an atom to a string, but since it's implicit it will be hard to find (especially since the atom isn't a string... )

Here are 3 steps to troubleshoot old scripts in Gimp 2.10.

Open Gimp 2.10 Edit > Preferences > Debugging > change debug policy to 'debug warnings, critical errors and crashes > click OK.
Close Gimp.

open command prompt.
gimp --pdb-compat-mode=off --verbose
(Windows needs the full path to Gimp)

If your script works on layers then open a mutilayer test image(s) and change the little box in 'Layers -Patterns' to the right of 'mode'. Change to 'Legacy'.
Hopefully you will get more info on whats failing.

I find 5 instances of the function number->string in your modified version of the code.

In the file GIMP 2.10\share\gimp\2.0\scripts\script-fu.init you will find the definition of number->string, which uses atom->string:


I am very puzzled how you can manage to get the error reported because I don't see a way for the script to have called atom->string without anything as an argument.

@Tas_mania
Thanks fo the tip on debugging. I'll try that out.

@paynekj
I don't know what's missing there, what it's complaining about. Why it reports to me and not to others. Also I don't understand why the original code works on a windows 7 install of GIMP 2.10 and not on my Linux flatpak installation. Hopefully I'll find out. Otherwise I'll have to keep GIMP 2.8 just do make next year's calendar towards the end of the year.

Just to be sure I didn't break anything I'll start modifying from the beginning ... with all that debug stuff enabled. I'll see how far I get, what errors occur.

Here's something else to try to check the building-blocks are in place.

Start the Script-fu console Filters>>Script-Fu>>Console

In the command line:
(tracing TRUE)
(number->string 5)

I get this, do you?

Pity. Perhaps use diff?
I get this:

Unless diff hides a character, or it should be like it is typed, MO is not equal to MOD, correct?

So I guess this one is one of the culprits:
(date-str (number->string date))

comparing the script-fu.init files of both GIMP versions I find.
GIMP 2.8:
(define (number->string n) (anyatom->string n number?))
GIMP 2.10:
(define (number->string n . base)

so far so good.
How would I have to change that line? Please help ...

and here is the output of script-fu TRACE:

Something else to try in the script-fu console

If it doesn't work with the 2nd test, then it looks like your version of GIMP has been built differently and it's time to start questioning the developers.

Full disclaimer. I'm trying this with GIMP-2.10-RC1 as I haven't been brave enough to install full 2.10 yet (too much trouble to keep the older versions intact)

It would be helpful if others could try the same test, stating which GIMP version and operating system.

Same as yours in my 2.10 flatpak on 'buntu 16.04.