[line elided for control chars: possibly a scala signature]

On Thu, Jan 5, 2012 at 2:07 PM, Robert Voyer <robert.voyer@gmail.com> wrote:

I'm getting this odd message in the Scala REPL:

[line elided for control chars: possibly a scala signature]

Can someone tell me what this is all about?

It means it didn't print a line because it's full of control characters and they have an unfortunate tendency to wreak havoc on one's terminal settings.  The leading perpetrator of this is the annotation-stored scala signature, as you can see with :javap on any scala class.
scala> :javap -v scala.PredefCompiled from "Predef.scala"public final class scala.Predef extends java.lang.Object...const #7d7d7d = Asciz Lscala/reflect/ScalaSignature;; const #7e7e7e = Asciz bytes;const #808080 = Asciz [line elided for control chars: possibly a scala signature] const #828282 = Asciz RuntimeVisibleAnnotations;const #848484 = Asciz InnerClasses;

On Fri, Jan 6, 2012 at 01:01, Paul Phillips wrote:
>
> On Thu, Jan 5, 2012 at 2:07 PM, Robert Voyer wrote:
>>
>> I'm getting this odd message in the Scala REPL:
>>
>> [line elided for control chars: possibly a scala signature]
>>
>> Can someone tell me what this is all about?
>
>
> It means it didn't print a line because it's full of control characters and
> they have an unfortunate tendency to wreak havoc on one's terminal settings.
>  The leading perpetrator of this is the annotation-stored scala signature,
> as you can see with :javap on any scala class.
>
> scala> :javap -v scala.Predef
> Compiled from "Predef.scala"
> public final class scala.Predef extends java.lang.Object
> ...
> const #7d7d7d = Asciz Lscala/reflect/ScalaSignature;;
> const #7e7e7e = Asciz bytes;
> const #808080 = Asciz [line elided for control chars: possibly a scala
> signature]
> const #828282 = Asciz RuntimeVisibleAnnotations;
> const #848484 = Asciz InnerClasses;

I wish I had got more support on asking for BASE95 instead of what we got...

I'm not sure the 25% space penalty for Base85 (I assume you mean 85 using the standard 5:4 encoding, not 95--the latter is too much of a pain to pack bytes into) is worth it given that e.g. we're already struggling to make Scala work with Dalvik.

  --Rex

On Fri, Jan 6, 2012 at 7:30 AM, Daniel Sobral <dcsobral@gmail.com> wrote:

On Fri, Jan 6, 2012 at 01:01, Paul Phillips <paulp@improving.org> wrote:
>
> On Thu, Jan 5, 2012 at 2:07 PM, Robert Voyer <robert.voyer@gmail.com> wrote:
>>
>> I'm getting this odd message in the Scala REPL:
>>
>> [line elided for control chars: possibly a scala signature]
>>
>> Can someone tell me what this is all about?
>
>
> It means it didn't print a line because it's full of control characters and
> they have an unfortunate tendency to wreak havoc on one's terminal settings.
>  The leading perpetrator of this is the annotation-stored scala signature,
> as you can see with :javap on any scala class.
>
> scala> :javap -v scala.Predef
> Compiled from "Predef.scala"
> public final class scala.Predef extends java.lang.Object
> ...
> const #7d7d7d = Asciz Lscala/reflect/ScalaSignature;;
> const #7e7e7e = Asciz bytes;
> const #808080 = Asciz [line elided for control chars: possibly a scala
> signature]
> const #828282 = Asciz RuntimeVisibleAnnotations;
> const #848484 = Asciz InnerClasses;

I wish I had got more support on asking for BASE95 instead of what we got...


--
Daniel C. Sobral

I travel to the future all the time.

On Fri, Jan 6, 2012 at 4:30 AM, Daniel Sobral
wrote:
> BASE95

It's always fun to look back:

http://comments.gmane.org/gmane.comp.lang.scala.internals/3133

I also enjoy how the individual messages are clearly marked with the
time of day, but the year is considered an extraneous detail. "Come
on, we're telling you what time it is, you want the year ALSO? You
readers of archived messages are never satisfied!"

Rex wrote:
> I'm not sure the 25% space penalty for Base85 (I assume you mean
> 85 using the standard 5:4 encoding, not 95--the latter is too much
> of a pain to pack bytes into)

Who cares if it's a pain, do you expect to write the encoder/decoder
repeatedly? If you mean it's inefficient, that's an argument, but
"it's a pain" is not an argument against something which could be
written in less than a day and used millions of times.

On Fri, Jan 6, 2012 at 12:56, Paul Phillips wrote:
> On Fri, Jan 6, 2012 at 4:30 AM, Daniel Sobral
> wrote:
>> BASE95
>
> It's always fun to look back:
>
>  http://comments.gmane.org/gmane.comp.lang.scala.internals/3133
>
> I also enjoy how the individual messages are clearly marked with the
> time of day, but the year is considered an extraneous detail. "Come
> on, we're telling you what time it is, you want the year ALSO? You
> readers of archived messages are never satisfied!"

Yeah, there was rather more support for a printable encoding than I
recalled. I see it was someone else bringing up BASE95 too.

On Fri, Jan 6, 2012 at 9:56 AM, Paul Phillips <paulp@improving.org> wrote:

Rex wrote:
> I'm not sure the 25% space penalty for Base85 (I assume you mean
> 85 using the standard 5:4 encoding, not 95--the latter is too much
> of a pain to pack bytes into)

Who cares if it's a pain, do you expect to write the encoder/decoder
repeatedly? If you mean it's inefficient, that's an argument, but
"it's a pain" is not an argument against something which could be
written in less than a day and used millions of times.

I meant that it was a computational pain, not a coding pain, but that's because I was envisioning using 11-digit numbers to encode 9 bytes (the smallest single-chunk solution on byte boundaries), and that can't be conveniently computed with Longs, and thus is computationally expensive.

But now that I look at it in more detail, if you're willing to do both chunking and bit-shifting, you can use nine 9-digit numbers to encode 59 bits each (59 bytes in 72 characters), which does fit into Long.  Thus it computationally would only be approximately as expensive as Base85 (though more expensive than Base64 by far, due to the modulus arithmetic), but the code would be considerably more complex for only a 2.4% improvement over Base85.  This also leaves you without a good terminator character outside of control characters, but I guess you can use tab or some other printable control character as your terminator if you want to do things that way.  (Or you could encode your zeros as 256s to distinguish them from "no data"--this will still barely fit.  Or you could prepend the length of the byte stream.)

For that miniscule improvement, I think you'd be better off applying the simplest level of Huffman coding or somesuch.  Or just leaving it the way it is.

  --Rex

On Fri, Jan 6, 2012 at 1:16 PM, Rex Kerr <ichoran@gmail.com> wrote:

But now that I look at it in more detail, if you're willing to do both chunking and bit-shifting, you can use nine 9-digit numbers to encode 59 bits each (59 bytes in 72 characters), which does fit into Long.  Thus it

That's _eight_ 9-digit numbers, of course.

  --Rex

> I also enjoy how the individual messages are clearly marked with the
> time of day, but the year is considered an extraneous detail. "Come
> on, we're telling you what time it is, you want the year ALSO? You
> readers of archived messages are never satisfied!"

Try .