Lars Fosdal

If you are a corporate developer, the money for tools are peanuts compare to other costs.

Can we stay on the topic, please? Are there any practical languages that are applicable to writing the same variety of solutions as Delphi, that are actually memory safe? Even if you manage your memory in Delphi, it is not hard to get corrupted data due to a dangling or misdirected pointer, even in Delphi.

Sometimes, when entering new areas of knowledge, you might not even know what to expect. Hence, a guiding hand can go a long way. Most people appreciate those that offer help without conditions.

IMO, that was not very helpful. If you are a new user, you may need to be guided on how to do it right, not just be told that you are doing it wrong.

Irrelevant content removed.

There also is https://docwiki.embarcadero.com/Libraries/Sydney/en/System.TypInfo.GetEnumProp which returns a PPropInfo, which again contains a PropType: PPTypeInfo, which you then can use with GetEnumValue?

What if you treat every value as a generic type? That way you are free to use TypeInfo? procedure TParam<T>.SetAsString(const aValue: string); var TV: TValue; begin TV := TValue.From<T>(Default(T)); try case TV.Kind of tkEnumeration: TV := TValue.FromOrdinal(TypeInfo(T), GetEnumValue(TypeInfo(T), aValue)); tkInteger: TV := TValue.From<Integer>(StrToInt(aValue)); tkInt64: TV := TValue.From<Int64>(StrToInt(aValue)); tkFloat: TV := TValue.From<Extended>(StrToFloat(aValue)); else TV := TValue.From<String>(aValue); end; FValue := TV.AsType<T>; except on E:Exception do begin CmdDebugOut(Parent.Debug + ': "' + aValue + '" -> ' + E.Message); FValue := Default(T); end; end; end; function TParam<T>.GetAsString: string; var TV: TValue; begin TV := TValue.From<T>(FValue); Result := TV.AsString; end;

@msohn - I don't usually spend much time in the text format .dfm.

I should simply stop posting without actually checking shit... object Label1: TLabel Left = 303 Top = 233 Width = 99 Height = 15 Caption = 'Text'#32'Text' end does however, work correctly. Edit But if you actually edited the dfm text and put in that #32, then view as form, and back to view as text - it has been converted to 'Text Text'. As @Lajos Juhászpoints out - Unicode text that is entered in the form attribute editor, will translate to #1234 values.

You can't really declare strings in .dfms as 'Text'#32'Text', can you? If you set a caption or label in a dfm from such a string in code, yes you'd be affected.

The problem even shows up in the IDE. and the cure is the same as for compiled code

What kind of license is it published under?

Ref := ItemProvider.Grab(ItemId); // or Ref := ItemProvider.GrabForChange(ItemId); try // do stuff finally ItemProvider.Drop(Ref); end; ItemProvider can do the allocation and loading, as well as the disposal. If there is parallell use, it can secure against readers/other writers, have a keep-alive in cache period, etc. In theory, with the "smart pointer" trick, you could even do away with the try/finally.

That is not what I intended to say. I was wondering if someone had tried to apply LLM for finding even better patterns for optimization than those that are currently implemented. Naturally, such improved patterns would be made into new deterministic rules in the compiler after being properly vetted. I agree that todays AI output has to be treated as indicative at best, and as bullshit at worst.

Request/Release Which is to be expected, I guess, since the training was not done with optimization in mind.

None of the techniques described in that paper appear to be related to the LLM generation of AIs.

Hasn't this already been demonstrated with "smart pointers"?

I wonder if anyone has tried to train an LLM on Assembly code generation to see if it could improve the current optimization patterns?

You are probably right, only some operators might be new/different (ARM f.x.). Book: https://www.amazon.com/Hackers-Delight-2nd-Henry-Warren/dp/0321842685

I am afraid so, even if it probably is somewhat outdated by now, in the light of new CPUs.

Dang, watching this led me to buy yet another book 🤖

Yeah, they are not exactly known for responsiveness.

Reported the documentation error at https://embt.atlassian.net/servicedesk/customer/portal/1/group/1/create/12 You can find it here https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-544

Contact EMBT support.

No code is in reality indeed a non-existing concept, however IBM App Connector Enterprise is a pretty impressive No/Low code tool, but it costs an arm and a leg. We've moved hundreds of integrations to IBM ACE and APIC. It scales well, security is not an afterthought, it supports a ton of protocols, integration mechanisms or data formats, and has proper CI/CD support. And... the GUI sucks, and the primary "lowcode" language is ESQL - which is IBM proprietary 😛 Price aside, still a better alternative than unproven No/Low code plugins for Delphi. Personally, I'd prefer to do integrations in .NET/C#. An abundance of tooling and libs, and runs on multiple platforms.