Re: [racket-dev] SIGSEGV MAPERR si_code 1 fault on addr (nil) when inserting rows via db / SQLite
Eric, I can't help fixing the problem with your current code, but I can point you to the docs where Ryan says you should probably use functions like start-transaction, commit-transaction and call-with-transaction (in case you missed those). http://docs.racket-lang.org/db/query-api.html?q=db#(part._transactions) PostgreSQL, MySQL, and SQLite connections are discouraged from using transaction-changing SQL statements So, for example, (query-exec db BEGIN TRANSACTION) becomes (start-transaction db). []'s Rodolfo Carvalho _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] SIGSEGV MAPERR si_code 1 fault on addr (nil) when inserting rows via db / SQLite
Thanks for the report. Your program led me to find *a* bug (a space leak in the statement finalizer thread). Fixing that bug causes your program to succeed consistently, but the bug I found should not have caused the segfault, and I haven't been able to find an underlying problem. I'll push the intermediate fix; if you still run into problems let me know. Ryan On 11/12/2011 05:42 PM, Eric Hanchrow wrote: This is with racket 5.2, from Ubuntu: Package: racket Version: 5.2.0-3 When I invoke the following file (on Ubuntu Linux erich-laptop 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux), I see $ rm -rfv /tmp/bug* ; racket ./repro.rkt removed `/tmp/buggissimo' SIGSEGV MAPERR si_code 1 fault on addr (nil) /bin/bash: line 1: 12150 Aborted racket ./repro.rkt #lang racket (require (only-in db query-exec query-value sqlite3-connect)) (define db (sqlite3-connect #:database /tmp/buggissimo #:mode 'create)) (query-exec db CREATE TABLE IF NOT EXISTS log_word_map(word TEXT, log_id INTEGER, PRIMARY KEY (word, log_id) ON CONFLICT FAIL)) (query-exec db BEGIN TRANSACTION) (for ([x (in-range 2)]) (query-exec db insert into log_word_map values (?, ?) (number-string x) 99)) (query-exec db COMMIT) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] DrRacket autocompletion change
I've just pushed a change that will hopefully make DrRacket's autocompletion more helpful. It now will suggest results based on the same fuzzy search that the documentation search uses. So, if you enter: #lang racket cur-dir and hit Ctrl-/ You'll get a menu with the following choices: current-directory current-load-relative-directory current-target-directory-getter current-target-plt-directory-getter current-write-relative-directory The search method and ranking is still pretty simple. I'm happy to take suggestions on how to improve it, especially if there are particular cases where you don't get the results you'd like. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] plea for short planet syntax in student languages?
Thank you very much for this! The documentation for *SL needs updating to reflect support for the short planet syntax, e.g. http://docs.racket-lang.org/htdp-langs/beginner.html?q=require#(form._((lib._lang/htdp-beginner..rkt)._require)) --- nadeem On Fri, Oct 7, 2011 at 12:50 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I've just now pushed a change for this. Robby On Wed, Oct 5, 2011 at 11:20 AM, John Clements cleme...@brinckerhoff.org wrote: I'm using the rsound planet package in beginning student languages, and requiring them to type (require (planet main.rkt (clements rsound.plt 2 6))) at the top of every file is a bit painful. Would it be difficult to support the shorter (require (planet clements/rsound)) syntax in the student languages? John _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] struct type properties and field accesses
Many built-in structure type properties (such as `prop:procedure' and `prop:set!-transformer') support providing an integer index into the structure to reference a particular field that should supply the value. This is a very useful pattern, but unfortunately, it's not one that any Racket programs can use. In particular, the procedure calling mechanism and the expander get around the inspector system to implement this behavior. It would be nice if additional structure type properties could do this as well. Here's a suggestion of how it could work. `make-struct-type-property' adds an optional argument which specifies that an integer value is an index into the structure. In that case, the generated property accessor procedure performs the field lookup itself, avoiding the inspector system. Note that this doesn't reduce the power of the inspector system, since the structure type property value could be the struct accessor procedure paired with the index, and then you could write your own struct property accessor procedure that did the dispatch. This is less convenient for both users and definers, and thus it would be nice to build it in. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] struct type properties and field accesses
On 11/13/2011 09:21 PM, Sam Tobin-Hochstadt wrote: Many built-in structure type properties (such as `prop:procedure' and `prop:set!-transformer') support providing an integer index into the structure to reference a particular field that should supply the value. This is a very useful pattern, but unfortunately, it's not one that any Racket programs can use. In particular, the procedure calling mechanism and the expander get around the inspector system to implement this behavior. It would be nice if additional structure type properties could do this as well. Here's a suggestion of how it could work. `make-struct-type-property' adds an optional argument which specifies that an integer value is an index into the structure. In that case, the generated property accessor procedure performs the field lookup itself, avoiding the inspector system. Note that this doesn't reduce the power of the inspector system, since the structure type property value could be the struct accessor procedure paired with the index, and then you could write your own struct property accessor procedure that did the dispatch. This is less convenient for both users and definers, and thus it would be nice to build it in. I think you can do this yourself already using the guard argument of make-struct-type-property. The guard function gets a list that contains the values that struct-type-info would return for the new structure type if it skipped the immediate current-inspector control check. Ryan _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
