Re: [racket-users] Error location in test submodules

2019-04-04 Thread Greg Hendershott
> Are you using emacs racket-mode? I have experience this issue only in that 
> mode since it does not (to my knowledge) implement all the error anchoring 
> features of DrRacket.

It might just be that you have DrRacket set to user a higher
errortrace level than racket-mode?

That is, in DrR, Language | Choose Language | Dynamic Properties, you
may have chosen one of the "Debugging"  radio buttons and checked
"Preserve stack trace".

In racket-mode, the equivalent is the `racket-error-context` variable:

  
https://github.com/greghendershott/racket-mode/blob/master/Reference.md#racket-error-context

If you have it set to 'low or 'medium, you might not get as much error
context as with 'high (just like if you had "weaker" options in that
DrR dialog box, DrR wouldn't show you as good error context).

As Eric notes, you can leave this set to 'low or 'medium, and do C-u
C-c C-c to re-reun with it temporarily set to 'high. This can be a
nice way to get the best of both worlds: Normally things build and run
faster (errortrace can be slow). If you experience an error, and the
message isn't ideal, you can C-u C-c C-c.


Finally, racket-repl-mode tries to notice Racket error messages in the
output and "linkify" them. You can click them with the mouse, or use
the standard M-x next-error (often bound to C-x `) to go to the error
location. This works with rackunit failures as well as errors.

Of course, it helps if the error file is /path/to/foo.rkt instead of
foo.rkt. Sometimes Racket tries to be helpful and abbreviate long
pathnames to be . racket-mode tries to defeat this abbreviation
so go-to-error can work. :)

Also, some macros don't do the ideal thing -- i.e. don't use e.g.
syntax/loc or quasisyntax/loc -- and the error location is inside the
macro when it might make more sense for it to be the macro use site.
There's not much racket-mode can do about that, AFAICT.


p.s. I didn't feel like you were dissing racket-mode, so I hope the
above doesn't sound defensive. I want to explain what it attempts to
do. I dogfood it heavily and I don't like it to annoy me. :)  However
I know it's far from perfect.  Also there are sometimes long stretches
where I have to be mostly just another user of racket-mode for $WORK,
and can't really detour to work on racket-mode much. Fortunately there
are other people who help contribute fixes and improvements (although
sometimes I get so busy I can barely keep up with their offered help,
and feel doubly guilty).

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Pattern: reusing the same name in macro-generated definitions

2019-04-04 Thread Greg Hendershott
If I understand correctly, the fourth paragraph here is relevant?

  
https://docs.racket-lang.org/reference/syntax-model.html#%28part._transformer-model%29

So, `foo-impl` is a binding introduced by the macro and gets that
macro invocation's fresh macro-introduction scope.

Whereas for example `name` is syntax coming from outside the macro,
and doing `(define-foo (blerg ___) ___)` twice would be an error due
to redefining `blerg`.

On Thu, Apr 4, 2019 at 4:45 PM zeRusski  wrote:
>
> I know in principle but on occasion I fail to understand the implications.  
> Let me think aloud. I don't have to be perfectly accurate, maybe just about 
> right. Hygiene here means that every symbol there e.g. arguments my macro 
> receives carry their "environment" with them. There exists some oracle which 
> can tell when two symbols refer to the same thing probably by checking 
> environments somehow. Since I just typed that foo-impl there in the template 
> it must be getting some fresh tag or "environment" attached to it to avoid 
> capturing something with the same name defined at the macro call site, right? 
> Ok. How the define before foo-impl is special then? We both know the "define" 
> I mean. Or is the newly attached "environment" is in fact not empty and comes 
> enriched with a bunch of Racket stuff? How do I reason when its safe to just 
> type a name and when it isn't? In fact, here. I just defined a foo-impl 
> outside. If I now remove the macro-defined foo-impl the code will still work 
> correctly and grab the outer definition. So define inside a template refers 
> to the usual define, but foo-impl doesn't? Why?
>
> (define (foo-impl op a b) (op a b))
>
> (define-simple-macro (define-foo (name:id formal:id ...) body:expr ...)
>  ... same ...
>
> (define-foo (bar op a b) (op a b))
> (define-foo (baz op a b) (op a b))
> (bar + 1 2)
> ;; => 3
>
>
>
> On Thursday, 4 April 2019 21:02:58 UTC+1, Ben Greenman wrote:
>>
>> Racket's macros are hygienic. They'll gensym for you.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Pattern: reusing the same name in macro-generated definitions

2019-04-04 Thread zeRusski
I know in principle but on occasion I fail to understand the implications.  
Let me think aloud. I don't have to be perfectly accurate, maybe just about 
right. Hygiene here means that every symbol there e.g. arguments my macro 
receives carry their "environment" with them. There exists some oracle 
which can tell when two symbols refer to the same thing probably by 
checking environments somehow. Since I just typed that *foo-impl* there in 
the template it must be getting some fresh tag or "environment" attached to 
it to avoid capturing something with the same name defined at the macro 
call site, right? Ok. How the *define* before *foo-impl *is special then? 
We both know the "define" I mean. Or is the newly attached "environment" is 
in fact not empty and comes enriched with a bunch of Racket stuff? How do I 
reason when its safe to just type a name and when it isn't? In fact, here. 
I just defined a foo-impl outside. If I now remove the macro-defined 
foo-impl the code will still work correctly and grab the outer definition. 
So define *inside* a template refers to the usual define, but *foo-impl* 
doesn't? Why?

(define (foo-impl op a b) (op a b))

(define-simple-macro (define-foo (name:id formal:id ...) body:expr ...)
 ... same ...

(define-foo (bar op a b) (op a b))
(define-foo (baz op a b) (op a b))
(bar + 1 2)
;; => 3



On Thursday, 4 April 2019 21:02:58 UTC+1, Ben Greenman wrote:
>
> Racket's macros are hygienic. They'll gensym for you. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Pattern: reusing the same name in macro-generated definitions

2019-04-04 Thread Ben Greenman
Racket's macros are hygienic. They'll gensym for you.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Pattern: reusing the same name in macro-generated definitions

2019-04-04 Thread zeRusski
While reading *rackunit* source I stumbled on a pattern that I can't figure 
out. Why the heck does it work? Condensed to its essence it amounts to 
introducing indirection with a macro-generated define:

#lang racket
> (require (for-syntax syntax/parse)
>  syntax/parse/define)

 


> (define-simple-macro (define-foo (name:id formal:id ...) body:expr ...)
>   (begin
> (define (foo-impl formal ...) body ...)
> (define-syntax (name stx)
>   (syntax-parse stx
> [(_ . args) #'(foo-impl . args)]
> [_:id #'(λ args (apply foo-impl args))]

 


> (define-foo (bar op a b) (op a b))
> (define-foo (baz op a b) (op a b))
> ;; Why am I not getting this error?
> ;; 
> ; module: identifier already defined
> ;   at: foo-impl



See that *foo-impl* there? The same name is being reused every time the 
*define-foo* macro is called. I would've expected Racket to shout at me 
that I'm attempting to redefine something, but it doesn't and magically it 
works. Why? Say, in Elisp or Clojure I would've gensymed that symbol. What 
am I missing? Does Racket perform some clever renaming to preserve hygiene 
or something? Could someone please help me reason through this.

Original source: 
https://github.com/racket/rackunit/blob/master/rackunit-lib/rackunit/private/check.rkt#L110

PS: also I left that second clause there just cause it just dawned on me 
how cool it is that we can use macros in identifier position :)

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Help with pretty printing

2019-04-04 Thread 'John Clements' via Racket Users
I’m glad to hear it! I think that it may not fail in nice ways for deeply 
nested s-expressions, but that not be an issue for you. I do think that there 
should be a nicer way than using a text%. 

John

> On Apr 4, 2019, at 11:14 AM, Stephen Foster  wrote:
> 
> Thanks, John.  Actually, when you distinguished between the line breaks and 
> the indentation, that helped me come up with the following algorithm.  It 
> basically, 1) lets pretty-print do its thing (inserting more line breaks than 
> I need), 2) uses a regex to scrub out all line breaks after a keywords, and 
> 3) fixes up the indentation after the fact.
> 
> (define (idiomatic-pretty-format d)
>   (define too-many-line-breaks (pretty-format d 0))
>   
>   (define (fix-line-breaks s)
> (regexp-replace* #px"(#:\\S*)\\s*" s "\\1 “))
>   
>   (define (fix-indentation s)
> (local-require framework)
> 
> (define t (new racket:text%))
> (send t insert s)
> (send t tabify-all)
> (send t get-text))
>   
>   (fix-indentation (fix-line-breaks too-many-line-breaks)) )
> 
> 
> I wasn't able to see anything in the pretty-print hooks documentation that 
> seemed to promise a more elegant solution.  However, perhaps I can build my 
> own printer with this pretty printing library: 
> https://docs.racket-lang.org/pprint/index.html
> 
> NOTE: The above function does have the drawback that it relies on 
> racket:text% -- which seems both a little excessive and also will trigger the 
> "Cannot require racket/gui/base a second time" error if you try to call it 
> from a Scribble doc.
> 
> Still on the hunt for a better way...
> 
> On Tue, Apr 2, 2019 at 4:47 PM John Clements  
> wrote:
> One note about this: it’s not really a question about indentation, which 
> isn’t ludicrously hard, it’s a question about inserting linebreaks, which 
> IMHO is much harder. Specifically, you’re asking for a pretty-printer that 
> treats keywords differently from other items. Have you looked through all of 
> the pretty-print hooks at
> 
> https://docs.racket-lang.org/reference/pretty-print.html?q=pretty-print#%28def._%28%28lib._racket%2Fpretty..rkt%29._pretty-print%29%29
> 
> ?
> 
> I’m pretty sure that what you want is not in there, but you should take a 
> look anyway.
> 
> John
> 
> 
> > On Apr 2, 2019, at 3:47 PM, Stephen Foster  wrote:
> > 
> > Hi all,
> > 
> > Suppose, I have a datum that represents valid racket code, like '(test #:a 
> > a #:b b #: c).  I'd love to render (arbitrarily deeply nested) datums like 
> > this to a string that displays like this:
> > 
> > (test
> >   #:a a
> >   #:b b
> >   #:c c)
> > 
> > Pretty printing almost works:
> > 
> > (displayln
> >(pretty-format
> > '(test #:a a #:b b #:c c)
> >24))
> > 
> > '(test
> >   #:a
> >   a
> >   #:b
> >   b
> >   #:c
> >   c)
> > 
> > I thought that fiddling with the columns parameter would help, but it 
> > doesn't:
> > 
> > (displayln
> >(pretty-format
> > '(test #:a a #:b b #:c c)
> >25))
> > 
> > (test #:a a #:b b #:c c)
> > 
> > Maybe there's some way can get racket/pretty to do what I want -- though I 
> > didn't see anything jump out at me in docs.
> > 
> > I was about to write my own pretty printer, but I figured that with so much 
> > stuff out there for typesetting Racket code (e.g in Scribble), I should at 
> > least ask if someone knows of something that does what I want: Basically, 
> > magically formats datums according to Rackety indentation idioms.  
> > 
> > Thanks,
> > Stephen
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> 
> 
> -- 
> 
> 
> Stephen Foster
> ThoughtSTEM Co-Founder
> 318-792-2035



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Help with pretty printing

2019-04-04 Thread Stephen Foster
Thanks, John.  Actually, when you distinguished between the line breaks and
the indentation, that helped me come up with the following algorithm.  It
basically, 1) lets pretty-print do its thing (inserting more line breaks
than I need), 2) uses a regex to scrub out all line breaks after a
keywords, and 3) fixes up the indentation after the fact.

(define (idiomatic-pretty-format d)
  (define too-many-line-breaks (pretty-format d 0))

  (define (fix-line-breaks s)
(regexp-replace* #px"(#:\\S*)\\s*" s "\\1 "))

  (define (fix-indentation s)
(local-require framework)

(define t (new racket:text%))
(send t insert s)
(send t tabify-all)
(send t get-text))

  (fix-indentation (fix-line-breaks too-many-line-breaks)) )


I wasn't able to see anything in the pretty-print hooks documentation that
seemed to promise a more elegant solution.  However, perhaps I can build my
own printer with this pretty printing library:
https://docs.racket-lang.org/pprint/index.html

NOTE: The above function does have the drawback that it relies on
racket:text% -- which seems both a little excessive and also will trigger
the "Cannot require racket/gui/base a second time" error if you try to call
it from a Scribble doc.

Still on the hunt for a better way...

On Tue, Apr 2, 2019 at 4:47 PM John Clements 
wrote:

> One note about this: it’s not really a question about indentation, which
> isn’t ludicrously hard, it’s a question about inserting linebreaks, which
> IMHO is much harder. Specifically, you’re asking for a pretty-printer that
> treats keywords differently from other items. Have you looked through all
> of the pretty-print hooks at
>
>
> https://docs.racket-lang.org/reference/pretty-print.html?q=pretty-print#%28def._%28%28lib._racket%2Fpretty..rkt%29._pretty-print%29%29
>
> ?
>
> I’m pretty sure that what you want is not in there, but you should take a
> look anyway.
>
> John
>
>
> > On Apr 2, 2019, at 3:47 PM, Stephen Foster 
> wrote:
> >
> > Hi all,
> >
> > Suppose, I have a datum that represents valid racket code, like '(test
> #:a a #:b b #: c).  I'd love to render (arbitrarily deeply nested) datums
> like this to a string that displays like this:
> >
> > (test
> >   #:a a
> >   #:b b
> >   #:c c)
> >
> > Pretty printing almost works:
> >
> > (displayln
> >(pretty-format
> > '(test #:a a #:b b #:c c)
> >24))
> >
> > '(test
> >   #:a
> >   a
> >   #:b
> >   b
> >   #:c
> >   c)
> >
> > I thought that fiddling with the columns parameter would help, but it
> doesn't:
> >
> > (displayln
> >(pretty-format
> > '(test #:a a #:b b #:c c)
> >25))
> >
> > (test #:a a #:b b #:c c)
> >
> > Maybe there's some way can get racket/pretty to do what I want -- though
> I didn't see anything jump out at me in docs.
> >
> > I was about to write my own pretty printer, but I figured that with so
> much stuff out there for typesetting Racket code (e.g in Scribble), I
> should at least ask if someone knows of something that does what I want:
> Basically, magically formats datums according to Rackety indentation
> idioms.
> >
> > Thanks,
> > Stephen
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
>

-- 


Stephen Foster
ThoughtSTEM Co-Founder
318-792-2035

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[racket-users] Re: Racket News - Issue 5

2019-04-04 Thread Juan Carlos Olivo
Thanks Paulo, I like seeing these additional resources regarding Racket and 
computer science, as I'm at an intermediate level on both. 

On Monday, April 1, 2019 at 4:05:27 PM UTC-5, Paulo Matos wrote:
>
> Issue 5 is here. 
>
> https://racket-news.com/2019/04/racket-news-issue-5.html 
>
> Come on - make a strong espresso today. You know you deserve it! 
> -- 
> Paulo Matos 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] Error location in test submodules

2019-04-04 Thread zeRusski


> If you want your tests to catch exceptions you need to wrap them in 
> exception handlers, which you could write a macro to do for you; as Eric 
> noted though you need to be careful to preserve source locations.
>

This gave me an idea, so I've been reading *rackunit* docs finally. I'm 
about halfway through and I don't exactly understand the machinery yet but 
with your note above and what I've read so far the following code actually 
does what I want:

(module+ test
>   (require rackunit)
>   (define-check (my-check pred thunk)
> (with-handlers ((;; exn predicate
>  (λ (exn) (and (not (exn:test:check? exn))
>(exn:fail? exn)))
>  ;; exn handler
>  (λ (e) (with-check-info (('exn (make-check-info 
> 'error e)))
>   (fail-check)
>   (check-pred pred (thunk
>   ;; throws
>   (my-check identity (thunk (f)))
>   ;; fails
>   (check eq? 2 3)
>   ;; succeeds
>   (check eq? 3 3))


Here's the output that preserves location of the check that failed:


; FAILURE
; /Users/russki/Code/fcgi-rkt/play.rkt:24:2
name: my-check
location: play.rkt:24:2
params: '(# #)
exn:
#(struct:check-info error #(struct:exn:fail "f-failed" 
#))


; FAILURE
; /Users/russki/Code/fcgi-rkt/play.rkt:26:2
name: check
location: play.rkt:26:2
params: '(# 2 3)


This is a good start I think. To make it useful you'd want to capture the 
errortrace somehow, unpack and report it in the check-info. That is you 
report both the failed test location and the exception with its errortrace. 
I'm sure I'll soon find out how to do all that so that a) rackunit API is 
used and b) report follows Racket and rackunit style as much as possible. 
If you can help of top of your head, that'd be great. Also note the 
necessity of wrapping the test body in a thunk, which is annoying but 
understandable and the docs make a note as to why that is. We could fix 
that and other boilerplate with a macro. I'm just trying to think how I 
could minimize the damage to *rackunit* proper. Speaking of ...

It is tempting to build my own thing for testing but I'll resist it as best 
I can. I'd much rather just have a tiny macro that doesn't interfere with 
rackunit and doesn't impose my oft ill-advised and rash preconceptions. The 
more I read rackunit docs the more I'm convinced I wouldn't be able to 
improve on it without making a big mess. It is possible that I'm going to 
run into more annoying little gotchas that I'd want to fix, but I'm not 
there, yet. Please, don't let my current attitude stop you.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.