golly-test Mailing List for Golly

If possible, I'd like to announce builds of Golly 2.8b3 in the
conwaylife.com forums some time in the next few days.

Tom, can you please do a 64-bit build for Windows?
I think you just need to edit your local-win.mak file and delete or
comment out any PERL related lines, and also add this line:
LUA_DEFS = -DLUA_COMPAT_5_2

Maks, can you please do 32 and 64-bit builds for Linux?
Hopefully it should be quite simple now that Perl is disabled.

Andrew

Me:

> That's going to make it tricky to fix.  ...

And it was.  Turned out to be a re-entrancy bug in the wxOSX code.
I couldn't find any way to work around it in the Golly code so had
to patch the wxOSX code (details below).  I hate having to do that
but unavoidable sometimes.  Dean, here is a new build that hopefully
won't crash when you scroll:

http://www.trevorrow.com/golly/golly-2.8b3-mac.zip

To Robert and anybody else who builds a Mac version of Golly,
edit /your/path/to/wxWidgets-3.0.2/src/osx/cocoa/window.mm and
add some lines (flagged by AKT) to wxWidgetCocoaImpl::mouseEvent():

static bool in_mouseEvent = false;  //AKT

void wxWidgetCocoaImpl::mouseEvent(WX_NSEvent event, WXWidget slf, void *_cmd)
{
    <snipped>

    //AKT: avoid crash due to re-entrancy
    if (in_mouseEvent) return;
    in_mouseEvent = true;
    
    if ( !DoHandleMouseEvent(event) )
    {
        <snipped>
    }

    in_mouseEvent = false;  //AKT
}

Andrew

Dave:

> It seems to me that the following snippet will sometimes fail to find
> the glife module, if I run it from clipboard immediately after a
> reboot.
> 
> import golly as g
> from glife.text import make_text
> test_text = make_text("test", "mono")  # fails if make_text not previously imported
> g.putcells(test_text)
> 
> ...

If you're only seeing the problem after a reboot then I doubt we can do
anything in Golly to avoid the problem, even if you can find a way to
make it reproducible.  Sounds to me like a bug in the Windows file system
code (unlikely) or in the python*.dll code.

Andrew

>> The glife package in Python causes
>> mysterious errors sometimes if a script wasn't saved where Golly
>> expected it to be, relative to the glife folder.  Are there any
>> similar limitations for Lua and gplus, that I haven't run into yet?
>
> Hmm, I'm not aware of any problems with glife.  I regularly run my
> own set of .py scripts that aren't in Golly's Scripts/Python folder.
> Let me know if you've got a script (hopefully simple!) that can
> reproduce the problem.

I've been running into a minor intermittent hiccup for quite a while,
documented at the bottom of this post:

http://conwaylife.com/forums/viewtopic.php?f=2&t=1682&p=18907#p18907

It seems to me that the following snippet will sometimes fail to find
the glife module, if I run it from clipboard immediately after a
reboot.

import golly as g
from glife.text import make_text
test_text = make_text("test", "mono")  # fails if make_text not
previously imported
g.putcells(test_text)

It was always true that a code snippet that imports make_text will run
with no problem, if another script that makes use of the glife
make_text module has been run successfully since the last reboot --
not just since the last restart of the Golly application, but the last
full OS reboot.  My usual workaround was to run pop-plot.py; that
always fixed the problem.

After the next reboot the problem would surface again.  It happened
dozens of times with the attached Herschel-to-glider statistics
generator script, which was why I ended up importing the relevant
make_text functions into the version of the script posted in the above
link.

However, I just went downstairs to my old laptop, rebooted, changed
the pattern and script folders to something that didn't contain the
glife folder (just for good measure) and ran the above snippet from
the clipboard... and it worked fine, no errors, on 32-bit Golly 2.7
and 2.8b3.

This is the computer where I was doing most of the conduit-collecting
work that required running the attached script, so I'm surprised that
the bug has failed to resurface.

... For now I guess I'll just mention it here as an unreproducible
mystery.  Will post details if the problem shows up again.

Keep the cheer,


Dave

Dean:

> I've found that Golly sometimes crashes if I scroll the window while
> running a large pattern.  ...

Ouch!  Yep, I can reproduce the crash quite easily.  Unfortunately it seems
to be happening inside some wxWidgets code:

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	0x00007fff8718df10 objc_msgSend + 44
1   com.apple.AppKit              	0x00007fff84df7d02 _NSDefaultTopLevelErrorHandler + 57
2   com.apple.AppKit              	0x00007fff847b378f -[NSApplication run] + 651
3   net.sourceforge.golly         	0x00000001001e036e wxGUIEventLoop::OSXDoRun() + 112
4   net.sourceforge.golly         	0x0000000100361274 wxCFEventLoop::DoRun() + 50
5   net.sourceforge.golly         	0x00000001002f00c1 wxEventLoopBase::Run() + 179
6   net.sourceforge.golly         	0x00000001002d29a6 wxAppConsoleBase::MainLoop() + 96
7   net.sourceforge.golly         	0x00000001001aeceb wxApp::OnRun() + 29
8   net.sourceforge.golly         	0x0000000100317c06 wxEntry(int&, wchar_t**) + 102
9   net.sourceforge.golly         	0x0000000100122c34 main + 20
10  net.sourceforge.golly         	0x0000000100001344 start + 52

That's going to make it tricky to fix.  I'll have to see if I can avoid
the crash somehow, possibly by disabling generating while scrolling.

Thanks for the detailed report!

Andrew

Dave:

> Meanwhile, I've gotten through the interesting process of converting
> that script into Lua.  ...

Much thanks -- I've added it to Scripts/Lua.  I had to make one minor
correction: you had g.autoupdate(True) rather than g.autoupdate(true).
This is one of Lua's more unfortunate aspects, but it's easy to catch
such errors if you do this

local g = golly()
require "gplus.strict"

while working on a script and then remove that line when it's working.
This is mentioned in the "Potential problems" section.

Actually, I removed the g.autoupdate(true) call completely and instead
added g.update() after g.fit().  This speeds up the display because
it avoids an unnecessary update after the *.put calls.  I've also
made the same improvement in metafier.py.


> ...  Then we'd finally be getting close to having a structured
> pattern format about as good as Xlife's #I format was a couple of
> decades ago...!  Lua will be available in Golly without anyone having
> to install anything extra, so it really seems as if a Lua "pattern
> script" format might become a viable option.

Yep, this is a big advantage of a statically embedded Lua.  I agree
it makes a lot of sense to have more .lua files in the pattern collection.
(No real need to have their .rle equivalents or .zip versions though.)
I'm keen to add Lua support in the next iOS/Android versions of Golly
so people can open the same set of patterns supplied in desktop Golly.


> -- I just checked, and it looks as if Golly can locate the gplus
> package no matter where the script is saved; it doesn't have to be in
> the Scripts\Lua directory.

Yep, this is an important feature (especially because we recommend
that people should NOT be putting their own files in Golly's supplied
folders).   It was easy to achieve by appending the necessary path info
to Lua's package.path.  You can see the list of search paths by copying
and executing this code via Run Clipboard:

local g = golly()
g.note(package.path:gsub(";",";\n"))


> The glife package in Python causes
> mysterious errors sometimes if a script wasn't saved where Golly
> expected it to be, relative to the glife folder.  Are there any
> similar limitations for Lua and gplus, that I haven't run into yet?

Hmm, I'm not aware of any problems with glife.  I regularly run my
own set of .py scripts that aren't in Golly's Scripts/Python folder.
Let me know if you've got a script (hopefully simple!) that can
reproduce the problem.

Andrew

> I'm pretty sure the problem was in the py_store code (in wxpython.cpp).
> I've fixed it so there shouldn't be any more crashes.

If I can run the current metafier.py script in the next 64-bit build
of Golly 2.8b3, that will be a very good sign, I think.

Meanwhile, I've gotten through the interesting process of converting
that script into Lua.  Had to look again at all the comments I put in
there a decade ago, saying basically "this could be done a lot better,
but I'm tired of registering all these subpatterns."

It's actually possible to improve metafier.lua relatively easily now,
probably cutting the size in half or more.  A few years back I wrote a
fairly nice Python recognizer script that allows subpatterns to be
selected and added by name to a customizable library.  The script runs
through a large pattern and fairly quickly removes subpatterns that
match something in the library, stopping at the first unrecognized
subpattern.

If the script gets all the way through and removes all the ON cells
from the original pattern, it writes out a Python script that
reconstitutes the pattern in terms of its subpatterns.  This turns out
to be a very competitive compressed pattern format for most large
structured patterns, much better than .rle.gz or .mc.gz, for example.
I suppose a zipped script would be even better compression.

My plan is to get back and translate recognizer.py into Lua, and write
patterns out as Lua-gplus scripts instead of Python scripts.  With any
luck I'll get around to allowing recursive definitions in the library,
too.  Then we'd finally be getting close to having a structured
pattern format about as good as Xlife's #I format was a couple of
decades ago...!  Lua will be available in Golly without anyone having
to install anything extra, so it really seems as if a Lua "pattern
script" format might become a viable option.

This might apply to patterns in the pattern collection as well.  There
are quite a few patterns that could stand to have default zoom
locations or simulation speeds set, or even just an initial status-bar
g.show() message to explain how best to run the pattern.  Maybe a
pattern-name.lua in the same folder as pattern-name.rle, so that it's
possible to bypass the script and open the RLE directly?  Or if that
takes up too much space in each Patterns subdirectory, maybe a
parallel Opener-Scripts directory with nothing but Lua files -- a
pattern-name.lua pointing to each pattern-name.rle in Patterns.

-- I just checked, and it looks as if Golly can locate the gplus
package no matter where the script is saved; it doesn't have to be in
the Scripts\Lua directory.  The glife package in Python causes
mysterious errors sometimes if a script wasn't saved where Golly
expected it to be, relative to the glife folder.  Are there any
similar limitations for Lua and gplus, that I haven't run into yet?

Anyway, the metafier.lua that I came up with is attached.  Let me know
if this or other questionable script contributions of mine seem to
need any more work...!

Keep the cheer,


Dave

I've found that Golly sometimes crashes if I scroll the window while running a large pattern.  I don't have a reliable way of making this happen, but this usually causes it:

Open this pattern:

x = 2, y = 1000000, rule = B3/S23
o$999999bo!

Choose Select All and then Random Fill from the Edit menu.  Choose a step size of 1 and a scale of 1:2, and let the pattern run for 50 gens or so.  Now position the mouse pointer in the horizontal scroll bar, near the right end, and hold down the mouse button.  Two things may happen.  Either (1), the generation number will stay constant and the window will scroll rapidly to the right, or (2) the generation number will increase and scrolling will be slower.  In case (1), let go of the button, let the pattern run a while longer, and try again.  Eventually case (2) should occur.  After a while, let go of the button.  The pattern will continue to advance and the window will continue scrolling slowly.  Click again in the scroll bar, and Golly will crash.

I've also had it crash while I was still pressing the mouse button, but that seems to be less common.

I'm using version 2.8b3 (64-bit) on an iMac with OS X 10.11.

Dean Hickerson

Dave:

> ...
> Tried changing the call to golly.store() in glife __init__.py so that
> it passes in an empty string instead of None by default -- that didn't
> seem to work either...

I'm pretty sure the problem was in the py_store code (in wxpython.cpp).
I've fixed it so there shouldn't be any more crashes.

Andrew

 > I deleted those files on my Mac (64-bit Golly) and WinXP (32-bit Golly)
> and metafier.py had no problems saving them.
>
> One thing you could try in metafier.py: delete the string parameters
> passed into OFFcell.save and ONcell.save.  I just noticed in the
> py_store code that we don't actually try to retrieve the optional
> description arg!  I suspect that's why the crash is occurring
> (although curious that I don't see any crash).

Okay, update from 64-bit laptop:

Confirmed that 32-bit Golly doesn't crash and exit when saving the
metafier tiles, by installing 32-bit Python to go with Golly 2.8b3.
No problem.
Tried editing metafier.py to OFFcell.save (OFFcellFileName,"").  Still
the same crash in 64-bit Windows Golly 2.7.
Tried OFFcell.save (OFFcellFileName) -- same crash.
Tried changing the call to golly.store() in glife __init__.py so that
it passes in an empty string instead of None by default -- that didn't
seem to work either...

Replaced the glife .save line in metafier.py with
g.store(OFFcell,OFFcellFileName).  That works fine in 64-bit Golly
2.7, for whatever reason.

So that's a fine workaround, but the crash is still rather puzzling.

Keep the cheer,


Dave

Dave:

> It turns out that it happens consistently on my laptop, running 64-bit
> Golly 2.7 and 64-bit Python 2.7.8.  ...
> ...
> Could you try deleting metapixel-ON.rle and metapixel-OFF.rle from
> your AppData\Roaming\Golly folder, before running your Windows test?

I deleted those files on my Mac (64-bit Golly) and WinXP (32-bit Golly)
and metafier.py had no problems saving them.

One thing you could try in metafier.py: delete the string parameters
passed into OFFcell.save and ONcell.save.  I just noticed in the
py_store code that we don't actually try to retrieve the optional
description arg!  I suspect that's why the crash is occurring
(although curious that I don't see any crash).

> It looks like your 2.8b3 Windows build is a 32-bit build.  Is it
> possible to get the 32-bit vs. 64-bit build information into Help >
> About Golly for this release, by the way?

The info in the About box is simply loaded from Help/about.html
so it would require some messy changes to show 32/64-bit info.
It's not that hard just to stop/restart Golly is it?

Andrew

> I just tested metafier.py on a glider in a 10x10 selection using
> the latest Mac and Win versions and had no problems.  Let me know
> if you find a reproducible crash.

It turns out that it happens consistently on my laptop, running 64-bit
Golly 2.7 and 64-bit Python 2.7.8.  It's a problem that I reported for
Golly 2.6, that's cropping up again after all, in spite of my not
having seen it when Golly 2.7 first came out.  See

  https://sourceforge.net/p/golly/mailman/message/34120507/

The script gets as far as displaying the "Building OFF metacell
definition..." message, and calls glife's save function --
OFFcell.save() -- but only if metafier.py has never been run before on
the computer).  A generic Windows crash message immediately appears,
and the file doesn't get saved:

Golly.exe
Golly.exe has stopped working
Windows can check online for a solution to the problem.
[V] View problem details  [Check online for a solution and close the
program] [Close the program] [Debug the program]

Problem signature:
Problem Event Name: APPCRASH
Application Name: Golly.exe
Application Version: 0.0.0.0
Application Timestamp: 556693b7
Fault Module Name: python27.dll
Fault Module Version: 2.7.8150.1013
Fault Module Timestamp: 53b1ee00
Exception Code: c0000005
Exception Offset: 00000000001284f2
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 1033
Additional Information 1: 6aec
Additional Information 2: 6aec34f1f02e17ccdbf463de6fd1d141
Additional Information 3: 840d
Additional Information 4: 840d9c3bfe4ac6541eccccf233834a29

It looks like your 2.8b3 Windows build is a 32-bit build.  Is it
possible to get the 32-bit vs. 64-bit build information into Help >
About Golly for this release, by the way?

I only have 64-bit Python installed on this laptop, so I can't test
metafier.py on 2.8b3.  But I now suspect that the problem is
64-bit-specific.  It's at least somewhat possible that I was testing a
32-bit build of Golly 2.7, and that's why I didn't see the crash last
May.

Could you try deleting metapixel-ON.rle and metapixel-OFF.rle from
your AppData\Roaming\Golly folder, before running your Windows test?

I just confirmed that 64-bit Golly 2.7 metafies things just fine, as
long as it doesn't have to call that OFFcell.save line.

Keep the cheer,


Dave

Dave:

> Anyway, I'll find some time over the weekend to play around with this
> build, and convert the metafier script to Lua at the very least.  I
> have to take another look at the Python version as well -- Golly
> crashed and exited when I tried to run it recently, but I'm not sure
> which version of Golly I was using.  I thought that problem had
> already been found and fixed, a good while back...?

I just tested metafier.py on a glider in a 10x10 selection using
the latest Mac and Win versions and had no problems.  Let me know
if you find a reproducible crash.

Which reminds me of another advantage of Lua.  Unlike Python, it
frees up all memory it uses when a script finishes.

Andrew

> Here are new Mac/Win builds for people to try:
>
> http://www.trevorrow.com/golly/golly-2.8b3-mac.zip
> http://www.trevorrow.com/golly/golly-2.8b3-win.zip
>
> I'm pretty happy with the gplus package but let me know if it could
> be improved.  It's documented in Help > Lua Scripting.  I've also
> added more tips to the "Potential problems" section.

Looks good so far!  I like the gplus coverage in the Lua Scripting
Help file.  Will have to think hard about what other hints might need
to be added -- there are quite a number of Python beginner errors that
have piled up on the conwaylife.com forums, that probably have
very-near-equivalent Lua beginner errors.

Anyway, I'll find some time over the weekend to play around with this
build, and convert the metafier script to Lua at the very least.  I
have to take another look at the Python version as well -- Golly
crashed and exited when I tried to run it recently, but I'm not sure
which version of Golly I was using.  I thought that problem had
already been found and fixed, a good while back...?

Keep the cheer,


Dave

Here are new Mac/Win builds for people to try:

http://www.trevorrow.com/golly/golly-2.8b3-mac.zip
http://www.trevorrow.com/golly/golly-2.8b3-win.zip

I'm pretty happy with the gplus package but let me know if it could
be improved.  It's documented in Help > Lua Scripting.  I've also
added more tips to the "Potential problems" section.

Other noteworthy changes:

I added a g.continue(err) function so Lua scripts can emulate
Python's "try: ... finally: ..." to execute finalization code.
See the end of slide-show.lua for example.

I also added a g.getfiles(dir) function to get the contents of
a given directory as an array of strings.  Subdir names are
terminated with the platform-specifc path separator.
See the top of slide-show.lua.

I've added more .lua scripts.  Dave, see p1100-MWSS-gun.lua
and Patterns/Life/Oscillators/p59-glider-loop.lua in particular.
I think it should be pretty easy now to convert metafier.py
to a .lua version.

Apart from adding a few more .lua files, I'm hoping these builds
are pretty close to the final 2.8b3 builds we can announce in
the forums, maybe in a week or two after Dave/Robert/Dean have
had a chance to spot any problems?

Andrew

Hi guys. Yes, sorry, I'm not able to give be Golly the time it deserves at
the moment. Remove it and we can look at revisiting it later.

Tim
On 15 Apr 2016 01:11, "Andrew Trevorrow" <an...@tr...> wrote:

> Maks:
>
> > Is it used for any builds/environments which aren't supported by either
> > the makefile-??? files, or the autoconf scripts? ...
>
> No, it's just an alternative way to build Golly.  Tim Hutton preferred
> to use CMake but he seems to be busy on other stuff at the moment.
> I'll wait a few days and then remove it (along with the CMake section
> in docs/Build.html).  If Tim reappears and wants to fix it we can
> easily add it back.
>
> Andrew
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

Maks:

> Is it used for any builds/environments which aren't supported by either
> the makefile-??? files, or the autoconf scripts? ...

No, it's just an alternative way to build Golly.  Tim Hutton preferred
to use CMake but he seems to be busy on other stuff at the moment.
I'll wait a few days and then remove it (along with the CMake section
in docs/Build.html).  If Tim reappears and wants to fix it we can
easily add it back.

Andrew

Dave:

> Now that gollylib() won't be called a "lib" any more, maybe just
> "glifelib" would be okay?

I'd prefer to avoid any reference to a library.  In Lua terminology
a library is some compiled C code (which is why I initially chose
gollylib for the name of the function that provides access to
Golly's statically linked code).  Best not to offend the Lua purists
by having "lib" in our package name.

> Or actually I like just plain "glib" -- nice and short, and it also
> means "fluent and voluble"...!  ...

Hmm, according to some online dictionaries it can also mean:

- ease and fluency in speaking or writing often to the point of
being insincere or deceitful

- readily fluent, often thoughtlessly, superficially, or insincerely

- speaking or spoken in a confident way, but without careful thought
or honesty

Not sure we want any of those connotations! :)

I think I'll use gplus.

Andrew

Is it used for any builds/environments which aren't supported by either the
makefile-??? files, or the autoconf scripts? If not, I'd say remove it:
less maintenance work for us, and less confusing for users.

On Thu, Apr 14, 2016 at 3:10 AM, Andrew Trevorrow <an...@tr...>
wrote:

> Is anybody still willing to maintain gui-wx/CMakeLists.txt?  If not, we
> should probably remove it from the final 2.8 release.
>
> At the moment it needs a number of changes:
>
> - include OpenGL headers and libs
> - include lua code
> - remove Perl stuff (or make it optional by defining ENABLE_PERL)
>
> Andrew
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

> I could have called the package "glife" but I wanted to avoid any
> confusion with the Python glife (there are a number of differences --
> some obvious, some subtle).

Now that gollylib() won't be called a "lib" any more, maybe just
"glifelib" would be okay?

Or actually I like just plain "glib" -- nice and short, and it also
means "fluent and voluble"...!  There are various flavors of Linux
with GLib packages, but I doubt that would cause any confusion.

Keep the cheer,


Dave

Is anybody still willing to maintain gui-wx/CMakeLists.txt?  If not, we
should probably remove it from the final 2.8 release.

At the moment it needs a number of changes:

- include OpenGL headers and libs
- include lua code
- remove Perl stuff (or make it optional by defining ENABLE_PERL)

Andrew

I'm nearly ready to do new Win/Mac builds.  Before I do, I'd like some
feedback/suggestions on some of the names I've chosen:

1. At the moment, all our .lua scripts must start with a line like:

local g = gollylib()

We can name the gollylib() function anything we like, so I'm now
thinking we should just call it golly().   Not only shorter but
it's closer to the Python equivalent line "import golly as g".
Any objections to that change?  Any other suggestions?

2. To include Lua's glife emulation package we currently do:

local gp = require "gpackage"

I could have called the package "glife" but I wanted to avoid any
confusion with the Python glife (there are a number of differences --
some obvious, some subtle).

I'm not 100% happy with the name gpackage, so any better ideas?
Maybe gplus, or ghelpers, or gextras?  Whatever name we choose, it
would be nice if its most likely local name (eg. "gp") is an
uncommon string so users can easily search for and/or rename "gp.".
At this stage I'm tossing up between gpackage and gplus.

I'll document the gpackage/whatever stuff in Help/lua.html
before doing the new builds.

Andrew

Dave:

> Attached is a draft heisenburp.lua ...

Thanks!  I'll add it to Scripts/Lua.

> Obviously I removed all the glife calls, which was pretty easy when I
> thought about it ...

Actually, I did a bit of reading on my hols and started work on
a package that should be able to emulate nearly all of glife.
(A Lua package is simply a folder containing a set of .lua files.)
For example, here's a working version of bricklayer.lua:

------------------------------------------------------------------------
-- Based on bricklayer.py from PLife (http://plife.sourceforge.net/).

local g = gollylib()
local gp = require "gpackage"
local pattern = gp.pattern

g.setrule("B3/S23")

local p22_half = pattern("2o$bo$bobo$2b2o3bo$6bob2o$5bo4bo$6bo3bo$7b3o!")
local p22 = p22_half + p22_half.t(26, 9, gp.flip)

local gun22 = p22 + p22[1].t(-18, 11)
local gun154 = gun22[27] + gun22[5].t(49, 12, gp.rcw) + gun22.t(5, 53, gp.flip_y)

local p7_reflector = pattern([[
2b2o5b2o$2b2o5bo$7bobo$7b2o$3b2o$3bobo$4bo3$13bo$10bo2b3o3b2o$3b5o
2b3o3bo2bo$b3obob3o4b2obobo$o4bo4b4obobo2b2o$2ob2ob4o3bobob2obo$
4bobobobobo2bo2bobo$4bobobo2bo2bob3ob2o$3b2obob4o6bobo$7bo4b6o2b
o$9bo2bo2bo4b2o$8b2o!]])
local pre_lom = pattern("2bo$2ob2o$2ob2o2$b2ob2o$b2ob2o$3bo!")

local all = gun154[210].t(-52, -38) + gun154[254].t(52, -38, gp.flip_x) +
	p7_reflector.t(8, 23) + pre_lom.t(-3, 30)

all.display("bricklayer")
------------------------------------------------------------------------

The above code is very similar to the Python version.  Note that "+" can
be used to join patterns.  You can also do p[n] to evolve pattern p.
It doesn't seem possible to emulate calls like p[n](...) or p(...)
so they have to be converted by inserting ".t" before the "(".
The "t" function just calls g.transform.

The require "gpackage" call loads a file called init.lua in Scripts/Lua/gpackage.
My prototype package also contains text.lua (similar to glife's text.py) so
scripts like pop-plot.lua can do this:

local gpt = require "gpackage.text"
local maketext = gpt.maketext

People can use whatever names they like for those locals.
Some time this week I'll commit the gpackage stuff and do new Mac/Win
builds so you and Robert can try it out.


> In dealing with keyboard event handling, I started thinking about the
> space-delimited event strings that Golly returns.  Seems like there's
> kind of an implicit assumption there that an easy split function is
> available.  ...

A nice split function is one of the things I intend to add to gpackage.
I'll be using it when I write draw-lines.lua, flood-fill.lua, etc.

> Just for the record, here's the rest of the list of syntax conversions
> that I noted down as I went along.  Python -> Lua:
> ...

Nice list.  I'll save it for when we announce 2.8b3 in the forums.
At that time it might be a good idea to start up a "Lua tutorial"
thread to encourage people to start writing Lua scripts.

Andrew

Andrew wrote/I wrote:
>> Ditto to Dave.  Any chance you could do .lua versions of
>> heisenburp.py and/or metafier.py?  I can upload a 32-bit Win build
>> of 2.8b3 if you need it.
>
> Sure, I can give that a try.  Heisenburp.py does a lot of keyboard
> monitoring and changes to layers and layer settings and so forth, so
> it should make for a good extended test of your Lua functions.

Attached is a draft heisenburp.lua that seems to work about the same
way that heisenburp.py did.  I added a couple of small details, mostly
to the status bar text, to try to explain what's going on a little
better.  It's a strange old script, and I don't remember seeing that
anyone else ever tried to build anything like it.

Obviously I removed all the glife calls, which was pretty easy when I
thought about it -- most of glife is fairly shallow aliases for
things, or syntactic sugar.  It's easy to do the same thing in a
slightly more wordy way.  Once that conversion was one, many of the
lines of Python were identical to their Lua versions.  Maybe if I were
rewriting the script from scratch, I might come up with a slightly
more Lua-like way of doing some things, but all in all it seems like
the Golly function calls are going to be very similar.

The biggest difference is glife's overloaded addition operator for
pattern objects.  Here's a sample line in Python:

    wire2c3=head2c3(625,388) + tail2c3(2143,1905)

In Lua this becomes

    wire2c3=g.join(g.transform(head2c3,625,388), g.transform(tail2c3,2143,1905))

-- which is actually identical to the syntax in Python-without-glife.
Similarly,

    wire2c3=head2c3(625,388)[10]

would become either

    wire2c3=g.evolve(g.transform(head2c3,625,388),10)
    wire2c3=g.transform(g.evolve(head2c3,10),625,388)

-- again, the same as Python-without-glife.

Not too bad, really, considering how many functions Lua doesn't have
built in -- like plain old string.split() for example.

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

In dealing with keyboard event handling, I started thinking about the
space-delimited event strings that Golly returns.  Seems like there's
kind of an implicit assumption there that an easy split function is
available.  Might it make sense in Lua to return the individual
substrings separately?

>From what I understand so far, it might be a nice Lua-like trick to
return {fullstring, key, charname, x, y, button, modifiers}, with nil
for the key-specific or click-specific parameters depending on the
event type.  Then if someone just wants the string they can do the
usual

    evt=g.getevent()

but if they want just the key name part, they could use

    evt, _, ch = g.getevent()
    if ch ~= nil then...

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

Just for the record, here's the rest of the list of syntax conversions
that I noted down as I went along.  Python -> Lua:

triple quotes become [[ ]]
variable definition -- generally just prefix first declaration with
"local" to avoid strange behavior from unexpected global variables.
list [] to {}
string concatenation "+" becomes ".."
cell-list concatenation has to be done with g.join(), in the absence
of a glife-overloaded addition operator
+=, -=, *= not supported in Lua -- have to say e.g., n=n+1
!= or <> to ~=
True, False become true, false
# comments become --
in if statements, ":" becomes " then "
"elif" beomes "elseif"
int() becomes math.floor(), or tonumber() when converting strings
str() becomes tostring()
"def" becomes "function", remove ending colon, remember to add "end"
at end of function
Add lots of "end" keywords at end of for loops, while loops,
if/elseif/else blocks, etc.

Other glife equivalents:

pattern() becomes g.parse()
getposint() becomes g.getpos() (and the returned strings may have to
be converted to numbers)
setposint() becomes g.setpos() (and the input numbers may have to be
converted to strings)
display() becomes g.new()

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

Other than all that, the only problem I ran into is that the
stable-Heisenburp pattern's circuitry is so embarrassingly out of
date.  A few Snarks and syringes could cut the area of this
monstrosity down to a fraction of the current size.  Not thinking
about that any more tonight...!

Keep the cheer,


Dave

Andrew Trevorrow wrote: 

> Dean, you might also like to test this build.  It has the new
> setview/getview/shrink changes.  I've tested these in a Lua script
> but haven't had time to try the Python versions.
>
> Actually, I'm not 100% sure the above build (made on 10.6) will
> run on your 10.11 system.  If it does run ok then it means we
> don't have to distribute 2 different Mac builds.

Thanks.  So far it's working fine.  I'll test the new functions in a day or two.

Dean