Codea 2.7.5 (145)

dave1707 · February 2019

I created a project in Codea. Copied it to the iCloud Drive . Did a Codea edit on the iCloud project. Closed the project. I was still in the Codea project list. Looked at the project and that didn’t have the changes. Had to go to the iCloud Drive and the changes were in that project. When the editor closes, shouldn't it stay with the project that was edited. I guess that also means you can have multiple projects with the same name.

dave1707 · February 2019

Tried the Export Projects. After creating the zip file, I looked at what was in it. I noticed that it contained the Dropbox asset folder. Also, when I tried the export of the zip file back to Codea, Codea eventually crashed before it showed the projects to restore.

Simeon · February 2019

@dave1707 any external projects will not show up on the main screen project list (for now). You'll have to open them for editing from the Files app. The one in your project list just happened to have the same name as an external project.

Thanks for finding the dropbox asset bug, I will test the re-importing. I may have broken it. How did you try to re-import your zip file? From the files app? From somewhere else?

dave1707 · February 2019

@Simeon I have the zip file in a folder in the Dropbox app. From there I did an export and selected Codea to receive it.

As for the external project, I created a project named 000 in Codea. I went to the Files app and copied that project 000 to the iCloud Drive. From the iCloud Drive, I selected it to open with the Codea editor. I made a change and closed the editor which left me in the Codea project list. I looked at project 000 there and it was still the original project. I went to the iCloud Drive and looked at project 000 there and it contained the changes. So I have 2 projects named 000, one with changes and one without. Is that how you see it working. I don’t mind the 2 projects, I just didn’t like being left in the Codea project list instead of the iCloud file where I started the editor.

dave1707 · February 2019

@Simeon I came across something that I hope you can change. This has been there for awhile. If I’m making changes or adding code in a project, I noticed that the autocomplete line hides some keys. For instance, if I key the variable b and I want to multiply it by some value, I press the +-*/ key which brings up a group of options to select. The problem is the bottom area is hidden by the autocomplete words. I then have to guess where the * or + or one of the other options is when I select it.

PS. Maybe you can lighten the color of the autocomplete so the background options show thru.

Simeon · February 2019

Ohh thanks for catching the autocomplete overlap bug. I’ll change it so it appears on top

Yeah the editing external projects (for now) will not show the projects in the main editor. I’d like to include them in the main editor under a section called “External” or something so you can easily find them again.

dave1707 · February 2019

@Simeon I tried moving the zip file from the Dropbox app to the icould Drive. I did a Share and selected Codea. The list of projects came up and I selected a project to import. That worked OK. So I’m not sure why it works from the iCloud Drive and not from the Dropbox app.

dave1707 · February 2019

@Simeon I selected Share on the zip file from the Dropbox app and the restore worked. Not sure what the difference is with selecting Share or Export.

Simeon · February 2019

Strange, I'll give it a try.

dave1707 · February 2019

@Simeon The autocomplete with popup keyboard buttons works great. Thanks, that was kind of annoying.

dave1707 · February 2019

@Simeon Codea still crashes on changes. When I’m trying to understand how some code is working, I’ll edit the code, make a simple change, execute the code. After several of those quick cycles, around 6 or so, Codea crashes. Sometimes it's when I execute the code, sometime when I’m keying changes. It’s not just this version, but has been happening for awhile. I think I mentioned this before, but I don’t know if you haven’t found the cause or you forgot about it. It’s not a big deal, but Codea still shouldn’t just crash.

PS. This is playing with voxels.

Simeon · February 2019

@dave1707 I would really like to sort this out, any particular project that triggers this a lot? Would the voxel example projects be a good test case for me to start to reproduce your issue?

I've been developing in Codea lately and haven't encountered this — but I've mostly been on 2D stuff.

dave1707 · February 2019

@Simeon I’ll see if I can put together an example that does it consistently.

dave1707 · February 2019

@Simeon Here’s a stripped down example that crashes Codea after about 7-8 restarts. It crashed the last 3 times I tried it. Run the code and while it’s drawing the terrain, stop the code to go back to the editor. Run the code again stopping it before the terrain finishes. Keep doing that cycle and after about 7-8 times it crashes for me. Usually in the code I’m working on, I’ll be making code changes and running it to see what happens. Sometimes Codea will crash while I’m in the editor making changes, other time when it executes the code. This is on a 16gb iPad Air with the latest code of iOS and Codea.

--# Main

function setup()
    parameter.watch("scene.voxels.generatingChunks")
    nbr=20
    scene = craft.scene()   
    allBlocks = blocks()  

    size = vec3(nbr,1,nbr)
    coordinates = vec3(size.x/2 * 20, 70, size.z/2 * 20)    
    v = scene.camera:add(OrbitViewer, vec3(size.x/2 * 20, 130, size.z/2 * 20), 400, 70, 2000)

    scene.voxels:resize(size)        
    scene.voxels.coordinates = coordinates 

    scene.voxels:generate(readProjectTab("Generation"), "generateTerrain")

    createCloud(200,80,200) 
end

function update(dt)
    scene:update(dt)
end

function draw()
    update(DeltaTime)
    scene:draw()     
end

function createCloud(x,y,z)    
    local c = scene:entity()
    c.position = vec3(x,y,z)
    local v = c:add(craft.volume, 25, 25, 25)
    local cx, cy, cz = v:size()

    local white = color(255, 255, 255, 255)
    local f = 0.07
    local power = 4
    local wx = craft.noise.perlin()
    wx.seed = x
    wx.frequency = f
    local wy = craft.noise.perlin()
    wy.seed = y
    wy.frequency = f 
    local wz = craft.noise.perlin()
    wz.seed = z
    wz.frequency = f 

    local r = 9
    local r2 = r*r

    for i = 0, cx-1 do
        for j = 0, cy-1 do
            for k = 0, cz-1 do
                local ox, oy, oz = wx:getValue(i,j,k), wy:getValue(i,j,k), wz:getValue(i,j,k)
                local dx, dy, dz = cx/2 - (i + ox * power), cy/2 - (j + oy * power), cz/2 - (k + oz * power)
                local d = dx*dx + dy*dy + dz*dz
                if d < r2 then
                    v:set(i,j,k, BLOCK_ID, 1, COLOR, white)  
                end
            end
        end        
    end

    c.scale = vec3(1,0.5,1)

    return c
end

--# Generation

function generateTerrain(chunk)
    cx, cy, cz = chunk:size()
    SEA_LEVEL = 10    
    -- block types as noise sources
    air = craft.noise.const(0)
    grass = craft.noise.const(chunk:blockID("Grass"))    
    local n = split(air, grass, SEA_LEVEL)
    n = warp(n, hills(40))  
    chunk:setWithNoise(n)
end

-- take two noise functions and split based on elevation
function split(a,b,depth)
    depth = depth or 64    
    local s = craft.noise.select()
    s:setSource(0, a)
    s:setSource(1, b)   
    s:setSource(2, craft.noise.gradient()) 
    s:setBounds(1.0 - depth / (cy + 0.0), 1.0)    
    return s
end

-- warp one noise function using others
function warp(input, d1, d2, d3)
    if d1 and d2 and d3 then
        local zero = craft.noise.const()        
        local displace = craft.noise.displace()
        displace:setSource(0, input)
        displace:setSource(1, d1) -- x
        displace:setSource(2, d2) -- y
        displace:setSource(3, d3) -- z
        return displace
    else
        local zero = craft.noise.const()        
        local displace = craft.noise.displace()
        displace:setSource(0, input)
        displace:setSource(1, zero) -- x
        displace:setSource(2, d1) -- y
        displace:setSource(3, zero) -- z
       return displace
    end
end

-- generic hills (height map style)
function hills(height, offset, frequency, octaves)    
    height = height or 10
    offset = offset or 0
    octaves = octaves or 5
    frequency = frequency or 0.25    
    local heightNorm = height / (cy + 0.0)    
    local shape = craft.noise.perlin()
    shape.octaves = octaves
    shape.frequency = frequency        
    local shape2D = craft.noise.scale(1,0,1)
    shape2D:setSource(0, shape)    
    local shapeFinal = craft.noise.scaleOffset()
    shapeFinal:setSource(0, shape2D)
    shapeFinal.scale = -heightNorm * 0.5
    shapeFinal.offset = -heightNorm - offset/cy ---heightNorm*2      
    return shapeFinal
end

dave1707 · February 2019

@Simeon I tried the above code on my iPad Pro and it didn’t crash Codea. On my iPad Air it crashes every time.

Bri_G · February 2019

@dave1707- is this a memory problem. What memory is in your Pro and iPad air? When you say crashes every time on the air do you mean 1 start or 7 or 8 starts?

piinthesky · February 2019

@simeon with my stuff (mainly 3D) i can almost guarantee that Codea will crash the fifth time i start the program (during the setup). Works fine 4 times in a row!

piinthesky · February 2019

@simeon i find the camera recording works first time, but if i try to do it the second time it will yield just a grey screen when i stop the recording.

Simeon · February 2019

@dave1707 thank you for that! I'll see what's going on in that example

@piinthesky sounds like it could be related to the issue dave1707 has

Simeon · February 2019

@dave1707 looks like there's a bad memory leak in the voxel stuff, trying to track it down. Your example was a big help

Simeon · February 2019

This will be fixed in the next beta

dave1707 · February 2019

@Bri_G My Air has 16gb and my Pro has 128gb. The program usually runs ok until the 7th or 8th start. It’s probably a memory problem because that’s about the only time Codea crashes.

Bri_G · February 2019

@dave1707 - have you tried clearing the garbage?

dave1707 · February 2019

@Bri_G I put garbagecollect in there just for kicks, but the program still cancels after 7-8 restarts. Memory should be cleared when a program starts. I think it’s a Codea memory issue, not a memory issue with the program. The program above is just a test program to show the problem. Under normal conditions, sometimes Codea will crash when I’m in the editor after I’ve gone thru several cycles of making a program change and running a program.

Bri_G · February 2019

fave1707 - just a thought. I am used to interpretive languages dropping out of the run mode when an error occurs. Recently I have noticed that Codea continues to run and post further errors. I have posted a comment on this previously. Could it be associated with that?

dave1707 · February 2019

@Bri_G No. The code runs OK the first 6 or 7 times then crashes the 8 or so time. After that it will run 6 or 7 times then crash again. It’s probably a memory issue with Codea itself.

Bri_G · February 2019

@dave1707 - hmmmm, so the code runs 6 or 7 times then crashes. Then, after restarting you run another 6 or 7 times before another crash. Couldn't be that you have 7 instances running in parallel, the latest one visible, which gets junked when it crashes as Codea restarts clean? Do you still get a good fps?

dave1707 · February 2019

@Bri_G I run the program then exit back to the editor. I run it again then exit back to the editor. I do that 6 or 7 times before Codea crashes. Codea wouldn’t be running my code when I’m in the editor so there won’t be 7 instances running. I don’t think Codea is cleaning up it’s memory upon restarts.

piinthesky · February 2019

yes i suspect that as well, but not only for the voxel stuff!

Simeon · February 2019

What's happening is that each time dave's project runs it allocates memory for the voxels (including textures)

It was failing to release the texture loaded into memory, leading to around 25 MB of accumulated memory to sit in RAM

Each run keeps accumulating this wasted memory until the iPad decides Codea needs to just back off, and closes Codea

Bri_G · February 2019

@Simeon - thanks for the update, doesn't garbagecollect() pick that up? Also does iOS have it's own memory manager monitoring apps, and is there a limit on the memory accessible to individual apps?

Simeon · February 2019

@Bri_G in this case it's lower level than that. We're allocating and failing to free memory at the C++ level. Lua doesn't know about it so it can't be affected by collectgarbage()

Simeon · February 2019

@dave1707 build 145 should fix the crash issue due to memory

@piinthesky hopefully this fixes your crash after >5 runs too

dave1707 · February 2019

@Simeon My code above crashes at 12 restarts. I tried it twice and both times it crashed at 12.

Simeon · February 2019

@dave1707 damn, I have a feeling that one is not memory related now but I'll try running over and over on an older iPad

dave1707 · February 2019

@Simeon The Export Projects works great now. It doesn’t contain the Dropbox folder anymore. One thing I just found out. If you just tap the zip file, it opens Codea for restore.

dave1707 · February 2019

@Simeon setInstructionLimit is missing. Is that the api you referred to.

Simeon · February 2019

@dave1707 hah yeah, that's the one. It hadn't been doing anything for a few years now,

piinthesky · February 2019

@simeon with 145 consistently crashing on the 6th start (no voxels). Camera recording still gives grey screen on second try.

Simeon · February 2019

@piinthesky damn. Is this with a particular Craft project?

piinthesky · February 2019

@simeon, yes the neutrino telescope one. It is fairly complex, so could be something i do wrong, but surprising it would work 5/6 times.

dave1707 · February 2019

@Simeon The find/replace doesn’t work right. If I do a replace all, it finds all occurances, but only replaces the first one.

PS. It also looks like it creates blank lines and screws up other lines. It seems to replace random spots.

PS. It looks like it replaces the first occurance, adds a blank line and the replaces where it thinks the next occurance was but it’s not. Adds another blank line and replaces where it thinks the next occurance was but it’s not. So it ends up replacing the first occurance and then just screwing up stuff after that.

Simeon · February 2019

Thank you for finding that. Will fix

Bri_G · February 2019

@Simeon @dave1707 - just tried to save my projects with the Codea archive option and it failed part way through. I have a lot of project files but I have a 5 minute setting for auto lock so the screen dims if you don’t catch it - are other iOS features put to sleep like file transfer etc by this setting. What setting do most users adopt?

dave1707 · February 2019

@Bri_G How many projects are to backing up. I have about 530 and it works OK. My projects aren’t that big so maybe that’s a reason. My zip file is 4.9mb.

Bri_G · February 2019

@dave1707 - I have 466 projects on my iPad Pro but I have tons of graphics in my Code ‘Documents’ folder many in assets folders. Plus I have a very large Dropbox Codea folder mainly filled with graphics. When I backup my system with your utility it’s very fast. When I backup to the Dropbox folder, using the Codea archiving tool, it takes age.When backing up to Dropbox does the Codea backup write first to the Codea Documents/Dropbox folder, then copy that to the remote Dropbox Cloud?

Simeon · February 2019

@Bri_G I could make it so the screen doesn’t sleep when exporting

Bri_G · February 2019

@Simeon - I thought it may be due to an iOS system power saver like screensaver etc. So I don’t know if it’s just from the screen sleeping. Not worth a lot of trouble, I currently use @dave1707 backup which captures all the code.

dave1707 · February 2019

@Simeon Something I just noticed with Export Projects. When I look at the zip file, I see that whatever is in the Documents folder just gets mixed in with the Codea projects. Is there a reason you don’t save a Documents folder with everything that’s in Documents in it. When you were saving the Dropbox folder, you had all the Dropbox files in there instead of mixed in with the Codea projects.

Bri_G · February 2019

@Simeon @dave1707 - just to show how my Documents folder() is arranged - I have 317 items in there of which 47 are asset files or collection - it also includes the Dropbox folder which includes 148 folders and 259 files.

From Codea my Dropbox assets visible include 3 Shaders,10 text or json files, 21 images and one model.

My Dropbox Codea folder, examined in FileExplorer, has 145 folders and 101 files.

Many of the files are not recognised in Codea, hence the limited number in the Dropbox.assets folder within Codea. What exactly is recorded in the exporting procedure.

dave1707 · February 2019

@Bri_G No wonder it takes so long to do an Export Projects. The Dropbox folder isn’t backed up, but you say it’s included in the Documents folder. The Documents folder does get backed up, but in my above post I saw that the contents of the Documents folder just gets included with the Codea projects and isn’t seperate as a folder. I don’t know if that’s a bug or was intended that way.

When you use my backup program, I only backup the Codea projects, nothing else.

Howdy, Stranger!

Categories

In this Discussion

Codea 2.7.5 (145)

Comments