[domuslink-developers] heyu config file getting screwed up
2 views
Skip to first unread message
Brandt Daniels
May 5, 2010, 1:32:42 AM5/5/10
to domuslink-...@googlegroups.com
still on r726 for now:
last night i edited my config file by hand to modify some of the
scripts. I then issued a heyu restart on the command line, like I am
used to doing.
After hitting reload on the browser all seemed to look good: the alias I
renamed, and the script I modified worked great.
When i got home from work tonight, the script was behaving the way it
did previously. I then logged into dL and saw that my alias also
returned back to what it was.
Kinda upset for a minute, but then I found that the good config file
from last night got backed up and I was able to restore it. After
restoring it, I again issued a 'heyu restart' from the command line, but
got all sorts of errors, a bunch of junk got appended to the end of the
file...After removing the junk, I restarted again and it was successful.
Now after hitting refresh on the browser, dL still displayed the old
alias name. Then I remembered something about caching, and I think we
are now caching the config file...
This could potentially be bad for the 'old hands' used to editing their
config files manually to update scripts and so forth. That being said, I
don't think the config file should be cached, until dL can handle
everything in there...
Am I correct about it being cached and that's why a 'heyu restart' from
the command line is ineffective?
Anyway, still not sure what happened that caused my config file to
revert after it was backed up in the middle of the night.
-Brandt
--
You received this message because you are subscribed to the Google Groups "domuslink-developers" group.
To post to this group, send an email to domuslink-...@googlegroups.com.
To unsubscribe from this group, send email to domuslink-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/domuslink-developers?hl=en-GB.
last night i edited my config file by hand to modify some of the
scripts. I then issued a heyu restart on the command line, like I am
used to doing.
After hitting reload on the browser all seemed to look good: the alias I
renamed, and the script I modified worked great.
When i got home from work tonight, the script was behaving the way it
did previously. I then logged into dL and saw that my alias also
returned back to what it was.
Kinda upset for a minute, but then I found that the good config file
from last night got backed up and I was able to restore it. After
restoring it, I again issued a 'heyu restart' from the command line, but
got all sorts of errors, a bunch of junk got appended to the end of the
file...After removing the junk, I restarted again and it was successful.
Now after hitting refresh on the browser, dL still displayed the old
alias name. Then I remembered something about caching, and I think we
are now caching the config file...
This could potentially be bad for the 'old hands' used to editing their
config files manually to update scripts and so forth. That being said, I
don't think the config file should be cached, until dL can handle
everything in there...
Am I correct about it being cached and that's why a 'heyu restart' from
the command line is ineffective?
Anyway, still not sure what happened that caused my config file to
revert after it was backed up in the middle of the night.
-Brandt
--
You received this message because you are subscribed to the Google Groups "domuslink-developers" group.
To post to this group, send an email to domuslink-...@googlegroups.com.
To unsubscribe from this group, send email to domuslink-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/domuslink-developers?hl=en-GB.
Cyril Duveau
May 5, 2010, 6:06:21 AM5/5/10
to domuslink-...@googlegroups.com
Brandt,
Looks like you are accessing the same file (heyu config) simultaneously
from 2 different ways.
If you want to edit it by hand, just close your browser. DL will read
the modified config once you relaunch the browser.
Cyril
Looks like you are accessing the same file (heyu config) simultaneously
from 2 different ways.
If you want to edit it by hand, just close your browser. DL will read
the modified config once you relaunch the browser.
Cyril
Brad
May 5, 2010, 9:34:15 AM5/5/10
to domuslink-developers
Good catch Brandt and you are correct about the caching. Also, between
the time you modified the file by hand, did you do anything in the
browser to change an alias or heyu config? I will put in a handler to
check the file modification time on page loads. If it changes, it will
reload the config files. As for the mean time, Cyril has the solution
above.
the time you modified the file by hand, did you do anything in the
browser to change an alias or heyu config? I will put in a handler to
check the file modification time on page loads. If it changes, it will
reload the config files. As for the mean time, Cyril has the solution
above.
Brandt Daniels
May 5, 2010, 11:42:48 AM5/5/10
to domuslink-...@googlegroups.com
I might have made changed in the browser after editing by hand. I usually have the browser and an SSH session to my heyu server going on at the same time.
-Brandt
-Brandt
Brandt Daniels
May 6, 2010, 1:38:35 AM5/6/10
to domuslink-...@googlegroups.com
What would happen in this case if you have multiple instances of dL
running on different computers around the house simultaneously?
running on different computers around the house simultaneously?
Brad
May 6, 2010, 1:46:26 PM5/6/10
to domuslink-developers
Each one has it's own cache as it is per http session. So a change on
one would be missed by the other. I'm looking into detection of
changes to the files.
Brad
one would be missed by the other. I'm looking into detection of
changes to the files.
Brad
Brad
May 6, 2010, 10:35:23 PM5/6/10
to domuslink-developers
Ok, I have an update, r729, that will detect file changes across
sessions and if it was edited locally.
Give it a try.
It will error when a change is found and tell you to stop your browser
and try again.
Brad
sessions and if it was edited locally.
Give it a try.
It will error when a change is found and tell you to stop your browser
and try again.
Brad
Brandt Daniels
May 7, 2010, 12:41:31 AM5/7/10
to domuslink-...@googlegroups.com
I assume this is because I didn't convert, I just used my conf file
from r726 which was already converted, and this is what it would be
like for a first time dL user that has not set any module types or
locations.
Could we have dL make a best guess on the type based on its module association?
Could we have dL make a best guess on the type based on its module association?
Brandt Daniels
May 7, 2010, 12:45:44 AM5/7/10
to domuslink-...@googlegroups.com
We will have to update doc/INSTALL to reflect how to upgrade from a new
version using the dynamic functions to a newer dL and how to transfer
over the floorplan and type settings.
On 5/6/10 9:18 PM, Brandt Daniels wrote:
r729: Even after closing the browser, restarting apache, and opening the browser I am getting this:
Brandt Daniels
May 7, 2010, 12:54:28 AM5/7/10
to domuslink-...@googlegroups.com
hmmm...seems kinda kludgy
No offense, but I'm not really feeling this caching thing...I think I'd prefer fresh reads when accessing a screen...
-Brandt
No offense, but I'm not really feeling this caching thing...I think I'd prefer fresh reads when accessing a screen...
-Brandt
On 5/6/10 7:35 PM, Brad wrote:
Brandt Daniels
May 7, 2010, 1:06:57 AM5/7/10
to domuslink-...@googlegroups.com
Sorry for the multiple replies, I just email when I run into
something...hope that is ok
Can we refrain from displaying this error message when doing a hide/show
operation on the alias screen, as it seems to work anyway even when
displaying the error message.
On 5/6/10 7:35 PM, Brad wrote:
something...hope that is ok
Can we refrain from displaying this error message when doing a hide/show
operation on the alias screen, as it seems to work anyway even when
displaying the error message.
On 5/6/10 7:35 PM, Brad wrote:
Brad
May 7, 2010, 10:06:14 AM5/7/10
to domuslink-developers
The updates I did were to test the detection of a file change outside
of the current session you have. We still need to decide how we want
to handle the error. In some cases, we may want to check if the file
has changed on a page load and if it has, reload the config files.
The caching will be very important when we start introducing more AJAX/
Javascript. As things will happen on the client side without having to
go back to the server very often.
As for refraining from the display of the error message in hide/show,
you shouldn't have gotten that error unless you did change it from
another session and then tried to change it again from a different
one.
Brad
of the current session you have. We still need to decide how we want
to handle the error. In some cases, we may want to check if the file
has changed on a page load and if it has, reload the config files.
The caching will be very important when we start introducing more AJAX/
Javascript. As things will happen on the client side without having to
go back to the server very often.
As for refraining from the display of the error message in hide/show,
you shouldn't have gotten that error unless you did change it from
another session and then tried to change it again from a different
one.
Brad
Brandt Daniels
May 7, 2010, 11:42:56 AM5/7/10
to domuslink-...@googlegroups.com
Thanks for clarifying....After thinking about it more I agree that instead of an error message, that it should then re-read the file.
Maybe we can place a lock file somewhere if an instance of dL is in edit mode, so that way you can't edit from two instances at the same time?
Maybe we can place a lock file somewhere if an instance of dL is in edit mode, so that way you can't edit from two instances at the same time?
Brad
May 8, 2010, 4:14:20 PM5/8/10
to domuslink-developers
I think I have a solution now. It checks if the file changed on any
action to a page or a page load. The errors do not show up unless a
change occurs when the action is being processed. So 99.9% you will
not see the error and you will see the changes on the next action you
take on a page. It was very simple.
Changes in webhookv12 - r730.
Brad
> > domuslink-develo...@googlegroups.com<domuslink-developers%2Bunsu...@googlegroups.com>
> > .
> > .
> > .
> > .
> > .
action to a page or a page load. The errors do not show up unless a
change occurs when the action is being processed. So 99.9% you will
not see the error and you will see the changes on the next action you
take on a page. It was very simple.
Changes in webhookv12 - r730.
Brad
> > .
> > > >>>>> For more options, visit this group athttp://
> > groups.google.com/group/domuslink-developers?hl=en-GB.
>
> > groups.google.com/group/domuslink-developers?hl=en-GB.
>
> > > >>> --
> > > >>> You received this message because you are subscribed to the Google
> > Groups "domuslink-developers" group.
> > > >>> To post to this group, send an email to
> > domuslink-...@googlegroups.com.
> > > >>> To unsubscribe from this group, send email to
> > domuslink-develo...@googlegroups.com<domuslink-developers%2Bunsu...@googlegroups.com>
> > > >>> You received this message because you are subscribed to the Google
> > Groups "domuslink-developers" group.
> > > >>> To post to this group, send an email to
> > domuslink-...@googlegroups.com.
> > > >>> To unsubscribe from this group, send email to
> > .
> > > >>> For more options, visit this group athttp://
> > groups.google.com/group/domuslink-developers?hl=en-GB.
>
> > groups.google.com/group/domuslink-developers?hl=en-GB.
>
> > > >> --
> > > >> You received this message because you are subscribed to the Google
> > Groups "domuslink-developers" group.
> > > >> To post to this group, send an email to
> > domuslink-...@googlegroups.com.
> > > >> To unsubscribe from this group, send email to
> > domuslink-develo...@googlegroups.com<domuslink-developers%2Bunsu...@googlegroups.com>
> > > >> You received this message because you are subscribed to the Google
> > Groups "domuslink-developers" group.
> > > >> To post to this group, send an email to
> > domuslink-...@googlegroups.com.
> > > >> To unsubscribe from this group, send email to
> > .
> > > >> For more options, visit this group athttp://
> > groups.google.com/group/domuslink-developers?hl=en-GB.
>
> > groups.google.com/group/domuslink-developers?hl=en-GB.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "domuslink-developers" group.
> > > To post to this group, send an email to
> > domuslink-...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > domuslink-develo...@googlegroups.com<domuslink-developers%2Bunsu...@googlegroups.com>
> > > You received this message because you are subscribed to the Google Groups
> > "domuslink-developers" group.
> > > To post to this group, send an email to
> > domuslink-...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > .
> > > For more options, visit this group athttp://
> > groups.google.com/group/domuslink-developers?hl=en-GB.
>
> > groups.google.com/group/domuslink-developers?hl=en-GB.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "domuslink-developers" group.
> > To post to this group, send an email to
> > domuslink-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > domuslink-develo...@googlegroups.com<domuslink-developers%2Bunsu...@googlegroups.com>
> > You received this message because you are subscribed to the Google Groups
> > "domuslink-developers" group.
> > To post to this group, send an email to
> > domuslink-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
Brandt Daniels
May 8, 2010, 5:03:08 PM5/8/10
to domuslink-...@googlegroups.com
I got this when I first started up r730, but I haven't seen it since:
Fatal error: Call to a member function getFirstSection() on a non-object in /volume1/web/webhook/lib/classes/global.class.php on line 111
The editing on multiple dL instances and via command line seems to be very seamless now! Great job!
Will continue testing...
-Brandt
Fatal error: Call to a member function getFirstSection() on a non-object in /volume1/web/webhook/lib/classes/global.class.php on line 111
The editing on multiple dL instances and via command line seems to be very seamless now! Great job!
Will continue testing...
-Brandt
Brad
May 8, 2010, 5:14:18 PM5/8/10
to domuslink-developers
Ahh, just changed that as I was having variable scope issues. I know
where that happens and will put in a check.
Brad
On 8 May, 16:03, Brandt Daniels <brandtdani...@gmail.com> wrote:
> I got this when I first started up r730, but I haven't seen it since:
> *Fatal error*: Call to a member function getFirstSection() on a
> non-object in */volume1/web/webhook/lib/classes/global.class.php* on
> line *111*
> For...
>
> read more »
where that happens and will put in a check.
Brad
On 8 May, 16:03, Brandt Daniels <brandtdani...@gmail.com> wrote:
> I got this when I first started up r730, but I haven't seen it since:
> non-object in */volume1/web/webhook/lib/classes/global.class.php* on
> line *111*
>
> read more »
Brad
May 8, 2010, 5:19:32 PM5/8/10
to domuslink-developers
Fixed it. We are now on webhookv12 r732.
Brad
Brad
Brandt Daniels
May 9, 2010, 2:13:59 AM5/9/10
to domuslink-...@googlegroups.com
Everything seems to be perfect!
-Brandt
-Brandt
Reply all
Reply to author
Forward
0 new messages