Lars Fosdal

Like @David Heffernan suggests, we override the version numbers from our Continua CI build server, using the same version/build number across all apps within the separate branches, and updating them through FinalBuilder parameters. Current versions: Devel is 2019.3.12.11451 and Pilot just went from 2018.11.6.5035 to Live 2018.11.6.36 As you can see, the version is y.m.d.BuildNo where the day is the planned release date. Devel build numbers start at y.m.d.10001 and are periodically reset. Pilots at y.m.d.5001 -> 5xxx Live at y.m.d.xxx + 1 We are trying to limit ourselves to three major releases per year, and avoid introducing breaking SQL Schema changes between the major releases. We still have too many hotfixes. The previous Live version had build number 353. Note that doesn't mean we had that many actual roll-outs, just that many commits 😛

I got 32Gb RAM, and I rarely go above 18-20Gb - so I got a lot of RAM to spare for IDEs excessively wasting memory.

Well, I can't be 100% certain - but the problem began when I used it, and never happened again after I stopped using it - and I did that for two different periods, on two different computers.

I mostly search in specific trees, with a specific file extension, and with a text or regular expression, using TextPad 8. Fast enough with SSDs.

I used it for a while, but it caused my PC to die unexpectedly from time to time.

Works perfectly 🙂

It seems it no longer is possible to report errors via the Tokyo IDE?

I've abstracted my app configs, using a model similar to Windows Registry, that either store into a Json file, or into Registry. From the app side, it is read at load, and write through on changes to ensure that changes are not lost. I've used a key TStorageKey = (StoredForUser, StoredForAllUsers, StoredForApplication, StoredForSystem); that maps to different locations in registry or file system to determine the scope of the config.

Tokyo is pretty good, but if I switch between a lot of projects to build - I still eventually run out of memory. I wouldn't mind a 64-bit IDE down the road.

XE7 was bad.

Usually, it seems to be related to something not compiling, and not necessarily in the unit that you are in.

If you use FireDAC, you can also use the FireDAC Monitor to capture everything that goes on, databasewise. http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Tracing_and_Monitoring_(FireDAC)

I have no experience with the MacOS shell, but a bit of googling dug up this? Not sure if appropriate. https://stackoverflow.com/questions/43020737/delphi-capture-osx-console-output

@Juan C.Cilleruelo - Do you invoke a new instance of OpenSCAD for each image? If you do, can't you execute it from a thread that waits for it to complete and return?

You are right, unless he is in control of the external program as well.

I have a DebugOut call that I mostly leave in the code as needed. By default it writes to OutputDebugString, but it also writes to a 4K line buffer internally, and I have patched the system menu to add a "Log to file" option. If the user enables logging to file, it first dumps the 4K line buffer then appends anything else being logged after that. For server apps, there is a midnight rollover routine that creates a new logfile, and deletes logfiles older than <configurable> days. As for adding / removing logging - I can ifdef or comment things in and out by hand, but mostly I just leave it in there, if it is not pure development test code, that is. More logging > less logging - when you actually need to figure out what happens.

I assume you are in control of the output location. f.x. %somepath%\generated\myimg.png What if you create a "signal" file that basically is the URL of your graphics output file with f.x. '.processing' at the end before you start generating the file? %somepath%\generated\myimg.png.processing Once the processing is complete, you delete the %somepath%\generated\myimg.png.processing That way, your other process could check if the file %somepath%\generated\myimg.png exists, but continue to wait if there is a %somepath%\generated\myimg.png.processing file there?

I think it looks good. It adds clarity and reduces clutter. I am slightly unsure of the [+] to > change for expansion in tree views, but we'll see.

Adding a few words about yourself is always useful.

The site header (blue, with Delphi-PRAXiS title) takes a little too much vertical space for my preferences.

Currency can hold Decimal(50,4) if I remember correctly. Extended could have worked, but strangely it's not available on 64-bit.

I agree. The post/comments could be condensed.

If you use Chrome on your family computer, you can have multiple user profiles and switch them there?

@NIRAV KAKU - have you tried the site on a mobile browser?

I welcomed ARC in principle, but there were three key problems for me:1. Having two different memory management models in our code base was not an option2. ARC carried an unexpectedly high performance penalty 3. The pitfalls of ARC were as many and as complex as for the classic reference count problems.