Jump to content

iwato

Members
  • Content Count

    1,355
  • Joined

  • Last visited

  • Days Won

    3

iwato last won the day on November 20

iwato had the most liked content!

Community Reputation

16 Good

2 Followers

About iwato

  • Rank
    Dedicated Member

Contact Methods

  • AIM
    moogoonghwa
  • Website URL
    http://www.grammarcaptive.com
  • Yahoo
    iddor
  • Skype
    kiusau

Profile Information

  • Gender
    Male
  • Location
    Seattle, Washington USA 98104

Previous Fields

  • Languages
    HTML, CSS, Javascript, PHP, MySQL and Spoken Language

Recent Profile Visitors

16,889 profile views
  1. iwato

    Troubleshooting MySQL's the Mecab Parser

    In most languages individual words can be sought and found because all words in a text are separated by blank spaces. For example, I have no trouble performing search and find operations for Arabic, Korean, or English. Chinese and Japanese words, however, are not separated by blank spaces and are impossible, as a result, to distinguish from their neighbors. The ngram and mecab parsers do not depend on blank spaces to perform their search, rather they search according to the number of bytes that typically make up Japanese and Chinese words: one, two, three, four, and at most five characters, generally speaking. One and two character words are the more common. The word 日本語 (Japanese language) is returned because it appears with a space before and after. The word 本質, however, is surrounded by text on either side. It is not delimited by spaces. Now, I just performed the additional MySQL command and discovered the following: SHOW STATUS LIKE 'mecab_charset'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | mecab_charset | utf8 | +---------------+-------+ 1 row in set (0.03 sec) This is additional proof that there is nothing wrong with my installation. My intuition suggests that the problem may lie with the DEFAULT CHARSET of my data table that is set to Latin. This said, changing the character set of a table can be problematic, and the columns themselves are correctly set to UTF-8. Thus, before proceeding I would like to ascertain the character set requirements for the InnoDB MySQL table when using the mecab parser. This, however, I have been unable to find. Roddy
  2. iwato

    Troubleshooting MySQL's the Mecab Parser

    I have just run TEST THREE above in the MySQL console. It produces the same result as in the SQL menu of phpMyAdmin. mysql> SELECT letter_no, letter_lang, letter_title, letter_abstract, submission_date, revision_date, MATCH (letter_title, letter_abstract, letter_body) AGAINST ("本質" IN NATURAL LANGUAGE MODE) AS letter_score FROM sevengates_letter WHERE MATCH (letter_title, letter_abstract, letter_body) AGAINST ("本質" IN NATURAL LANGUAGE MODE) ORDER BY letter_score DESC; Empty set (0.68 sec) This would explain why, in part, that no complaint is received from either PHP or MySQL, everything appears to be running fine -- simply it is not. Roddy p.s. As far as the character code is concerned the table is set to Latin, but the columns/fields in the table that are being search are set to UTF-8.
  3. iwato

    Troubleshooting MySQL's the Mecab Parser

    The code that I ran with phpMyAdmin and the code that I run with PHP when I make AJAX calls are the same. Simply, I had to substitute the ? mark with an actual term and was compelled to enter the quotation marks manually. Roddy
  4. iwato

    Troubleshooting MySQL's the Mecab Parser

    Thank you for the suggestion. This is what I discovered. The ORIGINAL SELECT letter_no, letter_lang, letter_title, letter_abstract, submission_date, revision_date, MATCH (letter_title, letter_abstract, letter_body) AGAINST (? IN NATURAL LANGUAGE MODE) AS letter_score FROM sevengates_letter WHERE MATCH (letter_title, letter_abstract, letter_body) AGAINST (? IN NATURAL LANGUAGE MODE) ORDER BY letter_score DESC TEST ONE: Insert a Japanese word that requires use of the Mecab parser to parse. SELECT letter_no, letter_lang, letter_title, letter_abstract, submission_date, revision_date, MATCH (letter_title, letter_abstract, letter_body) AGAINST (本質 IN NATURAL LANGUAGE MODE) AS letter_score FROM sevengates_letter WHERE MATCH (letter_title, letter_abstract, letter_body) AGAINST (本質 IN NATURAL LANGUAGE MODE) ORDER BY letter_score DESC RESULT ONE: Error - The Japanese word is recognized as an unidentified field or column. TEST TWO: Insert the same Japanese word delimited with single quotation marks. SELECT letter_no, letter_lang, letter_title, letter_abstract, submission_date, revision_date, MATCH (letter_title, letter_abstract, letter_body) AGAINST ('本質' IN NATURAL LANGUAGE MODE) AS letter_score FROM sevengates_letter WHERE MATCH (letter_title, letter_abstract, letter_body) AGAINST ('本質' IN NATURAL LANGUAGE MODE) ORDER BY letter_score DESC RESULT TWO: No error is generated. Neither, however, is a match found. TEST THREE: Insert the same Japanese word delimited with double quotation marks. SELECT letter_no, letter_lang, letter_title, letter_abstract, submission_date, revision_date, MATCH (letter_title, letter_abstract, letter_body) AGAINST ("本質" IN NATURAL LANGUAGE MODE) AS letter_score FROM sevengates_letter WHERE MATCH (letter_title, letter_abstract, letter_body) AGAINST ("本質" IN NATURAL LANGUAGE MODE) ORDER BY letter_score DESC RESULT THREE: No error is generated. Neither, however, is a match found. Please advise further. Roddy
  5. 0 down vote favorite BACKGROUND: I have built a custom search engine that works fine in English, but fails in Japanese, this despite confirmation from my host server that I have performed the installation of the Japanese mecab parser correctly. My own checks reveal the following: 1) SHOW CREATE TABLE: FULLTEXT KEY search_newsletter (letter_title, letter_abstract, letter_body) /*!50100 WITH PARSER mecab */ ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1 2) SHOW PLUGINS: ngram | ACTIVE | FTPARSER | NULL | GPL | mecab | ACTIVE | FTPARSER | libpluginmecab.so | GPL IMPLEMENTATION 1) MYSQL Statement: $sql ="SELECT letter_no, letter_lang, letter_title, letter_abstract, submission_date, revision_date, MATCH (letter_title, letter_abstract, letter_body) AGAINST (? IN NATURAL LANGUAGE MODE) AS letter_score FROM sevengates_letter WHERE MATCH (letter_title, letter_abstract, letter_body) AGAINST (? IN NATURAL LANGUAGE MODE) ORDER BY letter_score DESC"; 2) CUSTOM SEARCH ENGINE: See under Local Search / Newsletters at https://www.grammarcaptive.com/overview.html 3) DOCUMENT SEARCHED: See under Regular Updates / Newsletter / Archives / Japanese at https://www.grammarcaptive.com/overview.html COMMENT: Neither PHP, nor MySQL complains. Simply any Japanese word search that needs to be parsed is not returned. For example, the word 日本語 can be search and found, but does not require any parsing to be retrieved. The search for any other Japanese word in the newsletter fails. REQUEST: Any troubleshooting tips would be greatly appreciated. Roddy
  6. iwato

    External Link and the Onclick() Function

    Dsonesuk: I am not sure that I understand what you are recommending. Is it Create a div and a function on the current page that is triggered when this div is clicked. Load with this click only that portion of the page to which the current page links and contains the link whose normal functioning I wish to suppress and replace with some other function. Activate this some-other-function. If it is not, please elaborate further. If it is, please confirm. Roddy
  7. iwato

    SwiftMailer - An Odyssey of Reconstruction

    The reason for this assumption is that I have run into a lot of junk in my brief two years of coding. In any case, the problem has been resolved by resetting the PHP bin path for my server's CRONTAB. Further, my first scheduled email using Peppe Occhi's CRON Scheduler has been received along with the output for my newly installed CRON Scheduler CRON job. Finally, a credit on the Grammar Captive webpage has been posted for both Peppe Occhi and Symphony under the headings CRON Scheduler and SwiftMailer in the CREDITS section of the Grammar Captive mainpage. Hooray! Hooray! Once again, thank you W3Schools. Roddy
  8. iwato

    SwiftMailer - An Odyssey of Reconstruction

    No, I did not look up the operator, for it made no sense. What did make sense was a typo. Then, I looked at the surrounding code and tried to understand what was going on. After which I played with it until I found something that made sense and PHP no longer complained. I made a dozen other similar corrections on a variety of pages before I finally stumbled with PHP rejecting its own CORE function. Roddy
  9. iwato

    SwiftMailer - An Odyssey of Reconstruction

    $this->addressEncoder = !empty($addressEncoder) ? $addressEncoder : new Swift_AddressEncoder_IdnAddressEncoder(); This is exactly what I did do and moved onto the next error and correction, but before going any further let us wait until I have clarified with my host provider why all of my CRONTAB jobs are pointed to 5.6 and my default and domain settings are pointing to 7.2. This now appears to be the likely source of the problem, for after all, the scheduler.php that I set up depends on the CRONTAB for its existence. Roddy
  10. iwato

    SwiftMailer - An Odyssey of Reconstruction

    OK. I had lunch in between, but here it is: the first reported error. public function __construct(Swift_Transport_IoBuffer $buf, Swift_Events_EventDispatcher $dispatcher, $localDomain = '127.0.0.1', Swift_AddressEncoder $addressEncoder = null) { $this->buffer = $buf; $this->eventDispatcher = $dispatcher; $this->addressEncoder = $addressEncoder ?? new Swift_AddressEncoder_IdnAddressEncoder(); $this->setLocalDomain($localDomain); } The line indicated by PHP as the source of error. $this->addressEncoder = $addressEncoder ?? new Swift_AddressEncoder_IdnAddressEncoder(); If you need the error message, here is that as well. [19-Nov-2018 21:38:02 UTC] PHP Parse error: syntax error, unexpected '?' in /home/thege0/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php on line 53 Roddy p.s. The software was downloaded and installed with no version requirement using the following command. If I remember correctly, in the absence of a version number Composer provides automatically the most recent stable version. [...@vps ~]$ php composer.phar require swiftmailer/swiftmailer
  11. iwato

    SwiftMailer - An Odyssey of Reconstruction

    With your and Ingolme's insistence that the problem lies with the PHP version I have performed a little exploration and discovered that the bin folder path to the PHP binary file for my CRONTAB is set to PHP 5.6 and not to PHP 7.2 as are my primary domain and each of my add-on domains that employ PHP. I have notified my webserver host in regard to this inconsistency and am waiting for their reply. You see, Swiftmailer is used by CRON Scheduler to deliver notification about the successful execution of CRON jobs. Is it not likely then that the same version of PHP is used to run both pieces of software? In any case, I have already removed Swiftmailer and am in the process of reinstalling it. Further, changing the version of PHP should have no effect on the defective PHP code that I was compelled to modify in order to get SwiftMailer to even execute up to the point where the random_bytes( ) CORE function was needed. Hopefully, I will be back in a short while with the first problematic piece of SwiftMailer code. Roddy
  12. iwato

    SwiftMailer - An Odyssey of Reconstruction

    I have an easier and perhaps more informative way of achieving the same: [...@vps ~]$ php -v ea-php-cli Copyright 2017 cPanel, Inc. PHP 7.2.12 (cli) (built: Nov 13 2018 21:12:16) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies Roddy
  13. iwato

    SwiftMailer - An Odyssey of Reconstruction

    OK. I will uninstall and reinstall the software. However, rather than editing the software as I did before and thereby removing each and every fatal error that I encountered until PHP told that a PHP CORE function does not work. I will let the mentorship of W3Schools have a look at the code and error first. Indeed, what I expected to hear from y'all, I did not -- namely, that the PHP error regarding the random_bytes() function is not the true source of the error, and that something in the preceding line of code is triggering it -- say a call to a faulty class that I had perhaps created during one of my many edits. I am looking forward to a very interesting and perhaps even enlightening week with W3Schools for all concerned. Roddy
  14. iwato

    SwiftMailer - An Odyssey of Reconstruction

    The syntax errors that I showed you have been corrected file after file after file. Were I to retrace the errors I would have to reinstall the software and start all over again. It were as if the authors were trying to show the painstaking work that they went through to create the software, or alternatively all of the different ways that it could be adapted to specific needs. This is what I meant when I said it is software designed for professionals. Roddy
  15. BACKGROUND: I have a page with a link whose normal behavior is suppressed in order to make room for a script that produces a gallery of frames when the new page opens. The LINK <div class="moji"> <a id='hito_rireki' onclick="return false;" href="Emblem/hito.html"> <img src="Emblem/_Images/to.gif" width="105" height="90" alt="(人という文字) The Sino-Japanese Character for Person" title="クリックして下さい!" /> </a> </div> QUESTION: Is there a way to trigger this same link from a completely different page that does not involve the use of a GET or POST HTTPRequest? Roddy
×