Found this. Now I am confused at a higher level :slightly_smiling_face: https://wiki.archlinux.org/index.php/HiDPI
I’ve actually got a hidpi screen, but I avoid any problems by scaling everything up using the x server instead of by application.
That’s how you write an issue!
https://github.com/racket/racket/issues/3227\|https://github.com/racket/racket/issues/3227
@amirouche.boubekki has joined the channel
Could someone with write permissions to racket/ transfer this issue to the racket/scribble repo? https://github.com/racket/racket/issues/3226
@maueroats has joined the channel
Sokoban levels get complicated fast
Hello all!
Pretty sure that’s the number of nodes in your search tree, not the number of states, which is 15 ;) Looks like someone needs transposition tables?
I definitely recommend the Microban levels for starters, not the original XSokoban levels.
it’s neither: it’s the maximum possible branching factor
the planner takes an initial state and a set of all possible actions that can be applied, and actions may not be applicable in a particular state
so it doesn’t derive a set of applicable actions from the state at each node in the search space - the set of actions is computed ahead of time and then each state filters that set down to just the actions that are applicable in that specific state
hmm, actually I’m gonna add a sokoban-applicable-actions function to make this distinction clearer