VIP Auto-Load and ASCII Diagrams
Hi all, I made a little video explaining two relatively new features in Vip: 1. Vip has an Auto-Load functionality, inspired by shell hash-bang scripts. 2. It comes with a library that generates ASCII drawings from Lisp code. As I use Vip itself to generate a simple slide show, I call it a "Vip-Video": https://picolisp.com/pub/VipAsciiDiagrams.mp4 I hid the PentiKeyboard between each action. If it is all a bit to fast, just pause the video whenever you like. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Limitation of grid from @lib/simul.l
On Tue, Jul 02, 2019 at 10:19:29AM +0900, Alexander Burger wrote:
> For each grid-cell it woud be one more heap-cell for the name, plus 1.5
> heap-cells on the average for the index.
Without name, each grid-cell takes up 4 heap-cells:
One for the symbol itself, and three for its value holding the connections to
neighbor cells:
: (show (cadadr *Grid1))
"b2" (("a2" . "c2") "b1" . "b3")
-> "b2"
: (size (val @))
-> 3
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Limitation of grid from @lib/simul.l
On Tue, Jul 02, 2019 at 10:07:43AM +0900, Alexander Burger wrote: > @Mike: What do you think? Would it break or disturb any of your code? Hmm, one major drawback would be that it uses a lot more memory. For each grid-cell it woud be one more heap-cell for the name, plus 1.5 heap-cells on the average for the index. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Limitation of grid from @lib/simul.l
Hi Wojtek, Mike, > Speaking of readability, we could have a naming scheme not limited by the > 26 columns if we used lexicographic strings (e.g. a b ... x y z aa ab .. > etc). I've written a function generating relevant strings based on column > and row numbers. Feel free to incorporate it in the definition of 'grid': > > (de num->alnum (Col Row) > ... Good idea! @Mike: What do you think? Would it break or disturb any of your code? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Limitation of grid from @lib/simul.l
Thanks for the rundown Rick! pon., 1 lip 2019 o 22:12 napisał(a): > On Mon, 01 Jul 2019 14:50 -04:00, Wojciech Gac wrote: > > W dniu poniedziałek, 1 lipca 2019 Mike > napisał(a): > > > BTW, I have a huge collection of grid usage in my repo: > > > https://bitbucket.org/mihailp/tankfeeder/src/default/ > > > > @Mike, > > > > Thanks for the link. I'll make sure to have a look. I find the grid > > approach appealing, especially after reading "Array Abstinence". > > For your convenience, here are the files in Mike's collection that > appear to use grid. > > 2048.l > 4clojure/hard.l > advent2015/code2015.l > advent2016/code2016.l > advent2017/code2017.l > advent2018/code2018.l > bfs.l > Burger/rosettacode.l > exercism-io/a-f.l > flood-day14.l > flood-fill.l > grid-crashme.l > grid-warmup.l > maze.l > Menshikov/2.l > Menshikov/3.l > rosetta/hidato.l > rosetta/numbrix.l > rosetta/snusp.l > rosetta/ulam.l > spiral.l > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe >
Re: Limitation of grid from @lib/simul.l
On Mon, 01 Jul 2019 14:50 -04:00, Wojciech Gac wrote: > W dniu poniedziałek, 1 lipca 2019 Mike napisał(a): > > BTW, I have a huge collection of grid usage in my repo: > > https://bitbucket.org/mihailp/tankfeeder/src/default/ > > @Mike, > > Thanks for the link. I'll make sure to have a look. I find the grid > approach appealing, especially after reading "Array Abstinence". For your convenience, here are the files in Mike's collection that appear to use grid. 2048.l 4clojure/hard.l advent2015/code2015.l advent2016/code2016.l advent2017/code2017.l advent2018/code2018.l bfs.l Burger/rosettacode.l exercism-io/a-f.l flood-day14.l flood-fill.l grid-crashme.l grid-warmup.l maze.l Menshikov/2.l Menshikov/3.l rosetta/hidato.l rosetta/numbrix.l rosetta/snusp.l rosetta/ulam.l spiral.l -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Limitation of grid from @lib/simul.l
@Mike, Thanks for the link. I'll make sure to have a look. I find the grid approach appealing, especially after reading "Array Abstinence". @Rick, Exactly! MS Excel was my original inspiration :P Cheers, Wojtek W dniu poniedziałek, 1 lipca 2019 Mike napisał(a): > July 1, 2019 5:50 PM, "Wojciech Gac" wrote: > >> I see. Thanks for clarifying and for the example. >> > > BTW, I have a huge collection of grid usage in my repo: > https://bitbucket.org/mihailp/tankfeeder/src/default/ > > (mike) > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe >
Re: Limitation of grid from @lib/simul.l
July 1, 2019 5:50 PM, "Wojciech Gac" wrote: > I see. Thanks for clarifying and for the example. > BTW, I have a huge collection of grid usage in my repo: https://bitbucket.org/mihailp/tankfeeder/src/default/ (mike) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Limitation of grid from @lib/simul.l
On Mon, 01 Jul 2019 10:49 -04:00, Wojciech Gac wrote: > ... we could have a naming scheme not limited by the 26 columns if > we used lexicographic strings (e.g. a b ... x y z aa ab ... etc). MS Excel! :D -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Limitation of grid from @lib/simul.l
I see. Thanks for clarifying and for the example.
Speaking of readability, we could have a naming scheme not limited by the
26 columns if we used lexicographic strings (e.g. a b ... x y z aa ab ..
etc). I've written a function generating relevant strings based on column
and row numbers. Feel free to incorporate it in the definition of 'grid':
(de num->alnum (Col Row)
(let N Nil
(until (=0 Col)
(push 'N (if (=0 (/ Col 27)) (% Col 27) (inc (% Col 27
(setq Col (/ Col 27)))
(pack (mapcar '((C) (char (+ 96 C))) N) Row)))
Cheers,
Wojtek
pon., 1 lip 2019 o 15:34 Alexander Burger napisał(a):
> Hi Wojtek,
>
> > True, I would lose that advantage, but I think the main advantage of the
> > grid approach are the local relationships between neighbors, not access
> by
> > name.
>
> Yes. But if I elaborate my proposal of separate namespaces, you could have
> both
> advantages:
>
>(load "@lib/simul.l")
>
># Global grid symbols, created in 'pico' namespace
>(off *Grid1 *Grid2 *Grid3)
>
># Create each grid in its own namespace
>(symbols 'pico~grid1 'pico)
>(setq *Grid1 (grid 8 8))
>
>(symbols 'pico~grid2 'pico)
>(setq *Grid2 (grid 8 8))
>
>(symbols 'pico~grid3 'pico)
>(setq *Grid3 (grid 8 8))
>
># Restore search-order
>(symbols '(pico))
>
> Then:
>
>: (symbols '(grid2 pico)
> (mapc println *Grid2) )
>(a1 a2 a3 a4 a5 a6 a7 a8)
>(b1 b2 b3 b4 b5 b6 b7 b8)
>(c1 c2 c3 c4 c5 c6 c7 c8)
>(d1 d2 d3 d4 d5 d6 d7 d8)
>(e1 e2 e3 e4 e5 e6 e7 e8)
>(f1 f2 f3 f4 f5 f6 f7 f8)
>(g1 g2 g3 g4 g5 g6 g7 g8)
>(h1 h2 h3 h4 h5 h6 h7 h8)
>-> ("h1" "h2" "h3" "h4" "h5" "h6" "h7" "h8")
>
> but
>
>: (symbols '(grid2 pico)
> (mapc println *Grid1) )
>("a1" "a2" "a3" "a4" "a5" "a6" "a7" "a8")
>("b1" "b2" "b3" "b4" "b5" "b6" "b7" "b8")
>("c1" "c2" "c3" "c4" "c5" "c6" "c7" "c8")
>("d1" "d2" "d3" "d4" "d5" "d6" "d7" "d8")
>("e1" "e2" "e3" "e4" "e5" "e6" "e7" "e8")
>("f1" "f2" "f3" "f4" "f5" "f6" "f7" "f8")
>("g1" "g2" "g3" "g4" "g5" "g6" "g7" "g8")
>("h1" "h2" "h3" "h4" "h5" "h6" "h7" "h8")
>-> ("h1" "h2" "h3" "h4" "h5" "h6" "h7" "h8")
>
> All these symbols are separated now, but still
> readable and printable by name if the correct
> namespace is selected.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Limitation of grid from @lib/simul.l
Hi Wojtek,
> True, I would lose that advantage, but I think the main advantage of the
> grid approach are the local relationships between neighbors, not access by
> name.
Yes. But if I elaborate my proposal of separate namespaces, you could have both
advantages:
(load "@lib/simul.l")
# Global grid symbols, created in 'pico' namespace
(off *Grid1 *Grid2 *Grid3)
# Create each grid in its own namespace
(symbols 'pico~grid1 'pico)
(setq *Grid1 (grid 8 8))
(symbols 'pico~grid2 'pico)
(setq *Grid2 (grid 8 8))
(symbols 'pico~grid3 'pico)
(setq *Grid3 (grid 8 8))
# Restore search-order
(symbols '(pico))
Then:
: (symbols '(grid2 pico)
(mapc println *Grid2) )
(a1 a2 a3 a4 a5 a6 a7 a8)
(b1 b2 b3 b4 b5 b6 b7 b8)
(c1 c2 c3 c4 c5 c6 c7 c8)
(d1 d2 d3 d4 d5 d6 d7 d8)
(e1 e2 e3 e4 e5 e6 e7 e8)
(f1 f2 f3 f4 f5 f6 f7 f8)
(g1 g2 g3 g4 g5 g6 g7 g8)
(h1 h2 h3 h4 h5 h6 h7 h8)
-> ("h1" "h2" "h3" "h4" "h5" "h6" "h7" "h8")
but
: (symbols '(grid2 pico)
(mapc println *Grid1) )
("a1" "a2" "a3" "a4" "a5" "a6" "a7" "a8")
("b1" "b2" "b3" "b4" "b5" "b6" "b7" "b8")
("c1" "c2" "c3" "c4" "c5" "c6" "c7" "c8")
("d1" "d2" "d3" "d4" "d5" "d6" "d7" "d8")
("e1" "e2" "e3" "e4" "e5" "e6" "e7" "e8")
("f1" "f2" "f3" "f4" "f5" "f6" "f7" "f8")
("g1" "g2" "g3" "g4" "g5" "g6" "g7" "g8")
("h1" "h2" "h3" "h4" "h5" "h6" "h7" "h8")
-> ("h1" "h2" "h3" "h4" "h5" "h6" "h7" "h8")
All these symbols are separated now, but still
readable and printable by name if the correct
namespace is selected.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Limitation of grid from @lib/simul.l
Hi Alex,
True, I would lose that advantage, but I think the main advantage of the
grid approach are the local relationships between neighbors, not access by
name.
Cheers,
Wojtek
pon., 1 lip 2019 o 14:42 Alexander Burger napisał(a):
> Hi Wojtek,
>
> > I've noticed a limitation if one were to use
> > multiple grids simultaneously.
> > ...
> > Since the fields in the grid contain symbols named along the pattern of a
> > chessboard that get interned when the grid is created,
>
> Correct. 'grid' is intended for stand-alone usage.
>
>
> > be shared between grids. One way to remove this limitation would be to
> use
> > 'box' for every cell, thus guaranteeing the symbols' uniqueness, but at
> the
> > price of having human-readable symbols like 'a1.
>
> In fact, this is the case if the grid is wider than 26 columns. Then all
> cells
> are created using 'box' (i.e. anonymous symbols).
>
>
> > Another thing that came to my mind when porting this approach to Common
> > Lisp would be to have something like 'box' but with a user-supplied
> prefix.
> > For instance, in Common Lisp there's the function 'gensym', which called
> > without parameters returns a fresh, unique symbol,
>
> In PicoLisp you can create such symbols using 'pack' (i.e. transient
> symbols):
>
: (mapcar
> '((N) (pack "prefix" N))
> (range 3 7) )
>-> ("prefix3" "prefix4" "prefix5" "prefix6" "prefix7")
>
> So you might well just remove the 'intern' in the 'grid' code. But then
> you lose
> the advantage of being able to access the cells by name in the REPL.
>
> Another possibility is to create the grids in separate namespaces and
> switch
> namespaces as needed.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Limitation of grid from @lib/simul.l
Hi Wojtek,
> I've noticed a limitation if one were to use
> multiple grids simultaneously.
> ...
> Since the fields in the grid contain symbols named along the pattern of a
> chessboard that get interned when the grid is created,
Correct. 'grid' is intended for stand-alone usage.
> be shared between grids. One way to remove this limitation would be to use
> 'box' for every cell, thus guaranteeing the symbols' uniqueness, but at the
> price of having human-readable symbols like 'a1.
In fact, this is the case if the grid is wider than 26 columns. Then all cells
are created using 'box' (i.e. anonymous symbols).
> Another thing that came to my mind when porting this approach to Common
> Lisp would be to have something like 'box' but with a user-supplied prefix.
> For instance, in Common Lisp there's the function 'gensym', which called
> without parameters returns a fresh, unique symbol,
In PicoLisp you can create such symbols using 'pack' (i.e. transient symbols):
: (mapcar
'((N) (pack "prefix" N))
(range 3 7) )
-> ("prefix3" "prefix4" "prefix5" "prefix6" "prefix7")
So you might well just remove the 'intern' in the 'grid' code. But then you lose
the advantage of being able to access the cells by name in the REPL.
Another possibility is to create the grids in separate namespaces and switch
namespaces as needed.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Casella email non monitorata Re: Limitation of grid from @lib/simul.l
Buongiorno, questa casella non è monitorata. Questo significa che qualunque messaggio inviato qui, ben difficilmente verrà letto. Per avere la mia email corretta, contattatemi attraverso altri canali (telefono, Telegram, Signal, etc). Grazie e una buona giornata P.M.
Limitation of grid from @lib/simul.l
Hi, I've recently used the 'grid' function from @lib/simul.l in some code and having studied its internals, I've noticed a limitation if one were to use multiple grids simultaneously. Since the fields in the grid contain symbols named along the pattern of a chessboard that get interned when the grid is created, if one then decides to create another grid, some of the symbols will surely overlap and hence be shared between grids. One way to remove this limitation would be to use 'box' for every cell, thus guaranteeing the symbols' uniqueness, but at the price of having human-readable symbols like 'a1. Another thing that came to my mind when porting this approach to Common Lisp would be to have something like 'box' but with a user-supplied prefix. For instance, in Common Lisp there's the function 'gensym', which called without parameters returns a fresh, unique symbol, while when called with a string argument, prepends that string to the symbol's name. Thus, we can have something like this (Common Lisp): > (gensym "a1-") >> #:|a1-780| Am I missing something, or is this a genuine problem with 'grid'? Cheers, Wojtek
