Actually, the rules when you need to lock are simple and most of the time you can eliminate locking from code.
I don’t use debugger at all, I just dump stack and memory contents.
In some languages that might be true
Others, like Xojo, where we dont control the runtime they are likely more complicated
I might need to use a mutex to protect an object (but I dont know for sure since I dont control the runtime) so …
They’ll need to provide some guidance for sure
A debugger would be useful since the translation from Xojo source code to intermediate(s) to machine code makes it VERY difficult to actually just read the stack & memory dumps
Not knowing what machine code gets emitted for my Xojo code makes that less than useful
1 Like
You can always pass a copy, so no mutex is needed or pass a worker thread results for main thread to do the actual update.
wake me up, when it’s finished and working…
2 Likes
You know that you will sleep until eternity possibly…? Especially if you wait for production ready variant? Only a suggestion…
2 Likes
Enjoy the long nap 
1 Like
LOL! That’s almost verbatim what I told a coworker who was genuinely excited about preemptive threads in Xojo. I should lay a bet again which gets done sooner, moving our processing into Go or good/reliable preemptive threading in Xojo. It will probably take us years of concerted effort by many people on our time to move our processing to Go. I will still choose us over Xojo.
2 Likes
I bet on your Go team 
2 Likes
It’s wild how this is like the third time Xojo is working on multi processing of some sort.
1 Like
Because they’re being left behind in the dust by other languages that value performance and concurrency. We have a process that takes 15 minutes in Xojo. We duplicated it in Go and it took 3 minutes.
2 Likes
They even got Android running…okay at least you can compile something
The entire point is: it is slow like hell. And the next point is: thanks to their changes you have nearly no chance to use an old web application with the new “fast” version of Xojo. Even this fast version is when connecting a MYSQL Database and reading datasets much slower then for example Java. An operation which vosts with Xojo minutes costs with Java seconds. And there is the end of it. Xojo is not usable at all and dangerous in it’s code reliability while nobody knows what they will change next.
1 Like
THIS is the dangerous precedent they’ve set
Web 1 ? naw rewrite everything to Web 2
API 1 ? naw we are actively telling you to toss is all with the IDE and revise it all
Renamed Controls & Events ? naw throw that out and rework everything
AT least the Xojo framework was an OPTIONAL add on - which they’ve now abandoned
I’m busy trying to revise an existing iOS app and submit and update to the App Store
OMG !!!
The amount of trivial stuff I have to revisit is crazy
1 Like
What are you expecting? It is not a solution you can rely your code on for more then until next lunch
2 Likes
What can I say ?
inertia
2 Likes
Personally, its too little, too late for me.
They ignored me when I asked, the CEO gave reasons like “It allows a user to blow their toes off”, or “Its really easy to add, but we don’t think our target audience want it”.
I’ve been using it for years via an Objective-C plugin and now with pure Swift and guess what, I still have all my toes! Not to mention that, Xcode will actually tell you when you’re trying to use unsafe API, and provide hints on how to fix the problem.
If Xojo have only just started, it’s going to be a very long time before they have anything that matches the level of what customers can get in FREE tools.
Edit: Quite frankly, even if it was available today, it wouldn’t make me come back to Xojo, there are so many other issues and the biggest one is the way how the CEO and company have treated me while I was trying to help them. Geoff’s direct interactions is what made me finally “move on”.
7 Likes
As it has been painfully lamented many times in this forum - you just aren’t the target audience for the CEO. Being a professional developer of course you still have all of your toes! I can easily see an inexperienced user hurting more than helping themselves. It is just a shame that the CEO completely ignored the needs of professional developers and made bad decisions in that regard.
It doesn’t surprise me that any of us who write software for a living have moved on to other tools with better out of the box capabilities than Xojo has.
Edit: I started with Turbo Pascal 3.0 back in 1984 or 1985 and picked up Delphi 1.0 in 1995. I was so excited when I found REALBasic 3.0 or 4.0 back in the late 90’s. Unfortunately when all of the bad REALBasic/Xojo decisions started to be made it was a personal no brainer to know what tool I was going to go back and focus on going forward.
1 Like
Turbo Pascal 3.0! 
Are you using embarcadero?
1 Like
No - I didn’t go ALL the way back to the beginning of that toolchain. If it was still easy to run MS-DOS 3.2 maybe. 
Various projects and commitments had me using VB.NET and Delphi throughout the 2000’s. It was about 2014 that I just couldn’t deal with the bugs and lack of 3rd party controls that I really liked in Xojo.
So yes, about 2014 I committed fully to Embarcadero Delphi XE6 and have since added TMS FNC controls for multi-platform and UniGui for Web.
2 Likes
They implemented pre-emptive shedding ( of customers). It performs pretty well 
9 Likes