I understand the concepts. I’d be happy with anything that allowed me to pass off, say, numerical computations to run on other cores. The only stuff I would be passing is plain ol’ integers and doubles, and perhaps strings and booleans, so reentrant code wouldn’t be an issue.
If that isn’t for very short computations where the communications overhead would add more than pure processing time needs, you can do so with console apps doing that stuff for you. What Xojo intends to add with their worker class is basically just a wrapper that makes their handling easier, but nothing that couldn’t be done already.
And for macOS/iOS, Thomas Tempelmann explained how to use the system’s parallel processing APIs like Markus pointed out somewhere here.
1 Like
Yeh, but I want this to be built into the language and framework, easy to use, and transparently cross-platform. In other words, it should just work. I guess I am spoiled by Swift and its easy to use parallelism.
1 Like
Agreed. It took me some time to build a solution that’s partly xplatform and extendible, meaning it works on macOS and Windows. For the Windows part I had to use MBS because of Xojo’s IPCSocket on Windows being bound to file communication caused troubles when several helpers started at the same time.
And no, I don’t see you being spoilt asking for multi-core support in 2020…
P.S.: I have to admit although I consider myself quite Apple API savvy I never understood Thomas’ approach fully. As usual he used quite sophisticated structures …
cant call LOTS of framework stuff either 
anything that relies on consistent global state, whether its in your app or in the framework, could be suspect
Xojo would HAVE to document every last item that is / isnt preemptively safe
So much for Xojo being cross platform.
Am I just imagining or am I correct to assume that Geoff is much more active on the forum lately?
Well, when most people capable of answering have left, and the MVPs are busy patrolling, then … 
1 Like
MBS Xojo Examples Projects stay with Xojo 2019
The examples shipping with MBS Xojo Plugins are currently made with Xojo 2019. We tried to update a few for Xojo 2020r1, especially web projects. But the current Web 2 framework in the Xojo application is not complete yet from our perspective. More like a developer preview, where you take a sneak peal and wait for a future 2020r2 release to include more functionality
https://www.mbsplugins.de/archive/2020-09-11/MBS_Xojo_Examples_Projects_sta
1 Like
And the Engineers are far less active.
that has been true for a while
I just want to set expectations and announce we keep with Xojo 2019 for the examples for some time.
The ChartDirector examples can’t work without mouse down event in ImageView control.
Once another Xojo release comes and adds more Web things like mouse/key pressed events, we can better port some functionality.
Geoff is working on damage control. He doesn’t care about the core issues.
One thing that’s always impressed me about RB/RS/Xojo is that Geoff appeared to be so active on the NUG/Forum. Even if it was due to “damage control” it leaves the impression that he’s actively engaging the issues. So it was a bit surprising to me to see his astonishment at a bug “Wow, I had never noticed this before.” that evidently had several reports in the bugbase. I guess I imagined that he was regularly going through the issues with his one product to see which ones could be addressed. I certainly checked the bugbase often when I was working in xojo. It’s fairly easy to peruse for the most part.
I guess i’m surprised that he’s surprised. It’s a little jarring.
I think during the 2019r2 betas and release the thing that amazed me was his reply that “Wow we had no idea so many of you had other users as clients and the impact the event rename changes would have”
I’d post a link but … well … banned & all so 
Its there - probably in testers - when reverting the event name changes was discussed
3 Likes
Norman, as a former insider, can you tell us how bugs were handled? I was imagining that a certain number would be divvied out amongst the team on the regular. Is that not right? Is it haphazard? Systematic? None of the above?
My curiosity is piqued
Afraid that I am not supposed to discuss internals like that
Lets just say it could be better which should be no surprise given so many that sit in “Needs review” forever
Fair enough. I’ve been working in a sales/consulting role for the past 7-ish years and in Netsuite there is this concept of KPI’s (key performance indicators). I feel like bugs would be a good fit for being such an indicator. Knowing whether my product was getting better or worse, vis-à-vis bugs outstanding (and perhaps rated on severity) seems like something management would want to keep track of…
I’ve sat at the dinner table and talked with Geoff (xojo conference). He’s clearly ambitious, bold and obviously intelligent/well read. Good CEO traits. But after all these years it’s clear that the workflow for bugs isn’t titillating enough to capture his attention quite as much as his forward thinking about features and platforms to conquer. A moments meditation on this might give him the insight that he’s out of balance, and maybe it’s time to do the yeoman’s work of smashing some bugs, but even more importantly to not treat it like a fire to put out and put a workflow in place that keeps this cycle of ranting to a minimum.
Rapid. Release. Model. Is. Feature, and. Therefore. PR. Driven.
Or as Geoff allegedly said “Nobody pays for bug releases.”
Universities and large companies pay sometimes a lot of money to software vendors to get reliable support and timely bug fixes. For example we had a very expensive support-contract a couple of years ago where I wrote a bug report in the morning and I was sent a patch that fixed the bug the same day in the afternoon. On another occasion I got a patch the next day. Also we got very fast response when we needed help with the operation of the software or when we had questions. Providing such kind of service seems to be a worthwhile source of income for some software vendors.