Two days ago, Kevin Tew wrote:
This means that parallel zo and doc builds will use places instead
of processes.
Report bugs as usual :)
Here's a major bug: the memory consumption is *horrible*. Winooski,
the main build machine, has 4 cores and 4gb ram. Things used to be
pretty bad with 4
At Thu, 21 Apr 2011 05:33:47 -0400, Eli Barzilay wrote:
Two days ago, Kevin Tew wrote:
This means that parallel zo and doc builds will use places instead
of processes.
Report bugs as usual :)
Here's a major bug: the memory consumption is *horrible*.
Ok, we'll disable for now and
An hour and a half ago, Kevin Tew wrote:
An alternative patch that keeps places enabled but uses processes
for build.
Yes -- this is what I meant by disabling it. (Assuming that this
disables the parallel build with either places or processes.)
diff --git a/collects/setup/parallel-do.rkt
[ In case you don't know: since the late 90s, I have been teaching a course
dubbed software dev every so often. Students choose their favorite language, I
choose the project, they program, I program in Racket and in DrRacket (and
strictly). Over the semester the students code-walk their
* Jon Rafkind rafk...@cs.utah.edu
Release tests for (one of the) linux releases:
- Test that the `racket' and `racket-textual' source releases
compile fine
- Test that the binary installers for both work, try each one in
both normal and unix-style installation modes. (just
Matthias Felleisen wrote at 04/21/2011 01:07 PM:
-A- I demanded that students deliver their functionality via Unix shell
scripts, and so I did so too. My tcsh scripts check the argument number and
pass the arguments on to Racket. Firing up one of my clients or servers takes
several seconds.
Source distributions compiled ok. The racket distribution no longer
produces a 'drscheme' executable even though it does produce 'mzscheme'.
Is that a mistake?
On 04/21/2011 11:50 AM, Jon Rafkind wrote:
* Jon Rafkind rafk...@cs.utah.edu
Release tests for (one of the) linux releases:
-
Not a mistake. 'mzscheme' is kept for script-compatibility but
'drscheme' is dropped as part of the name change transition.
Jay
2011/4/21 Jon Rafkind rafk...@cs.utah.edu:
Source distributions compiled ok. The racket distribution no longer
produces a 'drscheme' executable even though it does
I had a request for line counts:
-- my own project used ~5,000loc, which includes comments and blank lines
-- of these, ~3,200 lines are 'real' code and some ~1,800 lines of
rackunit code
-- the Java projects run at about 2x to 3x the line count (the best project
comes in at
Two points worth noting:
1. Robby pointed out that I forgot to compile my code when I ran the script.
That was a critical omission on my side and it eliminates point -A- from my
list of negative observations.
2. I forgot to mention the most amazing aspect of my final test run with the
All of the plot tests and plot extensions in the science collection work as
expected.
On Wed, Apr 20, 2011 at 9:41 PM, Ryan Culpepper ry...@ccs.neu.edu wrote:
Checklist items for the v5.1.1 release
(using the v5.1.0.900 release candidate build)
Search for your name to find relevant items,
On Wed, Apr 20, 2011 at 10:41 PM, Ryan Culpepper ry...@ccs.neu.edu wrote:
* Robby Findler ro...@eecs.northwestern.edu
- DrRacket Tests
all passed except tests/drracket/test-engine-test.rkt and I'll be
looking into that one.
- Framework Tests
- Contracts Tests
- Games Tests
-
Hi All;
I'm trying to build 5.1 on debian/kfreebsd, and I'm having problems with
src/racket/src/port.c
The main problems stem from MZ_FLUSH_* not being defined. This in turn
seems to be because MZ_FDS is not defined at line 259. At that point I
got stuck, I couldn't see what controlled this
I tried to build the git HEAD today and ran into problems. During the make
process, it fails to create the framework with the following error message:
gcc -o Racket.framework/Versions/5.1.1.3/Racket -m32 -pthread -framework
CoreFoundation -dynamiclib -all_load libracket.a libmzgc.a -ldl -lm
It looke like you have `-L/opt/local/lib' in your LDFLAGS
configuration. Do you also have `-I/opt/local/include' in CPPFLAGS?
You machine is probably like mine, where you have two installations of
libiconv, and this error happens when the C headers of one installation
get mixed with the lib of
I don't have any *FLAGS variables set in my environment when I run configure or
make. But I do have libiconv installed through macports. It was out of date,
and I upgraded it, but now I am getting a different message:
gcc -o Racket.framework/Versions/5.1.1.3/Racket -m32 -pthread -framework
The recent change to `configure' makes it use `pkg-config' to add -L
and -I flags for libffi. But those should flags be added consistently;
that is, you should end up with a build that uses `libiconv' from
macports.
Did you run `configure' in a fresh build directory? If not, maybe you
have files
It looks like it was a problem with libffi, which was also out of date in my
macports. I upgraded it before your email, and the build got past that point
where it was failing. Hopefully it won't have any more problems.
Thanks for the help.
-Eric
On Apr 21, 2011, at 10:17 PM, Matthew Flatt
18 matches
Mail list logo
