Re: Do free Open Source Foundation's Software Stacks fall under US Export Law?
That's all folks. ;) On Wed, May 6, 2020 at 9:41 PM Alexander Burger wrote: > Hi Guido, > > On Wed, May 06, 2020 at 08:35:33PM +0200, Guido Stepken wrote: > > Perhaps you *all* learn, what a JIT compiler really is, in difference > > to a AOT Ahead of Time Compiler. > > > > https://en.wikipedia.org/wiki/Just-in-time_compilation > > > > Make ZEROpointZERO sense then to let Picolisp do, what Clang (the C to > > LLVM IR translator) does. > > > > If this is really the case, it promise, i say 'goodbye' from PicoLisp > > mailing list!!! I promise! > > > > Alex? > > Sorry, I'd love to, but I have no idea what you are talking about. PicoLisp > should not generate its code? > > — Alex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: PilCon 2020
Hi Guys, I agree with Christophe. It's best to organize a rehearsal way ahead of the actual event to give ourselves time to debug problems and investigate alternatives in case the proposed approach fails. And perhaps having pre-recorded presentations (if only as backups) would put us on the safe side. Regards, Wojtek On Tue, Apr 28, 2020 at 10:16 AM Alexander Shendi (Web.DE) < alexander.she...@web.de> wrote: > Hi Christophe, > > Thanks for responding. Packages has 71 and I do not have the resources to > compile 75 for myself. > > And what should I do in the (unlikely) case that I would want to ask a > question or even (The spectre of John McCarthy forbid) hold a presentation > myself? 😇 > > Am 28. April 2020 08:42:58 MESZ schrieb Jean-Christophe Helary < > jean.christophe.hel...@traduction-libre.org>: >> >> >> >> On Apr 28, 2020, at 15:20, Alexander Shendi (Web.DE) >> wrote: >>> >>> Dear List, >>> >>> My experience using Jitsi with Firefox wasn't good. I tried to attend an >>> online meeting with FF 71 and I managed to crash the server. Apparently >>> this is Firefox's fault though for not supporting all necessary features of >>> WebRTC. >>> >> >> Try 75. Maybe it is better. >> >> I'd like to use the Jitsi Android app, but I don't know how to use an USB >> headset with either my phone or a tablet. Maybe an analog headphone and the >> device's microphone is the way to go. >>> >> >> An analog headphone should be sufficient. But if you mute your mike during >> the presentations, there is no real need for a headphone. >> >> >> Jean-Christophe Helary >> -- >> http://mac4translators.blogspot.com @brandelune >> >> >> >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> >> > -- > You have zero privacy anyway. Get over it. > > Scott McNealy 1999 >
Re: EU Lisp online now
Yes, It started yesterday. The approach to streaming and scaling is based on pre-recorded talks by the speakers. Initially there was talk about making it fully interactive and live, but the organizers decided we don't really have the infrastructure to support that many people simultaneously. The first day of ELS (Monday) proved that, while there's nothing like meeting face-to-face, being able to meet *at all* is still cool and worthwhile. Regards, Wojtek On Tue, Apr 28, 2020 at 10:20 AM cilz wrote: > Hi guys, > > FYI EU Lisp 2020 is online now here: https://www.twitch.tv/elsconf > > This could gives us some ideas for our own PiLCon 2020. > > Best, > > Eric > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: PilCon 2020
Having started my adventure with Lisp conferences in 2018 (ELS 2018 in Marbella, Spain) I got completely hooked up on the idea of meeting super-interesting people and listening about stuff they're working on. I'd be excited to join you guys. Of course, being able to meet in person beats anything, but given the circumstances, an online conference is the next best thing, I guess. Cheers, Wojtek On Wed, Apr 22, 2020 at 8:43 AM Wilhelm Fitzpatrick wrote: > I'll add my voice as being another who would be interested in an online > convention. > > -Wilhelm > > On 4/21/20 11:13 PM, George-Phillip Orais wrote: > > Same here, as lurker and amateur PicoLisper, I love to join and the > > attend this online PilCon 2020, thank you Alex! > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Vip screen resize
Hi Mansur, Could be done, but since the function is meant to be run by manual invocation *and* after an infrequent operation (Tmux window resize), I'm not sure it matters that much. Assuming, that is, that (eqwin) is cheap to run. Wojtek On Thu, Apr 9, 2020 at 1:21 PM Мансур Мамкин wrote: > Hi all, > what about also comparing new values with current values, and do something > only when anything has changed. > > Best regards, > Mansur Mamkin > > On Wed, Apr 8, 2020 at 10:08 PM Wojciech Gac > wrote: > >> Hi, >> >> I typically use my Vip/Picolisp setup inside Tmux. I've noticed that when >> I resize the window occupied by Vip, it does not automatically adapt to the >> new dimensions, nor could I find a quick way to do it manually. So I took a >> look at the source code and decided to write some helper functions. The >> function GetScreenSize uses "stty size" (to avoid relying on Ncurses). The >> function UpdateScreenSize sets the environment variables LINES and COLUMNS, >> as well as the Vip variables *Lines and *Columns to the appropriate values. >> The problem is I don't really know how to force Vip to redraw its windows. >> I've tried "repaint" cause it looked like it should do the trick, but it >> did not. Am I missing something? >> >> Wojtek >> >> # Return a list of screen dimensions in the form (Lines Columns) >> (de GetScreenSize () >>(mapcar format >> (mapcar pack >> (split >> (chop (in '(stty size) (line T))) >> " " >> >> # Update environment variables and internal variables holding the screen >> size >> (de UpdateScreenSize (Lines Columns) >>(sys "LINES" Lines) >>(sys "COLUMNS" Columns) >>(setq vip~*Lines Lines >> vip~*Columns Columns)) >> >
Re: Vip screen resize
Thanks Alex! This is very elegant and concise. And it works. One other problem I noticed with my Vip (this is under Termux) is that for some reason it won't allow me to exit insert mode. It worked fine yesterday and I have no idea what changed. Initially I thought it might be some escaping issue, i.e. Esc/C-[ being interpreted as some other symbol, but it works fine for Vim (both Esc and C-[). What I'm getting now is that pressing Esc results in an open bracket being inserted into the buffer. No way to return to command mode. When I fresh instance of Vip, I can enter commands normally. But the first switch to insert mode breaks things. I was worried that perhaps messed something up in the "vip.l" file I had open on the side, but have since replaced its contents with the upstream version and even reinstalled Picolisp and the issue persists. On Thu, Apr 9, 2020 at 7:37 AM Alexander Burger wrote: > Hi Wojtek, > > > I typically use my Vip/Picolisp setup inside Tmux. I've noticed that > when I > > Me too. I never have any shell session running without Tmux, neither > locally nor > remote. > > > > resize the window occupied by Vip, it does not automatically adapt to the > > new dimensions, nor could I find a quick way to do it manually. So I > took a > > Yeah, this is a known issue. > > Originally, when Vip was written to use Ncurses, it was notified when the > terminal changed in 'getch': > >(de getch () > (loop > (curses "wget_wch" NIL (: ptr) '(*Chr (4 . I))) > (NIL (= 410 *Chr) # KEY_RESIZE > (setq *Chr (unless (= 27 *Chr) (char *Chr))) ) > (setq > *Lines (car (struct "LINES" '(I))) > *Columns (car (struct "COLS" '(I))) ) > (eqwin) ) ) > > Whenever Vip received a SIGWINCH signal, the above 'setq' was triggered. > > Now, as Vip does not use Ncurses any longer, the above does not work. The > PicoLisp core does not handle SIGWINCH. > > I avoid this situation by either not changing the terminal, or by simply > restarting Vip ;) > > > > look at the source code and decided to write some helper functions. The > > function GetScreenSize uses "stty size" (to avoid relying on Ncurses). > The > > function UpdateScreenSize sets the environment variables LINES and > COLUMNS, > > as well as the Vip variables *Lines and *Columns to the appropriate > values. > > Good. > > > The problem is I don't really know how to force Vip to redraw its > windows. > > I've tried "repaint" cause it looked like it should do the trick, but it > > did not. Am I missing something? > > 'repaint' might be the right place, but it is called very often. Not sure > if it > slows everything down too much. Also, I would recommend 'eqwin' as in the > example above, to re-calculate the window sizes. > > > I would recommend to install it into a function key handler. It just needs > in > ~/.pil/viprc > >(de *F12 > (in '(stty size) > (setq *Lines (read) *Columns (read)) ) > (eqwin) ) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Vip screen resize
Hi, I typically use my Vip/Picolisp setup inside Tmux. I've noticed that when I resize the window occupied by Vip, it does not automatically adapt to the new dimensions, nor could I find a quick way to do it manually. So I took a look at the source code and decided to write some helper functions. The function GetScreenSize uses "stty size" (to avoid relying on Ncurses). The function UpdateScreenSize sets the environment variables LINES and COLUMNS, as well as the Vip variables *Lines and *Columns to the appropriate values. The problem is I don't really know how to force Vip to redraw its windows. I've tried "repaint" cause it looked like it should do the trick, but it did not. Am I missing something? Wojtek # Return a list of screen dimensions in the form (Lines Columns) (de GetScreenSize () (mapcar format (mapcar pack (split (chop (in '(stty size) (line T))) " " # Update environment variables and internal variables holding the screen size (de UpdateScreenSize (Lines Columns) (sys "LINES" Lines) (sys "COLUMNS" Columns) (setq vip~*Lines Lines vip~*Columns Columns))
Re: View kanji stroke order from within Vip
Thanks for pointing this out. Cheers, Wojtek sob., 3 sie 2019 o 11:26 Alexander Burger napisał(a): > On Fri, Aug 02, 2019 at 06:18:57PM +0200, Wojciech Gac wrote: > > I've cooked up a tiny code snippet which, together with SVG images from > the > > BTW, > >(de *F8 () > (let ... > > is not really correct. > > The *Fn key definitions expect a 'prg' body, not a 'fun' function. So the > () is > NIL as the first expression in the body, and has no effect. > > Better would be > >(de *F8 > (let ... > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: View kanji stroke order from within Vip
OK, what I thought would be the most difficult part, namely stroke numbering, turns out to actually be pretty easy. Turns out, the original SVGs have a "StrokeNumbers" section, in which the numbers are listed as items of the form: 1 The two numbers at the end are just X and Y coordinates, so this could be used to "postprocess" the image section of the XPM, placing the numbers by hand (i.e. by code) in appropriate locations. An example result would be something like this: "", "", "", "", "", "", "", "", "", "", "", " 1 . .. ", ".. .. ", " .. .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .... ", "2 .. ", " .. .. ", " .. ", " .. ", " .. ", " .. ", " .. ", " .", " .", " .", " .", " .", " .", " .", " .", " .", " .", " .", " 3 ... .", ". .", " .", "", "", " ", "", "", "", "", "", "", "" Cheers, Wojtek sob., 3 sie 2019 o 10:49 Wojciech Gac
Re: View kanji stroke order from within Vip
Using ImageMagick, it's easy to convert SVG to XPM. The example invocation would be: convert -monochrome -size 128x128 .svg .xpm It's very fast, so it could be done in a JIT fashion, perhaps caching the output images in some other directory to avoid redundant work. I'm experimenting with making the image part of an XPM readable enough to be useful. Cheers, Wojtek sob., 3 sie 2019 o 07:49 Alexander Burger napisał(a): > Hi Wojtek, > > > I've cooked up a tiny code snippet which, together with SVG images from > the > > KanjiVG project, allows the user to view the stroke order of a kanji > > character at cursor. > > Nice! > > I have not tried, but why did you write 'decimalToBase'? FYI, if it is > just to > get hexadecimal strings, you could use the 'hex' function in PicoLisp. > > > > It would be cool to be able to automatically > > convert the SVGs to ASCII art and perhaps display them natively within > Vip. > > Indeed. One way would be to render the SVGs to some pixmap image, and > convert > the resulting bytes into a Vip buffer. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
View kanji stroke order from within Vip
Hi, I've cooked up a tiny code snippet which, together with SVG images from the KanjiVG project, allows the user to view the stroke order of a kanji character at cursor. This is supposed to help Japanese learners learn how to write various kanji. Currently it's just a hack, depending on an external viewer, i.e. Firefox. It would be cool to be able to automatically convert the SVGs to ASCII art and perhaps display them natively within Vip. The code is available in a Github Gist: https://gist.github.com/wsgac/67d88273d4bb43aeac19c4c5f820c542 Cheers, Wojtek
Re: Vip without [N]curses
Thanks Alex! This is exactly what I was missing :).
Cheers,
Wojtek
W dniu środa, 31 lipca 2019 Alexander Burger
napisał(a):
> Hi Wojtek,
>
>> By the way, I wanted to clear a misunderstanding I seem to be having,
>> regarding code evaluation in Vip. The wiki article says, that if I move
to
>> the command buffer and enter a Picolisp expression on a line of its own,
>> then I can execute it by pressing Enter.
>
> Oh, sorry! The article is outdated in this regard.
>
> The Vip REPL now no longer behaves this way (triggering evaluation with an
> opening parenthesis). Instead, it needs ": " (a colon and a space).
>
> Practically, you get the colon by pressing ':' (as in Vim) or . At
this
> point you can enter commands like "e" (edit), "w" (write) and so on (see
the
> full list in the 'command' function in the 'case C' body. BUT if you press
> a(nother) space here, the rest of the line will be evaluated.
>
> This is easier than it sounds ;)
>
> Try this: Hit '-' a few times to get a bigger command window. Then hit
space,
> space,(+ 3 4 and . The command window shows
>
>: (+ 3 4)
>-> 7
>
> The focus is back to the current edit window.
>
> Or, you move to the command window permanently with "qj" or "^wj", and
edit
> expressions manually. You can (re)evaluate any line there by pressing
on
> it.
>
>
>> While I'm on the topic, is there a way to evaluate arbitrary Picolisp
code
>> from *any* Vip buffer, i.e. sending region to the Picolisp REPL?
>
> Not a region (in the sense of as part of a file), but you can evaluate
('load')
> the whole file by pressing F7.
>
> Or you copy some lines to the command window ('y' and 'p' commands) and
evaluate
> them there.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
Re: Vip without [N]curses
By the way, I wanted to clear a misunderstanding I seem to be having, regarding code evaluation in Vip. The wiki article says, that if I move to the command buffer and enter a Picolisp expression on a line of its own, then I can execute it by pressing Enter. So what I did was, I entered the following command: (out "/tmp/vip-test" (prinl "test")) And pressed Enter with the cursor on that expression. Based on the article, I would expect the code to be run and the /tmp/vip-test file to appear, but it didn't. Am I missing something? While I'm on the topic, is there a way to evaluate arbitrary Picolisp code from *any* Vip buffer, i.e. sending region to the Picolisp REPL? Cheers, Wojtek śr., 31 lip 2019 o 11:56 Alexander Burger napisał(a): > On Tue, Jul 30, 2019 at 10:41:40AM +0200, Alexander Burger wrote: > > I tested on Termux, Tmux, XTerm and Linux Console. If anybody is > interested, it > > is in the rolling picoLisp.tgz release :) > > Released an updated version now (19 7 31). > > Fixed some bugs - not directly related to the changes from curses to escape > sequences, but to the different screen updates and the ^Z (SIGTSTP and > SIGCONT) > handling. > > Just in case anybody actually uses it. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Vip without [N]curses
Ok, that did the trick. Turns out the variables were set, but not exported. Thanks, Wojtek wt., 30 lip 2019 o 13:26 Alexander Burger napisał(a): > On Tue, Jul 30, 2019 at 01:07:43PM +0200, Wojciech Gac wrote: > > Right. So my Bash has the two variables set and exported, but they do not > > propagate over to Picolisp, i.e. when I evaluate (sys "LINES"), i get > NIL. > > Any way to force pil to grab those variables? > > I have in my ~/.bashrc > >export COLUMNS LINES > > and get > >$ ./pil + >: (sys "COLUMNS") >-> "48" >: (sys "LINES") >-> "48" > > Is it different in your case? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Vip without [N]curses
Right. So my Bash has the two variables set and exported, but they do not propagate over to Picolisp, i.e. when I evaluate (sys "LINES"), i get NIL. Any way to force pil to grab those variables? Cheers, Wojtek wt., 30 lip 2019 o 12:57 Alexander Burger napisał(a): > On Tue, Jul 30, 2019 at 12:33:15PM +0200, Wojciech Gac wrote: > > I know, but the invocation I mentioned worked for me before. The > invocation > > from your email doesn't work either. Same error as before. > > I see from > > > > > [/usr/local/bin/vip:6] !? (need X (chop (next)) " ") > > that it happens in 'align'. The only place where @lib/vip.l calls 'align' > is in > 'status' (that's why you get the inverse video): > >(need (- *Columns (length A) (length Z)) " ") > > > So it looks like *Columns is not set. > > Vip fetches it with > >(setq > *Columns (format (sys "COLUMNS")) > *Lines (format (sys "LINES")) ) > > I think in your environment these variables are not set or not exported. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Vip without [N]curses
I know, but the invocation I mentioned worked for me before. The invocation from your email doesn't work either. Same error as before. Cheers, Wojtek wt., 30 lip 2019 o 12:13 Alexander Burger napisał(a): > Hi Wojtek, > > > Hmm... When running Vip (both with and without "+"), I get a reversed > video > > Picolisp prompt. When I exit with a (bye), I get the following error > > message: > > > > [/usr/local/bin/vip:6] !? (need X (chop (next)) " ") > > NIL -- Small number expected > > The invocation did not change. > > You can either call it from the REPL > >$ ./pil lib/vip.l + >: (vi "file") >... >: (vi 'car) > > Or make a startup script. I have in my path > a bin/vi > >#!/data/data/com.termux/files/home/pico/bin/picolisp > /data/data/com.termux/files/home/pico/lib.l ># 04oct17abu > >(load "@bin/vip") > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Vip without [N]curses
Hmm... When running Vip (both with and without "+"), I get a reversed video Picolisp prompt. When I exit with a (bye), I get the following error message: [/usr/local/bin/vip:6] !? (need X (chop (next)) " ") NIL -- Small number expected Cheers, Wojtek wt., 30 lip 2019 o 11:10 Wojciech Gac napisał(a): > Great news! > > I also found it increasingly annoying, even on the user side, that on > various systems getting Vip to run correctly was not always easy. Giving it > a try right now. > > Cheers, > Wojtek > > wt., 30 lip 2019 o 10:48 Alexander Burger > napisał(a): > >> Hi all, >> >> more and more I got frustrated with all the quirks of Ncurses (as >> discussed here >> and in IRC), so I decided to abandon them, and implement Vip directly >> with ANSI >> escape sequences (VT-100). >> >> To my surprise this turned out quite easy, and the result is both smaller >> and >> simpler! >> >> I tested on Termux, Tmux, XTerm and Linux Console. If anybody is >> interested, it >> is in the rolling picoLisp.tgz release :) >> >> ☺/ A!ex >> >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> >
Re: Vip without [N]curses
Great news! I also found it increasingly annoying, even on the user side, that on various systems getting Vip to run correctly was not always easy. Giving it a try right now. Cheers, Wojtek wt., 30 lip 2019 o 10:48 Alexander Burger napisał(a): > Hi all, > > more and more I got frustrated with all the quirks of Ncurses (as > discussed here > and in IRC), so I decided to abandon them, and implement Vip directly with > ANSI > escape sequences (VT-100). > > To my surprise this turned out quite easy, and the result is both smaller > and > simpler! > > I tested on Termux, Tmux, XTerm and Linux Console. If anybody is > interested, it > is in the rolling picoLisp.tgz release :) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Limitation of grid from @lib/simul.l
Sure. I haven't considered these implications when I came up with the function :). Cheers, Wojtek wt., 23 lip 2019 o 11:52 Alexander Burger napisał(a): > On Thu, Jul 04, 2019 at 02:48:42PM +0200, Alexander Burger wrote: > > Hi Wojtek, Mike, > > > > On Thu, Jul 04, 2019 at 09:53:10AM +, Mike wrote: > > > +1 > > > ok > > > > Great! So I went ahead and released it. > > Sorry!! Looks like this was not a good idea ;) > > Besides the fact that the creation of such large amounts of internal > symbols > significantly increases memory and time requirements (if the grid is > large), it > is too easy to cause conflicts with existing symbols. > > For example, in tests Mike made, we found out that it eventually uses > 'if2' as a > grid node. However, 'if2' is a built-in function. > > In a similar way, the chances are high that many other symbols will clash > too, > (unless namespaces are used, also discussed in this thread). > > So please excuse that I'll revert @lib/simul.l ... > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: VIP Auto-Load and ASCII Diagrams
Great news. Congrats! W dniu piątek, 5 lipca 2019 Alexander Burger napisał(a): > Hi all, > > now I found it (with help from Mike)! > > It was a stupid bug in 'super', which was there all the time, but for some > reason never showed up. > > I made a new release. > > > BTW, a note for invoking Vip: As long as the current version is not in the > global release, the best way is > >$ ./pil @lib/vip.l + >: (vi "file") > > because bin/vip has a gloral path in its hash-bang. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Limitation of grid from @lib/simul.l
Thanks! czw., 4 lip 2019 o 14:56 Alexander Burger napisał(a): > Hi Wojtek, Mike, > > On Thu, Jul 04, 2019 at 09:53:10AM +, Mike wrote: > > +1 > > ok > > Great! So I went ahead and released it. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: VIP Auto-Load and ASCII Diagrams
'v' also drew a box in my case. czw., 4 lip 2019 o 14:08 Mike napisał(a): > > # VIP @lib/vip/draw.l > > (box 3 4 10 15) > > > > then open it with 'vip' and press "v" to view the drawing, I suspect it > crashes > > too. Is that the case? > > > > No, It draw a box > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe >
Re: VIP Auto-Load and ASCII Diagrams
Yes, it crashes either way. :w with other files works fine. czw., 4 lip 2019 o 13:04 Alexander Burger napisał(a): > On Thu, Jul 04, 2019 at 12:06:02PM +0200, Wojciech Gac wrote: > > Provided you have Vip in your path, just run it, open a new file, input > the > > line: > > > > # VIP @lib/vip/draw.l > > > > and try saving via :w > > Does it also crash also if the file is initially not empty? E.g. if it has > ># VIP @lib/vip/draw.l >(box 3 4 10 15) > > before you do :w ? > > > Also, does Vip work when editing a plain file? > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: VIP Auto-Load and ASCII Diagrams
Provided you have Vip in your path, just run it, open a new file, input the line: # VIP @lib/vip/draw.l and try saving via :w czw., 4 lip 2019 o 12:03 Mike napisał(a): > I've never used vip before and dont understand what steps I should do to > crash > > > > > > > July 4, 2019 12:51 PM, "Alexander Burger" wrote: > > > On Tue, Jul 02, 2019 at 06:58:21PM +0900, Alexander Burger wrote: > > > >> On Tue, Jul 02, 2019 at 11:28:19AM +0200, Wojciech Gac wrote: > >> Weird... I've updated my PicoLisp and when I try to save a file with the > >> following line: > >> > >> # VIP @lib/vip/draw.l > >> > >> Vip dies and I get a segmentation fault. > >> > >> Strange! Can you try to strace or something? > > > > Does anybody else can reproduce this crash? > > > > ☺/ A!ex > > > > -- > > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe >
Re: VIP Auto-Load and ASCII Diagrams
Attaching my strace output. wt., 2 lip 2019 o 12:04 Alexander Burger napisał(a): > On Tue, Jul 02, 2019 at 11:28:19AM +0200, Wojciech Gac wrote: > > Weird... I've updated my PicoLisp and when I try to save a file with the > > following line: > > > > # VIP @lib/vip/draw.l > > > > Vip dies and I get a segmentation fault. > > Strange! Can you try to strace or something? > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > draw-test-strace.out Description: Binary data
Re: VIP Auto-Load and ASCII Diagrams
Weird... I've updated my PicoLisp and when I try to save a file with the following line: # VIP @lib/vip/draw.l Vip dies and I get a segmentation fault. wt., 2 lip 2019 o 10:06 Wojciech Gac napisał(a): > This is very cool! One step further along the way to a self-sufficient > development environment :). > > wt., 2 lip 2019 o 09:12 napisał(a): > >> Am 2019-07-02 04:26, schrieb Alexander Burger: >> > 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. >> >> Very nice! >> Thank you Alex for creating and sharing this :-) >> >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> >
Re: VIP Auto-Load and ASCII Diagrams
This is very cool! One step further along the way to a self-sufficient development environment :). wt., 2 lip 2019 o 09:12 napisał(a): > Am 2019-07-02 04:26, schrieb Alexander Burger: > > 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. > > Very nice! > Thank you Alex for creating and sharing this :-) > > -- > 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
@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
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 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
>
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
Re: Certain file contents break the :r function in Vip
Thanks a lot for the explanation guys. Cheers, Wojtek śr., 26 cze 2019 o 02:14 Alexander Burger napisał(a): > Hi Wojtek, > > > I'm wondering then... what if someone wanted to use PicoLisp to emit > > characters somewhere (say, to a listening process) and the case required > > one to send a null byte. Does this limitation extend to all attempts at > > representing the null byte or only in the file context? > > As Andreas explained, you can use (wr 0) to output a null bybe. > > In addition, to do arbitrary manipulations on I/O, you can use pipes. For > example, to read text in non-UTF8 format: > >(in (list "/usr/bin/iconv" "-f" "ISO-8859-15" "-t" "UTF-8" File) > ... ) > > and to write something: > >(out (list "/usr/bin/iconv" "-o" File "-f" "UTF-8" "-t" "CP1252") > ) > > So there is no reason to bother PicoLisp itself with the mess of existing > character sets and file formats. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Certain file contents break the :r function in Vip
Hi Alex, I see. Thanks for the response. I'm wondering then... what if someone wanted to use PicoLisp to emit characters somewhere (say, to a listening process) and the case required one to send a null byte. Does this limitation extend to all attempts at representing the null byte or only in the file context? Cheers, Wojtek wt., 25 cze 2019 o 13:54 Alexander Burger napisał(a): > Hi Wojtek, > > > I've noticed this when messing around with my .emacs file. When you have > a > > file with a null character somewhere within a double-quoted string > > (e.g. "\0") and you try to insert it into the current buffer with :r, > then > > it breaks Vip > > Right, this is a limitation of Vip (and PicoLisp in general): It can > handle only > files with non-null characters in UTF-8 encoding. > > Characters in PicoLisp are symbols, and a null-byte works as a name > terminator > (similar to C), so symbols cannot have names with null-bytes. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Certain file contents break the :r function in Vip
Hi everyone! I've noticed this when messing around with my .emacs file. When you have a file with a null character somewhere within a double-quoted string (e.g. "\0") and you try to insert it into the current buffer with :r, then it breaks Vip with the following message: !? (set C T) NIL -- Protected symbol ? Any ideas or comments? Cheers, Wojtek
