Libraries & objects
About Archicad and BIMcloud libraries, their management and migration, objects and other library parts, etc.

Error message in 3D (GDL Code Robustness)

Anonymous
Not applicable
When working in 3D or when working on an elevation when the walls are turned on, I sometimes get the following message...

"polygon is degenerated at line 278 in the 3D script of file wa_frame_us_10.gsm"

I have had this happen before when a door height gets accidentally set to zero or something similar to that. In this particular case, I cannot find what is causing the problem. Is there a way to find out what is causing this?
17 REPLIES 17
Thomas Holm
Booster
Leo wrote:
Karl wrote:
...The root of the problem is the GDL language itself. It lucks normal structure-oriented instructions, protection and checking of variables, debugging commands. It looks like a dinosaur from 1980th. ...
Well, perhaps it is a dinosaur from the 1980s.

But that doesn't seem to stop skilful programmers to do amazing things with it. I encourage you to check out Ralph Wessel's work with the Modular Joinery object that I've described before. Complex and flexible, yet simple, logical and structured, and a GUI that serves as an example for others, and all (as I think Ralph said) pure GDL. Free for Archicad subscribers. Get it through your reseller!
AC4.1-AC26SWE; MacOS13.5.1; MP5,1+MBP16,1
Karl Ottenstein
Moderator
Leo wrote:
The root of the problem is the GDL language itself. It lucks normal structure-oriented instructions, protection and checking of variables, debugging commands. It looks like a dinosaur from 1980th.
I 'know' you well enough from your posts here, Leo, to know that you know that this is not the problem.

Yes, GDL is a dinosaur from the 1980's, but it is a step above assembly language (!) and has all of the statements required to do proper error-checking to create robust code... there is range and value enforcement in the Parameters script itself, and one needs no more than if-etc within the normal scripts. Yes, higher-level languages would make it easier, but it really is not hard with GDL.

Many of the library part failures are due to divide-by-zero and other rather basic problems. Again, RANGE and VALUES make that pretty easy - and elsewhere, how hard it is for the programmer to insert IF PARAM>0 THEN etc?

The hard part about complex GDL parts that call deep macros (windows and doors, typically) IMHO is this: Yes, you can prevent a zero (e.g.) from reaching the parameter of a deeply called macro - which may then completely prevent the generation of part of an object - but if that zero was computed, and not directly from a user parameter, there is no easy mechanism to link the erroneous value back to the source parameters in a friendly way that can be cleanly communicated to the user. To me, that is an issue greater than GDL itself, but gets into the core UI.

Cheers,
Karl
One of the forum moderators
AC 27 USA and earlier   •   macOS Ventura 13.6.6, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Anonymous
Not applicable
Karl wrote:
I 'know' you well enough from your posts here, Leo, to know that you know that this is not the problem.
Thank you, Karl, for the compliment. I realy know that some individuals try writing robust GDL code and can be a rather success in this way. Thank you, Thomas, for your nice example. I'll try to check it out, as you suggested. But, as saying goes, the exception proves the rule.

I have a lot to say on the theme, but I'll try to limit myself for avoid flooding. I am going to make just several remarks.

Unfortunately or fortunately, professional commercial development can't rely on individuals. A company hires one/one gives up/one is ill; a department has got a good budget/ a company cuts our budget; managers try to reach timeline by enlarging a developer group. It's life. Programmers and architects, there are no differences.

Karl, you've compared GDL and assembler . Sorry for my irony, it's a good choice, isn't it? But have you ever seen new version of a serious assembly-written system coming every year? What about a lot of robust variation in its code (market specific, for example) ? Did you remember what documentation for that systems looked like? Was it like a "talking-around" speach (with a background idea - try to investigate any additional details by yourself)?

Are you sure most errors come from bad parameters? May be from mistyping of names of variables too? Or from copying GOTO statements without changing lables? Or from wrong assumptions about a global parameter meaning or behaviour in various contexts? Or from using a lot of global variables in rather a large piece of code? In most of these cases an object crashes with an error like "Division by zero", especially in geometry-processing code.

GDL is a language for processing geometry entities. We code objects with a lot of parameters. Usually, a GDL program creates rather a lot of parameter-rich geometric primitives, which correspond with each other. So, regular GDL object has lots of variables and branching. What does GDL offer us to deal with this complexity? Nothing. Absolutely nothing.
But GUI programming brings object-oriented concept into our usual practice mainly up to these reasons!

From my point of view, there are the main weaknesses of GDL, which affect reliability of GDL objects:
1. Lack of strict variable declaration rule.
2. Lack of normal subroutines with local variables. We can use CALL statements, but do you seriosly isolate every subroutine in an individual object? How do you review the whole code of your object? I guess, this approach is possible, but doubt about its usefulness.
3. No internal error-state handling features. They haven't implement even usual Basic instruction ON ERROR GOTO, so we can't isolate and handle error conditions. But, besides this, they must have implemented some regular way for informative and logic handling of error-like situations.
4. What have we got for debugging? We can't use "PRINT" in PARAMETERS Script, so what can they offer? Nothing. They have a report window, but we can't write to the window! I keep silence about tracing.
5. What about informative error-related messages? As Steve reported above, he got an error message without any library object identification!

These all are about robustness, from my point of view. Once again, some of us can write rather robust GDL objects, but we are talking about a commercial product. It's a result of a lot of modifications and each particular modification is done by a human. Who has an essential quality - he is making mistakes. Sometimes, even you and I make mistakes, as we are humans too . But GDL developers know nothing about this. Possibly, they haven't read any classical programming books.

Sorry for a so long message, but I really need to blow off steam.

Cheers,
Leo.
Anonymous
Not applicable
Karl,

As an old GDL programmer starting from the '80s I have to agree with Leo here. GDL is better than a poke in the eye with a sharp stick (and still better in many ways than what I've seen from Revit so far), but just because it is possible in principle to produce fully error checked and robust code doesn't mean it is easy, realistic, nor in some cases even possible in practice (sometimes the complexity of the task overwhelms the coding environment - or at least the coder).

I have gone on about this at some length in so many places that I won't belabor the point here, but I feel very strongly that AC desperately needs a major update in the GDL area in particular and CCC (custom content creation) in general. (I have been arguing this since I first met Tamas almost twenty years ago.)
Karl Ottenstein
Moderator
Of course I agree with you on many of your points! I've been programming since 1969 - 40 years now - and was a bit of an expert on programming language design and implementation at one point in my career, as well as software engineering practices and more.

Of course, many aspects of modern languages help prevent bugs. But none fully prevent them. This could easily turn into a debate over classes of languages such as Modula/Oberon vs C/C++, sort of the modern equivalent of the Assembler vs Fortran debates of the 1950's through 1970's.

Software Engineering is more than a strongly typed language with useful scoping rules. It is a manner of creating maintainable code in a team process that survives the loss of an employee (mentioned by Leo), is amenable to change, and much more. No, I don't like GDL, and yes, by its nature, it makes it too easy to accidentally introduce bugs. But, discipline in coding, variable naming, inline documentation and more along with proper testing and code walkthrough procedures can work there as well as elsewhere.

But, to the specific issue: Most of the problems I have seen in Graphisoft's own library parts over many years have been related to parameters whose values were not kept constrained to the allowable value range. Maybe once in a while an undeclared variable (created by a typo) whose value is of course interpreted as zero by GDL...and that variable is only referenced within a conditional block based on particular parameter values, making full testing coverage difficult. So certainly merely requiring all variables to be declared would be a huge help! Any other 'modern' language features would of course help more. But, the lack of those features is to me no excuse for library code that blows up...or if it does blow, does not get fixed by Graphisoft within a short time frame.

Cheers!
Karl
One of the forum moderators
AC 27 USA and earlier   •   macOS Ventura 13.6.6, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Anonymous
Not applicable
I think we are all in substantial agreement on this.

It is a poor workman who blames his tools. but even the best carpenter will complain when asked to use a wobbly miter saw.

I don't make excuses for my own bugs. I just fix them. But I do wish that it weren't so damnably hard to juggle all the bits and pieces. I often just don't have time to do it right and end up with some inelegant hard coded parameter limits or such. There have also been plenty of times when what my client wanted turned out to be impossible due to GDL limitations that are contrary to simple and reasonable expectations.
Anonymous
Not applicable
Matthew wrote:
I think we are all in substantial agreement on this.
Yes. Absolutely.

I think, a programming language and quality of code influence even a good programmer. So, I wish Graphisoft to get resources and "stamina" for moving ArchiCAD on a solid, good-coded, and well thought-out base.
Karl Ottenstein
Moderator
Matthew wrote:
It is a poor workman who blames his tools. but even the best carpenter will complain when asked to use a wobbly miter saw.
A perfect summary!

Cheers,
Karl
One of the forum moderators
AC 27 USA and earlier   •   macOS Ventura 13.6.6, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB