QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: random1 on October 11, 2021, 10:34:21 pm

Title: It's time for a new editor/IDE for qb64
Post by: random1 on October 11, 2021, 10:34:21 pm

Hi all

I have a program that's size is over 8,000kb including a BI file.  The main source
makes up around 20K lines of code with the bi file making up the rest.  The QB64
editor is useless.  When I click a on a drop down menu it can take up to 5 seconds
to respond.  To do something like move to a sub it can also take several seconds
to update the screen.  When I try to add to the code I get delays after say, typing
3 characters   The Backspace is a nightmare, I press the back space, nothing happens
and then it might delete 50 characters, etc.....
I tried Dav's IDE but it also has problems.  Both work fine with smaller .bas files
but not a project this size.
I know there has been talk here about updating the qb64 editor or maybe adding a
modern IDE. 
My question is, is there another IDE that works well for qb64?  I tried notepad++ and
Geany's IDE.  Both manage the 7,000kb without issue but I was not able to customize
them to suite me.
Anyway, any suggestions would be appreciated.

Thanks
R1     

Title: Re: It's time for a new editor/IDE for qb64
Post by: Pete on October 11, 2021, 10:43:22 pm

Turn syntax checking off.

Pete

Title: Re: It's time for a new editor/IDE for qb64
Post by: random1 on October 12, 2021, 12:56:19 am

Pete

I ended up getting rid of the .BI file and placing the contents into the main programs .bas.
The bi file contained mostly strings of converted images of which I was able to get rid of a
few which were no longer needed.  This seemed to fix my problem and everything seems
to be running as expected.  The main program .bas is now 7,575 KB.  I expected the syntax
checking was part of the problem, made worse by the size of the BI file.  Turning it off had
no real effect, getting rid of the bi file did.

R1

Title: Re: It's time for a new editor/IDE for qb64
Post by: Pete on October 12, 2021, 01:26:37 am

I worked in QB64 during the days when compilation speeds took  probably five times longer than they do today. Since I was working a some project of up to 90,000 lines of code, I dealt with the IDE lag and slow compilation speed by breaking the programs up into several individual modules. This is similar to you dropping the bi file. For the shared routines, I wrote a script to load them. On the few occasions I had to compile the entire program, I'd hit F5 and go out for lunch. Seriously, it took over 15-minutes to finish. I'm certainly glad Rob made a lot of headway since then. Ass for the syntax checking, I notice lag in most routines starting around 8,000 lines of code, but definitely by 15,000 it becomes annoying enough that I shut it off. The only other trick is to put new subs at the front, so the checker gets finished sooner.

Pete

Title: Re: It's time for a new editor/IDE for qb64
Post by: RhoSigma on October 12, 2021, 02:19:52 am

Quote from: random1 on October 11, 2021, 10:34:21 pm

....  I tried notepad++ and Geany's IDE.  Both manage the 7,000kb without issue but I was not able to customize them to suite me.

If you not did already in the past, please follow the link in my signature below. On that page scroll down approx. half a weel spin to get to the "Bonus Stuff Section", from there download the NppThemesQB.7z archive. This archive contains all necessary files to get syntax highlighting and command shortcuts to call the QB64 compiler directly from within Notepad++, the HTML file(s) give you step by step instructions on how it works and how to install. If you need assistence, then let me know.

Title: Re: It's time for a new editor/IDE for qb64
Post by: Pete on October 12, 2021, 10:52:03 am

Joan Jett sang it best, "I Love Rock'n Rho"

Pete

Title: Re: It's time for a new editor/IDE for qb64
Post by: SMcNeill on October 12, 2021, 11:41:31 am

The problem with the IDE is everyone wants it to do everything...  Formatting, auto-spacing, syntax checking, text colorization,   Key word completion, all upper case keywords...  No wait, let's scratch that and make those optional.  Optional underscores, debugging features, option explicit checking...  And on and on and on!!

And all of this built over a framework that translates your code to c and writes it to disk *with every keystroke*!

It all leads to lag in the IDE as you describe, and the longer the code, the greater the lag.

And honestly, you can just expect the issue to grow worse as ever more features are added and inserted into the IDE.  Folks want it to do EVERYTHING, but as more and more gets added, the upper size limit decreases with which you can realistically do ANYTHING.  Which is why I've been migrating over to a secondary IDE for large projects more and more with each version released.  😉

Title: Re: It's time for a new editor/IDE for qb64
Post by: Pete on October 12, 2021, 12:04:27 pm

You reply made me think a bit more about the situation, and now I'm more in favor of a custom configuration that would support multiple IDE's. I have Paint.net set up that way. I just click the desktop icon for the particular set up I want, and it loads with all the pre-set features I need for a particular type of project.

IDE hotkeys to do things like turn syntax checking off, would be nice, too. Yep, we want it all! It's a mixed bag. We programmers all hit a point where we'd like to tell others to go take a flying flock, but then we realize, hmmmm, it would be neat to add something more, and then we add it, anyway.

Any IDEa if the IDE does use a single string to hold all the code?

Pete

Title: Re: It's time for a new editor/IDE for qb64
Post by: doppler on October 12, 2021, 12:16:00 pm

Reminds me of the Dr Seuss story of the moose and his antlers.  All the creatures wanted to live on the antlers (re: IDE/UI).  The moose complained it was not a good idea to live on his antlers.  They ignored the moose.  After rut season the moose threw off his antlers in front of a hunter.  Last scene is all the animals where mounted with the antlers in the hunters home.

Moral of the story: "Stop asking for IDE changes, otherwise you will be hanging from a hunters home wall."

Title: Re: It's time for a new editor/IDE for qb64
Post by: SMcNeill on October 12, 2021, 12:25:43 pm

Quote from: Pete on October 12, 2021, 12:04:27 pm

You reply made me think a bit more about the situation, and now I'm more in favor of a custom configuration that would support multiple IDE's. I have Paint.net set up that way. I just click the desktop icon for the particular set up I want, and it loads with all the pre-set features I need for a particular type of project.

IDE hotkeys to do things like turn syntax checking off, would be nice, too. Yep, we want it all! It's a mixed bag. We programmers all hit a point where we'd like to tell others to go take a flying flock, but then we realize, hmmmm, it would be neat to add something more, and then we add it, anyway.

Any IDEa if the IDE does use a single string to hold all the code?

Pete

Yep.  All stored in idet$

Title: Re: It's time for a new editor/IDE for qb64
Post by: Petr on October 12, 2021, 01:00:21 pm

@random1

The problem is by no means in the IDE. Look for the problem between the keyboard and the chair!

The path you are looking for is to add binaries after the end of the EXE file, on the one hand you do not burden the IDE and mainly you can add a bunch of images and build the whole program at a higher level. This is an even better method than adding images like DATA. Now what form he chose. Hexadecimal description of each point? This is brutal nonsense. Yeah, I used to do that a long time ago too! But I say, it's stupid! Or Base64? This is a far more elegant way!

Everything I describe here can be found on the forum.

Title: Re: It's time for a new editor/IDE for qb64
Post by: Aurel on October 12, 2021, 01:18:56 pm

Quote

The main source
makes up around 20K lines of code with the bi file making up the rest.

wow...
i tried once scintilla with 24000 lines of code (cc basic)
well i think that DAV iDE should work ..he just need to increase text buffer that can hold such a big file
I will see if my AurelEdit can do that  ???

Title: Re: It's time for a new editor/IDE for qb64
Post by: Pete on October 12, 2021, 01:27:41 pm

@SMcNeill  I thought so. Thanks for confirming. I wonder if Rob knew it's faster to use MID$() to write to a single string than to split it, add to it, and rejoin it? I mean it's much faster to use MID$(). I experimented with it one, using a C application for a C/C++ word processor app. I was quite surprised at the speed difference.

It would be interesting to know the differences between methods to code an IDE, in regard to using arrays vs RA files, single string method, or some other method. WPs are similar to IDEs, but word wrap is a whole new element. With an IDE, it's more about how long of a line is allowed. So if anyone was going to tackle some new IDE, it would be wise to know the answer to these questions, a well as learn from any of the challenges the current method presents. I mean I now love the QB64 IDE, but only for projects less than 10,000 lines when syntax checking is on.

Pete

Title: Re: It's time for a new editor/IDE for qb64
Post by: FellippeHeitor on October 12, 2021, 02:13:30 pm

Plenty of powerful IDEs out there, QB64 can be used solely as a compiler. For command-line compilation switches, type qb64 --help in the console.

Here's a feature-less IDE from back in the day, enjoy all ye nostalgics: http://qb64.org/historical_qb64/qb64v0954-win.7z (http://qb64.org/historical_qb64/qb64v0954-win.7z)

Title: Re: It's time for a new editor/IDE for qb64
Post by: Pete on October 12, 2021, 02:53:56 pm

A nice smaller hobby project would be to code an app that compiles from an external editor. SENDKEYS is great for this in Windows. With SENDKEYS, you can create a nice little app you click to save the contents in an editor like notepad, compile it, and run it.

Pete

Title: Re: It's time for a new editor/IDE for qb64
Post by: Aurel on October 12, 2021, 03:07:51 pm

I cannot find bigger code ..probably there is somewhere on github
i found one of tcl interpreter called jim it is 12000 loc
see image , before that i increase buffer to 1 500 000 chars
and load fine that large code .
if i found bigger code i will let you know

Title: Re: It's time for a new editor/IDE for qb64
Post by: random1 on October 12, 2021, 08:39:23 pm

Hi all

I first started using the BI file just to move stuff out of the main bas file to make mods easier
and keep things sorted.  The normal way was to store all the image strings into a sub called (images). 
where each image has it's own shared name.
When the program first starts all the image strings are loaded by running the sub IMAGES.  Now they
can be loaded at any time using something like the code below.  BINPICS converts the string back into
a .png image then it's loaded using _LOADIMAGE and _PUTIMAGE. 

The BI file contained all the dim shared statements and the image strings

Code: QB64: [Select]

1. DIM SHARED PIC1$
2. DIM SHARED PICTURE1$
3. DIM SHARED SPLASH1$  'stored in the image sub
4.  
5. 'CODE TO DISPLAY IMAGE
6. PIC1$=SPLASH1$
7. BINPICS  '<- CONVERTS IMAGE STRING TO .PNG IMAGE
8. I = _LOADIMAGE(PICTURE1$)
9. _PUTIMAGE (1,1), I
10. IF I < -1 THEN _FREEIMAGE I
11. KILL PICTURE1$    
12.  

Like I said using the BI file was not the norm, it was added way back as a means to manage my
images files outside the main bas code.  This had little effect when the BI was very small but over
time it grew and grew.  All I needed was go back to my normal methods which was already planned
when the project was finished.  Anyway, problem fixed. 

R1

Title: Re: It's time for a new editor/IDE for qb64
Post by: random1 on October 12, 2021, 08:48:50 pm

I am in my 8th decade of walking around on this earth and while I may not
be as sharp as I once was,  I can still get around.  I wrote my first basic
program back in 1982 for a digital electronics class in college.  We did not
have a computer lab so all code it was written using pen and paper.   

I still think we need a modern IDE in order to make qb64 more attractive. 
I think the current one is the reason qb64 goes mostly unnoticed in the
programming world.  We can have both so it's not like were loosing anything.

R1

Text Only | Text with Attachments