Forum OpenACS Development: XoWiki 0.36

Collapse
Posted by Gustaf Neumann on

Changes in XoWiki 0.36 (relative to 0.35) and in XOTcl Core 0.43 (relative to 0.42) XOTcl Request Monitor 0.38 (relative to 0.37)

  • Implementation Issue: Specification of evaluation contexts

    xotcl-core contains new classes ::xo::Context and ::xo::ConnectionContext to define the evaluation context for webpages or included matters. Evaluation contexts are somewhat similar to an activation record in programming languages. They combine the parameter declaration (e.g. of a page, an includelet) with the actual parameters (specified in an includelet) and the provided query values (from the url). The parameter declaration are actually implemented via XOTcl's non positional arguments and use their syntax and semantics. The connection context is a context with user and url-specific information

    The contexts are used in XoWiki 0.36 via Package initialize ... similar to page_contracts and they are used as well included content (includelets and for including XoWiki pages in other applications), and used for per-connection caching as well. They are used as well in the xotcl-request monitor. For the simplified inclusion of XoWiki pages in other applications see xowiki/lib/view.tcl. The including page needs essentially:

    <include src="/packages/xowiki/lib/view" url="/xowiki/en/index">

    The intention is of the connection context is similar as with ad_conn, but based on objects and integrated with calling conventions.

    So far, it is pretty simple, but should get more clever in the future. The idea is to allow better testing scripts, which are independent of connection information from the aolserver (ns_conn). We are not there yet, but we are getting closer. Another idea is to use lazy (or demand-driven) initialization, but this will require a new XOTcl release.

  • Prototypes

    XoWiki 0.36 supports the concept of a prototypes. XoWiki prototypes are objects (any kind of XoWiki pages) which are available in a directory (named .../prototypes) and available in every XoWiki instance. when a prototype is called, it is instantiated and added to the list of pages of a folder. Whenever it is updated, new revision add added to the content repository. However, the original prototype on disk does not change and can be tailored for other applications in maybe different ways. This is somewhat similar to prototype based languages such as self, where new objects are created through cloning and modified as needed.

    Here are a few examples of prototypes:

    a) A sample index page of type ::xowiki::Page with the Title "Index Page":

    ::xowiki::Page new -title "Index Page" -text {

      <p>This is the default start page of XoWiki. You can edit this page and
      save it to provide a personalized look of the XoWiki instance......</p>
      >>left-col<<
      {{recent -max_entries 25}}
      >><<
      >>right-col<<
      {{last-visited -title "Last Visited" -max_entries 10 }}
      <br>
      {{most-popular -title "Most Popular" -max_entries 10 }}
      >><<
    }

    b) A sample object page with active content:

    ::xowiki::Object new -title "CGI" -text {

       proc content {} {
       return "Hello World. It is now [clock format [clock seconds]]."
       }

    }

    The following prototypes are included in XoWiki 0.36:

    • ./www/prototypes/ajax-chat.page
    • ./www/prototypes/categories-portlet.page
    • ./www/prototypes/CGI.page
    • ./www/prototypes/CGI2.page
    • ./www/prototypes/CGI3.page
    • ./www/prototypes/index.page
    • ./www/prototypes/weblog-portlet.page
    • ./www/prototypes/weblog.page

  • Direct includes of computed HTML chunks

    XoWiki 0.36 supports in addition to the adp includes a light-weight means for including content in pages. With the syntax for included matters (double braces) one can either include different XoWiki pages or instances of the portlets classes ::xowiki::Portlet; when these are evaluated, their occurrences are replaced with the computed HTML content. These includelets can be parameterized with the usual non-positional argument syntax. In the example above, recent, last-visited and most-popular are such instances.

    The old, adp-style includelets are still in the package, but are deprecated and with be removed in the future.

  • Weblog and Categories

    The weblog includelet is now configurable to much higher degree. It is now possible to define from the prototype page different kinds of listings by redefining the templates for weblog entries and the whole weblog. The prototype page is called weblog-portlet. The prototype for the full weblog application (with weblog-calender, private and public tags and categories) is still called weblog.

    The filtering options of the weblog-portlet allow now as well filtering for multiple criteria to show e.g. only those entries, which are assigned to two categories (such as XOTcl and introduction).

    Similarly, the categories includelet allows to specify to show only entries which must not be assigned to certain categories. One can specify now, list the categories for a certain category (e.g. XOTcl) but not those in e.g. introduction and testing.

    The combination of the weblog and categories portlets allow to develop different kind of applications (e.g. a news management for different kind of news entries) with little or no programming effort.

    I have not solved the problem with (indirect) recursive nesting yet. For the time being the weblog does not show pages with page names containing "weblog". If an xowiki instance needs multiple weblog views their names (not titles) should include "weblog".s

  • Security Management:

    XoWiki allows now the specification of site wide admin (swa) in security policies. This means, that only site wide admins are allowed to execute some commands. Links leading to these functions will only appear for site wide admins.

    Furthermore there is a new package parameter: security_policy. A package administrator can switch now between two policies (::xowiki::policy1 and ::xowiki::policy2).

    Policy1 requires for all destructive operations (deletes, delete_revision) and programmatical operations (involving Tcl code, e.g. editing the ::xotcl::Objects) package admin rights, for re-index site wide admin right). Policy 2 requires also for destructive operations site wide admin rights.

  • Database Interaction Improvements

    The new XOTcl method db_1row runs in the scope of an XOTcl object. That means that the output variables are directly added as instance variables of the specified object.

    The generic content repository classes got extended by a faster method to get a bag of objects out of the database. This is convenient to avoid to run out of database pools for nested db_foreach. The new method instantiate_objects is used in the weblog implementation and can be used like: set answer_set [::xowiki::Page instantiate_objects -sql "select ... from ..."] foreach c [$answer_set children] { ns_log notice [$c serialize] }

  • Better handling of notifications.

    Notifications are now decoupled of the data-source service contract and use the above contexts, provide nicer subject lines, which are more suitable for mail-filters. We exclude objects of type ::xowiki::PageTemplate and ::xowiki::Object from notification.

  • Improved Serializer

    The new method serialize is available for all XOTcl objects. The serializer provides a better handling of cyclical dependencies, when mixins are involved. It contains a fix for namespace handling to make the XOTcl communication library classes working with the aolserver (thanks for Stefan Sobernig for pointing this out). Now other ::xotcl::* objects can be included in the aolserver blueprint (e.g. non positional argument handlers)

    Since the serializer is distributed with XOTcl, this change would require a new XOTcl release (which is pending). For the time being, i have included the fixes in xotcl-core.

  • Numerous other Changes:
    • Improved handling of return_urls (e.g. in XoWiki pages included in other apps, as well on the admin pages)
    • Implemented a second delete method for admins, that allows to delete objects even when they cant be instantiated (from admin pages)
    • More general page_name lookup (using prototypes) and error handling
    • ::xo::show_stack included
    • More reliable clean-up management for deleting objects after a connection is closed ( destroy_on_cleanup)
    • Allow to filter weblog entries for multiple categories (show only entries contained in all given categories) One of the three delivery methods of the XoWiki chat (streaming) has some troubles currently (maybe a problem with the current firefox); for now, we use the two other methods...
    • Overall improvement of code structure
    • Dave's patch for return_url handing in edit_new
    • Stan's patch for background delivery
So, i hope, i have this time all files checked in. The documentation in the handbook will follow. From the weekend until Sept. 1, i will be on vacation without internet access, so i won't be able to answer any kind of questions.
Collapse
2: Re: XoWiki 0.36 (response to 1)
Posted by Stan Kaufman on
Gustaf, this is an astounding advance. How do you accomplish this much in 24 hours per day?? Many thanks!!
Collapse
3: Re: XoWiki 0.36 (response to 1)
Posted by Carl Robert Blesius on
Incredible progress Gustaf.

In the time period we need to upgrade, test, and launch what we think is the newest version of xowiki you release another one (and we have Dave helping)!

I took some time today to test some of the very cool things you have added (e.g. I really like the new lightweight includlet feature and the examples you included). Thank you again for your amazing work. A lot of people are benefiting from it.

Enjoy your vacation.

Collapse
4: Re: XoWiki 0.36 (response to 1)
Posted by Stan Kaufman on
Hmm...in a fresh install (oacs-5-2, xowiki 0.36, xotcl-core 0.43), there is something weird going on. The main xowiki page generates this server error:

invalid command name "::xowiki::Package"
    while executing
"::xowiki::Package initialize -ad_doc {

  This is the resolver for this package. It turns a request into
  an object and executes the object with the ..."
    (file "/web/oacs52/packages/xowiki/www/index.vuh" line 2)
    invoked from within
"source [ad_conn file]"
    (procedure "rp_handle_tcl_request" line 3)
    invoked from within
"$handler"
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
                $handler
            } ad_script_abort val {
                # do nothing
            }"
    invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "rp_serve_abstract_file" line 60)
    invoked from within
"rp_serve_abstract_file "$root/$path""
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
            rp_serve_abstract_file "$root/$path"
            set tcl_url2file([ad_conn url]) [ad_conn file]
            set tcl_url2path_info..."

And looking through the xotcl classes in the API browser (/xotcl/), ::xowiki::Package no longer appears in the list. Somehow it's not getting initialized even though it appears to be defined in /xowiki/tcl/package-procs.tcl. The error log during installation shows this problem sourcing that file, though:

[17/Aug/2006:17:20:59][11723.2684358124][-main-] Error: Error sourcing /web/oacs52/packages/xowiki/tcl/package-procs.tcl:
invalid command name "::xo::PackageMgr"
    while executing
"::xo::PackageMgr create Package  -superclass ::xo::Package  -parameter {{folder_id "[::xo::cc query_parameter folder_id 0]"}}"
    (in namespace eval "::xowiki" script line 3)
    invoked from within
"namespace eval ::xowiki {

  ::xo::PackageMgr create Package \
      -superclass ::xo::Package \
      -parameter {{folder_id "[::xo::cc query_paramet..."
    (file "/web/oacs52/packages/xowiki/tcl/package-procs.tcl" line 1)
...etc

And indeed, I can't grep any definition of ::xo::PackageMgr in either xotcl-core or xowiki.

There's another problem in the error log during installation:

[17/Aug/2006:17:20:59][11723.2684358124][-main-] Error: Error sourcing /web/oacs52/packages/xowiki/tcl/xowiki-portlet-procs.tcl:
expected a list of classes but got ::xo::Context
    ::xowiki::Portlet ::xotcl::Class->superclass
    ::xowiki::Portlet ::xotcl::Object->configure
    ::xotcl::Class ::xotcl::Class->create
    invoked from within
"Class create ::xowiki::Portlet  -superclass ::xo::Context  -parameter {{name ""} {title ""} {__decoration "portlet"}}"
    (in namespace eval "::xowiki::portlet" script line 2)
...etc

Not sure what this means.

Gustaf, before you go on your well-deserved holiday, can you have a look at this? Many thanks!

Collapse
5: Re: XoWiki 0.36 (response to 4)
Posted by Gustaf Neumann on
Sorry, i missed to add a file in xotcl-core. Should be fine after an update of xotcl-core from cvs head and a restart.

-gustaf

Collapse
6: Re: XoWiki 0.36 (response to 5)
Posted by Stan Kaufman on
Many thanks, Gustaf! That fixes everything! Have a most excellent holiday!
Collapse
7: Re: XoWiki 0.36 (response to 1)
Posted by Matthew Burke on
I should've left well enough alone. I finally got xowiki 0.33 working and decided to move up to xowiki 0.36. Upgrading didn't work---When I got to /xowiki all I get is a web page that tells me "File not found". No errors in the log, etc.

I also tried a completely clean install using xowiki and xotcl-core off of HEAD but I get the same error. I don't have a good idea on where to start tracking this down, so any hints would be appreciated.

Collapse
8: Re: XoWiki 0.36 (response to 7)
Posted by Stan Kaufman on
Matthew, what do you mean by a "clean install"? Do you have both xowiki 0.36 and xotcl-core 0.43? Have you started with a completely clean install of the db or at least restarted the server? I've had no trouble running xowiki 0.36 and xotcl-core 0.43 on an oacs-5-2 system. I have seen the "File not found" error when I forgot to use the latest xotcl-core version (back when Gustaf was upgrading both packages rapidly).
Collapse
11: Re: XoWiki 0.36 (response to 8)
Posted by Matthew Burke on
Yeah, clean install of the db and did a cvs update to get xotcl-core 0.43 and xowiki 0.36.

I tried again, this time wiping the two package dirs and getting them from CVS once again and now eveything works.

Collapse
12: Re: XoWiki 0.36 (response to 11)
Posted by Michael Steigman on
A clean install isn't an option here. I want to install it into a working system. I reloaded the production DB into the dev environment and tried installed the latest xowiki/xotcl-core from HEAD (w/o the upgrade I had to go through after installing xotcl-core from the repository) and see the same behavior. Both packages appear to be enabled and I don't see any problems in the log regarding either package on server restart. I see this in the log when trying to access an xowiki package instance:

[25/Aug/2006:13:49:54][4915.1091598688][-conn:x-dev::4] Notice: --after adp, ::262 ::xowiki::Package->return_page (204ms, 43ms)
[25/Aug/2006:13:49:54][4915.1091598688][-conn:x-dev::4] Notice: --i ::262 DONE, ::262 -> (205ms, 0ms)

Collapse
13: Re: XoWiki 0.36 (response to 12)
Posted by Stan Kaufman on
Yeah, there are some issues Gustaf will need to look at when he gets back from vacation. It doesn't seem likely that this bug is actually related to your problem (since a fresh install doesn't generate your problem). But it's clear that Gustaf has been refining things rapidly, so I would imagine that the packages will settle out soon.
Collapse
14: Re: XoWiki 0.36 (response to 12)
Posted by Gustaf Neumann on
Concerning updates for the last few releases of xowiki:
some files were removed in the newer xowiki from cvs, which do harm the new version (now most requests are handled by index.vuh, so if there is e.g. a left-over www/view.tcl, it will mess up).

so, i would recommend for the upgrade to rename the old packages/xowiki directory and check out a fresh version from cvs. The rest should be done by the update scripts.

-gustaf

Collapse
15: Re: XoWiki 0.36 (response to 14)
Posted by Michael Steigman on
Checked out stuff from scratch again from CVS. Reinstalled and restarted with pretty much the same result:

Error:

No page 'wiki/' available.

In the logs (a bit further up - probably didn't notice these last week):

snip...
[05/Sep/2006:11:53:58][20443.1087388000][-conn:x-dev::0] Notice: --try en:wiki/ -> 0, ::262 ::xowiki::Package->resolve_request (18ms, 0ms)
[05/Sep/2006:11:53:58][20443.1087388000][-conn:x-dev::0] Notice: --W object='wiki/', ::262 ::xowiki::Package->resolve_page (18ms, 0ms)
[05/Sep/2006:11:53:58][20443.1087388000][-conn:x-dev::0] Notice: no prototype for 'wiki/' found, ::262 ::xowiki::Package->resolve_page (18ms, 0ms)
[05/Sep/2006:11:53:58][20443.1087388000][-conn:x-dev::0] Notice: --before adp, ::262 ::xowiki::Package->return_page (19ms, 0ms)

Collapse
16: Re: XoWiki 0.36 (response to 15)
Posted by Gustaf Neumann on
Michael,

your are trying to load a page named "wiki/". This is configured and not standard behavior of xowiki. can it be that you have defined (in the package parameters or in the folder object) that the index_page is "wiki/" and you have no page named "wiki/" available? Either remove in the first step the definition of the index_page or remove the trailing slash.

Collapse
17: Re: XoWiki 0.36 (response to 16)
Posted by Michael Steigman on
Hi Gustaf,

I have the package mounted at mysite/wiki and the navigation is generated automatically based on the list of subsite apps. Since I've named the application instance "wiki", the link is generated as mysite/wiki, which is redirected to mysite/wiki/ (not sure if this is something xowiki is doing). I haven't configured anything, just mounted the package. I tried tacking "index" onto the url (mysite/wiki/index) but that resulted in a different error.

I also don't seem to have an index_page param (if it is an instance param) and since I cannot get to an xowiki page, I can't change behavior any other way.

Collapse
22: Re: XoWiki 0.36 (response to 17)
Posted by Gustaf Neumann on
you mean, you are navigating from the "main site" page, where xowiki appears under applications, the url is wiki. i just tried this, also with subsite, and i saw no problem... is "mysite" the host or a name of the subsite? do you have already xowiki pages there? what happens, if you mount it a second time e.g. as woki instead if wiki? can you get to the admin page (mysite/wiki/admin/) of xowiki?
Collapse
23: Re: XoWiki 0.36 (response to 22)
Posted by Michael Steigman on
mysite is the host. So I have mounted xowiki at mysite.com/wiki. However, I am using the host-node map so myhost.com is actually mainsite.com/mysite. Just occured to me that this might be part of the problem so I tried accessing the package via mainsite and sure enough, everything seems to work fine. This is not a possible solution for me though. Any idea as to why this is happening?
Collapse
24: Re: XoWiki 0.36 (response to 23)
Posted by Dave Bauer on
Michael

Can you get to wiki/admin/
From there you can edit the Xowiki::object and add

set index_page en:index

Then create a new Xowiki::Page called index.

Then tell us what happens.

Thanks

Collapse
25: Re: XoWiki 0.36 (response to 24)
Posted by Michael Steigman on
Yes, I can get to wiki/admin but "set index_page en:index" is there already. There appears to be a default index page as well. Everything works OK when I bypass the host-node map.
Collapse
27: Re: XoWiki 0.36 (response to 22)
Posted by Michael Steigman on
Gustaf,

Just to follow up - Dave B and I just spent a bit of time trying to figure this out in IRC. Perhaps this will info will help:

Here's what appears at the beginning of a good request (i.e., the package is accessed directly, not through a host-node mapped site):

Notice: --starting... /intranet/wiki/en/index  form vars = , ::43182 -> (14ms, 0ms)
Notice: --try en/index -> 0, ::43182 ::xowiki::Package->resolve_request (15ms, 1ms)
Notice: --try en:index -> 43223, ::43182 ::xowiki::Package->resolve_request (16ms, 0ms)

I'm simple typing in mainsite.com/mysite/wiki. Here's the request through a host-node mapped site that generates the error:

Notice: --starting... /wiki/  form vars = , ::262 -> (9ms, 0ms)
Notice: --try wiki/ -> 0, ::262 ::xowiki::Package->resolve_request (10ms, 1ms)
Notice: --try en:wiki/ -> 0, ::262 ::xowiki::Package->resolve_request (11ms, 1ms)
262 is the Main Site instance of acs-subsite and 43182 is the xowiki instance. It seems to us that in a request for the index page or the root url of the package, the invoke method sees /wiki as an object instead of "". The page error itself is generated by the invoke method when this code returns "": set page [my resolve_page [my set object] method].
Collapse
28: Re: XoWiki 0.36 (response to 27)
Posted by Gustaf Neumann on
do you have xowiki mapped as wiki in the host-node map, or do you have a subsite mapped, that contains xowiki mounted as wiki. The first setup is a problem, since e.g. register etc. are not urls of xowiki. I found a bug with the second case in connection with the host-node map, but i did not get your error messages. Please update xotcl-core from cvs head and look, whether this helps in your case.

all the best
-gustaf

Collapse
29: Re: XoWiki 0.36 (response to 28)
Posted by Michael Steigman on
The latter. I updated and things are working now. Thanks!

On an unrelated subject, has anyone noticed that when you view xowiki on openacs.org, all the fonts shrink to the point they are almost unreadable, at least on Firefox? I see the same effect on my intranet with xowiki and a couple of other pages, including a basic listbuilder page with filters that I put together. Does anyone know what causes that?

Collapse
30: Re: XoWiki 0.36 (response to 29)
Posted by Michael Steigman on
Just to follow up on my own observations above, I've found a couple of issues with the styling of xowiki. The first is that it seems to be unconditionally including the generic lists.css and this wipes out any changes folks may have made to list formatting/colors on their sites. I'm just getting started with the package and haven't done anything with xotcl yet but it looks like this is happening in Page's header_stuff proc.

Also, the basic xowiki.css includes this line:

table, td {font: 10px 'Lucida Grande', Geneva, Verdana, Arial, sans-serif; color: #000;}

which sets a base font size for all text in tables. This does not play nicely with the rest of the CSS on my site or on openacs.org. Check out https://openacs.org/xowiki/ and notice how the fonts in the top nav become illegible. This same thing happens on my site. Not sure what the best solution is here but I just deleted the line from my local copy of xowiki.css.

There's one other issue I'd like to bring up and it isn't really xowiki specific. Many packages now require their own navigation (admin/edit/etc.) but each one does it a little differently. Bug tracker, PM and Logger each use a different shade of blue/purple in a fat, page wide nav bar. This isn't going to look nice inside very many master templates. Xowiki has a very simple set of links in gray. I actually prefer this style but whatever the preference, shouldn't we handle this a little better, i.e., more uniformly and in a way that can easily be styled by a site's maintainer? We could start by having packages output a simple list of package nav links and style that at the site level. Thoughts?

Collapse
10: Re: XoWiki 0.36 (response to 7)
Posted by Michael Steigman on
Ever figure this out Matthew? I'm seeing the same thing. It's an old site that has been updated to 5.2.3. xotcl-core was installed first from the repository (0.38) but then updated to the latest on HEAD (0.43). xowiki is version 0.36. Running xotcl 1.4.0.
Collapse
9: Re: XoWiki 0.36 (response to 1)
Posted by Matthew Dodwell on
Gustaf,

Thanks for all your work on this. It looks great. I've just upgraded to 5.2.3 and xowiki 0.36 encountering 2 issues - both are now sorted, but just for reference.

1. Had to update xotcl to 1.4.0 (from 1.3.6) after experiencing the xowiki::Package error - I should have started with this one!!

2. There is a missing dependency to acs-datetime for the mini-calendar display - dt_systime is not found without this package.

Thanks again

Matthew

Collapse
18: Re: XoWiki 0.36 (response to 1)
Posted by Matthew Dodwell on
Gustaf,

got the following error message when trying to add a new wiki page with embedded images. Any ideas?

wrong # args: should be "ns_cache names cache"
while executing
"ns_cache names xowiki_cache link-*-$folder_id"
(procedure "update_references" line 15)
::xowiki::f1 ::xowiki::WikiForm->update_references
invoked from within
"my update_references"
(procedure "new_data" line 7)
::xowiki::f1 ::xowiki::WikiForm->new_data
invoked from within
"::xowiki::f1 new_data"
invoked from within
"set item_id [::xowiki::f1 new_data]"
("uplevel" body line 1)
invoked from within
"uplevel #$level $new_data"
("1" arm line 598)
invoked from within
"switch $errno {
0 {
# TCL_OK
}
1 {
# TCL_E..."
(procedure "ad_form" line 612)
invoked from within
"ad_form -extend -name [my name] -validate [my validate] -new_data $new_data -edit_data $edit_data -on_submit $on_submit -new_request $new_request -..."

cheers
Matthew

Collapse
19: Re: XoWiki 0.36 (response to 18)
Posted by Matthew Dodwell on
Sorry - posted too soon - it's added the article fine, so no problem apart from the odd message.

Cheers
Matthew

ps - fantastic piece of code

Collapse
20: Re: XoWiki 0.36 (response to 1)
Posted by Dave Bauer on
The version of ns_cache you are using doeen't support the parameter xowiki is using, specifically "pattern". In previous versions of ns_cache, "ns_cache names" only took one parameter. The latest version has a second optional parameter.

AFAICT you need to acutally get ns_cache from CVS to get this version of the code. You can also change the code to this:

lsearch [ns_cache names xowiki_cache] link-*-$folder_id

instead of

ns_cache names xowiki_cache link-*-$folder_id

Collapse
21: Re: XoWiki 0.36 (response to 20)
Posted by Gustaf Neumann on
yes, ns_cache 1.5 is needed. it is available since a couple of years. i would recommend the more recent version of ns_cache rather than the lsearch variant since this is more efficient. There is more than one occurance, where "ns_cache names .... pattern" is used.
Collapse
26: Re: XoWiki 0.36 (response to 21)
Posted by Dave Bauer on
Gustaf.

We have been using ns_cache 1.5 on openacs.org for quite some time. It does not include a "pattern" argument to ns_cache names.

From this the parameter was added on May 8, 2003
http://aolserver.cvs.sourceforge.net/aolserver/nscache/tclcache.c?view=log

and ns_cache 1.5 was released on March 16, 2003.
http://sourceforge.net/project/showfiles.php?group_id=3152&package_id=60515&release_id=146794

Maybe someone can do a new release of ns_cache, the only difference is that optional pattern parameter.