I've been working on a new macro expander for Racket, and I'm starting
to think that it will work. The new expander is not completely
compatible with the current expander --- and that will be an issue if
we eventually go forward with the change --- but most existing code
still works.
Here's a repo
At Tue, 17 Feb 2015 19:59:38 -0500, Sam Tobin-Hochstadt wrote:
> On Tue, Feb 17, 2015 at 6:41 PM, Matthew Flatt wrote:
> > At Tue, 17 Feb 2015 14:12:54 -0500, Sam Tobin-Hochstadt wrote:
> > Does another system have a Racket-like in-place option (that works
> > better)?
>
At Tue, 17 Feb 2015 14:12:54 -0500, Sam Tobin-Hochstadt wrote:
> Regardless of that, though, I think we should switch to updating only
> "main-distribution" (and perhaps "main-distribution-tests"). I doubt
> people expect `make` in the Racket source tree to update their
> software somewhere else on
Continuing in reverse order:
- My sense is that the switch to `make` so that it updates packages,
which was a result of
http://lists.racket-lang.org/users/archive/2015-January/065345.html
has been a good change for most people most of the time.
The `as-is` target is currently available for bui
It's good to know that canceling a filesystem-change event can be
expensive on Windows, in which case they probably shouldn't be used on
Windows when resolving module paths. I'll investigate more and remove
the use.
Meanwhile, there's not a good way to disable the current use in v6.1,
but the hack
y summary:
> > 45.1% pkgs/racket-doc/scribblings/raco/
> > 4.7% pkgs/racket-doc/scribblings/reference/
> > 47.5% racket/collects/compiler/
> >
> > ~~
> >
> > fe9a04d Matthew Flatt 2015-01-08 09:11
> > :
> > | d
Hi Jan,
Interesting problem!
I think I see what you mean: There's no way to combine the completion
of an event plus saving its value as an atomic operation, except by
putting the synchronization in its own thread. But if you put the
synchronization in its own thread, then there's no way to preven
At Thu, 29 Jan 2015 15:34:37 -0300, Gustavo Massaccesi wrote:
> If there are some easy technical details and advice, you can write a
> nice blog post about this.
Good idea. I have some advice on finalization (don't do it), and I
could write about how Racket tries to help when you can't follow that
At Wed, 28 Jan 2015 16:21:51 -0700, Byron Davies wrote:
> Your code, commented:
>
> (define orig-i (current-inspector)) ; saves the original inspector
> (define sub-i (make-inspector orig-i)) ;make a new inspector whose parent
> is the original inspector
>
> (current-inspector sub-i) ;makes th
Yes, it's a bug in v6.1.1. I've just pushed a repair for the next
build.
Do you need a workaround for v6.1.1? Your variant that sets
`sandbox-namespace-specs` is what I would have tried; unfortunately,
that runs into a second bug in v6.1.1 that I recently fixed. If you
need a workaround other than
At Wed, 21 Jan 2015 11:22:38 -0500, Tony Garnock-Jones wrote:
> Over the past few months, more and more subsystems have started logging
> at info level as part of regular compilation.
>
> I prefer having PLTSTDERR=info in order to catch log-info that happens
> at runtime, and find the compile-time
I don't think you want to do anything with the compiler or macros.
Instead, it's a matter of having a sufficiently powerful inspector
(which is the concept of "inspectability" turned into a language
construct).
If you have just
(struct a (x))
(a 1)
then the result will print as `#`. But if you
We don't have build products handy on a server, but it shouldn't be
difficult to build yourself using Visual Studio 10. I recommend setting
up the command line using "vcvarsall.bat x86_amd64", and then build
from the Git repo using "nmake win32-in-place".
That process will give you debugging infor
e:
> Is it perhaps worth being more explicit about this possibility in the
> docs? I'm thinking of a sentence that says "when is
> set, delete-file may have only the effect of changing the permissions
> on the file" or similar.
>
> Robby
>
> On Wed, Jan 14,
At Wed, 14 Jan 2015 09:07:08 -0500, Neil Toronto wrote:
> On 01/13/2015 02:00 PM, mfl...@racket-lang.org wrote:
> > 9f3c82c Matthew Flatt 2015-01-13 08:47
> > :
> > | Windows: change `delete-{file,directory}` to attempt permission correction
> > |
> > | If a fi
It wasn't that I forgot to implement pieces, after all. The problem was
a bug in the byte compiler's handling of `#%variable-reference` when
inlining. I've pushed a repair.
At Mon, 12 Jan 2015 19:24:56 -0700, Matthew Flatt wrote:
> It's supposed to be safe; the beha
It's supposed to be safe; the behavior in this example is definitely a
bug.
The `#%variable-reference` form used to work only on top-level and
module variables. It seems that I forgot to fill in some pieces when I
made `#%variable-reference` work on local bindings (several years ago,
mainly for us
I'm not sure what you have in mind with some of the steps, such as step
4 (using `raco pkg` or `raco link`?).
The trace suggests that "gui-lib" is linked as a clone at the `raco
pkg` level. Using `raco link -r` to adjust links installed by the
package manager has a difficult-to-predict effect, but
> Is that enough context to see the issue?
>
> On Tue, Jan 6, 2015 at 11:58 AM, Matthew Flatt wrote:
>
> > At Tue, 06 Jan 2015 14:14:22 -0500, Neil Van Dyke wrote:
> > > Dan Liebgold wrote on 01/06/2015 02:00 PM:
> > > > What is a straightforward way
Do you have the latest "images-doc" and/or "gui-lib" packages?
Recently, there was a problem with the "images" documentation where it
tried to use `racket/gui` at document-build time. At the same time,
there was also a problem in `racket/gui` that could cause a crash
(mainly on Mac OS X) after `ra
If your library's name is also `json` you could put in a place that is
included in PLTCOLLECTS when you run v5.2.1, but use a PLTCOLLECTS that
doesn't include it when your run v6.1 (in much the same way that you
use different PLTCOMPILEDROOTS settings for the different versions).
If your library h
Some of us have discussed this in recent months. So far, our conclusion
has been "not yet".
At Mon, 05 Jan 2015 10:56:01 +, Stephen De Gabrielle wrote:
> (Sorry if this is the wrong list)
>
> I just saw the LTS Haskell announcement, and it made me wonder if there is
> a racket equivalent?
>
I wasn't able to replicate the problem, but I think I see what could go
wrong. I've pushed an attempt at a repair.
At Wed, 7 Jan 2015 18:31:35 +0100, Jens Axel Søgaard wrote:
> Hi All,
>
> I got a contract when I tried to build racket. Any ideas?
>
> The main error is below.
> Entire log is here
At Tue, 06 Jan 2015 14:14:22 -0500, Neil Van Dyke wrote:
> Dan Liebgold wrote on 01/06/2015 02:00 PM:
> > What is a straightforward way to designate the "compiled" directory to
> > look for zo files in that can be based on the Racket version? I'd
> > like to have Racket 5.2.1 and 6.1 running in
n the
release notes.
At Tue, 6 Jan 2015 11:46:11 -0800, Dan Liebgold wrote:
> That method isn't available in 5.2.1, unfortunately. Oh, and wishlist item:
> the reference docs specify the version the function was introduced in.
>
> On Tue, Jan 6, 2015 at 11:39 AM, Matthew Flatt wrot
You probably want to set `current-compiled-file-roots`, which can be
initialized by the `PLTCOMPILEDROOTS` environment variable, instead.
At Tue, 6 Jan 2015 11:27:35 -0800, Dan Liebgold wrote:
> Hmmm... so this should be as easy to implement as:
>
> (use-compiled-file-paths (list (build-path "c
I think the root of the problem is that `raco setup` gets anywhere
close to the 1 GB limit. Also, since the "images.scrbl" document
involves images, the problem may be related to using foreign libraries
when close to the memory limit (where the foreign library can't force a
Racket GC to recover fro
It looks like this patch was submitted for v6.1. Version 6.1.1 (the
current release), uses SGC instead of Boehm's GC during the build
process by default. So, it at least avoids this immediate problem.
I can't think of any other problem that would turn up in v6.1.1, but
I'm not sure it will work. W
At Wed, 17 Dec 2014 10:38:59 -0500, Asumu Takikawa wrote:
> On 2014-12-17 08:22:33 -0700, Matthew Flatt wrote:
> > Commit 134f793 moved files out of a directory named "tests". By
> > default, a directory named "tests" is treated specially by the
> >
At Tue, 16 Dec 2014 16:32:59 -0500, Asumu Takikawa wrote:
> On 2014-12-16 13:26:38 -0800, Asumu Takikawa wrote:
> > Branch: refs/heads/master
> > Home: https://github.com/racket/typed-racket
> > Commit: 3e45f258bed22d16b1f7ab1cac701d20c5f57e06
> >
> https://github.com/racket/typed-ra
At Thu, 11 Dec 2014 17:00:14 -0800, Dan Liebgold wrote:
> If I use the -X and -S command line parameters to Racket to make my local
> collects dir the first one searched, it makes it so I can't do (require
> srfi/1).
Yes, this is subtle and confusing.
> Is there something special about the srfi p
hat if
> we wanted).
>
> Robby
>
>
> On Tue, Dec 9, 2014 at 6:22 PM, Jay McCarthy wrote:
> > Specifically, you can get errors like "Called export 72 and expected
> > set->list but got list->set. Chaos!"
> >
> > Jay
> >
> > On Tu
Unfortunately, the bytecode compiler is not completely deterministic.
Generating the same ".zo" file from the same source is likely to
produce different bytes each time. The root causes are various counters
and hash orders, and I hope to fix that eventually. For now, since the
generated bytecode is
At Fri, 5 Dec 2014 14:04:47 -0800, John Clements wrote:
> 1) compilation failed because it couldn't find the 'racket' collection, but
> I noticed that it was referring to a nonexistent path, presumably because I
> had moved the root of the installation. Has that always been a bad idea?
Ok, yes, i
it compiled in normal time, so
> it has something to do with interrupted makes.
>
> On Fri, Dec 5, 2014 at 5:36 PM, Matthew Flatt wrote:
> > Sorry --- I've figure out how I misread your message, and I'm no longer
> > interested in the output of `raco show`.
> &
ng more happens after the build of minimal Racket.
I think that aspect of the makefile should change.
Meanwhile, I'm not clear on why moving your directory caused the
package system to lose track of "at-exp-lib", and I'll look into that
further.
At Fri, 5 Dec 2014 15:22:03 -0
Can you run `raco pkg show`? It looks like `raco pkg install` thinks
you have "main-distribution" and "main-distribution-test" installed
already.
At Fri, 5 Dec 2014 14:04:47 -0800, John Clements wrote:
> Urg... more interesting problems. I pulled and tried to rebuild, and things
> went pear-shaped
In cooperation with Sam, I've pushed a change to the way that `make`
links the content of "pkgs". If you run `make` again, it should tell
you to delete your old
racket/etc/config.rktd
Also, the "native-pkgs" submodule is gone. The problem that John saw
with "libintl.8.dylib" has been fixed by
At Sat, 29 Nov 2014 22:00:44 -0500, Eli Barzilay wrote:
> On Sat, Nov 29, 2014 at 8:30 PM, Sam Tobin-Hochstadt
> wrote:
> > On Sat, Nov 29, 2014 at 8:16 PM, Eli Barzilay wrote:
> >> On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt
> >> wrote:
> >>> To clone individual repositories, use the n
Although I object to some of your characterizations of the difference
between PLaneT and the new package system, it's fair to say that PLaneT
provides better support to package authors for creating new APIs that
are intended to replace (but coexist with) old APIs.
I think the answer to that proble
We should change that example. It would indeed be strange for package
named "tic-tac-toe" would introduce a `data/matrix` module, and the
documentation really shouldn't suggest that it makes sense for a
package to introduce overlaps that are not reasonably expected from the
package name.
There ar
Do you have in mind making "xrepl" intended to be part of Minimal
Racket? If not, what's the mechanism for `racket` using "xrepl" when
it's available?
A similar question applies to "libeditline". Currently, for Linux and
other Unix platforms (not counting "natipkg" variants), our convention
is tha
At Sat, 22 Nov 2014 14:16:32 -0500, Eli Barzilay wrote:
> On Fri, Nov 21, 2014 at 4:26 PM, Robby Findler
> wrote:
> > The two candidates are the trampoline approach and the "just move the
> > documentation files over into the user space as if a package had been
> > installed".
>
> Oh, *that*'s th
Yes, our Cygwin support has rotted in a variety of small but exotic
ways.
I'm in the process of fixing the problems. The enclosed patch applies
to the development branch or the v6.1.1 release candidate, and it might
work for you, but I'm still checking it.
The fixed-up implementation will be limi
I think you probably want to get information directly from
`compiler/cm`, probably `compiler/cm` doesn't provide the right
information right now, and probably some adjustments to `compiler/cm`
could get you useful information through the logging API. Also,
`parallel-compile-files` might need to cha
At Mon, 27 Oct 2014 12:25:22 -0400, Ryan Culpepper wrote:
> mflatt:
> - optimizations (most from Gustavo Massaccesi) (82ffd405, 25c05d66,
> a7a912ee, 1f2f7a1d, d14b4a80, 769c5b6e, 35eb6562, 15423988)
> - add replace-evt (as suggested by Jan Dvořák) (bc69a9b0)
> - fixing letrec updates? (e
installation and re-installed and drracket starts up fine.
>
> -- Matthias
>
>
>
>
>
> On Oct 23, 2014, at 2:26 PM, Matthew Flatt wrote:
>
> > Is it possible that you installed on top of an existing v6.0.900.900
> > installation (for the previou
Is it possible that you installed on top of an existing v6.0.900.900
installation (for the previous release's candidate)?
The file
share/pkgs/drracket/drracket/private/compiled/rectangle-intersect_rkt.zo
existed in v6.0.900.900, but it does not exist in v6.1.0.900, because
the library moved to
I can confirm the crash with a Cairo 1.14 build on 64-bit Mac OS X.
I've submitted a bug report for Cairo (Bug 85372).
For the record, here's how I assembled the report:
The crash happened for me when building the "plot" documentation. By
successively pruning the document's source, I whittled th
At Wed, 22 Oct 2014 10:25:51 -0400, Sam Tobin-Hochstadt wrote:
> On Wed, Oct 22, 2014 at 10:20 AM, Matthew Flatt wrote:
> > Expansions that produce this bad `identifier-binding` result probably
> > happen up all the time. They don't bother the bytecode compiler,
> >
I agree that this is broken, but I'd like to put it on hold, because
its another basic problem with the way the current macro expander
represents lexical context.
Adjusting the context of the expressions changes the result, because
its the macro-introduced nature of the `main` definition that trig
At Fri, 17 Oct 2014 17:56:51 +0200, David Bremner wrote:
> Matthew Flatt writes:
>
> >
> > Meanwhile, I haven't answered your original question. Can you remind me
> > of the specific steps that I'd need to follow to try the script that
> > you sent befo
The development version of the package manager now supports Git
repository references using "http[s]://" and sites other than GitHub.
That is, a package source can have the form
git://host/[...]
for a host other than "github.com", and a source can have one of the
forms
http://[...].git
https:
At Thu, 16 Oct 2014 09:13:54 -0400, Ryan Culpepper wrote:
> * Matthew Flatt
>- Racket Tests
>- Languages Tests
>- GRacket Tests (Also check that `gracket -z' and `gracket-text' still
> works in Windows and Mac OS X)
>- mzc --exe tests
>-
At Fri, 17 Oct 2014 07:43:17 +0200, David Bremner wrote:
> Matthew Flatt writes:
>
> >
> > That said, is there a particular reason that basing the build on the
> > git repo would be better?
> >
>
> One reason is that I need I need to track from release to
Hi David,
If I understand correctly, you're trying to base the build on a
checkout of the Racket git repository. I think it's better to base it
on a release source distribution, instead:
* The source distribution embeds a reference to a release-specific
package catalog, which effectively free
The latest should work. Please try a snapshot:
http://pre.racket-lang.org/
At Thu, 2 Oct 2014 12:55:50 -0700, Nick Sivo wrote:
> Figured I'd wait until OS X Yosemite was closer to release before
> mentioning this, but DrRacket 6.1 doesn't run on it. Now that Yosemite
> has reached Release Cand
I think that commit b946d4639e fixes this crash.
It's nice of you to ask the day after the repair. :) I had spent a lot
of time trying to replicate that crash, with no success, but yesterday
was my lucky day. Claire ran a pessimization experiment on the bytecode
compiler that made "image.scrbl" cr
12:32:48 +0100, Antonio Menezes Leitao wrote:
> Hi,
>
> On Thu, Sep 18, 2014 at 12:00 PM, Matthew Flatt wrote:
>
> > I think there must be a problem with v6.1's support for soft links on
> > Windows, while previous versions of Racket were oblivious to links
I think there must be a problem with v6.1's support for soft links on
Windows, while previous versions of Racket were oblivious to links on
Windows.
What does
(resolve-path "C:\\Users\\aml\\AppData\\Roaming\\Racket")
report?
At Wed, 17 Sep 2014 17:31:55 +0100, Antonio Menezes Leitao wrote:
> H
At Wed, 03 Sep 2014 13:07:05 +0400, Yaroslav Tsarko wrote:
> are there any
> reasons why Racket currently uses very old
> version of GNU Lightning? According to sources, Racket 6.1 uses GNU
> Lightning version 1.2 which originates from 2004
> [...]
> Is it manpower problems (there is nobody who c
At Sat, 30 Aug 2014 10:25:53 -0700, Kevin Forchione wrote:
>
> On Aug 30, 2014, at 7:09 AM, Matthew Flatt wrote:
>
> > Just for the record, this is my fault for not incrementing the version
> > with a change to the compiler's optimizer.
> >
> > I thou
wrap-evt
> (peek-bytes-evt skip 0 #f port)
> (lambda(x) 0)))
>
> instead of the wrapped port event at port.rkt:1027
>
> Then again, couldn't `do-peek` just return the appropriate
> `peek-bytes-evt` when `count` is nonzero?
>
> Marc
>
> On Thu, Sep
Can you provide an example?
Here's what I tried, but it blocks without busy-waiting:
#lang racket
(require file/gunzip file/gzip)
(define dest (open-output-bytes))
(deflate (open-input-bytes #"hello") dest)
(define bstr (get-output-bytes dest))
(define-
Just for the record, this is my fault for not incrementing the version
with a change to the compiler's optimizer.
I thought of the optimization as "local" and having no effect on a
module's interface to other modules. There's no such thing, though,
since optimizer-inferred properties of a function
po to reflect that addition. Are the
> contents of the main distribution not part of the repo anymore?
>
> Vincent
>
>
>
> At Wed, 27 Aug 2014 08:46:02 -0600,
> Matthew Flatt wrote:
> >
> > The Racket snapshots at
> >
> > http://www.cs.utah.edu/
The Racket snapshots at
http://www.cs.utah.edu/plt/snapshots/
now include the Optimization Coach package.
At Tue, 12 Aug 2014 18:32:05 +0100, Matthew Flatt wrote:
> Our build system can create a distribution from any set of packages,
> and so we can easily switch over one of the snapsh
If you put the code below in a module, you don't get an error, because
the syntax object that has the unsealed context doesn't appear in the
fully-expanded module. The syntax object is in a local macro binding
that disappears.
If you remove the `let' around
(bind h (define q 5))
(define q 8)
Tue, 12 Aug 2014 18:00:21 +0200, Matthew Flatt
> wrote:
>
> > I'm not sure how difficult it will be. It's tedious enough that the
> > last time I thought about it, I just left a note next to
> > "no-cgc-needed" in "racket/src/racket/Makefile.in&quo
We discussed the possibility git submodules last year, and I think the
consensus was that it wouldn't work well. We did attach the
native-library repo (for Mac OS X and Windows) as a submodule to the
main Racket repo, and that worked well enough, but I think it has
worked only because the native-li
hstadt wrote:
> How difficult would it be to allow the bootstrap process to use a
> preexisting Racket installation? This would alleviate some of the
> performance loss, for example in rebuilds by developers or in continuous
> integration.
>
> Sam
> On Aug 11, 2014 11:16 PM, &q
The gcc 4.9 release notes warn about this optimization:
https://gcc.gnu.org/gcc-4.9/porting_to.html
I'm surprised that this change hasn't caused more trouble for us.
At Tue, 12 Aug 2014 08:39:01 +0100, Matthew Flatt wrote:
> Apparently, when gcc 4.9.1 sees
>
> memcpy
).
At Tue, 12 Aug 2014 02:00:04 -0400, Asumu Takikawa wrote:
> On 2014-08-12 06:06:51 +0100, Matthew Flatt wrote:
> > What platform are you using?
> >
> > I imagine that running `./racketcgc` within the "racket" subdirectory
> > of your build directory will s
At Tue, 12 Aug 2014 00:43:04 -0400, Asumu Takikawa wrote:
> On 2014-08-12 05:16:21 +0100, Matthew Flatt wrote:
> > If you have an existing build in a repo checkout, then `make` is likely
> > to fail, because the makefile dependencies are not precise enough to
> > deal wit
I've changed the Racket CGC implementation --- which is mostly used
only to build the normal Racket variant --- to use SGC by default,
instead of the Boehm GC. The intent of the switch is to make the more
portable GC the default.
If you have an existing build in a repo checkout, then `make` is lik
Thanks for the report. Unfortunately, I'm not able to replicate the
crash, so I'm not sure what to recommend.
If you have Visual Studio installed, then it may offer to open a
debugger, or you could attach to the process while a "program has
crashed" dialog is showing. A C-level backtrace extracted
Sorry that I lost track of this one. I've pushed a repair.
At Tue, 29 Jul 2014 16:26:21 -0700, Sam Tobin-Hochstadt wrote:
> Here's a simpler version of this problem:
>
> #lang racket
> (parameterize ([current-namespace (make-base-namespace)])
> (expand (datum->syntax
>#f
>
At Tue, 29 Jul 2014 06:31:21 -0700, Sam Tobin-Hochstadt wrote:
> Plumbers look like a fundamental new runtime system concept, and so I think
> we should mention them, even though most people won't use them.
At Tue, 29 Jul 2014 13:47:58 -0400, Matthias Felleisen wrote:
> +1 on plumbers, if only for
At Mon, 28 Jul 2014 14:33:07 -0400, Ryan Culpepper wrote:
> mflatt:
> - ARM JIT: fix software floating-point (ffb0dd52)
> - add plumbers (d5b42f8c)
> - raco make: improve parallelism (9e3b9844)
> - deprecate 3-arg module name resolver calls (8aaa3fc5)
> - win32: support symbolic links (3e3cb716, 9f
Unless I still have it wrong, the implementation of 2 was
straightforward.
I would have overlooked the need to restrict `chaperone-struct` to
chaperones of accessors and mutators if you hadn't mentioned it.
At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote:
> Consider the following mo
I'll push a repair.
The problem is in the representation of syntax objects and the flaky
way that it was generalized to support identifiers that move across
submodule boundaries (but the problem didn't just affect programs with
submodules, in this case).
At Thu, 24 Jul 2014 16:24:42 -0400, Sam To
Nice example. Offhand, I think that #2 is right, but I'll have to look
at it more to be sure.
At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote:
> Consider the following module:
>
> (module m racket
> (struct x [a])
> (define v1 (x 'secret))
> (define v2 (x 'public))
> (provid
24 Jul 2014 11:09:11 +0100, Matthew Flatt wrote:
> In Racket, it looks like a lot of the time is still in generic
> dispatch: directing hash operations to `equal?`-based hashing,
> directing `equal?`-based hashing operation to the string-specific
> operation, directing equality co
In Racket, it looks like a lot of the time is still in generic
dispatch: directing hash operations to `equal?`-based hashing,
directing `equal?`-based hashing operation to the string-specific
operation, directing equality comparison to string-specific equality
comparison, and so on.
I'm not sure i
At Sun, 20 Jul 2014 22:37:36 -0700, Jon Rafkind wrote:
>
> On 07/17/2014 05:03 PM, Ryan Culpepper wrote:
> >
> > * Jon Rafkind
> > Release tests for (one of the) linux releases:
> > - Test that the `racket' and `racket-textual' source releases
> > compile fine (note that they're still cal
At Fri, 18 Jul 2014 09:52:26 -0500, Robby Findler wrote:
> Unless someone knows why it is a bad idea, how about adding a #:all?
> argument that flattens all the way down?
>
> I don't see many uses of flatten-begin in our tree, but the one in
> compatibility/package sure looks like it could use the
"Killed" means that the OS terminated the `racket/racket3m` process
from the outside. For example, the process may have exceeded a
memory-use limit.
At Sat, 19 Jul 2014 20:25:24 -0400, "Alexander D. Knauth" wrote:
> I made a fork of the racket repo and committed some changes in a topic
> branch,
At Thu, 17 Jul 2014 20:03:12 -0400, Ryan Culpepper wrote:
> * Matthew Flatt
>- Racket Tests
>- Languages Tests
>- GRacket Tests (Also check that `gracket -z' and `gracket-text' still
> works in Windows and Mac OS X)
>- mzc --exe tests
>-
ogram on a different source file containing a
> reference to that definition.
>
> Clearly this is possible, since Racket manages, but is there a way
> that I can do it?
>
> Sam
>
> On Wed, Jul 16, 2014 at 7:55 AM, Matthew Flatt wrote:
> > Yes, it can be ".2"
an that I can/should just drop the .1 to get the defined name?
> Can it also be .2 etc?
>
> Sam
> On Jul 16, 2014 4:34 AM, "Matthew Flatt" wrote:
>
> > That `posn1.1` is a unreadable symbol that stands for the symbol
> > `posn1` plus some marks that distinguish it
That `posn1.1` is a unreadable symbol that stands for the symbol
`posn1` plus some marks that distinguish it.
In other words, `posn1.1` bridges (in an ugly way) the symbol-based
world of module environments and the identifier-based world of syntax.
In the future, I hope to shift module environment
Added!
At Tue, 8 Jul 2014 05:36:55 +0100, Matthew Flatt wrote:
> Hi Jan,
>
> That's a nice idea. Something similar --- but in a restricted form ---
> is used internally to implement various primitive events. I think I see
> how to generalize it to work with more arbitrary e
The "gc" directory is Boehm's GC. We've modified it a little (grep for
"PLTSCHEME"), but we try not to maintain the GC itself, except to
upgrade every once in a while.
See
http://www.hboehm.info/gc/
for the latest version, the mailing list, etc.
I should look again at making Racket work with
Yes, `raco setup` with no arguments would succeeded and should fix
things up at this point.
When you use `raco pkg update`, it effectively passes the `--tidy` flag
to `raco setup`. That is, `raco setup --tidy rackjure` would avoid the
problem, and it should also fix things up at this point.
It's
I've pushed a repair. To double-check it, change 1140 to something like
1340, since the table of primitives changed as part of the repair.
Thanks for the report!
At Wed, 9 Jul 2014 09:39:50 -0400, Sam Tobin-Hochstadt wrote:
> The following exchange with rudybot, which is running the programs in
>
At Tue, 8 Jul 2014 11:49:49 -0400, Sam Tobin-Hochstadt wrote:
> On Tue, Jul 8, 2014 at 11:35 AM, Matthew Flatt wrote:
> > At Tue, 8 Jul 2014 10:15:10 -0400, Sam Tobin-Hochstadt wrote:
> >> - I think we need to support planet packages -- there are some people
> >> st
At Tue, 8 Jul 2014 10:15:10 -0400, Sam Tobin-Hochstadt wrote:
> - I wonder if using Docker instead of VirtualBox could make
> incrementality easier, since that's one of things that they focus on.
I don't think it would be easier, but it might be more efficient and
even easier to set up, so it see
At Tue, 8 Jul 2014 09:08:34 -0400, Sam Tobin-Hochstadt wrote:
> On Tue, Jul 8, 2014 at 8:14 AM, Matthew Flatt wrote:
> > At Tue, 08 Jul 2014 14:08:27 +0200, Jan Dvořák wrote:
> >> On Tue, 2014-07-08 at 12:46 +0100, Matthew Flatt wrote:
> >> > The rightmost col
At Tue, 08 Jul 2014 14:08:27 +0200, Jan Dvořák wrote:
> On Tue, 2014-07-08 at 12:46 +0100, Matthew Flatt wrote:
> > The rightmost column of the table may need some explanation. The column
> > highlights conflicts among names of package-installed executables,
> > foreign lib
I've been working on a service that builds all packages listed at
"pkgs.racket-lang.org". The idea is to run builds regularly (at least
once a day) and link to documentation and build-status information from
"pkgs.racket-lang.org".
Here's a table showing the current results for each package:
ht
1 - 100 of 1176 matches
Mail list logo
