bolprocessor-devel — Bol Processor developer discussion list

Re: [bp-dev] Windows compatibility of the PHP interface

[Bernard B. <ber...@gm...>]

Since you are getting image and sound at the moment, you may try the 
last procedure: importing a MIDI file into a sound-object.

See "Create or replace MIDI codes loading a MIDI file..." at the boootom 
of the page. Click "Choose File", select a file, then "send". You can 
try this Xmas song which I uploaded as "this_song.mid" because it has 
various instruments and several tracks. I am confident Windows will play 
it correctly.

Then change its duration, for instance down to 7 beats to play it 
faster. Other buttons suppress evenst such as pitchbend or volume but 
that's not audible on this file.

Now we can move to more constructive tasks :-)

Bernard

Re: [bp-dev] Windows compatibility of the PHP interface

[Bernard B. <ber...@gm...>]

Wow, that's the way!  Even if it looks clumsy, we're lucky it works. And 
no problem on a Mac since those backslashes never show up!

With the updated prototype_image.php I have just sent you, everything 
should work now. I updated the upload.

Maybe later we find a more elegant way of dealing with this, but for the 
time being we do have a framework that runs on both plateforms, and the 
future code won't need to contain any bizarre signs!

Congratulations for this fix :-)

Bernard

Rainer Schuetz wrote on 01/08/2020 22:30:
> I sent an email with attachments and the ml-server blocked again, I 
> resend with text only for the big image:
>
>> On 1. Aug 2020, at 22:24, Rainer Schuetz <rs...@ba... 
>> <mailto:rs...@ba...>> wrote:
>>
>>
>>
>>> On 1. Aug 2020, at 21:07, Bernard Bel <ber...@gm... 
>>> <mailto:ber...@gm...>> wrote:
>>>
>>> Well… At the moment I used DIRECTORY_SEPARATOR everywhere, but I 
>>> don't understand where it should be used and where plain slashes are 
>>> necessay! There seems to be no relevant documentation on this topic…
>>
>> I can’t claim understanding, but as an input to be considered: when 
>> php speaks with the system, it seems to use or receive backslash. The 
>> whole backslash thingy entered the picture because you used that 
>> document root and getcwd() in the beginning. I continued using 
>> getcwd() and didn’t think about how subsequent operations would 
>> handle this. I took for granted that php would know when it “speaks 
>> to the web” and converts backslashes it got from “speaking to 
>> windows” to slashes once it outputs stuff. That was wrong, but I also 
>> didn’t follow how you designed the paths you would be using when you 
>> made php “speak to the web”/generate html. I guess once they’re 
>> declared variables, they’re strings and php doesn’t think about 
>> converting them any more.
>>
>>
>>> Maybe normal slashes everywhere would do the job?
>>
>> Yes! But what you did with “define SLASH /“ wasn’t enough, because 
>> the “bp_xyz” variables I suggested still receive backslashes from 
>> getcwd(), and you seem still to use those ones as well. Also - what I 
>> had to learn the hard way - unlike variable declarations a subsequent 
>> “define” seems not to override a preceding one - it has to be 
>> commented out. To get all over slashes I did a quick and clumsy 
>> replace for each individual variable following your model for “root”, 
>> and then everything flipped - and the links work!!! Windows even 
>> plays the MIDI-file without any MIDI-configuration on my part!!! With 
>> these settings the test links worked on Windows (I just tried two or 
>> three):
>>
>> <Screenshot 2020-08-01 at 22.20.50.png>
>
>
> // define('SLASH',DIRECTORY_SEPARATOR);
> define('SLASH',"/");
>
> $root = $_SERVER['DOCUMENT_ROOT'].SLASH;
> $root = str_replace("\\",SLASH,$root);
> $root = str_replace(SLASH,SLASH,$root);
>
> // take bottom-up approach
> $bp_php_path = getcwd();
> $bp_application_path = dirname($bp_php_path);
> $bp_parent_path = dirname($bp_application_path);
>
> $bp_home_dir = str_replace($bp_parent_path.SLASH,'',$bp_application_path);
> $part_dir = str_replace($bp_parent_path,'',$bp_php_path);
> $path_above = str_replace($root,'',$bp_php_path);
> $path_above = str_replace($part_dir,'',$path_above);
>
>
> $bp_php_path = str_replace("\\",SLASH,$bp_php_path);
> $bp_application_path = str_replace("\\",SLASH,$bp_application_path);
> $bp_parent_path = str_replace("\\",SLASH,$bp_parent_path);
> $bp_home_dir = str_replace("\\",SLASH,$bp_home_dir);
> $part_dir = str_replace("\\",SLASH,$part_dir);
> $path_above = str_replace("\\",SLASH,$path_above);
>
>
> if(isset($_GET['path'])) $path = urldecode($_GET['path']);
> else $path = '';
>
> $text_help_file = $bp_application_path.SLASH."BP2_help.txt";
>
> // $test = FALSE;
> $test = TRUE;
> if($test) {
>         echo "SHIT”; // is my test string for verifying something has 
> changed, sorry ;-)
>         echo SLASH;
>         echo "<small>”;
> ….
>
>> <Screenshot 2020-08-01 at 21.32.19.png>
>
> //
>
>
>
>
>>> I have just done one thing and uploaded the files: using a constant 
>>> "SLASH" that can be defined either as DIRECTORY_SEPARATOR or as "/" 
>>> in the beginning of _basic_tasks.php.  So you quickly check whether 
>>> classical slashes work… ;-)
>>
>> It wasn’t quick for me ;-) but worth it!
>>
>> Best
>> .r.
>>
>> PS: I haven’t committed that last version yet. I’ll wait for your 
>> final version!
>>
>>
>>> Bernard
>>>
>>> Rainer Schuetz wrote on 01/08/2020 20:16:
>>>> Dear Bernard,
>>>>
>>>> Yes, this looks like serious progress. I can’t check seriously, no 
>>>> time, sorry. But I went to that “one” link. The wrong concatenation 
>>>> of absolute path problem is gone! Yey, a well assembled relative 
>>>> link! But the backslashes are still swallowed. Php still writes a 
>>>> link-segment with Windows/backslash syntax to a html-source tag, 
>>>> and as a result all \ are swallowed:
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bolprocessor-devel mailing list
>>> bol...@li... 
>>> <mailto:bol...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>>
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

[Bernard B. <ber...@gm...>]

Regarding the image, please replace prototype-image.php with the 
enclosed version.I added the "require_once("_basic_tasks.php");" so that 
the slash is defined. Otherwise images remain dark…

Rainer Schuetz wrote on 01/08/2020 22:40:
> I fear the urlencode stuff has to be rethought for consistent use with 
> slash. The image at the end of that page doesn’t open atm - it used to 
> in the past..
>
> Best
> .r.
>
>> On 1. Aug 2020, at 22:30, Rainer Schuetz <rs...@ba... 
>> <mailto:rs...@ba...>> wrote:
>>
>> I sent an email with attachments and the ml-server blocked again, I 
>> resend with text only for the big image:
>>
>>> On 1. Aug 2020, at 22:24, Rainer Schuetz <rs...@ba... 
>>> <mailto:rs...@ba...>> wrote:
>>>
>>>
>>>
>>>> On 1. Aug 2020, at 21:07, Bernard Bel <ber...@gm... 
>>>> <mailto:ber...@gm...>> wrote:
>>>>
>>>> Well… At the moment I used DIRECTORY_SEPARATOR everywhere, but I 
>>>> don't understand where it should be used and where plain slashes 
>>>> are necessay! There seems to be no relevant documentation on this 
>>>> topic…
>>>
>>> I can’t claim understanding, but as an input to be considered: when 
>>> php speaks with the system, it seems to use or receive backslash. 
>>> The whole backslash thingy entered the picture because you used that 
>>> document root and getcwd() in the beginning. I continued using 
>>> getcwd() and didn’t think about how subsequent operations would 
>>> handle this. I took for granted that php would know when it “speaks 
>>> to the web” and converts backslashes it got from “speaking to 
>>> windows” to slashes once it outputs stuff. That was wrong, but I 
>>> also didn’t follow how you designed the paths you would be using 
>>> when you made php “speak to the web”/generate html. I guess once 
>>> they’re declared variables, they’re strings and php doesn’t think 
>>> about converting them any more.
>>>
>>>
>>>> Maybe normal slashes everywhere would do the job?
>>>
>>> Yes! But what you did with “define SLASH /“ wasn’t enough, because 
>>> the “bp_xyz” variables I suggested still receive backslashes from 
>>> getcwd(), and you seem still to use those ones as well. Also - what 
>>> I had to learn the hard way - unlike variable declarations a 
>>> subsequent “define” seems not to override a preceding one - it has 
>>> to be commented out. To get all over slashes I did a quick and 
>>> clumsy replace for each individual variable following your model for 
>>> “root”, and then everything flipped - and the links work!!! Windows 
>>> even plays the MIDI-file without any MIDI-configuration on my 
>>> part!!! With these settings the test links worked on Windows (I just 
>>> tried two or three):
>>>
>>> <Screenshot 2020-08-01 at 22.20.50.png>
>>
>>
>> // define('SLASH',DIRECTORY_SEPARATOR);
>> define('SLASH',"/");
>>
>> $root = $_SERVER['DOCUMENT_ROOT'].SLASH;
>> $root = str_replace("\\",SLASH,$root);
>> $root = str_replace(SLASH,SLASH,$root);
>>
>> // take bottom-up approach
>> $bp_php_path = getcwd();
>> $bp_application_path = dirname($bp_php_path);
>> $bp_parent_path = dirname($bp_application_path);
>>
>> $bp_home_dir = 
>> str_replace($bp_parent_path.SLASH,'',$bp_application_path);
>> $part_dir = str_replace($bp_parent_path,'',$bp_php_path);
>> $path_above = str_replace($root,'',$bp_php_path);
>> $path_above = str_replace($part_dir,'',$path_above);
>>
>>
>> $bp_php_path = str_replace("\\",SLASH,$bp_php_path);
>> $bp_application_path = str_replace("\\",SLASH,$bp_application_path);
>> $bp_parent_path = str_replace("\\",SLASH,$bp_parent_path);
>> $bp_home_dir = str_replace("\\",SLASH,$bp_home_dir);
>> $part_dir = str_replace("\\",SLASH,$part_dir);
>> $path_above = str_replace("\\",SLASH,$path_above);
>>
>>
>> if(isset($_GET['path'])) $path = urldecode($_GET['path']);
>> else $path = '';
>>
>> $text_help_file = $bp_application_path.SLASH."BP2_help.txt";
>>
>> // $test = FALSE;
>> $test = TRUE;
>> if($test) {
>>         echo "SHIT”; // is my test string for verifying something has 
>> changed, sorry ;-)
>>         echo SLASH;
>>         echo "<small>”;
>> ….
>>
>>> <Screenshot 2020-08-01 at 21.32.19.png>
>>
>> /<Screenshot 2020-08-01 at 21.32.19.png>/
>>
>>
>>
>>
>>>> I have just done one thing and uploaded the files: using a constant 
>>>> "SLASH" that can be defined either as DIRECTORY_SEPARATOR or as "/" 
>>>> in the beginning of _basic_tasks.php.  So you quickly check whether 
>>>> classical slashes work… ;-)
>>>
>>> It wasn’t quick for me ;-) but worth it!
>>>
>>> Best
>>> .r.
>>>
>>> PS: I haven’t committed that last version yet. I’ll wait for your 
>>> final version!
>>>
>>>
>>>> Bernard
>>>>
>>>> Rainer Schuetz wrote on 01/08/2020 20:16:
>>>>> Dear Bernard,
>>>>>
>>>>> Yes, this looks like serious progress. I can’t check seriously, no 
>>>>> time, sorry. But I went to that “one” link. The wrong 
>>>>> concatenation of absolute path problem is gone! Yey, a well 
>>>>> assembled relative link! But the backslashes are still swallowed. 
>>>>> Php still writes a link-segment with Windows/backslash syntax to a 
>>>>> html-source tag, and as a result all \ are swallowed:
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> bolprocessor-devel mailing list
>>>> bol...@li... 
>>>> <mailto:bol...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

O shit, and the screenshot I sent was the wrong one, the correct one looked all the same but all slashes instead of backslashes!!! I already deleted it… Can you trust me ;-)

Best
.r.


> On 1. Aug 2020, at 22:40, Rainer Schuetz <rs...@ba...> wrote:
> 
> I fear the urlencode stuff has to be rethought for consistent use with slash. The image at the end of that page doesn’t open atm - it used to in the past..
> 
> Best
> .r.
> 
>> On 1. Aug 2020, at 22:30, Rainer Schuetz <rs...@ba... <mailto:rs...@ba...>> wrote:
>> 
>> I sent an email with attachments and the ml-server blocked again, I resend with text only for the big image:
>> 
>>> On 1. Aug 2020, at 22:24, Rainer Schuetz <rs...@ba... <mailto:rs...@ba...>> wrote:
>>> 
>>> 
>>> 
>>>> On 1. Aug 2020, at 21:07, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>>> 
>>>> Well… At the moment I used DIRECTORY_SEPARATOR everywhere, but I don't understand where it should be used and where plain slashes are necessay! There seems to be no relevant documentation on this topic…
>>> 
>>> I can’t claim understanding, but as an input to be considered: when php speaks with the system, it seems to use or receive backslash. The whole backslash thingy entered the picture because you used that document root and getcwd() in the beginning. I continued using getcwd() and didn’t think about how subsequent operations would handle this. I took for granted that php would know when it “speaks to the web” and converts backslashes it got from “speaking to windows” to slashes once it outputs stuff. That was wrong, but I also didn’t follow how you designed the paths you would be using when you made php “speak to the web”/generate html. I guess once they’re declared variables, they’re strings and php doesn’t think about converting them any more.
>>> 
>>> 
>>>> Maybe normal slashes everywhere would do the job?
>>> 
>>> Yes! But what you did with “define SLASH /“ wasn’t enough, because the “bp_xyz” variables I suggested still receive backslashes from getcwd(), and you seem still to use those ones as well. Also - what I had to learn the hard way - unlike variable declarations a subsequent “define” seems not to override a preceding one - it has to be commented out. To get all over slashes I did a quick and clumsy replace for each individual variable following your model for “root”, and then everything flipped - and the links work!!! Windows even plays the MIDI-file without any MIDI-configuration on my part!!! With these settings the test links worked on Windows (I just tried two or three):
>>> 
>>> <Screenshot 2020-08-01 at 22.20.50.png>
>> 
>> 
>> // define('SLASH',DIRECTORY_SEPARATOR);
>> define('SLASH',"/");
>> 
>> $root = $_SERVER['DOCUMENT_ROOT'].SLASH;
>> $root = str_replace("\\",SLASH,$root);
>> $root = str_replace(SLASH,SLASH,$root);
>> 
>> // take bottom-up approach
>> $bp_php_path = getcwd();
>> $bp_application_path = dirname($bp_php_path);
>> $bp_parent_path = dirname($bp_application_path);
>> 
>> $bp_home_dir = str_replace($bp_parent_path.SLASH,'',$bp_application_path);
>> $part_dir = str_replace($bp_parent_path,'',$bp_php_path);
>> $path_above = str_replace($root,'',$bp_php_path);
>> $path_above = str_replace($part_dir,'',$path_above);
>> 
>> 
>> $bp_php_path = str_replace("\\",SLASH,$bp_php_path);
>> $bp_application_path = str_replace("\\",SLASH,$bp_application_path);
>> $bp_parent_path = str_replace("\\",SLASH,$bp_parent_path);
>> $bp_home_dir = str_replace("\\",SLASH,$bp_home_dir);
>> $part_dir = str_replace("\\",SLASH,$part_dir);
>> $path_above = str_replace("\\",SLASH,$path_above);
>> 
>> 
>> if(isset($_GET['path'])) $path = urldecode($_GET['path']);
>> else $path = '';
>> 
>> $text_help_file = $bp_application_path.SLASH."BP2_help.txt";
>> 
>> // $test = FALSE;
>> $test = TRUE;
>> if($test) {
>>         echo "SHIT”; // is my test string for verifying something has changed, sorry ;-)
>>         echo SLASH;
>>         echo "<small>”;
>> ….
>> 
>>> <Screenshot 2020-08-01 at 21.32.19.png>
>> 
>> <Screenshot 2020-08-01 at 21.32.19.png>
>> 
>> 
>> 
>> 
>>>> I have just done one thing and uploaded the files: using a constant "SLASH" that can be defined either as DIRECTORY_SEPARATOR or as "/" in the beginning of _basic_tasks.php.  So you quickly check whether classical slashes work… ;-)
>>> 
>>> It wasn’t quick for me ;-) but worth it!
>>> 
>>> Best
>>> .r.
>>> 
>>> PS: I haven’t committed that last version yet. I’ll wait for your final version!
>>> 
>>> 
>>>> Bernard
>>>> 
>>>> Rainer Schuetz wrote on 01/08/2020 20:16:
>>>>> Dear Bernard,
>>>>> 
>>>>> Yes, this looks like serious progress. I can’t check seriously, no time, sorry. But I went to that “one” link. The wrong concatenation of absolute path problem is gone! Yey, a well assembled relative link! But the backslashes are still swallowed. Php still writes a link-segment with Windows/backslash syntax to a html-source tag, and as a result all \ are swallowed:
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> bolprocessor-devel mailing list
>>>> bol...@li... <mailto:bol...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

I fear the urlencode stuff has to be rethought for consistent use with slash. The image at the end of that page doesn’t open atm - it used to in the past..

Best
.r.

> On 1. Aug 2020, at 22:30, Rainer Schuetz <rs...@ba...> wrote:
> 
> I sent an email with attachments and the ml-server blocked again, I resend with text only for the big image:
> 
>> On 1. Aug 2020, at 22:24, Rainer Schuetz <rs...@ba... <mailto:rs...@ba...>> wrote:
>> 
>> 
>> 
>>> On 1. Aug 2020, at 21:07, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>> 
>>> Well… At the moment I used DIRECTORY_SEPARATOR everywhere, but I don't understand where it should be used and where plain slashes are necessay! There seems to be no relevant documentation on this topic…
>> 
>> I can’t claim understanding, but as an input to be considered: when php speaks with the system, it seems to use or receive backslash. The whole backslash thingy entered the picture because you used that document root and getcwd() in the beginning. I continued using getcwd() and didn’t think about how subsequent operations would handle this. I took for granted that php would know when it “speaks to the web” and converts backslashes it got from “speaking to windows” to slashes once it outputs stuff. That was wrong, but I also didn’t follow how you designed the paths you would be using when you made php “speak to the web”/generate html. I guess once they’re declared variables, they’re strings and php doesn’t think about converting them any more.
>> 
>> 
>>> Maybe normal slashes everywhere would do the job?
>> 
>> Yes! But what you did with “define SLASH /“ wasn’t enough, because the “bp_xyz” variables I suggested still receive backslashes from getcwd(), and you seem still to use those ones as well. Also - what I had to learn the hard way - unlike variable declarations a subsequent “define” seems not to override a preceding one - it has to be commented out. To get all over slashes I did a quick and clumsy replace for each individual variable following your model for “root”, and then everything flipped - and the links work!!! Windows even plays the MIDI-file without any MIDI-configuration on my part!!! With these settings the test links worked on Windows (I just tried two or three):
>> 
>> <Screenshot 2020-08-01 at 22.20.50.png>
> 
> 
> // define('SLASH',DIRECTORY_SEPARATOR);
> define('SLASH',"/");
> 
> $root = $_SERVER['DOCUMENT_ROOT'].SLASH;
> $root = str_replace("\\",SLASH,$root);
> $root = str_replace(SLASH,SLASH,$root);
> 
> // take bottom-up approach
> $bp_php_path = getcwd();
> $bp_application_path = dirname($bp_php_path);
> $bp_parent_path = dirname($bp_application_path);
> 
> $bp_home_dir = str_replace($bp_parent_path.SLASH,'',$bp_application_path);
> $part_dir = str_replace($bp_parent_path,'',$bp_php_path);
> $path_above = str_replace($root,'',$bp_php_path);
> $path_above = str_replace($part_dir,'',$path_above);
> 
> 
> $bp_php_path = str_replace("\\",SLASH,$bp_php_path);
> $bp_application_path = str_replace("\\",SLASH,$bp_application_path);
> $bp_parent_path = str_replace("\\",SLASH,$bp_parent_path);
> $bp_home_dir = str_replace("\\",SLASH,$bp_home_dir);
> $part_dir = str_replace("\\",SLASH,$part_dir);
> $path_above = str_replace("\\",SLASH,$path_above);
> 
> 
> if(isset($_GET['path'])) $path = urldecode($_GET['path']);
> else $path = '';
> 
> $text_help_file = $bp_application_path.SLASH."BP2_help.txt";
> 
> // $test = FALSE;
> $test = TRUE;
> if($test) {
>         echo "SHIT”; // is my test string for verifying something has changed, sorry ;-)
>         echo SLASH;
>         echo "<small>”;
> ….
> 
>> <Screenshot 2020-08-01 at 21.32.19.png>
> 
> <Screenshot 2020-08-01 at 21.32.19.png>
> 
> 
> 
> 
>>> I have just done one thing and uploaded the files: using a constant "SLASH" that can be defined either as DIRECTORY_SEPARATOR or as "/" in the beginning of _basic_tasks.php.  So you quickly check whether classical slashes work… ;-)
>> 
>> It wasn’t quick for me ;-) but worth it!
>> 
>> Best
>> .r.
>> 
>> PS: I haven’t committed that last version yet. I’ll wait for your final version!
>> 
>> 
>>> Bernard
>>> 
>>> Rainer Schuetz wrote on 01/08/2020 20:16:
>>>> Dear Bernard,
>>>> 
>>>> Yes, this looks like serious progress. I can’t check seriously, no time, sorry. But I went to that “one” link. The wrong concatenation of absolute path problem is gone! Yey, a well assembled relative link! But the backslashes are still swallowed. Php still writes a link-segment with Windows/backslash syntax to a html-source tag, and as a result all \ are swallowed:
>>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> bolprocessor-devel mailing list
>>> bol...@li... <mailto:bol...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

I sent an email with attachments and the ml-server blocked again, I resend with text only for the big image:

> On 1. Aug 2020, at 22:24, Rainer Schuetz <rs...@ba...> wrote:
> 
> 
> 
>> On 1. Aug 2020, at 21:07, Bernard Bel <ber...@gm...> wrote:
>> 
>> Well… At the moment I used DIRECTORY_SEPARATOR everywhere, but I don't understand where it should be used and where plain slashes are necessay! There seems to be no relevant documentation on this topic…
> 
> I can’t claim understanding, but as an input to be considered: when php speaks with the system, it seems to use or receive backslash. The whole backslash thingy entered the picture because you used that document root and getcwd() in the beginning. I continued using getcwd() and didn’t think about how subsequent operations would handle this. I took for granted that php would know when it “speaks to the web” and converts backslashes it got from “speaking to windows” to slashes once it outputs stuff. That was wrong, but I also didn’t follow how you designed the paths you would be using when you made php “speak to the web”/generate html. I guess once they’re declared variables, they’re strings and php doesn’t think about converting them any more.
> 
> 
>> Maybe normal slashes everywhere would do the job?
> 
> Yes! But what you did with “define SLASH /“ wasn’t enough, because the “bp_xyz” variables I suggested still receive backslashes from getcwd(), and you seem still to use those ones as well. Also - what I had to learn the hard way - unlike variable declarations a subsequent “define” seems not to override a preceding one - it has to be commented out. To get all over slashes I did a quick and clumsy replace for each individual variable following your model for “root”, and then everything flipped - and the links work!!! Windows even plays the MIDI-file without any MIDI-configuration on my part!!! With these settings the test links worked on Windows (I just tried two or three):
> 
> <Screenshot 2020-08-01 at 22.20.50.png>


// define('SLASH',DIRECTORY_SEPARATOR);
define('SLASH',"/");

$root = $_SERVER['DOCUMENT_ROOT'].SLASH;
$root = str_replace("\\",SLASH,$root);
$root = str_replace(SLASH,SLASH,$root);

// take bottom-up approach
$bp_php_path = getcwd();
$bp_application_path = dirname($bp_php_path);
$bp_parent_path = dirname($bp_application_path);

$bp_home_dir = str_replace($bp_parent_path.SLASH,'',$bp_application_path);
$part_dir = str_replace($bp_parent_path,'',$bp_php_path);
$path_above = str_replace($root,'',$bp_php_path);
$path_above = str_replace($part_dir,'',$path_above);


$bp_php_path = str_replace("\\",SLASH,$bp_php_path);
$bp_application_path = str_replace("\\",SLASH,$bp_application_path);
$bp_parent_path = str_replace("\\",SLASH,$bp_parent_path);
$bp_home_dir = str_replace("\\",SLASH,$bp_home_dir);
$part_dir = str_replace("\\",SLASH,$part_dir);
$path_above = str_replace("\\",SLASH,$path_above);


if(isset($_GET['path'])) $path = urldecode($_GET['path']);
else $path = '';

$text_help_file = $bp_application_path.SLASH."BP2_help.txt";

// $test = FALSE;
$test = TRUE;
if($test) {
        echo "SHIT”; // is my test string for verifying something has changed, sorry ;-)
        echo SLASH;
        echo "<small>”;
….

> <Screenshot 2020-08-01 at 21.32.19.png>






>> I have just done one thing and uploaded the files: using a constant "SLASH" that can be defined either as DIRECTORY_SEPARATOR or as "/" in the beginning of _basic_tasks.php.  So you quickly check whether classical slashes work… ;-)
> 
> It wasn’t quick for me ;-) but worth it!
> 
> Best
> .r.
> 
> PS: I haven’t committed that last version yet. I’ll wait for your final version!
> 
> 
>> Bernard
>> 
>> Rainer Schuetz wrote on 01/08/2020 20:16:
>>> Dear Bernard,
>>> 
>>> Yes, this looks like serious progress. I can’t check seriously, no time, sorry. But I went to that “one” link. The wrong concatenation of absolute path problem is gone! Yey, a well assembled relative link! But the backslashes are still swallowed. Php still writes a link-segment with Windows/backslash syntax to a html-source tag, and as a result all \ are swallowed:
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li...
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
> 

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

> On 1. Aug 2020, at 21:07, Bernard Bel <ber...@gm...> wrote:
> 
> Well… At the moment I used DIRECTORY_SEPARATOR everywhere, but I don't understand where it should be used and where plain slashes are necessay! There seems to be no relevant documentation on this topic…

I can’t claim understanding, but as an input to be considered: when php speaks with the system, it seems to use or receive backslash. The whole backslash thingy entered the picture because you used that document root and getcwd() in the beginning. I continued using getcwd() and didn’t think about how subsequent operations would handle this. I took for granted that php would know when it “speaks to the web” and converts backslashes it got from “speaking to windows” to slashes once it outputs stuff. That was wrong, but I also didn’t follow how you designed the paths you would be using when you made php “speak to the web”/generate html. I guess once they’re declared variables, they’re strings and php doesn’t think about converting them any more.


> Maybe normal slashes everywhere would do the job?

Yes! But what you did with “define SLASH /“ wasn’t enough, because the “bp_xyz” variables I suggested still receive backslashes from getcwd(), and you seem still to use those ones as well. Also - what I had to learn the hard way - unlike variable declarations a subsequent “define” seems not to override a preceding one - it has to be commented out. To get all over slashes I did a quick and clumsy replace for each individual variable following your model for “root”, and then everything flipped - and the links work!!! Windows even plays the MIDI-file without any MIDI-configuration on my part!!! With these settings the test links worked on Windows (I just tried two or three):





> I have just done one thing and uploaded the files: using a constant "SLASH" that can be defined either as DIRECTORY_SEPARATOR or as "/" in the beginning of _basic_tasks.php.  So you quickly check whether classical slashes work… ;-)

It wasn’t quick for me ;-) but worth it!

Best
.r.

PS: I haven’t committed that last version yet. I’ll wait for your final version!


> Bernard
> 
> Rainer Schuetz wrote on 01/08/2020 20:16:
>> Dear Bernard,
>> 
>> Yes, this looks like serious progress. I can’t check seriously, no time, sorry. But I went to that “one” link. The wrong concatenation of absolute path problem is gone! Yey, a well assembled relative link! But the backslashes are still swallowed. Php still writes a link-segment with Windows/backslash syntax to a html-source tag, and as a result all \ are swallowed:
>> 
> 
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

[Bernard B. <ber...@gm...>]

Well… At the moment I used DIRECTORY_SEPARATOR everywhere, but I don't 
understand where it should be used and where plain slashes are necessay! 
There seems to be no relevant documentation on this topic…

Maybe normal slashes everywhere would do the job?

I have just done one thing and uploaded the files: using a constant 
"SLASH" that can be defined either as DIRECTORY_SEPARATOR or as "/" in 
the beginning of _basic_tasks.php.  So you quickly check whether 
classical slashes work… ;-)

Bernard

Rainer Schuetz wrote on 01/08/2020 20:16:
> Dear Bernard,
>
> Yes, this looks like serious progress. I can’t check seriously, no 
> time, sorry. But I went to that “one” link. The wrong concatenation of 
> absolute path problem is gone! Yey, a well assembled relative link! 
> But the backslashes are still swallowed. Php still writes a 
> link-segment with Windows/backslash syntax to a html-source tag, and 
> as a result all \ are swallowed:
>

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

Dear Bernard,

Yes, this looks like serious progress. I can’t check seriously, no time, sorry. But I went to that “one” link. The wrong concatenation of absolute path problem is gone! Yey, a well assembled relative link! But the backslashes are still swallowed. Php still writes a link-segment with Windows/backslash syntax to a html-source tag, and as a result all \ are swallowed:

Not Found

The requested URL /bolprocessor/php/..ctests-mi.abc1_ee9b7331d6f62db3a5194abb54a84e1b_tempcycle2_codesmidicodes.txt was not found on this server.


And the source for this link looks like this:

<a onclick="window.open('..\ctests\-mi.abc1_ee9b7331d6f62db3a5194abb54a84e1b_temp\cycle2_codes\midicodes.txt','MIDItext','width=300,height=300'); return false;" href="..\ctests\-mi.abc1_ee9b7331d6f62db3a5194abb54a84e1b_temp\cycle2_codes\midicodes.txt">EXPLICIT MIDI codes</a>

Feels like “almost there” - it’s just to find why php uses backslashes when it writes html. 

Btw, the “play link” is back! But a similar problem, this time an error-message in the browser console:

GET http://localhost:8080/bolprocessor/php/..ctests-mi.abc1_ee9b7331d6f62db3a5194abb54a84e1b_tempcycle2_codesmidicodes.mid 404 (Not Found)
 
The folder-hierarchy is gone because all backslashes in the page-source disappear in the resulting link!

Btw, the “site” feels quite a bit snappier now.

I said I was not going to test on the Mac, but this doesn’t qualify as test, so: I hear sound on the Mac now without having done *any* MIDI configuration! Yey too!!

Best
.r.



> On 1. Aug 2020, at 19:20, Bernard Bel <ber...@gm...> wrote:
> 
> Dear Rainer,
> 
> The new files with relative-path navigation have been uploaded now. I checked all links and procedures, hoping that I didn't forget any of them!
> 
> On top of the _basic_tasks.php file there is a "test" variable. When activated, many relevant variables will be displayed on all pages, which should make debugging easier if you discover faulty links…
> 
> While I do appreciate your suggestion of installing a more interactive and efficient procedure for checking errors, I have been avoiding any work under pressure or deadlines during my whole career. I am deeply allergic to telephone, skype and all similar equipments — even for chatting with friends and relatives. I like to have an agenda with all options open, including, most important, the right time to start a work and get fully occupied with the development or research.
> 
> In addition, the process of writing code compatible with all environments may have taken a long time due to the late discovery of problems, but once it is done we won't need this sort of trial-and-error process. We'll just continue with solid guidelines ! There is still plenty of work on the interface, notably the editing of Csound instruments that should attract Anthony's critical comments! :-)
> 
> I am impressed that you stayed 3 years in India during childhood. Did you learn a local language? Our son's first language was a mixture of Penjabi and Hindi that we hardly understood. But he quickly understood the advantage of communicating in English, French and German (with his Austrian friend). Being a child in India is "wie Gott in Frankreich" ;-)
> 
> To-morrow we'll move to a presumably cooler place.  All the best to team members!
> 
> Bernard
> 
> Rainer Schuetz wrote on 01/08/2020 14:08:
>>> On 1. Aug 2020, at 13:44, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>> 
>>> It will probably be ready tonight. It takes time to check every single operation… ;-)
>> I know that feeling that something burns under the nail… So if you are at something and you really can’t be sure if it works on Windows, send me a file or a snapshot and I’ll try it. I have a working setup in a virtual machine now, so skipping between the Mac and Windows is two steps less than before, as Windows is on the Mac, and the Windows server-browser access the folder on the Mac.
>> If such situation occurs in the future after your holidays, we might consider using a collaborative coding environment like Atom & Teletype… That would allow you to type something in France, me to store it locally in my village right away, and press the “reload button” on the Windows machine. That might be a way to handle those “trial-and-error” phases collaboratively in a relatively efficient way. We should be sitting together on Skype while that happens ;-) (it will be like at MS, where always two guys sit over a problem together ;-) )
>> Best
>> .r.
>> _______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li... <mailto:bol...@li...>
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li... <mailto:bol...@li...>
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>

Re: [bp-dev] Windows compatibility of the PHP interface

[Bernard B. <ber...@gm...>]

Dear Rainer,

The new files with relative-path navigation have been uploaded now. I 
checked all links and procedures, hoping that I didn't forget any of them!

On top of the _basic_tasks.php file there is a "test" variable. When 
activated, many relevant variables will be displayed on all pages, which 
should make debugging easier if you discover faulty links…

While I do appreciate your suggestion of installing a more interactive 
and efficient procedure for checking errors, I have been avoiding any 
work under pressure or deadlines during my whole career. I am deeply 
allergic to telephone, skype and all similar equipments — even for 
chatting with friends and relatives. I like to have an agenda with all 
options open, including, most important, the right time to start a work 
and get fully occupied with the development or research.

In addition, the process of writing code compatible with all 
environments may have taken a long time due to the late discovery of 
problems, but once it is done we won't need this sort of trial-and-error 
process. We'll just continue with solid guidelines ! There is still 
plenty of work on the interface, notably the editing of Csound 
instruments that should attract Anthony's critical comments! :-)

I am impressed that you stayed 3 years in India during childhood. Did 
you learn a local language? Our son's first language was a mixture of 
Penjabi and Hindi that we hardly understood. But he quickly understood 
the advantage of communicating in English, French and German (with his 
Austrian friend). Being a child in India is "wie Gott in Frankreich" ;-)

To-morrow we'll move to a presumably cooler place.  All the best to team 
members!

Bernard

Rainer Schuetz wrote on 01/08/2020 14:08:
> 
> 
>> On 1. Aug 2020, at 13:44, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> It will probably be ready tonight. It takes time to check every single 
>> operation… ;-)
> 
> I know that feeling that something burns under the nail… So if you are 
> at something and you really can’t be sure if it works on Windows, send 
> me a file or a snapshot and I’ll try it. I have a working setup in a 
> virtual machine now, so skipping between the Mac and Windows is two 
> steps less than before, as Windows is on the Mac, and the Windows 
> server-browser access the folder on the Mac.
> 
> If such situation occurs in the future after your holidays, we might 
> consider using a collaborative coding environment like Atom & Teletype… 
> That would allow you to type something in France, me to store it locally 
> in my village right away, and press the “reload button” on the Windows 
> machine. That might be a way to handle those “trial-and-error” phases 
> collaboratively in a relatively efficient way. We should be sitting 
> together on Skype while that happens ;-) (it will be like at MS, where 
> always two guys sit over a problem together ;-) )
> 
> Best
> .r.
> 
> 
> 
> 
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
> 

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

> On 1. Aug 2020, at 13:44, Bernard Bel <ber...@gm...> wrote:
> 
> It will probably be ready tonight. It takes time to check every single operation… ;-)

I know that feeling that something burns under the nail… So if you are at something and you really can’t be sure if it works on Windows, send me a file or a snapshot and I’ll try it. I have a working setup in a virtual machine now, so skipping between the Mac and Windows is two steps less than before, as Windows is on the Mac, and the Windows server-browser access the folder on the Mac.

If such situation occurs in the future after your holidays, we might consider using a collaborative coding environment like Atom & Teletype… That would allow you to type something in France, me to store it locally in my village right away, and press the “reload button” on the Windows machine. That might be a way to handle those “trial-and-error” phases collaboratively in a relatively efficient way. We should be sitting together on Skype while that happens ;-) (it will be like at MS, where always two guys sit over a problem together ;-) )

Best
.r.

Re: [bp-dev] Windows compatibility of the PHP interface

[Bernard B. <ber...@gm...>]

Dear Rainer,

Your screen shots make it clear: we are in trouble because of the use of 
absolute links. So, today I am reworking the entire set of files to 
enable navigation via relative paths… This is probably due to the fact 
won't interprate links the same way when navigating on a local or an 
on-line server. Because I had never faced this problem on shared sites!

Still using urlencode() and urldecode() when passsing paths to URLS so 
that spaces, slashes etc. are proprely encoded. It is safe and it does 
not harm if unnecessary.

It will probably be ready tonight. It takes time to check every single 
operation… ;-)

Bernard

Rainer Schuetz wrote on 01/08/2020 01:08:
> Dear Berny,
> 
> Sorry, no joy - the problem seems to be on a different level.
> 
> I’ve tried a bit to look behind the scenes:
> 
> I’ll go through it for the “Explicit Midi Codes” link
> 
> Let’s distinguish three things first:
> 
> 1. the rendering of a links as I see it
>    a) in the status line of the browser when I hover over the link in 
> the page
>    b) in a browser address field after I clicked
>    c) the error-message the browser gives me
> 2. correctness of the elements of that link such that it actually points 
> to and thus opens a file (a wrongly assembled link might still be 
> syntactically correct)
> 3. What I see concerning that link looking at the html source generated 
> by php (which I can ask the browser to show).
> 
> Let’s look at syntax first (are all slashes there? Are all words in the 
> link spelt correctly?
> 1a)
> Hover: This link is *syntactically* correct, all slashes are there (none 
> lost) - YES, syntactically this is correct
> 1b)
> Click the link: syntactically in the address bar the link is not 
> displayed correctly. After php/ “..ctestsC:U…" all slashes are missing 
> except one %08 - but  after that the b of the word bolprocessor is 
> missing - so there are multiple things fishy here (and no, I don’t have 
> a folder “olprocessor” (the “belprocessor”-one I had the other day was 
> just to amuse you and demonstrate that even the home-folder needn’t be 
> “bolprocessor” - it has been back to normal right after that “trytwice” 
> test.):
> 
> http://localhost:8080/bolprocessor/php/..ctestsC:UsersschueSites%08olprocessorctests-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt
> 
> 1c)
> And this is the error message of the browser: the link is even a bit 
> more messy, there is this box in front of olprocessor which might be a 
> hint why the b is missing.
> 
> 2) now, the worst thing in that link is of course that at the beginning 
> we have a correct http link down to …lessor/php/ , but then - o horror - 
> first a syntacially incorrect segment that wants to redirect us to 
> ../ctests but can’t, because it’s missing a slash, and then worst: now a 
> full absolute link from c:/ all the way down to the textfile is added - 
> and it’s syntactically broken on top of it.
> 
> 3) Now a quick look in the html source the browser interprets gives a 
> hint what the biggest problem seems to be related to: the (relative) 
> html-link there is represented with backslashes (correct *windows* 
> syntax, but on that level we actually *require* forward slash, because 
> it’s html. So I guess you use code that generates “Windows paths” in 
> literal html-generation. That explains the missing slashes in the links 
> (though its weird that they’re there in the status line!!). This is 
> clearly a mistake, but a mistake that is inconsequential on the Mac, 
> because there the system path uses forward-slashes as well, so you get 
> away with the mistake.

Re: [bp-dev] August holiday

[Bernard B. <ber...@gm...>]

Dear Anthony,

As we delayed or departure by 24 hours I have some time today to sort 
out Windows compatibility on the interface.

 From Rainer's latest message, which included displays of 
badly-interpreted URLs, I guess that the whole problem has been the use 
of absolute paths in many parts of navigation and access to files. So, 
today's work is the revise the entire code to deal only with relative 
paths. It's not that complicated. ;-) Actually it bears some analogy 
with your work of taking care of UTF encodings.

This reminds me of the difficulty of transcoding to UTF8 texts in 
Devanagari script that was already multibyte and context-sensitive! 
Finally I had done it using a rewrite grammar on BP2. Fortunately there 
is no need for going back to the old encodings. A few were describing 
sanskrit characters as sequences of graphic segments while others were 
mapping them to phonetic units in a multi-language approach…

I also remember the difficulty of checking the encoding of an arbitrary 
plain text file. It seems there is no valid method except if you can 
detect that a particular character that you are sure is UTF8 in the 
context of the application. With BP2 we fortunately have a small number 
of such graphemes. (Yesterday I discovered '≤' and '≥' in 
"-gr.badflags". We probably also have '≠' in arithmetic comparisons.)

It's wonderful that you are in the process of sorting out this encoding 
issue!

HTML5 has an "audio" tag that plays wav, mp3 and ogg files nicely, yet 
no MIDI file. For this reason I installed https://www.midijs.net. 
However, that's just a preview of sound-objects at the time of importing 
a MIDI file. We'll use the "play" command to hear the object on the 
actual sound system connected to the console.

As to encoding MIDI files, I found the enclosed document which is 
apparently the latest standard format. We should always store them as 
"type 1" even though they will generally have a single track. And use 
metrical time indeed. In the header, the "division" parameter is "the 
number of ticks in a quarternote". It's probably related to 
Pclock/Qclock. The "time resolution" parameter we have in BP2 is only 
used for the quantization of time structures. When I load MIDI files 
created by BP2, I don't find the "division" parameter but I notice that 
to play them back at the same speed (with mm = 60) the "division" should 
be 480.  I am not yet very clear about this! It will be easy to clarify 
and fix, comparing input and output.

I'll be very pleased to rewrite the graphic output for BP using my 
recent training with GD library.

I'll be back very soon

Bernard

Anthony Kozar wrote on 01/08/2020 00:42:
> Dear Bernard,
>
> I hope you have a wonderful and relaxing holiday!  It can be very nice 
> to be away from any Internet connection for awhile. :)
>
> Hopefully, I will be able to catch up on all of the emails and new 
> developments in your PHP interface while you are away as well as make 
> progress on the console app.  I was excited to read that you have the 
> interface making sounds in the browser!  I look forward to trying 
> that.  I came across a library called Tone.js in the last week that 
> looks very interesting too.  Apparently some browsers now have audio 
> synthesizers built in with a common Javascript API for utilizing them. 
> This might be another interesting output option for BP3.
>
> I want to work on the play command and Midi output.  Now that I have 
> LoadSettings() working I think that modifying the Load*() functions 
> for other similar file types (-cs, -mi, -tb) should be relatively 
> easy. Last night though I started working on resolving some of the 
> text encoding issues.  If all goes well, I think I will be able to 
> make BP console very usable in the new environment by the end of August!
>
> Happy travels and we'll talk to you again soon!
>
> Anthony
>
>
> On 7/28/20, 10:17 AM, Bernard Bel wrote:
>> Dear Anthony,
>>
>> There is no emergency, each of us should set his own agenda according to
>> what is inspiring at the moment rather than fixing priorities on a huge
>> to-do list. ;-) I worked on the prototypes editor because I expected it
>> to be a boring task… Ssometimes I do boring tasks just to feel the
>> relief of them! The first two weeks of August I will be travelling,
>> visiting friends and sleeping in forests most of the time with no
>> Internet connection. After this we will have other activities until the
>> last week of August, so it will be difficult for me to focus on long
>> developments. I will certainly read exchanges and figure out plenty of
>> new tasks. For this reason I felt happy to document what has been done
>> so far on the interface.
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

[bp-dev] UTF-8 support & backwards compatibility

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

Hello all,

Yesterday, I took a good look at how the UTF-8 encoding works and 
contemplating how BP console can support it.  The encoding scheme of 
UTF-8 is actually quite different than I had thought or assumed and that 
turns out to be good for backwards compatibility with MacOS Roman, I 
think.  I was under the mistaken impression that most single-byte codes 
in the range 128-255 were mapped to characters in the ISO/IEC 8859-1 
encoding and that only a few codes were used to prefix multi-byte 
characters.  I was confused because the Unicode character map IS 
compatible with ISO/IEC 8859-1 up to code point 255.  However, as some 
of you may know, UTF-8 re-encodes all characters with code points above 
127 using 2-4 bytes.  Wikipedia has a very nice explanation of how this 
works and of the significant advantages that this encoding scheme has 
for backwards compatibility and auto-detection when using Unix/C-based 
software that operates on strings as sequences of single bytes.

One of the difficulties that I thought we would face in supporting both 
UTF-8 and MacOS Roman input files was being able to tell the difference 
between them for the "high ASCII" characters that are common in BP2 
files (such as •, …, ¬, etc.).  But I now think this won't be difficult 
at all because of the clever design of UTF-8.  NONE of the byte values 
between 128-255 represent single characters in UTF-8.  And the patterns 
they form in multi-byte sequences to encode non-ASCII characters are 
very unlikely to occur in normal text input.  So, when BP console reads 
in a file in MacOS Roman encoding it will be possible to detect that it 
is not UTF-8 because those "high ASCII" characters will look like 
invalid UTF-8 byte sequences!  As long as we limit ourselves to 
supporting UTF-8 and MacOS Roman I think it will be quite easy to 
auto-detect which encoding the input files are in.

A couple of examples should help for those who are interested.  (All 
byte values are in hexadecimal).

Character   MacRoman   8859-1   Unicode   UTF-8
------------------------------------------------------
Bullet •    A5         n/a(1)   20 22     E2 80 A2
Ellipsis …  C9         n/a      20 26     E2 80 A6
Not ¬       C2         AC       00 AC     C2 AC

(1) The closest character to the bullet in ISO/IEC 8859-1 is the 
"interpunct" with a code point of B7.  (We could support the interpunct 
as an alternative to the bullet if desired).

The UTF-8 byte sequences for • and … appear as '‚Ä¢' and '‚Ķ' in MacOS 
Roman so there is little chance of confusing them.  I just now see the 
coincidence that ¬ is C2 in MacOS Roman and C2 AC in UTF-8 which appears 
as '¬' in MacOS Roman.  There is some potential for confusion if  is 
the only non-ASCII character in an input file, but since BP2 uses ¬ to 
represent a line continuation and (I believe) it must be immediately 
followed by a newline sequence, we can probably use that fact to tell 
the difference.

So, this is just a very long way of saying that there is good news on 
the text encoding front and that I have a better idea of how to deal 
with supporting two very different encodings.  There are probably some 
small hurdles in the code to get over -- one is that BP2 expects all of 
the above characters to fit in a single-byte char type -- but those are 
(hopefully) just implementation details.

Best regards,

Anthony

P.S.  What I have learned about UTF-8 also explains why my test program 
to output "high ASCII" UTF-8 characters failed to work as expected in 
the Terminal app on OS X.  I wasn't outputting valid UTF-8-encoded 
characters!  If I just "cat" a valid UTF-8 file, then I can see the 
non-ASCII characters just fine in the terminal! :)

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

Dear Berny,

Sorry, no joy - the problem seems to be on a different level. 

I’ve tried a bit to look behind the scenes:

I’ll go through it for the “Explicit Midi Codes” link

Let’s distinguish three things first:

1. the rendering of a links as I see it
  a) in the status line of the browser when I hover over the link in the page
  b) in a browser address field after I clicked
  c) the error-message the browser gives me
2. correctness of the elements of that link such that it actually points to and thus opens a file (a wrongly assembled link might still be syntactically correct)
3. What I see concerning that link looking at the html source generated by php (which I can ask the browser to show).

Let’s look at syntax first (are all slashes there? Are all words in the link spelt correctly?
1a)
Hover: This link is *syntactically* correct, all slashes are there (none lost) - YES, syntactically this is correct

1b)
Click the link: syntactically in the address bar the link is not displayed correctly. After php/ “..ctestsC:U…" all slashes are missing except one %08 - but  after that the b of the word bolprocessor is missing - so there are multiple things fishy here (and no, I don’t have a folder “olprocessor” (the “belprocessor”-one I had the other day was just to amuse you and demonstrate that even the home-folder needn’t be “bolprocessor” - it has been back to normal right after that “trytwice” test.):

http://localhost:8080/bolprocessor/php/..ctestsC:UsersschueSites%08olprocessorctests-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt <http://localhost:8080/bolprocessor/php/..ctestsC:UsersschueSites%08olprocessorctests-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt>

1c)
And this is the error message of the browser: the link is even a bit more messy, there is this box in front of olprocessor which might be a hint why the b is missing.


2) now, the worst thing in that link is of course that at the beginning we have a correct http link down to …lessor/php/ , but then - o horror - first a syntacially incorrect segment that wants to redirect us to ../ctests but can’t, because it’s missing a slash, and then worst: now a full absolute link from c:/ all the way down to the textfile is added - and it’s syntactically broken on top of it.

3) Now a quick look in the html source the browser interprets gives a hint what the biggest problem seems to be related to: the (relative) html-link there is represented with backslashes (correct *windows* syntax, but on that level we actually *require* forward slash, because it’s html. So I guess you use code that generates “Windows paths” in literal html-generation. That explains the missing slashes in the links (though its weird that they’re there in the status line!!). This is clearly a mistake, but a mistake that is inconsequential on the Mac, because there the system path uses forward-slashes as well, so you get away with the mistake.



As to the question why something wrongly generates the path-segments after ctests as a absolute path, that starts from c:\.. again, I don’t know - maybe some str_replace operation fails to delete the front part of that path? But I’ve seen that “C:/Users….” In some forms as “value” - and that might also have to do with it. Shouldn’t those forms contain a relative path starting from the bolprocessor folder? Well - no idea. But I think there results a vague idea of what goes wrong here: it’s not a urlencode problem, it has to do with the question: when does php assembles Windows-paths (getcwd, using backslash and starting from C:\…., and when does it need to create html-paths, using strictly forward-slash and starting from /bolprocessor/… Currently it still puts Windows paths in places, where it should have converted them to html-paths. Vaguely in that direction it seems to point…).

So much from me. All the best - I also wish you the nicest holidays, and an enjoyable trip to Marseille!!! I haven’t been to France for 30 years, but that Camus/Sartre, Gitanne/Goulouise and French elegance-flair/nostalgy is still fully alive in me - I’d love to go there (unfortunately I hardly speak any French…). Enjoy, but stay safe!!

Yours with huggs
Rainer




> On 31. Jul 2020, at 23:45, Bernard Bel <ber...@gm...> wrote:
> 
> Dear Rainer,
> 
> I think I finally understand what is going wrong!
> 
> When navigating with page "index.php", paths are often passed as GET instructions in the URLs. When these contain DIRECTORY_SEPARATORs, it is possible that the link will be messed up. Therefore I am now putting urlencode() and urldecode() everywhere to make sure that these URLs appear well-formed on all systems. All DIRECTORY_SEPARATORs are converted to "%2F" in the URL, then decoded back - hopefully with the proper encoding for separators!
> 
> I think I have fixed it everywhere and uploaded a new version. But since I am navigating on Mac which is quite tolerant with encodings, the real check will be on Windows. No hurry, we'll finalize this point next week when I get close to a connection…
> 
> In all this we should also take into account that this is not web navigation: our machines might behave differently when navigating on a local web server. Having everything fine on Mac with MAMPS doesn't prove it will be multiplatform. We're learning, aren't we ?
> 
> All the best
> 
> Bernard
> 
> Rainer Schuetz wrote on 31/07/2020 21:05:
>> 
>> 
>>> On 31. Jul 2020, at 20:44, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>> 
>>> You should not put anything else that the PHP files in the "php" folder… 
>> 
>> Of course not… Those paths don’t exist - they are constructed by php on Windows. 
>> 
>> My php-folder is exactly like yours - git would immediately tell me if something was differing. The only thing I get are these long lists of session folders/files in ctests which I remove before I change branches or something…
>> 
>> Best
>> .r.
>> 
>> 
>> 
>> 
>> 
>> 
>>> Bernard
>>> 
>>> Rainer Schuetz wrote on 31/07/2020 18:27:
>>>> With that latest version, I don’t get boxes any more but the slashes are still missing and a unneeded “bolprocessor” is robbed it’s b:
>>>> 
>>>> /bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt
>>>> 
>>>> And that “Play midi file” link, unfortunately I don’t get it at all…
>>>> 
>>>> Best
>>>> .r.
>>>> 
>>>>> On 31. Jul 2020, at 16:55, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>>>> 
>>>>> Yes, this is a bit confusing.
>>>>> 
>>>>> On Mac with a MAMP installation the absolute URL is always:
>>>>> 
>>>>> http://localhost/try/bolprocessor/ <http://localhost/try/bolprocessor/> etc. (where 'try' would be the top folder)
>>>>> 
>>>>> Anyway, it seems that the problem was sending a (possibly incorrect) absolute link to window.open().
>>>>> 
>>>>> I have revised the entire code and replaced these with relative links. I uploaded the revised package…
>>>>> 
>>>>> You will still need to verify that you get a "Play MIDI file" link on the prototype page (see attached picture).
>>>>> 
>>>>> If it is not there it might mean that MIDI Library wasn't able to create the MIDI file, or the link is incorrect - but it is a relative link.
>>>>> 
>>>>> If it is visible, check that clicking the link will play the sound. It may be very short and week, so use hearphones because these events are very short ones.
>>>>> 
>>>>> We're slowly moving to compatibility ! ;-)
>>>>> 
>>>>> Bernard
>>>>> 
>>>>> 
>>>>> Rainer Schuetz wrote on 31/07/2020 15:34:
>>>>>> 
>>>>>> 
>>>>>>> On 31. Jul 2020, at 15:11, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>>>>>> 
>>>>>>> I'll reply the next part of your message in a separate mail.
>>>>>> 
>>>>>> Yea, I realised my path-related descriptions were too messy to be helpful. So on Windows the correct path is:
>>>>>> 
>>>>>> http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt <http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt>
>>>>>> 
>>>>>> The path generated in the browser:
>>>>>> 
>>>>>> http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt <http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt>
>>>>>> 
>>>>>> So it’s swallowing multiple slashes and and adding in stuff.
>>>>>> 
>>>>>> On Mac displays as:
>>>>>> 
>>>>>> users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>> 
>>>>>> Which is an absolute path starting with the word “users” spelt wrong (Users) and maybe missing an initial slash. I can’t remember ever having seen such a path in a browser… not sure if it’s even allowed… But now I see that it’s the browser converts it to that. The manually corrected path:
>>>>>> 
>>>>>> http:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>> 
>>>>>> Or
>>>>>> 
>>>>>> http://Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>> 
>>>>>> Doesn’t open either. If absolute path is required, the only thing that opens for me is:
>>>>>> 
>>>>>> file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>> 
>>>>>> But it would make much more sense to just use 
>>>>>> 
>>>>>> http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>> 
>>>>>> So the path generated by php for server-based http-access should be 
>>>>>> 
>>>>>> bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>> 
>>>>>> Or (not sure)
>>>>>> 
>>>>>> /bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>> 
>>>>>> Which opens just fine for me… But this is a bit confusing, and I really can’t think through it these days…. Very sorry (but the issues are there)
>>>>>> 
>>>>>> Best
>>>>>> .r.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> bolprocessor-devel mailing list
>>>>>> bol...@li... <mailto:bol...@li...>
>>>>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
>>>>> 
>>>>> <Screen Shot 2020-07-31 at 16.49.52 (2).png>_______________________________________________
>>>>> bolprocessor-devel mailing list
>>>>> bol...@li... <mailto:bol...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> bolprocessor-devel mailing list
>>>> bol...@li... <mailto:bol...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
>>> 
>>> _______________________________________________
>>> bolprocessor-devel mailing list
>>> bol...@li... <mailto:bol...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li... <mailto:bol...@li...>
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] August holiday

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

Dear Bernard,

I hope you have a wonderful and relaxing holiday!  It can be very nice 
to be away from any Internet connection for awhile. :)

Hopefully, I will be able to catch up on all of the emails and new 
developments in your PHP interface while you are away as well as make 
progress on the console app.  I was excited to read that you have the 
interface making sounds in the browser!  I look forward to trying that. 
  I came across a library called Tone.js in the last week that looks 
very interesting too.  Apparently some browsers now have audio 
synthesizers built in with a common Javascript API for utilizing them. 
This might be another interesting output option for BP3.

I want to work on the play command and Midi output.  Now that I have 
LoadSettings() working I think that modifying the Load*() functions for 
other similar file types (-cs, -mi, -tb) should be relatively easy. 
Last night though I started working on resolving some of the text 
encoding issues.  If all goes well, I think I will be able to make BP 
console very usable in the new environment by the end of August!

Happy travels and we'll talk to you again soon!

Anthony


On 7/28/20, 10:17 AM, Bernard Bel wrote:
> Dear Anthony,
>
> There is no emergency, each of us should set his own agenda according to
> what is inspiring at the moment rather than fixing priorities on a huge
> to-do list. ;-) I worked on the prototypes editor because I expected it
> to be a boring task… Ssometimes I do boring tasks just to feel the
> relief of them! The first two weeks of August I will be travelling,
> visiting friends and sleeping in forests most of the time with no
> Internet connection. After this we will have other activities until the
> last week of August, so it will be difficult for me to focus on long
> developments. I will certainly read exchanges and figure out plenty of
> new tasks. For this reason I felt happy to document what has been done
> so far on the interface.

Re: [bp-dev] Running BP1 on (emulated) Apple II

[Bernard B. <ber...@gm...>]

Via the Facebook group of Apple II fans, I found a chap who lives in 
Marseille and will help me to duplicate the BP1 floppy disks.

They suggest to create disk images that will travel safely. I'll see if 
he is equipped for it. He has a huge workshop with plenty of old machines!

I will visit him after 15 August. Yes, this is "holiday" in France for 
most people, including retired ones. ;-) We also expect viruses and 
other annoying beings to be on holiday!

I'll certainly read all messages regularly and take action when 
necessary…  Next I have to include Csound objects in the drawing of 
images. For the time being they appear with duration = 0…

See you all soon on virtual space

Bernard


Bernard Bel wrote on 29/07/2020 16:27:
> Back to the project of running BP1 in Apple II emulation…
> 
> I have been able to buy a 5 1/4" floppy disk unit in good shape for only 
> 50 euros. My aim is now to borrow an Apple II form a fan user and copy 
> the disks to new supports. Then I would send these copies to Anthony by 
> Fedex in a carefully sealed package.
> 
> The friend to whom I had given my IIc has disposed of it… (He's still my 
> friend!) A second-hand IIc is sold about 400 to 800 euros on eBay, this 
> would be too much!
> 
> However I discovered a Facebook group "Apple II France" and I am sending 
> them a request for borrowing a machine for, say, 1/2 hour to copy the 
> floppies. They seem to be very active, using oscilloscopes and soldering 
> irons to repare their machines - like in the old good days. If one of 
> them lives in a reachable area, I will take the next step of 
> duplication, using the recent disk unit.
> 
> Bernard

Re: [bp-dev] Windows compatibility of the PHP interface

[Bernard B. <ber...@gm...>]

Dear Rainer,

I think I finally understand what is going wrong!

When navigating with page "index.php", paths are often passed as GET 
instructions in the URLs. When these contain DIRECTORY_SEPARATORs, it is 
possible that the link will be messed up. Therefore I am now putting 
urlencode() and urldecode() everywhere to make sure that these URLs 
appear well-formed on all systems. All DIRECTORY_SEPARATORs are 
converted to "%2F" in the URL, then decoded back - hopefully with the 
proper encoding for separators!

I think I have fixed it everywhere and uploaded a new version. But since 
I am navigating on Mac which is quite tolerant with encodings, the real 
check will be on Windows. No hurry, we'll finalize this point next week 
when I get close to a connection…

In all this we should also take into account that this is not web 
navigation: our machines might behave differently when navigating on a 
local web server. Having everything fine on Mac with MAMPS doesn't prove 
it will be multiplatform. We're learning, aren't we ?

All the best

Bernard

Rainer Schuetz wrote on 31/07/2020 21:05:
>
>
>> On 31. Jul 2020, at 20:44, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> You should not put anything else that the PHP files in the "php" folder…
>
> Of course not… Those paths don’t exist - they are constructed by php 
> on Windows.
>
> My php-folder is exactly like yours - git would immediately tell me if 
> something was differing. The only thing I get are these long lists of 
> session folders/files in ctests which I remove before I change 
> branches or something…
>
> Best
> .r.
>
>
>
>
>
>
>> Bernard
>>
>> Rainer Schuetz wrote on 31/07/2020 18:27:
>>> With that latest version, I don’t get boxes any more but the slashes 
>>> are still missing and a unneeded “bolprocessor” is robbed it’s b:
>>>
>>> /bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt
>>>
>>> And that “Play midi file” link, unfortunately I don’t get it at all…
>>>
>>> Best
>>> .r.
>>>
>>>> On 31. Jul 2020, at 16:55, Bernard Bel <ber...@gm... 
>>>> <mailto:ber...@gm...>> wrote:
>>>>
>>>> Yes, this is a bit confusing.
>>>>
>>>> On Mac with a MAMP installation the absolute URL is always:
>>>>
>>>> http://localhost/try/bolprocessor/ etc. (where 'try' would be the 
>>>> top folder)
>>>>
>>>> Anyway, it seems that the problem was sending a (possibly 
>>>> incorrect) absolute link to window.open().
>>>>
>>>> I have revised the entire code and replaced these with relative 
>>>> links. I uploaded the revised package…
>>>>
>>>> You will still need to verify that you get a "Play MIDI file" link 
>>>> on the prototype page (see attached picture).
>>>>
>>>> If it is not there it might mean that MIDI Library wasn't able to 
>>>> create the MIDI file, or the link is incorrect - but it is a 
>>>> relative link.
>>>>
>>>> If it is visible, check that clicking the link will play the sound. 
>>>> It may be very short and week, so use hearphones because these 
>>>> events are very short ones.
>>>>
>>>> We're slowly moving to compatibility ! ;-)
>>>>
>>>> Bernard
>>>>
>>>>
>>>> Rainer Schuetz wrote on 31/07/2020 15:34:
>>>>>
>>>>>
>>>>>> On 31. Jul 2020, at 15:11, Bernard Bel <ber...@gm... 
>>>>>> <mailto:ber...@gm...>> wrote:
>>>>>>
>>>>>> I'll reply the next part of your message in a separate mail.
>>>>>
>>>>> Yea, I realised my path-related descriptions were too messy to be 
>>>>> helpful. So on Windows the correct path is:
>>>>>
>>>>> http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt
>>>>>
>>>>> The path generated in the browser:
>>>>>
>>>>> http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt
>>>>>
>>>>> So it’s swallowing multiple slashes and and adding in stuff.
>>>>>
>>>>> On Mac displays as:
>>>>>
>>>>> users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
>>>>> <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>
>>>>> Which is an absolute path starting with the word “users” spelt 
>>>>> wrong (Users) and maybe missing an initial slash. I can’t remember 
>>>>> ever having seen such a path in a browser… not sure if it’s even 
>>>>> allowed… But now I see that it’s the browser converts it to that. 
>>>>> The manually corrected path:
>>>>>
>>>>> http:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
>>>>> <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>
>>>>> Or
>>>>>
>>>>> http://Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
>>>>> <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>
>>>>> Doesn’t open either. If absolute path is required, the only thing 
>>>>> that opens for me is:
>>>>>
>>>>> file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>>>>>
>>>>> But it would make much more sense to just use
>>>>>
>>>>> http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>>>>>
>>>>> So the path generated by php for server-based http-access should be
>>>>>
>>>>> bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
>>>>> <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>
>>>>> Or (not sure)
>>>>>
>>>>> /bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
>>>>> <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>>>
>>>>> Which opens just fine for me… But this is a bit confusing, and I 
>>>>> really can’t think through it these days…. Very sorry (but the 
>>>>> issues are there)
>>>>>
>>>>> Best
>>>>> .r.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> bolprocessor-devel mailing list
>>>>> bol...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>>>>
>>>> <Screen Shot 2020-07-31 at 16.49.52 
>>>> (2).png>_______________________________________________
>>>> bolprocessor-devel mailing list
>>>> bol...@li... 
>>>> <mailto:bol...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bolprocessor-devel mailing list
>>> bol...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>>
>> _______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li... 
>> <mailto:bol...@li...>
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

> On 31. Jul 2020, at 20:49, Bernard Bel <ber...@gm...> wrote:
> 
> This also an illicit path: putting data in the "php" folder…
> 
> I uploaded an updated version after checking that the construction of relative links works even in subfolders of the highest data folders.

I’ll merge and push, but I am sorry, I cannot verify them before next week.

Best
.r.

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

> On 31. Jul 2020, at 20:44, Bernard Bel <ber...@gm...> wrote:
> 
> You should not put anything else that the PHP files in the "php" folder… 

Of course not… Those paths don’t exist - they are constructed by php on Windows. 

My php-folder is exactly like yours - git would immediately tell me if something was differing. The only thing I get are these long lists of session folders/files in ctests which I remove before I change branches or something…

Best
.r.






> Bernard
> 
> Rainer Schuetz wrote on 31/07/2020 18:27:
>> With that latest version, I don’t get boxes any more but the slashes are still missing and a unneeded “bolprocessor” is robbed it’s b:
>> 
>> /bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt
>> 
>> And that “Play midi file” link, unfortunately I don’t get it at all…
>> 
>> Best
>> .r.
>> 
>>> On 31. Jul 2020, at 16:55, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>> 
>>> Yes, this is a bit confusing.
>>> 
>>> On Mac with a MAMP installation the absolute URL is always:
>>> 
>>> http://localhost/try/bolprocessor/ <http://localhost/try/bolprocessor/> etc. (where 'try' would be the top folder)
>>> 
>>> Anyway, it seems that the problem was sending a (possibly incorrect) absolute link to window.open().
>>> 
>>> I have revised the entire code and replaced these with relative links. I uploaded the revised package…
>>> 
>>> You will still need to verify that you get a "Play MIDI file" link on the prototype page (see attached picture).
>>> 
>>> If it is not there it might mean that MIDI Library wasn't able to create the MIDI file, or the link is incorrect - but it is a relative link.
>>> 
>>> If it is visible, check that clicking the link will play the sound. It may be very short and week, so use hearphones because these events are very short ones.
>>> 
>>> We're slowly moving to compatibility ! ;-)
>>> 
>>> Bernard
>>> 
>>> 
>>> Rainer Schuetz wrote on 31/07/2020 15:34:
>>>> 
>>>> 
>>>>> On 31. Jul 2020, at 15:11, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>>>> 
>>>>> I'll reply the next part of your message in a separate mail.
>>>> 
>>>> Yea, I realised my path-related descriptions were too messy to be helpful. So on Windows the correct path is:
>>>> 
>>>> http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt <http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt>
>>>> 
>>>> The path generated in the browser:
>>>> 
>>>> http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt <http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt>
>>>> 
>>>> So it’s swallowing multiple slashes and and adding in stuff.
>>>> 
>>>> On Mac displays as:
>>>> 
>>>> users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>> 
>>>> Which is an absolute path starting with the word “users” spelt wrong (Users) and maybe missing an initial slash. I can’t remember ever having seen such a path in a browser… not sure if it’s even allowed… But now I see that it’s the browser converts it to that. The manually corrected path:
>>>> 
>>>> http:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>> 
>>>> Or
>>>> 
>>>> http://Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>> 
>>>> Doesn’t open either. If absolute path is required, the only thing that opens for me is:
>>>> 
>>>> file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>> 
>>>> But it would make much more sense to just use 
>>>> 
>>>> http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>> 
>>>> So the path generated by php for server-based http-access should be 
>>>> 
>>>> bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>> 
>>>> Or (not sure)
>>>> 
>>>> /bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>> 
>>>> Which opens just fine for me… But this is a bit confusing, and I really can’t think through it these days…. Very sorry (but the issues are there)
>>>> 
>>>> Best
>>>> .r.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> bolprocessor-devel mailing list
>>>> bol...@li... <mailto:bol...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
>>> 
>>> <Screen Shot 2020-07-31 at 16.49.52 (2).png>_______________________________________________
>>> bolprocessor-devel mailing list
>>> bol...@li... <mailto:bol...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li... <mailto:bol...@li...>
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
> 
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

[Bernard B. <ber...@gm...>]

This also an illicit path: putting data in the "php" folder…

I uploaded an updated version after checking that the construction of 
relative links works even in subfolders of the highest data folders.

Bernard

Rainer Schuetz wrote on 31/07/2020 17:48:
> Okay, now this is verified current state on Windows (after you sent 
> the single file), I am on the right branch and commit history correct:
>
> I use the MAMP-Server and the bolprocessor folder is actually a child 
> of the Webserver document root (and not linked in) I get this now:
>
> ----
> Forbidden
> You don't have permission to access 
> /bolprocessor/php/..olprocessorC:UsersschueSitesolprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt 
> on this server.
> ---
>
> There is more to it, as the path statement on Windows contains little 
> boxes that indicate that there is some weird symbol in there, either a 
> control character or an exotical symbols for which no font is present. 
> These symbols disappear during a copy paste from my windows machine 
> (Remote Desktop) to my Mac...
>
>
> So something really weird is going on there now… But sorry, I can’t 
> try to understand it during the remaining week, maybe you have an idea.
>
> I think that “display debug-messages”-switch you added the other day 
> is a great thing. You might want to add much more debug messages in 
> other places as well.
>
> As to Mac I think it’s better I don’t “test” on Mac, as my system 
> configuration differs markedly from yours… I was comparing what was to 
> be expected on a Mac and compare it to Windows, but better if I focus 
> on Windows only for “reports"…
>
> Best
> .r.
>
>
>
>
>> On 31. Jul 2020, at 15:39, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> I am enclosing a versio of prototype.php that uses relative paths to 
>> call window.open().  It works fine, juste a few additional lines are 
>> required. If it solves the problem then I will put relative paths for 
>> all window.open() calls…
>>>
>>> http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>>>
>>> As I am still in a hurry, I couldn’t look at leisure or in an 
>>> attempt-at-understanding-way at the stuff. But when randomly trying 
>>> out buttons, I did bump into a bug which is also an incostency 
>>> between Mac and Windows. These buttons:
>>>
>>> <image.png>
>>>
>>> Generate a) paths that don’t work
>>>
>>> Mac: 
>>> http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>>>
>>>
>>
>> <prototype.php>_______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li... 
>> <mailto:bol...@li...>
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

[Bernard B. <ber...@gm...>]

You should not put anything else that the PHP files in the "php" folder… 
This is why the "/bolprocessor/php/olprocessorctests/" path is not licit 
and will mess up things…

Bernard

Rainer Schuetz wrote on 31/07/2020 18:27:
> With that latest version, I don’t get boxes any more but the slashes 
> are still missing and a unneeded “bolprocessor” is robbed it’s b:
>
> /bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt
>
> And that “Play midi file” link, unfortunately I don’t get it at all…
>
> Best
> .r.
>
>> On 31. Jul 2020, at 16:55, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> Yes, this is a bit confusing.
>>
>> On Mac with a MAMP installation the absolute URL is always:
>>
>> http://localhost/try/bolprocessor/ etc. (where 'try' would be the top 
>> folder)
>>
>> Anyway, it seems that the problem was sending a (possibly incorrect) 
>> absolute link to window.open().
>>
>> I have revised the entire code and replaced these with relative 
>> links. I uploaded the revised package…
>>
>> You will still need to verify that you get a "Play MIDI file" link on 
>> the prototype page (see attached picture).
>>
>> If it is not there it might mean that MIDI Library wasn't able to 
>> create the MIDI file, or the link is incorrect - but it is a relative 
>> link.
>>
>> If it is visible, check that clicking the link will play the sound. 
>> It may be very short and week, so use hearphones because these events 
>> are very short ones.
>>
>> We're slowly moving to compatibility ! ;-)
>>
>> Bernard
>>
>>
>> Rainer Schuetz wrote on 31/07/2020 15:34:
>>>
>>>
>>>> On 31. Jul 2020, at 15:11, Bernard Bel <ber...@gm... 
>>>> <mailto:ber...@gm...>> wrote:
>>>>
>>>> I'll reply the next part of your message in a separate mail.
>>>
>>> Yea, I realised my path-related descriptions were too messy to be 
>>> helpful. So on Windows the correct path is:
>>>
>>> http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt
>>>
>>> The path generated in the browser:
>>>
>>> http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt
>>>
>>> So it’s swallowing multiple slashes and and adding in stuff.
>>>
>>> On Mac displays as:
>>>
>>> users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
>>> <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>
>>> Which is an absolute path starting with the word “users” spelt wrong 
>>> (Users) and maybe missing an initial slash. I can’t remember ever 
>>> having seen such a path in a browser… not sure if it’s even allowed… 
>>> But now I see that it’s the browser converts it to that. The 
>>> manually corrected path:
>>>
>>> http:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
>>> <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>
>>> Or
>>>
>>> http://Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
>>> <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>
>>> Doesn’t open either. If absolute path is required, the only thing 
>>> that opens for me is:
>>>
>>> file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>>>
>>> But it would make much more sense to just use
>>>
>>> http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>>>
>>> So the path generated by php for server-based http-access should be
>>>
>>> bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
>>> <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>
>>> Or (not sure)
>>>
>>> /bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
>>> <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>>>
>>> Which opens just fine for me… But this is a bit confusing, and I 
>>> really can’t think through it these days…. Very sorry (but the 
>>> issues are there)
>>>
>>> Best
>>> .r.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bolprocessor-devel mailing list
>>> bol...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>>
>> <Screen Shot 2020-07-31 at 16.49.52 
>> (2).png>_______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li... 
>> <mailto:bol...@li...>
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

With that latest version, I don’t get boxes any more but the slashes are still missing and a unneeded “bolprocessor” is robbed it’s b:

/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt

And that “Play midi file” link, unfortunately I don’t get it at all…

Best
.r.

> On 31. Jul 2020, at 16:55, Bernard Bel <ber...@gm...> wrote:
> 
> Yes, this is a bit confusing.
> 
> On Mac with a MAMP installation the absolute URL is always:
> 
> http://localhost/try/bolprocessor/ <http://localhost/try/bolprocessor/> etc. (where 'try' would be the top folder)
> 
> Anyway, it seems that the problem was sending a (possibly incorrect) absolute link to window.open().
> 
> I have revised the entire code and replaced these with relative links. I uploaded the revised package…
> 
> You will still need to verify that you get a "Play MIDI file" link on the prototype page (see attached picture).
> 
> If it is not there it might mean that MIDI Library wasn't able to create the MIDI file, or the link is incorrect - but it is a relative link.
> 
> If it is visible, check that clicking the link will play the sound. It may be very short and week, so use hearphones because these events are very short ones.
> 
> We're slowly moving to compatibility ! ;-)
> 
> Bernard
> 
> 
> Rainer Schuetz wrote on 31/07/2020 15:34:
>> 
>> 
>>> On 31. Jul 2020, at 15:11, Bernard Bel <ber...@gm... <mailto:ber...@gm...>> wrote:
>>> 
>>> I'll reply the next part of your message in a separate mail.
>> 
>> Yea, I realised my path-related descriptions were too messy to be helpful. So on Windows the correct path is:
>> 
>> http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt <http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt>
>> 
>> The path generated in the browser:
>> 
>> http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt <http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt>
>> 
>> So it’s swallowing multiple slashes and and adding in stuff.
>> 
>> On Mac displays as:
>> 
>> users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> Which is an absolute path starting with the word “users” spelt wrong (Users) and maybe missing an initial slash. I can’t remember ever having seen such a path in a browser… not sure if it’s even allowed… But now I see that it’s the browser converts it to that. The manually corrected path:
>> 
>> http:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> Or
>> 
>> http://Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> Doesn’t open either. If absolute path is required, the only thing that opens for me is:
>> 
>> file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> But it would make much more sense to just use 
>> 
>> http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> So the path generated by php for server-based http-access should be 
>> 
>> bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> Or (not sure)
>> 
>> /bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> Which opens just fine for me… But this is a bit confusing, and I really can’t think through it these days…. Very sorry (but the issues are there)
>> 
>> Best
>> .r.
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> bolprocessor-devel mailing list
>> bol...@li... <mailto:bol...@li...>
>> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel <https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel>
> 
> <Screen Shot 2020-07-31 at 16.49.52 (2).png>_______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

[Rainer S. <rs...@ba...>]

Okay, now this is verified current state on Windows (after you sent the single file), I am on the right branch and commit history correct:

I use the MAMP-Server and the bolprocessor folder is actually a child of the Webserver document root (and not linked in) I get this now:

----
Forbidden
You don't have permission to access /bolprocessor/php/..olprocessorC:UsersschueSitesolprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt on this server.
---

There is more to it, as the path statement on Windows contains little boxes that indicate that there is some weird symbol in there, either a control character or an exotical symbols for which no font is present. These symbols disappear during a copy paste from my windows machine (Remote Desktop) to my Mac...



So something really weird is going on there now… But sorry, I can’t try to understand it during the remaining week, maybe you have an idea.

I think that “display debug-messages”-switch you added the other day is a great thing. You might want to add much more debug messages in other places as well.

As to Mac I think it’s better I don’t “test” on Mac, as my system configuration differs markedly from yours… I was comparing what was to be expected on a Mac and compare it to Windows, but better if I focus on Windows only for “reports"…

Best
.r.




> On 31. Jul 2020, at 15:39, Bernard Bel <ber...@gm...> wrote:
> 
> I am enclosing a versio of prototype.php that uses relative paths to call window.open().  It works fine, juste a few additional lines are required. If it solves the problem then I will put relative paths for all window.open() calls…
>> 
>> http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> As I am still in a hurry, I couldn’t look at leisure or in an attempt-at-understanding-way at the stuff. But when randomly trying out buttons, I did bump into a bug which is also an incostency between Mac and Windows. These buttons:
>> 
>> <image.png>
>> 
>> Generate a) paths that don’t work
>> 
>> Mac: http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt <http://users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>> 
>> 
> 
> <prototype.php>_______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel

Re: [bp-dev] Windows compatibility of the PHP interface

[Bernard B. <ber...@gm...>]

Yes, this is a bit confusing.

On Mac with a MAMP installation the absolute URL is always:

http://localhost/try/bolprocessor/ etc. (where 'try' would be the top 
folder)

Anyway, it seems that the problem was sending a (possibly incorrect) 
absolute link to window.open().

I have revised the entire code and replaced these with relative links. I 
uploaded the revised package…

You will still need to verify that you get a "Play MIDI file" link on 
the prototype page (see attached picture).

If it is not there it might mean that MIDI Library wasn't able to create 
the MIDI file, or the link is incorrect - but it is a relative link.

If it is visible, check that clicking the link will play the sound. It 
may be very short and week, so use hearphones because these events are 
very short ones.

We're slowly moving to compatibility ! ;-)

Bernard


Rainer Schuetz wrote on 31/07/2020 15:34:
>
>
>> On 31. Jul 2020, at 15:11, Bernard Bel <ber...@gm... 
>> <mailto:ber...@gm...>> wrote:
>>
>> I'll reply the next part of your message in a separate mail.
>
> Yea, I realised my path-related descriptions were too messy to be 
> helpful. So on Windows the correct path is:
>
> http://localhost:8080/bolprocessor/ctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_temp/cycle2_codes/midicodes.txt
>
> The path generated in the browser:
>
> http://localhost:8080/bolprocessor/php/olprocessorctests/-mi.abc1_l17f78gc0u0dn0k1aq4rsvttls_tempcycle2_codesmidicodes.txt
>
> So it’s swallowing multiple slashes and and adding in stuff.
>
> On Mac displays as:
>
> users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
> <http://Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>
> Which is an absolute path starting with the word “users” spelt wrong 
> (Users) and maybe missing an initial slash. I can’t remember ever 
> having seen such a path in a browser… not sure if it’s even allowed… 
> But now I see that it’s the browser converts it to that. The manually 
> corrected path:
>
> http:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>
> Or
>
> http://Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
> <http:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>
> Doesn’t open either. If absolute path is required, the only thing that 
> opens for me is:
>
> file:///Users/rs/Projects/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>
> But it would make much more sense to just use
>
> http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt
>
> So the path generated by php for server-based http-access should be
>
> bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
> <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>
> Or (not sure)
>
> /bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt 
> <http://localhost/bolprocessor/ctests/-mi.abc1_fevkrev7g7subcgk6ejfcetqp1_temp/cycle2_codes/midicodes.txt>
>
> Which opens just fine for me… But this is a bit confusing, and I 
> really can’t think through it these days…. Very sorry (but the issues 
> are there)
>
> Best
> .r.
>
>
>
>
>
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel