Re: [racket-dev] lib changes between versions
I usually use this macro in a wrapper that require/provides the libs and provides compatibility wrappers when needed ;; compile time version switch (define-syntax (version=? stx) (syntax-case stx () [(_ min-version body body-else) (if (string=? (version) (syntax-e #'min-version)) #'body #'body-else)])) On Thu, 08 Jan 2015 02:56:16 +0100, Dan Liebgold dan.liebg...@gmail.com wrote: Actually this issue is still perplexing me. In 5.2.1 I have my own json lib which provides jsexpr-string. In 6.1 it's part of the distribution's collects directory. Is there a command line for racket that'll cause it to find mine under 5.2.1 and the standard lib in 6.1 (skipping mine)? Dan On Wed, Jan 7, 2015 at 4:51 PM, Dan Liebgold dan.liebg...@gmail.com wrote: Ugh. Never mind... the old json lib is mine. Carry on :) On Wed, Jan 7, 2015 at 4:45 PM, Dan Liebgold dan.liebg...@gmail.com wrote: I'm maintaining the same racket code between Racket version 5.2.1 and 6.1. One thing that changed between those version was the json to string (and vice versa) lib functions. Is there a straightforward way to define those functions so they'll work with both lib versions? Thanks, -- Dan Liebgold[dan.liebg...@gmail.com] -- Dan Liebgold[dan.liebg...@gmail.com] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] SGC as default
What about ./configure --enable-racket=`which racket` ? Already needed and used for cross-compilation. Tobias On Tue, 12 Aug 2014 18:00:21 +0200, Matthew Flatt mfl...@cs.utah.edu 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, but maybe it's worth pursuing now. At Tue, 12 Aug 2014 04:39:55 -0700, Sam Tobin-Hochstadt 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, Matthew Flatt mfl...@cs.utah.edu wrote: 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 likely to fail, because the makefile dependencies are not precise enough to deal with the switch. You can discard your old build directory, or it might work to simply delete builddir/racket/libmzgc.a If you're using CGC and want to continue using the Boehm GC, then provide `--disable-sgc` to `configure`. I've tuned SGC to bring its performance closer to the Boehm GC, but it's still slower. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev -- Tobias Hammer DLR / Robotics and Mechatronics Center (RMC) Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] ffi sizeof bool
Hi,
i guess this shouldn't happen:
$ cat s.cc
#include stdio.h
int main()
{
printf(%zu\n, sizeof(bool));
}
$ g++ s.cc -o s
$ ./s
1
Welcome to Racket v6.0.0.5.
- (require ffi/unsafe)
- (ctype-sizeof _bool)
4
Tested with multiple unix/linux OS, all gcc 4.3.4
Tobias
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] ffi sizeof bool
Just checked and _Bool is also 1 byte, same as C++. What i don't
understand yet is to which standard does the current _bool conform? I
couldn't find any platform with int sized bool.
On Fri, 04 Apr 2014 17:10:30 +0200, Matthew Flatt mfl...@cs.utah.edu
wrote:
Yes, `_bool` is a problem. I'll add a `_stdbool` that corresponds to
`bool` from C99's stdbool.h, which I imagine must be the same as
`bool` in C++.
At Fri, 4 Apr 2014 08:56:18 +0200, Tobias Hammer wrote:
Hi,
i guess this shouldn't happen:
$ cat s.cc
#include stdio.h
int main()
{
printf(%zu\n, sizeof(bool));
}
$ g++ s.cc -o s
$ ./s
1
Welcome to Racket v6.0.0.5.
- (require ffi/unsafe)
- (ctype-sizeof _bool)
4
Tested with multiple unix/linux OS, all gcc 4.3.4
Tobias
_
Racket Developers list:
http://lists.racket-lang.org/dev
--
Tobias Hammer
DLR / Robotics and Mechatronics Center (RMC)
Muenchner Str. 20, D-82234 Wessling
Tel.: 08153/28-1487
Mail: tobias.ham...@dlr.de
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] package system, minimal builds and more
All in one answer On Tue, 01 Oct 2013 15:30:11 +0200, Neil Toronto neil.toro...@gmail.com wrote: On 10/01/2013 09:20 AM, Tobias Hammer wrote: * monolithic math currently math is one big package and installing it pulls in nearly everything through the docs. Is it planned to split it into -lib and -doc? We were waiting for a reason. This is one. I'll try it on my flight home tonight. (Never done any package management before.) Thanks for tackling this. I think its worth the effort. I suppose this is a good rule of thumb: if your docs make pictures, put them in a separate package. Yes, thats a good minimum requirement. For standalone builds or for small devices it would be even better if it's possible to build everything that might be useful in this setting without a single doc. On Thu, 03 Oct 2013 17:26:08 +0200, Robby Findler ro...@eecs.northwestern.edu wrote: These two are fixed now (with the snapshot build http://plt.eecs.northwestern.edu/snapshots/20131003-154d940/). Thanks, will try as soon as possible. On Wed, 02 Oct 2013 16:39:42 +0200, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: * raco pkg warnings On every command i get warning: tool pkg registered twice: pkg and #path:/home/hamm_to/tmp/racket/_tmp/racket-5.90.0.9/collects/pkg warning: tool setup registered twice: setup and #path:/home//hamm_to/tmp/racket/_tmp/racket-5.90.0.9/collects/setup warning: tool link registered twice: link and #path:/home/hamm_to/tmp/racket/_tmp/racket-5.90.0.9/collects/setup /home/hamm_to/tmp/racket/_tmp/racket-5.90.0.9/ is the used installation. What command did you run to get this error? I haven't been able to replicate it. It seems to only happen if i have PLTCOLLECTS=:, not if it's set to anything else to unset. Then a raco pkg is enough to trigger it. You can see these with `raco pkg show`. Is that what you're looking for? Exactly what i was looking for (raco pkg show -a -d). Thanks. On Wed, 02 Oct 2013 18:32:51 +0200, Jay McCarthy jay.mccar...@gmail.com wrote: I think I need more details. If you have pkg A installed, then it should only download a small checksum to see if A needs to be updated. If this is broken, then it is an error. That works as supposed. If you do NOT have pkg A installed, then it will download the full file. If that install fails, then 'raco pkg' cleans up after itself and deletes the things it downloaded. Apt does not do this and saves everything in a temporary directory that must be manually cleaned. I did not implement that because it feels wrong to run a command like 'raco pkg clean-old-tmp-files' or something. But it sounds like you want that? Yes, that's what i had in mind because I'm used to this behavior and i was wondering why raco downloaded the files over and over on a _failed_ install (Only noticed it because it was a relatively large install). But the temporary files are a good point that i completely forgot. I think, in hope that installs (hopefully) rarely fail it's better as it is now. Tobias _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] package system, minimal builds and more
Hi, i played a bit with the new package system, minimal installs and cross compiling. It works pretty good but i have a few problems and remarks/questions. I start with a fresh yesterdays minimal source (min-racket-5.90.0.9-src.tgz), build it (natively for linux) and try to install packages. (Given in no particular order) * compiler-lib install fails with the following error ./bin/raco pkg install -i compiler-lib Resolving compiler-lib via http://www.eecs.northwestern.edu/plt/snapshots/20130929-6d4ff30/catalog/ Resolving compiler-lib via https://pkg.racket-lang.org Downloading checksum for compiler-lib Downloading http://racket-packages.s3-us-west-2.amazonaws.com/pkgs/b824ed762533834659b5f0ee047deafb101acc74/compiler-lib.zip raco pkg install: package conflicts with existing installed package: compiler-lib module path: compiler/option As its needed by racket-doc and similar it blocks install of a lot of packets * the snapshot catalog seems to be nonexistent If i browse to http://www.eecs.northwestern.edu/plt/snapshots/20130929-6d4ff30/catalog/, i always get a 404. Is this intended? * redownload after fail the package manager seems to download every packet again after a failed install or user interruption. Would it be worth to reuse the once downloaded zips if the checksum is the same (similar to the behavior of apt). * raco pkg warnings On every command i get warning: tool pkg registered twice: pkg and #path:/home/hamm_to/tmp/racket/_tmp/racket-5.90.0.9/collects/pkg warning: tool setup registered twice: setup and #path:/home//hamm_to/tmp/racket/_tmp/racket-5.90.0.9/collects/setup warning: tool link registered twice: link and #path:/home/hamm_to/tmp/racket/_tmp/racket-5.90.0.9/collects/setup /home/hamm_to/tmp/racket/_tmp/racket-5.90.0.9/ is the used installation. * sometimes installations fail without a reason or hangs ./bin/raco pkg install -i xrepl [...] The following uninstalled packages are listed as dependencies of macro-debugger-text-lib and they will be installed: parser-tools-lib unstable-list-lib Resolving parser-tools-lib via http://www.eecs.northwestern.edu/plt/snapshots/20130929-6d4ff30/catalog/ Resolving parser-tools-lib via https://pkg.racket-lang.org Resolving parser-tools-lib via https://planet-compat.racket-lang.org raco pkg install: cannot find package on catalogs package: parser-tools-lib rerunning the command and it suddenly works. * monolithic math currently math is one big package and installing it pulls in nearly everything through the docs. Is it planned to split it into -lib and -doc? * cross compiling and installing is it possible to install packages as part of the bootstrap process? the problem i have is that the build machine is a regular linux but the cross compile target is constrained in that it cannot install packages (no internet, no writable discs, ...). But i can't install via raco because racket is compiled for that target it does not run on linux. I can currently work around this by installing a linux racket with same version, installing there and then copying share/, but thats somewhat ugly. * More verbose require error If i require something nonexistent i get an exception like (require fdfsdfsdf) ; readline-input:4:8: collection not found ; for module path: fdfsdfsdf ; collection: fdfsdfsdf ; in collection directories: ;/home/hamm_to/.racket/snapshot/collects ; /volume/USERSTORE/hamm_to/tmp/racket-qnx/linux-racket-5.90.0.9/collects ;/home/hamm_to/.racket/snapshot/collects ; /volume/USERSTORE/hamm_to/tmp/racket-qnx/linux-racket-5.90.0.9/collects ;... [22 additional linked and package directories] Is it possible to somehow show these additional 22 entries? Maybe not in the error but from raco? I know these are a lot of things and some might be obvious or result from misunderstanding or missing something. So thanks for enlightening answers to any of these. Tobias _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] behavior of 'local-transformer-expand' changed
Hi, Commit e51ac9cc [1] from about a month ago changed the allowed values for local-transformer-expands context-v argument. It now refuses 'module and 'module-begin. Previously i could simply pass the result from syntax-local-context. I am not sure what i should pass now and what implications the change has. Any hints appreciated. Tobias [1] http://git.racket-lang.org/plt/commitdiff/e51ac9cc _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] behavior of 'local-transformer-expand' changed
Here is a strip down example of a case that worked before and gave an error with the new version. I was only interested in the information if the argument to mac could be expanded to something bound or not. So the quick solution here was to wrap the provide in begin and expand it in 'top-level. Tobias PS: The whole local-expand construct is only needed in my case to work around the unfortunate behavior that racket lacks source locations in error message for transformer phase. It would really, really simplify debugging if that could be changed. ;; --- example #lang racket (require (for-syntax racket)) (define-syntax (mac stx) (syntax-case stx () [(_ id val) (begin (define e (local-transformer-expand #'val ;; 'module worked before (syntax-local-context) #f)) #`(begin-for-syntax #,e))])) (begin-for-syntax (define C 'C) (define-syntax (B stx) (syntax-case stx () [(_) #'(provide C)]))) (mac id (B)) On Thu, 01 Aug 2013 14:16:14 +0200, Matthew Flatt mfl...@cs.utah.edu wrote: I removed those options because the implementation did not look sensible for those cases. Implementation aside, using 'module-begin doesn't make sense to me. A form in the place of `#%module-begin' is always expanded at phase-level 0, so there isn't really. I'm less certain about 'module. It may make sense to use 'module and get the same effect as wrapping the form with `begin-for-syntax', expanding with `local-expand', and removing the expansion again. Do you have an example where you use 'module? At Thu, 1 Aug 2013 10:12:16 +0200, Tobias Hammer wrote: Hi, Commit e51ac9cc [1] from about a month ago changed the allowed values for local-transformer-expands context-v argument. It now refuses 'module and 'module-begin. Previously i could simply pass the result from syntax-local-context. I am not sure what i should pass now and what implications the change has. Any hints appreciated. Tobias [1] http://git.racket-lang.org/plt/commitdiff/e51ac9cc _ Racket Developers list: http://lists.racket-lang.org/dev -- - Tobias Hammer DLR / Robotics and Mechatronics Center (RMC) Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics updates
I really like the new set features, especially mutable sets and lists as sets. Two things i have notices: * The docs for set-intersect seem a bit mixed up with set-union stuff * I could not get set-intersect on lists working, what i've tried - (set-intersect '(1 2 3) '(2 3 4)) ; set-add: contract violation ; expected: set? ; given: 2 - (set-intersect (list-set '(1 2 3)) '(2 3 4)) ; set-intersect: set arguments have incompatible equivalence predicates ; first set: (set 1 2 3) ; incompatible set: '(2 3 4) Tobias On Tue, 23 Jul 2013 17:37:15 +0200, Carl Eastlund c...@ccs.neu.edu wrote: My work on adding gen:set, and related changes to define-generics and gen:dict, is ready for review and (hopefully) to push to the master branch. The branch moved in the process of cleaning things up, it's now at: https://github.com/carl-eastlund/racket/tree/generics-from-scratch (The from scratch just refers to the process of rebuilding the git history, I didn't go out of my way to rewrite anything in the code base from scratch, although in some places a lot of code did move around.) What's new in the branch: - Generics now support a few new options - #:fallbacks specifies fallback method implementations for instances with no implementation - #:fast-defaults specifies instances on a fast path, useful for built-in types - #:defined-predicate gives a more intuitive and efficient interface than #:defined-table - #:derive-property allows generics to piggy-back on existing struct properties - Sets are now a generic datatype through gen:set - lists are now sets - the built-in set types are now documented as hash sets - there are mutable and weak hash sets - you can define new set types quickly with define-custom-set-types - most set operations are now methods with fallbacks - sets now support -copy and -clear operations, plus mutating [!] versions of operations - Dictionaries have a few changes - new macro define-custom-hash-types [*] - most dict operations are now methods with fallbacks - dicts now support -copy, -clear, -clear!, and -empty? operations I've run some benchmarks and performance of the various generic operations are comparable to the current HEAD, so there should be no major performance changes with this patch. [*] I've added define-custom-hash-types and define-custom-set-types rather than just adding make-custom-set akin to make-custom-hash because make-custom-hash is hard to use. The documented behavior -- that any custom hash is equal to any other created with the same bindings and predicates / hash functions -- was never true and can be expensive or at least tricky to implement. It seemed more sensible to just remove the erroneous documentation on make-custom-hash, and add the definition form to create constructors for new, explicitly-compatible dict and set types. Both definition forms bind predicates and constructors for new (set or dict) types with immutable, mutable, and weak variants that inter-operate. If there are no serious issues brought up in the next day or two, I'll push it to the development branch, since our current release process isn't following HEAD. Carl Eastlund -- - Tobias Hammer DLR / Robotics and Mechatronics Center (RMC) Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Symlink trouble
Hi, i am currently implementing an application that heavily relies on rackets great serialize functionality to exchange data between racket processes on different computers. That works well until i stumbled over a very confusion behavior of rackets filesystem and module path resolution. I will explain first, what i observed and then why this causes some trouble: * relative (module) paths are resolved with something like (or (current-load-directory) (current-directory)) * collection paths are resolved with (find-executable-path (find-system-path 'exec-file) (find-system-path 'collects-dir)) for the system collection and with the given path for the others * you can require a module relative and via collection, if they resolve to the same name, there is no error serialize stores the module path and symbol where the deserialize function can be found. It's interesting how this module path is determined * If the file containing the deserialize identifier (if implemented by hand or the file where e.g serializable-stuct is used) is loaded via collection, then the serialized stream contains a collection path (determined via identifier binding and mpi magic) * If this file is loaded relative, the fallback method with current-(load)-directory is used Nothing special so far, but the fun starts with how current-directory is initialized. It uses (on *nix systems) getcwd() but this function returns the path with all symbolic links resolved (getcwd is only a thin OS-wrapper, and the OS provides nothing else). This little detail can easily break the serialization framework (and maybe other things too). The scenario is a file that is in a path containing a symlink and that is in the current collections, e.g /abc/symlink/more/def/file.rkt and PLTCOLLECTS=/abc/symlink/more: and file.rkt contains a serializable-struct definition. Now one racket process loads file.rkt relative, serializes a struct instance and sends it to another racket process. The other process loads def/file via collection and deserialies the struct. The receiver now has a struct that is of a different type and that he can't access. This fails because the serialized data contains the absolute symlink-free path that differs from the path the receiver used to load file.rkt (because for collection dirs symlinks are not resolved). The same happens of course when the data is send to another computer that has a symlink in the path to file.rkt, even if they both load the same way. The confusing thing is that from the users point of view everything is consistent. His working directory and collections all point to the same location. It is clear that this behavior is by far not limited to racket as nearly all programming languages use getcwd internally. A quick google search for getcwd and symlinks gives a lot of results... I came up with a few solutions but i would like to get some feedback on them. They all more or less use that the shell keeps track of the 'real' (better: visible) working directory. Most *nix shells set 'PWD' in the environment but it is not guaranteed and can of cause be altered by the user. - The quick and very dirty hack is to set the current-directoy before any use code is executed racket -e '(current-directory (or (getenv PWD) (current-directory)))' program.rkt Too ugly to really use it... - A better fix would be to change how the current-directory parameter is initialized during the startup. It could be some heuristic that tries to use the env-variable if it is a complete and existing path and falls back to getcwd otherwise. As far as i can tell this won't break anything because after this one time at startup the C-sides cwd and rackets parameter are completely decoupled. - A more conservative solution would be a command line argument to racket to set the initial value for current-directory. One could then populate it with env's PWD or from `pwd` or whatever suits. I would appreciate any feedback on how i can work around this behavior (except don't use symlinks ...) or if i missed something obvious. If not, would any of the two real solutions be viable? They shouldn't be too hard to implement i could create a patch if one of them seems ok. Tobias -- - Tobias Hammer DLR / Robotics and Mechatronics Center (RMC) Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Symlink trouble
On Wed, 17 Apr 2013 16:39:22 +0200, Matthew Flatt mfl...@cs.utah.edu wrote: Yes, I think Racket should use PWD --- if the expansion of soft links produces the same path as getcwd(), which seems to be what /bin/pwd does. That check is even better than the one i had in mind. That should prevent any possible ambiguities. Should Racket also set PWD (optionally, but by default) when it creates a subprocess? I think probably so. Yes, i think that is a sensible default. Setting only the os cwd, as racket currently does would cause the same problems for any subprocesses that uses this information (at least most shells and, in the future, racket). To make sure we're all on the same page: The general problem is that there can be more than one filesystem path that reaches a file. It would be great if we could normalize every path to a canonical form, but path normalization in general seems to intractable due to the possibilities of soft links, hard links, multiple mount points, case-sensitivity choices, and probably other twists that I'm forgetting. We have therefore settled on different definitions of same file, depending on the context. Right For module paths, same file involves only syntactic normalizations of the pathname (e.g., no checking for soft links). Various pieces of the system are carefully implemented to be consistent with syntactic normalization. For example, suppose that PLTCOLLECTS is set to /home/mflatt/plt, but /home/mflatt is a symlink to /Users/mflatt; pathnames associated to modules that are accessed via collection will consistently use /home/mflatt, and not somehow hop over to /Users/mflatt. As long as a user is similarly consistent when supplying paths, it all works out. That matches my observations. Files accessed via collection always keep their paths 'as is'. But it is enough to start a program via racket file instead of racket -l what/ever to break this. Therefore it seems to be the normal case that it fails (at least for console racket). Unfortunately, `current-directory' is a place where you don't get to choose the path. You might say /home/mflatt/plt to get to a Racket installation, but to initialize `current-directory', the path gets turned into an inode and back to a path via getcwd() --- exactly the sort of thing that breaks a syntactic view of same. Correct The PWD environment variable addresses the problem with getcwd(): nice shells set PWD based on a syntactic derivation of the current directory, instead of an inode-based derivation. So, Racket should take advantage of the information that nice shells provide. Probably it should also act as a nice shell by default. What exactly do you mean by acting as a nice shell? Setting PWD for subprocesses? In that sense it should definitely be nice (by default). (As it happens, I use csh on Mac OS X, and it's not nice in the above sense. That helps explain why I never got PWD vs. cwd() before.) Just tried bash, csh and ksh on linux and they all seem to set PWD. But i can't tell if thats the default or specific to my installation. At Wed, 17 Apr 2013 12:06:29 +0200, Tobias Hammer wrote: Hi, i am currently implementing an application that heavily relies on rackets great serialize functionality to exchange data between racket processes on different computers. That works well until i stumbled over a very confusion behavior of rackets filesystem and module path resolution. I will explain first, what i observed and then why this causes some trouble: * relative (module) paths are resolved with something like (or (current-load-directory) (current-directory)) * collection paths are resolved with (find-executable-path (find-system-path 'exec-file) (find-system-path 'collects-dir)) for the system collection and with the given path for the others * you can require a module relative and via collection, if they resolve to the same name, there is no error serialize stores the module path and symbol where the deserialize function can be found. It's interesting how this module path is determined * If the file containing the deserialize identifier (if implemented by hand or the file where e.g serializable-stuct is used) is loaded via collection, then the serialized stream contains a collection path (determined via identifier binding and mpi magic) * If this file is loaded relative, the fallback method with current-(load)-directory is used Nothing special so far, but the fun starts with how current-directory is initialized. It uses (on *nix systems) getcwd() but this function returns the path with all symbolic links resolved (getcwd is only a thin OS-wrapper, and the OS provides nothing else). This little detail can easily break the serialization framework (and maybe other things too). The scenario is a file that is in a path containing a symlink and that is in the current collections, e.g /abc/symlink/more/def/file.rkt and PLTCOLLECTS=/abc/symlink/more: and file.rkt
Re: [racket-dev] Symlink trouble
On Wed, 17 Apr 2013 17:25:02 +0200, Matthew Flatt mfl...@cs.utah.edu wrote: That matches my observations. Files accessed via collection always keep their paths 'as is'. But it is enough to start a program via racket file instead of racket -l what/ever to break this. I should have mentioned that you could use `racket full-path-to-file' to avoid the problem, which is a workaround that I have used often. Thanks. I didn't know that. That seems to solve it for everything relying on the module path of the initial file. Unfortunately, but understandably current-directory is not affected. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] amd64 out of memory
I get this on i386, when the VM sucks up ~ 2GB of memory. You can try env PLT_SETUP_OPTIONS=-j 1, that helps for me. Tobias On Tue, 16 Apr 2013 17:50:52 +0200, Jon Rafkind rafk...@cs.utah.edu wrote: The PPA build has been failing the past 2 days or so for amd64 machines due to the Racket VM running out of memory, usually during 'raco setup' but not correlated with any specific collection. I don't have an amd64 machine on hand to test. Has anyone else seen this behavior on amd64 (or any architecture I guess)? The PPA i386 package seems to build fine. See these buildlogs: https://launchpadlibrarian.net/137534947/buildlog_ubuntu-oneiric-amd64.racket_5.3.4.3-20130416~oneiric_FAILEDTOBUILD.txt.gz https://launchpadlibrarian.net/137534947/buildlog_ubuntu-oneiric-amd64.racket_5.3.4.3-20130416%7Eoneiric_FAILEDTOBUILD.txt.gz https://launchpadlibrarian.net/137532928/buildlog_ubuntu-quantal-amd64.racket_5.3.4.3-20130416~quantal_FAILEDTOBUILD.txt.gz https://launchpadlibrarian.net/137532928/buildlog_ubuntu-quantal-amd64.racket_5.3.4.3-20130416%7Equantal_FAILEDTOBUILD.txt.gz https://launchpadlibrarian.net/137533283/buildlog_ubuntu-raring-amd64.racket_5.3.4.3-20130416~raring_FAILEDTOBUILD.txt.gz https://launchpadlibrarian.net/137533283/buildlog_ubuntu-raring-amd64.racket_5.3.4.3-20130416%7Eraring_FAILEDTOBUILD.txt.gz -- - Tobias Hammer DLR / Robotics and Mechatronics Center (RMC) Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compilation of 5.3.2 fails on some compilers
Thanks for the patch. I've changed more AC_TRY_RUN()s to AC_COMPILE_IFELSE()s and AC_LINK_IFELSE()s to work better for cross-compilation, and I'll push that soon. Great! They all look good except one. The test for GNU preprocessor never fails because whether the macro exists or not does not influence anything. Before the change the value returned from main was the indication if the macro was set or not. I think the test can be fixed by letting the compilation fail when __GNUC__ is undefined: diff --git a/src/racket/configure.ac b/src/racket/configure.ac index 92af108..15b6742 100644 --- a/src/racket/configure.ac +++ b/src/racket/configure.ac @@ -801,7 +801,7 @@ AC_COMPILE_IFELSE( #ifdef __GNUC__ return 0; #else -return 1; +if; // should fail on any valid c compiler #endif }, using_gnu_cpp=yes, using_gnu_cpp=no) if test $using_gnu_cpp = yes ; then I don't think I agree about the compare-and-swap test. If the compiler's default mode on a given machine is i386, then I don't think the `configure' script or other parts of the Racket build should try to override that. The choice of architecture should be left up to the user and system defaults. You are probably right. We will most likely have to carry gccs default i386 burden around until 32bit platforms die out. Tobias At Sat, 2 Feb 2013 01:26:06 +0100, Tobias Hammer wrote: Thanks for the detailed explanation. It's a lot clearer now why it's needed. But i figured out that the real culprit was cross-compilation in combination with autoconf. autoconfs default rule for test results when running cross-compilation was set to noinline not available, and therefore setting the define to expand to nothing. It should be, in this case and for inline too, enough to check for compilation, not for running the test. If the attribute is not supported the compilation should already fail. I attached a patch to change these two test and fix a typo. Compilation runs without any errors then. While checking for more similar tests i noticed that the test for compare-and-swap is completely screwed up. Even on a modern Core i7 with gcc 4.x it fails with default settings on a 32bit OS. The CAS builtins need at least -march=i686 there to run, otherwise you get undefined symbol errors. That never happens on 64bit OS because gcc knows that every x86-64 processor has CAS operations. I think it would be a good choice to set -march when using gcc with 32bit OS, assuming at least a pentium pro processor might be ok nowadays. It must be remain unset for 64bit, or gcc throws errors. Unfortunately my autoconf skills are far too limited to provide a patch. Tobias On Fri, 01 Feb 2013 19:30:15 +0100, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 1 Feb 2013 12:23:59 +0100, Tobias Hammer wrote: i am getting the following error when i try to compile racket-textual on a a version of gcc that does not support the 'noinline' attribute: xsrc/place.c: In function 'place_start_proc': xsrc/place.c:2793: warning: assignment makes pointer from integer without a cast xsrc/place.c: At top level: xsrc/place.c:3185: error: conflicting types for 'place_start_proc_after_stack' xsrc/place.c:2793: note: previous implicit declaration of 'place_start_proc_after_stack' was here The cause is that the forward declaration of 'place_start_proc_after_stack' is missing. It was originally there (L 95) but the MZ_DO_NOT_INLINE macro expands to nothing, effectively removing the declaration. The wrapping macro was added in commit 9692765e2 but the commit message gives no real reason why it is needed. I am a bit worried to revert the change because i don't know which bug i could reintroduce. What would be the correct fix to compile 5.3.2? Hopefully, the right fix is to make `MZ_DO_NOT_INLINE(decl)' expand to `decl' if no no inline annotation is available. If place_start_proc_after_stack() is inlined at its only use, whcih is in place_start_proc(), then a new place will not register its stack bounds correctly for the implementation of continuations. The implementation of continuations assumes that local variables in place_start_proc_after_stack() are shallower on the stack than variables in place_start_proc(), and inlining can defeat that assumption. If there's no way to say no inlining and inlining of that function can still happen, then we'll have to work harder to confuse the C compiler. The same is true for any other use of MZ_DO_NOT_INLINE(). _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] make-log-receiver changed behavior in 5.3.2
Between 5.3.1 and 5.3.2 the result value of make-log-receiver changed from a guaranteed 3 element vector to a 4 element vector. That's a backward incompatible change that will likely break programs relying on the old behavior. I think it would be worth a mentioning somewhere in the release notes to save others from spurious exceptions. Tobias -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] make-log-receiver changed behavior in 5.3.2
I of course meant the result vector of a sync on a log-receiver. On Fri, 18 Jan 2013 16:30:45 +0100, Tobias Hammer tobias.ham...@dlr.de wrote: Between 5.3.1 and 5.3.2 the result value of make-log-receiver changed from a guaranteed 3 element vector to a 4 element vector. That's a backward incompatible change that will likely break programs relying on the old behavior. I think it would be worth a mentioning somewhere in the release notes to save others from spurious exceptions. Tobias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] replacing current-load/use-compiled
maybe there is a better way but you can write a little wrapper that changes the handler: ;; --- wrap.rkt (begin-for-syntax (require racket/base) (define old-handler (current-load/use-compiled)) (current-load/use-compiled (lambda args (printf inside handler ~a\n args) (apply old-handler args start with racket -f wrap.rkt -t your-file.rkt Tobias On Wed, 16 Jan 2013 18:49:12 +0100, Dan Liebgold dan.liebg...@gmail.com wrote: Does anyone know if there's a way to replace current-load/use-compiled at startup time without changing cstartup.inc and rebuilding executables? -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] How to avoid to modify .gitignore when pull request
Edit .gitgnore and then use git update-index --assume-unchanged .gitignore to tell git to ignore the changes. Revert with git update-index --no-assume-unchanged .gitignore if needed. Tobias On Thu, 13 Dec 2012 15:22:29 +0100, Chen Xiao chenxiao770...@gmail.com wrote: I fork the codebase on my local computer. Then I .configure make make install, as a result, there are many compiled things like bin or *.o files. To avoid add them to my commit, I modify .gitignore to ignore them all. But I can't avoid add .gitignore at all, isn't it? So how do you solve this problem? -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Identifier macros
I learned about identifier macros mostly from scrambling through the racket sources. There they are often seen in places where macros are used instead of functions to avoid the cost of a function call. Normally. macros have the drawback that they can't be passed around or applied like functions. (define-syntax-rule (call/print fun args ...) (begin (printf call ~s\n (cons 'fun '(args ...))) (fun args ...))) (call/print printf ~a ~a\n 1 2) ; works (apply call/print printf ~a ~a\n '(1 2)) ; fails with use does not match pattern That's where identifier macros come into play: (define-syntax call/print (syntax-id-rules () [(_ fun args ...) (begin (printf call ~s\n (cons 'fun '(args ...))) (fun args ...))] [_ (lambda (fun . args) (printf call ~s\n (cons 'fun args)) (apply fun args))])) (call/print printf ~a ~a\n 1 2) ; works with first rule (apply call/print printf ~a ~a\n '(1 2)) ; works with the second rule Like this both cases work and the user must not know if, what he calls is a function or a macros. The advantage for the user is that he gets a speedup in the common case and the developer can optimize functions without breaking code. Maybe that would be a good addition for the Optimization section. Tobias On Tue, 04 Dec 2012 23:16:17 +0100, Carl Eastlund c...@ccs.neu.edu wrote: I'm confused about so-called identifier macros. I had thought that ordinary transformers bound to functions could only transform application-position references to themselves, and that a set! transformer was required to transform bare references and set! references. Turns out I was wrong, set! transformers are in fact only required to transform set! references. So why are they listed under the documentation for identifier macros and why does that documentation imply that normal transformers can't handle bare references? Carl Eastlund -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] FFI: pointer to an array in a C struct type
On Mon, 03 Dec 2012 11:45:08 +0100, Neil Toronto neil.toro...@gmail.com wrote: This error seems wrong: #lang racket (require ffi/unsafe ffi/unsafe/cvector) (define-cstruct _mpz ([alloc _int] [size _int] [limbs (_gcable _cvector)])) (define z (make-mpz 1 1 (list-cvector '(1) _long))) (mpz-limbs z) _cvector: cannot automatically convert a C pointer to a cvector The error might be correct, though late and confusing, if a cvector's base representation isn't a pointer type. Is it? The base representation should be a pointer but the length and type information to convert it back to a cvector is missing. Whats stored inside the struct is only a plain pointer, without the information you supplied to make-mpz, and because of this _cvector only has a racket-c-conversion (see ffi/unsafe/cvector.rkt). If that error is correct, then how are FFI users meant to define a C struct that has a long * field that points to an array? I've not yet managed to define one whose instances survive a garbage collection cycle without using (_gcable _cvector). Here's one of my desperate attempts: #lang racket (require ffi/unsafe ffi/unsafe/cvector) (define-cstruct _mpz ([alloc _int] [size _int] [limbs _gcpointer])) (define z (make-mpz 1 1 (cvector-ptr (list-cvector '(1) _long (ptr-ref (mpz-limbs z) _long 0) 1 (collect-garbage) (ptr-ref (mpz-limbs z) _long 0) 139856348920568 I mean to be complain-y this time. This shouldn't be this hard to figure out. I guess the problem here is, that the gc only knows memory with only pointers (to gcable memory) inside and (atomic) memory without any pointers it should follow. You try to mix them up. make-mpz should malloc (see ffi docs) atomic memory and you put a pointer managed by the gc into it. The pointer gets relocated on gc, but the ref inside the struct is not known and not updated. I unfortunately don't know a simple, gc- and typesafe way to put pointers inside structs. My attempts to get around this were pretty hacking (using a raw malloc'd pointer, embed a struct with plain values as pointer inside an interor-malloc'd struct together with all others pointers, etc). I would be really interested in a way to accomplish this, too. Tobias -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] for loop singleton optimization
What about (let ([set (lambda (a) (set 1 2 a))]) (for/list ([x (in-set (set 3))]) x)) ? Tobias On Wed, 28 Nov 2012 19:24:12 +0100, J. Ian Johnson i...@ccs.neu.edu wrote: Cool. I submitted a pull request with this change since it's always an improvement. Thanks, -Ian - Original Message - From: Matthew Flatt mfl...@cs.utah.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: dev dev@racket-lang.org Sent: Wednesday, November 28, 2012 12:58:09 PM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] for loop singleton optimization I think that would be an ad hoc optimization in each `in-'. For example, (define-sequence-syntax *in-set (lambda () #'in-set) (lambda (stx) (syntax-case stx () [[(id) (_ st)] in `racket/set' could change to (define-sequence-syntax *in-set (lambda () #'in-set) (lambda (stx) (syntax-case stx (set) [[(id) (_ (set v))] #`[(id) (in-value v)]] [[(id) (_ st)] At Wed, 28 Nov 2012 12:50:49 -0500 (EST), J. Ian Johnson wrote: It would be great to optimize singletons out of comprehensions, since I (and probably others) have macros that expand into singleton constructors that are much better suited to just be a rebinding. (time (for ([n (in-range 1 100)]) (for ([k (in-set (set n))]) (random k cpu time: 340 real time: 338 gc time: 16 (time (for ([n (in-range 1 100)]) (for ([k (in-value n)]) (random k cpu time: 120 real time: 118 gc time: 0 Is this easily added to for.rkt? -Ian _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] cstruct and properties
On Sun, 11 Nov 2012 17:39:07 +0100, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 7 Nov 2012 20:00:51 +0100, Tobias Hammer wrote: i am currently playing around with properties attached to cstructs and ran into some problems. Normally, with racket structs, i can access a property without an instance of the struct via the struct type descriptor (struct:S). There seems to be nothing similar for cstructs, so the only way i found to check for or access a property is to create a dummy instance solely for this purpose. Would it be possible to add a similar type descriptor for cstructs? To account for the incompatibility with the one for structs it might make sense to name it different, maybe cstruct:S or similar. I've added it as `struct:cpointer:S' --- sticking with struct: because it is a structure type in the usual sense, but adding cpointer: because it corresponds to the wrapper struct, and not really to `S' instances. The naming is perfectly reasonable and now everything works as expected. Thanks! If such a descriptor would exists it should be included in the transformer bindings for cstructs. Another info i am really missing there is the super-type field. As far as i can see, it would be a valid semantic to set it to the identifier if the cstruct was created by type and to set it #f if it got its super-type by cpointer. After looking into this, I'm not sure what you had in mind after all. I fixed a related issue, which is that a cstruct subtype now inherits its parent's wrapper and properties. For example, (define-values (p p? p-ref) (make-struct-type-property 'my-p)) (define-cstruct _S ([a (_array _byte 23)]) #:property p (lambda () _S)) (define-cstruct (_T _S) ()) (p? (ptr-ref (malloc _T) _T)) produces #t. But I think that's not all that you were getting at, so maybe an example would help. You are right, that not what i had in mind. What i tried to suggest is to adjust the transformer time information for cstructs to bring them closer to the ones of normal structs. I got a bit confused by the code, so scratch that last part about super-type by cpointer. Example: #lang racket (require (for-syntax racket/list racket/struct-info) ffi/unsafe) ;; 1 (struct A (a)) (struct B A ()) ;; 2 (define-cstruct _S ([a _int])) (define-cstruct (_T _S) ()) (define-syntax (a stx) (printf 1: ~a\n2: ~a\n (sixth (extract-struct-info (syntax-local-value #'B))) (sixth (extract-struct-info (syntax-local-value #'T #'(void)) (a) = 1: #syntax:/home/hamm_to/tmp/racket-testing/cstruct-super-info.rkt:7:10 A 2: #t I would expect the syntax-object for identifier S at 2. #t says T has no super-type and thats clearly not the case. But one more thing on properties. A source of really nasty bugs is if you try to use the ctype of a cstruct inside the property: (define-values (p p? p-ref) (make-struct-type-property 'my-p)) (define-cstruct _S ([a (_array _byte 23)]) #:property p _S) Fixed in a way that turns that into an error for a too-early use of `_S', as we discussed. Great, one less source of ugly segfaults. -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Just out of curiosity: What are your / the teams objections against some kind of real versioning system that allows to * specify a version number without creating a new package * specify dependencies based on minimal version * keep/pin a package at some particular version (maybe your code depends on an exact, even buggy behavior) * keep directory and file names between incompatible versions without getting banned from solar What made me also wonder when i read the docs is, why is it allowed to have packets that have the same directories as the core racket distribution? Tobias On Thu, 08 Nov 2012 14:16:58 +0100, Jay McCarthy jay.mccar...@gmail.com wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. I've tried to answer all questions and explain everything about Planet 2 in the documentation, which I've uploaded a copy of here: http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html In particular, it explains what the plan is to go from this beta release to the final release. If you currently have packages on Planet 1, I am excited to help you make the transition to Planet 2. (I am currently in the process of converting my packages.) Please do not hesitate to let me know how I can help. This represents the third iteration of the design of Planet 2. (The first was worked on from August 10, 2010 to March 11, 2011. The second in July 2011. The third from August 2011 until now, although coding didn't begin until December 2011.) Enjoy, Jay p.s. In the implementation, I'm particularly proud of the little language for defining command-line interfaces with matching functions (see planet2/main.rkt for a use) and the testing infrastructure that allows you to run sequences of shell commands and check their output (see tests/planet2/tests-install.rkt for a nice example.) _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] cstruct and properties
Hi, i am currently playing around with properties attached to cstructs and ran into some problems. Normally, with racket structs, i can access a property without an instance of the struct via the struct type descriptor (struct:S). There seems to be nothing similar for cstructs, so the only way i found to check for or access a property is to create a dummy instance solely for this purpose. Would it be possible to add a similar type descriptor for cstructs? To account for the incompatibility with the one for structs it might make sense to name it different, maybe cstruct:S or similar. If such a descriptor would exists it should be included in the transformer bindings for cstructs. Another info i am really missing there is the super-type field. As far as i can see, it would be a valid semantic to set it to the identifier if the cstruct was created by type and to set it #f if it got its super-type by cpointer. But one more thing on properties. A source of really nasty bugs is if you try to use the ctype of a cstruct inside the property: (define-values (p p? p-ref) (make-struct-type-property 'my-p)) (define-cstruct _S ([a (_array _byte 23)]) #:property p _S) (define s (ptr-ref (malloc _S) _S)) ; dummy instance Getting the value results in: (p-ref s) #ctype (ctype-sizeof (p-ref s)) 4 Checking ffi/unsafe.rkt shows that i get a temporary cpointer as ctype. The real type already exists at the time the wrapper-struct is created but it is not yet accessible by the name _S. The following small patch should solve this by locally introducing the correct name during the struct creation. diff --git a/collects/ffi/unsafe.rkt b/collects/ffi/unsafe.rkt index 37ffc7c..4842e87 100644 --- a/collects/ffi/unsafe.rkt +++ b/collects/ffi/unsafe.rkt @@ -1384,7 +1384,7 @@ #'(begin) (with-syntax ([(prop ...) property-stxes]) #'(define make-wrap-TYPE - (let () + (let ([_TYPE _TYPE*]) (struct cpointer:TYPE (ptr) #:property prop:cpointer 0 prop ...) -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] crash with subprocess
Hi, i am experiencing random crashes when using subprocess followed by a subprocess-wait. My test program, that i call via subprocess is special, in that it kills itself very fast with a sigkill after executing. Unfortunately, i wasn't able to reproduce this behavior in a small sample but i could record three different core dumps with full debug info (attached). I tested with my own build of git head and 5.3.0.21. All crashes/freezes are preceded by the message unexpected error from waitpid(138321448[1]): 10 with a completely invalid pid argument to waitpid. The errno 10 is No child processes. What follows this message are random freezes (ctrl+c has no effect), heap corruptions or segfaults. I hope the supplied information is enough to locate whatever goes wrong, otherwise i can, of course send in more. Tobias -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.dehangs, ctrl+c not working, unexpected error from waitpid(138321064[1]): 10 unexpected error from waitpid(8345[1]): 10 unexpected error from waitpid(8344[1]): 10 unexpected error from waitpid(138321064[1]): 10 unexpected error from waitpid(8345[1]): 10 unexpected error from waitpid(8344[1]): 10 unexpected error from waitpid(138321448[1]): 10 unexpected error from waitpid(138321064[1]): 10 unexpected error from waitpid(8345[1]): 10 unexpected error from waitpid(8344[1]): 10 unexpected error from waitpid(138321448[1]): 10 unexpected error from waitpid(138321064[1]): 10 unexpected error from waitpid(8345[1]): 10 unexpected error from waitpid(8344[1]): 10 unexpected error from waitpid(138321448[1]): 10 ^\Quit (core dumped) (gdb) bt #0 0xe424 in __kernel_vsyscall () #1 0xb7643ea7 in poll () from /lib/libc.so.6 #2 0x0820f10c in default_sleep (v=0, fds=0xb56540e8) at ./../src/port.c:10114 #3 0x082c9653 in check_sleep (need_activity=1, sleep_now=1) at ./../src/thread.c:4043 #4 0x082cb262 in scheme_thread_block (sleep_time=0) at ./../src/thread.c:4751 #5 0x082cb7b5 in scheme_block_until (_f=0x820ca17 subp_done, fdf=0x820cb32 subp_needs_wakeup, data=0xb62bec90, delay=0) at ./../src/thread.c:4887 #6 0x0820cd8e in subprocess_wait (argc=1, argv=0xb6260eb4) at ./../src/port.c:8670 #7 0x0808f101 in _scheme_tail_apply_from_native_fast (rator=0x83c6f58, argc=1, argv=0xb6260eb4) at ./../src/schnapp.inc:34 #8 0x0808efdd in _scheme_tail_apply_from_native (rator=0x83c6f58, argc=1, argv=0xb6260eb4) at ./../src/schnapp.inc:64 #9 0x081080a8 in ts__scheme_tail_apply_from_native (rator=0x83c6f58, argc=1, argv=0xb6260eb4) at ./../src/jitcall.c:174 #10 0xb7780964 in ?? () #11 0x08093db8 in scheme_do_eval (obj=0x0, num_rands=2, rands=0xbfd1667c, get_value=-1) at ./../src/eval.c:2837 #12 0x080c3638 in scheme_finish_apply_for_prompt (prompt=0x0, _prompt_tag=0xb57b8150, proc=0xb57b7f90, argc=2, argv=0xbfd1667c) at ./../src/fun.c:5847 #13 0x080c3934 in scheme_apply_for_prompt (prompt=0xb39f3610, prompt_tag=0xb57b8150, proc=0xb57b7f90, argc=2, argv=0xbfd1667c) at ./../src/fun.c:5926 #14 0x080c4b13 in call_with_prompt (in_argc=5, in_argv=0xb6260ec0) at ./../src/fun.c:6325 #15 0x0808f101 in _scheme_tail_apply_from_native_fast (rator=0x83c4428, argc=5, argv=0xb6260ec0) at ./../src/schnapp.inc:34 #16 0x0808efdd in _scheme_tail_apply_from_native (rator=0x83c4428, argc=5, argv=0xb6260ec0) at ./../src/schnapp.inc:64 #17 0x081080a8 in ts__scheme_tail_apply_from_native (rator=0x83c4428, argc=5, argv=0xb6260ec0) at ./../src/jitcall.c:174 #18 0xb7780964 in ?? () #19 0xb7766064 in ?? () #20 0xb5902334 in ?? () #21 0x08093db8 in scheme_do_eval (obj=0x0, num_rands=0, rands=0x0, get_value=-1) at ./../src/eval.c:2837 #22 0x0808edda in _scheme_apply_multi_from_native (rator=0xb39efbe0, argc=0, argv=0x0) at ./../src/schnapp.inc:87 #23 0x081174d4 in ts__scheme_apply_multi_from_native (g7=0xb39efbe0, g8=0, g9=0x0) at ./../src/jit_ts.c:121 #24 0xb7780903 in ?? () #25 0x08093db8 in scheme_do_eval (obj=0x0, num_rands=0, rands=0x0, get_value=-1) at ./../src/eval.c:2837 #26 0x080ca33b in pre_post_dyn_wind (prepost=0xb39efbe0) at ./../src/fun.c:8214 #27 0x080ca3e7 in post_dyn_wind (d=0xb3a3fc48) at ./../src/fun.c:8237 #28 0x080cada6 in scheme_dynamic_wind (pre=0x80ca3bd pre_dyn_wind, act=0x80ca389 do_dyn_wind, post=0x80ca3d3 post_dyn_wind, jmp_handler=0, data=0xb3a3fc48) at ./../src/fun.c:8411 #29 0x080ca532 in dynamic_wind (c=3, argv=0xb6260f60) at ./../src/fun.c:8258 #30 0x0808f101 in _scheme_tail_apply_from_native_fast (rator=0x83c4858, argc=3, argv=0xb6260f60) at ./../src/schnapp.inc:34 #31 0x0808efdd in _scheme_tail_apply_from_native (rator=0x83c4858, argc=3, argv=0xb6260f60) at ./../src/schnapp.inc:64 #32 0x081080a8 in ts__scheme_tail_apply_from_native (rator=0x83c4858, argc=3, argv=0xb6260f60) at ./../src/jitcall.c:174 #33 0xb7780964 in ?? () #34 0x08093db8 in scheme_do_eval (obj=0x0, num_rands=11
Re: [racket-dev] crash with subprocess
It uses only a single place. The system is 32bit Linux: Linux 2.6.32.59-0.7-pae #1 SMP 2012-07-13 15:50:56 +0200 i686 i686 i386 GNU/Linux Tobias On Thu, 30 Aug 2012 15:17:05 +0200, Matthew Flatt mfl...@cs.utah.edu wrote: It looks like we still have problems with the `subprocess' implementation that cooperates with places. Does your program use multiple places, or just one? If it uses multiple places, does it use `subprocess' in multiple places? Is your platform 32-bit Linux? At Thu, 30 Aug 2012 13:38:23 +0200, Tobias Hammer wrote: Hi, i am experiencing random crashes when using subprocess followed by a subprocess-wait. My test program, that i call via subprocess is special, in that it kills itself very fast with a sigkill after executing. Unfortunately, i wasn't able to reproduce this behavior in a small sample but i could record three different core dumps with full debug info (attached). I tested with my own build of git head and 5.3.0.21. All crashes/freezes are preceded by the message unexpected error from waitpid(138321448[1]): 10 with a completely invalid pid argument to waitpid. The errno 10 is No child processes. What follows this message are random freezes (ctrl+c has no effect), heap corruptions or segfaults. I hope the supplied information is enough to locate whatever goes wrong, otherwise i can, of course send in more. Tobias -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] raco make cannot marshal value error
Thanks for the explanation. I think i understand now what i did wrong. The 3D syntax was a good hint for further reading. I digged up a thread* where you already had to explain it 10 years ago :) Tobias * http://www.cs.utah.edu/plt/mailarch/plt-scheme-2002/msg00111.html On Thu, 26 Jul 2012 15:36:44 +0200, Matthew Flatt mfl...@cs.utah.edu wrote: I agree that it's a bug, in a sense, that your program runs even though it cannot be compiled. This is an example of 3-D syntax: you're embedding a value (i.e., an instance of `s') that you can't write as a literal into the result of a macro expansion. I think 3-D syntax probably should not be allowed, but the macro system currently allows it. Most likely, using 3-D syntax is a bad idea. It's possible that you want to replace `#:transparent' with `#:prefab' in your example, since a prefab structure can be written as a literal. More likely, I think you want to generate an expression that constructs an `s' instead of generating an `s' instance in the macro expansion. At Thu, 26 Jul 2012 14:59:41 +0200, Tobias Hammer wrote: Hi, i have the following two files, one that only requires the other and calls a macro and the other one that defines that macro: === main.rkt #lang racket (require err.rkt) (a) === err.rkt #lang racket (begin-for-syntax (struct s (arg) #:transparent) (define (fun arg) (printf arg: ~a\n arg))) (define-syntax (a stx) (syntax-case stx () [(_) (with-syntax ([v #`#,(s 123)]) #'(begin (begin-for-syntax (fun v])) (provide a) When executing 'racket main.rkt' directly i get the expected output arg: #(struct:s 123) but when i try to call 'raco make main.rkt' instead, i get this strange error: arg: #(struct:s 123) write: cannot marshal value that is embedded in compiled code value: (s 123) context...: /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:388:6 /home_local/hamm_to/racket/racket-5.3.0.16/collects/racket/private/more-scheme.r kt:151:2: call-with-break-parameterization /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:188:5 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:508:26 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:501:42 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:466:0: maybe-compile-zo /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:579:2: do-check /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:653:4 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/commands/make.rkt:7 7:8: for-loop /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/commands/make.rkt: [running body] /home_local/hamm_to/racket/racket-5.3.0.16/collects/raco/raco.rkt: [running body] /home_local/hamm_to/racket/racket-5.3.0.16/collects/raco/main.rkt: [running body] I think i need a little help to understand what is happening here and what i am doing wrong. I had expected that running and compiling works on the same set of programs. Thanks for any clarification. Tobias -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] raco make cannot marshal value error
Hi, i have the following two files, one that only requires the other and calls a macro and the other one that defines that macro: === main.rkt #lang racket (require err.rkt) (a) === err.rkt #lang racket (begin-for-syntax (struct s (arg) #:transparent) (define (fun arg) (printf arg: ~a\n arg))) (define-syntax (a stx) (syntax-case stx () [(_) (with-syntax ([v #`#,(s 123)]) #'(begin (begin-for-syntax (fun v])) (provide a) When executing 'racket main.rkt' directly i get the expected output arg: #(struct:s 123) but when i try to call 'raco make main.rkt' instead, i get this strange error: arg: #(struct:s 123) write: cannot marshal value that is embedded in compiled code value: (s 123) context...: /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:388:6 /home_local/hamm_to/racket/racket-5.3.0.16/collects/racket/private/more-scheme.rkt:151:2: call-with-break-parameterization /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:188:5 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:508:26 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:501:42 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:466:0: maybe-compile-zo /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:579:2: do-check /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/cm.rkt:653:4 /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/commands/make.rkt:77:8: for-loop /home_local/hamm_to/racket/racket-5.3.0.16/collects/compiler/commands/make.rkt: [running body] /home_local/hamm_to/racket/racket-5.3.0.16/collects/raco/raco.rkt: [running body] /home_local/hamm_to/racket/racket-5.3.0.16/collects/raco/main.rkt: [running body] I think i need a little help to understand what is happening here and what i am doing wrong. I had expected that running and compiling works on the same set of programs. Thanks for any clarification. Tobias -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Strange error with gui and ffi
Hi, i am getting a strange error message from racket if i use racket/gui in the main module and only racket in a required one. If i load another shared lib in the required module i get the following output: jpeg: unsupported library version: unknown === context === racket-5.2.0.1/collects/racket/draw/unsafe/jpeg.rkt: [running body] racket-5.2.0.1/collects/racket/draw/private/bitmap.rkt: [traversing imports] racket-5.2.0.1/collects/racket/draw/private/dc.rkt: [traversing imports] racket-5.2.0.1/collects/racket/draw/private/svg-dc.rkt: [traversing imports] racket-5.2.0.1/collects/racket/draw.rkt: [traversing imports] racket-5.2.0.1/collects/mred/private/kernel.rkt: [traversing imports] racket-5.2.0.1/collects/mred/private/const.rkt: [traversing imports] racket-5.2.0.1/collects/mred/private/check.rkt: [traversing imports] racket-5.2.0.1/collects/mred/private/mred.rkt: [traversing imports] racket-5.2.0.1/collects/mred/mred.rkt: [traversing imports] racket-5.2.0.1/collects/mred/main.rkt: [traversing imports] racket-5.2.0.1/collects/racket/gui/base.rkt: [traversing imports] racket-5.2.0.1/collects/racket/gui.rkt: [traversing imports] guibug.rkt: [traversing imports] Same problem with last nightly. It seems like it is happening only if the shared lib is statically linked to another libjpeg but as far as i understand that should have no invfuence on anything. It's also not happening if i use racket/gui instead of only racket as lang in the required module. I used the following code to produce the error. guibug.rkt: #lang racket/gui (require guibug_req.rkt) guibug_req.rkt #lang racket (require ffi/unsafe) (require racket/runtime-path) (define-runtime-path lib-path libVLCore) (define lib-handle (ffi-lib lib-path)) Has anyone an idea what is happening there? Tobias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Strange error with gui and ffi
Am 01/19/2012 02:02 PM, schrieb Matthew Flatt: At Thu, 19 Jan 2012 13:30:40 +0100, Tobias Hammer wrote: i am getting a strange error message from racket if i use racket/gui in the main module and only racket in a required one. If i load another shared lib in the required module i get the following output: jpeg: unsupported library version: unknown It does seem that loading libVLCore interferes with the use of libjpeg; if you use `racket/gui' in guibug_req.rkt, that would avoid the problem by initializing the libjpeg use in `racket/draw' (via `racket/gui') before libVLCore is loaded. Sure, that would be a possibility. Can you say more about the platform, libVLCore's linking, and the libjpeg that libVLCore uses? Platform is Suse linux i386. The jpeg lib is IJG (http://www.ijg.org) release 6b from 1998. So it's pretty old and may be incompatible to the current version. But i can't replace it because the readme says it may be modified. The linking is this libjpeg as normal static lib (.a) and the libVLCore as regular shared lib that includes the static lib. Even if libVLCore is statically linked to a libjpeg, I think it could interact with dynamic loading of another libjpeg, depending on the platform and linking options. I digged a bit more and found the following line the rackets libffi: handle = dlopen(name, RTLD_NOW | RTLD_GLOBAL); If i interpret the manpages correct that means that all symbols from the lib are loaded and used to resolve references. That may be convenient for the libraries that the racket core uses but may lead strange behavior like the one i got whenever name clashes happen. Maybe it would be a good idea to make this import all behavior optional. Tobias _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] raco make broken
Hello, raco make --no-deps seems to be broken: default-load-handler: cannot open input file: racket-5.2.0.6/collects/compiler/cffi.rkt (No such file or directory; errno=2) === context === standard-module-name-resolver racket-5.2.0.6/collects/compiler/compiler-unit.rkt:82:2: core50 racket-5.2.0.6/collects/compiler/commands/make.rkt: [running body] racket-5.2.0.6/collects/raco/raco.rkt: [running body] racket-5.2.0.6/collects/raco/main.rkt: [running body] Tested with latest nightly build. Tobias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
