
Does anyone know why scribble would print out a ???
as the result of an expression in an examples block?

When I run the same example in a repl, I get the correct output.

@leif I think that means it’s unprintable in some fashion

@samth That would make sense, except that it still shows up in the repl just fine.

I did add a prop:convertible property, that might be doing it….

@leif Yes, it looks like the base renderer prints "???" for any convertible (where convertible values not recognized by the HTML renderer fall through to the base renderer). Maybe that’s a bad idea in the base renderer.

@mflatt Mmmm…maybe. Given the convertible?
interface I don’t think we can do much better though.

It probably should be documented somewhere though.

@mflatt Although in this case, looking, it looks like assuming I can convert it into an image is bad.

Like, I can convert it into a video, but I would honestly just rather it print out its type like in a repl: #<producer>

@mflatt Mmm…looking at the docs, it actually says: > If pretty-print? is true, the sandbox’s printer is set to pretty-print-handler. In that case, values that are convertible in the sense of convertible? are printed using write-special,

However, when I call write-special directly from within drracket, it shows up as you would expect:

#lang scratch
(require video/base)
(define x (clip "green"))
(write-special x)

write-special
means that rendering is up to the port; Scribble doesn’t use DrRacket’s editor%
-based port

AH

okay

In that case, if I turn off #:pretty-print?
when defining the evaluator, will the text no longer be formatted in a nicely indented way?

(I say that because it would make sense to have a middle ground here, where you want the nice indentation, but not the auto-conversion.)

You could turn off #:pretty-print?
, but I think adjusting the base renderer is more likely the right change

Fair. It also looks like it still tries to convert it even when pretty-print? is set to #f
. :disappointed:

So, when you say adjust the base renderer, do you mean submitting a PR?

Or just for the documentation for one package?

I’m looking into the right change.

Okay cool, thanks.

@leif Setting #:pretty-print?
to #f
has no effect because the default operation–as long as current-print
and print-as-expression
are not changed–is to take the result value and typeset it with to-element

That makes sense.

@leif Change pushed

@mflatt cool, thank. checking them out now

@mflatt Also, just to make sure, the package server builds the docs with the latest stable version of racket?

No, http://docs.racket-lang.org\|docs.racket-lang.org is built with the current release

Err…ya, okay.

Basically 6.10, until the next version comes out.

(As I understand it anyway)

Sorry – I misread what you wrote. “latest stable version” is a reasonable synonym for “current release”!

No worries.

Just wondering how long the ???
will stay on the package server’s docs. :slightly_smiling_face:

Also, fyi, it looks like packages with conflicts don’t show up in the search results.

I suspect that’s probably because the package server doesn’t know which one to pick.

right

Is there any way to tell the package server which one it should choose as the primary package?

(Also cool. After compiling the new build it looks like the base renderer is working as expected, thanks. :slightly_smiling_face: )

@blerner has joined the channel

@ryanc when running raco check-requires
on a file of mine, I’m getting an error that looks like this: derivation-parser: error on token #229: <local-value, #<syntax:/Users/alexis/gits/racket/racket/racket/collects/syntax/parse/private/lib.rkt:63:55 -string>>

I am not sure what that means. does that mean anything to you, or should I just open a bug?

I’ve got a demo file to prototype how I want a new hash-lang to be… right now I just want to poke around quickly so I’m using #lang reader "literal.rkt"
and that file does port->list to just dump everything it saw. It is failing on a line with a single \|
in it because it isn’t balanced. Is there another #lang reader (or whatever) that does a looser parse? I just want to prototype the syntax at this point and not get tripped up on racket readerisms…

@zenspider that is due to port->list
, not reader
. port->list
calls read
. is that really what you want, or do you want port->lines
or something like that?

I’m currently line oriented, but I don’t need to be… I want balanced parens and just about nothing else

I only did port->list
because it calls read
until exhausted, right?

you could use port->list
, but parameterize read-accept-bar-quote
to #f

interesting… I’ll try that

that would make \|
not act as a special character

thanks. that did it. perfect

I’m making a hash-lang for lexers… so I want bare \|
s

@lexi.lambda, it means that that macro debugger’s parser and the macro expander’s instrumentation are out of sync. Yes, please file a bug in the macro-debugger repo.

@leif The pkg-build service should pay attention to rings to pick among conflicting packages; it doesn’t, yet. I’ll try to make that improvement sometime soon.