Re: [racket-dev] Racket head fails to compile
On 20/02/14 14:19, Matthew Flatt wrote: At Sun, 09 Feb 2014 08:35:03 +, Paulo J. Matos wrote: On 09/02/14 00:03, Matthew Flatt wrote: There should be many more flags passed to `gcc`, including some -I flags and some -D flags. Is something in your environment overriding the CFLAGS definition in the makefile? Normally, a definition in the makefile would take precedence over an environment variable, but maybe something else is taking precedence over the definition? Doh, right. I assumed for no good reason racket would behave the same way my usual project does and use env CFLAGS as the optimization flags used for compilation. Any other env variable the racket build system uses for me to add additional compilation flags? (for example to build with `-O2 -ftree-vectorize` or `-O0 -g3`) After some thought shouldn't -D... and -I... flags be controlled by CPPFLAGS and not CFLAGS such that overriding CFLAGS would still leave CPPFLAGS intact? I've changed the makefiles so that setting CFLAGS (or CPPFLAGS) will hopefully work the way you expect. Thanks for the fix. I will give it a try. -- PMatos _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket head fails to compile
On 09/02/14 00:03, Matthew Flatt wrote: There should be many more flags passed to `gcc`, including some -I flags and some -D flags. Is something in your environment overriding the CFLAGS definition in the makefile? Normally, a definition in the makefile would take precedence over an environment variable, but maybe something else is taking precedence over the definition? Doh, right. I assumed for no good reason racket would behave the same way my usual project does and use env CFLAGS as the optimization flags used for compilation. Any other env variable the racket build system uses for me to add additional compilation flags? (for example to build with `-O2 -ftree-vectorize` or `-O0 -g3`) After some thought shouldn't -D... and -I... flags be controlled by CPPFLAGS and not CFLAGS such that overriding CFLAGS would still leave CPPFLAGS intact? -- PMatos _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket head fails to compile
Hello, If I grab racket HEAD and try to compile it with: git clone ... racket.git cd racket/racket/src mkdir build cd build ../configure --prefix=... make -j16 I get: make[6]: Entering directory `/home/pmatos/work/racket/racket/src/build/racket/gc' gcc -O0 -g3 -c ../../../racket/gc/alloc.c gcc -O0 -g3 -c ../../../racket/gc/reclaim.c gcc -O0 -g3 -c ../../../racket/gc/allchblk.c ../../../racket/gc/alloc.c:19:30: fatal error: private/gc_priv.h: No such file or directory # include private/gc_priv.h gc/ has an include/private directory so I would have expected the command line to gcc to be something like: gcc -O0 -g3 -c ../../../racket/gc/alloc.c -Iinclude/ Also, when I try simply: make I get: make[6]: Entering directory `/home/pmatos/work/racket/racket/src/build/racket/gc' rm -f mach_dep.o ./if_mach SPARC SOLARIS gcc -c -o mach_dep2.o ../../../racket/gc/sparc_mach_dep.S make[6]: ./if_mach: Command not found make[6]: *** [mach_dep.o] Error 127 The if_mach script exists in racket/gc but not in the build/racket/gc so I guess somewhere there needs to be a copy of the script onto the build directory. I am curious how you guys usually do the build if not like this... -- PMatos _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] bug: internal typechecker error
On 22/10/12 21:43, Paulo J. Matos wrote: Hello, As I was converting a program into typed racket in drscheme 5.3 I got an internal typechecker error. Load the attached file and press run. That should allow you to reproduce the problem. git HEAD has the problem fixed. -- PMatos _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new logo
Upon startup of DrRacket, create an animation that moves the lambda onto an r, and then complete with 'acket' as per Eli suggestion. That would be awesome, even though I don't know how hard would be to produce such animation. On 11/02/12 18:27, John Clements wrote: On Feb 11, 2012, at 10:23 AM, Matthias Felleisen wrote: John and Neil, we seem to have lost momentum on this discussion. For the record, I like the idea of changing our logo a bit. I like the direction in which is evolving, though I will admit that losing the lambda completely. Have you guys considered a small change that makes the 'r' more lambda-ish? In any case, I am all for keeping the new logo around for a while so that we can check whether we get used to it or not. Would it be productive to choose one randomly on startup? Also, in case it's not obvious, a rotated and flipped version of the logo does recall the lambda pretty clearly: Re-rendering the image with the lighting in the right place might change or improve this, though I agree that the weighting of the strokes is all wrong here. John _ Racket Developers list: http://lists.racket-lang.org/dev -- PMatos _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Test results are slightly incomprehensible...
...if you're not used to them, that is. Hi, I am running the racket tests to know if something went wrong with my fork of racket. The fork was done at tag 2ef9f5ae. I run the tests with from the install directory with: , | racket$ bin/racket -r ./collects/tests/racket/quiet.rktl ` Attached, you can find the output I obtain for both my repository and the main repository. The diff looks like: Section(basic) Section(unicode) Section(rx) Section(reading) Section(readtable) Section(printing) Section(macro) Section(syntax) Section(procs) Section(stx) Section(module) Section(numbers) Section(unsafe) Section(object) Section(struct) Section(unit) Section(unit/sig) Section(threads) Section(logger) Section(synchronization) Section(deep) Section(continuation-marks) Section(prompt) Section(wills) Section(namespaces) Section(modprot) Section(chaperones) Section(parameters) Section(port) Section(file) Section(udp) Section(file-after-udp) Section(path) Section(optimization) Section(names) Section(setup) Section(for) Section(list) Section(math) Section(vector) Section(function) Section(dict) Section(contract) Section(fixnum) Section(flonum) Section(mpair) Section(etc) Section(structlib) Section(async-channel) Section(restart) Section(mzlib-string) Section(path) Section(filelib) Section(portlib) Section(threadlib) Section(sets) Section(date) Performed 35 expression tests (31 value expressions, 4 exn expressions) and 6 exception field tests. Errors were: (Section (got expected (call))) ((date) ((638931660) Error (find-seconds 0 1 2 1 4 1990))) (Other messages report successful tests of error-handling behavior.) Section(compat) Section(command-line) Section(stream) Section(sequence) Section(generator) Section(pconvert) Section(pretty) Section(control) Section(serialization) Section(packages) Section(mzlib/contract) Section(sandbox) Performed 281 expression tests (281 value expressions, 0 exn expressions) and 0 exception field tests. Errors were: (Section (got expected (call))) ((sandbox) ((bad-exception-message: with-limit: out of time) #t (#procedure:e-match? out of memor(?:y) #procedure:run #procedure:...ket/sandbox.rktl:71:55))) ((sandbox) (#f #t (#procedure:run* #procedure:...ket/sandbox.rktl:67:55))) (Other messages report successful tests of error-handling behavior.) Section(shared) Section(kw) Section(macrolib) Section(resource) Section(syntax/) Performed 152701 expression tests (139300 value expressions, 13401 exn expressions) and 26923 exception field tests. Errors were: (Section (got expected (call))) ((date) ((638931660) Error (find-seconds 0 1 2 1 4 1990))) ((sandbox) ((bad-exception-message: with-limit: out of time) #t (#procedure:e-match? out of memor(?:y) #procedure:run #procedure:...ket/sandbox.rktl:71:55))) ((sandbox) (#f #t (#procedure:run* #procedure:...ket/sandbox.rktl:67:55))) (Other messages report successful tests of error-handling behavior.) Section(moddep) Section(boundmap) Section(id-table) Section(cm) Section(module-reader) Performed 153275 expression tests (139865 value expressions, 13410 exn expressions) and 26941 exception field tests. Errors were: (Section (got expected (call))) ((date) ((638931660) Error (find-seconds 0 1 2 1 4 1990))) ((sandbox) ((bad-exception-message: with-limit: out of time) #t (#procedure:e-match? out of memor(?:y) #procedure:run #procedure:...ket/sandbox.rktl:71:55))) ((sandbox) (#f #t (#procedure:run* #procedure:...ket/sandbox.rktl:67:55))) (Other messages report successful tests of error-handling behavior.) Section(version) Section(foreign) Section(uni-norm) Performed 505944 expression tests (492534 value expressions, 13410 exn expressions) and 26941 exception field tests. Errors were: (Section (got expected (call))) ((date) ((638931660) Error (find-seconds 0 1 2 1 4 1990))) ((sandbox) ((bad-exception-message: with-limit: out of time) #t (#procedure:e-match? out of memor(?:y) #procedure:run #procedure:...ket/sandbox.rktl:71:55))) ((sandbox) (#f #t (#procedure:run* #procedure:...ket/sandbox.rktl:67:55))) Section(basic) Section(unicode) Section(rx) Section(reading) Section(readtable) Section(printing) Section(macro) Section(syntax) Section(procs) Section(stx) Section(module) Section(numbers) Section(unsafe) Section(object) Section(struct) Section(unit) Section(unit/sig) Section(threads) Section(logger) Section(synchronization) Section(deep) Section(continuation-marks) Section(prompt) Section(wills) Section(namespaces) Section(modprot) Section(chaperones) Section(parameters) Section(port) Section(file) Section(udp) Section(file-after-udp) Section(path) Section(optimization) Section(names) Section(setup) Section(for) Section(list) Section(math) Section(vector) Section(function) Section(dict) Section(contract) Section(fixnum) Section(flonum) Section(mpair) Section(etc) Section(structlib) Section(async-channel) Section(restart) Section(mzlib-string) Section(path) Section(filelib) Section(portlib) Section(threadlib) Section(sets)
Re: [racket-dev] Who page
On 03/09/11 19:01, Neil Van Dyke wrote: Finally, Racket is supported by an band of volunteers Maybe initially someone wrote 'an army' and then 's/band/army' since 'band' sounds less threatning. :) -- PMatos _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket tests
On 31/08/11 17:35, Eli Barzilay wrote: Much easier to run and to follow -- run this: racket -r quiet.rktl with your newly made executable. Just a note that for that to work I need to be in: lib/racket/collects/tests/racket/ -- PMatos _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Warnings in source code
Hi, I was just looking at the warnings in racket source code after Sam posted the bite size projects threads with the link to the wiki. I can't access http://drdr.racket-lang.org/ (the page just doesn't load) So, I cloned racket, configured it and did a make. I only get two warning on the whole build: gcc -I./.. -I../../../racket/src/racket/gc2/../include -g -O2 -pthread -Wall-c xsrc/place.c -o place.o ../../../racket/src/racket/gc2/../src/place.c: In function ‘place_async_send’: ../../../racket/src/racket/gc2/../src/place.c:2450:14: warning: operation on ‘ch-in’ may be undefined ../../../racket/src/racket/gc2/../src/place.c: In function ‘scheme_place_async_try_receive’: ../../../racket/src/racket/gc2/../src/place.c:2589:17: warning: operation on ‘ch-out’ may be undefined This is with GCC4.5. I will try later GCC4.6 though but I am amazed GCC4.5 only shows two warnings. Well, it's definitely a good sign but I was wondering if I overlooked something. Do I have to enable any components which when compiled will issue some warnings that you want sorted? Cheers, -- PMatos _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Warnings in source code
On 26/08/11 17:28, Sam Tobin-Hochstadt wrote: Great. It might be helpful to try building with clang as well, as it gives very helpful warning/error messages. The next step is to figure out how to patch that file to remove the warning. I will compile with clang and gcc46 and will try to submit a patch fixing these warnings. Will post back in case I get stuck. -- PMatos _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Warnings in source code
On 26/08/11 17:55, Robby Findler wrote: There are plenty of warnings when you build under windows. oh... :-/ If the problem is windows then I don't think I will be able to help since I don't have access to a windows box at home. -- PMatos _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Warnings in source code
On 26/08/11 17:28, Sam Tobin-Hochstadt wrote: Great. It might be helpful to try building with clang as well, as it gives very helpful warning/error messages. The next step is to figure out how to patch that file to remove the warning. I will try later GCC4.6 though but I am amazed GCC4.5 only shows two warnings. Well, it's definitely a good sign but I was wondering if I overlooked something. ok, at least GCC46 finds heaps of warnings that GCC45 doesn't. None major but will get them sorted. -- PMatos _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23267: master branch updated
On 17/08/11 09:49, Marijn wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/16/11 20:54, Stephen Bloch wrote:
Wouldn't it be even better to put curly-braces around the body of the
C macro, so people using it don't have to know that it expands into
multiple statements?
I read a long time ago (I think it was on LWN, but I can't find the
article) about some tricks that are used in the linux kernel to mitigate
weaknesses of the C preprocessor. You wrap multiple statement macros in
do { } while(0), so that you don't have to think about whether you
need curly braces and it will absorb (and need) a semicolon, so that it
won't break your if-statements. You can read more about it here:
https://www.securecoding.cert.org/confluence/display/seccode/PRE10-C.+Wrap+multi-statement+macros+in+a+do-while+loop
I was quite amazed to read about this bug in Racket and I was going to
suggest exactly the same thing. All Racket code should ensure no macro
expands to more than one expression. Use `do { ... } while(0)' pattern.
Consider this email just a reinforcement of Marijn' suggestion.
--
PMatos
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
[racket-dev] Doc typo
From the raco exe help pma...@mietzekatze:~/Code/eboc $ ~/Applications/racket-5.0.1.1/bin/raco help exe raco exe [ option ... ] source-file where option is one of -o file : Write executable as file --gui : Geneate GUI executable ... Should be Generate instead of Geneate. -- PMatos _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
