Installing LambdaCore task runs out of seconds

[katernya]

I needed to up the foreground seconds in options.h for my xen hardware assisted VM.

[toddsundsted]

What core are you running?

[katernya]

Installed packages core, 1.0.5 (#200) Core Package kernel, 1.0.4 (#2) Kernel Package lambdacore, 0.0.4 (#227) LambdaCore Package

I tried the prerelease database first, but switched to the stable release after I got the error. When that didn't fix it, I upped the seconds in options.h.

[toddsundsted]

My guess is that it failed while importing the lambdacore package. Is that correct? If you have a moment, send me the traceback. In theory there should be sufficient suspends in the import/export code, but I could have missed something. Thanks!

[katernya]

Updating... Installing version "0.0.4" of package "lambdacore" from the remote archive...

9:_fetch_from_archive (this == #9), line 15: Task ran out of seconds

... called from #9:import_package_from_archive (this == #9), line 3 ... called from #9:@install (this == #9), line 40 (End of traceback)

[toddsundsted]

Thanks!

[toddsundsted]

This will be fixed in kernel 1.0.7 (to be released soon).

[toddsundsted]

I released kernel 1.0.7, which should fix this problem, and built a new Stunt database that incorporates this kernel. You will need to build the server from the latest code in the stunt branch to use the latest kernel. See the instructions on http://stunt.io/ for more detail.

I'd be very interested in confirmation that this works if you have the time to test it.

[Sylras]

@install lambdacore with $composed Updating...

9:_fetch_from_archive (this == #9), line 5: Task ran out of seconds

... called from #9:fetch_index (this == #9), line 3 ... called from #9:@install (this == #9), line 13 ... called from #5:huh (this == #5), line 6 (End of traceback)

With the kernel 1.0.7 (and more precisely with your "improvise" stunt.db from "ten days ago" as I'm writing this)

[toddsundsted]

@Sylras, thanks! It's now failing when updating the list of packages. The previous fix should have taken care of this, too, so it's back to the drawing board.

The work-around for now is to compile the server with more background and foreground seconds, to ensure the server has time to receive and process the data from the archive.

How long was the delay between giving the "@install" command and the error?

[Sylras]

1-2 seconds tops. It wasn't instant, but pretty quick.

I tried the same with more foreground seconds (not with more background seconds yet) but that didn't change a thing. Then I changed the in-db fg_seconds and bg_seconds properties, no change either.

Then I tried this: ;notify(#5, tostr("seconds left: ", seconds_left())); seconds left: 0 1

Oh and with a ghostcore (basically MOO db with rpg stuff), I got stuff like (made-up number, tell me if you need actual values) "-283847 seconds left" for evals, which just saves seconds_left() and substracts another seconds_left() after the eval is done. Then I looked at your source and noticed that you didn't change anything in regards of the seconds_left built-in, so I'm kinda out of ideas why this isn't working as intended...

You might want to know that I'm doing all this with cygwin, not a "real" unix environment.

[toddsundsted]

1-2 seconds is less surprising than instantaneously, so that's good (I think).

You will need to increase background ticks/seconds. I attempt to solve this by dynamically increasing background ticks/seconds, and then suspending, since you can't change foreground ticks/seconds for a running task.

The verb in question is `$composed:_set_seconds_and_ticks'.

When I run the latest Stunt server on Stunt.db from improvise, and eval `seconds_left()' I get:

;notify(#5, tostr("seconds left: ", seconds_left()));
seconds left: 5
1

In this case you get "seconds left: 0"? Is that correct?

What's the exact test you're trying on Ghostcore? I have a copy of that db.

Also, have you tried this on a stock LambdaMOO server on cygwin?

[Sylras]

Yep... it's my system, not the stunts server. Just tried this seconds_left() test on a stock LambdaMOO server (surprisingly difficult to get a core if the main source is down...) and got 0 too. Maybe my cygwin environment lacks something, I have no clue.

I bet I wouldn't even need to increase the ticks/seconds if seconds_left() worked right for me, darn...

[edit] Now I'm completely lost... using stunts with ghostcore:

;notify(#2, tostr("seconds left: ", seconds_left())); seconds left: 2672008

It's probably still cygwin though... sigh

[edit2] Or not... using LambdaMOO 1.8.1 with ghostcore: ;notify(#2, tostr("seconds left: ", seconds_left())); seconds left: 0

At this point, I'm probably just making things more confusing, so I'll shut up. If you need anything else, feel free to ask...

[Sylras]

Okay, actually one more thing. It's not EXACTLY a stunt thing, but maybe you want to work on this anyways..

After some searching, I found EmeraldMOO (http://sourceforge.net/projects/emeraldmoo/files/EmeraldMoo/0.0.3a/) with cygwin-specific code/configuration changes. After compiling that, seconds_left() worked like intended. (emerald+ghostcore)

I tried to somehow include those changes in my local stunt copy, but failed due to me being waaay too inexperienced with this. All I see so far is that apparently emerald uses some other (more complex?) kind of configuration and disables virtual timers.

[toddsundsted]

The only significant change in EmeraldMoo is the following in timers.c:

diff --git a/timers.c b/timers.c
index 8e9ca4b..744bd12 100644
--- a/timers.c
+++ b/timers.c
@@ -29,6 +29,11 @@
 #  undef ITIMER_VIRTUAL
 #endif

+#ifdef __CYGWIN__
+/* Till someone would find out how to use virtual_timers right on cygwin */
+#  undef ITIMER_VIRTUAL
+#endif
+
 typedef struct Timer_Entry Timer_Entry;
 struct Timer_Entry {
     Timer_Entry *next;

You could safely merge the five new lines in by hand.

Or just put the following somewhere near the top of the file (under the includes, maybe):

#  undef ITIMER_VIRTUAL

These changes should disable virtual timers, which are not supported in Cygwin.

[Sylras]

Yeah, that's what I did when I tried to find out what was different. But it didn't change the seconds_left() problem, so I was assuming I missed something else. Or the... um... "./configure" caught something for cygwin yours doesn't, as that one's producing a much longer log of checks.

[toddsundsted]

Hmmmm... there are only a small handful of Cygwin-specific ifdefs. It's possible it is related to configure. Did you try to simply undef ITIMER_VIRTUAL itself?

[Sylras]

Yep, I removed the whole #ifdef thing and just put in # undef ITIMER_VIRTUAL instead on my first try already.

[toddsundsted]

Ok. Thanks for trying it out! Further progress will have to wait until I can spin up a Cygwin environment to test on. I can create and upload a variant of the improvise database with LambdaCore already loaded, however, I have a feeling the timer issue will show up in other ways.

[toddsundsted]

If I cook up a work-around, I'll post it here.

[Sylras]

I think so too, that's why I've switched to a "real" unix environment. But maybe someone else won't have that chance, so thanks for trying to fix this!