1.5 problems/questions

After updating to 1.5 I have the following problems.
iPad1 iOS 5.1.1

I have made a calculation program (fore radio tubes) including two graphs, one for the Vg-Ia and one for the Va-Ia curves. Graphs including main and sub lines (divisions).
Running under V1.5, all lines are thicker (but not all lines) than under the previous version.
What is wrong? Something with the pixel calculations? A pixel is a pixel I think. What can/must I do?

While editing you can open the tools menu with the eye on the extended keyboard, this will open the main tools menu. After selecting an item it is not possible to go back to the main tools menu for selecting another item. Re-open the tools menu doesn’t help.
What do I wrong.

In the editor, opening a tab takes a very long time, some times is not possible to make a selection at all, it seems codea don’t response. I must than close the editor and restart it again to solve this problem.

Are above problems iPad1 problems? I don’t hope so.
For the rest, 1.5 is a very nice update.

Greetings, Dirk Hartland

1/ line width: very thin lines (1 to 3pixels) were not drawn correctly by previous versions of codea. TLL has corrected that, but now lines are thicker => you have to adjust your code.
2/ help panel: swipe right on the panel to go up one level

Hi @Jmv38,

Just set myself up with 1.5 (Wow!!) and ran the demos (drool), looked at the reference docs (pheeew) and then loaded a key app that I am studying to better my code for Codea - 3D workbench - you’re app.

Unfortunately it didn’t work - probably due to clashes with the new features as 3D, meshes and rotations have all been enhanced.

No idea where the problem is - just bombs out of Codea. Too much to investigate on new features now, so will return to playing with my new toy. Hope you can update you app for a later date as I found it very useful.

Thanks,

Bri_G

:slight_smile:

1.5 is very nice, getting my head around shaders…

however,
I mainly use keyboard with ipad 2 in landscape rotation, and 2 things I’ve noticed.

  1. the editor seems a little sluggish at times, maybe this is an impact of the extra context sensitive help etc? In shader lab this was really bad when I forget to pause the shader :wink:

  2. handling of long lines is still not right, if a line runs to more than one line (ie it wraps) it used to look messed up, now it sometimes looks messed up, and also typing on the line behaves weird/types in the wrong places…

Not wanting to whinge cos there so much good, but there you are

.@spacemonkey apologies for those two issues. I will be fixing them by rewriting the editor once more, but it would have delayed 1.5 by another month or so had I waited to do that for this release.

.@Bri_G I’ll have to have a look at that project to see what’s causing the issue. Is that on the forums?

.@Simeon, no dramas, all the good far out weighs a couple of niggles, just means I need to refactor a bit to avoid long lines :wink:

.@spacemonkey I’ve had some of the same issues as you in particular the when it comes to typing and also copying lines of code from in the code editor when its not running.

I usually work on my ipad 2 in a portrait orientation but switched to landscape when I ran into the typing issue.

.@simeon
I’d like to add that when it comes to deleting? Sometimes your cursor doesn’t delete what it appears it should. This was noticeable when a side panel reference is open.

Hi @Simeon,

Found it at Jmv38’s website at this link

http://jmv38.comze.com/CODEAbis/server.php

There’s a tutorial and the workbench links around videos on 3D planets.

Hope that helps.

Bri_G

:slight_smile:

Thanks @Bri_G

Thanks Jmv38!

Help panel works! Stupid me, right swipe is from left to right and from right to left!

Line thickness, yes correct now, but I added the instruction noSmooth().
I was thinking that noSmooth() was the default.
Simeon, the default smooth() or noSmooth() is not reported in the help panel.

Version 1.5 (editor) is slower than the previous version, okay I have an iPad1, no problem. Again, 1.5 is a very nice update!

Greetings Dirk.nl

I’ve downloaded the update, run a few of the demos, realised that I’ve a lot to learn about the new features, and checked that some of my projects will run (generally with changes to how I created parameters, and an undoing of my workaround for the line thickness oddity in 1.4.6). My arc code is looking much better, and another project else has lost some of the oddities of line-drawing from the previous version.

.@Simeon, I will take the opportunity of the remark about rewriting the editor to make this comment: I have a recurrent problem that when I navigate through my code either by choosing a function or searching for text, if I choose an item (to go there), it often puts me there but places the cursor and the sought-for text or function at the bottom of the edit window. Underneath my onscreen keyboard. It took me a while to figure out what was happening. Could the default positioning be the centre of the visible code editing window, taking into account whether the keyboard is visible? (iPad 2, iOS 5.1, I’ve never used an external keyboard with this device.)

But I’ll return to the positive - I am excited at all the things I want to try with 1.5. It’s here, which means I’m no longer worrying (I was, a bit) about transition of my code from 1.4.6 (it was essentially trivial). It’s got lots of new things to learn about and explore. And finally I have somewhere to put all the normals I’ve been calculating by hand for the past two months. :slight_smile:
Hurray for 1.5!

Richard

@Simeon the line break highlighting works great now, but could you implement it also for multiline comments like:

--[[
...
]]--

--[[
...
--]]

Alternatively .@hartland think of the eye as a toggle switch. Tap it once to open it up, tap it again to close it. Do the same for the new spyglass code search icon.

.@Simeon yeah, I noticed the highlights but worry that since strings are highlighted red there may be some confusion as to what’s contained within a string and what’s not? Especially when you get to the string literals versus the new red highlight that comes about print.

Can you maybe make print a different color like maybe purple? So we know when its not being used inside a string? Cause right now there’s no difference its red in and red out.