Need Help Testing A Simple Script

Wallace · **Posted:** Sun Mar 15, 2015 3:39 pm **(#41)**

GnuTux wrote:

You should be OK, Wallace. The test-calc script was just a quick tool help solve the mystery of why some users were getting incorrect results when using 3D-Extrusion.

As it turns out, someone has released a script which globally redefines several standard math functions, including the round function. GIMP users who have images-grid-layout.scm installed are potentially going to have problems with any other script that makes use these functions (i.e. 3D Extrusion).

At this point, the solution is to remove or better yet, use the updated version of images-grid-layout.scm, which SaulGoode and Odin have corrected and attached to this post.

Okay no problem, thanks.

paynekj · **Posted:** Sun Mar 15, 2015 3:46 pm **(#42)**

GnuTux wrote:

Proper coding practice directs that if a function is to be used locally, it should be declared as being local. If the function actually needs to be global, the coder needs to ensure the function name is unique.

That's certainly good advice:- we've seen here where people have had two copies of the same script and wondered why editing one of them had no effect, or where the second script has the same name but a completely different function. It was those circumstances that prompted me to create the test for duplicate scripts: http://gimpscripts.com/2011/11/test-for ... e-scripts/ although that wouldn't have found this problem- maybe someone could create a test script to check all the basic functions, or we could just follow ofnuts' advice and use Python instead.

Now if you want to be truly evil:

Code: Select all

(define (+ p1 p2)
  (- p1 p2)
)

Which for the non-coders, re-defines addition as subtraction :shock:

Kevin

GnuTux · **Posted:** Sun Mar 15, 2015 4:24 pm **(#43)**

That's pretty dang evil, Kevin. :lol

It would be nice to have a script to check basic functions and yeah, yeah, Ofnuts' solution to all problems is to use Python. :roll:

Speaking of strange issues with Script-Fu, remember the odd behavior we saw here? With duplicate scripts, it appears there can be a situation where pieces of each script are used, the UI of one and the backend of another.

ofnuts · **Joined:** Oct 25, 2010 **Posts:** 4757

jontait2 wrote:

@Saul:
What I don't understand is how defines in one user script can affect the operation of other scripts - they're supposed to be independent, aren't they?

They are executed by the same script executor:

Attachment:

script-fu.png [ 4.57 KiB | Viewed 1341 times ]

By contrast, python scripts are run in new processes (less interaction, but more overhead).

jontait2 · **Joined:** Dec 27, 2014 **Posts:** 508

ofnuts wrote:

They are executed by the same script executor

Yes, I am aware of that, Ofnuts .. I have previously been right the way thru the source of the Script-Fu plugin to see how it worked but I was under the impression that user scripts only inherited the standard TinyScheme objects plus whatever is defined in the "special" files such as script-fu.init. Or, to put it in Pythonic terms, each script would have its own effective "namespace".
But, as Saul pointed out, all the scripts on a system are effectively coalesced into one top-level as though loaded from one great big file.
Now, if I didn't pick-up on that little dark secret even after going right thru the source, how the hell is the average user supposed to avoid conflicts between scripts on their system?
Methinks this could be done better.

GnuTux · **Posted:** Sun Mar 15, 2015 6:23 pm **(#46)**

jontait2 wrote:

ofnuts wrote:

Not sure this is a good way to obtain a direction. What happens for small angles (sin or cos <.5)?

This script can only produce extrusion at angles which are multiples of 45 degrees - at each step of the extrusion process it simply copies the existing layer to a new layer, translates it by {-1, 0 or +1} pixels in each of the x and y directions and then merges with the existing layer. The fact that the GUI allows you to enter intemediate angles is rather misleading - eg. if you enter 30 degrees it will just round down to 0; if you enter 31 degrees it will round up to 45.
So it may just as well be done with a look-up table anyway!

I chose this approach because of future plans to enhance the script to extrude at an arbitrary angle. I just haven't gotten around to updating it with the new modifications I have in mind.

ofnuts · **Joined:** Oct 25, 2010 **Posts:** 4757

GnuTux wrote:

Ofnuts' solution to all problems is to use Python. :roll:

Certainly not. I would never make such a blanket statement(*). But the subset of Gimp problems that can be solved with Script-fu can be usually be solved more efficiently with Python.

(*) especially since many problems that look like good script-fu/python-fu candidates are better solved with ImageMagick and a shell script.

saulgoode · **Posted:** Mon Mar 16, 2015 5:30 am **(#48)**

jontait2 wrote:

If only.. as far as I'm concerned this is more a case of taking the lid off a can of worms!
If it really is true that every user script on a system inherits all the global defines of every other script registered at Gimp start-up there could be any number of hideous clashes still waiting to be discovered.

There typically is no need for a script to define anything globally except for the procedures that are to be registered with the PDB. If your script is defining other things globally, then you are quite likely doing it wrong™.

If you have valid reasons for your script to define some things globally (and there are some situations where this is the case) then it is up to you to ensure that your definitions do not interfere with other global definitions. A simple way to do this is by using the script name as a prefix to the variable name (e.g. 'layerfx-round', 'grid-layout-round'). One could also place the definitions within a dedicated environment (i.e, a "module") but the end result is effectively the same.

Code: Select all

(define grid-layout (make-environment
  (define (round x) 
    <body>)
  (define (less a b)
    <body>)
  (define (scale img draw new_width new_height)
    <body>)
  ))

; these functions would now be invoked using
; 'grid-layout' as the environment/namespace.
; for ex:
(grid-layout::round -0.7)
(grid-layout::scale img layer 300 200)

jontait2 · **Joined:** Dec 27, 2014 **Posts:** 508

Yes, absolutely.
Personally, I haven't needed to use global definitions in any of the scripts I've written thus far, and if I did, then I would automatically (as a matter of good programming practice) use script-specific prefixes.
What worries me is the number of scripts out there which do use globals and which do not necessarily conform to such "sanitizing" practices.
Perhaps we need a sanity checker?

Issabella · **Posted:** Mon Mar 16, 2015 4:39 pm **(#50)**

Here my test about looking for the evil grid-layout.script

GnuTux · **Posted:** Mon Mar 16, 2015 4:47 pm **(#51)**

Issabella wrote:

Here my test about looking for the evil grid-layout.script

The Procedure Browser says it on your system. In the search box, look for: images-grid-layout.scm (leave off the script-fu- part).

If not found, maybe it got placed in the share folder you posted earlier, the one with the other default scripts?

Looks like this same script has been an issue on here before. Guess Marcello has it installed too.

viewtopic.php?f=8&t=11435&start=0

Issabella · **Posted:** Tue Mar 17, 2015 3:00 am **(#52)**

Hello everybody. At the end I think I've found my naughty hidden grid-layout and of course I have enjoyed removing it. :hehe

I found it when I opened program files until I opened scripts fold, and there it was. Before I opened by via user etc...
So please, could you confirm me if it is all right now?
Here my last test:

Odinbc · **Posted:** Tue Mar 17, 2015 8:25 am **(#53)**

Issabella, it look like your good to go. :bigthup

If you need to use IGLO (images-grid-layout.scm) in the future, here is an updated copy that works without error.
Subject: Need Help Testing A Simple Script

Issabella · **Posted:** Tue Mar 17, 2015 8:28 am **(#54)**

Thank you so much Odin. I don't really need it now, so I keep the link just in case in the future. It's something as I took dislike to this special script for the moment. :hehe

Issabella · **Posted:** Tue Mar 17, 2015 8:36 am **(#55)**

I did my Test Calc. I hope everything is all right now.

GnuTux · **Posted:** Tue Mar 17, 2015 12:09 pm **(#56)**

Looks good, Issabella. You're getting the correct results. :bigthup

You can go back to the official release of 3D Extrusion now and all should be well.
http://gimpscripts.com/2013/12/3d-extrusion/

Thanks to everyone who helped track down this issue.

Issabella · **Posted:** Tue Mar 17, 2015 12:42 pm **(#57)**

Thank you to you all for your help and your interest in this problem. I'm so proud of you, who have spent many hours to solve the problem.
I'm so happy that this script "3D extrusion" works perfectly now in my Gimp. :jumpclap

Odinbc · **Posted:** Tue Mar 17, 2015 3:02 pm **(#58)**

I received an reply email from Kamil Svoboda the author of IGLO - Images Grid LayOut. He's read this thread and will be fixing his script 'asap'.

Issabella · **Posted:** Tue Mar 17, 2015 3:09 pm **(#59)**

Thanks Odin, good news. :bigthup

	Similar Topics	Replies
	My Experiments On GMIC Testing filters: Simple Graphics (now 14)	1046
	Amazing what can be found under testing	30
	Testing Gmic-Qt Standalone 3.1	4
	questions about testing with DIEGO_Render_FillingPlus	13
	New layer modes in LayerFX-2.10 for testing.	9