<solved> QB64 without its IDE GUI ?

[Jack]

thanks Steve  
that worked, like someone else I renamed it qb64pe-cli after compiling it to source directory and then moving it to the main QB64 folder because otherwise it doesn't find the internal folder among other things

[Fifi]

@Fifi. just for information. I compile qb64pe 3.5.0 with the -Os option and I get :

qb64pe = 5,6 Mio

qb64pe_cli = 3,1 Mio

I renamed qb64pe to qb64pe_cli for the version without editor.

good tip SMcNeill.

Hi Coolman,
II was able to do a clean install of macOS Catalina on my second iMac 27 i5 then with the latest Brew, Xcode 10.4 and Curl 7.87.0 and  qb64pe 3.5.0 finally installed on one of my systems.
So on macOS Catalina the sizes are: qb64pe normal install: 8468344b (8.5MB), qb64pe compiled with -Os: 5956504b (5.9MB) and qb64pe without the IDE and compiled with -Os: 3 393176b (3.4 MB).
So in order to save as much disk space as possible I need to find out what files I can delete from the folder where I put the qb64pe without its IDE to run smoothly (I guess I can delete the Wiki folder and maybe other files not used with this version).
I'll let you know when I'm satisfied.
Cheers.
Fifi

[Coolman]

hello @Fifi, developers should know which directories and files can be removed to use the unedited version. if someone can give the answer, that would be cool. i even think that offering this lighter version in the github could attract many developers. that said, the whole qb64pe directory is about 81.3 mb, which is reasonable. i'm testing with geany as editor and everything works fine. i use geany extensively with many languages (freebasic, freepascal, python, C, x11basic, yabasic, bacon, brandy basic, ada. i even installed rust), it's cool to be able to use qb64 with this editor...

[mnrvovrfc]

I don't get the movement to make QB64PE like Freebasic. Is the IDE really that bad?

Just use -o and -x switches with the regular QB64PE executable. Why so much work only to remove what is not needed, to save a few megabytes on a 64-bit system? You guys are behaving as if we had to deal with QB64 in its early days while it used SDL for images and music. Back then it wasn't possible to change the EXE file destination or change the EXE file name, had to do it with a batch file. Also had to deal with the "SCREEN 0" for QB64's messages and maybe if it wrote "stderr" as a file to the directory it was married to.

What if you need help with a keyword and you're not sure about the syntax? Do you just fire up the greedy web browser into QB64PE Wiki and look it up? Yeah I know, the help system in the IDE is clunky but it's a far cry from what was in QuickBASIC, and it was said M$ sold a lot of copies of QuickBASIC largely because it had better help than almost anything else on the programming system market at its time.

Very few persons do what I do: load the help text file directly into the editor I happen to be using, and try to ignore the pretty-print nonsense which makes things harder to read.

On Linux I use Pluma and any other text editor with the same codebase, a few times Geany, on KDE only Kate, and I run "qb64pe" executable on a separate open terminal. It doesn't bother me typing in the command, with the right name of the BASIC source file.

It's not going to be any different for whoever calls himself/herself "developer" and dismisses BASIC anyway for silly reasons. QB64PE has a lot of competition only for the sake of creating games. Coolman mentioned one of them already which I think is plain disgusting, either that one or Haskell.

[Kernelpanic]

In SuSE-Linux, my editor for C and Java in KDE was jedit. For me the best editor on Linux for that.

And for HTML the Quanta Plus. The Homesite clone on Linux, and just as so good. Unfortunately, it has not been developed further since 2009. - I once had a short email exchange with the developer . . . really to bad about the editor, like the Homesite, which was sabotaged first by the buyer Macromedia and then by Adobe in order to force their own crap. Keyword: Dreamweaver!

[Kernelpanic]

Ok, also Wikipedia has no a correct picture of Homesite. That is Homesite around 1988 (latest version 5.5):

[Fifi]

I don't get the movement to make QB64PE like Freebasic. Is the IDE really that bad?

Hi mnrvovrfc

I don't think there is any movement from anyone to make qb64pe like fb. And no, the IDE isn't that bad but on macOS where it's almost unusable without the MouseWheel.

Just use -o and -x switches with the regular QB64PE executable. Why so much work only to remove what is not needed, to save a few megabytes on a 64-bit system? 

Of course I use the command line with the -x-q -o switches. 

However, my personal need for a long time to separate the compiler from the IDE is for a very specific project where the compiler is on an embedded system that will fit on a chipset.

So every byte saved will be a real plus for this very special project.

At the same time, the devs of this specific project will continue to use the complete qb64pe with its iDE but on their development machines (whatever the OS of their choice) and only the finished sources will be sent to the project to be compiled and executed "on the fly".

I just can't tell you more, but this is the principle.

But now that it's so easy to separate the IDE from the compiler, wouldn't it be a good idea if these two parts were effectively separated (the IDE and the compiler) and the two executables were called one else: ie. the IDE calls the compiler to pass it the source to compile (and run if needed) and conversely if needed the compiler calls the IDE to send it back the error codes (and the line number of the problem)?

This would have multiple advantages:
a) although the whole project would still be delivered in its entirety (IDE and compiler in the same package), it would still leave the choice to the users to use another editor that they master or prefer. So this will not distort the image or the spirit of the initial QB64 project.
b) it would also make it possible for others to create special tools where only the compiler is used, like in my case.
c) this would place the compiler like any other standard compiler (eg. GCC, C++, etc) and I imagine would open a very large audience.

Also, I don't think it's a huge development to make since the two parts are well and truly separate.

But it's up to the developers of the qb64pe project to decide even if some of the old team categorically opposed it for no real reason (especially since the separation already exists).

Moreover, as a complete package, it would continue to differentiate qb64pe from other BASIC languages like FB or others which precisely don't have an IDE.

Just my two cents.
Cheers.
Fifi

[DSMan195276]

However, my personal need for a long time to separate the compiler from the IDE is for a very specific project where the compiler is on an embedded system that will fit on a chipset.

So every byte saved will be a real plus for this very special project.

I'm going to be 100% honest with you, QB64-PE does not sound like the right tool for this. That said, in such an environment why wouldn't you compile the executable elsewhere and just place the executable on the target machine? There's really only disadvantages to waiting to compile the code when it needs to be run. Additionally, you're paying for the space for more than just QB64-PE since it also needs a C++ compiler (which you otherwise might not need). If space is constrained to the point where the ~3MB saved by not having the IDE is a big deal, it seems like you'd be much better off just not having the compiler on the machine at all and save a whole bunch more space.

If the issue is compatibility of the executable then what you might want is for QB64-PE to make it easier to cross-compile your executable for that embedded platform. Then you could compile the executable on a separate machine and send only the executable to the minimal machine it will run on.

But now that it's so easy to separate the IDE from the compiler, wouldn't it be a good idea if these two parts were effectively separated (the IDE and the compiler) and the two executables were called one else: ie. the IDE calls the compiler to pass it the source to compile (and run if needed) and conversely if needed the compiler calls the IDE to send it back the error codes (and the line number of the problem)?

Personally I like this idea (and from a user perspective they wouldn't even need to notice), but IMO it's unrealistic that it will happen soon. It's easy enough to create a compiler lacking the IDE, it is _not_ currently possible to create the IDE without the compiler. That would require a lot more work, and honestly there's just too much to do as it is.

[mnrvovrfc]

Making the IDE independent from the compiler means creating an interpreter, a darned good one like M$ wrote which became separated from QuickBASIC, and some people refuse to give it up.

@Fifi wish you the best of success in your project. You have a vision and determined to make it work. Sadly I haven't read many other Macintosh users as serious and passionate about their work with those computers. Would like to break past the memes against ApCo to the tune of, "How much did it cost you?" Too much whining about free software not available on their platform on one side, and a lot of false bragging about being able to pay for something on the other side, in the forum about music software I belonged to many years ago and had to abandon.