json.encode fails if table contains functions.
How do I get json.encode to let me default types it can’t handle or add my own string and continue?
I’m trying to use json for documenting abstract syntax tables generated by the Minifier parser instead of writing my own.
@CodingOnNapkins - have a look at the dkjson doc : http://dkolf.de/src/dkjson-lua.fsl/wiki?name=Documentation. You can pass a function to catch exeptions.
function ex (reason, value, stat, msg)
return tostring...
end
print(json.encode(data, { exception = ex }))
color on document name offset when search icon tapped
also the error bar
@CodingOnNapkins can you show me a screenshot of what you’re referring to?
Small bug in the dependency selection, when the keyboard is up & you press the ‘+’ and minimize the keyboard, the selector changes from the black theme, to a white colour
this kills my. codea. It used to work fine. Is it a bug in my version or is it the normal behavior? Thanks.
--# Main
-- testsss
-- Use this function to perform your initial setup
function setup()
print("Hello World!")
end
-- this is a diagonal grid to visualize transparency
function grid()
local w = 20
local img = image(w,w)
setContext(img)
noSmooth()
background(0)
strokeWidth(0.5)
stroke(128)
for i=1,w/2 do
line(0,i*2,i*2,0)
line(i*2, w, w, i*2)
end
setContext()
return img
end
-- a background image
back = grid()
@Jmv38 that shouldn’t kill Codea — that’s a bug. I’ll try to see if I can get render commands working in the global scope, I’m unsure if I will be able to do this.
Hi All,
Not sure if this is a feature of previous versions but - I have a problem with printing text out. I was downloading one of Ignatz’s 3D model files and wanted to print it out to check it was there. It resulted in killing Codea. I tried again with a short part of the text printed and this was fine. Is there a limit on the print output buffer and is it protected? See code below.
-- DownGist
-- Downloading data
function setup()
-- Request some data
http.request( 'https://gist.github.com/dermotbalson/7884446/raw/a9766e3e63a7e83ffcb73a3ae68e5beba4d0be96/gistfile1.txt',
didGetData, didNotGetData )
end
-- Our callback function
function didGetData( data, status, headers )
strEnd = string.len(data)
print("Downloading ")
print(status)
piece = string.sub(data,0,199)
print("String length: "..strEnd)
print(piece)
-- print(data)
end
-- Our failure function
function didNotGetData( error )
print( "Failed to get data. Error:" )
print( error )
end
Remove the comment from the second print statement to see the effect. My iOS is 8.22 on an iPad 2.
Bri_G
note - edited print(status) line - no effect on program.
Hi All,
Question for anyone who knows - related to problem above. Is the Output window an image? The reason I ask is that if you increase the string length from 199 to 199248 (don’t ask about the number) and you scroll down to the bottom (wait for the printing to finish) - then scroll the window up by touch - I see a black window with white text against a dark grey window. The movement of the text to me suggests that it is an image - probably saved to preserve processor time as against re-printing the window. If that’s the case how is the memory management of the graphics done and can the size of the image get out of hand.
Anticipating a reply - I think this window should be a real text based window and output control should be done with upward and downward scrolling buttons so that the output is limited to output window size. Also - it would be useful if we could have a ‘clear’ command to enable window clearing and then printing from the draw() function to avoid the inevitable scrolling when we really need overwriting.
Then again I could be barking up the wrong tree.
Bri_G
@Bri_G - Not sure what you mean, but it made me find this. When you run this code, after some time the background turns black and Codea freezes. You can’t exit or restart or scroll or anything.
function setup()
str=""
for i=1, 199248 do
str=str.."a"
end
print(str)
end
function draw()
background(255, 255, 255, 255)
strokeWidth(5)
end
@Saturn031000 - thanks for confirmation that a long string can freeze the system. If you keep stroking the Output window upwards you will probably eventually see the effect I’ve mentioned when it displays the last line of the print output.
I’ve also noted colour changes as you stroke the window - not every time flipping between a black background and the grey.
Thanks,
Bri_G
@Saturn031000 @simeon
This is probably caused by unrecoverable memory overflow during immutable string copying.
I have also caused the jump out of codea to home screen by trying to edit a very long tab in the editor. I put large outputs in a tab instead of printing it so I can search it with the editor but I cannot edit that tab.
My suggestion is to handle long strings with only one reference in some way that does not require the copying of the string but doing a classic edit in place.
Perhaps adding the function string.editLongStringInPlace(string,function doing edit) would be simple enough to do if it is easy to determine if the string has only one reference.
Lots of my code just adds to the end of a long string: out=out…“add to string”
This type of action may be the only problem with long immutable strings.
Perhaps implementing a long string as a userdata with C type processing might help be an easier solution?
@Bri_G - something I sometimes do when I am printing out long strings is to write them as code, into a code tab, with -[[ and --]] on each end to make it a comment. See the Storage section of the reference for how to do this.
You will only be able to see the output when you stop your program, but it can be as long as you need.
You could saveText to a file. I have several text files greater than 1 meg and don’t have any problems with them.
@Simeon
no way yet for me to link to pictures this text description is all I can do now
I think lots of under-text colors get displaced after console or search left side box opened.
Could the OVERLAY, FULLSCREEN and STANDARD testing be missing at times when lines rewrapped?
blue bubble on this line
sprite("Document:xxx",... on next line
happens sometimes when long line becomes two lines when search started.
May be an editor layout bug when lines wrap.
note error red arrows often confusing and on wrong line and the error lines don't tell what the error is
Thanks for the feedback, never used it before but saveProjectTab() did the job. In app reference to it better than the webpage reference. Nice way round the problem, but I’m still concerned about the Codea crash on printing big files. I think it needs to be resolved but probably low priority.
Bri_G
i’ve just noticed that putting this outide the draw() function:
font("Courier")
local fs = 14
fontSize(fs)
will not change current text settings.
Does that mean that now none of the style parameters can be changed ouside the draw()? Or does this only apply to some parameters, and in that case, which ones?
Thanks.
@Jvm38 - when you say outside of draw do you mean in the global scope or in a function that’s called from setup?
Does it work if the code is in a function that’s ultimately called from within draw() ?
@Jmv38 - quickest way to find out is to test it!
@Ignatz @Jmv38 If either of you were on the Beta version of Codea and you loaded the real Codea 2.3 version, did you reload it from the App Store or from the purchased area (cloud) of the App Store. I don’t want to wipe out all of my projects and have to reload them. I’m not sure which is the correct way to update from the beta version.
EDIT: Nevermind. After looking at the App Store more closely, there wasn’t any other choice but to download from the purchased area (cloud). Codea loaded with no problem and all the projects were still there.