s
> >>> not forget.
> >>>
> >>> Robby
> >>>
> >>> On Fri, Mar 20, 2015 at 3:41 PM, Alexis King
> wrote:
> >>>> This has been discussed before, and I think it’s a good idea, but I
> also think any such feature should be
It would be nice if we could have an unsafe version of require/typed, which
doesn't generate a contract, but simply "lies" to the type system about the
type. This, of course, breaks the type system's guarantees, and causes UB
if optimizations are one, but in some cases contracts cannot be generated
I'm pretty sure Racket is not much less scalable than Apache, which is
notoriously poor at scaling due to its fork-pool approach. I actually don't
know about it, but I see no architectural reason why the Racket HTTP server
would be much slower than, say, nginx - Racket threads after all are
schedul
I suppose this is a non-answer, but it shouldn't be hard at all to write a
"with-error-as-exception" form. I generally believe it's idiomatic to
extend the language whenever something inconvenient, or whenever a
boilerplate "design pattern", comes up.
On Fri, Mar 13, 2015 at 4:27 PM, Jack Firth w
I do not think it is possible. DrRacket is designed so that the interaction
window has the namespace of exactly the file you are writing. That is, what
you type in the interactions window should behave similarly to if you
appended it into the file. And running the file should have the same
behavior
I feel like swapping out flonums by default to rationals by default would
cause unexpected slowness in a large number of programs though. Would it be
possible to make it a reader extension like at-exp is currently? So I can
say "#lang exact-decimals racket", and the reader would read the decimals
a
It seems that bit-vectors have a really weird bug, where short bit-vectors
that aren't equal will often return true when tested with equal?.
Here's a trivial example: http://pasterack.org/pastes/35137
Is this a known bug? It shouldn't be hard to fix; the equality tester just
needs to, umm, do it
I would actually think that a good first step would be to port the Racket
VM, so that business logic can be run in Racket. GUI would be hard of
course, but I think that for the moment being able to run a background
process written in Racket would be "enough" for me, communicating with an
Android GU
Of course. But it's similar to having C++ programmers write in C. Having C
support for a device is not having "partial C++ support", and similarly I
think that having a R5RS-like system supported on Android/iOS is not having
"partial Racket support".
That being said, I'm actually quite curious why
I think this is really wrong. Of course, you can program in Racket in a
R5RS style, but it would hardly be idiomatic Racket. Most of my Racket code
is very hard to port to R5RS, due to using features like generics, the
match macro, and for/... loops. As another example, almost all of my
non-trivial
I've always felt that comparing with other systems like Chicken and Gambit
Scheme is counterproductive. Racket's compiler design is rather different
(although I'm not complimenting it: way too many things are written in C).
The ultimate goal of course would be to port the Racket VM to Android and
Yes, expanding to let* will indeed be better for the optimizer. The
optimizer, IIRC, currently uses a "You using set!? I give up" approach, and
if you ever mention set!-ing the variable, the compiler will then insert
typechecks every time the variable is used, slowing down things, and also
box anyt
Just as an aside, I'm slightly annoyed by the fact that educational uses of
Racket are so prevalent that people think Racket is a toy language to teach
people how to program. (Another pet peeve: the Racket in HtDP and similar
books is very unidiomatic and uses lots of deprecated forms).
I hope you
I ran raco distribute on a 64-bit Windows running 32-bit Racket 6.0,
then moved the resulting folder to another machine. But suddenly this
error appears in the console windows and the program refuses to run:
file-exists?: contract violation
expected: path-string?
given: #f
context...:
Could I chime in and suggest building with something like Debian stable
which has older, but not too old, libraries? Things built on Debian stable
should work on newer Linuxes.
On Sun, Mar 9, 2014 at 7:39 PM, Matthias Felleisen wrote:
>
> On Mar 5, 2014, at 4:03 PM, Junia Magellan wrote:
>
> I w
So if code is using first/rest instead of car/cdr when I already know the
lists are proper, it could incur a significant performance penalty? After
all, memoization still needs a table lookup each time I do a first/rest.
(i.e. implementing datastructures in terms of lists should use car/cdr for
pe
Forgive me if I am super terribly wrong. Isn't it the case that an improper
list is only known to be improper if we walk to the end and find something
other than an empty? So wouldn't that mean "first" and "rest" take linear
time since they must make sure the argument is a list? Clearly that doesn'
IDK though, Debian stable is very popular. I would suggest somebody should
build a package for it and upload it to racket-lang.org
On Tuesday, March 4, 2014, Matthew Flatt
>
wrote:
> At Mon, 3 Mar 2014 23:19:47 -0800, John Clements wrote:
> > I’d like to run racket 6 on a 64-bit Debian 7 VPS (tha
inefficiency with Racket on Windows
that could cause this massive slowdown?
On Thu, Feb 27, 2014 at 6:34 PM, Cristian Baboi wrote:
>
>
> On 28 februarie 2014 01:13:46 EET, Eric Dong wrote:
>
>> Windows shouldn't be much slower though. What CPU model do you have?
>> (2
This would be highly anomalous. Python is usually at least 10 times slower
than Racket for most tasks.
On Thu, Feb 27, 2014 at 10:49 AM, Cristian Baboi
wrote:
> În data de Thu, 27 Feb 2014 17:41:06 +0200, Neil Toronto <
> neil.toro...@gmail.com> a scris:
>
>
> On 02/27/2014 08:33 AM, Cristian B
Hi there,
My Racket GUI application needs to do a lot of cleanup work when exiting,
i.e. when the user presses the X button. Wrapping the .rkt in a shell
script which waits and then does the cleanup is a bit too hacky for me.
There are many exit handlers in the Racket documentation (exit-handler e
21 matches
Mail list logo
