headers
Hannes Wallnoefer | 10 Mar 11:07
Picon
Gravatar

Helma 1.4.2 is out

Helma 1.4.2 is out. If you're using an old and wrinkled version of
Helma, this is a good time to update.

Download:
http://helma.org/download/

Change Log:
http://helma.org/download/changelog/1.4.2/

Note that if you want to use the Imaging code within a Helma
application running inside a third party servlet container such as
Tomcat, or want better error responses from the Image constructor, you
may want to use an even fresher version such as today's CVS snapshot
:-)

Hannes
Permalink | Reply | 0 comments |
headers
Hannes Wallnoefer | 11 Mar 17:01
Picon
Gravatar

Important fix, visual debugger

Two big changes today (of course these things always happen the day
_after_ a release...)

First, I fixed a very serious bug that randomly messes up responses on
busy multiprocessor machines. The problem was caused by the reqtype
field in helma.framwork.core.RequestEvaluator _not_ being declared as
volatile, which caused read errors between the web thread and the
worker thread. If you are using a recent Helma snapshot on a
production server *with more than one CPU* you definitely want this
bug fixed.

Second, I added support for the visual Rhino debugger to Helma. This
is one of these why-haven't-I-done-this-before things, considered how
easy it was. Just add rhino.debug = true to your app.properties file
and restart. The debugger works like a charm, you can set breakpoints,
evaluate properties or even random code...  The only bad thing is
window/code management (at least with an average Helma application
:-). I think that could be fixed pretty easily by adding a tree pane
containing all open files. And you'll probably want to set
requestTimeout way to avoid being kicked out of your debugging session
by a TimeoutException!

I think these two items are reason enough for a new 1.4.3 release.
Expect it to be out on monday.

For those buiding from CVS: The changes are in both CVS HEAD and
helma_1_4 branch. If you build from CVS for production use, make sure
you use helma_1_4 branch. Otherwise, you'll get the repository code,
which is fine if you want to test it, but is not recommended for
production use yet.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Hannes Wallnoefer | 11 Mar 17:10
Picon
Gravatar

Re: Important fix, visual debugger

PS: I should have added a link to the Rhino debugger page so you know
what I'm talking about:

http://www.mozilla.org/rhino/debugger.html

h.

On Fri, 11 Mar 2005 17:01:09 +0100, Hannes Wallnoefer <hannesw <at> gmail.com> wrote:
> Two big changes today (of course these things always happen the day
> _after_ a release...)
> 
> First, I fixed a very serious bug that randomly messes up responses on
> busy multiprocessor machines. The problem was caused by the reqtype
> field in helma.framwork.core.RequestEvaluator _not_ being declared as
> volatile, which caused read errors between the web thread and the
> worker thread. If you are using a recent Helma snapshot on a
> production server *with more than one CPU* you definitely want this
> bug fixed.
> 
> Second, I added support for the visual Rhino debugger to Helma. This
> is one of these why-haven't-I-done-this-before things, considered how
> easy it was. Just add rhino.debug = true to your app.properties file
> and restart. The debugger works like a charm, you can set breakpoints,
> evaluate properties or even random code...  The only bad thing is
> window/code management (at least with an average Helma application
> :-). I think that could be fixed pretty easily by adding a tree pane
> containing all open files. And you'll probably want to set
> requestTimeout way to avoid being kicked out of your debugging session
> by a TimeoutException!
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Juerg Lehni | 11 Mar 17:24
Gravatar

Re: Re: Important fix, visual debugger

That's really great news indeed.

I'm probably asking for too much now, but is it possible to run the 
Rhino debugger in a remote session from another machine?

J

Am 11.03.2005 um 17:10 schrieb Hannes Wallnoefer:

> PS: I should have added a link to the Rhino debugger page so you know
> what I'm talking about:
>
> http://www.mozilla.org/rhino/debugger.html
>
> h.
>
>
> On Fri, 11 Mar 2005 17:01:09 +0100, Hannes Wallnoefer 
> <hannesw <at> gmail.com> wrote:
>> Two big changes today (of course these things always happen the day
>> _after_ a release...)
>>
>> First, I fixed a very serious bug that randomly messes up responses on
>> busy multiprocessor machines. The problem was caused by the reqtype
>> field in helma.framwork.core.RequestEvaluator _not_ being declared as
>> volatile, which caused read errors between the web thread and the
>> worker thread. If you are using a recent Helma snapshot on a
>> production server *with more than one CPU* you definitely want this
>> bug fixed.
>>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hannes Wallnoefer | 11 Mar 17:36
Picon
Gravatar

Re: Re: Important fix, visual debugger

On Fri, 11 Mar 2005 17:24:09 +0100, Juerg Lehni <juerg <at> scratchdisk.com> wrote:
> That's really great news indeed.
> 
> I'm probably asking for too much now, but is it possible to run the
> Rhino debugger in a remote session from another machine?

It should work via X11, or some other sort of network display
technology such as VNC, but it doesn't have any network support built
in AFAIK. Which doesn't mean it can't be done, of course, but I wonder
how usable it would be under average bandwith conditions.

One constraint of the debugger is that it needs rhino.optlevel to be
set to -1 (pure interpreter, no compilation to class files). Helma
takes care of this now when starting an app in visual debugger mode,
but it means that it'll be hard to "plug into" a production
environment.

Hannes

> 
> J
> 
> Am 11.03.2005 um 17:10 schrieb Hannes Wallnoefer:
> 
> > PS: I should have added a link to the Rhino debugger page so you know
> > what I'm talking about:
> >
> > http://www.mozilla.org/rhino/debugger.html
> >
> > h.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hannes Wallnoefer | 14 Mar 17:36
Picon
Gravatar

Re: Re: Important fix, visual debugger

I optimized the Rhino debugger a bit for working with Helma apps. It
looks now like this:

http://helma.org/static/images/helma/helma-debugger.png

Please check it out, it'll go into the Helma 1.4.3 bug fix release
which I plan to put out tomorrow, so hurry up with any
feedback/whishes/reports.

Hannes

PS to Juerg: I thought a lot about your question of remote debuggable
apps over the weekend, and I think now it's doable, even for
production systems. Maybe in Helma 1.5. More on this at a later time.

On Fri, 11 Mar 2005 17:36:28 +0100, Hannes Wallnoefer <hannesw <at> gmail.com> wrote:
> On Fri, 11 Mar 2005 17:24:09 +0100, Juerg Lehni <juerg <at> scratchdisk.com> wrote:
> > That's really great news indeed.
> >
> > I'm probably asking for too much now, but is it possible to run the
> > Rhino debugger in a remote session from another machine?
> 
> It should work via X11, or some other sort of network display
> technology such as VNC, but it doesn't have any network support built
> in AFAIK. Which doesn't mean it can't be done, of course, but I wonder
> how usable it would be under average bandwith conditions.
> 
> One constraint of the debugger is that it needs rhino.optlevel to be
> set to -1 (pure interpreter, no compilation to class files). Helma
> takes care of this now when starting an app in visual debugger mode,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hannes Wallnoefer | 14 Mar 17:52
Picon
Gravatar

Re: Re: Important fix, visual debugger

Since it was buried in the first posting and I'm being jabbered about
this, here's how to enable the rhino debugger in app.properties:

rhino.debug = true

h.

On Mon, 14 Mar 2005 17:36:59 +0100, Hannes Wallnoefer <hannesw <at> gmail.com> wrote:
> I optimized the Rhino debugger a bit for working with Helma apps. It
> looks now like this:
> 
> http://helma.org/static/images/helma/helma-debugger.png
> 
> Please check it out, it'll go into the Helma 1.4.3 bug fix release
> which I plan to put out tomorrow, so hurry up with any
> feedback/whishes/reports.
> 
> Hannes
> 
> PS to Juerg: I thought a lot about your question of remote debuggable
> apps over the weekend, and I think now it's doable, even for
> production systems. Maybe in Helma 1.5. More on this at a later time.
> 
> On Fri, 11 Mar 2005 17:36:28 +0100, Hannes Wallnoefer <hannesw <at> gmail.com> wrote:
> > On Fri, 11 Mar 2005 17:24:09 +0100, Juerg Lehni <juerg <at> scratchdisk.com> wrote:
> > > That's really great news indeed.
> > >
> > > I'm probably asking for too much now, but is it possible to run the
> > > Rhino debugger in a remote session from another machine?
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
VividVisions, Walter Krivanek | 14 Mar 23:28
Picon

property loading/scaling

Hi,

I've got a question, regarding collection loading/scaling or rather 
property loading/scaling.
The documentation says:

"The default way is to just fetch an index of children consisting of 
the object's keys, and then fetch the objects on demand, which allows 
the Hop to scale to large child collections where only few of the 
objects are actually accessed."

When one of these objects is accessed, are automatically all properties 
loaded into memory or just those, who are requested (by a function or 
macro)?

For example:
I've got objects representing a document.
Each doc has a title and a body.
I want to display a list of documents, but only need to show the titles.
Are the body properties loaded anyway?

I'm sorry, if I have overlooked a page in the documentation dealing 
with this subject.
If so, please just send me the link.

Thanks!
Walter
Permalink | Reply | 2 comments |
headers
Michael Platzer | 14 Mar 23:54
Picon

Re: property loading/scaling

VividVisions, Walter Krivanek wrote:

> "The default way is to just fetch an index of children consisting of 
> the object's keys, and then fetch the objects on demand, which allows 
> the Hop to scale to large child collections where only few of the 
> objects are actually accessed."
>
> When one of these objects is accessed, are automatically all 
> properties loaded into memory or just those, who are requested (by a 
> function or macro)?

i assume that all of the properties are loaded immediately into memory, 
since all the helma-generated sql-queries are of the form "select * from 
..."

if anyone knows different, please go ahead and correct me,
greets,
  michi
Permalink | Reply | 1 comment |
headers
VividVisions, Walter Krivanek | 15 Mar 08:56
Picon

Re: property loading/scaling

Michael Platzer wrote:

> VividVisions, Walter Krivanek wrote:
>
>> "The default way is to just fetch an index of children consisting of 
>> the object's keys, and then fetch the objects on demand, which allows 
>> the Hop to scale to large child collections where only few of the 
>> objects are actually accessed."
>>
>> When one of these objects is accessed, are automatically all 
>> properties loaded into memory or just those, who are requested (by a 
>> function or macro)?
>
> i assume that all of the properties are loaded immediately into 
> memory, since all the helma-generated sql-queries are of the form 
> "select * from ..."

I thought so...
Then I will have to find another way to solve this.
Because these "document" objects are huge and would cause severe memory 
problems if all of their properties are loaded when looking at a list 
of 200+ "documents".

Is there a way to use the _extends property without _prototype?
Like:

object1 type.properties:
title = TITLE_COL

obect2 type.properties:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane