AlekXL

You should never underestimate people's foolishness, Markus. Smart people are always a minority.

perhaps, our time or money investment to FPC/Lazarus could change EMBT behavior. Skip subscription fee once, and invest it to the better cause. Let EMBT know, that you did so..

I would politely disagree.

actually, the only way to fix it is to have compiler opensourced and local skilled software engineer hired -- to investigate such issue. He could resolve issue, and then report it! So vote the issue

That's it! It's the debugger that makes all the difference. Merlin pants, I'm working on Lazarus project right now, and multi-threaded to boot. Do you know that there is no way to switch thread while debugging? No even in trunk Lazarus? Neither on Win, nor Linux? This is show stopper! -- @Nasreddine Lazarus may look ugly, but it's the only real way to improve things for pascal now. We need to concentrate our efforts on Lazarus. Additionally you can actually write IDE-agnosttic pascal language server -- debugger, code-insight, etc -- and sell it, after creating bindings for Lazarus, VS-code, IDEA, etc..

I am wondering, in that possible to use FullDebugMode features of FMM4, in Lazarus/FPC? At least on Windows?

And are you asking to help for free, or you paying? If the latter, then well, I could give you some..

@Nasreddine It's not that's difficult to create decent editor. Intellisense/Code Insight -- that's more tricky, but still doable. There are lots of examples of this. Creating yet another source editor is boring, low hanging fruit But here the catch, the real, cruel truth: it's the debugger - the thing that makes all the difference.. Do you know many debuggers? Decent ones? Especially for languages which compile to real executable? Even Delphi IDE native debuggers are horrible on non-windows platforms. If you really want to contribute, you should probably give your effort to tweak existing debugger engines, like LLDB, GDB, Titan for usage with generated-from-Pascal executable -- and especially on android.

Mess how? Don't like it? Don't use it! Terrible mess is what's going to happen with mobile arc-enabled code, when current ARC disappears. People who invested their time in mobile development is being dumped. We got PR article instead of solution. Marco announced, that EMBT decided to break nextgen code-base. Instead to addressing the problem, he just did PR-thing, damage control, giving excuses about why this was necessary. And what about Desktop? Other languages are blooming with innovations, and Delphi is stagnating, we still forced to use only one memory model for object instances! ARC is great thing, especially when it's non-compulsory. I believe, there are 3 memory management models, and each of them has 2 cool features out 3: simplicity, productivity, and performance Classic model offers simplicity and performance. Productivity -- not so much -- more code to write, more mistakes to make. GC sports both simplicity and productivity. But not performance. ARC offers productivity and performance. But lets not be fooled, ARC is not simple. Why Delphi can't have two of them? Even now there is a way to make some tricks about mixing non-ARC and ARC instances. This code actually supported by classic compiler [result:unsafe] function Fast():IInterface; begin result :=TInterfacedObject.Create(); end; procedure DoIt(); var [unsafe] intf:IInterface; begin intf:= Fast(); end; I don't want GC in Delphi, actually -- I'd go to C# for that. But ARC is nice. And I'd prefer to not being forced to extract interface for each and every object I want ARCed. And, by closing the feature request with "Won't FIX" resolution he thought , it would never be a time, nor reason, right? Otherwise, he'd say: OK, let this stay open, and maybe we need it at some time.

Then why he closed the issue with "Won't Fix" resolution? Some issue don't get fixed or implemented, but Marco says: "We should consider all options", and keep them opened didn't he? But in this specific issue his resolution was "Won't Fix"

there are a lot things, in which C++ sucks: 1. lack of try ..finally 2. lack of properties sematics 3. lack of proper RTTI and attributes 4. lack of proper unified exception model for both software and hardware exceptions But actually due to outstanding support of operator overloading, C++ allows ARC-enabled objects to exist and even to mix them with simple memory mode Delphi wouldn't have such luxury -- because shared_ptr magic is, if I am not wrong, based on -> operator overloaded. Well, Delphi doesn't have it, just as it doesn't have smart enough compiler. Delphi implementation of shared_ptr patter would be ugly, and ineffective -- mark my words. Neither it will help to address broken compatibility for nextgen code. My approach would. Truth is -- return to classic memory is right step, but it is step backwards, nonetheless Mixed On-Demand ARC approach would give Delphi an edge, unlike poorly implemented non-extendable mrecords. The said model would allow user to choose, whether and when to use ARC, and use those models side-by-side easily Even mixing those object would not be difficult: not simple, but still relatively easy. Because ease is about productivity, and simplicity about understanding

Faster how? You win maybe 1-2 seconds, on rarely needed task, but bloat the toolbar for good. Add one I tool-button to show specific dedicated popup to filter based on visibilty. Another one, with specific dedicated popup for entity filter : All, types, routines, g_variables, storage members Place entity search edit box, to right. Done. By default there should be no other controls on Structure view toolbar. And don't forget to de-bloat the popup on entities. Popup menus are also called Context menus -- this is all about context, if some action is not applicable to the entity selected, Popup menu should not show it. Ask them then! We need community wisdom, dont we? You can try. I opine that MMX windows should be separated to two or more dockable windows. If one need those allegedly useful other features, let him dock those windows together.

Missed me already, did you? And where's the fun in this?

And it just don't work. Guess I am doing this all wrong.. But it doesn't matter, this tool is not that important or powerful to spend my time learning it. I want it work with zero-assumption. Look at Gexperts procedure list, or CnWizards couterpart -- they just work. Only problem they show routines only. 1. Look at the picture. Window 1 and 2 should be merged. Bloat-ware -- anything aside syntax entities -- removed! 2. Text edit number 3 -- don't know what it does, it doesnt even show a tooptip about -- and don't care. Send him to Mordred, too. There is no place for multi line editor in docked, space-limited environment 3. "Member search bar" should be "Entity search bar" -- filtering out both types and members, containing the typeword 4. Window 5 /toolbar just wouldn't die, would it? I right-click, choose Hide, and guess what? Send it to already known address. 5. Get rid if smart-ass chevron logic --completely -- they are confusing and counter-intuitive. 5. Look at the IDE native structure window -- I want MMX to take no more space, than this

Understood. Well, I'd love to see more reasonable interface though. Not new icons, mind you. But rather MMX-implemented Structure View -- it lacks "Incremental Filter", and therefore barely usable. I opine :simply by adding such (dockable) window , would make all the difference. Currently MMX Windows is bloated, counter-intuitive and too complex to grasp.. Icons too -- I have no time memorize their meaning. I'd rather use simple popup menu with "check-items"