Geoff Perlman XDC 2020 Q & A

I missed the live Q & A. If anyone managed to catch it, please post here what was said.

I should let Hal summarize if for you :slight_smile:

I didnt find it terribly enlightening as there was still a lot of “in the future” kind of talk and things they couldnt tell us

They did record it so maybe they will make that available ?

Ah I didn’t realise they were recording it. I assumed that they wouldn’t in case someone caught them off guard with a question.

I’ll wait patiently to see if @HalGumbert writes something down.

I think the only comment I’ve seen him make so far was on the discord :slight_smile:
I got the impression he was disappointed (?)

there are follow on discussions on the forums about workers and man I sure ho they fix the way things are right now

https://forum.xojo.com/conversation/post/480955

Karen asks a very good q and the answer is … well … not entirely pleasing

EDIT : at this time

1 Like

Watching it now. There’s no way workers are coming out in R1. Doesn’t look like iOS API 2.0 either :frowning:

It sure sounds like Workers are going to be VERY limited initially… and if history is any guide, for a LONG time.

-karen

1 Like

Yeah I was surprised by Kems answer to your question - makes no sense to me that the worker couldnt also have a fair amount of the main app code compiled into it.
But without a compat flag of some kind (like the Desktop, Web, IOS, Console ones) exposed there no decent way to do that and indicate what code would even b proposed to be compiled into the worker.

At least that way I could pass data in JSON that made up some object, use that to create an instance from the data, then I can no reuse my object code for whatever it is I’m going to do
But at the moment that doesnt sound possible

Flags are one solution, but I would thing that the compiler could just include all code used by the worker subclass in the worker app, and throw errors if any code used in the worker is not usable in a console app.

But I can see how that could be an issue for code in classes and modules where some of the code is not console safe and some not… The compile would need to handle that and I’m guessing it can’t. Of course that situation could just trow a compile error

1 Like

the IDE has to send the worker all the code and then the compiler could strip it out based on usage
however since a worker i a console app it probably should not be sent any thing like a window etc that is UI

I guess, like you, I’m more surprised some of this wasnt already done or thought of (apparently)

1 Like

If you don’t mind me asking, what was your reasoning behind the choice of JSON? A well constructed binary format should be faster to serialize and de-serialize.

Because naturally scheduling eats into time saved by concurrency, any time that can be saved here, will impact the overall time. At least that’s my thinking.

I saw that the workers are persistent, which is good IMHO, as it reduces launch/release delays.

not sure unpacking binary would be that much faster
it might
its really going to depend on how/if they can make it so these easy to build helpers can get access to the same code we use in the main app
not being able to leverage that code is a huge loss IMHO
they really need to solve that

1 Like

Correct me if I’m wrong but the current compiler could strip a lot of things from the code that eventually end up in our built apps (like unused framework components) to make our apps smaller but it doesn’t. Not sure I’d cross my fingers for it to do it when it comes to workers…

I breathed a sigh of relief at that too.

A related question, perhaps best answered by @samRowlands, do you think we will still be able to distribute apps using workers on the Mac App Store if they have bundled console apps?

1 Like

Yes.

1 Like

Why do they still show stuff that we won’t be able to get in 2020r1? I really don’t understand the reasoning. Xojo has teased us for years with “oh, xyz is just around the corner”. This is getting old old old.

1 Like

I basically said it’s just vaporware until it ships. Been waiting around three years. When it ships all the controls demoed years ago won’t all be there as some will come ‘later’. While Im happy about a Date Picker, there’s no sign of a Time Picker or Timestamp Picker. Literally, WTF.

Also disappointed that “Easy Database Connectivity” is further down on the list.

Making me glad I jumped into PHP. where I can apply my Xojo skillz. :slight_smile:

2 Likes

Correct me if I’m wrong but the current compiler could strip a lot of things from the code that eventually end up in our built apps (like unused framework components) to make our apps smaller but it doesn’t. Not sure I’d cross my fingers for it to do it when it comes to workers…

It does this already
What it DOESNT do is trip at the level of methods
It will strip out classes & modules that are never referenced

So it definitely could do this for workers
But the IDE would have to NOT send the code for any UI elements (windows, menu bars, buttons, etc) as if you try this in a console app the compile fails VERY early on. Long before it ever gets to the point of linking and striping out unused code.

1 Like

Phew.

I suppose this isn’t an announcement of what’s coming in the next release, merely what’s been going on over the last 12 months. I agree though that it’s very annoying to tease a feature that isn’t bake with their track record - it may well be 12 months before we see workers for all I know.

I learn something new everyday.

1 Like