@Bri_G
I think the memory message might be different depending on how much memory the device has.
For the number of bytes in the table, I don’t think that matters. If I cut the size of the letters in str, the limit is still 13,956. If I cut it down small enough so it prints 2 occupancies per line, then I can double the line count. So it’s the number of lines and not the number of bytes.
@Bri_G Heres some code to run that gives the memory error and byte count. I get to a count of 25 with 905969664 bytes before the memory error. I’m on a 64gb iPad Air 3. So the max memory is somewhere above that value and less than twice that value.
PS. I tried running this on my 12.9” iPad Pro 1 128 GB and it gets to the count of 25 and then crashes Codea. Both are on version 3.1(208). I don’t get the memory message.
displayMode(STANDARD)
function setup()
str="aaaaaaaaaaaaaaaaaaaaaaaaaaa"
for z=1,1000 do
str=str..str
print(z.." "..#str)
end
end
@dave1707 - I get exactly the same as you for your last post, crashes. My pad is iPad Pro 9.7” 128 GB. Printed up to 24. On you previous post whatever you put into the upper value for z in the for statement is printed out, no crash but no text string visible in the print window. This must be because of the way Codea handles strings. That has always been a slow output - why? Is there some optimisation of code, which outputs to the screen, but no optimisation (Lua library) for print output to the output window.
p.s. are both your iPads on iOS 13.3.1 ?
@Bri_G Both on iOS 13.3.1 . Not sure why my iPad Air 3 doesn’t crash but my iPad Pro 1 does when I run the code for memory error.
@Simeon I posted this code farther up, but I just found something strange about it. I thought that if there was too much to print that it didn’t print anything. But what I found out was it just prints blanks. If you change the for loop count to 13956, it prints the alphabet 13956 times. If it’s 13957 then it prints blanks. If you run this, you’ll see that it prints the table size of 13957 and the string end. If you scroll the print window all the way to the beginning, you see the string start. It’s all blank in between. I don’t think this is by design because why would you print just blank lines instead of not printing anything at all.
function setup()
print("start")
tab={}
str="abcdefghijklmnopqrstuvwxyz"
for z=1,13957 do
table.insert(tab,str)
end
print(table.concat(tab," "))
print(#tab)
print("end")
end
@dave1707 hmm that seems like it could be a UI layout issue triggered by printing. I think I need to scrap the whole output window and replace it with something better
@Simeon I’m not sure how this happened. I was editing some code and a black circle appeared and I couldn’t get rid of it. Also, the code kept scrolling to the bottom. I would scroll the code to the top and after I reached the top, it slowly started scrolling back to the bottom. It did that several times. I exited the editor and went back in and everything was ok.
@dave1707 wow, that is really strange. It almost looks the same size and shape as the magnifying loupe
@Simeon I did a screen save of the magnifying loupe over the same area of the code. I was able to overlay the one image over the other and they both look like they’re the exact same size.
@dave1707 the next version of Codea gets rid of the magnifying loupe (replacing it with the Apple standard text controls since iOS 13). So this bug may be resolved as a result of that
@Simeon - run the code below then change the colour for the image but don’t enter from the colour wheel - instead, with the colour wheel open tap the run button.
function setup()
--
img = image(600,600)
setContext(img)
spriteMode(CORNER)
fill(132, 236, 67)
rect(0,0,600,600)
setContext()
end
function draw()
-- This sets a dark background color
background(40, 40, 50)
sprite(img,WIDTH/2,HEIGHT/2)
end
@Simeon @Bri_G Are you referring to Codea crashing if you run the code with the color wheel open. The below code crashes if run with the color wheel open.
function setup()
fill(132, 0, 67)
end
@dave1707 - yup, it also does it wth the rectMode() rect() on mine. Looks like leaving the colour routine unclosed triggers the bomb. Are all the routines provided with active/inactive flags which are parsed before the run command is permitted to fly?
Edit: From your observation looks like it’s just the colour wheel. Also this was easy to miss as a slight offset on the run button closes the colour wheel.
@Simeon I think this was reported before, but I can’t find where, so I’ll show it again. This shows the UFO and the KEY. But it you slide the parameter to false, it shows 2 UFO’s. It should always show the UFO and the KEY.
displayMode(STANDARD)
function setup()
parameter.boolean("show",true)
pic=readImage(asset.builtin.Space_Art.UFO)
end
function draw()
background(0)
if show then
sprite(asset.builtin.Space_Art.UFO,WIDTH/2,HEIGHT/2+100)
else
sprite(pic,WIDTH/2,HEIGHT/2+100)
end
sprite(asset.builtin.Planet_Cute.Key,WIDTH/2,HEIGHT/2)
end
yikes!
-- davebug
displayMode(STANDARD)
function setup()
pic=readImage(asset.builtin.Space_Art.UFO)
end
function draw()
background(0)
sprite(pic,WIDTH/2,HEIGHT/2)
sprite(asset.builtin.Planet_Cute.Key,WIDTH/2,HEIGHT/2-100)
end
@piinthesky I don’t remember who posted this, I think @Bri_G did. I’m not sure how long ago it was but I think we had a Codea release since then. Maybe, maybe not. Time seems to be standing still.
@Simeon - couple of things I have noticed about the new asset system:
Firstly, I have cut and pasted a long asset link address over a selected variable in a definition, in doing so it lost the asset part of the link and started with .documents
Secondly, I think the asset list has an issue at times, not sure if it relates to reserved words but I have a Dropbox folder named planeTXT which it sees as planetxt - the problem is it can not see the real name (case sensitive) and so can not see the enclosed files. I get round it by typing in planeTXT at the .
Edit: Another thing I noticed was I selected an asset path which was at the end of a function call with other parameters to paste a new path. When I did there was two asset parts to the new address - like ‘assetasset.documents …etc’.
@Simeon - couple of things possible issue.
First simple thing I have a lot of projects on my Codea project screen. A lot sorted into collections. I recently scrolled down in portrait mode to open a collection looking for a project and found it. Thinking of the project I wanted to run I turned the screen to landscape mode and the project icons present were well away from the ones I wanted. So I had to rescroll to find my project again. This suggests the project screen is One big image - is that so? If so it could possibly take up a lot of memory. Are all apps allocated a finite memory slot or is it extendable as required?
Secondly, I’m struggling with the asset path system in the beta. For a single instance it’s fine but with the old mode of addressing I could use a path and concatenation with a table for the final file name. I can’t seem to get the current system to use a table of files. If it is possible could you describe the syntax needed.
@Bri_G it’s not one big image, what’s happening is that the scroll offset is maintained from landscape to portrait, but that doesn’t make any sense for a long list. So for example if you are 3000 pts down in portrait then rotate to landscape, you’re going to be 3000 pts down in landscape, which is not going to be showing the same set of projects.
What I need to do is check which project was at the top of your list and compute the position of that project in the other orientation / view size, then scroll to that
Can you be more specific on the issue you have with the asset paths? Could you post some code where it’s not working for you?
@Bri_G Are you looking for something like this where you put a variable name in the [ ]. I use the below code to get different files. You can use one [ ] or 2 like I have below.
a=asset.builtin[name1][name2]