Blog > 4.7.4 Beta

Home Forums ViewPort 4.7.4 Beta

This topic contains 7 replies, has 2 voices, and was last updated by  Anonymous .

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #10681


    Hanno – great work- thank you!

    Propbasic compiles ok IF you do not LOAD libraries

    If you use LOAD command, then the compiler breaks with "Could not read source file", and then gives the folder as ..Local SettingsTemplib.pbas rather than in my project dir.

    So I guess this is related to the new file/folder handling too.
    The issue might also apply to LOADing tasks (not checked yet).

    Sorry to keep you on your toes!!

    edit: If you use the full path & filename in the load command its OK.



    another issue:

    If you have a FUNC without a RETURN, then PropBasic compiler throws a warning (good so far).
    But in the new VP, this is treated as a serious error, and so you cannot Run or Load the program to the Prop. Also the status bar shows "compiler error", even though the .spin file is created.

    also… not sure where the warnings / errors are displayed now? I can see the .err file created in the program folder… Maybe that’s a work in progress? When I click the status-bar "Failed to compile code for Propbasic" link I see the "Status" window… I guess later the err. info will be displayed there?

    (Info: Not sure if you are familiar with PropBasic, but you can save an instruction by NOT using a return statement from a function when the __param1 already contains the value you wish to be returned!)




    Cannot reproduce this yet, but seems important enough not to forget. Maybe if you think through the VP code logic, you might think of something!

    So… "sometimes" when either loading or compiling code (aka. developing all day), then updates in the TASKS/COGS do not get compiled when compiling or loading the main program.

    I spent a few hours today battling with some code which was not working, only to discover all the changes were not being compiled and deployed when I hit Load… just an older .spin compiled version. So obviously the bug I was trying to solve stayed put to annoy me!!

    As a last resort I just examined the .spin files and realised only the main program was compiled fresh each time, and the linked (LOADed) tasks were very old. I can imagine this is some weird-case scenario based on your new file-copy logic to the temp directory, but I think very important! Unfortunately I deleted all the .spin files from the project dir. and the system temp dir. before analysing it further. However, that did cure the problem, and now VP seems to be compiling the files as expected.

    (Perhaps an old or locked .spin file … perhaps something to do with installing the new beta version – maybe the temp .spin files need to be deleted when the VP starts ?….)

    I will keep a watch on it now, and send a test-case if I can.



    Ok… this old-version-file thing is definitely an issue. After a few edits to another task file it is behaving the same way. Again deleting the propbasic files in system temp folder solves it.
    If the problem is not obvious for you, please reply and I will gladly try to experiment a bit to pinpoint the cause.



    and another observation…

    If the attempt to compile fails because the program is too big, then the "Origin exceeds FIT limit…" warning comes up, and then a new .spin file with a random guid-type file name appears in the VP editor.

    I’m not sure that is the desired result… the VP can get quickly cluttered with all the random files!

    Is it not possible to open just the real .spin file? Or even better the source file with the culprit code highlighted where appropriate. However, in the case that something does not fit (so no specific error) then maybe it is not appropriate to open the spin or source file at all? As what can we refer to? Just the user should now that something needs to be reduced!

    (I appreciate this is a side effect of your new compile file handling- which seems to have caused you some more headaches than it might have solved! As can be the way with these things!! I hope my feedback is useful and taken positively even if short-time means I write it quickly sometimes…)




    when compiling a .pbas source with an error, sometimes the .pbas source code is opened to show the error- but next to the source code file which was already opened… So now I have 2 instances of the source code open. Do it again, I have 3 opened! Which do I close… which did I last edit… arghh.. need to watch out for that! The editor should pop into the existing instance of the file, not open a new one each time?



    Thanks for the feedback!
    I’ve gone through and addressed all issues with 4.75:
    - You still don’t have to save a file in order to compile/load/debug it.
    - VP creates a temporary file, either in the temp directory, or in the directory of the saved file and compiles that
    - VP looks for referenced files in the same directory. For spin, VP also looks in viewport/lib and the Parallax library (if Prop Tool was installed)
    - when a compile error occurs VP selects that file and highlights error
    - warnings are ignored for now
    - VP compiles a .pbas file into a .spin file with same name
    - Referenced files need to be saved to take effect.



    Hanno- just been testing these changes… AWESOME !

    Thank you for the quick new version. Now it seems I can keep quiet for a while!!

    .. although could not rest without 1 more (not urgent) thing…:)

    In the VP editor, the start of every .pbas source file is lacking formatting, until [u:24k03cs5]after[/u:24k03cs5] the first propbasic command. It can be solved by putting:
    ‘ CON
    at the top of the source code file.
    It’s not a big deal, more annoying for a perfectionist than anything, although sometimes is does mean certain characters are unreadable before the first PropBasic command in the file… You need to try it to see. The first few comment lines will be black instead of green if you do not have ‘ CON on the first line.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.