Re: [bp-dev] A sneak peak at the future of Bol Processor

[Anthony K. <mai...@an...>]

Hello Bernard and Rainer,

It's wonderful to see the additional exciting developments this morning. 
  Thanks Rainer!  You beat me to compiling for Windows.  I have a 
cross-compiler installed on my Mac and was planning to try that out 
soon.  I'm so glad to hear that it worked for you!  This new portability 
is so amazing.  It motivates me to want to finish the work I started and 
make BP console truly usable for music-making!

Alas, I will be busy with other things for at least the next few days. :(

A few more comments below.

On 7/6/20, 11:57 AM, Bernard Bel wrote:

> You are probably right regarding OVH's limitations. I guess they'll
> suggest a dedicated server at a monthly price I can't afford. ;-)

My web hosting service provides all of the standard Linux dev tools we 
need (GCC, git, PHP, MySQL, and Apache).  If it would be helpful, I can 
set up a sandbox environment for developing a BP web app and give you 
access to it, Bernard.  The web front end would have to be 
password-protected though since I don't think we can trust BP to not be 
exploitable at this point.

> My motivation has been to take advantages of calling BP procedures via
> PHP instructions. In this way, part of the input could be prepared in
> advance — even using database storage — and the output could also be
> processed in various ways. For instance, Csound orchestras, definitions
> of sound-object prototypes etc., anything that contains more information
> that we can handle on a single line could be maintained in database
> tables. I admit that this motivation has been naively prompted by my
> current activity with databases and web.

I think a web interface to BP would be very helpful to allow curious 
individuals to try out some of BP's unique concepts before "committing" 
to installing it on their own machines.

> So, having little hope that OVH grants me superuser's rights on a shared
> hosting, I tried something else and it "almost" worked: using MAMP Pro
> on my personal computer.
>
> After activating gcc I was able to compile an run a tiny program that
> says "Hello". Then I compiled BP using the Makefile, and it did compile,
> yielding "bp" or 875 Kb announced as "Unix executable file". It did not
> work when called from PHP:
>
> <?php
> $cmd = "./bp -v";
> exec($cmd,$o);
> print_r($o);
> ?>
>
> "bp32" also did not run. However both run fine when called via Terminal.
> This means that I have come as far as compiling a correct version of BP
> under PHP on a MAMP server. Going beyond this step probably requires
> working on MAMP setup - still a bit obscure to me. I'll manage it; :-)

Hmmm... strange that can't run a macOS binary on macOS just because it 
is called from PHP.  I see that your script uses "./bp".  Are the PHP 
script and bp in the same directory?  You might try using a full 
pathname to bp.  Alternatively, try copying the bp binary to somewhere 
on your path (or the web server's CGI bin folder?) and removing the 
"./".  Also, "-v" is not a valid option for BP console.  I think you 
want "--version".

> It is an extremely pleasant surprise that this C code is really
> cross-platform. This is probably the effect of systematic programming
> when migrating BP through upgrades of MacOS. A major migration (which
> had taken me several months full time) was the one from 68K to PPC circa
> 1994. This forced me to clean-up many dependencies, unknowingly
> preparing the code for later upgrades, among which Anthony's migration
> to MacOS X which was also a big issue.

Yes, the fact that it compiled on an ARM platform makes me think we 
won't have much trouble compiling for Android either.  Imagine being 
able to play with BP on your tablet or smartphone! :)

> It's wonderful to hear that exec time is much smaller via command-line
> calls, even though large amounts of RAM may still be hired for storing
> items. This indicates that the strategy of minimizing memory usage that
> was so critical in the 1990s now pays off again. This is an advantage of
> poverty ;-)

I suspect the speedup is mostly due to the fact that BP console doesn't 
have to poll for events like the Mac Classic & Carbon versions did. 
Every time BP2 calls GetNextEvent(waitTime) creates a delay.

The low memory usage could be an advantage on mobile and embedded 
devices though.  (One can imagine that, someday, someone might create an 
interactive multimedia installation using BP on a Raspberry Pi or even 
Arduino-like device).

> I agree with the suggestion that building a standalone application BP4
> with its proper GUI should take full advantage of BP3's command-line
> features. This is a reason why I am looking for some way of storing
> large pieces of data. Once it works with a MySQL file it will be easy to
> translate the process to the standalone app. My understanding is that
> the GUI would be similar to the body of a car with a unique engine.
>
> Bernard

Well, on to far less interesting tasks for now. ;-)

Cheers for the progress we've made though!

Anthony