return 08; generates PHP Parse error:
the leading zero should be removed from all of these return statements.
Issue 2.
PHP Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /var/www/html/gedview/includes/functions/functions_print.php on line 1483,
I copied the latest functions_print.php
(
* @version $Id: functions_print.php 7115 2015-10-31 18:26:28Z sridharb $
) svn 7117.
over on top of my "old" version of gedview.
Seems to fix it.
I tried a full replacement / update of gedview and got more errors than I wanted to deal with.
PHP 7 is touted as being twice as fast as php 5.6 and taking 1/2 the memory.
May be my imagination, but gedview does seem to be faster.
My ged view data base has 19K persons, and I"m using postgresql.
Last edit: vince-br549 2015-12-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Issue 1.
in the trunk version
In /modules/research_assistant/ra_functions.php
function parseMonthsToInt($month)
return 08; generates PHP Parse error:
the leading zero should be removed from all of these return statements.
I'm not finding the function actually used anywhere, but I suspect it
needs '' around the numbers so they appear as an element of a string in
the formatted date. I think RA is actually using one of the other date
packages to do this now.
Issue 2.
PHP Warning: preg_replace(): The /e modifier is no longer supported, use
preg_replace_callback instead in
/var/www/html/gedview/includes/functions/functions_print.php on line 1483,
I copied the latest functions_print.php
(
* @version $Id: functions_print.php 7115 2015-10-31 18:26:28Z sridharb $
)
over on top of my "old" version of gedview.
Seems to fix it.
I thought we had all of the /e and other grep deprecated code updated in
the current SVN version.
I tried a full replacement / update of gedview and got more errors than
I wanted to deal with.
I'm stuck in the middle at the moment
My port uses Firebird, and I can't get the 'latest' code to run fully
until I can complete reworking PDO to handle the SQL differences. My
ADOdb based version runs fine even on PHP7 so I'm not sure it's worth my
time ... but I'll through a bit more time at it first.
PHP 7 is touted as being twice as fast as php 5.6 and taking 1/2 the memory.
May be my imagination, but gedview does seem to be faster.
My ged view data base has 19K persons, and I"m using postgresql.
I'm not seeing a substantial speed increase on applications that are
using multiple files across multiple directories such as PGV. Only when
running code is it quicker and it needs the opcache running as well,
which only works well if you are not looking up lots of dynamic data
from databases :)
re: adding " around the returns, the name of the function is parseMonthsToInt,
so my understanding is just remove the leading zeros. I don't consider myself a PHP expert by any streatch but....
return 8;
returns int value of 8. which was the point of the function.
where return "08"; returns a string, ahh but then PHP will handle it just fine.
I enabled opcache, so maybe that explains my perception of speed boost.
your post mingled with mine, was confused as to which were your comments and which were mine.
--
Vince
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
your post mingled with mine, was confused as to which were your comments
and which were mine.
I forget that SF mangles quoting ... about time there was a real
standard for messaging and one that does not use html to mess things
further ...
You are right about the 'int' ... I've been playing with code that
unmangles UK and American dates today and some routines complain if the
month is not supplied as two characters :(
I'm fighting another problem at the moment as the 'getInstance' is not
returning a class but just an array of data and I can't see at the
moment how it ever worked as there is no 'new' call in any of the code
I'm looking through ...
I'm fighting another problem at the moment as the 'getInstance' is not
returning a class but just an array of data and I can't see at the
moment how it ever worked as there is no 'new' call in any of the code
I'm looking through ...
Bugger I hate PDO ... it's returning the 'INDI' as 'INDI ' add an extra
'trim' and everything bust into life!
The research_assistant module is not actively supported by anyone.
I agree with Lester: That parseMonthsToInt function isn't used anywhere. It seems to be dead code. My vote is to remove the function or to at least comment it out. However, if it's going to remain, its code should be corrected to make PHP 7 happy. Remove those leading zeros. (My vote here: PHP 7 is dumb. What's wrong with leading zeros?)
Which is it going to be? Let me know, and I'll update SVN accordingly.
@vince-br59:
Don't pick-and-choose what you're going to run under PHP 7. There were other occurrences of the preg_replace function with the /e modifier.
You need to use the entire SVN package, but remove/delete the modules you're not going to use. My site is quite happy with just the following modules: GEDFact_assistant, JWplayer, lightbox, slideshow.
Last edit: Gerry Kroll 2015-12-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
my undrstanding is leading zeros means it is an octal value, hence the error
since there is no such octal value as 08. guessing PHP 7 reads entire file and tried to cache it, thus found the offending 08.
Being new here, where would you like me to post my php 7 results, if at all :)
I just added some more to the help forum
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
getting wordy, i am. was reading a huge book on php. they suggest never ending a php file
with
?>
to prevent accidentle blank lines from mucking up the works when creating html.
tnx for listening
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, SVN 7118 contains the corrected use of the leading zero in that research_assistant function. It also comments-out that same function, since it's apparently not used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@vince-br59:
What alternative does that all-knowing book of yours recommend?
We already know that blank lines preceding or following PHP code can have undesirable effects, and everybody doing work on PhpGedView (i.e., Lester and me) is careful about that. Don't forget also that Byte Order Marks (BOM), when present in PHP scripts, produce very strange and undesirable results. We're equally careful about this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Title:
Modern PHP
By:
Josh Lockhart
Publisher:
O'Reilly Media
Formats:
Print Ebook Safari Books Online
Print:
February 2015
Ebook:
February 2015
Pages:
268
Print ISBN:
978-1-4919-0501-2
| ISBN 10:
1-4919-0501-8
Chapter 3: Standards PSR-2: Basic Code Style
on page 41.
See
item 2.2 on
([http://www.php-fig.org/psr/psr-2/])
Surprised me, it did.
I'm in trouble, using tabs.
I use eclipse for php coding, turns out it has the option to
use the psr-2 format
window->preferences->PHP->Formater active profile.
--
Vince
Last edit: vince-br549 2015-12-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PhpGedView scripts use tabs extensively. What do you mean when you say they're causing you trouble? Your editor should be able to treat tabs as if they were a string of blanks. Generally, each tab in PhpGedView code is equivalent to 4 spaces.
That last URL you posted is just ONE project's opinion. PhpGedView precedes that project by a good many years. Having said that, I do agree that when a project is launched, coding style standards should be the first order of business if the project is to succeed as a collaborative effort.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, the use of tabs was not causing me trouble in phpgedview. when I said I was in trouble, it was because I was not following any of the PSR standards. My formal education dates to pre 1970. Don't recall ever hearing anything about coding style in class. It did seem to make a lot of sense to eliminate the trailing ?> which is where this discussion began.
Agreed, codeing style is, at least for me, a personel choice. These book authors, and you folks have much more experience and skill than me, I'm trying to learn and figured I could benefit from these folks, and yours! For me, I need to pick a style, and stick with it. PSR-2 since published, seems a place to land.
--
Vince
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I totally agree ... My major objection to PSR in general is that it starts from a base of replacing al tabs with spaces. Something I object to especially since the code base for developing PHP extensions IS still tab based. I'd poste another mone about PSR but it's not appeared here. I'll repost if SF has not let it through later.
Vince ... I'm Eclipse based and have been for years and I make sure any PSR rules are removed from the mix :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Vince ... basically PGV does not follow PSR2 rules, prefering a more tradtional coding style, so you will find things like replacing a single tab with 4 spaces which the PSR2 style corrector in Eclipse will implement and moving the opening brace to the next line down in some coding elements will make comparisons with the PGV code base difficult.
With regards the closing ?>, I've just checked and I don't think PSR actually demands it! It would be in PSR1 if anywhere but that just documents the dropping of the <? opening short tag, so your book is actually creating rules that do not exist ;)
For easy working with PGV and some related projects, 'PHP Convention' setting in Eclipse is top of the list for good reason ... Zend is second but shows the much more vertically expanded format that 'modern' styles seem to prefer but is not something I find any reason to change to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wrote my first program over 50 years ago, and have developed my personal style over those many years. If I'm modifying someone else's code, I try to follow whatever style the original author used.
Let's not worry about coding styles. Use whatever works for you. It's far more important to produce code that is free of bugs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This version is known to work with all versions of PHP from 5.3 right through to 7.4. I understand that it also works with PHP 8, but I haven't personally tried that.
Last edit: Gerry Kroll 2021-09-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Issue 1.
in the trunk version
In /modules/research_assistant/ra_functions.php
return 08; generates PHP Parse error:
the leading zero should be removed from all of these return statements.
Issue 2.
PHP Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /var/www/html/gedview/includes/functions/functions_print.php on line 1483,
I copied the latest functions_print.php
(
* @version $Id: functions_print.php 7115 2015-10-31 18:26:28Z sridharb $
) svn 7117.
over on top of my "old" version of gedview.
Seems to fix it.
I tried a full replacement / update of gedview and got more errors than I wanted to deal with.
PHP 7 is touted as being twice as fast as php 5.6 and taking 1/2 the memory.
May be my imagination, but gedview does seem to be faster.
My ged view data base has 19K persons, and I"m using postgresql.
Last edit: vince-br549 2015-12-27
On 27/12/15 15:37, vince-br549 wrote:
I'm not finding the function actually used anywhere, but I suspect it
needs '' around the numbers so they appear as an element of a string in
the formatted date. I think RA is actually using one of the other date
packages to do this now.
I'm not seeing a substantial speed increase on applications that are
using multiple files across multiple directories such as PGV. Only when
running code is it quicker and it needs the opcache running as well,
which only works well if you are not looking up lots of dynamic data
from databases :)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
re: adding " around the returns, the name of the function is parseMonthsToInt,
so my understanding is just remove the leading zeros. I don't consider myself a PHP expert by any streatch but....
return 8;
returns int value of 8. which was the point of the function.
where return "08"; returns a string, ahh but then PHP will handle it just fine.
I enabled opcache, so maybe that explains my perception of speed boost.
your post mingled with mine, was confused as to which were your comments and which were mine.
--
Vince
On 27/12/15 20:13, vince-br549 wrote:
I forget that SF mangles quoting ... about time there was a real
standard for messaging and one that does not use html to mess things
further ...
You are right about the 'int' ... I've been playing with code that
unmangles UK and American dates today and some routines complain if the
month is not supplied as two characters :(
I'm fighting another problem at the moment as the 'getInstance' is not
returning a class but just an array of data and I can't see at the
moment how it ever worked as there is no 'new' call in any of the code
I'm looking through ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On 27/12/15 21:20, Lester Caine wrote:
Bugger I hate PDO ... it's returning the 'INDI' as 'INDI ' add an extra
'trim' and everything bust into life!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
The research_assistant module is not actively supported by anyone.
I agree with Lester: That parseMonthsToInt function isn't used anywhere. It seems to be dead code. My vote is to remove the function or to at least comment it out. However, if it's going to remain, its code should be corrected to make PHP 7 happy. Remove those leading zeros. (My vote here: PHP 7 is dumb. What's wrong with leading zeros?)
Which is it going to be? Let me know, and I'll update SVN accordingly.
@vince-br59:
Don't pick-and-choose what you're going to run under PHP 7. There were other occurrences of the preg_replace function with the /e modifier.
You need to use the entire SVN package, but remove/delete the modules you're not going to use. My site is quite happy with just the following modules: GEDFact_assistant, JWplayer, lightbox, slideshow.
Last edit: Gerry Kroll 2015-12-28
my undrstanding is leading zeros means it is an octal value, hence the error
since there is no such octal value as 08. guessing PHP 7 reads entire file and tried to cache it, thus found the offending 08.
Being new here, where would you like me to post my php 7 results, if at all :)
I just added some more to the help forum
OK deleted research assistant code. wasn't in my old version.
getting wordy, i am. was reading a huge book on php. they suggest never ending a php file
with
?>
to prevent accidentle blank lines from mucking up the works when creating html.
tnx for listening
Yes, that leading zero indicating an octal value makes a lot of sense. That's the case in other programming languages too.
I'll update SVN to remove the leading zeros and also to comment out that apparently unused function.
OK, SVN 7118 contains the corrected use of the leading zero in that research_assistant function. It also comments-out that same function, since it's apparently not used.
@vince-br59:
What alternative does that all-knowing book of yours recommend?
We already know that blank lines preceding or following PHP code can have undesirable effects, and everybody doing work on PhpGedView (i.e., Lester and me) is careful about that. Don't forget also that Byte Order Marks (BOM), when present in PHP scripts, produce very strange and undesirable results. We're equally careful about this.
The book is:
Title:
Modern PHP
By:
Josh Lockhart
Publisher:
O'Reilly Media
Formats:
Print:
February 2015
Ebook:
February 2015
Pages:
268
Print ISBN:
978-1-4919-0501-2
| ISBN 10:
1-4919-0501-8
Chapter 3: Standards PSR-2: Basic Code Style
on page 41.
See
item 2.2 on
([http://www.php-fig.org/psr/psr-2/])
Surprised me, it did.
I'm in trouble, using tabs.
I use eclipse for php coding, turns out it has the option to
use the psr-2 format
window->preferences->PHP->Formater active profile.
--
Vince
Last edit: vince-br549 2015-12-28
PhpGedView scripts use tabs extensively. What do you mean when you say they're causing you trouble? Your editor should be able to treat tabs as if they were a string of blanks. Generally, each tab in PhpGedView code is equivalent to 4 spaces.
That last URL you posted is just ONE project's opinion. PhpGedView precedes that project by a good many years. Having said that, I do agree that when a project is launched, coding style standards should be the first order of business if the project is to succeed as a collaborative effort.
Sorry, the use of tabs was not causing me trouble in phpgedview. when I said I was in trouble, it was because I was not following any of the PSR standards. My formal education dates to pre 1970. Don't recall ever hearing anything about coding style in class. It did seem to make a lot of sense to eliminate the trailing ?> which is where this discussion began.
Agreed, codeing style is, at least for me, a personel choice. These book authors, and you folks have much more experience and skill than me, I'm trying to learn and figured I could benefit from these folks, and yours! For me, I need to pick a style, and stick with it. PSR-2 since published, seems a place to land.
--
Vince
I totally agree ... My major objection to PSR in general is that it starts from a base of replacing al tabs with spaces. Something I object to especially since the code base for developing PHP extensions IS still tab based. I'd poste another mone about PSR but it's not appeared here. I'll repost if SF has not let it through later.
Vince ... I'm Eclipse based and have been for years and I make sure any PSR rules are removed from the mix :)
Vince ... basically PGV does not follow PSR2 rules, prefering a more tradtional coding style, so you will find things like replacing a single tab with 4 spaces which the PSR2 style corrector in Eclipse will implement and moving the opening brace to the next line down in some coding elements will make comparisons with the PGV code base difficult.
With regards the closing ?>, I've just checked and I don't think PSR actually demands it! It would be in PSR1 if anywhere but that just documents the dropping of the <? opening short tag, so your book is actually creating rules that do not exist ;)
For easy working with PGV and some related projects, 'PHP Convention' setting in Eclipse is top of the list for good reason ... Zend is second but shows the much more vertically expanded format that 'modern' styles seem to prefer but is not something I find any reason to change to.
I wrote my first program over 50 years ago, and have developed my personal style over those many years. If I'm modifying someone else's code, I try to follow whatever style the original author used.
Let's not worry about coding styles. Use whatever works for you. It's far more important to produce code that is free of bugs.
Which version should be used with php7?
You should always use the most recent "SVN" version that you download by clicking the "download snapshot" link on this page:
https://sourceforge.net/p/phpgedview/svn/HEAD/tree/trunk/phpGedView/
This version is known to work with all versions of PHP from 5.3 right through to 7.4. I understand that it also works with PHP 8, but I haven't personally tried that.
Last edit: Gerry Kroll 2021-09-06