Codea 3.7 (369)

@sim Is this an option or a bug. I can’t seem to find the sequence that gets me into this. It happens when I close a project, but not all the time. Normally I have 6 projects in each row, not 10. I kind of like it, but when I try to scroll the screen, it switches to 6 across.

@dave1707 @sim - if that’s 361 I think I’ll skip it until 362 emerges.

@Bri_G It doesn’t cause any problems and like I said, as soon as I start to scroll the screen, it switches back to the normal size. It doesn’t happen all the time and I’m still trying to find an exact sequence that causes it. None of the projects are affected. If you’re worried about the wired naming, that’s how I name things to keep my utility projects upfront followed by numbered projects that I modify or try regularly. I sort my projects by alpha, so projects starting with # or numbers stay ahead of my normal named projects. So there’s no reason to not use a certain version of Codea.

@dave1707 @sim - loaded 61 and no issues as yet. Transitions look slick.

1 Like

I’m having the same result by opening an second Codea window on the side, the Codea app switch to iPhone mode or something, and didn’t get back to iPad for some reason.

I just had this happen to me, too! It seems to be related to changes we made to the project browser. I’ll have to review the code changes here, but did you ever put Codea into split view with another app while editing a project? (That’s how it happened to me)

I think that’s the issue, one notification was removed relating to size changes which drove the layout that we’ll need to restore

The only time it happened for me was when I closed a project with only 1 running. I couldn’t figure out a pattern that caused it, but I always knew when it was going to happen. It seemed like it took a lot longer for the project to close when it would happen.

Thanks for reporting the issue. We’ve fixed the issue and will include the fix in the next build.

4 Likes

Just to introduce him, @unsung_lee is my friend and has joined @John, @jfperusse and me in working on Codea!

3 Likes

@sim Tried the Run in New Window which worked OK. I’m not sure about the Live Coding. The live coding only seems to work if the change is made in the current line. If I try changing “12345” to val, it kicks out an error. Also, if the text line is changed to text(val,WIDTH/2,HEIGHT/2) and I change the value of val in setup to something else, it isn’t updated in the text line. If I change “12345” to some other number in the text line, it’s updated. Not sure how much is supposed to work.

viewer.mode=FULLSCREEN

function setup()
val=33
end

function draw()
background(0)
text(“12345”,WIDTH/2,HEIGHT/2)
end

PS. After playing with this more, I understand why making changes in setup doesn’t work. setup is only run at startup. But I do run into errors sometimes. If a number or string is nil because I backspaced all the way to make a change or I changed to a variable name not defined yet.

1 Like

It definitely needs some work (and will be optional), thank you for trying it and letting us know how it went. We will be making it more like Air Code where errors are ignored until they are fixed in the code rather than blindly running every change

@sim Dependency doesn’t seem to work with Run in New Window.

1 Like

Good find. Would be happy to take feedback about how we should do the Lua code injection here

You already noticed the issue with setup() not being re-run when changes are made. It’s not very intuitive and caught me out initially

At the moment we simply call load on the buffer you are editing whenever a change is made. We could call setup() again, but that might cause problems when people initialise global state there that shouldn’t be re-initialised

In Air Code, we do not re-initialise classes (x = class()) when re-injecting the code, we may do the same here to allow modification of existing class instances

@sim I don’t think setup() should be rerun. That could mess up a running project. If a setup variable is changed, is there a way to just update that variable. The other problem is not updating the running code if there’s an error in the edited code.

We could have a reloaded() callback that only gets called when hot loading code (if there is anything the user needs to update)

1 Like

Actually I’m thinking what if we have a shortcut key to call load() on the current line, or currently selected text

This would let you update a variable in setup() then hit the shortcut or menu item to send it to the viewer on its own

@sim @ John @ dave1707 - loaded and ran 362. Ran a project to look for visual differences initially. Noted the toolbar changes at bottom right and the second option on the drop-down from the run button.

Pressed on the ‘rerun’ icon in the toolbar which re-ran the project in the errored out run screen and it re-ran the project coming back with the same error - as expected.

Tapped on the far right icon in the toolbar and the dialogue came up for recording the screen and when I tapped on the option to not record Codea crashed.

Two issues - firstly can you confirm the function of the icons in the bottom toolbar. Also the icons seem less defined than before and some don’t reflect their function as a result of it.

Secondly - I think the crash for screen recording is an old issue, was it fixed before or has it just slipped down the priority list?

Edit: a forum query, just noted when this post was made that a link to @moechofe with an arrow popped up. Does this mean that the post was sent to @moechofe ?

@Bri_G Funny feature.

With 361, I got +10 crashs per day.
With 362, I got zero (so far), good job Codea team. :grin:

@sim @John @dave1707 @moechofe - one quick query and an observation.

Query - TLL now seems to have more developers involved, could you list the members and their function and let us know who we should be addressing with issues so I don’t raise issues with the wrong developer.

Observation - while running with the split screen I noticed the run window on the right seemed narrower and was dominated by the side bar in my project. Also the graphical output from the project seemed to be centred in the run window which was notable as my project had only displayed an animated sprite centre screen in the run window. The sprite was visible below the sidebar. Was that intentional?

Also, on my pad, moving the widow bar to the left is limited. Wouldn’t it be better to be able to scroll to the far left, leaving a hook icon so it can be dragged back, allowing you to see most of the editor window or output window to get the max out of the flexibility?

Edit: my eyesight first thing on a morning not too good. Icons on toolbar OK but the video recording one doesn’t imply it’s function.