Sincere Thanks for Not Wasting Resources on the GDL Environment

[James Murray]

I do a fair bit of GDL work, and I have been personally frustrated over the last few versions of Archicad that the GDL environment has become much more crashy, and of course there is no autosave, which inevitably results in lost work, often hard work, because GDL is a miserable language in the first place.

When I have complained about this in the past, I am duly patted on the head and reminded that GDL users are an absolutely insignificant minority of AC users, and there is simply no chance of any development or QA resources being spent in this area.

It has taken me a while, I’m embarrassed to admit, but I have belatedly gained wisdom about this situation. Now whenever the GDL environment crashes, I rejoice that no resources have been spent on it, and with the resulting ample attention available, the rest of Archicad should be perfect real real soon.

[DGSketcher]

If I didn't know better I might assume this was written with a hint of sarcasm 🤔

[SenecaDesignLLC]

if its not sarcasm i completely disagree.. 

the only time something crashes is when i code an unending loop unintentionally lol

otherwise how can you really complain about basic math lol

[godi]

I actually have no complains nor problems with GDL, but have exactly that same opinión about how GS made lists system die, no schem solution can have EVER the level of detail I had with bills of materials generated with list

[Hmooslechner]

On Mac since some Versions, its very well known, that the action "mouse-draw of code-passages" causes the gdl-editor to display false code. If you do so, you have to save your work with knowing of the false code, because you cant see it. Then, after re-opening, You can see the wrong passages of the code and correct it.  So - on Mac, the only way of changing code-Place is "keyboard-copy-paste". With the Mouse, You get in trouble.  

As i said - this Bug is very well known by Graphisoft since some Versions and was never corrected.

[godi]

Yes, that is true, but at least GDL, with glitches, is still working

[leceta]

At least it would be super handy to know how the heck, using what workflow, what debugging tools, what macros managing system is Graphisoft's in-house GDL library developer team making his daily work. This would be super handy, to say the least. As it is a know-how of one (quite an important part) of a comercial tool we are paying for, it makes sense to have a good reference to look into. Does it exist? I ignore...

[DGSketcher]

That's a very good question. It's hard to believe that the library developers are using the native AC GDL scripting interface after all these years? It should have a much more efficient interface by now if they are using it.

[leceta]

I have recently started using VScode for my GDL development process, editing them in xml format paired with a batch script for automating the xml to gsm conversion, and I must say I feeling quite comfortable with the new workflow.

"testing" the GDL codes takes some extra steps, save xml,convert to gsm, update Archicad library, but it is less than 10 seconds. In Archicad 25 now its also possible to automate the library updating process with python (i'm not currently working in a AC 25 project though but i'll implement that on future projects, for sure)

[DGSketcher]

I guess it depends on your programming skill set, but I quite like the immediacy of scripting / check / save / view results in AC without resorting to an external interface or knowing the dark arts of Python to import the VScode results into AC. GDL is an easy language to learn for both simple and complex objects and needs to be made readily accessible to ALL users. Param-O will never come close to what can be achieved with conditional coding.

[leceta]

sure, I'm talking from the resignation of someone who believes that an IDE enhancement will never happen. We are definitely not the first who demands such a thing...

[leceta]

for your interest, I have created a wish for a webinar (?) on this topic

https://community.graphisoft.com/t5/Wishes-forum/a-Webinar-on-how-Archicad-develops-in-house-their-G...

[Peter Baksa]

Hi,

We rely heavily on LP_XMLConverter to convert HSF source format to and from GSM and LCF. Here are the tutorials we have in this theme:

http://gdl.graphisoft.com/tips-and-tricks/how-to-use-the-lp_xmlconverter-tool

http://gdl.graphisoft.com/tips-and-tricks/hsf-source-format

http://gdl.graphisoft.com/tips-and-tricks/how-to-replace-parameter-values-in-xml-format

Source code is stored in a version control system, and a diff tool is used to do code review of changes. These can be useful even for single-person development, check out if you haven't heard.

Build, localization and release is done with custom python scripts working from the source code. We have plans to publish a toolset, but I can't promise dates (expect more than a year). A small team could easily work with shell command files.

The GDL editor is inevitable when we are developing new model or doing small changes. Bigger changes involving many elements and many parameters are easier to do in HSF. We recommend using VSCode with the GDL extension as code editor.

With debugging we are very basic, the most straightforward way is using print for logging variables, sphere / circle to mark geometry, and commenting out suspicious code to quickly find which macro / command is faulty.