Recent articles from FAQ

Parser is a simple and convenient object-oriented language, which allows creating good sites in short time. Parser was started in Art. Lebedev studio in 1997. Nowadays, most of sites created by Art. Lebedev studio are made with Parser.

Language is designed and optimized in such a way that it would be more convenient to create good sites. Language supports working with forms, cookies, table files, databases, and XML. Support for user operators and classes allows to extend its functionality.

You can gradually change files of existing site to include Parser constructions, for instance, by describing page titles and tables of HTML-document with Parser methods, using environment variables with Parser, simplify form-processing. Or you can plan convinient site internal stricture from scratch, and write code relying on all Parser abilities. Parser is not a replacement of HTML-code, Parser is the way of generating it.
That is why it’s very easy to change things—you can always see what changed as a result of this or that command.

Parser is, among other things, a macro-language. It has no print operator; all the code in source file is, in fact, a big print operator. Parser syntax is immersed into text. That is, you do not write program that outputs text. On the contrary, you add logic to already existing text, ^if(condition){action}, and organize it by splitting HTML-code into blocks like:

@header[]

...
@footer[]
...
@navigation[]
...
@body[]
...

All project source code are available at  CVS server:
You can build it with Unix/Cygwin, standard for GNU project set of files—INSTALL, configure and Makefiles, and with Microsoft Visual Studio 2003+.
We welcome all additions and enchanecements.

cvs -d :pserver:anonymous@cvs.parser.ru:/parser3project login
Empty password.
cvs -d :pserver:anonymous@cvs.parser.ru:/parser3project co -r release_3_3_4 parser3

There are also serveral other modules in repositary, see “Compiling Parser from source code” section in documentation.

In Art. Lebedev studio we are absolutely sure that no proprietary technology can stay up-to-date and actual. Always there would appear something new which will superceed technologies of previous generation. By making Parser available for everybody fo free we want to compete with nobody in a field of site-creating tools. Wide spread Parser usage would help the technology be up-to-date. Proprietary technologies are comparatively narrower and slower. We do not sell a tool, we give it for free to anyone who wants it, hoping that this will help people.

PHP is a programming language requiring appropriate training. Parser has simple tools that resolve complex tasks and is especially good in that it allows mere mortals to create and maintain complex dynamic sites without spending too much time.

Not claiming that this is thorough analisys:

Parser is macrolanguage, there is no print operator, while PHP syntax is more like C. Hence Parser itself is template processor, while PHP requires to use some template-processing library.
In Parser UTF-8 is built into language and is transparent for developer, while in PHP it is set of functions.
In Parser there is unified interface to work with database servers, including large text fields, while in PHP for each SQL server it’s individual set of functions.
Parser extensively uses object technology even in system types—string is an object with methods, while in PHP there is just set of functions to work with strings.
In Parser it is much more easier to use XML and XSL, than in PHP.
In Parser there is system type table, while in PHP there is no.
In Parser caching function is built-in, while in PHP it is not.
Parser implements throughout automatic user input handling-that is, when, for example, in SQL statement you would get ' fixed to '', while PHP has only rudimentary support.

Parser which is compiled in safe mode (by default) protects other users who are hosted on that same server as you do from your errors. That is even if you would write a page, where in a form somebody can enter Parser code, and after submit it got executed, this code can never get access to files belonging to other users of the server, even if administrator of the server would not take additional measures to provide security for other server users.

On the safety of your site Parser in safe mode influences rather indirectly, not allowing, for example, to run:

rm -rf

or to write some script to disk, which would do something bad to your data—that is Parser would allow write a script to disk, but would not allow to grant it a right to execute (there is no chmod function in Parser, and there is no way to call system chmod program).

Roughly speaking, safe mode Parser allows administrators to pay less attention to security settings when they configure server, and if site developer maked a mistake Parser makes it difficult to cause harm  your site.
Resume: safe mode Parser (default) is more safe by defenition, regardles of security settings of particular hosting provider.

Example: from unsafe mode one can

^exec[/../../bin/rm -rf /]

while from safe mode—can not. In case of commertial hosting, part of this protection is doubled by hosting provider (because not all scripts are as “right” as Parser). But only part, Parser does that it in full.

To do this you should add to Apache configuration files .htaccess or httpd.conf (section <virtualhost>) these lines (it is assumed, that /cgi-bin referres to directory, configured in ScriptAlias in httpd.conf):

AddHandler parsed-html html
Action parsed-html /cgi-bin/parser3.cgi

Also one can Install Parser on Apache web-server as server module.

Start Management Console, click right mouse button on the name of your web-site and select “Properties”.
Go to “Home directory” sheet and in “Application settings” section click “Configuration...” button. In opened dialog box click “Add” button.
In “Executable” field type full name of CGI-script parser3.exe or ISAPI extension parser3isapi.dll.
In “Extension” field type “.html”.
Switch “Check that file exists” checkbox on.
Click “OK” button. Then in Web Site Properties dialog go to “Documents” sheet, and addindex.html to the list of files, used as index documents.
We also recommend you to remove handlers of those file name extensions which you do not use.

Binaries of CGI version of Parser for *nix in download section are compiled in SAFE MODE. Such Parser checks group and owner of a file before reading it, and reads only those files, group or owner of which are same as group or owner of the process in which Parser works.

This is done on purpose, so that in case of error in a script malicious users would not exploit it and get access to the files they never need any access, such as /etc/passwd.

It is sometimes the case when system administrator configured your web-server in such a way that group and user, on behalf of which CGI process works (Group and User directives in httpd.conf, for Apache) do not match niether group nor user to which belong files created by you.

In that case you would get the message “…safe mode…”
Possible steps:
Ask your system administrator to read this message, he/she would understand it.
If you feel like it, Compile Parser from source code and turn that option off.

Look into error log file of web-server, and also into suexec.log (if you have it), there you would find detailed description of what have happened.
Typicaly error “Premature end of script headers” means that you have forgotten to set the “executable” bit or have chosen the version of Parser which does not match your server operating system (ask system administrator what is it).
Also the reason could be that you uploaded to server an executable file NOT in binary mode. In that case size of uploaded file would differ from that of file on your local disk.
Another reason could be that you have a typo error in .htaccess file, log file record would countain detailed information on what’s wrong.
If you would see some other error in a log file, it’s text would suggest you how to fix it.

We guess, that by “browser” you mean MSIE and you forgot that by default in this browser
[x] Friendly HTTP error messages
are displayed. This option tells browser, that when it gets HTTP response which size is less then 512 bytes it should not display that response, but rather browser’s own error message. Hence, this is fixed by turning this MSIE option off.

Parser is not assigned as a handler of your documents after all.
To test whether Parser itself works, type this in your browser's address line:
http://your_site/cgi-bin/parser3.cgi (or .exe, for Win32 version) You should see something like this:

Parser/3.x.x

If you can see it, that means Parser is uploaded where it should have been, and its rights are set correctly.

If you have uploaded parser correctly, and you have not forgotten to put directives specified in documentation to .htaccess, you may have forgotten to allow Apache to process .htaccess in httpd.conf file by directive AllowOverride (see Apache documentation). To check whether .htaccess is processed, put there some arbitrary wrong instruction, say «mytest», to the very beginning of it. If, after page reload you do NOT see 500 error (which must appear if you configured everything right), that means you have .htaccess file ignored. Change AllowOverride directive or turn to your administrator.

To test Parser, download from appropriate section a test document, unpack it to webspace of your site and open it in from your site in a browser.
This document tries to run several tests and reports results. You can see sample results here.

Yes, sure. Refer directly to Parser and it whould report its version.

Sure. But they must be prefixed by “^” character. For instance, if you need to output a semicolon-separated list:

^table.menu{…}[^; ]

Read about External and internal data in documentation.

Make yourself a useful operator, see section “User-defined operators” in documentation.

Use

${name}.jpg

Why? Because there should be destinction between this and…

$table.field

…this. So Parser would know that dot is not part of syntax, and does not mean that Parser should get “jpg” field of ”name” object.

According to documentation this code outputs value of one variable named a$b. To output values of two variables, separated by nothing, you should use ${a}${b} code, or simplier: ${a}$b

The thing is that ^#0A is equivalent of newline character in person. By such code we create a table with empty first line. For the Parser NOT to understand that character as a table line delimiter, it should be “tainted”. Fix your code:

$tReplace[^table::create{from	to
^taint[^#0A]	<p>}]

And after calling ^sMyString.replace[$tReplace] all newline characters would be replaced to <p>

Starting with version 3.4.4. tables can be edited. Now it is possible to change a cell value and to insert a row ($t.name[value] and ^t.insert{row}).

You can consult documentation and learn how to create your own for operator, which would behave like you need.
Particularly, there is an example of steppedfor operator which works like for, but has “step” parameter:

@steppedfor[name;from;to;step;code]
$caller.$name($from)
^while($caller.$name<=$to){
    $code
    ^caller.$name.inc($step)
}

Now you can write…

@somewhere[][i]
^steppedfor[i](1;10;2){$i }

…local variable of somewhere method is changed.

After referring to documentation we write user-define operator, which then use instead of foreach method:

@foreach[h;key;value;code;order_direction][tkey]
$tkey[^h._keys[]]
^tkey.sort{$tkey.key}[^if(def $order_direction){$order_direction}{asc}]
^tkey.menu{
    $caller.$key[$tkey.key]
    $caller.$value[$h.[$tkey.key]]
    $code
}

Example of usage:

^foreach[$myhash;k;v]{
    key=$k
    value=$v
}[desc]

How they say in documentation, when parser meets unhandled exception it calls @unhandled_exception[], which is declared in default configuration file auto.p from Parser distribution. It is bad to show errors to visitors, so, by default, @unhandled_exception_release[] is called from @unhandled_exception[], which only reports that error occured (Unhandled Exception), and suggests to look for details in parser3.log, or switch on debug mode, so then error messages would output right to browser. To turn this debug mode on you need to modify auto.p file so @unhandled_exception[] would call @unhandled_exception_debug[] instead.

Usually this is это unbalanced brackets or forgotten ’^’ prefix before special parser characters ’;’, ’^’, ’$’ and others.
If you want character ’;’ to be shown, you need to write it as ’^;’ in your code. As a metter of principle, this is not always needed, but if you would use that form—it would do no harm ;)

This means that you call an operator and are trying to pass it less parameters then it requires. Most frequently this error occurs when you type spaces or newlines between method parameter braces.

This means that you call an method and are trying to pass it more parameters then it can accept. Most frequently this error occurs when you pass a method some string containing special characters, most likely character “;”, and forgetting to prefix them with “^”. Parser regards this character as a delimiter of method parameters.

The code is trying to output an object which can not be represented as a string automatically. For example, if in the middle of page text use there would be ^date::now[] we would get this error. To show a date object, one must do about this:
$now[^date::now[]]
^now.sql-string[]
Same applies to table, hash and other objects.

You are trying to code with @USE or ^use[] but never set configuration variable $MAIN:CLASS_PATH. So Parser does not know where to look for class modules you are trying to link. Details are in documentation.

Module with operators or classes you are trying to link by @USE or ^use[] was not found along paths specified in configuration variable $MAIN:CLASS_PATH.
Frequently this problem is due to some white space after name of file with the module to be linked.
Also is could be that after @USE and list of modules one forgets to declare method @main[] and start their code right there, assuming that it would automatically become main.

Not configured or not does not exist configuration file auto.p (located beside parser3.cgi). To test things quickly—download from appropriate section test document, unpack it to webspace of your site, and open it in browser.
For this file to be able to check all paths you would need to change configuration file auto.p and specify an absolute path in $confdir.

Parser requires other version of sql driver (libparser3mysql.so) then installed.
The reason is likely in that you moved from one Parser version to other, but forgot to update your sql driver.

An attempt to execute some SQL query is taking place (^table::sql{}, ^int:sql{} and others) outside of an operator for connecting to DB ^connect[connect strings]{queries here}.

The one who configured your Parser either forgot to put suggested configuration file or spoiled it.
By default, if $request:charset is not specified (now is good moment to take a look at documentation) it is UTF-8.
Parser were not told in which charset are all its documents($request:charset) so it thinks they all are in UTF-8.
Hence if one asks to transcode something from UTF-8 to windows-1251 (by defining $response:charset) and on transform input there would be a text in windows-1251, Parser would protest.

Such message appeares if Parser detects too long a cycle. For instance, if your would use the code ^while(1){something} you would see this message. Moreover, if you would use for or menu which would iterate more then 20000 times, you’d see it too.

You would see this message if Parser would think your code went into endless cycle. Usually the reason is incorrect or too deep a recoursion (more then 1000 subcalls).

When an answer from CGI-script is no longer needed by the client of web-server, for instance when user pressed the Stop button or connection were lost, web-server sends a script a signal “Hey, your output is no longer needed”. Starting from 3.0.0007 version Parser intercepts this signal and creates an error “parser.interrupted”.
But in case Parser were run but not started to process the request, or, on the contrary, the request were already been processed the fact got recorded to log file by that record.

You can always catch Parser exception "file.missing" and display /404.html instead yourself. Method @unhandled_exception can be changed like this:

@unhandled_exception[exception;stack]
^if(^env:REMOTE_ADDR.match[^^developer (your) IP address]){
	^unhandled_exception_debug[$exception;$stack]
}{
	^if($exception.type eq "file.missing"){
		^rem{*** if there is no file, doing internal ***}
		^rem{*** redirect to the page with 404 error ***}
		^rem{*** and don't forget about $response:status(404) on that page ***}
		$response:location[/404/]
	}{
		^unhandled_exception_release[$exception;$stack]
	}
}

Before posting a question do try to find an answer in FAQ, in documentation and in forum.

If you couldn’t find an answer to your question, ask it in forum sticking to these rules:
1. Put an idea of your question to subject line. Subjects like ’Help’, or ’I don’t know what to do’ won’t really mean anything, so you are likely to get little attention
2. In message body put what you wanted to get, what you did, and what you did get
3. Remember that others would try to help you to solve your problem solely reading the description you’ve provided, so try to describe everything in detail, sequentally, try to reduce slang and other things, reducing readability of your post.

If your question is about Parser code:
1. Provide relevant piece of this code (do not post 10 pages of code, nobody will read it)
2. It’s preferable to post code in pseudotags [code][/code]. This would help others to read it.
3. Indicate precise version of Parser/web-server/OS used.

If your question is not about Parser, but rather about Apache, MySQL, IIS, etc-do not forget to search for answer in corresponding documentations (google is also very useful, especially searching in groups).
Have you written it? Now thoroughly re-read your message. In 80% cases it already contains an answer to your question.

You sould read about “format commands in forum” and use them.

In some mail clients you can do that.
1. configure message filter so that messages from forum would get to separate folder
2a. The Bat!: for this folder select: View|View threads by|References
2b. Outlook Express: View|Current View... (*) Group messages by conversation

Those in black are registered users which logged under registered name, while those in grey were not logged on.

These are threads, in which currently logged-in user has ever participated. This mode is available only to logged-in users. There’s no point in sending a link to any of pages of “My threads”, nobody but you will see the page the way you see it.

The first is the posting timestamp, while the second is last modification timestamp. You can modify your own message unless somebody has already replied to it.
P. S. Moderator can only erase messages, but not change them.

You can edit your message only until somebody replies to it.

Messages with red timestamps are new.
By default, ’New’ messages are those posted less then 72 hours ago. Registered users can set an option in a forum profile to make ’new’ mean ’those posted after the time I last logged in’.

It means, that this message has no “body”, e.g. one may not click it, there’s nothing more to see then the subject line. This mark is set automatically, there’s no need to type it in by hand. A link is there for those who’d like to reply to the message.