claude

Working on 'et' (my escape-time #fractal program) this morning.

I added #supersampling presets from 1x1 through 8x8, selectable by keypress. It already did supersampling but you had to enter 3 numbers in a modal dialog.

The calculations of the array used for progressive image rendering were annoyingly slow, so I'm now caching them on disk using the xdg-basedir and vector-mmap packages (et is written in #Haskell). I also need the directory and filepath packages for this part.

The arrays get quite big, almost 700MB total for all supersampling sizes with a base resolution of 1024x576 pixels (it takes up 6 bytes per pixel). Changing the base resolution size means recalculating and storing another set of arrays. Cache will bloat!

So I'm thinking there might be a better procedural way to do what the arrays do, which is #Adam7 style interlacing (coarse pixels getting gradually finer in a multipass rendering) with the pixels in each pass ordered so that the center gets rendered first and it spreads out towards the edges.

So in short I need a cheap function from (ImageWidth, ImageHeight, PixelIndex) to (PixelX, PixelY, PixelWidth, PixelHeight), because using anything other than #atomics to increment PixelIndex is much too slow in #concurrent #multicore Haskell.

Jun 5, 2019 at 8:01amWeb
Show threadclaudeJun 5, 2019

Added a new feature to et-gtk: quick image saving. The time of program launch is stored, and pressing 's' saves an image with this timestamp and a sequence number in the filename. Uses the #Haskell 'xdg-userdirs' (to find "~/Pictures" regardless of language) and 'time' packages (to get the time and format it).

Eventually the PNG files will contain metadata (formula, coordinates, etc) that can be reloaded into the et GTK GUI, and I want to add a batch mode to the CLI renderer so I can point it at a bunch of such PNGS with options like "re-render all of these at higher resolution".

Even later I want to add an 'r' shortcut to add to a render queue, so I don't need to launch the CLI renderer manually.

Show threadclaudeJun 5, 2019

I re-enabled "ignore isolated glitches" for non-progressive rendering (as used in the CLI renderer, but not the GTK GUI). This speeds up high resolution perturbation rendering at the cost of inaccuracy (hopefully invisible after downscaling).

Theoretical worst case is 1/4 of pixels being wrong, but that is highly unlikely in practice.

Show threadclaudeJun 5, 2019
Implemented PNG comment metadata saving. Still working on PNG comment metadata loading. Nearly there I think. The build times with #cabal #ghc #haskell are killing me though.
Show threadclaudeJun 5, 2019

Over 2 minutes to build each time I make a typo :(

Fixed them now though, PNG comment metadata loading works in the GTK GUI.

No more copy/pasting values from various windows into text files to save my explorations!

Show threadMasseRJul 10, 2019
@mathr
Have you tried just ghci or ghcid? Ghci interpreting is much faster
Show threadclaudeJul 10, 2019

@MasseR Not properly - I did try `cabal v2-repl` to test some things but not sure how it interacted with executables.

Moreover there might be some issues with #GTK and #OpenGL vs #thread local storage, but probably not insurmountable.

More important will likely be splitting the package from one fat `et.cabal` with #library and #executable, into separate packages for library and executable - this will save `cabal v2-install` rebuilding the whole library every time I change only the executable's source.

#haskell #cabal #ghc #ghci

Show threadclaudeJul 30, 2019

@MasseR ok so I tried `cabal repl` again as laptop takes even longer to recompile:

```
$ cabal v2-repl et-gtk
...
longhash/Hs-gi-gtk-ghc865.so: undefined symbol: gtk_cell_accessible_parent_get_row_header_cells)
cabal: repl failed for exe:et-gtk from et-0.
```

So my guess is that the GHCI runtime linker fails to load the foreign GTK library...