Shop OBEX P1 Docs P2 Docs Learn Events
FlexProp: a complete programming system for P2 (and P1) - Page 35 — Parallax Forums

FlexProp: a complete programming system for P2 (and P1)

1323335373854

Comments

  • (Do note that your fix also seems to break cases that don't rely on this "unset flag ignored" big brain logic)

  • Still looking for the buggy case...

    This one makes my brain hurt, but is actually correct, too:

    C set -> body runs, ok

    C cleared, Z set, C set -> body runs, ok

    C cleared, Z set, C cleared -> body does not run, ok

    C cleared, Z cleared -> body does not run, ok

  • Wuerfel_21Wuerfel_21 Posts: 4,374
    edited 2022-07-12 14:18

    Okay, found actual issue, seems to be entirely unrelated to the actual branch opt logic:

    In the arg01 == 0 case, result1 isn't set at all. Maybe the conditional call isn't handled right in isDeadAfter?

  • Wuerfel_21Wuerfel_21 Posts: 4,374
    edited 2022-07-12 14:43

    Yep, that's it, PR incoming

    EDIT: Perhaps also of note is that the version with the branch opt applying is actually larger here due to the optimizer failing to eliminate the localXX registers.

  • Thanks, Ada!

  • There's a new version 5.9.14 of FlexProp, available from my Patreon page and from github (see my signature for links). This version has much better support for 64 bit integers in C and in BASIC; they should be working for all practical purposes now, although naturally there could still be bugs (and so 64 bit integers are documented as "experimental"). There are a few other enhancements for BASIC (like PEEK/DPEEK/LPEEK, VARPTR, and base 4 and base 8 literals), improvements to the bytecode backends to better support C code, and of course plenty of bug fixes.

  • pik33pik33 Posts: 2,347

    Int64 in C opens a way to port several useful pieces of code. I have sources of simple mp2 and mp3 decoders in C, which I tried on a bare metal RPi. Both are simple enough to port (<1000 lines of C code) but I didn't try to compile them here as they use 64-bit integers somewhere.

  • Is any of the work that supports this done at the IR level? Just curious if so, could it be a stepping stone to possibly one day having 64bit ints in spin(2?)? I know it's a much harder issue since there aren't types in spin... would just make writing drivers for some sensors that need a lot of higher precision math way easier (pressure sensors seem notorious for this, Melexis' thermal imaging sensors, etc). It's doable using the high 32bit mul in spin now, but so obtuse.

    Cheers

  • @avsa242 said:
    Is any of the work that supports this done at the IR level? Just curious if so, could it be a stepping stone to possibly one day having 64bit ints in spin(2?)? I know it's a much harder issue since there aren't types in spin... would just make writing drivers for some sensors that need a lot of higher precision math way easier (pressure sensors seem notorious for this, Melexis' thermal imaging sensors, etc). It's doable using the high 32bit mul in spin now, but so obtuse.

    Cheers

    There are types in Flexspin's spin2 to some extent, might just need a new type name for it. Or maybe not. not sure. You can however directly call some internal functions like _int64_add to make manual 64 bit ops more readable.

  • ersmithersmith Posts: 5,900
    edited 2022-07-22 18:43

    @avsa242 said:
    Is any of the work that supports this done at the IR level? Just curious if so, could it be a stepping stone to possibly one day having 64bit ints in spin(2?)? I know it's a much harder issue since there aren't types in spin...

    It's done in a language independent way, so in principle one could use it to add 64 bit ints to Spin/Spin2. But as you say, there aren't any types in Spin so it would require some kind of language change.

    Edit to add: flexspin does have a way to add "types" to parameter and variable declarations, but these types are only used in a very limited number of places and generally don't have much effect on the code generation; we can get away with that because everything fits in one register, but for a 64 bit type that would no longer be true.

  • RaymanRayman Posts: 13,805

    Couldn’t you just use pointers to 64 bit int data for Spin functions?

  • @Rayman said:
    Couldn’t you just use pointers to 64 bit int data for Spin functions?

    That's an interesting idea, but it would be slow and handling intermediates would be even worse. For example in A*(B+C) we'd have to allocate a temporary for the B+C, which means a call to the memory allocator. So I think that the solution used in BASIC and C (treating 64 bit numbers as pairs of 32 bit numbers) is probably the right one.

  • pik33pik33 Posts: 2,347
    edited 2022-07-31 10:18

    Flexprop is now unusable.

    It reloads the file from disk at every get focus event so I cannot go out to check the manual without save the file, or what I wrote is lost.
    I tried to switch off this option in the editor settings. The result is pop-up window - "the file (filename) has changed on disk. Reload it?" Whatever I cllick, yes, or no, this window reappears again and I can do nothing except closing the flexprop.


    I tried to replace the executable in the directory to the old, good one and it still works bad while the new executable works OK in the old directory. ?


    What makes the difference is something in src directory. Another "?"

  • @pik33 said:
    Flexprop is now unusable.

    It reloads the file from disk at every get focus event so I cannot go out to check the manual without save the file, or what I wrote is lost.

    Sorry about that, I missed some cases in the file change code. It should be fixed in github now.

    I tried to replace the executable in the directory to the old, good one and it still works bad while the new executable works OK in the old directory. ?

    What makes the difference is something in src directory. Another "?"

    The flexprop executable is just a Tcl interpreter, and it hardly ever changes. The real program is the Tcl/Tk scripts in the src/ directory, mainly gui.tcl.

  • Eric,

    I have noticed a couple issues, not sure how long they have been around. I have a 2019 Mac Book Pro (i7).

    I am running version 5.9.15-beta.

    If I right click on the tab flexprop crashes.
    I cannot open more than 2 Files at a time or the edit screen goes blank.
    When editing a file, anytime I enter a " (Quotation mark) the edit windows flashes with ever keystroke until I type the closing " (Quotation mark).
    I am still occasionally getting that serial error on upload.

    If there is anything I can do / provide for troubleshooting let me know.

  • Eric,

    One more question.

    How do you troubleshoot a failed build when the compiler only says "child killed: SIGABRT"

  • @"Greg LaPolla" said:
    I have noticed a couple issues, not sure how long they have been around. I have a 2019 Mac Book Pro (i7).

    I'm using a fairly old Mac Mini, with a recent-ish MacOS.

    If I right click on the tab flexprop crashes.

    I can't seem to reproduce this. Any time I right click on any part of the tab I get the Cut/Copy/Paste edit menu; which, arguably, should only come up on a right click inside the actual window. Do right clicks inside the window also crash for you?

    I cannot open more than 2 Files at a time or the edit screen goes blank.

    I do sometimes see the screen go blank when a new tab is opened, but it comes back as soon as I do anything (e.g. clicking on another tab). It seems to come and go; I can't reliably get the blank screen. Do you see it all the time, or just sometimes?

    When editing a file, anytime I enter a " (Quotation mark) the edit windows flashes with ever keystroke until I type the closing " (Quotation mark).

    Does this happen in all languages, or just some? In the BASIC test file I edited I saw the screen flash when I enter the first quotation mark and the last quotation mark, but not with any other keystrokes.

    I am still occasionally getting that serial error on upload.

    Yes, that does seem to happen occasionally even on Linux, but it's pretty rare for me. Have you tried adding an explicit "-FIFO 2048" to the loadp2 command line? Or perhaps "-FIFO 512"?

    How do you troubleshoot a failed build when the compiler only says "child killed: SIGABRT"

    Which compiler is doing this? In general I'd try running the same command from a terminal window and seeing if there's any other output.

    Regards,

  • @ersmith said:

    I can't seem to reproduce this. Any time I right click on any part of the tab I get the Cut/Copy/Paste edit menu; which, arguably, should only come up on a right click inside the actual window. Do right clicks inside the window also crash for you?

    It happens randomly, but only happens when clicking on the tab. Within the window it's fine. After a little messing around it seems that if you open 4 files you can make it crash pretty consistently

    Not sure this will help:

    Gregs-MacBook-Pro:flexprop glapolla$ ./flexprop
    objc[7319]: Invalid or prematurely-freed autorelease pool 0x7fd1a100a230.
    Abort trap: 6

    I do sometimes see the screen go blank when a new tab is opened, but it comes back as soon as I do anything (e.g. clicking on another tab). It seems to come and go; I can't reliably get the blank screen. Do you see it all the time, or just sometimes?

    After a little testing, If I click to another tab and then back it seems to fix it. I have been closing the app and re-opening

    Does this happen in all languages, or just some? In the BASIC test file I edited I saw the screen flash when I enter the first quotation mark and the last quotation mark, but not with any other keystrokes.

    So far only in spin2. I have made a habit of just typing double quotations and then filling it in. It appears to only happen when typing the quotes

    Yes, that does seem to happen occasionally even on Linux, but it's pretty rare for me. Have you tried adding an explicit "-FIFO 2048" to the loadp2 command line? Or perhaps "-FIFO 512"?

    I will give these a try as it happens randomly I cannot consistently reproduce it.

    Which compiler is doing this? In general I'd try running the same command from a terminal window and seeing if there's any other output.

    using spin2

  • flexprop (5.9.15-beta) on macos (12.5 Monterey)... When I open a lrage number of .spin2 files (some large, some small), clicking on some of the files TABs does not display that correct file in the editor. The last displayed file's content remains on display. In order to reset and correctly display that file, you must click on other TABS until you find one that it displays the correct file in the editor. At this point, you may be able to click on the original file's TAB to display it correctly. This happened recently when I had 14 .spin2 files open and was comparing compiles on several similar code files.

    Probably not easy to re-create... What can I look for to determine where this issur may be occurring?

    dgately

  • @dgately said:
    flexprop (5.9.15-beta) on macos (12.5 Monterey)... When I open a lrage number of .spin2 files (some large, some small), clicking on some of the files TABs does not display that correct file in the editor. The last displayed file's content remains on display. In order to reset and correctly display that file, you must click on other TABS until you find one that it displays the correct file in the editor. At this point, you may be able to click on the original file's TAB to display it correctly. This happened recently when I had 14 .spin2 files open and was comparing compiles on several similar code files.

    Probably not easy to re-create... What can I look for to determine where this issur may be occurring?

    dgately

    My first guess (if this is new behavior) is to look at the code for checking for file updates. This was added recently and might be causing a delay that's messing something up on MacOS. To disable it, you could try commenting out the two lines:

    bind . <FocusIn> { checkFocusIn %W }
    bind . <FocusOut> { checkFocusOut %W }
    

    near line 1728 of src/gui.tcl. To comment them out, put a number sign in front of each line so that they look like:

    # bind . <FocusIn> { checkFocusIn %W }
    # bind . <FocusOut> { checkFocusOut %W }
    

    If that clears up the problem then we'll at least know where to look.

    Thanks!

  • @ersmith said:

    @dgately said:

    bind . <FocusIn> { checkFocusIn %W }
    bind . <FocusOut> { checkFocusOut %W }
    

    near line 1728 of src/gui.tcl. To comment them out, put a number sign in front of each line so that they look like:

    # bind . <FocusIn> { checkFocusIn %W }
    # bind . <FocusOut> { checkFocusOut %W }
    

    Tried this... No change.
    https://youtube.com/shorts/1FEvcov9vR0

  • @dgately : did older versions of flexprop work correctly for you? Not much has changed lately, so if there's a working version we can probably find what broke pretty quickly. Of course, if this is an old bug that you've just noticed then that's another story :(.

  • @dgately and @"Greg LaPolla" : Google tells me that some other people have had trouble with the notebook widget under MacOS. I've applied what someone claims is a work-around, and things did seem better on my machine (I didn't have the blank tab happen at all, whereas before it would happen from time to time). I've updated github with this fix; I hope it will help you. I've also turned off the quote flashing, which was kind of annoying even when it worked, and unbound the right click menu from everything except the actual text widget.

  • @ersmith said:
    @dgately : did older versions of flexprop work correctly for you? Not much has changed lately, so if there's a working version we can probably find what broke pretty quickly. Of course, if this is an old bug that you've just noticed then that's another story :(.

    Hmm... On GitHub, I went back through the history of gui.tcl changes & checked-out the entire repository for changes in January, April, May and the 2 most-recent guid.tcl changes. Each time (I "make install"), i could not get the issue to appear. When I go back to the latest sources from GitHub, "make install", I can re-create the issue. I'll keep trying to re-create with older sources.

  • @dgately said:

    @ersmith said:
    @dgately : did older versions of flexprop work correctly for you? Not much has changed lately, so if there's a working version we can probably find what broke pretty quickly. Of course, if this is an old bug that you've just noticed then that's another story :(.

    Hmm... On GitHub, I went back through the history of gui.tcl changes & checked-out the entire repository for changes in January, April, May and the 2 most-recent guid.tcl changes. Each time (I "make install"), i could not get the issue to appear. When I go back to the latest sources from GitHub, "make install", I can re-create the issue. I'll keep trying to re-create with older sources.

    Look up the git bisect feature - it will help you check out old versions in optimally-sized steps to find the faulty commit as quickly as possible.

  • evanhevanh Posts: 15,126

    And git log for listing all the commits to select from with bisect.

  • I now think that going back through git history may not be productive, because (I think) the bug is in Tcl/Tk itself. It sounds like this bug https://core.tcl-lang.org/tk/tktview/91ca777b4df21a42caf31deab5fac49e6b179416 In the discussion someone posted a work-around for older tcl/tk versions, and I've applied it in the current FlexProp github. Does this help things for MacOS users? (It seems to on my Mac mini, but then the frequency was never very high for me.)

    .

  • @ersmith said:
    I now think that going back through git history may not be productive, because (I think) the bug is in Tcl/Tk itself. It sounds like this bug https://core.tcl-lang.org/tk/tktview/91ca777b4df21a42caf31deab5fac49e6b179416 In the discussion someone posted a work-around for older tcl/tk versions, and I've applied it in the current FlexProp github. Does this help things for MacOS users? (It seems to on my Mac mini, but then the frequency was never very high for me.)

    This appears to fix the issue on my system (macOS 12.5)!

    Thanks, Eric!

  • @evanh said:
    And git log for listing all the commits to select from with bisect.

    I find it convenient to leave a copy of gitk (the only GUI program I ever use with Git) open on the repository whenever I'm doing anything more complicated than git commit.

  • @dgately said:

    @ersmith said:
    I now think that going back through git history may not be productive, because (I think) the bug is in Tcl/Tk itself. It sounds like this bug https://core.tcl-lang.org/tk/tktview/91ca777b4df21a42caf31deab5fac49e6b179416 In the discussion someone posted a work-around for older tcl/tk versions, and I've applied it in the current FlexProp github. Does this help things for MacOS users? (It seems to on my Mac mini, but then the frequency was never very high for me.)

    This appears to fix the issue on my system (macOS 12.5)!

    Thanks for checking this, Dennis!

Sign In or Register to comment.