[racket-users] Test

Test please ignore https://github.com/racket/racket-lang-org/issues/154 https://github.com/racket/racket/wiki/Mailing-Lists Kind Regards Stephen De Gabrielle This message

[racket-users] Test message sent to racket-users@googlegroups.com

Please ignore, thanks. -- 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. To view this discussion on the web visit

Re: [racket-users] test user-interact function dont work

WOW. I finish read the doc about #:final That is so beatiful thing. Thank you to you three Em dom, 17 de fev de 2019 às 22:18, Joao Pedro Abreu De Souza < jp_ab...@id.uff.br> escreveu: > Thanks for the feedback! > I will study this code and make more functional > > Em dom, 17 de fev de 2019

Re: [racket-users] test user-interact function dont work

Thanks for the feedback! I will study this code and make more functional Em dom, 17 de fev de 2019 22:13, Philip McGrath Well, if you call `(exit 0)`, your Racket program really will exit with > code 0 without doing anything else: the function `exit` never returns, so, > in your case, `execute`

Re: [racket-users] test user-interact function dont work

Well, if you call `(exit 0)`, your Racket program really will exit with code 0 without doing anything else: the function `exit` never returns, so, in your case, `execute` never returns, `refine-main` never returns, and Rackunit never gets a chance to look at any output it may or may not have

Re: [racket-users] test user-interact function dont work

Thanks a lot. Sorry about the simple error. Em dom, 17 de fev de 2019 22:06, Matthias Felleisen > > On Feb 17, 2019, at 6:44 PM, Joao Pedro Abreu De Souza > wrote: > > (check-equal? > (with-output-to-string >(lambda () > (with-input-from-string "input" >(lambda () >

Re: [racket-users] test user-interact function dont work

> On Feb 17, 2019, at 6:44 PM, Joao Pedro Abreu De Souza > wrote: > > (check-equal? > (with-output-to-string >(lambda () > (with-input-from-string "input" >(lambda () > (refine-main) Your mistake is in the above line. You want to write refine-main not

Re: [racket-users] test user-interact function dont work

(define (refine-main) (display next-string) ;;feito (set! next-command (shell-parser (my-read-line))) ;;TODO my-read-line (execute next-command) ;;TODO execute (refine-main)) ;;feito This is refine-main "shell-parser" is just a PEG-based parser, that return a

Re: [racket-users] test user-interact function dont work

Well, there's no imediate return, i need to type exit 0 to finally the test works I am using read-line to read input. Today later I will post more code(of refine-main). Thanks Em dom, 17 de fev de 2019 10:37, Greg Hendershott What does it do? Does `check-equal?` show a failure message? If so,

Re: [racket-users] test user-interact function dont work

What does it do? Does `check-equal?` show a failure message? If so, what does it say? I don't know what `refine-main` does, but this simple version works for me: #lang racket (require rackunit) (define (refine-main) (display (read-line))) ;echo (check-equal? (with-output-to-string

[racket-users] test user-interact function dont work

Hi everyone. I have a test of a user-related function that I don't can see why don't work : #lang racket (require rackunit) (require "../../main.rkt") (check-equal? (with-output-to-string (lambda () (with-input-from-string

[racket-users] test suite for hygienic expander?

Is there a test suite for the macro expander? I assume that you must have one, but it would save me some effort if somebody can tell me where it is. I'm interested in finding out if you have good corner cases for testing a proposal for a hygienic expander. --Mitch -- You received this

Re: [racket-users] "Test did not clean up resources" message from GUI test runner

On Tuesday, August 22, 2017 at 12:53:20 AM UTC+8, Ryan Culpepper wrote: > On 08/20/2017 09:28 PM, Alex Harsanyi wrote: > > I just noticed that the GUI test runner displays "test did not clean up > > resources" messages on my tests, but it is not clear to me what resources > > are not being

Re: [racket-users] "Test did not clean up resources" message from GUI test runner

On 08/20/2017 09:28 PM, Alex Harsanyi wrote: I just noticed that the GUI test runner displays "test did not clean up resources" messages on my tests, but it is not clear to me what resources are not being cleaned up. I tried to reproduce the problem in the following test case: #lang

[racket-users] "Test did not clean up resources" message from GUI test runner

I just noticed that the GUI test runner displays "test did not clean up resources" messages on my tests, but it is not clear to me what resources are not being cleaned up. I tried to reproduce the problem in the following test case: #lang racket (require rackunit rackunit/gui db)

[racket-users] Test message - please ignore

Sorry for the burned electrons; my co-founder has been having some trouble sending to the list and I'm wondering if it's a general issue. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails

[racket-users] Test request

Hey guys I'm proving this app and I will be grateful if can help me with new ideas or evaluate it. I create a serie of videos that show your functions and objetive. Exist a survey that you can respond, it is in http://goo.gl/forms/jsNIgRvdr8 together with the videos. Not is problem if you

RE: [racket-users] test amazes me

:3). Jos _ From: Matthias Felleisen [mailto:matth...@ccs.neu.edu] Sent: lunes, 25 de mayo de 2015 3:37 To: Alexander D. Knauth Cc: Jos Koot; Racket-Users List Subject: Re: [racket-users] test amazes me I didn't implement test-engine but worked with Kathy to design and occasionally add

Re: [racket-users] test amazes me

At Mon, 25 May 2015 08:03:22 +0200, Jos Koot wrote: Now I am looking into rackunit and (planet schematics/schemeunit:3). I believe the former is a descendant of the latter, so you're probably better off sticking to Rackunit. Vincent -- You received this message because you are subscribed to

Re: [racket-users] test amazes me

Look at what this does: #lang racket (require test-engine/racket-tests) (check-expect 1 1) (check-expect 2 2) (check-expect 3 3) (check-expect (displayln hello) (displayln world)) (test) (test) Welcome to DrRacket, version 6.2.0.3--2015-05-17(542b960/a) [3m]. Language: racket [custom]; memory

[racket-users] test amazes me

#lang racket (module a racket (require test-engine/racket-tests) (check-expect 1 1) (test)) (module b racket (require test-engine/racket-tests) (check-expect 2 2) (test)) (require 'a 'b) This gives me: Welcome to DrRacket, version 6.2.900.3--2015-05-16(e8b52f6/a) [3m]. Language:

Re: [racket-users] test amazes me

I didn't implement test-engine but worked with Kathy to design and occasionally add features and/or maintain it. As you may know, in *SL the test-engine library runs (test) automatically when a programmer runs a program. That works out perfectly. I never imagined this library used for plain

Re: [racket-users] test submodules vs tests in separate file

And apologies for this completely wrong remark! On Fri, May 22, 2015 at 7:19 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Contracts mediate boundaries between parts of your program and sometimes tests should go across the boundary (to help test the contracts) and sometimes they should

Re: [racket-users] test submodules vs tests in separate file

; #lang racket (define/contract (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add2 (integer? integer? . - . integer?)])) (define (add2 x y) (+ x y)) (module+ test (require rackunit) (check-exn exn:fail? (λ _ (add1 20.5 21.5)))

Re: [racket-users] test submodules vs tests in separate file

For that kind of situation, you should consider writing your test submodule like this: #lang racket (define (add1 x y) (integer? integer? . - . integer?) (+ x y)) (provide (contract-out [add1 (integer? integer? . - . integer?)])) (module* test racket (require (submod ..)) (add1 #f #f))

Re: [racket-users] test submodules vs tests in separate file

Yes, there is : http://docs.racket-lang.org/style/Units_of_Code.html?q=define%2Fcontract#%28part._.Contracts%29 Thank you for the link. The How to Program Racket Guide will be really helpful. But I must admit I'm a little confused. Looking at the *fahrenheit* example in the Guide: #lang

Re: [racket-users] test submodules vs tests in separate file

That's good to know. That means my previous conclusion is wrong and I'm not forced to use define/contract when using test submodules. Robby Findler ro...@eecs.northwestern.edu writes: For that kind of situation, you should consider writing your test submodule like this: #lang racket

Re: [racket-users] test submodules vs tests in separate file

Contracts mediate boundaries between parts of your program and sometimes tests should go across the boundary (to help test the contracts) and sometimes they should go inside (to test internal functions). You have to pick one or the other with a given test module tho. Robby On Friday, May 22,

Re: [racket-users] test submodules vs tests in separate file

On Fri, May 22, 2015 at 5:41 PM, Atticus attic...@posteo.org wrote: Imho it would be nice if there was a small hint in the documentation about that case, perhaps there is and I didn't see it? Yes, there is :

Re: [racket-users] test submodules vs tests in separate file

Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. -- Anthony Carrico -- 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,

Re: [racket-users] test submodules vs tests in separate file

You could always do something like (require (prefix-in contracted: (submod ..))) to get separate bindings for the versions contracted by contract-out. On May 22, 2015, at 11:37, Anthony Carrico acarr...@memebeam.org wrote: Has this been an oversight? Do we need two official test submodules?

Re: [racket-users] test submodules vs tests in separate file

Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. That’s a worthy point. I prefer to locate tests as close as possible to the code being tested. But the fact that 'raco test ...' and DrRacket only recognize a single submodule named

Re: [racket-users] test submodules vs tests in separate file

If you want to have the contracts enforced in the test submodule, all you have to do is add (require (submod “..”)) to the submodule. You don’t need to use define/contract, and you don’t need to use module* instead of module+. You can just use #lang racket (provide (contract-out ; convert

Re: [racket-users] test submodules vs tests in separate file

DOn't forget $ raco test --submoulde matthew-s-tests On May 22, 2015, at 3:12 PM, Matthew Butterick m...@mbtype.com wrote: Has this been an oversight? Do we need two official test submodules? One from the inside, and one from without. That’s a worthy point. I prefer to locate tests as

Re: [racket-users] test submodules vs tests in separate file

On May 22, 2015, at 8:19 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Contracts mediate boundaries between parts of your program and sometimes tests should go across the boundary (to help test the contracts) and sometimes they should go inside (to test internal functions). You have

Re: [racket-users] test submodules vs tests in separate file

Adding to the suggestions, you can write something like `test-internal` and `test-external` submodules plus (module+ test (require (submod .. test-internal) (submod .. test-external))) At Fri, 22 May 2015 15:23:33 -0400, Matthias Felleisen wrote: DOn't forget $ raco test

Re: [racket-users] test submodules vs tests in separate file

Adding to the suggestions, you can write something like `test-internal` and `test-external` submodules plus (module+ test (require (submod .. test-internal) (submod .. test-external))) Enlightenment achieved At Fri, 22 May 2015 15:23:33 -0400, Matthias Felleisen

Re: [racket-users] test submodules vs tests in separate file

I usually prefer test submodules because I like the proximity to the code being tested. Plus in Emacs racket-mode I can fold/hide the test submodules if they ever become distracting. Exceptions to usually: - Even with the ability to hide/fold tests, if the ratio of tests to tested is really

Re: [racket-users] test submodules vs tests in separate file

Three advantages of `test` submodules interspersed with the implementation code: * You're usually working on implementation and tests at the same time, and putting them adjacent in the same file is helpful (without fancy IDE support). * These tests constitute documentation for someone who

Re: [racket-users] test submodules vs tests in separate file

On 05/21/2015 08:44 AM, Neil Van Dyke wrote: Three advantages of `test` submodules interspersed with the implementation code: It is worth mentioning that submodules don't work well with typed racket yet, so TR tests are often in another file. -- Anthony Carrico -- You received this message

Re: [racket-users] test submodules vs tests in separate file

Great advice, thank you very much. Neil Van Dyke n...@neilvandyke.org writes: Three advantages of `test` submodules interspersed with the implementation code: * You're usually working on implementation and tests at the same time, and putting them adjacent in the same file is helpful

Re: [racket-users] test submodules vs tests in separate file

I usually prefer test submodules because I like the proximity to the code being tested. Plus in Emacs racket-mode I can fold/hide the test submodules if they ever become distracting. Nice feature. Btw thank you for making racket-mode :) Exceptions to usually: - Even with the ability to

[racket-users] test submodules vs tests in separate file

Hello, What is the recommended way to add tests in racket? I was looking through the racket documentation and there are two options for adding tests, using test submodules or using a separate file for tests (rackunit documentation). Some authors seem to prefer one over the other for example

Re: [racket-users] test submodules vs tests in separate file

Startup will be fastest if you `raco make` the foo.rkt file to a compiled/foo.zo bytecode file. When you `racket foo.rkt` (directly or via #!) it will load the compiled/foo.zo provided it's not older. Not compiled/foo.zo; it would be compiled/foo_rkt.zo. -- You received this message because

Re: [racket-users] test submodules vs tests in separate file

(Otherwise the .rkt file must be parsed and expanded each/every time you run. This includes test submodules, even though they won't be run. In addition, expansion time can be significant with non-trivial macros, including but not limited to Typed Racket.) Very interesting, this reduced the

Re: [racket-users] test submodules vs tests in separate file

Three advantages of `test` submodules interspersed with the implementation code: Here's a fourth: no need for tricks like require/expose to sneak around interfaces. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this

Re: [racket-users] test submodules vs tests in separate file

I thought that the compilded code would have fewer debugging information (source code location etc) or not able to use the stepper. I have not used the stepper in racket yet (but the stepper in gambit scheme which is really useful at least for a beginner like me). Oh I see what you mean. No,

Re: [racket-users] test submodules vs tests in separate file

Are there any advantages/disadvantages of using test submodules vs separate test files? Or is it just a matter of personal preference? It looks like that test submodules are more convenient and flexible but I observed that test submodules increase the start up time of racket scripts. If

Re: [racket-users] test submodules vs tests in separate file

Do you mean the case where you update your .rkt but don't re-make, so that the .zo is older? Racket will ignore the zo. As a result, although you lose the startup speed-up, you don't get any confusion from it running outdated code. I thought that the compilded code would have fewer debugging