topic Re: Sincere Thanks for Not Wasting Resources on the GDL Environment in GDL

Sincere Thanks for Not Wasting Resources on the GDL Environment

James Murray — Mon, 13 Dec 2021 17:34:42 GMT

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.

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

DGSketcher — Mon, 13 Dec 2021 22:31:19 GMT

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

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

SenecaDesignLLC — Mon, 13 Dec 2021 23:40:42 GMT

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

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

godi — Tue, 14 Dec 2021 14:04:21 GMT

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

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

Hmooslechner — Mon, 20 Dec 2021 06:09:56 GMT

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.

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

godi — Mon, 20 Dec 2021 11:28:48 GMT

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

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

leceta — Thu, 13 Jan 2022 14:12:22 GMT

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...

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

DGSketcher — Thu, 13 Jan 2022 09:01:25 GMT

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.

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

leceta — Thu, 13 Jan 2022 11:18:16 GMT

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-GDL-objects/m-p/327063#M19314

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

leceta — Thu, 13 Jan 2022 11:26:54 GMT

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)

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

DGSketcher — Thu, 13 Jan 2022 12:32:43 GMT

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.

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

leceta — Thu, 13 Jan 2022 14:17:17 GMT

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...

Re: Sincere Thanks for Not Wasting Resources on the GDL Environment

Peter Baksa — Tue, 25 Jan 2022 16:24:35 GMT

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.