Pages

Tuesday, September 12, 2017

short post - pspg is ready for release

https://github.com/okbob/pspg. Please, test.

18 comments:

  1. Hi there, thanks for your efforts, I compiled commit 9226ea543d23 and can say it does work (I didn't look long for any new stuff though).

    I may have a biggy, though; I do a lot of Chinese database stuff and pspg is a godsend to me. However I realized that column alignments are regularly out of sync as soon as double-width characters are displayed. I'm not sure but wasn't it the case that they do align just fine, as they do in 'most' (but sadly not in 'less')?

    I've been working on so many things in the meantime so my memory could be wrong.

    I could supply some test data if you think you might work on that. Double-width characters do work in 'most', as I said, so that is proof it is in principle feasable.

    ReplyDelete
  2. I am using Czech chars in UTF8 encoding and there are not issues, please, recheck - ncursesw should be used if you are using wide chars.

    ReplyDelete
  3. I used

    gcc pager.c -o pager -L. -lncursesw

    to compile like I did before. Czech chars and everything outside of 7bit ASCII is one problem, but the other one is graphically wide characters.

    Some time ago I published https://github.com/loveencounterflow/to-width which uses a bunch of helpful Unicode-aware packages (sindresorhus/string-width and martinheidegger/wcstring which you find on npmjs.org and github) to achieve constant-width output in the presence of mixed narrow (single-cell) and wide (double-cell) codepoints.

    ReplyDelete
  4. I think the screenshot demonstrate quite nicely what I'm talking about. I could give you a bunch of *.sql files to feed into a test database if that is helpful (in case you want to take up the challenge at all).

    ReplyDelete
  5. please, send me a test case. Maybe the issue is on psql side, maybe in psps.

    ReplyDelete
  6. Here you go:

    https://github.com/loveencounterflow/fwtest

    Hope it helps,
    cheers

    ReplyDelete
  7. I started new issue - https://github.com/okbob/pspg/issues/19

    ReplyDelete
  8. Although there are still some artefacts for horizontal scrolling (maybe due wrong calculation display len) it is much better.

    ReplyDelete
  9. Very nice. Thanks!

    It seems that pspg currently does not handle window resizing.

    ReplyDelete
  10. @PL - It is working somewhere. Looks like not everywhere ncurses mechanism is working. When I call psql and pspg locally, then it is working. When I use ssh it doesn't work. It can be related to ncurses version too.

    ReplyDelete
  11. Pavel,
    Even when I run locally, it doesn't work for new query after resizing.

    ReplyDelete
  12. What ncurses version do you use? I have not a problem with ncurses 6 - ncurses-6.0-8.20170212.fc26.src.rpm

    ReplyDelete
  13. I use libncursesw5-dev on Ubuntu.

    ReplyDelete
  14. probably this is a reason. The resizing there doesn't work well when the application is nested. You can try direct call of pspg (without psql) by pspg -f somefile. Is resizing working there?

    ReplyDelete
  15. Hm, without psql it working.

    Here my actions:
    1. run select * from pg_class to start pspg
    2. Resize terminal window
    3. After resizing pspg still correctly working with this query!
    4. Stop pspg (by pressing q)
    5. Run another query and pspg stops working correctly
    6. When restarting psql, pspg works correctly again.

    ReplyDelete
  16. It is strange. Any new query means new instance of pspg. So when you stop pspg, then it is finished, and with new query, then it should to get fresh window size. So it looks like the core of the issue will be else where. What is psql version? Some older psql clients had a issue with resizing.

    ReplyDelete
  17. Yes, you are right!

    The issue on a psql 9.4
    With psql 9.6 worked fine.

    ReplyDelete
  18. I tested pspg on an up to date Debian 9 with Pg 9.6.
    I compiled it with just a simple make. It works as expected.
    I have found just a small typo: The error message for -s states that there are only 11 colour schemas while in the program there are 12.

    ReplyDelete