Right, thanks. This is a better definition:

octal_j_=: 3 : 0
t=. ,y
if. LF e. t do.
  t=. octal each <;._2 t,LF
  }: ; t ,each LF return.
end.
u=. isutf8 t
x=. a. i. t
m=. x < 32
if. u > 1 e. m do. t return. end.
m=. I. m +. u < x > 126
r=. t ,"0 1 [ 3 # EAV
s=. '\',.}.1 ": 8 (#.^:_1) 255,m{x
EAV -.~ , s m} r
)

   octal_j_ '時間',2 3 4 {a.
時間\002\003\004


On Sun, Feb 5, 2012 at 9:30 PM, bill lam <bbill....@gmail.com> wrote:

> Execuse me, all code points below 128 are valid utf8 because they are valid
> 7-bit ascii. For example,
>
>   isutf8 128{.a.
> 1
>   isutf8 129{.a.
> 0
>   isutf8 '時間', 2 3 4{a.
> 1
>
> ascii mixes well with control characters,
>
>    octal_j_ 'abc',2 3 4{a.
> abc\002\003\004
>
> It would be more usefuly if
>
>    octal_j_ '時間',2 3 4 {a.
> 時間\002\003\004
>
> I meant only octalize the range 0-31. Other characters will be taken care
> by
> choosing a suitable font.
>
> Вск, 05 Фев 2012, Chris Burke писал(а):
> > That is exactly the point  - if the argument is not valid utf8, it
> displays
> > it in octal. In your example, the 2 3 4 { a. ensure that it is not valid
> > utf8.
> >
> > However if the argument is utf8, it is returned unchanged, e.g.
> >
> >    octal_j_ '時間'
> > 時間
> >
> > The change I just suggested is that instead of checking the entire
> string,
> > check the string line by line.
> >
> > On Sun, Feb 5, 2012 at 2:59 PM, bill lam <bbill....@gmail.com> wrote:
> >
> > > This is a output using octal_j_
> > >
> > >   octal_j_ '時間',2 3 4 {a.
> > > \346\231\202\351\226\223\002\003\004
> > >
> > > For most chinese, display with octal_j_ is almost rubbish. I guess
> russian
> > > would also be similar.
> > >
> > > Вск, 05 Фев 2012, Chris Burke писал(а):
> > > > In J gtk, the session expects data in utf8 format. Obviously a. won't
> > > work,
> > > > but could be converted to utf8 for display.
> > > >
> > > > The utility that formats data for display is octal_j_. This does a
> simple
> > > > check on the argument string and either returns it unchanged, or
> formats
> > > to
> > > > octal. A simple improvement is to run the formatter on each line,
> rather
> > > > than the string as a whole, as below:
> > > >
> > > > octal_j_=: 3 : 0
> > > > t=. ,y
> > > > x=. a. i. t
> > > > n=. x e. 9 10 13
> > > > m=. n < 32 > x
> > > > if. (isutf8 t) > 1 e. m do. t return. end.
> > > > if. LF e. t do.
> > > >   t=. octal each <;._2 t,LF
> > > >   }: ; t ,each LF return.
> > > > end.
> > > > r=. t ,"0 1 [ 3 # EAV
> > > > if. #m=. I. m +. x>126 do.
> > > >   s=. '\',.}.1 ": 8 (#.^:_1) 255,m{x
> > > >   r=. s m} r
> > > > end.
> > > > EAV -.~ ,r
> > > > )
> > > >
> > > > For example, this works reasonably well with the new definition:
> > > >
> > > >    load 'unicode'
> > > >    toutf8 &> _16<\a.
> > > >
> > > > On my machine, the first two rows (first 32 chars) are still in
> octal,
> > > but
> > > > the rest get displayed using the proper characters (where available
> in
> > > the
> > > > font).
> > > >
> > > > I would appreciate suggestions for futher improvements to the octal
> > > utility.
> > > >
> > > >
> > > > On Sun, Feb 5, 2012 at 1:14 PM, bill lam <bbill....@gmail.com>
> wrote:
> > > >
> > > > > behaviour of < is different if the string is unicode.  u: is
> required
> > > in
> > > > > some places and it is not related to simplicity or complexity if
> you
> > > > > wants correct results.
> > > > >
> > > > > compare the outputs of _16{.a. with  u: _16{.a.
> > > > >
> > > > > the first contains illegal utf8 characters which can be checked by
> > > > > isutf8 _16{.a.
> > > > >
> > > > > What would you expect from gtkide to display those illegal
> characters?
> > > > >
> > > > > Вск, 05 Фев 2012, Fraser Jackson писал(а):
> > > > > > Why should I have to use u: to box elements of a.  ?  Seems an
> > > > > unnecessary
> > > > > > complication - and a bigger problem for beginners.
> > > > > >
> > > > > > In gtkide <"0 [2}. u: i. 16 16  still has all the problems.  That
> > > > > suggests
> > > > > > some problems are associated with the unicode treatment of
> control
> > > > > > characters.
> > > > > >
> > > > > > Even in Jconsole the first and second line are also
> irregular.When
> > > the
> > > > > > configure specifies a mono spaced font in gtkide we should surely
> > > expect
> > > > > > characters within the ascii set will be treated as atoms and
> > > assigned a
> > > > > > single space.
> > > > > >
> > > > > > I am really seeking that members of the alphabet  ( and hence any
> > > literal
> > > > > > nouns defined using that set ) have each member treated as an
> atom
> > > and
> > > > > that
> > > > > > that treatment is clearly separated from their role in
> controlling
> > > the
> > > > > > nature of the display.  That seems to have been achieved in J602.
> > > > > >
> > > > > > The treatment of type 131072 - unicode obviously involves a host
> of
> > > other
> > > > > > issues with respect to display and treatment of aoms.  However
> there
> > > are
> > > > > a
> > > > > > large number of problems within the narrower framework of atoms
> > > within
> > > > > a. or
> > > > > > represented by those characters. Precise, simple and consistent
> > > display
> > > > > of
> > > > > > those atoms is extremely valuable and important and has not yet
> been
> > > > > > achieved with the gtkide.
> > > > > >
> > > > > > Fraser
> > > > > > ----- Original Message -----
> > > > > > From: "bill lam" <bbill....@gmail.com>
> > > > > > To: <programming@jsoftware.com>
> > > > > > Sent: Sunday, February 05, 2012 3:04 PM
> > > > > > Subject: Re: [Jprogramming] Problems displaying the alphabet in
> > > J701gtk
> > > > > and
> > > > > > J701jhs
> > > > > >
> > > > > >
> > > > > > > It seemes that the characters in the first two rows caused the
> > > trouble,
> > > > > > > the following display ok in gtkide,
> > > > > > >
> > > > > > > <"0 [ u: 2}. i.16 16
> > > > > > >
> > > > > > > jconsole have no problem in displaying them.
> > > > > > >
> > > > > > >   <"0[u: i.16 16
> > > > > > >
> > > > > >
> > > > > >
> > > ----------------------------------------------------------------------
> > > > > > For information about J forums see
> > > http://www.jsoftware.com/forums.htm
> > > > >
> > > > > --
> > > > > regards,
> > > > > ====================================================
> > > > > GPG key 1024D/4434BAB3 2008-08-24
> > > > > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> > > > >
> ----------------------------------------------------------------------
> > > > > For information about J forums see
> http://www.jsoftware.com/forums.htm
> > > > >
> > > >
> ----------------------------------------------------------------------
> > > > For information about J forums see
> http://www.jsoftware.com/forums.htm
> > >
> > > --
> > > regards,
> > > ====================================================
> > > GPG key 1024D/4434BAB3 2008-08-24
> > > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > >
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to