@UberGoober - hmmm, semicolons I do miss them.
No seriously, I remember chasing bugs which were down to missing semi-colons - and I don’t miss them !!!
But I do like discovering how systems work and just found a big hole under fonts. How does Codea assign them. Just a small cog in a massive tool that is Lua and Codea.
I’m assuming there’s a table with entries pointing to each font/font address. Is it something embedded in iOS ?
That’s why I love autocomplete so much—even in its limited current form I bet I use it at least three times every minute, often more. Any small improvement in autocomplete is like gold to me.
I pity your keyboard/touch-screen must be red hot.
Really? I know you’re joking but that’s really not a lot. If I tapped the quick-bar three times a minute for a thousand years I don’t think it’d ever get hotter than it started.
…but on the other topic, I’m confused about the obstacle you’re encountering.
Below I’m finagling the font a bit, but the relevant part is at the end, where I’m capturing a font as a variable, changing the font, and then passing that variable to a function that uses it to change the font back.
Results attached.
print(font())
h = font()
font("AmericanTypewriter-Bold")
print(font())
atb = font()
font(h)
print(font())
font(atb)
print(font())
function changeFont(fontName)
font(fontName)
end
changeFont(h)
print(font())
autocomplete is nice, though I am not sure the recent changes are improvements.
as for small improvements, I’m all for them. however, since the time our masters have to spend on Codea is limited, I prefer small high value improvements. I think the style-dot thing may be an improvement, though I’m not sure. I am pretty sure it’s not a high-value improvement.
As for what saves time, I predict that if you track your programming time, you will find that typing less will not much improve your overall time to get things done. I suspect you’ll find that thinking without typing, and especially debugging, are where the time sinks are.
But maybe that’s just me. If everything I typed was perfectly correct, typing time would be more important. 
@RonJeffries —ah but there you go again—what you call high value is different than what I call high value.
For me the recent autocomplete changes are vast improvements, even though the feature still only works correctly like 40% of the time.
And autocomplete saves way more than just strict typing time—I am what you might call memory-challenged, and simply not having to scroll around or change tabs to remember a variable name is, as I say, gold.
Autocomplete literally lets me think less, program more—so for me the thing you’re criticizing, ironically, has all the virtues you’re praising.
i do recommend that you track your time spent. i don’t know what you’ll learn, but i’m sure you’ll learn something.
I’m not sure how I’d track time saved not pressing keys and not searching for variable names.
I think I also have a pretty good internal barometer in that every time autocomplete works I’m a little pleased, and every time it doesn’t work I’m a little annoyed — and I suppose it goes without saying that I rate a low annoyance level in the high value category.
I didn’t expect this topic to get so much attention
@RonJeffries so the main rationale behind the proposed change was indeed trying to reduce namespace polution. I’m a fan of fluent syntax, but I can see it’s not for everyone. I tend to do the following:
style.push()
.fill(255)
.strokeWidth(5)
.stroke(255, 255, 255, 128)
There’s also the possibility of just writing the style.fill(255) etc… on each new line. Any time you see a color argument you can give it a color object or any of the standard overloads (i.e. grayscale, rgb, rgba, grayscale+alpha)
As for getting style values I just assumed you wouldn’t really be trying to get multiple ones so passing zero parameters causes it to return the style value rather than the the style table/namespace. It seemed like the most sensible thing to do.
I was trying to be consistent with this new syntax, so I’ve been playing with matrix.push() and context.push() as well.
I’m also working on stuff like require 'legacy' for compatibility with older projects.
As for timelines, I’ve been out of commission for the last month, which has delayed the project. Once the IDE is compatible with Codea 4 and is useable, we will immediately go into early beta and all you guys can start playing with it so we can get feedback and suggestions.
I’m also looking into having a dedicated Library folder like Shade has for adding user extensions to Codea, that will function globally. The new class bindings also supports this, so as an example I’ve already done the following when playing around with the new editor:
-- Entity class extensions
function entity:placementWobble(duration, spinCount, tiltAngle, height)
local scn = self.scene
local y = self.y
self.y = y + height
scn:tween(self):to{y = y}:time(duration * 0.75):ease(tween.bounceOut):unscaled()
local up = vec3(0,1,0)
local right = vec3(1,0,0)
scn:tween{t = 0}:to{t = 1}:time(duration):ease(tween.circularIn):unscaled():onStep(function(tween, t)
local t2 = 1.0 - t
local dir = quat.angleAxis(tiltAngle * t2, right) * up
local dir2 = quat.angleAxis(t * spinCount * 360.0, up) * dir
self.rotation = quat.fromToRotation(vec3(0,1,0), dir2.normalized)
end)
end
Yes, the new tween system is also fluent. I can’t help myself
So if people wanted to just add new methods to existing built-in types, this will be possible. Making Codea a bit more flexible. This will also work with shaders, so you can #include something from the library, the project or even a lua function that lives in the shader and dynamically generates code.
I know it’s extremely slow going at the moment, so I hope it’ll be worth it for you guys
This is what the entity:placementWobble() function was being used for: https://twitter.com/johntwolives/status/1419323648406548482?s=20
@John - OMG that’s mind blowing. Please tell me that doesn’t need the latest iPad tech to run? I’m already seeing my iPad slowing down with iOS upgrades and the knock on effect with Codea.
@Bri_G what version of iOS can you run? The current build is using 14.6
Interesting stuff, John. I’m sorry to hear you’ve been out of commission and hope you’re back up to standard now.
I certainly have no problem with fluent syntax, other than that sometimes you’re not really sure what has happened or how it works, as we see in CodeaUnit, which is mostly magical to the reader. That’s the case to a lesser extent in collection handling such as we see in Python, where the syntax passes the result on, rather than the original style or whatever. I value keeping the namespace clean, even though it doesn’t help me much day to day.
I do think the “legacy” idea is a good one. I would try never to use it, but when you just need to get some old program going, it would be helpful.
As a rule, I’d personally prefer classes for fluent syntax, as you show with tween, but I think that’s a personal preference left over from my long OO career: arguably Lua is more about functions than objects. I imagine that it might be best if you could lean Codea pretty firmly in one direction or the other rather than have some this.that().mumble() sometimes and foo:bar():baz() other times.
The library folder is very valuable. I gather that one has to include or require things, which seems like the right thing to do.
Where I’d like to get more help in Codea usage is on the editor side. Some form of snippets capability seems like it would be valuable, though I admit I’d probably have more like 5 snippets than 50, so I can’t say it would be amazingly valuable. I wish there were at least a replace that worked, and I’d simply love some real refactoring support, but in the absence of menus, controlling that would be difficult. And, of course, it’s bloody hard to do real refactoring that are context sensitive.
Anyway, Codea is amazing given the limits of the iOS system, and Apple’s bizarre rules. I look forward to Codea 4 with antici …
pation.
Thanks!
R
@UberGoober of course we all get to program as we wish. As I use a magic keyboard for programming, and because it’s so erratic, I’d turn off the autocomplete if I could. I think I have a lower tolerance for irritation than even you claim. 
I am quite sure that my time spend debugging … and mind you, with my focus on TDD and testing, I don’t have to debug often … my time spent debugging is far greater than my time spent typing. So no amount of time saved typing will make up for the absence of some feature that helps me avoid common mistakes.
And I have a few mistakes that are quite common. I often forget to return the result of some accumulation, a table build or iterative approximation. And I even forget to return results in general. Sometimes I copy-paste something and fail to make all the needed changes. Sometimes I typo a name and get a mysterious nil somewhere. I’d pay extra for an “allow no globals here” feature.
Finding most of those mistakes is quick, since I usually run the program quite frequently, every 5 or 10 minutes at most. But sometimes I get into a long programming cycle, 20 minutes or more, and then when I finally run, something weird happens, and sometimes it’s hard to find. Next thing I know, I’ve gone 90 minutes with nothing working, I’ve bashed prints all over the program, and there’s nothing for it but to revert.
Your experience might be quite different, and so the things you need that would really save you time would be different as well. I find value in paying attention to what really slows me down, so that I can develop tools and habits that help me go faster without mistakes.
I suspect there are some common areas where “most” programmers would benefit from similar tools and habits. And I’m sure that there are plenty of programmers who work differently, perhaps better, and who wouldn’t get as much benefit from the things that help me.
If there’s a general good idea here, it might just be that we do well to pay attention to what works for us, and what doesn’t, and try to adjust how we work to stay in the good places more of the time.
Everyone’s mileage varies … and we’re all somewhat the same, and somewhat different.
One example: for me, your style-saving object would be more valuable than the style.this.that stuff. I think it provides more leverage.
Another: I guess I’d better check out what you’ve done with CodeaUnit, to see what I can steal and put into my version.
Rock on!
As for myself, I like simplicity. I’m not sure how well I’m going to like the strung out commands separated by periods as in
style.push().fill(color.white).stroke(color.red).strokeWidth(5) .
but then I guess it’s not that different from
pushStyle();fill(255);stroke(255,0,0);strokeWidth(5)
Over the years there have been many changes and you get used to them after awhile.
@RonJeffries well if we’re going to talk about time-saving in general, the single most massive time-saver ever, for me, by orders of magnitude on top of orders of magnitude, is what I’ve learned about TDD from watching how you do it.
I hate to be honest about how many times I have to learn the lesson, over and over and over, that it takes barely any time at all for wading right in without test cases to become a major boondoggle that I’d have avoided by just doing the seemingly-too-simple-to-be-necessary tests up front—a lesson I still haven’t learned fully, if we’re talking real talk.
That said, I think I don’t need a time-tracking system to be 100% certain of the massive gains between being able to type three letters and then auto-complete a variable versus having to quit a project, open another one, hunt down the right variable name, quit that project, open the first one back up, hunt down the place I had been working at in my code, and then finally type the name in—if I hadn’t forgotten it already by then, or forgotten to copy it when I was looking at it (which tbh happens not a little bit), making me do the whole thing over again.
Everybody’s different, but whenever I’m working with dependencies, that scenario comes up at least once in almost every session—so for my particular limitations, I feel confident in the value of an autocomplete that would eliminate it.
Thank you for the kind words. I’m glad you’ve found TDD test cases useful. As you’ll see in my articles, I often skip them … and almost always regret it. Don’t be like me.
As for dependencies, yes, they’re a pain. Switching back and forth is horrid: it’s one good reason why multiple instances of Codea would be wonderful.
I rarely use dependencies other than for CodeaUnit or Cameras. I’m hoping that the new Library capability will make them easier. As for auto-complete, it seems not to help me much. I wonder what you do differently to find it more useful.
—> to be clear, I’m talking about the value I’d get from an improved auto-complete…
@John - I’m on iPadOS 15.0 and there are all sorts of new ‘multitasking’ features been added. I think this version has been sloped towards metal support at the expense of the older kit. So, graphically interchanges aspect changes etc are slow and not slick. This shows up in Codea at times - few forum notes describing observations been posted.