omnibrain

On the other hand, I'm currently building something with Supabase as part of the backend (that's just postgreSQL with some fluff, like Auth around it), Frontend with vue.js and Quasar Framework, and it's almost RAD. Only deployment will be more complex. But with modern webservers like Caddy deploying a webserver with working TLS is no problem at all anymore. Funnily, while Caddy is Open Source it is sponsored by ZeroSSL, which in the end belongs to Idera nowadays.

The trouble with web is less about the development of the user interfaces (web apps), but more that most developers that did desktop application development their whole life are still stuck in desktop developer paradigmns. They are stuck not only in the UI paradigmns, but also have often no clue how authentication works, how to build software for zero trust environments, how to deploy the whole stack, etc, how to work with the latency. For those it would need a new generation of RAD tools. An IDE that lets them build client and server, auth and everything is handled by the framework and when they press "build" they get a docker container ready for deployment.

I wish them the best of luck. I hope the product is not of vital interest to the company. They were somewhat between a rock and a hard place, having a legacy Delphi application with a sub par engineering team. But rewrites (in a completely new technology) rarely go well. (At least in time and in budget). Does your company already work with react or are they going to build a completely new engineering team, or even outsource the development?

I would go with Supabase. In the end it's "just" postgreSQL, but they sprinkled tons of sugar on top of it.

Being overworked is not the only reason for burnout. It can also happen due to the opposite (boreout) or just working in a bad environment. Be careful.

Honestly, it would be best if you started looking for a new job. You coworkers don't care. Your boss doesn't care. It works for them (for now), but it will crush you.

Thanks for the clarification. I misunderstood what you want to do with the new server component then. I currently use THttpAppSrv and I'm curious what your future developments are going to offer.

I would really like to continue to be able to use webservers without SSL/TLS for several reasons: In a more complex setup ssl gets offloaded from the application servers to load balancers, reverse proxies or web application gateways modern reverse proxies like caddy are ridiculously easy to use and just work with ACME certificates (or self signed) with almost zero config, it's not even funny it's usually easier to update a reverse proxy/load balancer or WAG for new openSSL versions than the applications itself webservers embedded into the application, bound only to localhost, don't need ssl/tls (for internal APIs) it's easier during development if you don't have to wrangle self signed certs and browser errors But I don't care if the ssl/tls code get's compiled into the program or not. I just want to be able to use a server without SSL/TLS.

Ah, did not know that. Is there a way to convert our 100+ existing DFMs?

Are there any (known) changes to the compiler regarding string handling from Delphi 10.2 (or 11.0)to 11.2? I don't have code, because I can't reproduce it yet, it's more of a feeling, that something is wrong. We do a lot of serial communication. Parts of the code are rather old, but survived man Delphi version changes. Some of the code may be pre-Unicode but got modernized before my time and thus before source control, so I can't check the history. We read the ansichars that come via the serial connection and put them into chars and them into strings and work from there. I think that's not ideal because strings are unicode (nowadays) but so far it worked fine. Recently we switched from Delphi 10.2 to 11.2 (with a short stint in 11.0, but I'm only 80% sure the error wasn't there). And now it only works like 99.9% of the time. (With our test systems everything works, but our customers have more "traffic). The error is, that we get symbols we can't explain in positions where they don't belong. It looks like chars get converted to other hex values. At the moment I'm just poking around, because the error is rare enough and we don't have a trace yet. But perhaps someone knows of a possible change to string/char handling with the most recent compiler versions.

Sure, but coming from Java and .Net it's just a basic language feature missing. Maybe it's easier to implement if everything runs in a VM...

As suspected unsave byte/char handling. We converted the offending parts to TByte now. But it was also a problem because the code expected a byte converting to an integer value, but the message could have had legit anything else at this point. The trigger was an unusual message. Once we had a trace we could recreate it with our test hardware and it was obvious. The exception was many calls deep into the processing code and got only caught on the top of the call stack so we would have probably taken a few more days to really find this part. Perhaps we should add something like MadExcept. It's a shame that Delphi offers no inbuilt StackTrace at runtime.

Good news everybody, we got a trace and it looks like we can provoke this issue with our test hardware.

They should keep their "value". It could for example be the "length field" and $A9 for the 3rd byte/char received would mean that we have to work with the next 169 characters, the 171st char/byte received would then be a checksum over all bytes/chars received, which could be $F3 for example. It could very well be that it has been broken forever, but we processed millions of "messages" per month and never had this problem. But like I said, I can't totally rule out, that we just never received such a message before. It could be just a single character causing this trouble by getting converted and only in few positions it would cause (visible) trouble. Today we traced all the "messages" at a customer, but of course it did not happen. Tomorrow I'm going to add additional logging code, so we pinpoint closer where the exception happens and then we should know what the "wrong data" is.

The value can be basically anything from $01 to $ff. It's serial communication with various protocols. Some text based, some byte based and some of them a mix of both. Some of them are delimited by EOT ($04), for some we need to calculate the lengths, for some we need to calculate CRCs, etc. Not all in the same process, but the pattern ist the same for all of them and the tfr_com.dataavail ist the same. The serial communications components provides ansichars. And we don't expect to receive multi byte characters via serial communications anyway. We communicate with old hardware, with old protocols. Most of the time there is no encoding specified, but for the text parts (if there are some) most of the times just plain ascii characters are used.

I tried to condense the code: procedure tfr_com.dataavail(sender:TObject; Count:integer); var i : word; c : char; // serielles zeichen empfangen ac : ansichar; s : string; begin for i:=1 to count do if com.ReadChar(ac) then begin c:=char(ac); {$R-} showinchar(c); if assigned(receivecharproc) then receivecharproc(c); {$R+} end; end; //receivecharproc is procedure tfi_m.receivechar(ach:char); begin //state machine that works with the chars to parse the various protocols and adds them to a string typed variable for further processing end; ReadChar provides us ansichars, so I guess it's easiest just to stay with ansichars for further processing. But why did it work for 10 years and suddenly stopped? I can't rule out, that we see a new type of input we haven't seen before. But I still have no trace of what we actually receive...

Are you going to put it on github?

Yeah, me neither. That's why I ask in general terms. Like if someone asked if anything with pointers and DLLs has changed in the latest release. Then we would answer "of course, ASLR and HE-ASLR is enabled by default. Look into the linker options." I hope for something like that. I suspect the code has been broken since the unicode migration and now some (undefined?) behaviour in edge cases may have changed. I'm afraid I won't be able to avoid reworking it, into proper datatypes for stuff received via serial connection. (A proper mix between raw byte protocols, text protocols and protocols that mix both). The discussion in Best type for data buffer: TBytes, RawByteString, String, AnsiString, ... - Algorithms, Data Structures and Class Design - Delphi-PRAXiS [en] (delphipraxis.net) goes into a similar direction, thoguh starting at another angle.

"transliteration" is a good word. My gut feeling is, that we receive some byte value that translates to a char, that get's "transliteraded" to a unicode glyph and when we try to work with the byte value again we get the value of the unicode glyph. Yes, I'm currently thinking about converting everything to ansichars and ansistrings, or even rawbytestrings, or possible TBytes (though we depend heavily on pos() for protocol parsing). But it may very well be, that I'm chasing ghosts. So if someone could chime up and say "yes, something really changed", that would give me confidence. ?

Can you show a bit more code? How do you setup the stream? Perhaps you need to (re)set the position of the stream to 0 before sending.

With Delphi 11.2 every so often when opening a project, or opening another unit when having a project open my IDE hangs. It's always a different code file, but the symptoms are always the same. "CodeInsight: Loading project [...]" stops moving and the IDE just sits there, consuming 0% CPU and a varying amount of RAM. Only thing I can do is to kill Delphi via the Task Manager. Our projects can be quite large, with lots of units. I also use MMC, GExperts and DDevTools in their latest incarnations. Are there any likely cuprits? Anything I could do?

Thanks, but it looks like that the classic version is gone from 11.2.

bds.exe is just idly communicating back and forth with the DB server, the DB components use at design time. DelphiLsp.exe (all 3 processes) does nothing. Even if I kill those processes Delphi stays stuck. 😞

I ran into a problem, that the debugger (in 11.2) does not seem to understand if you use the same name in tow places within one function. case geocoder of gc_pos: begin //... var lat:=posdata.data[0].latitude; var long:=posdata.data[0].longitude; //... end; gc_nom: begin //.. var lat:=position.lat; var long:=position.lon; //.. end; //... end; When debugging into the gc_nom case the debugger showed me uninitialised values ever after the assignement.

I threw together a simple file serving THttpServer to host some local data (mainly static JSON to emulate some APIs). But now I need to add a "Access-Control-Allow-Origin: *" header. Where would I do this. My server code is literally not more than: HttpServer1.DocDir:='C:\temp; HttpServer1.Port:='16010'; HttpServer1.Addr:='127.0.0.1'; HttpServer1.Start(); I tried to add an "OnBeforeAnswer"-Handler, but I'm totally lost. procedure Tffileserver.HttpServer1BeforeAnswer(Sender, Client: TObject); begin var lclient:=THttpConnection(client); lclient.SendHeader('Access-Control-Allow-Origin: *'); end;