Re: [racket-dev] Scribble output changes

[Matthew Flatt]

At Fri, 05 Aug 2011 19:54:07 -0400, Prabhakar Ragde wrote:
> For what it's worth, I found the documentation on tables largely 
> incomprehensible, and could not get them to render through LaTeX without 
> everything all mushed together.

I agree.

(As it happens, if I had continued working on Scribble today, then
easy-to-use options/variants for cell spacing and borders would have
been my next change --- or, at least, so I thought at the point that I
shifted to other things.)

> Apropos of which, I don't know how to produce pure raw LaTeX code from 
> within Scribble. I can usually cheat with things like
> 
> (make-element
>  (make-style "begin" '(exact-chars)) ...)
> 
> or (make-style "relax" ...), but for LaTeX package macros that parse one 
> of their arguments more exactly (where wrapping the argument in 
> \relax{...} will not work), I have to resort to building what I want at 
> a high enough level that I can wrap it all in \relax without LaTeX 
> getting upset. I feel like I'm pretty much doing what the LaTeX renderer 
> does, but trying to stay within a higher-level API. If we want Scribble 
> to be a LaTeX replacement but still render through LaTeX, it might need 
> more thinking as to how to provide access in a Rackety fashion.

I agree with all that, too. It sounds like you're doing the right
experiments to figure out what the better interface should be!

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [plt] Push #23181: master branch updated

[Robby Findler]

How about

 #:mode (sum I I O)

for the mode spec where the #:mode keyword is optional but, if present must
be followed by what looks like a use of the relation but with a
Mode?

Robby

On Friday, August 5, 2011, Casey Klein 
wrote:
> On Fri, Aug 5, 2011 at 8:13 AM,   wrote:
>> clklein has updated `master' from 1a65678924 to 576272362b.
>>  http://git.racket-lang.org/plt/1a65678924..576272362b
>>
>
> This push adds a more general way to define relations in Redex,
> currently under the name define-judgment-form. For those of you
> familiar with the existing define-relation form, this new form lifts
> the restriction that relations have no outputs when executed. In
> particular, it lets you specify which positions are inputs and which
> are outputs, and it statically checks that the outputs can be computed
> from the inputs without "guessing" any intermediate values.
>
> Here's a simple example:
>
> (define-language nats
>  (n z (s n)))
>
> (define-judgment-form nats
>  mode : O O I
>  sum ⊆ n × n × n
>  [(sum z n n)]
>  [(sum (s n_1) n_2 (s n_3))
>   (sum n_1 n_2 n_3)])
>
>> (judgment-holds (sum (s (s z)) (s z) (s (s (s z)
> true
>> (judgment-holds (sum (s (s z)) (s z) (s (s z
> false
>> (judgment-holds (sum (s z) n (s (s z))) n)
> `((s z))
>> (judgment-holds (sum n_1 n_2 (s (s z))) (n_1 n_2))
> `(((s (s z)) z) ((s z) (s z)) (z (s (s z
>
> I see three use cases:
>
> 1. Defining type systems in a way that supports mechanized
> typesetting. Here's an example:
>
> https://gist.github.com/1128672
>
> There are still plenty of type systems Redex can't express, but the
> new form gets a lot of low-hanging fruit.
>
> 2. Defining structural operational semantics in a way that supports
> mechanized typesetting. Here's an example:
>
> https://gist.github.com/1128685
>
> Relations defined in this way don't work directly with traces. You can
> embed them in reduction-relation, as the example demonstrates, but you
> lose out on edge labels. It shouldn't be too difficult to rig up
> something better, if this turns out to be important.
>
> 3. Defining relations using something like multi-valued metafunctions.
> Here's an example in which (add1 e) may reduce to 0.
>
> https://gist.github.com/1128692
>
> Any feedback is welcome, but I'm especially interested in opinions on
> two points:
>
> 1. Is there a better name than define-judgment-form? I would have
> liked the name define-relation, if it weren't already taken. Is it OK
> to overload it?
>
> 2. Should mode declarations use a different syntax? I tried to do
> something in the paren-free style of define-relation contracts, but I
> don't like the result -- partially because I personally like parens,
> partially because it makes it harder to give good error messages.
>
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] Scribble output changes

[Prabhakar Ragde]

Matthew wrote:


Latex output changed in more ways:

 * Table content is vertically centered by default, making it more
   consistent with HTML.

 * In a table cell, a paragraph with a `#f' style name is rendered as a
   single line (as before), but a width is imposed on paragraphs that
   have a style name to make them flow as paragraphs.


For what it's worth, I found the documentation on tables largely 
incomprehensible, and could not get them to render through LaTeX without 
everything all mushed together. I finally wrote my own table function 
(using \array, which spaces things out well) that had the formatting I 
wanted. Cell styles? No clue.


Apropos of which, I don't know how to produce pure raw LaTeX code from 
within Scribble. I can usually cheat with things like


(make-element
(make-style "begin" '(exact-chars)) ...)

or (make-style "relax" ...), but for LaTeX package macros that parse one 
of their arguments more exactly (where wrapping the argument in 
\relax{...} will not work), I have to resort to building what I want at 
a high enough level that I can wrap it all in \relax without LaTeX 
getting upset. I feel like I'm pretty much doing what the LaTeX renderer 
does, but trying to stay within a higher-level API. If we want Scribble 
to be a LaTeX replacement but still render through LaTeX, it might need 
more thinking as to how to provide access in a Rackety fashion.


Sorry if I'm being completely ignorant here. I'm a passable Racket 
programmer but a lousy LaTeX programmer. --PR

_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]

[Neil Toronto]

Redirecting this from Kevin back to the group, because I think at least 
plot2d is good enough for anyone to play with now.


I've put all of it here:

https://github.com/ntoronto/plt-stuff/tree/master/plot

The main module files are meant to be plot2d.rkt and plot3d.rkt. Both 
contain tests right now. In particular, Kevin, the tests in plot2d.rkt 
show how to generate simple 2D plots and save them to files.


(In fact, I've just added plot2d->file, which writes a plot to a file or 
output stream using any bitmap or vector format that Racket supports. I 
haven't tested it much, but it appears to work.)


This code is very young and fairly untested; standard warnings apply. 
(May pillage your families and murder your crops, etc.) The interface 
WILL change, so don't count on it.


Neil T

On 08/03/2011 09:41 AM, Kevin Tew wrote:

Have a github link yet?

I have a simple line graph I need to generate and would like to give
your 2d plot a try.

Kevin

On 08/02/2011 11:33 AM, Neil Toronto wrote:

Re-routing this email exchange to [racket-dev] for comments.

Long story short: Jay roped me into replacing the current `plot'
module by wrapping a plot library I was working on for my own use.
(FWIW, I'm happy to finally contribute something!) Intended features:

1. Doesn't depend on an FFI to libplplot
2. Can automatically place plot area on functions and points
3. Uses parameters for keyword argument default values
4. Uses only dc<%> primitives / Is very pretty
5. Is more flexible (when using the new plot2d and plot3d modules)

Linux screenshots:

http://students.cs.byu.edu/~ntoronto/plot2d.png
http://students.cs.byu.edu/~ntoronto/plot3d.png

The first shows off the almost-finished plot2d. It's as fast as the
original `plot', and `shade' is twice as fast. Props to Matthew and
Linux's foreign drawing libs for making it look so nice.

The second shows off 3d-plot-area%, which wraps a dc<%> with 3d
drawing primitives. The new plot3d will be 1.5x-2x slower, but the new
features (e.g. compositing 3d plots, contours) should be worth it.

I'll push code to github soon, and ask for volunteers to verify that
it looks good on Mac and Windows.

Specific questions
--

Matthew: It should look good on Mac and Windows if their drawing libs
do subpixel-accurate, high-quality antialiasing. Do they?

Doug and other heavy `plot' users: What can I add to plot2d and plot3d
to make your life easier?

Noel: Do you happen to have a kernel density estimator implementation
that uses FFT or is otherwise more efficient than O(n^2)? Currently,
(plot2d (density samples)) works, but is slow on large samples.

Anyone: Are there any original `plot' features that should *not* be
emulated in the new `plot' wrapper module?

Anyone: Is it easy/possible to manipulate snip%s with, say, a
click-and-drag? How about placing edit boxes on them? If it's not
hard, I would like to make the 3d plots manipulatable after rendering.

Neil T

On 07/30/2011 02:01 PM, Jay McCarthy wrote:

Yup, so that old programs will keep working.

Will you support the line fitting?

Jay

On Sat, Jul 30, 2011 at 1:56 PM, Neil Toronto
wrote:

Sure can! Does "compatible source library" mean a bunch of wrappers
for the
functions "plot" currently exports?

Neil

On 07/30/2011 05:49 AM, Jay McCarthy wrote:


Awesome. We've been wanting to throw it out for a long time. Can you
make a compatible source library too... so we can replace it in the
core?

Jay

On Fri, Jul 29, 2011 at 10:35 PM, Neil Toronto
wrote:


I've attached a screenshot of what I'm working on.

It's a replacement for Racket's plot module. The plot module has
these
drawbacks:

1. It's not smart enough to automatically size plots to the things -
"renderers" - you're plotting. A renderer is only a function that
accepts
an
image snip, so the plotter can't compute a rectangle that contains
it.

2. It depends on an external library, plplot.

3. It draws ugly curves because plplot can't draw lines with
subpixel-accurate endpoints. Also, plplot messes up antialiasing
when the
curves are made of too many lines. Whatever Racket uses doesn't
have this
problem, at least on Linux.

4. It doesn't use parameters for things for which parameters make
sense,
like the size of the plots.

I could probably alter the plot module for any one or two of these
and
submit patches. For all four, writing a replacement makes more sense.

FWIW, this is related to my research. I've been using R to generate
plots,
but it's getting annoying to serialize samples in Racket and then
unserialize them in R.

Also, Bayesians make a LOT of plots. It's *really* nice to display
them
using image snips. That's very, very cool.

This project feels vacation-y and relaxing. I figure it's because it
doesn't
require any more math than linear algebra. :D

Neil

_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev




_
 For lis

Re: [racket-dev] [plt] Push #23181: master branch updated

[Casey Klein]

On Fri, Aug 5, 2011 at 8:13 AM,   wrote:
> clklein has updated `master' from 1a65678924 to 576272362b.
>  http://git.racket-lang.org/plt/1a65678924..576272362b
>

This push adds a more general way to define relations in Redex,
currently under the name define-judgment-form. For those of you
familiar with the existing define-relation form, this new form lifts
the restriction that relations have no outputs when executed. In
particular, it lets you specify which positions are inputs and which
are outputs, and it statically checks that the outputs can be computed
from the inputs without "guessing" any intermediate values.

Here's a simple example:

(define-language nats
  (n z (s n)))

(define-judgment-form nats
  mode : O O I
  sum ⊆ n × n × n
  [(sum z n n)]
  [(sum (s n_1) n_2 (s n_3))
   (sum n_1 n_2 n_3)])

> (judgment-holds (sum (s (s z)) (s z) (s (s (s z)
true
> (judgment-holds (sum (s (s z)) (s z) (s (s z
false
> (judgment-holds (sum (s z) n (s (s z))) n)
`((s z))
> (judgment-holds (sum n_1 n_2 (s (s z))) (n_1 n_2))
`(((s (s z)) z) ((s z) (s z)) (z (s (s z

I see three use cases:

1. Defining type systems in a way that supports mechanized
typesetting. Here's an example:

https://gist.github.com/1128672

There are still plenty of type systems Redex can't express, but the
new form gets a lot of low-hanging fruit.

2. Defining structural operational semantics in a way that supports
mechanized typesetting. Here's an example:

https://gist.github.com/1128685

Relations defined in this way don't work directly with traces. You can
embed them in reduction-relation, as the example demonstrates, but you
lose out on edge labels. It shouldn't be too difficult to rig up
something better, if this turns out to be important.

3. Defining relations using something like multi-valued metafunctions.
Here's an example in which (add1 e) may reduce to 0.

https://gist.github.com/1128692

Any feedback is welcome, but I'm especially interested in opinions on
two points:

1. Is there a better name than define-judgment-form? I would have
liked the name define-relation, if it weren't already taken. Is it OK
to overload it?

2. Should mode declarations use a different syntax? I tried to do
something in the paren-free style of define-relation contracts, but I
don't like the result -- partially because I personally like parens,
partially because it makes it harder to give good error messages.

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] search (was Roogle?)

[Noel Welsh]

This matches my understanding.

N.

On Fri, Aug 5, 2011 at 8:33 PM, Matthias Felleisen  wrote:
>
> So where does this leave us:
>
> 1. with very little data about real searches, which happen locally, via 
> DrRacket  (would it matter if we could do a Guillaume-style data collection 
> for a few dozen students?)
>
> 2. with an understood deficit on our search; I haven't seen anyone deny this
>
> 3. a few options on improving search when we're on-line via JS calls to 
> search engines (this clearly requires some experimentation before we commit)
>
> 4a. John's wonderful idea of search the examples in our docs. Well, I imagine 
> he's searching for all one-argument functions, runs them on the example, and 
> produces the list of functions that compute acceptable results. Now, if we 
> hashed these searches, we get a crowd-sourcing problem -- perhaps. The more 
> users/students search for pure functions, the better we get. Perhaps.
>
> 4b. and we know that once text search is incorporated we may wish to look for 
> some form of semantic search.
>
> Did I overlook something? -- Matthias

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Racket and Text Editors

[Vincent St-Amour]

I've added an updated version of the document to the Guide.

If you think it's not in the right place, I'm fine with putting it
elsewhere.

Vincent


At Thu, 04 Aug 2011 16:30:47 -0400,
Vincent St-Amour wrote:
> 
> 
> As I mentioned at RacketCon, I've been working (with help from Asumu
> Takikawa and Jon Rafkind) on a document that provides pointers to
> tools for using Racket with popular text editors.
> 
> I now have a draft of it on my webpage:
> http://www.ccs.neu.edu/home/stamourv/using-racket-with-your-editor-of-choice.html
> 
> I think this would be a nice resource to have somewhere in the Racket
> documentation. Does anyone have an idea where it should go?
> 
> I'd also like feedback on the document itself. It's not especially
> detailed, and I'm sure I forgot a lot of useful things.
> 
> Vincent
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] bug czar and documentation king

[Noel Welsh]

The king is dead -- long live the king!

On Fri, Aug 5, 2011 at 9:01 PM, Matthias Felleisen  wrote:
>
> We than Ryan Culpepper (Utah) for his work as bug czar for the past year or 
> so.
>
> As of the next release, Sam Tobin-Hochstadt (NEU) will take over the bug czar 
> duty.
>
> Ryan will become king of documentation, with the charge to improve its 
> organization and presentation.
>
> Thanks guys -- Matthias
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] bug czar and documentation king

[Matthias Felleisen]

We than Ryan Culpepper (Utah) for his work as bug czar for the past year or so. 

As of the next release, Sam Tobin-Hochstadt (NEU) will take over the bug czar 
duty. 

Ryan will become king of documentation, with the charge to improve its 
organization and presentation. 

Thanks guys -- Matthias


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] search (was Roogle?)

[Matthias Felleisen]

So where does this leave us: 

1. with very little data about real searches, which happen locally, via 
DrRacket  (would it matter if we could do a Guillaume-style data collection for 
a few dozen students?)

2. with an understood deficit on our search; I haven't seen anyone deny this

3. a few options on improving search when we're on-line via JS calls to search 
engines (this clearly requires some experimentation before we commit) 

4a. John's wonderful idea of search the examples in our docs. Well, I imagine 
he's searching for all one-argument functions, runs them on the example, and 
produces the list of functions that compute acceptable results. Now, if we 
hashed these searches, we get a crowd-sourcing problem -- perhaps. The more 
users/students search for pure functions, the better we get. Perhaps. 

4b. and we know that once text search is incorporated we may wish to look for 
some form of semantic search. 

Did I overlook something? -- Matthias


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Jens Axel Søgaard]

2011/8/5 Stephen Chang 

For online, full-text search, couldn't one just use google and add
> "site:docs.racket-lang.org" to the query?


The Google stemmer is well-suited for natural languages.
It sucks for Scheme/Racket identifiers.

Try for example to find cons* or list? .

/Jens Axel
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Racket and Text Editors

[Vincent St-Amour]

At Fri, 5 Aug 2011 03:22:07 -0400,
Eli Barzilay wrote:
> The problem is that the meta collection is not intended for
> distribution.  Even if it's moved to some collection that will get
> included, it's an abuse of what `collects' means at the moment.

I see. How about a `contrib' directory at the top level of the
distribution? That would be a good place if we ever want to
distribute, say, quack as part of the Racket distribution.

> > > * `check-requires' is even less important than that...  Including
> > >   it means including a whole bunch of other things (for example,
> > >   the macro stepper's textual interface).  If anything, add it as
> > >   an xrepl command.
> > 
> > Adding it to xrepl is a good idea.
> 
> Tell me how to call it, and I'll add it.

`check-requires' sounds good. Maybe with `cr' as an available
abbreviation?

As for inclusion in xrepl, `show-requires' (from
`macro-debugger/analysis/check-requires.rkt') may be a better starting
point than `check-requires-script.rkt'.

Vincent
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] Scribble output changes

[Matthew Flatt]

For HTML output, `racketblock' and `codeblock' now use a style that
discourages line wrapping. So, when you make code that is too wide, it
will usually[*] extend past the right margin instead of wrapping lines.
This doesn't mean that too-wide code is ok; it's just a better failure
mode in most cases.

[*] Probably not for IE7 and earlier.


Latex output changed in more ways:

 * Documentation via `defform', `defproc', etc., renders with a
   vertical bar to the left, instead of a thin horizontal line above.
   (Thanks to an anonymous DLS'11 reviewer for this suggestion.)

   Also, those forms add vertical space like `codeblock', so they look
   right in document formats such as the SIGPLAN style.

 * Table content is vertically centered by default, making it more
   consistent with HTML.

 * In a table cell, a paragraph with a `#f' style name is rendered as a
   single line (as before), but a width is imposed on paragraphs that
   have a style name to make them flow as paragraphs.

 * More generally, a paragraph or nested flow can be "boxable", which
   means that it supplies a rendering mode (via a `box-mode' style
   property) such that the output is a Tex box instead of a paragraph.
   Box mode is triggered by cells in a multi-column table.

   The output from `racketblock' and `codeblock' is boxable, which
   means that tables and table columns containing code automatically
   size the expected way (i.e., like HTML). Meanwhile, outside of a
   table, boxable blocks render the old way, which allows page breaks
   within the block and generally cooperates better with Latex document
   styles.

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Noel Welsh]

On Fri, Aug 5, 2011 at 4:44 PM, Stephen Chang  wrote:
> For online, full-text search, couldn't one just use google and add
> "site:docs.racket-lang.org" to the query?

Yeah, that seems to do it. The ordering of results is a bit odd
sometimes. I don't know the details but Google offers site specific
search under certain conditions. I think the site specific search is
basically equivalent what you suggest.

N.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Stephen Chang]

On Fri, Aug 5, 2011 at 9:45 AM, Shriram Krishnamurthi  wrote:
> Noel is absolutely right.
>
> We live in an era where Search Just Works.  I do dozens of Google
> searches on most days.  To go from there to Help Desk is an incredibly
> jarring experience.  I have to load new instructions into my head:
> "stick to one word", "stem!", etc., that I haven't had to use on
> search engines since the late 1990s.
>
> Even though I like to program on flights and trains, where Eli's
> concerns apply completely, I am also fully aware that I cannot get
> various services while disconnected.  What is unconscionable is that
> I can't do *better* while connected to the internet.

For online, full-text search, couldn't one just use google and add
"site:docs.racket-lang.org" to the query?

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] Better than roogle? (was: Re: Roogle?)

[John Clements]

... related idea I had about two years ago: don't search on types, search on 
inputs & desired outputs.  So:

(? (list 3 4 5)) => (list 5 4 3)

... produces "reverse".  How does it get there? By simply trying them all.  You 
could narrow the search by checking first for arity, and then perhaps by doing 
clever things with contracts.

In my mind, this has the same "just close your eyes and search" attitude that 
has made google so useful.

John




smime.p7s
Description: S/MIME cryptographic signature
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Shriram Krishnamurthi]

I suspect your related work section missed a few. (-:

On Fri, Aug 5, 2011 at 10:06 AM, Matthias Felleisen
 wrote:
>
> It was my Diplomarbeit finished in 1983, so that makes it 28 years now.
>
>
>
> On Aug 5, 2011, at 12:17 AM, Shriram Krishnamurthi wrote:
>
>> This idea is proposed roughly every 2-3 years for at least 30 years.
>> I am not aware of anyone having made this idea "fly".
>>
>> Shriram
>>
>> On Fri, Aug 5, 2011 at 12:13 AM, Robby Findler
>>  wrote:
>>> I too tried it (ages ago) and ended up roughly where Eli is, but I
>>> didn't want to judge since I wasn't actually trying to use it for
>>> something useful (and, as we all know, that can change how you use
>>> things and how well they work for you). So I wonder if anyone has a
>>> positive experience with this kind of searching in an "in anger" kind
>>> of setting?
>>>
>>> Robby
>>>
>>> On Thu, Aug 4, 2011 at 9:08 PM, Eli Barzilay  wrote:
 6 minutes ago, Asumu Takikawa wrote:
> A few of us in the lab today were discussing how the Haskell
> community has this nice tool called Hoogle
> (http://www.haskell.org/hoogle) that lets you search Haskell docs by
> type.

 Are there any *practical* uses for that thing?

 (Not a flame, I tried it a few times, and it looked like i might be
 useful in a language where you use point-free style to compose
 functions -- so you might know the type that you need `(a -> b -> c)
 -> (b -> c -> a)' but not the `flip' name.  But such serches don't
 see, to work.  So from this shallow scan, it looks like one of these
 things that sound cool on paper, but are useless in practice.)


> Is it at all feasible to supplement Racket's doc search to display
> contracts

 That won't be hard in itself, but the real problem is huge blocks of
 text in the results which would make it much less useful.

> and/or search by contract? (or type for TR)

 That would be more difficult, since the search will need to do a lot
 more work.  I'm also guessing that given that we have much more *text*
 in contracts (as in "integer" and "resolved-module-path?"), it will
 make searching show way more false positives.

 --
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!
 _
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

>>>
>>> _
>>>  For list-related administrative tasks:
>>>  http://lists.racket-lang.org/listinfo/dev
>>
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>
>

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Matthias Felleisen]

It was my Diplomarbeit finished in 1983, so that makes it 28 years now. 



On Aug 5, 2011, at 12:17 AM, Shriram Krishnamurthi wrote:

> This idea is proposed roughly every 2-3 years for at least 30 years.
> I am not aware of anyone having made this idea "fly".
> 
> Shriram
> 
> On Fri, Aug 5, 2011 at 12:13 AM, Robby Findler
>  wrote:
>> I too tried it (ages ago) and ended up roughly where Eli is, but I
>> didn't want to judge since I wasn't actually trying to use it for
>> something useful (and, as we all know, that can change how you use
>> things and how well they work for you). So I wonder if anyone has a
>> positive experience with this kind of searching in an "in anger" kind
>> of setting?
>> 
>> Robby
>> 
>> On Thu, Aug 4, 2011 at 9:08 PM, Eli Barzilay  wrote:
>>> 6 minutes ago, Asumu Takikawa wrote:
 A few of us in the lab today were discussing how the Haskell
 community has this nice tool called Hoogle
 (http://www.haskell.org/hoogle) that lets you search Haskell docs by
 type.
>>> 
>>> Are there any *practical* uses for that thing?
>>> 
>>> (Not a flame, I tried it a few times, and it looked like i might be
>>> useful in a language where you use point-free style to compose
>>> functions -- so you might know the type that you need `(a -> b -> c)
>>> -> (b -> c -> a)' but not the `flip' name.  But such serches don't
>>> see, to work.  So from this shallow scan, it looks like one of these
>>> things that sound cool on paper, but are useless in practice.)
>>> 
>>> 
 Is it at all feasible to supplement Racket's doc search to display
 contracts
>>> 
>>> That won't be hard in itself, but the real problem is huge blocks of
>>> text in the results which would make it much less useful.
>>> 
 and/or search by contract? (or type for TR)
>>> 
>>> That would be more difficult, since the search will need to do a lot
>>> more work.  I'm also guessing that given that we have much more *text*
>>> in contracts (as in "integer" and "resolved-module-path?"), it will
>>> make searching show way more false positives.
>>> 
>>> --
>>>  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
>>>http://barzilay.org/   Maze is Life!
>>> _
>>>  For list-related administrative tasks:
>>>  http://lists.racket-lang.org/listinfo/dev
>>> 
>> 
>> _
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
> 
> _
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Shriram Krishnamurthi]

Noel is absolutely right.

We live in an era where Search Just Works.  I do dozens of Google
searches on most days.  To go from there to Help Desk is an incredibly
jarring experience.  I have to load new instructions into my head:
"stick to one word", "stem!", etc., that I haven't had to use on
search engines since the late 1990s.

Even though I like to program on flights and trains, where Eli's
concerns apply completely, I am also fully aware that I cannot get
various services while disconnected.  What is unconscionable is that
I can't do *better* while connected to the internet.

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Problems compiling Racket-5.1.2 on SunOS5.10(x86)

[Matthew Flatt]

At Thu, 4 Aug 2011 14:26:55 -0500, Kent Mein wrote:
> I'm trying to compile 5.1.2 on SunOS5.10(x86) and I'm getting the 
> following errors, anyone have any ideas?
> 
> [...]
> 
> ffi-obj: couldn't get "scheme_register_process_global" from #f (libc.so.1: 
> racketcgc: fatal: scheme_register_process_global: can't find symbol)

It looks like identifiers aren't exported by the `racket' executable.

Does configuring with `-rdynamic' in LDFLAGS fix the problem?:

 env LDFLAGS="-rdynamic" configure


Another possibility is 

  configure --enable-shared

which usually isn't recommended, but it should work around the problem.

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Noel Welsh]

On Fri, Aug 5, 2011 at 8:45 AM, Eli Barzilay  wrote:
> Ah, if you mean a way to have both kinds of searches work on your
> installation

Yes.

> Well, the issue was exactly the dependency on an on-line connection
> and no user-specific docs.

For the first, the ajax request should get around it. For the second:
m'eh. You'll still get the JS index results. One could transmit the
set of installed packages to the full text server, but the great is
the enemy of the good, and it just needs to be good enough.

N.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Eli Barzilay]

About a minute ago, Noel Welsh wrote:
> On Fri, Aug 5, 2011 at 8:12 AM, Eli Barzilay  wrote:
> > About a minute ago, Noel Welsh wrote:
> >> With the power of asynchronous requests (aka ajax) it is. I've
> >> gotta fix Myna first; maybe then I'll have a spare moment to
> >> implement it.
> >
> > That doesn't help with the goal of standalone docs.
> 
> Sorry, don't understand this.

Having the documentation available through your installation,
off-line, and holding documentation of misc packages that you
installed.


> > Oh, you mean running something *different* on
> > docs.racket-lang.org?
> 
> That is one possibility. The other option is to always make an ajax
> request to the full text search. It's asynchronous, so it won't stop
> page rendering, and if it doesn't return successfully (no Internet
> connection, for example) the user experience won't be affected
> (beyond not having the full text results in addition to the current
> javascript index results).

Ah, if you mean a way to have both kinds of searches work on your
installation, then that's certainly a solution.  (But my guess is that
it'll be even more difficult to set up.)


> > (And the search can be solved in an even easier way with a google
> > custom search.)
> 
> Ok. I thought there were issues with Google, but, yeah, if it works
> it is certainly easier than setting up Lucene.

Well, the issue was exactly the dependency on an on-line connection
and no user-specific docs.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Noel Welsh]

On Fri, Aug 5, 2011 at 8:12 AM, Eli Barzilay  wrote:
> About a minute ago, Noel Welsh wrote:
>> With the power of asynchronous requests (aka ajax) it is. I've gotta
>> fix Myna first; maybe then I'll have a spare moment to implement it.
>
> That doesn't help with the goal of standalone docs.
>

Sorry, don't understand this.

> Oh, you mean running something *different* on docs.racket-lang.org?

That is one possibility. The other option is to always make an ajax
request to the full text search. It's asynchronous, so it won't stop
page rendering, and if it doesn't return successfully (no Internet
connection, for example) the user experience won't be affected (beyond
not having the full text results in addition to the current javascript
index results).

> (And the search can be
> solved in an even easier way with a google custom search.)

Ok. I thought there were issues with Google, but, yeah, if it works it
is certainly easier than setting up Lucene.

N.
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Racket and Text Editors

[Eli Barzilay]

9 hours ago, Vincent St-Amour wrote:
> At Thu, 4 Aug 2011 18:08:58 -0300, Rodolfo Carvalho wrote:
> > 
> > About Bash completion, [...]
> 
> That's a good point.
> 
> I think it would be nice to have it be part of the regular
> distribution. Eli, is there a way to do that?

The problem is that the meta collection is not intended for
distribution.  Even if it's moved to some collection that will get
included, it's an abuse of what `collects' means at the moment.


9 hours ago, Vincent St-Amour wrote:
> 
> I didn't want to repeat information that was already in the xrepl
> documentation, but you're right that highlighting some of the
> features is probably a good idea.

Yes, these highlights fit well with this text.


> > * `check-requires' is even less important than that...  Including
> >   it means including a whole bunch of other things (for example,
> >   the macro stepper's textual interface).  If anything, add it as
> >   an xrepl command.
> 
> Adding it to xrepl is a good idea.

Tell me how to call it, and I'll add it.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Problems compiling Racket-5.1.2 on SunOS5.10(x86)

[Eli Barzilay]

12 hours ago, Kent Mein wrote:
> I'm trying to compile 5.1.2 on SunOS5.10(x86) and I'm getting the
> following errors, anyone have any ideas?
> 
> I used --disable-libffi when calling configure.

Even if you make the C compilation go through by disabling plot,
you'll run into problems in many other places that need the ffi
support.  The most obvious problem is that you'll have no GUI support.
Why are you disabling it?

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] Problems compiling Racket-5.1.2 on SunOS5.10(x86)

[Kent Mein]

I'm trying to compile 5.1.2 on SunOS5.10(x86) and I'm getting the 
following errors, anyone have any ideas?

I used --disable-libffi when calling configure.

make[4]: Entering directory `/home/staff01/mein/Downloads/racket-5.1.2/src/plot'
env CC="gcc" CFLAGS="-g -O2  -Wall " LDFLAGS=" " ../racket/racketcgc -c 
./build.rkt "libplplot" ./plplot/dc_drv.c ./plplot/plcont.c ./plplot/plfill.c 
./plplot/plmap.c ./plplot/plshade.c ./plplot/plwind.c ./plplot/pdfutils.c 
./plplot/plcore.c ./plplot/plgridd.c ./plplot/plmeta.c ./plplot/plstripc.c 
./plplot/plargs.c ./plplot/plctrl.c ./plplot/plhist.c ./plplot/plot3d.c 
./plplot/plsym.c ./plplot/plbox.c ./plplot/plcvt.c ./plplot/plimage.c 
./plplot/plpage.c ./plplot/pltick.c ./plplot/plbuf.c ./plplot/pldtik.c 
./plplot/plline.c ./plplot/plsdef.c ./plplot/plvpor.c
ffi-obj: couldn't get "scheme_register_process_global" from #f (libc.so.1: 
racketcgc: fatal: scheme_register_process_global: can't find symbol)

 === context ===
/home/staff01/mein/Downloads/racket-5.1.2/collects/racket/private/more-scheme.rkt:264:28
/home/staff01/mein/Downloads/racket-5.1.2/collects/ffi/unsafe.rkt:178:2: 
get-ffi-obj*
/home/staff01/mein/Downloads/racket-5.1.2/collects/racket/gui/dynamic.rkt: 
[running body]
/home/staff01/mein/Downloads/racket-5.1.2/collects/scheme/gui/dynamic.rkt: 
[traversing imports]
/home/staff01/mein/Downloads/racket-5.1.2/collects/mzlib/sendevent.rkt: 
[traversing imports]
/home/staff01/mein/Downloads/racket-5.1.2/collects/dynext/compile-unit.rkt: 
[traversing imports]
/home/staff01/mein/Downloads/racket-5.1.2/collects/dynext/compile.rkt: 
[traversing imports]
/home/staff01/mein/Downloads/racket-5.1.2/src/plot/build.rkt: [traversing 
imports]

I've also tried --disable-foreign but then I get this:
make[4]: Entering directory `/home/staff01/mein/Downloads/racket-5.1.2/src/plot'
env CC="gcc" CFLAGS="-g -O2  -Wall " LDFLAGS=" -Wl,-E" ../racket/racketcgc -c 
./build.rkt "libplplot" ./plplot/dc_drv.c ./plplot/plcont.c ./plplot/plfill.c 
./plplot/plmap.c ./plplot/plshade.c ./plplot/plwind.c ./plplot/pdfutils.c 
./plplot/plcore.c ./plplot/plgridd.c ./plplot/plmeta.c ./plplot/plstripc.c 
./plplot/plargs.c ./plplot/plctrl.c ./plplot/plhist.c ./plplot/plot3d.c 
./plplot/plsym.c ./plplot/plbox.c ./plplot/plcvt.c ./plplot/plimage.c 
./plplot/plpage.c ./plplot/pltick.c ./plplot/plbuf.c ./plplot/pldtik.c 
./plplot/plline.c ./plplot/plsdef.c ./plplot/plvpor.c
ffi-lib?: foreign interface not supported for this platform

 === context ===
/home/staff01/mein/Downloads/racket-5.1.2/collects/ffi/unsafe.rkt:178:2: 
get-ffi-obj*
/home/staff01/mein/Downloads/racket-5.1.2/collects/racket/gui/dynamic.rkt: 
[running body]
/home/staff01/mein/Downloads/racket-5.1.2/collects/scheme/gui/dynamic.rkt: 
[traversing imports]
/home/staff01/mein/Downloads/racket-5.1.2/collects/mzlib/sendevent.rkt: 
[traversing imports]
/home/staff01/mein/Downloads/racket-5.1.2/collects/dynext/compile-unit.rkt: 
[traversing imports]
/home/staff01/mein/Downloads/racket-5.1.2/collects/dynext/compile.rkt: 
[traversing imports]
/home/staff01/mein/Downloads/racket-5.1.2/src/plot/build.rkt: [traversing 
imports]


I've tried disabling plot as well, things compile but then when I try to
make install I get this:
make[2]: Leaving directory `/home/staff01/mein/Downloads/racket-5.1.2/src'
env CFLAGS="-g -O2  -Wall " LDFLAGS="-Wl,-E"  racket/racket3m -X 
"/export/scratch/mein/racket-5.1.2/lib/racket/collects" -N "raco setup" -l- 
setup--no-user
raco setup: bootstrapping from source...
ffi-lib?: foreign interface not supported for this platform

 === context ===
/export/scratch/mein/racket-5.1.2/lib/racket/collects/ffi/unsafe.rkt:178:2: 
get-ffi-obj*
/export/scratch/mein/racket-5.1.2/lib/racket/collects/racket/gui/dynamic.rkt: 
[running body]
/export/scratch/mein/racket-5.1.2/lib/racket/collects/scheme/gui/dynamic.rkt: 
[traversing imports]
/export/scratch/mein/racket-5.1.2/lib/racket/collects/mzlib/sendevent.rkt: 
[traversing imports]
/export/scratch/mein/racket-5.1.2/lib/racket/collects/dynext/link-unit.rkt: 
[traversing imports]
/export/scratch/mein/racket-5.1.2/lib/racket/collects/dynext/dynext-unit.rkt: 
[traversing imports]
/export/scratch/mein/racket-5.1.2/lib/racket/collects/setup/setup-go.rkt: 
[traversing imports]
/export/scratch/mein/racket-5.1.2/lib/racket/collects/setup/main.rkt: [running 
body]

Thanks,

Kent Mein
-- 
m...@cs.umn.edu
http://www.cs.umn.edu/~mein
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Eli Barzilay]

About a minute ago, Noel Welsh wrote:
> With the power of asynchronous requests (aka ajax) it is. I've gotta
> fix Myna first; maybe then I'll have a spare moment to implement it.

That doesn't help with the goal of standalone docs.


> [Either add a stage to the build process so docs.racket-lang.org
> gets a different search to the local docs or do an Ajax request to
> the full text server and, update the JS index results with the full
> text results if the request completes.]

Oh, you mean running something *different* on docs.racket-lang.org?
That still requires some non-low-hanging hacking of the build process
and the organization of stuff on the server.  (And the search can be
solved in an even easier way with a google custom search.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Noel Welsh]

With the power of asynchronous requests (aka ajax) it is. I've gotta
fix Myna first; maybe then I'll have a spare moment to implement it.

[Either add a stage to the build process so docs.racket-lang.org gets
a different search to the local docs or do an Ajax request to the full
text server and, update the JS index results with the full text
results if the request completes.]

(There are a bunch of really interesting problems here for machine
learning or NLP inclined people who want to work on real systems.)

N.

On Fri, Aug 5, 2011 at 8:01 AM, Eli Barzilay  wrote:
> Changing from a simple JS search that can be installed with Racket to
> a search server is not something that hangs low...
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] Roogle?

[Eli Barzilay]

Three minutes ago, Noel Welsh wrote:
> 
> In conclusion, I think adding full text search (e.g. Lucene/Solr)
> would have the largest impact on the existing search and this
> doesn't even require much implementation work. Pick the low hanging
> fruit!

Changing from a simple JS search that can be installed with Racket to
a search server is not something that hangs low...

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev