Golly 2.8 has been released

For general discussion about Conway's Game of Life.
User avatar
dvgrn
Moderator
Posts: 6058
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Golly 2.8 has been released

Post by dvgrn » October 17th, 2016, 9:25 am

Andrew wrote:@dvgrn and Extrementhusiast: Please try the following 64-bit build of Golly 2.9b1 for Windows (the zip file only contains Golly.exe so just replace your existing Golly.exe).

http://www.trevorrow.com/golly/Golly-2. ... -64bit.zip

I'm pretty sure it fixes the "Bug detected in SyncUndoHistory" error. Not quite so sure about the "Illegal operation" error but I haven't seen either message appear on my Mac or Win7 system, so fingers crossed.
Looks good so far on 64-bit Windows. I'm able to set up a complicated combination of selections and evolve operations, after converting to LifeHistory.

I can undo the entire sequence with Ctrl+Z, back through the rule change.
I can redo the entire sequence with Ctrl+Shift+Z.
I can Reset from the end of the sequence to just after the rule change (to T=0).
I can redo part of the sequence.
I can Reset to T=0 from any point in the sequence.
I can redo part of the sequence, then replace the end of the sequence by making new selections, etc.
I can Reset or Undo the new sequence correctly.

Here's hoping that was the last remaining Undo bug! I haven't tried to duplicate the population-calculation-illegal-operation problem.

User avatar
Andrew
Moderator
Posts: 766
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Golly 2.8 has been released

Post by Andrew » October 17th, 2016, 5:48 pm

dvgrn wrote:I haven't tried to duplicate the population-calculation-illegal-operation problem.
Minor point: the "illegal operation while calculating" error can occur at various points in the code (eg. when calculating the next step), not just when calculating the population.

User avatar
dvgrn
Moderator
Posts: 6058
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Golly 2.8 has been released

Post by dvgrn » October 17th, 2016, 7:28 pm

Uh-oh. Running 2.9b1, I seem to have proven that there's some way to mess up the Undo system -- but I don't know what it is yet.

Starting with the following pattern, which I was editing by moving the leftmost two Snarks southwest by one cell diagonally, then two cells more --

Code: Select all

x = 87, y = 62, rule = LifeHistory
29.2A20.2A$28.A.A20.A.A$22.2A4.A24.A4.2A$20.A2.A2.2A.4A16.4A.2A2.A2.A
$20.2A.A.A.A.A2.A16.A2.A.A.A.A.2A$23.A.A.A.A22.A.A.A.A$23.A.A.2A24.2A
.A.A$24.A32.A$62.A$37.2A4.2A17.3A$28.2A7.A6.A7.2A11.A$28.2A5.A.A6.A.A
5.2A10.A.A$9.A25.2A8.2A17.A.A$9.3A53.A$12.A$11.2A3$3.2A75.2A$3.A21.2A
28.2A23.2A$2A.A22.A28.A$A2.3A4.2A11.3A30.3A$.2A3.A3.2A11.A34.A$3.4A
51.A.2A$3.A15.2A35.2A.A.A$4.3A12.A.A34.A2.A$7.A13.A36.2A7.2A$2.5A14.
2A44.2A$2.A$4.A70.2A.A$3.2A24.A45.2A.3A$27.3A51.A$26.A48.2A.3A$26.2A
46.A2.2A$73.A.A$55.A16.A.A.3A$55.3A15.A2.A2.A$58.A17.A.A.A$57.2A16.2A
2.A.A$72.A.A2.A.A.A$16.2A54.2A2.2A.2A$15.A.A5.2A$15.A7.2A30.3A$14.2A
39.A23.A$56.A20.3A$28.A47.A$24.2A.A.A46.2A$23.A.A.A.A17.A$20.A2.A.A.A
.A.2A14.3A$20.4A.2A2.A2.A17.A$24.A4.2A18.A$22.A.A24.2A$22.2A23.2A2.A$
46.A2.3A$47.A23.A$48.4A6.2A3.2A5.A.A$50.A7.2A3.2A6.A$52.A$51.2A30.2A$
83.A.A$85.A$85.2A!
I ran a script that uses a selected signal to populate this kind of glider loop with signals of a given period. I saved the file, then hit Undo before running the script again to create a different-period gun (p157 and p314, in this case).

At some point I noticed that the selection was one cell to the right of where it should have been. A few cycles of Undo/Redo/Reset later, the pattern in Golly's window was the following:

Code: Select all

x = 89, y = 59, rule = LifeHistory
36.2A20.2A$35.A.A20.A.A$29.2A4.A24.A4.2A$27.A2.A2.2A.4A16.4A.2A2.A2.A
$27.2A.A.A.A.A2.A16.A2.A.A.A.A.2A$30.A.A.A.A22.A.A.A.A$30.A.A.2A24.2A
.A.A$31.A32.A$69.A$44.2A4.2A17.3A$35.2A7.A6.A7.2A11.A$35.2A5.A.A6.A.A
5.2A10.A.A$42.2A8.2A17.A.A$11.A60.A$11.A$14.A$9.A3.A$9.4A.A$12.A2.A
71.2A$5.A5.2A.2A16.2A28.2A23.2A$5.A27.A28.A$2.A27.3A30.3A$2.4A6.A17.A
34.A$3.A4.A3.A52.A.2A$2A.A59.2A.A.A$A2.3A4.2A.2A6.A41.A2.A$.2A3.A3.2A
.2A6.A.A41.2A7.2A$3.4A2.A13.A50.2A$3.2A14.2A2.A$4.3A2.A9.A.A2.A57.2A.
A$7.A2.A10.A2.A57.2A.3A$2.5A.2A11.2A.2A5.A56.A$2.A26.A52.2A.3A$4.A2.A
20.A52.A2.2A$3.2A.2A21.A2.A47.A.A$27.6A29.A16.A.A.3A$26.A2.A32.3A15.A
2.A2.A$26.2A.2A34.A17.A.A.A$64.2A16.2A2.A.A$79.A.A2.A.A.A$79.2A2.2A.
2A$18.A$17.A.A5.A36.3A$25.A36.A23.A$16.2A.2A42.A20.3A$15.A.2A.A2.2A.
2A55.A$15.A2.A4.2A.A3.A52.2A$14.2A.2A7.A2.A.A22.A$25.A.A3.A22.3A$22.A
4.3A.A.A23.A$22.A.2A.A.A.A2.A21.A$23.A.A.A.A.A24.2A$20.A2.A.A.3A.2A.
2A18.2A2.A$20.7A.2A2.A2.A17.A2.3A$24.A2.A.2A.2A20.A23.A$22.A.2A.A27.
4A6.2A3.2A5.A.A$22.2A.2A30.A7.2A3.2A6.A$59.A$58.2A!
If I hit Undo far enough, I could get the mess to disappear and go back to the pattern I actually started the editing session with, which was

Code: Select all

x = 82, y = 59, rule = LifeHistory
29.2A20.2A$28.A.A20.A.A$22.2A4.A24.A4.2A$20.A2.A2.2A.4A16.4A.2A2.A2.A
$20.2A.A.A.A.A2.A16.A2.A.A.A.A.2A$23.A.ABABAB20.BABABA.A$23.A.AB2AB
22.B2ABA.A$24.AB.2B24.2B.BA$27.3B22.3B7.A$27.4B6.2A4.2A6.4B7.3A$25.3B
2AB6.A6.A6.B2A3B8.A$25.3B2AB3.BA.A6.A.AB3.B2A3B7.A.A$9.A13.10B.B2A8.
2AB.10B5.A.2B$9.3A10.13B12.13B5.2ABA$12.A8.14B12.14B6.2BAB$11.2A7.15B
12.15B5.BA4B$11.5B3.ABAB2.8B16.8B2.4B4.7B$13.3B2.B2AB5.6B16.6B5.4B2.
3B5A.4B.B$3.2A7.8BA4.9B14.9B4.7B3A4B2AB.B2A$3.A8.8B5.2A4.4B12.4B4.2A
5.14BA3B2A$2A.A.B3.10B7.A5.4B10.4B5.A6.5BA3BA4BAB.2B$A2.3AB.2B2A7B4.
3A7.4B8.4B7.3A3.5B2A2B2AB2A2B$.2A2.BA3B2A7B4.A10.4B6.4B10.A3.10BA4B$
3.4A12B16.4B4.4B11.A.2AB.5BAB2A3B$3.A.2B3.7B.B2A15.4B2.4B10.2A.A.AB2.
6B2A3B$4.3AB2.7B.BA.A15.8B11.A2.A5.5B3A2B$7.A4.4B5.A16.6B14.2A5.10B$
2.5A5.4B5.2A16.4B21.11B$2.A10.4B21.2A4B21.10B$4.A9.4B19.ABA5B20.8B.B
2A.A$3.2A10.4B10.A6.3BA2.4B18.7B3.B2AB3A$16.4B7.3A5.4B4.4B17.6B6.B4.A
$17.4B5.A7.4B6.4B17.6B4.2A.3A$18.4B4.2A5.4B8.4B16.5B4.A2.2A$19.9B4.4B
10.4B14.8B.A.A$20.6B5.4B12.4B4.A8.8BA.A.3A$20.8B2.4B14.4B3.3A6.6B.2BA
B.A2.A$18.15B16.4B5.A4.7B2.2B2.A.A.A$18.14B18.4B3.2A4.7B3.B.2A2.A.A$
18.13B20.4B2.4B.8B2.A.A2.A.A.A$16.2AB.10B22.4B3.11B2.2A2.2A.2A$15.A.A
B3.B2A3B25.4B.12B$15.A6.B2A3B26.B3A12B$14.2A6.4B29.A13B10.A$23.3B30.A
9B11.3A$24.2B.BA26.12B9.A$23.B2ABA.A24.16B6.2A$22.BABABA.A17.A6.24B$
20.A2.A.A.A.A.2A14.3A3.23B$20.4A.2A2.A2.A17.A2.24B$24.A4.2A18.A.B.24B
$22.A.A24.2A27B$22.2A23.2A2.A22B.4B$46.A2.3A3B3.2B3.B7.2B3.4B$47.A4.
2B3.4B.3B5.BA2B3.4B$48.4A5.B2AB.B2AB4.A.A5.3BA$50.A7.2A3.2A6.A7.ABA$
52.A27.2A$51.2A28.B!
(After drawing an eater at the lower right, I ran an initial script, LifeEdit_empty_gun.py, to remove the blue cells and clear out all the signals.)

I could then get the incorrect pattern to be rebuilt by hitting Ctrl+Shift+Z repeatedly to get to the end of the Redo chain. Tried that several times, after multiple Undo operations or a Reset, with the same result each time.

A small clue that might be useful is that I vaguely remember bumping an arrow key while I was trying to do another operation, like a select and Ctrl+C, maybe? Anyway, it was an arrow key followed or preceded a split second away by some other action. And the problem showed up immediately after that keyboard fumble -- i.e., the next Undo put the selection in the wrong place, one cell too far left, and then things just got worse from there.

I've attached the two scripts I was using, just for the record, along with the 10/17 Golly temp files I found in a likely folder.
Attachments
gol48D2.tmp.zip
temp files for Undo problem
(19.52 KiB) Downloaded 162 times

User avatar
Andrew
Moderator
Posts: 766
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Golly 2.8 has been released

Post by Andrew » October 18th, 2016, 2:05 am

dvgrn wrote:Uh-oh. Running 2.9b1, I seem to have proven that there's some way to mess up the Undo system -- but I don't know what it is yet.
I haven't been able to reproduce any similar sort of problem here, probably because I'm not doing the exact same steps.
A small clue that might be useful is that I vaguely remember bumping an arrow key while I was trying to do another operation, like a select and Ctrl+C, maybe? Anyway, it was an arrow key followed or preceded a split second away by some other action. And the problem showed up immediately after that keyboard fumble -- i.e., the next Undo put the selection in the wrong place, one cell too far left, and then things just got worse from there.
Is it just the selection *rectangle* that's in the wrong place, or is it the selection contents as well?

Anyway, I think you need to try and isolate just what those arrow key + action steps are. It does sound plausible that doing 2 things quickly could cause a bug if the 2nd action is happening due to a Yield call somewhere before the 1st action has finished. Something like the recent bug Scorbie reported that caused a weird display on Linux.

User avatar
dvgrn
Moderator
Posts: 6058
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Golly 2.8 has been released

Post by dvgrn » October 18th, 2016, 9:25 am

Andrew wrote:Is it just the selection *rectangle* that's in the wrong place, or is it the selection contents as well?
The first wrong thing I noticed was the selection rectangle, offset by one cell left of where it should have been. The script uses the selection to fill the signal loop, and I'd just un-done the results of running the script. The script had worked fine, but it certainly wouldn't have worked if the selection had really been in that location.

After that, the selection contents start looking wrong, too, because the undo operations are happening in the wrong place. The original problem definitely seems to be a simple frame shift in every case, though. In fact, from years of experience with this bug, I think I can say that the frame shift always matches a move in one orthogonal direction or other, and the distance is always one you can get by pressing an arrow key. (I've seen it when I'm zoomed out pretty far, and I remember checking that the offset I saw matched the current arrow key step.)

The problem might be hitting an arrow key while a script action is being un-done, or something like that. I often have scripts that do fairly complex things, so it would take quite a while to back the changes out. I'll see if I can duplicate the problem somehow with an artificially busy script.

David
Posts: 212
Joined: November 3rd, 2009, 2:47 am
Location: Daejeon, South Korea

Re: Golly 2.8 has been released

Post by David » November 12th, 2016, 6:34 pm

I'm using Linux Mint 17.3 64-bit, and I've downloaded Golly 2.8-gtk-64bit, but when I click on "Set Rules...", I get the following error message:

Code: Select all

An assertion failed!
../src/common/unichar.cpp(65): assert "Assert failure" failed
in ToHi8bit(): character cannot be converted to single byte
Call me "Dannyu NDos" in Forum. Call me "Park Shinhwan"(박신환) in Wiki.

User avatar
Andrew
Moderator
Posts: 766
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Golly 2.8 has been released

Post by Andrew » November 13th, 2016, 5:41 pm

I'm only guessing but maybe the problem is due to some non-ASCII character in the full path to your rules directory (ie. the one you can specify in Prefs > Control), so try avoiding any such characters and see if the error disappears.

User avatar
dvgrn
Moderator
Posts: 6058
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Golly 2.8 has been released

Post by dvgrn » February 4th, 2017, 1:30 am

I'm finally starting to try to make some more use of Lua, and ran into a minor hiccup today.

To make use of the different paste modes in the Lua version of g.putcells(), from the gplus module, my first attempt was

patternvar.put(x,y,{1,0,0,1},"xor")

but thanks to Lua's carefree way of throwing away input values that it doesn't need, the "xor" gets silently discarded. What actually works is

patternvar.put(x,y,{1,0,0,1,"xor"})

Seems a little weird to have to hide the paste mode inside the transformation matrix to get it noticed. I could get used to it, but I'm not sure I should...!

Also, might it make sense to adjust init.lua so that "emptypat = pattern()" works the same as "emptypat = pattern({})" ?

EDIT: Another interesting-but-not-surprising thing I ran into and worked around, while working on a 50K universal megafier script for Adam's old stable 2^N megacells.

There are various places where you need a row of 500 eaters or more, or a long row of reflectors or Fx77 conduits -- lots of repetition. I tried building cell lists (cell tables?) in the obvious inefficient way, by adding one eater at a time in a for loop. But very quickly Golly's memory usage explodes -- I couldn't even get all the way around the megacell, just a few thousand fishhook eaters, before the script started running very slowly.

Golly had used up the meager (by modern standards) three gigs of memory on this laptop and was paging to the hard drive. It seemed as if Lua's garbage collector just wasn't keeping up with the increasingly larger discarded temporary tables.

Here's a code snippet that reproduces the problem for me:

Code: Select all

local g = golly()
local gp = require "gplus"
local split = gp.split
local pattern = gp.pattern

local pat = pattern({})
local x = 0

local k=g.getevent()
while k=="" do
  pat=pat+pattern("2o$2o!",x, 0)
  x=x+3
  k=g.getevent()
  g.show(x//3)
end
pat.put()
I start seeing serious trouble around 5000 blocks or so. Y'all probably have more memory, so your mileage may vary.

Might it be worth adding a pattern.append method to the gplus module? That way this kind of incremental pattern building could be done by adding new cells to the same table at each step, instead of garbage-collecting two entire tables after copying them into a third. I think that's what's going on here, anyway -- haven't tested the theory yet.

The immediate simple workaround was to build a series of medium-sized cell tables -- one edge of the megacell at a time, for example -- store them in separate variables, and combine them at the very end. Those medium-sized tables only have to get copied and discarded once, and it seems to be enormously faster.

For the new megafier script I'll probably write an "N copies of pattern P at offset X, Y" function that builds and appends increasingly longer subpatterns with 2^k copies each, assembling N from its binary bits. It looks like that will be significantly faster again than my current method.

Still, maybe it's a good idea to document the issue in the Lua Scripting Help document, under Potential Problems and/or "Using the gplus module" -- at least if anyone else can see this effect. It just seems as if Python's += operator for patterns is much more memory-efficient than Lua's pat1 = pat1 + pat2 ... or at least it's garbage-collected a lot more smoothly.

User avatar
Andrew
Moderator
Posts: 766
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Golly 2.8 has been released

Post by Andrew » February 4th, 2017, 4:09 pm

dvgrn wrote:patternvar.put(x,y,{1,0,0,1},"xor") ...
Yep, that won't work because the put function doesn't expect to see a mode string. Make the following changes to gplus/init.lua and let me know if they work ok. If so I'll commit those changes for the next release.

Code: Select all

    p.put = function (x, y, A, mode)
        -- paste pattern into current universe
        x = x or 0
        y = y or 0
        A = A or m.identity
        mode = mode or "or"
        local axx, axy, ayx, ayy = table.unpack(A)
        g.putcells(p.array, x, y, axx, axy, ayx, ayy, mode)
    end

    p.display = function (title, x, y, A, mode)
        -- paste pattern into new universe and display it all
        title = title or "untitled"
        x = x or 0
        y = y or 0
        A = A or m.identity
        mode = mode or "or"
        g.new(title)
        local axx, axy, ayx, ayy = table.unpack(A)
        g.putcells(p.array, x, y, axx, axy, ayx, ayy, mode)
        g.fit()
        g.setcursor(m.zoomin)
    end
Also, might it make sense to adjust init.lua so that "emptypat = pattern()" works the same as "emptypat = pattern({})" ?
Works the same for me. What difference are you seeing?
Might it be worth adding a pattern.append method to the gplus module?
I doubt whether that would improve things all that much. The pattern stuff in gplus is really for convenience when translating Python code to Lua. If you want efficiency best to avoid it and work directly with the lower level commands.

User avatar
dvgrn
Moderator
Posts: 6058
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Golly 2.8 has been released

Post by dvgrn » February 4th, 2017, 6:47 pm

Andrew wrote:
dvgrn wrote:patternvar.put(x,y,{1,0,0,1},"xor") ...
Yep, that won't work because the put function doesn't expect to see a mode string. Make the following changes to gplus/init.lua and let me know if they work ok. If so I'll commit those changes for the next release.
Looks good -- I tried it in my test megafier script, and it worked fine.
Andrew wrote:
Also, might it make sense to adjust init.lua so that "emptypat = pattern()" works the same as "emptypat = pattern({})" ?
Works the same for me. What difference are you seeing?
Hmm. None at all. Must have been a late-night superstition brought on by an unrelated bug. Never mind that one, please.
Andrew wrote:
Might it be worth adding a pattern.append method to the gplus module?
I doubt whether that would improve things all that much.
Guess not. I looked again at how the gplus module works, and tried adding an experimental p.append. Definitely don't have any amazing improvements to report immediately...!

User avatar
Andrew
Moderator
Posts: 766
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Golly 2.8 has been released

Post by Andrew » February 5th, 2017, 5:27 am

dvgrn wrote:I looked again at how the gplus module works, and tried adding an experimental p.append.
There's really no need for an append function. Note that you can modify a pattern's internal array by just changing p.array, so here's a version of your test code that uses much less memory:

Code: Select all

local g = golly()
local gp = require "gplus"
local split = gp.split
local pattern = gp.pattern

local pat = pattern({})
local x = 0

local block = g.parse("2o$2o!")

local k=g.getevent()
while k=="" do
  -- MEMORY HOGGER: pat=pat+pattern("2o$2o!",x, 0)
  pat.array = g.join(pat.array, g.transform(block, x, 0))
  x=x+3
  k=g.getevent()
  g.show(x//3)
end
pat.put()

User avatar
dvgrn
Moderator
Posts: 6058
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Golly 2.8 has been released

Post by dvgrn » February 5th, 2017, 6:49 am

Andrew wrote:
dvgrn wrote:I looked again at how the gplus module works, and tried adding an experimental p.append.
There's really no need for an append function. Note that you can modify a pattern's internal array by just changing p.array, so here's a version of your test code that uses much less memory...
Relatively speaking, anyway. It does let me run the test longer without paging to the hard drive. But the new version still requires garbage-collecting the entire internal array with every added block, thanks to the g.join() call.

Compare the performance there to an actual append operation:

Code: Select all

local g = golly()
local gp = require "gplus"
local split = gp.split
local pattern = gp.pattern

local pat = pattern({})
local x = 0

local block = g.parse("2o$2o!")

local k=g.getevent()
while k=="" do
  -- MEMORY HOGGER: pat=pat+pattern("2o$2o!",x, 0)
  -- STILL KIND OF A MEMORY HOGGER: pat.array = g.join(pat.array, g.transform(block, x, 0))
  alen = #pat.array
  pat.array[alen+1], pat.array[alen+2], pat.array[alen+3], pat.array[alen+4] = x, 0, x+1, 0
  pat.array[alen+5], pat.array[alen+6], pat.array[alen+7], pat.array[alen+8] = x, 1, x+1, 1  
  x=x+3
  k=g.getevent()
  g.show(x//3)
end
pat.put()
This adds 100,000 blocks to the internal array in about a second on my system, which is about a factor of forty time improvement over what even the non-memory-hog script can manage, with a correspondingly large reduction in memory use.

Now, I'm not sure that Lua's length operator will always work correctly with pattern arrays, so I have some more experimenting to do. Couldn't get this idea to work yesterday in init.lua, because the length always came back as zero.

User avatar
Andrew
Moderator
Posts: 766
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Golly 2.8 has been released

Post by Andrew » February 5th, 2017, 5:12 pm

dvgrn wrote:I'm not sure that Lua's length operator will always work correctly with pattern arrays ...
It should always work if the pattern array is constructed correctly. For # to work a non-empty array must have only integer indices that start at 1 and are contiguous (ie. array[1] to array[#array] are not nil).
Couldn't get this idea to work yesterday in init.lua, because the length always came back as zero.
Maybe you were requesting the length of a pattern rather than its array field?

User avatar
dvgrn
Moderator
Posts: 6058
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Golly 2.8 has been released

Post by dvgrn » February 5th, 2017, 5:37 pm

Andrew wrote:
Couldn't get this idea to work yesterday in init.lua, because the length always came back as zero.
Maybe you were requesting the length of a pattern rather than its array field?
Not as far as I can see. The debug line below kept telling me that everything was length zero, when I tried using p.append with the megafier script I'm working on. Here's what I tried adding to init.lua as a first experiment:

Code: Select all

    p.append = function (p2)
        -- TODO:  add checks for pattern-ness, two-state vs. multistate
        local length = #p.array
        -- g.note(length.." "..#p2)
        for i=1, #p2 do
            length = length + 1
            p.array[length]=p2[i]
        end
        return p
    end
But I must have been doing something else wrong -- this test code is working fine now:

Code: Select all

local g = golly()
local gp = require "gplus"
local split = gp.split
local pattern = gp.pattern

local pat = pattern({})
local x = 0

local block = g.parse("2o$2o!")

local k=g.getevent()
while k=="" do
  -- MEMORY HOGGER: pat=pat+pattern("2o$2o!",x, 0)
  -- STILL KIND OF A MEMORY HOGGER: pat.array = g.join(pat.array, g.transform(block, x, 0))
  -- DIRECT CHANGES TO PATTERN ARRAY WORK:  alen = #pat.array
  --        pat.array[alen+1], pat.array[alen+2], pat.array[alen+3], pat.array[alen+4] = x, 0, x+1, 0
  --        pat.array[alen+5], pat.array[alen+6], pat.array[alen+7], pat.array[alen+8] = x, 1, x+1, 1  
  -- PATTERN.APPEND WORKS EQUALLY WELL:
  pat.append(block.t(x,0))
  x=x+3
  k=g.getevent()
  g.show(x//3)
end
pat.put()
I'll try again -- maybe I'm making non-canonical pattern arrays in the megafier script somehow... though I'm only using standard gplus functionality. Will try retrieving the key/value pairs if the length comes up as zero again, and see what turns up.

User avatar
LegionMammal978
Posts: 14
Joined: July 7th, 2016, 9:37 am

Re: Golly 2.8 has been released

Post by LegionMammal978 » May 25th, 2017, 6:45 am

Annoying bug on Win10 64-bit: When I attempt to run a pattern stored in the clipboard, I just get a dialog box with "Sorry, but Perl scripting is no longer supported."

User avatar
_zM
Posts: 172
Joined: June 26th, 2016, 3:07 pm

Re: Golly 2.8 has been released

Post by _zM » May 25th, 2017, 8:05 am

Are you using Ctrl-Shift-O? If yes, try pasting the pattern in. If not, try using Ctrl-Shift-O.
Creator of multiple rules that may or may not be what you'd expect

fluffykitty
Posts: 651
Joined: June 14th, 2014, 5:03 pm

Re: Golly 2.8 has been released

Post by fluffykitty » May 30th, 2017, 12:15 pm

Do you have a Perl script assigned to paste/open? If so, remove it or replace it with a Python/Lua script.
I like making rules

User avatar
gameoflifeboy
Posts: 474
Joined: January 15th, 2015, 2:08 am

Re: Golly 2.8 has been released

Post by gameoflifeboy » May 31st, 2017, 12:54 pm

I've had this problem before. When you choose the "Run Clipboard" option (which is for running scripts) with a pattern in the clipboard, the interpreter thinks it's a Perl script. Instead, you should select "Open Clipboard" which opens the clipboard as a pattern.

fluffykitty
Posts: 651
Joined: June 14th, 2014, 5:03 pm

Re: Golly 2.8 has been released

Post by fluffykitty » May 31st, 2017, 6:17 pm

Probably the large number of $ signs. (I wonder if I can trick Golly's language detection with a carefully made string...)
I like making rules

User avatar
gameoflifeboy
Posts: 474
Joined: January 15th, 2015, 2:08 am

Re: Golly 2.8 has been released

Post by gameoflifeboy » June 11th, 2017, 10:36 pm

On Golly 2.8, pressing the keys Z, V, T, etc. usually works for undoing, pasting, fitting, etc. However, sometimes it doesn't and Ctrl+Z, Ctrl+V, Ctrl+T need to be pressed instead. This usually happens right after un-minimizing Golly and usually stops as soon as the pattern gets edited.

fluffykitty
Posts: 651
Joined: June 14th, 2014, 5:03 pm

Re: Golly 2.8 has been released

Post by fluffykitty » June 12th, 2017, 2:30 pm

Check Caps Lock. That can cause problems (because WxWidgets is stupid, most likely)
I like making rules

Post Reply