Tuesday, September 12, 2017

short post - pspg is ready for release

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

19 Comments:

At September 12, 2017 at 6:21 AM , Blogger John Frazer said...

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.

 
At September 12, 2017 at 9:10 AM , Blogger Pavel Stěhule said...

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.

 
At September 12, 2017 at 9:30 AM , Blogger John Frazer said...

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.

 
At September 12, 2017 at 9:33 AM , Blogger John Frazer said...

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).

 
At September 12, 2017 at 9:43 AM , Blogger Pavel Stěhule said...

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

 
At September 12, 2017 at 1:35 PM , Blogger John Frazer said...

Here you go:

https://github.com/loveencounterflow/fwtest

Hope it helps,
cheers

 
At September 13, 2017 at 2:13 AM , Blogger Pavel Stěhule said...

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

 
At September 13, 2017 at 5:08 AM , Blogger Pavel Stěhule said...

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

 
At September 14, 2017 at 6:45 AM , Blogger PL said...

Very nice. Thanks!

It seems that pspg currently does not handle window resizing.

 
At September 14, 2017 at 7:00 AM , Blogger Pavel Stěhule said...

@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.

 
At September 14, 2017 at 7:26 AM , Blogger PL said...

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

 
At September 14, 2017 at 7:37 AM , Blogger Pavel Stěhule said...

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

 
At September 14, 2017 at 7:44 AM , Blogger PL said...

I use libncursesw5-dev on Ubuntu.

 
At September 14, 2017 at 8:00 AM , Blogger Pavel Stěhule said...

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?

 
At September 14, 2017 at 8:16 AM , Blogger PL said...

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.

 
At September 14, 2017 at 8:21 AM , Blogger Pavel Stěhule said...

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.

 
At September 14, 2017 at 8:27 AM , Blogger PL said...

Yes, you are right!

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

 
At September 14, 2017 at 8:30 AM , Blogger Pavel Stěhule said...

:)

 
At September 15, 2017 at 10:28 AM , Anonymous Wolfgang said...

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.

 

Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home