Shop OBEX P1 Docs P2 Docs Learn Events
Would this work for an IDE? - Page 5 — Parallax Forums

Would this work for an IDE?

1235»

Comments

  • RaymanRayman Posts: 14,572
    I kinda got hung up on whether to support line numbers or not... Then realized might be over my head there... Would have to just copy Femto…
  • jmgjmg Posts: 15,171
    David Betz wrote: »
    jmg wrote: »
    David Betz wrote: »
    Rayman wrote: »
    I was contemplating Femto-Basic 2...

    That would be easy to make self hosted...
    I'm working on something like that. ..

    Sounds interesting..
    Don't get too excited. This work is derived from various other BASIC interpreters that I wrote for P1. I'd like to try to get it to generate PASM instead of byte code this time though. I don't have any illusions that people will actually use this thing. It's just a fun project at present. I'll try to make it easy to add functions to interface to hardware though so it would be possible to use it in some of the same ways that Femto BASIC was used. However, Taqoz is much better for that. Also, as has been mentioned elsewhere, the P2 has enough RAM that more standard languages may be possible like MicroPython, Javascript, or Lua.

    How does that compare with ersmith's Basic or Bean's Basic ?
  • jmg wrote: »
    David Betz wrote: »
    jmg wrote: »
    David Betz wrote: »
    Rayman wrote: »
    I was contemplating Femto-Basic 2...

    That would be easy to make self hosted...
    I'm working on something like that. ..

    Sounds interesting..
    Don't get too excited. This work is derived from various other BASIC interpreters that I wrote for P1. I'd like to try to get it to generate PASM instead of byte code this time though. I don't have any illusions that people will actually use this thing. It's just a fun project at present. I'll try to make it easy to add functions to interface to hardware though so it would be possible to use it in some of the same ways that Femto BASIC was used. However, Taqoz is much better for that. Also, as has been mentioned elsewhere, the P2 has enough RAM that more standard languages may be possible like MicroPython, Javascript, or Lua.

    How does that compare with ersmith's Basic or Bean's Basic ?
    Mine is intended to run on the P2 not on a PC.

  • Hey, a basic stamp on steroids'.

    Mike
  • TorTor Posts: 2,010
    edited 2020-04-08 11:51
    Yes swap file is normally part of windows. If anything Linux copied the idea.
    Er, no. Linux took it from Unix, and from the best method used there. Window's "swap" file was rather primitive compared to the *nix way, and still is to some degree I believe. As far as I know there's never been any idea in Windows which was later copied into Linux or Unix. There are some compatibility tools - the ability to mount Windows filesystems, and the Wine project to execute Windows binaries.

    As for a RAM drive - it's possible to have RAM not generally available for the OS and use that for a RAM drive.

  • RaymanRayman Posts: 14,572
    I sure hope Chip didn't start this thread due to some issue updating Prop Tool...
    I know in the past it was said that the Prop Tool could not be updated due to some third party component...

    I'm getting by with my SpinEdit, but it's nowhere near as polished as Prop Tool...
  • Hey, a basic stamp on steroids.
    I suggested to Chip that after the P2 is fully up and running (with x-platform tools and a substantial library to get new users up and working quickly) that it might be fun for him, and appreciated by many Parallax customers, to create a P2BASIC interpreter -- a BASIC Stamp on steroids.
  • JonnyMac wrote: »
    Hey, a basic stamp on steroids.
    I suggested to Chip that after the P2 is fully up and running (with x-platform tools and a substantial library to get new users up and working quickly) that it might be fun for him, and appreciated by many Parallax customers, to create a P2BASIC interpreter -- a BASIC Stamp on steroids.
    Yeah, that would be cool. Even a P1BASIC interpreter could have been a big step up from the BS2. There was a SpinStamp for a while but I don't think they ever developed a version of PBASIC that worked with it. I still have a couple that I'm about to give away.

  • If you want to develop on your windows PC, but still be cross platform. Then you probably want to get msys2 ( https://www.msys2.org ).

    MSYS2 only compiles for MS Windows?
    What addition steps are necessary to produce a binary for other OS?
  • Rayman wrote: »
    I kinda got hung up on whether to support line numbers or not... Then realized might be over my head there... Would have to just copy Femto…

    Line numbers solve the problem of needing a full-screen editor, which creates a lot of hardware dependencies. They allow you to make sensible program edits with only a dumb terminal that understands no special character except ENTER. They are also a trap of course, but it is line numbers that made it possible to implement Tiny Basic in as little as 1K of program code. (I once seriously considered porting Tiny Basic to the P1, but feature creep quickly collided with reality.)
  • localroger wrote: »
    Rayman wrote: »
    I kinda got hung up on whether to support line numbers or not... Then realized might be over my head there... Would have to just copy Femto…

    Line numbers solve the problem of needing a full-screen editor, which creates a lot of hardware dependencies. They allow you to make sensible program edits with only a dumb terminal that understands no special character except ENTER. They are also a trap of course, but it is line numbers that made it possible to implement Tiny Basic in as little as 1K of program code. (I once seriously considered porting Tiny Basic to the P1, but feature creep quickly collided with reality.)
    I used a line number based editor for my P1 BASIC interpreters but the language didn't use the line numbers. It had symbolic labels. The editor could have been replaced by a GUI but I never wrote one.

  • kg1,
    Sorry, I was wrong, it appears you can't cross compile to non-windows platforms with MSYS2, but the source code you write and compile with it should compile without issues on other platforms with gcc (or compatible) toolchains. For OpenSpin I only compile the windows binaries myself, and David Zemon's team city stuff compiles the other platforms from the same source.
  • @Roy Eltham Thank you Roy. I have some very old Microsoft C code which I will experiment with in MSYS2 then GCC.
  • David Betz wrote: »
    localroger wrote: »
    Rayman wrote: »
    I kinda got hung up on whether to support line numbers or not... Then realized might be over my head there... Would have to just copy Femto…

    Line numbers solve the problem of needing a full-screen editor, which creates a lot of hardware dependencies. They allow you to make sensible program edits with only a dumb terminal that understands no special character except ENTER. They are also a trap of course, but it is line numbers that made it possible to implement Tiny Basic in as little as 1K of program code. (I once seriously considered porting Tiny Basic to the P1, but feature creep quickly collided with reality.)
    I used a line number based editor for my P1 BASIC interpreters but the language didn't use the line numbers. It had symbolic labels. The editor could have been replaced by a GUI but I never wrote one.

    Separating the line numbers from the function of jump and call targets helps a lot with the inevitable need for a renumbering function, but it also means you're not using mnemonic line numbers so targeting parts of the program for listing and editing becomes more arbitrary.
  • localroger wrote: »
    David Betz wrote: »
    localroger wrote: »
    Rayman wrote: »
    I kinda got hung up on whether to support line numbers or not... Then realized might be over my head there... Would have to just copy Femto…

    Line numbers solve the problem of needing a full-screen editor, which creates a lot of hardware dependencies. They allow you to make sensible program edits with only a dumb terminal that understands no special character except ENTER. They are also a trap of course, but it is line numbers that made it possible to implement Tiny Basic in as little as 1K of program code. (I once seriously considered porting Tiny Basic to the P1, but feature creep quickly collided with reality.)
    I used a line number based editor for my P1 BASIC interpreters but the language didn't use the line numbers. It had symbolic labels. The editor could have been replaced by a GUI but I never wrote one.

    Separating the line numbers from the function of jump and call targets helps a lot with the inevitable need for a renumbering function, but it also means you're not using mnemonic line numbers so targeting parts of the program for listing and editing becomes more arbitrary.
    True. I guess you could still use ranges of line numbers to partition your program even though they can't be used as GOTO targets. I guess it also would be pretty easy for me to allow line numbers for GOTO as well. One problem though is that I don't have any concept of GOSUB. All subroutines/functions are named and can take parameters and return a value. I've tried to stick with VB syntax where I can but I can't say I like it very much.

Sign In or Register to comment.