>
> 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.
On 2015-05-21 07:15AM, Matthew Flatt wrote:
>I've been working on a new model of macros for Racket.
> http://www.cs.utah.edu/~mflatt/scope-sets-5/
Minor typo in the last paragraph of Section 1.1: "insprired".
Also, shouldn't the x's under syntax-rules and in the expansion of
(m) have a 'b' in t
DEADLINE EXTENDED: Submissions is now May 31st, 2015
Call For Papers:
Scheme and Functional Programming Workshop 2015
Vancouver, British Columbia, Canada
(Co-located with ICFP 2015)
http://andykeep.com/SchemeWorkshop2015/
> 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 g
> 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. N
There's also the much-older leftparen:
https://github.com/vegashacker/leftparen/
Sam
On Thu, May 21, 2015 at 9:44 PM, Asumu Takikawa wrote:
> On 2015-05-21 15:36:56 -0700, Vishesh Yadav wrote:
>> I'm working on racket web server to implement a basic web app. I found myself
>> doing lots of low l
On 2015-05-21 15:36:56 -0700, Vishesh Yadav wrote:
> I'm working on racket web server to implement a basic web app. I found myself
> doing lots of low level stuff like cookie handling, session management etc
> almost from scratch. I was thinking to abstract all these stuff into some
> small library
Thanks Jens
That looks great. I'll give MetaPict whirl!
Dan
On Fri, May 22, 2015 at 2:28 AM, Jens Axel Søgaard
wrote:
> Here is an example from MetaPict:
>
>
> http://soegaard.github.io/docs/metapict/metapict.html#%28def._%28%28lib._metapict%2Fpict..rkt%29._brushstipple%29%29
>
> The same effe
Hi!
I'm working on racket web server to implement a basic web app. I found myself
doing lots of low level stuff like cookie handling, session management etc
almost from scratch. I was thinking to abstract all these stuff into some small
library maybe, but before that I wanted to ask if there is
And maybe helpful for the original question: Including `(alt-tag
"div")` in the property list of your styles produces in the HTML
output instead of , which is more directly what you want
and avoids any default inset of .
At Thu, 21 May 2015 16:52:12 -0400, Shriram Krishnamurthi wrote:
> Of course
I'll revise the docs to clarify that the default style is up to the
target environment. For HTML output, `nested` corresponds to
, and that (usually?) insets its content by default. For
Latex output, `nested` corresponds to a plain list environment, which
doesn't inset.
At Thu, 21 May 2015 16:52:1
Of course it is. I can certainly hack my way around it using CSS. But
I'm wondering why the behavior doesn't match my reading of the docs:
did I misread, is the code broken, or are the docs broken? That's
really all I'm trying to figure out. (And if the code or docs are
wrong, then presumably someo
I don’t know if there’s a better more general solution, but does this do what
you want?
@(define exercise-style (make-style "exercise" (list (attributes '([style .
"margin-left: 0em"])
@(define question-style (make-style "question" (list (attributes '([style .
"margin-left: 0em"])
@(defi
Isn't it the whole point of styles to allow this kind of fixes? I am playing
with similar fixes for TeX output. Scribble is an UNCOL and all UNCOLs fail a
little bit at least -- Matthias
On May 21, 2015, at 2:19 PM, Shriram Krishnamurthi wrote:
> Understood. But my understanding of the doc
Yes, indeed. All those functions right there feel like they belong in
the generic pict library, not in the meta-pict layer on top.
Robby
On Thu, May 21, 2015 at 11:53 AM, Jens Axel Søgaard
wrote:
> Maybe there are other useful pict/brush modifiers of interest?
>
> https://github.com/soegaard/met
Understood. But my understanding of the docs is that it shouldn't do
that in the first place.
On Thu, May 21, 2015 at 2:15 PM, Ben Lerner wrote:
> Probably a CSS fix: assuming you have something like this in your CSS
> preamble
>
> div.question { padding-left: 2em; }
>
> to cause the indentation,
Probably a CSS fix:
assuming you have something like this in your CSS preamble
div.question { padding-left: 2em; }
to cause the
indentation, then something like this will disable the nested
one:
div.exercise > div.question { padding-left:
Thanks for these replies. Sorry I'm only now getting to them: Google failed to
notify me of them.
The problem with using (nested ...) is that it indents its content even when I
don't use the 'inset style. Therefore, if I have (as I do)
@exercise{@question{...}}
everything in the exercise ends
> 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 debuggi
Oh, nice! We should add brushstipple to pict itself.
Robby
On Thu, May 21, 2015 at 11:28 AM, Jens Axel Søgaard
wrote:
> Here is an example from MetaPict:
>
> http://soegaard.github.io/docs/metapict/metapict.html#%28def._%28%28lib._metapict%2Fpict..rkt%29._brushstipple%29%29
>
> The same effect c
Thanks to a pull request from Alexander Knauth, you can add a
RACKET_VERSION = SCOPE_SNAPSHOT to your .travis.yml build matrix:
https://github.com/greghendershott/travis-racket/blob/master/.travis.yml#L31
Also, as with RACKET_VERSION = HEAD, you can put this version into an
allowed failures lis
>> (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 redu
> 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 b
I've been working on a new model of macros for Racket. The new model
provides a simple account of scope, makes reasoning about macros
easier, and simplifies the implementation of the macro expander while
fixing bugs (e.g., submodules in Typed Racket).
You can read more about the model here:
htt
Great advice, thank you very much.
Neil Van Dyke 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 (without fancy IDE
>
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 messag
> 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
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 ha
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 lar
1. Thanks for figuring this out!
2. I'm pushing a commit to utilize this.
3. I wanted to link to your post in my commit message -- but I can't.
When I type this, your post isn't showing up in the Google Groups UI
for this thread --
https://groups.google.com/forum/#!topic/racket-users/ANgDaNplOBc
After some more research into the issue I have found the following description
which sounds familiar.
http://www.cocoabuilder.com/archive/cocoa/235068-nsapplication-appleevent-and-cfrunloop-source-strange-interaction.html
> It is working nicely, except for the quit sequencing. In Linux/GTK, the
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 pollen
Your answer is perfect. Thanks a lot! I sent you a private message already
to have some further discussion.
Mianlai
On Thu, May 21, 2015 at 12:43 PM, Alexander D. Knauth
wrote:
> Here’s one way to do something like that with a macro:
>
> https://github.com/AlexKnauth/define-match-spread-out/blo
33 matches
Mail list logo
