I *think* Catagolue in its current state should be able to accept custom rules (it accepts custom symmetries), although I'll have to modify it to not attempt to produce animated SVGs for non-standard rules.

I'll need to see a sample progress file from A for Awesome's script to make sure it's compatible, though.

What do you do with ill crystallographers? Take them to the mono-clinic!

calcyman wrote:I *think* Catagolue in its current state should be able to accept custom rules (it accepts custom symmetries), although I'll have to modify it to not attempt to produce animated SVGs for non-standard rules.

I'll need to see a sample progress file from A for Awesome's script to make sure it's compatible, though.

I don't know, myself. It still reports the version as v0.54; is there any particular requirement for the format, or does my v0.54+0.Ni work? Also, there is an extra feature involving pseudo-objects in my forthcoming version that would have to be disabled, as I am assuming that a server-side workaround would be an inconvenience. Also, how do you plan to verify the hauls? What if, for example, someone searches a custom rule table for (for example) tlife, but then realizes that they were using an erroneous rule table and they submit a haul that looks right superficially but instead contains a lot of objects that don't even work in the specified rule? Also, sometimes there are bugs caused by modifying a rule table after running apgsearch on it that result in xq1's being reported; how would those be dealt with?

I don't even know enough about v1.N and Catagolue to be able to make certain that whatever data my version sends wouldn't break Catagolue, as it is.

Anyway, here's a sample progress file for tlife (Note the large quantity of xp160s, mostly non-interacting pairs or triples):

It might make sense to support non-totalistic rules formally in Catagolue, at least to the extent of recognizing standard rule names -- I don't know if it's worth getting the animated SVGs working, but it shouldn't be too horribly difficult. Standardizing on Hensel's format might help prevent the problem mentioned above, of people using different rule table variants but reporting results to the same rule name; that sounds messy.

-----------------

I'm kind of surprised that there isn't a Hensel-non-totalistic-gen.py script in Golly's Rule-Generators folder by this time, actually. Should be straightforward to write -- just a lookup table between lines of the rule table and letters in the rule string, isn't it? Well, except for the minus signs, I suppose.

-- Anyone want to tackle that project? I'd be happy to test it and check it in to Golly.

I'll try to remember to put something on golly-test also, and see what Tom Rokicki thinks about adding native support in Golly for Hensel's format. No promises there, though...!

dvgrn wrote:I'm kind of surprised that there isn't a Hensel-non-totalistic-gen.py script in Golly's Rule-Generators folder by this time, actually. Should be straightforward to write -- just a lookup table between lines of the rule table and letters in the rule string, isn't it? Well, except for the minus signs, I suppose.

I think at least hex neighborhood should be supported. Von Moore isn't that interesting.

The progress file you showed me seems to be perfectly Catagolue-compatible. Have fun!

is there any particular requirement for the format, or does my v0.54+0.Ni work?

It can't contain any spaces, but v0.54+0.1i (for example) should be fine.

Also, there is an extra feature involving pseudo-objects in my forthcoming version that would have to be disabled, as I am assuming that a server-side workaround would be an inconvenience.

Indeed.

Also, how do you plan to verify the hauls?

I don't. Catagolue only verifies hauls for b3s23/C1.

What if, for example, someone searches a custom rule table for (for example) tlife, but then realizes that they were using an erroneous rule table and they submit a haul that looks right superficially but instead contains a lot of objects that don't even work in the specified rule? Also, sometimes there are bugs caused by modifying a rule table after running apgsearch on it that result in xq1's being reported; how would those be dealt with?

Make your script create a backup of the rule-table and chmod it to be read-only (and only read from the backup)?

Von Moore isn't that interesting.

Who's Von Moore?

What do you do with ill crystallographers? Take them to the mono-clinic!

dvgrn wrote:I'm kind of surprised that there isn't a Hensel-non-totalistic-gen.py script in Golly's Rule-Generators folder by this time, actually. Should be straightforward to write -- just a lookup table between lines of the rule table and letters in the rule string, isn't it? Well, except for the minus signs, I suppose.

-- Anyone want to tackle that project? I'd be happy to test it and check it in to Golly.

There are two scripts available which are most of the way there.

EricG's original script HenselNotation->Ruletable(1.3).py which uses the r/y swapped version of Hensel's notation (i.e. the neighbours.html version). It is very nicely documented though. And,

The rule generator which is part of the isotropic apgsearch I posted on the Hacking apgsearch thread after Scorbie posted a version using existing rules. The rule generator can be used standalone to generate just the 2-state isotropic rules using the included isotropic-rule.py script. This script is based on the neighbours2.html version of Hensel's notation, which in addition to the r/y swap replaced n with v.

I would be happy to work with you to clean those up and get a script checked into Golly, but I think there's one aspect which still needs deciding on, and that is a canonical form for the representation - to avoid having multiple rule files representing the same rule.

However, I think native support in Golly would be a better option.

I'm excited about using Catagolue to record soup search results in other rules. But I do think a few details should be sorted out before submitting hauls for non-totalistic rules - in particular the canonical rule name format mentioned above, and potentially a means of associating rule nicknames with the canonical representation of the rule name.

The latest version of the 5S Project contains over 226,000 spaceships. There is also a GitHub mirror of the collection. Tabulated pages up to period 160 (out of date) are available on the LifeWiki.

A for awesome wrote:I experimentally tried to submit a haul in tlife to Catagolue just a moment ago, and it seems that Catagolue rejected it. I don't know why this is. Here's the file, if anyone's interested:

By 'just a moment ago', do you mean 19:04:57 (over an hour ago)? There were five attempts in quick succession (each one 200ms apart), each with the following stacktrace:

java.lang.IllegalArgumentException: name cannot be null or empty
at com.google.appengine.api.datastore.KeyFactory.createKey(KeyFactory.java:82)
at com.google.appengine.api.datastore.KeyFactory.createKey(KeyFactory.java:77)
at com.google.appengine.api.datastore.KeyFactory$Builder.addChild(KeyFactory.java:276)
at com.cp4space.payosha256.PayoshaUtils.getToken(PayoshaUtils.java:163)
at com.cp4space.payosha256.PayoshaUtils.callPayosha(PayoshaUtils.java:223)
at com.cp4space.catagolue.servlets.PayoshaServlet.doPost(PayoshaServlet.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at com.google.apphosting.utils.servlet.ParseBlobUploadFilter.doFilter(ParseBlobUploadFilter.java:125)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:37)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.utils.servlet.JdbcMySqlConnectionCleanupFilter.doFilter(JdbcMySqlConnectionCleanupFilter.java:60)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:260)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:78)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:148)
at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:469)
at com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:437)
at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:444)
at com.google.tracing.CurrentContext.runInContext(CurrentContext.java:256)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:308)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:300)
at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:441)
at com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:235)
at java.lang.Thread.run(Thread.java:745)

I don't understand why this would happen, since it hasn't even attempted to submit the haul at this point (it was just contacting /payosha256 to obtain a token for the proof-of-work).

What do you do with ill crystallographers? Take them to the mono-clinic!

A for awesome wrote:I experimentally tried to submit a haul in tlife to Catagolue just a moment ago, and it seems that Catagolue rejected it. I don't know why this is. Here's the file, if anyone's interested:

By 'just a moment ago', do you mean 19:04:57 (over an hour ago)? There were five attempts in quick succession (each one 200ms apart), each with the following stacktrace:

java.lang.IllegalArgumentException: name cannot be null or empty
at com.google.appengine.api.datastore.KeyFactory.createKey(KeyFactory.java:82)
at com.google.appengine.api.datastore.KeyFactory.createKey(KeyFactory.java:77)
at com.google.appengine.api.datastore.KeyFactory$Builder.addChild(KeyFactory.java:276)
at com.cp4space.payosha256.PayoshaUtils.getToken(PayoshaUtils.java:163)
at com.cp4space.payosha256.PayoshaUtils.callPayosha(PayoshaUtils.java:223)
at com.cp4space.catagolue.servlets.PayoshaServlet.doPost(PayoshaServlet.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at com.google.apphosting.utils.servlet.ParseBlobUploadFilter.doFilter(ParseBlobUploadFilter.java:125)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:37)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.utils.servlet.JdbcMySqlConnectionCleanupFilter.doFilter(JdbcMySqlConnectionCleanupFilter.java:60)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:260)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:78)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:148)
at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:469)
at com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:437)
at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:444)
at com.google.tracing.CurrentContext.runInContext(CurrentContext.java:256)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:308)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:300)
at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:441)
at com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:235)
at java.lang.Thread.run(Thread.java:745)

I don't understand why this would happen, since it hasn't even attempted to submit the haul at this point (it was just contacting /payosha256 to obtain a token for the proof-of-work).

That might be when I tried to test the peer-reviewing (another thing that I'm not sure why it isn't working); otherwise, I don't know why there were 5 attempts. If that is indeed the case, I don't know why it seems to have not even submitted the haul.

Edit: I think I figured it out; I forgot to import urllib2. I still don't know why the peer-reviewing isn't working; will it mess anything up if I just remove that section?

Edit 2: Worked this time! Only one thing: catagolue.appspot.com/hashsoup always gives the rulename for the rle in all caps. As this raises lots of pointless warnings if one tries to paste the rle into Golly, is there any way to change this?

A for awesome wrote:Edit 2: Worked this time! Only one thing: catagolue.appspot.com/hashsoup always gives the rulename for the rle in all caps. As this raises lots of pointless warnings if one tries to paste the rle into Golly, is there any way to change this?

Great! Yes, I'll rectify that at the same time I get the animated SVGs working properly.

What do you do with ill crystallographers? Take them to the mono-clinic!