[racket-users] Error reporting with (flat?) contracts

[Philip McGrath]

While trying to express in the contract system Daniel Prager's check that a
possibly-buggy square root function actually returns the square root of its
argument (and in particular the nice error messages, I ran into a few
things that weren't quite as I expected.

My first attempt, using flat-contract-with-explanation, looks like this:

(define/contract (squares-to/within/c x error)
  (-> (>=/c 0) (>=/c 0) flat-contract?)
  (flat-contract-with-explanation
   (λ (rslt)
 (cond
   [(not (real? rslt))
(λ (blame)
  (raise-blame-error
blame rslt
'(expected: "real?" given: "~e")
rslt))]
   [(<= (abs (- x (* rslt rslt)))
error)
#t]
   [else
 (λ (blame)
   (raise-blame-error
blame rslt
'(expected:
  "a number that squares to ~e ± ~e"
  given: "~e"
  "\n  " given " squared:  ~e")
x error rslt (* rslt rslt)))]

(define/contract (buggy-sqrt x)
  (->i ([x (>=/c 0)])
   [rslt (x)
(if (= 0 x)
(=/c 0)
(and/c (>/c 0)
   (squares-to/within/c x 0.001)))])
  1)


(Aside: I noticed that despite this thread, flat-contract-with-explanation
still does not accept a #:name argument, or at least not in 6.9.)

Given the above, (buggy-sqrt 4) produces this fairly unhelpful error
message, including none of the nice reporting:

buggy-sqrt: broke its own contract
  promised: (and/c (and/c real? positive?) anonymous-flat-contract)
  produced: 1
  in: the rslt result of
  (->i
   ((x (and/c real? (not/c negative?
   (rslt
(x)
(if (= 0 x)
  (=/c 0)
  (and/c
   (>/c 0)
   (squares-to/within/c x 1e-07)
  contract from: (function buggy-sqrt)
  blaming: (function buggy-sqrt)
   (assuming the contract is correct)
  at: unsaved-editor:26.18


I then tried dropping down to make-flat-contract like this:

(define/contract (squares-to/within/c-v2 x error)
  (-> (>=/c 0) (>=/c 0) flat-contract?)
  (make-flat-contract
   #:name `(squares-to/within/c-v2 ,x ,error)
   #:first-order (λ (rslt)
   (and (real? rslt)
(<= (abs (- x (* rslt rslt)))
error)))
   #:late-neg-projection
   (λ (blame)
 (λ (rslt neg-party)
   (cond
 [(not (real? rslt))
  (raise-blame-error
blame rslt #:missing-party neg-party
'(expected: "real?" given: "~e")
rslt)]
 [(<= (abs (- x (* rslt rslt)))
error)
  rslt]
 [else
  (raise-blame-error
   blame rslt #:missing-party neg-party
   '(expected:
 "a number that squares to ~e ± ~e"
 given: "~e"
 "\n  " given " squared:  ~e")
   x error rslt (* rslt rslt))])

(define/contract (buggy-sqrt-v2 x)
  (->i ([x (>=/c 0)])
   [rslt (x)
(if (= 0 x)
(=/c 0)
(and/c (>/c 0)
   (squares-to/within/c-v2 x 0.001)))])
  1)


but (buggy-sqrt-v2 4) gives this error:

buggy-sqrt-v2: broke its own contract
  promised: (and/c (and/c real? positive?) (squares-to/within/c-v2 4 1e-07))
  produced: 1
  in: the rslt result of
  (->i
   ((x (and/c real? (not/c negative?
   (rslt
(x)
(if (= 0 x)
  (=/c 0)
  (and/c
   (>/c 0)
   (squares-to/within/c-v2 x 1e-07)
  contract from: (function buggy-sqrt-v2)
  blaming: (function buggy-sqrt-v2)
   (assuming the contract is correct)
  at: unsaved-editor:67.18


which is improved only in that it includes a name: it still doesn't use the
nice error message I programed in, and it doesn't even tell me which case
of the and/c failed (though that is fairly obvious in this case).

Just for completeness, I also tried a struct, like so:

(struct squares-to/within-contract (x error)
  #:property prop:custom-write contract-custom-write-property-proc
  #:property prop:flat-contract
  (build-flat-contract-property
   #:name
   (match-lambda
 [(squares-to/within-contract x error)
  `(squares-to/within/c-v3 ,x ,error)])
   #:first-order
   (match-lambda
 [(squares-to/within-contract x error)
  (λ (rslt)
(and (real? rslt)
 (<= (abs (- x (* rslt rslt)))
 error)))])
   #:late-neg-projection
   (match-lambda
 [(squares-to/within-contract x error)
  (λ (blame)
(λ (rslt neg-party)
  (cond
[(not (real? rslt))
 (raise-blame-error
  blame rslt #:missing-party neg-party
  '(expected: "real?" given: "~e")
  rslt)]
[(<= (abs (- x (* rslt rslt)))
 error)
 rslt]
[else
 (raise-blame-error
  blame rslt #:missing-party neg-party
  '(expected:
"a number that squares to ~e 

Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Ben Greenman]

On Tue, May 2, 2017 at 11:43 PM, Daniel Prager 
wrote:

> I kind of expected that it would be possible to do what I wanted with
> "indy" contracts, but struggled with the heavy use of combinators in the
> examples.


Two offhand thoughts:

1. To practice with dependent contracts, I made a "full" spec for the
JavaScript left-pad function.
https://www.npmjs.com/package/left-pad

The exercise was fun, I learned a lot, and I think my solution is "as
readable as possible" :) .
https://github.com/bennn/racket-left-pad


2. "Oh Lord, Don't Let Contracts be Misunderstood" implements a little DSL
on top of ->i contracts: http://www.ccs.neu.edu/racket/pubs/icfp16-dnff.pdf

-- 
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] Apropos contracts: simple predicates and switching on and off

[Philip McGrath]

Here's the "quick" way I'd write the real-sqrt in Racket, combined with an
illustration of one of the advantages of using the established contract
combinators: here they gracefully report a kind of error that in the
original would have caused an error in the error-checking code.

(define/contract (real-sqrt x)
  (->i ([x (>=/c 0)])
   [rslt (x)
(if (= 0 x)
(=/c 0)
(and/c (>=/c 0)
   (λ (rslt) (<= (abs (- x (* rslt rslt))) error])
  "not even a number")


The part of what you describe that has the least support in the Racket
system is controlling the level of safety through a mechanism
like pre-conditions-on/post-conditions-on. It would be easy enough to
create a contract that is always satisfied if e.g. pre-conditions-on (which
might be most Rackety to right as a parameter) is non-false, but I would
suspect, at least in a case like this, you would already have paid most of
the cost by getting into the contract system in the first place.

The most typical solution, as Matthew illustrates, is to attach the
contract at a module boundary with contract-out rather than a function
boundary with define/contract, perhaps ultimately to attach it only to the
public API of your library rather than for internals, and to leave off
checks on the domains of functions (with the "any" contract) once you know
they behave properly. Personally, though, having been annoyed once too
often in tracking down an error that turned out to result from having
changed the number of values a function returned, I'm happy to pay the
price for good errors and trust the wonderful Racket implementers to keep
the price as cheap as possible.

Interestingly I had some trouble getting the nicely specific error messages
you had in your example: I'll post about that separately.

-Philip

On Tue, May 2, 2017 at 9:22 PM, Matthew Butterick  wrote:

>
> On May 2, 2017, at 4:33 PM, Daniel Prager 
> wrote:
>
> (define/pre-post (real-sqrt x)
>   #:pre ([(real? x) "real argument expected"]
>  [(>= x 0) "non-negative argument expected"])
>
>   #:implementation (sqrt x)
>
>   #:post ([(implies (= x 0) (= result 0)) "The sqrt of zero should be
> zero"]
>   [(implies (> x 0) (> result 0)) "Positive numbers have positive
> square-roots"]
>   [(implies (> x 0) (<= (abs (- x (* result result))) 0.001))
>"result * result = x (to within error)"]))
>
>
>
> It sounds like you want alternate notation for stuff the contract system
> can already do.
>
> AFAICT the function below is equivalent to your function above. One could
> create a macro to go from one to the other:
>
>
> (define/contract (real-sqrt x)
>   (([x (and/c
> (or/c (λ (x) (real? x))
>   (curry raise-argument-error 'real-sqrt "real argument
> expected"))
> (or/c (λ (x) (>= x 0))
>   (curry raise-argument-error 'real-sqrt "non-negative
> argument expected")))])
>. ->i .
>[result (x)
>(cond
>  [(= x 0) (or/c (λ (result) (= result 0))
> (curry raise-result-error 'real-sqrt "sqrt of
> zero should be zero"))]
>  [(> x 0) (and/c
>  (or/c (λ (result) (> result 0))
>(curry raise-result-error 'real-sqrt
> "sqrt of positive number should be positive"))
>  (or/c (λ (result) (<= (abs (- x (* result
> result))) 0.0001))
>  (curry raise-result-error 'real-sqrt
> "result * result = x (to within error)")))])])
>   (sqrt x))
>
>
> Thinking more about the functional context, a macro — say (define/pre-post
> ...) that cleanly defined the following functions would be pretty sweet
> (continuing with the real-sqrt example):
>
>- real-sqrt-unsafe
>- real-sqrt-with-pre-conditions
>- real-sqrt-with-pre-and-post-conditions
>- real-sqrt (make-parameter one-of-the above)
>
>
> Rather than mint new identifiers, one could also export the function via
> multiple submodules, each of which has a different level of contracting.
> The advantage is that the "safety level" 1) can be adjusted by the caller,
> 2) without having to change the name of the identifier in the code. Again,
> this could all be automated through a macro:
>
> (begin
>   (define (real-sqrt x)
>  ;; no contract)
>   (provide real-sqrt)
>
>   (module+ precheck
> (provide (contract-out [real-sqrt precheck-contract ···])))
>
>   (module+ allchecks
> (provide (contract-out [real-sqrt allcheck-contract ···])))
> )
>
> And so on.
>
>
>
> --
> 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 

Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Daniel Prager]

Thanks Matthew

That's very helpful. I definitely want to hook into the existing contract
system if possible, and you've given some good pointers to how this might
be done.

I kind of expected that it would be possible to do what I wanted with
"indy" contracts, but struggled with the heavy use of combinators in the
examples.

Your example is illuminating: I'll have a play with it and see if I can
figure out a suitable macro to reduce the boilerplate.

The use of module+ approach is good motivation to get more familiar with
the module system: back to Beautiful Racket for a refresher!

* * *

Thinking more about it, it also makes sense to reify contracts to allow
them to clip onto alternative implementations.

I'll come back later with some more code (unless someone beats me to it ;-).

* * *

I'm also interested in whether more people would use contracts routinely if
they were made a bit more accessible in terms of ease-of-use and making it
easy to turn them on and off.

When I used and advocated them first in the late 90s my colleagues thought
it was all too "bondage and discipline" so I went it alone.

When I was tech lead in naughties I corralled one team into using them to
good effect, but it required a degree of leadership and personal support.

Now, with the more widespread acceptance of unit tests and TDD, I wonder
whether they might be an easier "sell".


Dan



On Wed, May 3, 2017 at 12:22 PM, Matthew Butterick  wrote:

>
> On May 2, 2017, at 4:33 PM, Daniel Prager 
> wrote:
>
> (define/pre-post (real-sqrt x)
>   #:pre ([(real? x) "real argument expected"]
>  [(>= x 0) "non-negative argument expected"])
>
>   #:implementation (sqrt x)
>
>   #:post ([(implies (= x 0) (= result 0)) "The sqrt of zero should be
> zero"]
>   [(implies (> x 0) (> result 0)) "Positive numbers have positive
> square-roots"]
>   [(implies (> x 0) (<= (abs (- x (* result result))) 0.001))
>"result * result = x (to within error)"]))
>
>
>
> It sounds like you want alternate notation for stuff the contract system
> can already do.
>
> AFAICT the function below is equivalent to your function above. One could
> create a macro to go from one to the other:
>
>
> (define/contract (real-sqrt x)
>   (([x (and/c
> (or/c (λ (x) (real? x))
>   (curry raise-argument-error 'real-sqrt "real argument
> expected"))
> (or/c (λ (x) (>= x 0))
>   (curry raise-argument-error 'real-sqrt "non-negative
> argument expected")))])
>. ->i .
>[result (x)
>(cond
>  [(= x 0) (or/c (λ (result) (= result 0))
> (curry raise-result-error 'real-sqrt "sqrt of
> zero should be zero"))]
>  [(> x 0) (and/c
>  (or/c (λ (result) (> result 0))
>(curry raise-result-error 'real-sqrt
> "sqrt of positive number should be positive"))
>  (or/c (λ (result) (<= (abs (- x (* result
> result))) 0.0001))
>  (curry raise-result-error 'real-sqrt
> "result * result = x (to within error)")))])])
>   (sqrt x))
>
>
> Thinking more about the functional context, a macro — say (define/pre-post
> ...) that cleanly defined the following functions would be pretty sweet
> (continuing with the real-sqrt example):
>
>- real-sqrt-unsafe
>- real-sqrt-with-pre-conditions
>- real-sqrt-with-pre-and-post-conditions
>- real-sqrt (make-parameter one-of-the above)
>
>
> Rather than mint new identifiers, one could also export the function via
> multiple submodules, each of which has a different level of contracting.
> The advantage is that the "safety level" 1) can be adjusted by the caller,
> 2) without having to change the name of the identifier in the code. Again,
> this could all be automated through a macro:
>
> (begin
>   (define (real-sqrt x)
>  ;; no contract)
>   (provide real-sqrt)
>
>   (module+ precheck
> (provide (contract-out [real-sqrt precheck-contract ···])))
>
>   (module+ allchecks
> (provide (contract-out [real-sqrt allcheck-contract ···])))
> )
>
> And so on.
>
>

-- 
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] Apropos contracts: simple predicates and switching on and off

[Matthew Butterick]

> On May 2, 2017, at 4:33 PM, Daniel Prager  wrote:
> 
> (define/pre-post (real-sqrt x)
>   #:pre ([(real? x) "real argument expected"]
>  [(>= x 0) "non-negative argument expected"])
> 
>   #:implementation (sqrt x)
> 
>   #:post ([(implies (= x 0) (= result 0)) "The sqrt of zero should be zero"]
>   [(implies (> x 0) (> result 0)) "Positive numbers have positive 
> square-roots"]
>   [(implies (> x 0) (<= (abs (- x (* result result))) 0.001))
>"result * result = x (to within error)"]))


It sounds like you want alternate notation for stuff the contract system can 
already do. 

AFAICT the function below is equivalent to your function above. One could 
create a macro to go from one to the other:


(define/contract (real-sqrt x)
  (([x (and/c
(or/c (λ (x) (real? x))
  (curry raise-argument-error 'real-sqrt "real argument expected"))
(or/c (λ (x) (>= x 0))
  (curry raise-argument-error 'real-sqrt "non-negative argument 
expected")))])
   . ->i .
   [result (x)
   (cond
 [(= x 0) (or/c (λ (result) (= result 0))
(curry raise-result-error 'real-sqrt "sqrt of zero 
should be zero"))]
 [(> x 0) (and/c
 (or/c (λ (result) (> result 0))
   (curry raise-result-error 'real-sqrt "sqrt 
of positive number should be positive"))
 (or/c (λ (result) (<= (abs (- x (* result 
result))) 0.0001))
 (curry raise-result-error 'real-sqrt 
"result * result = x (to within error)")))])])
  (sqrt x))


> Thinking more about the functional context, a macro — say (define/pre-post 
> ...) that cleanly defined the following functions would be pretty sweet 
> (continuing with the real-sqrt example):
> real-sqrt-unsafe
> real-sqrt-with-pre-conditions
> real-sqrt-with-pre-and-post-conditions
> real-sqrt (make-parameter one-of-the above)

Rather than mint new identifiers, one could also export the function via 
multiple submodules, each of which has a different level of contracting. The 
advantage is that the "safety level" 1) can be adjusted by the caller, 2) 
without having to change the name of the identifier in the code. Again, this 
could all be automated through a macro:

(begin
  (define (real-sqrt x)
 ;; no contract)
  (provide real-sqrt)

  (module+ precheck
(provide (contract-out [real-sqrt precheck-contract ···])))

  (module+ allchecks
(provide (contract-out [real-sqrt allcheck-contract ···])))
)

And so on.



-- 
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: Apropos contracts: simple predicates and switching on and off

[Daniel Prager]

Thinking more about the functional context, a macro — say (define/pre-post
...) that cleanly defined the following functions would be pretty sweet
(continuing with the real-sqrt example):

   - real-sqrt-unsafe
   - real-sqrt-with-pre-conditions
   - real-sqrt-with-pre-and-post-conditions
   - real-sqrt (make-parameter one-of-the above)

and of course plugging into the contract system.

Example sketch of use and expansion below ...

Dan



*Example ...*

(define/pre-post (real-sqrt x)
  #:pre ([(real? x) "real argument expected"]
 [(>= x 0) "non-negative argument expected"])

  #:implementation (sqrt x)

  #:post ([(implies (= x 0) (= result 0)) "The sqrt of zero should be zero"]
  [(implies (> x 0) (> result 0)) "Positive numbers have positive
square-roots"]
  [(implies (> x 0) (<= (abs (- x (* result result))) 0.001))
   "result * result = x (to within error)"]))


*Expansion (not yet using the contract system): *

(define (real-sqrt-unsafe x)
  (sqrt x))


(define (real-sqrt-with-pre-conditions x)
  (pre [(real? x) "real argument expected"]
   [(>= x 0) "non-negative argument expected"])

  (real-sqrt-unsafe x))


(define (real-sqrt-with-pre-and-post-conditions x)
  (define result (real-sqrt-with-pre-conditions x))

  (post [(implies (= x 0) (= result 0)) "The sqrt of zero should be zero"]
[(implies (> x 0) (> result 0)) "Positive numbers have positive
square-roots"]
[(implies (> x 0) (<= (abs (- x (* result result))) 0.001))
 "result * result = x (to within error)"])
  result)


(define real-sqrt (make-parameter real-sqrt-with-pre-and-post-conditions))

-- 
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] Apropos contracts: simple predicates and switching on and off

[Daniel Prager]

My concept of how (simple) contracts should work was influenced by the
Bertrand Meyer /  Eiffel approach and spent many years of rolling my own
contracts in lesser languages to mimic this.

The main things I found pragmatically useful were:

   1. Being able to specify pre-conditions and post-conditions as simple
   predicates
   2. Being able to selectively turn off contracts (typically
   post-conditions) in well-tested code for performance.

With very simple hand-rolled assertions (plus some design discipline) I
reckon I achieved 80% pf the promise of contracts, with my debugging time
plunging by a factor of 10, and much cleaner designs.

When I finally programmed in Eiffel there were several added benefits of
language support that I appreciated:

   - More concise and clear expression of contracts
   - The implies operator
   - Proper support for invariant-checking
   - Proper support for covariant inheritance
   - Tools for automatically generating documentation
   - Better tools for turning off contracts by configuration

But I was only able to get to use Eiffel in one organisational setting —
quite a big negative!

* * *

Coming across to Racket I was thrilled to see that contracts are a big part
of the system, but they are certainly a bit different to what I was used to!

I'd like to share a sketch of how I would start to hand-roll the kind of
contracts I was used to in Racket.

My questions are:

   - Is it feasible to get similar behaviour from the official contract
   system?, or
   - Do these considerations call for building up an alternative system?


Restating my goals:

   1. Specify pre-conditions and post-conditions as simple predicates
   (boolean expressions)
   2. Selectively turn off contracts (mainly post-conditions) for
   performance in well-tested code.

Example: real square root function, and sketch of support below.

Now, I appreciate that the Racket contract system provides all sorts of
support for higher-level functional programming, but it concerns me that as
a big fan of contracts I've been reluctant to use them consistently in
Racket.

I hope to change that in my second decade of Racket (formerly PLT Scheme)
use, but may need some support and guidance!

Dan



#lang racket

(define pre-conditions-on #t)
(define post-conditions-on #t)

(define (implies a b)
  (or (not a) b))

(define-syntax-rule (pre [test? msg] ...)
  (unless (not pre-conditions-on)
(unless test?
  (error (~a "Pre-condition violation: " msg))) ...))

(define-syntax-rule (post [test? msg] ...)
  (unless (not post-conditions-on)
(unless test?
  (error (~a "Post-condition violation: " msg))) ...))

(define (real-sqrt x)
  (pre [(real? x) "real argument expected"]
   [(>= x 0) "non-negative argument expected"])

  (define result (sqrt x))
  ; Change the implementation to 1, 0, (- x) to trigger various
post-condition errors

  (post [(implies (= x 0) (= result 0)) "The sqrt of zero should be zero"]
[(implies (> x 0) (> result 0)) "Positive numbers have positive
square-roots"]
[(implies (> x 0) (<= (abs (- x (* result result))) 0.001))
 "result * result = x (to within error)"])
  result)


(real-sqrt 0)
(real-sqrt 9)
(real-sqrt -9) ; Pre-condition error

-- 
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 6.9

[George Neuner]

On Mon, 1 May 2017 15:37:49 -0400, James
 wrote:

>I've been systematically looking at different Linux GUI environments,
>on and off, for a while now.  I currently use macOS on both my
>desktop and laptop but have Linux and Windows virtual machines.
>I might switch to Linux for the host OS at some point.  The thing
>I am finding to be lacking in all the Linux GUIs I've tried so far
>is, surprisingly, some basic usability issues.

The GUI situation with Linux can be confounding to newcomers.  There
are too many choices, and those choices - in general - just aren't as
good as Mac or Windows users have come to expect.

I have yet to see anything on Linux that I would consider close to the
experience of OpenWindows/Motif on Solaris, or to DecWindows on Ultrix
... nevermind Macintosh or Windows.

I haven't much experience with the Unix Macintoshes, but I developed
applications for the old [toolbox] MacOS, and I do remember how it
worked.


>It's things like
>target areas for the mouse that are too small.  For example, I have
>to go back and forth a few times to get the mouse on the right spot
>to resize a window. 

These types of things *usually* are settable.  Unfortunately, the way
is not alway intuitive - e.g., the click area may be in the
preferences for the window manager rather than with the preferences
for the mouse.


>There is often a lack of feedback.  For example,
>you click to run and application and nothing happens.  You don't
>know whether it errored out immediately or it's just being slow to
>start up. 

This is a [near] universal issue with Linux and Unix GUIs.

E.g., on Windows, the "wait" cursor is displayed unconditionally *by
the operating system* for several seconds while launching a new
process - until a timeout occurs or the new process creates its own
window.  While this is going on, the cursor remains in wait style even
if the mouse passes over the window of an open application.

Old MacOS had a similar feature.

But in Linux, the GUI is not at all integrated with the OS.  The
desktop manager (shell) can display a wait cursor while it starts a
new process, but the manager can only control the cursor over *its*
own space.  If the mouse passes over an open application window, it
becomes the property of that application.  

This is a limitation of the window manager library [or maybe how it is
used] rather than a limitation of Linux per se ... but it is there
nontheless.

The desktop manager also is limited because Linux does not provide the
same variety of system event hooks to monitor, and the windows
managers are (somewhat) more constrained by the system security model.
WRT Windows, it isn't as easy for a Linux desktop manager to determine
when (or if) a new windowing application is ready.


>There tend to be a lack of keyboard shortcuts (compared
>to the Mac.)  What would really be nice is keyboard shortcuts that
>don't conflict with the terminal.  So you can, for example, use
> keyboard shortcuts to cut and paste between the terminal and the
>GUI.  Too often, things just don't work and stay that way too long.

Linux is open source: things that are broken [by some definition] stay
broken until someone gets fed up and fixes them.


>For example, in Ubuntu 12 to 14, and possibly even more recently 
>(I left Ubuntu after 14), TCP/IP would not work if you set it up 
>in the GUI.  You had to use the command line.  

I haven't used Ubuntu for quite a while - much of my recent work has
been on CentOS.   I did have trouble with (removeable) PCMCIA WiFi
adapters in Ubuntu 12, but that was a driver issue ... I don't recall
any particular problems with setup.

George

-- 
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] Speeding up graphics / moving away from 2htdp/image

[WarGrey Gyoudmon Ju]

On Tue, May 2, 2017 at 8:02 PM, Daniel Prager 
wrote:

> Hi Ju
>
> Interesting results. Did you run the Contract Profiler tool? [
> http://docs.racket-lang.org/contract-profile/]
>
> I think it's fairly well understood that the contract-induced performance
> costs across the typed / untyped boundary can be severe.
>

No, I didn't run the Contract Profiler tool.

I just wanted to optimize it, the weirdest thing I found is, the total time
is much larger then the sum of the in-function `time`s, I guess all bitmaps
are checked one by one by the contract system, they are all objects.

Last time I mentioned the flomap, I said "You need to convert the flomap
struct into a bitmap% instance when drawing", the main reason is that
nobody seems to maintain the images-lib, and it's Bitmap% is not the
standard one since it exists before typed class is available, therefore the
`flomap->bitmap` will simply fail due to the contract error. There is a
pull request for it, but still has not been merged since 2015. [
https://github.com/racket/images/pull/2]



> BTW: At the back of my mind is the thought that the performance one could
> achieve on these kinds of benchmarks would go up ridiculously by pushing
> the work to a GPU.
>

Yeah, some games shipped with the main distribution are written in
racket-wrapped OpenGL. Despite the totally different APIs, you can try real
time rendering algorithms without worrying about the performance. In fact,
I am hesitating too, I have already finished the computational model of the
CSS engine, but not sure whether the GUI part should be implemented with
OpenGL or not. Designing application as a Game UI developer is fun, but
meanwhile I do not have much time to do that.

-- 
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] Self evaluating Racket Interpreter

[Matthias Felleisen]

> On May 2, 2017, at 12:01 AM, circularba...@gmail.com wrote:
> 
> I am somewhat reluctant to use structures as I want to keep the interpreter 
> as minimal as possible. Also, I'm not familiar enough with the semantics of 
> frames to implement it in interpreter.rkt.
> 
> With regards to mcons being different from cons, Oscar Lopez has suggested 
> that in stackoverflow. So, I re-implemented the interpreter in r5rs so that 
> set-car! and set-cdr! are available and I wouldn't need to use mcons. I've 
> attached the files here.
> 
> I still got an error
>; application: not a procedure;
>;  expected a procedure that can be applied to arguments
>;   given: (mcons 'expr (mcons 'env))
>;   arguments...: [none]
> 
> It looks like it still has something to do with mcons.


Not at all. I could just gibe you the answer (and tell you the fix, code 
unseen) but that would mean I don’t teach you how to fish, which is really what 
you need to learn. In this spirit, 


PLEASE READ THE ERROR MESSAGE. [caps intentional to draw attention] 

If you can’t figure it out from there, can you please help us improve it? 
Thanks. 







> I suspect that this might have something to do with Racket's implementation 
> of r5rs? Again, this might be completely wrong but I don't know how to 
> determine the cause. 
> 
> -- 
> 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] Readtable extensions and syntax coloring in DrRacket

[brendan]

Hi Andrew. Thanks, I do know about the here string syntax, and it's part of why 
I'm not willing to put much effort into fixing the lexer. :)

William, udelim is neat and may be useful for me, so thanks for mentioning it.

On Monday, May 1, 2017 at 6:48:12 PM UTC-4, Andrew Gwozdziewycz wrote:
> Hi Brendan,
> 
> I'm wondering if you tried the here string syntax for your use case,
> which other than the fact that it requires a couple of newlines seems
> similar in vein to what you were going for (e.g. it doesn't escape
> anything)?

-- 
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] Speeding up graphics / moving away from 2htdp/image

[Daniel Prager]

Hi Ju

Interesting results. Did you run the Contract Profiler tool? [
http://docs.racket-lang.org/contract-profile/]

I think it's fairly well understood that the contract-induced performance
costs across the typed / untyped boundary can be severe.

BTW: At the back of my mind is the thought that the performance one could
achieve on these kinds of benchmarks would go up ridiculously by pushing
the work to a GPU.

Dan


On Tue, May 2, 2017 at 8:06 PM, WarGrey Gyoudmon Ju 
wrote:

> Hello, I found an interesting thing.
>
> My conclusion was totally wrong since your example are written in Untyped
> Racket, the generated contracts eat all the seconds unconsciously.
>
> Timing your example in Typed Racket with my functional bitmap combiners:
>
> no optimizing, generating all 2500 bitmaps on the fly:
> bitmap-*-append...
> cpu time: 386 real time: 387 gc time: 20
> bitmap-table...
> cpu time: 381 real time: 381 gc time: 10
>
> with memorizing (only 2 distinguishable bitmaps are generated):
> bitmap-*-append...
> cpu time: 85 real time: 85 gc time: 0
> bitmap-table...
> cpu time: 93 real time: 94 gc time: 23
>
> Still slower than pict, but as a raster graphics API, it does a great job!
>
>

-- 
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] Re: Racket 6.9

[James]

I've been systematically looking at different Linux GUI environments, on and 
off, for a while now.  I currently use macOS on both my desktop and laptop but 
have Linux and Windows virtual machines.  I might switch to Linux for the host 
OS at some point.  The thing I am finding to be lacking in all the Linux GUIs 
I've tried so far is, surprisingly, some basic usability issues.  It's things 
like target areas for the mouse that are too small.  For example, I have to go 
back and forth a few times to get the mouse on the right spot to resize a 
window.  There is often a lack of feedback.  For example, you click to run and 
application and nothing happens.  You don't know whether it errored out 
immediately or it's just being slow to start up. There tend to be a lack of 
keyboard shortcuts (compared to the Mac.)  What would really be nice is 
keyboard shortcuts that don't conflict with the terminal.  So you can, for 
example, use keyboard shortcuts to cut and paste between the terminal and the 
GUI.  Too often, things just don't work and stay that way too long.  For 
example, in Ubuntu 12 to 14, and possibly even more recently (I left Ubuntu 
after 14), TCP/IP would not work if you set it up in the GUI.  You had to use 
the command line.  

James

-- 
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] Speeding up graphics / moving away from 2htdp/image

[WarGrey Gyoudmon Ju]

Hello, I found an interesting thing.

My conclusion was totally wrong since your example are written in Untyped
Racket, the generated contracts eat all the seconds unconsciously.

Timing your example in Typed Racket with my functional bitmap combiners:

no optimizing, generating all 2500 bitmaps on the fly:
bitmap-*-append...
cpu time: 386 real time: 387 gc time: 20
bitmap-table...
cpu time: 381 real time: 381 gc time: 10

with memorizing (only 2 distinguishable bitmaps are generated):
bitmap-*-append...
cpu time: 85 real time: 85 gc time: 0
bitmap-table...
cpu time: 93 real time: 94 gc time: 23

Still slower than pict, but as a raster graphics API, it does a great job!

On Sat, Apr 29, 2017 at 11:19 AM, WarGrey Gyoudmon Ju  wrote:

>
>
> On Sat, Apr 29, 2017 at 5:21 AM, Daniel Prager 
> wrote:
>
>> On Sat, Apr 29, 2017 at 2:10 AM, WarGrey Gyoudmon Ju <
>> juzhenli...@gmail.com> wrote:
>>
>>> Hello, I think the main reason that pict is faster than 2htdp/image is,
>>> the pict is implemented with struct while the 2htdp/image is implemented
>>> with class, the speed of rendering is just as fast/slow as each other, but
>>> manipulation on class is much heavier than on struct when combining large
>>> numbers of shapes. Maybe you want to check the code of `table` in pict-lib,
>>> it is a good example to place shapes into grids in a functional way.
>>>
>>
>> Interesting. I'd also note that unlike pict 2htdp/image doesn't provide a
>> way to draw direct to dc, necessitating going via bitmaps when using it in
>> conjunction with racket/gui.
>>
>
> Actually, this is not the case, every 2htdp/image shape is a subclass of
> snip%(see the `draw` method of snip%), though you have to compute another 9
> arguments...
>
> I remembered some points that old conversations had suggested:
> 1. 2htdp/image is not efficient enough for building real world gui
> application, racket/draw should be used instead.
> 2. When drawing large amount of shapes, the cost of getting into and out
> the drawing context is critical.
> 3. typed racket is helpful even for real time rendering, say, perlin
> noise, almost as fast as java, (but I did not see the direct link between
> your work and real time rendering.)
>
> Good luck 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.