Re: [racket-dev] Embedding racket in vim

[Eric Dobson]

+correct vim group.


On Mon, Dec 10, 2012 at 10:25 PM, Eric Dobson wrote:

> I have recently installed a version of vim with the mzscheme option
> enabled. And it sortof works except that some times it segfaults or has
> other memory corruption issues. So I enabled MZ_GC_CHECK when compiling
> vim, and now I get the corruption every single time on startup.
>
> Here is the output from gdb when running it:
>
> GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC
> 2012)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "x86_64-apple-darwin"...
> warning: Unable to read symbols for
> Racket.framework/Versions/5.3.1.9_3m/Racket (file not found).
>
> warning: Unable to read symbols from "Racket" (not yet mapped into memory).
> Reading symbols for shared libraries .. done
>
> (gdb) run
> Starting program: /Users/endobson/proj/vim/install/bin/vim
> Reading symbols for shared libraries
> .+...
> done
> Reading symbols for shared libraries . done
> ?: bad module path
>   in: #
>   context...:
>standard-module-name-resolver
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x00a0
> 0x000100328d99 in scheme_top_level_do_worker (dyn_state=0x0,
> k=0x7fff5fbfdd10, eb=1000, new_thread=1606409488) at fun.c:1227
> 1227scheme_longjmp(*save, 1);
> (gdb) bt
> #0  0x000100328d99 in scheme_top_level_do_worker (dyn_state=0x0,
> k=0x7fff5fbfdd10, eb=1000, new_thread=1606409488) at fun.c:1227
> #1  0x0001003ff41e in _module_resolve (modidx=0x103004150,
> stx=0x103004068, env=0x0, load_it=1) at module.c:3860
> #2  0x00010041162a in parse_requires () at schthread.h:376
> #3  0x0001004122e4 in do_namespace_require () at module.c:7685
> #4  0x0001004123ce in scheme_namespace_require (r=0x103ec8008) at
> module.c:1316
> #5  0x0001001574dd in _mh_execute_header ()
> #6  0x0001001585d8 in _mh_execute_header ()
> #7  0x00010005bc43 in _mh_execute_header ()
> #8  0x00010004ca4a in _mh_execute_header ()
> #9  0x00010015f608 in _mh_execute_header ()
> #10 0x0001002a6093 in call_with_basic (data=0x103ec8008) at
> schthread.h:376
> #11 0x0001002a64a8 in scheme_main_setup (no_auto_statics=1606414024,
> _main=0x7fff5fbfe268, argc=6433496, argv=0x7fff5fbfe240) at salloc.c:194
> #12 0x000100161fff in _mh_execute_header ()
> #13 0x7fff939eb7e1 in start ()
> (gdb)
>
> I can include more information if you can tell me what is useful.
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Embedding racket in vim

[Eric Dobson]

I have recently installed a version of vim with the mzscheme option
enabled. And it sortof works except that some times it segfaults or has
other memory corruption issues. So I enabled MZ_GC_CHECK when compiling
vim, and now I get the corruption every single time on startup.

Here is the output from gdb when running it:

GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC
2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...
warning: Unable to read symbols for
Racket.framework/Versions/5.3.1.9_3m/Racket (file not found).

warning: Unable to read symbols from "Racket" (not yet mapped into memory).
Reading symbols for shared libraries .. done

(gdb) run
Starting program: /Users/endobson/proj/vim/install/bin/vim
Reading symbols for shared libraries
.+...
done
Reading symbols for shared libraries . done
?: bad module path
  in: #
  context...:
   standard-module-name-resolver

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00a0
0x000100328d99 in scheme_top_level_do_worker (dyn_state=0x0,
k=0x7fff5fbfdd10, eb=1000, new_thread=1606409488) at fun.c:1227
1227scheme_longjmp(*save, 1);
(gdb) bt
#0  0x000100328d99 in scheme_top_level_do_worker (dyn_state=0x0,
k=0x7fff5fbfdd10, eb=1000, new_thread=1606409488) at fun.c:1227
#1  0x0001003ff41e in _module_resolve (modidx=0x103004150,
stx=0x103004068, env=0x0, load_it=1) at module.c:3860
#2  0x00010041162a in parse_requires () at schthread.h:376
#3  0x0001004122e4 in do_namespace_require () at module.c:7685
#4  0x0001004123ce in scheme_namespace_require (r=0x103ec8008) at
module.c:1316
#5  0x0001001574dd in _mh_execute_header ()
#6  0x0001001585d8 in _mh_execute_header ()
#7  0x00010005bc43 in _mh_execute_header ()
#8  0x00010004ca4a in _mh_execute_header ()
#9  0x00010015f608 in _mh_execute_header ()
#10 0x0001002a6093 in call_with_basic (data=0x103ec8008) at
schthread.h:376
#11 0x0001002a64a8 in scheme_main_setup (no_auto_statics=1606414024,
_main=0x7fff5fbfe268, argc=6433496, argv=0x7fff5fbfe240) at salloc.c:194
#12 0x000100161fff in _mh_execute_header ()
#13 0x7fff939eb7e1 in start ()
(gdb)

I can include more information if you can tell me what is useful.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] And/or as procedures when not in application position

[Sam Tobin-Hochstadt]

On Mon, Dec 10, 2012 at 11:05 PM, Matthias Felleisen
 wrote:
>
> If you can make syntax identifier thingies like and behave as in a 
> short-cutting way when they are used in a context such as andmap, I have no 
> objections.

You would need a different list operation -- you can't express
`andmap` in terms of `foldr` no matter what you do with `and` (but you
surely know that).

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] And/or as procedures when not in application position

[Matthias Felleisen]

If you can make syntax identifier thingies like and behave as in a 
short-cutting way when they are used in a context such as andmap, I have no 
objections. 

By coincidence, I talked to Vincent an idea like that today but not and and 
andmap. 




On Dec 10, 2012, at 8:53 PM, Sam Tobin-Hochstadt wrote:

> On Mon, Dec 10, 2012 at 7:07 PM, Matthias Felleisen
>  wrote:
>> 
>> Using and and or as higher-order functions, say for (fold (combine f and) #t 
>> l) has performance implications. It is quite different from (andmap f l).
> 
> In one sense, this is obviously true, since `andmap` is
> short-circuiting.  But with a sightly different implementation of
> `andmap`, I think (based on looking at the decompiled output) that
> these would generate basically identical code.  So the extra
> higher-orderness shouldn't be a performance problem here.
> 
> Sam



smime.p7s
Description: S/MIME cryptographic signature
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] And/or as procedures when not in application position

[Sam Tobin-Hochstadt]

On Mon, Dec 10, 2012 at 7:07 PM, Matthias Felleisen
 wrote:
>
> Using and and or as higher-order functions, say for (fold (combine f and) #t 
> l) has performance implications. It is quite different from (andmap f l).

In one sense, this is obviously true, since `andmap` is
short-circuiting.  But with a sightly different implementation of
`andmap`, I think (based on looking at the decompiled output) that
these would generate basically identical code.  So the extra
higher-orderness shouldn't be a performance problem here.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2

[Neil Van Dyke]

Jay McCarthy wrote at 12/10/2012 02:22 PM:
On Sun, Dec 9, 2012 at 1:26 PM, Neil Van Dyke > wrote:



* I'm very concerned about discarding support for mixing versions
of packages.  PLaneT 1 didn't fully nail this, but I suspect
planet2 is punting needlessly, rather than getting data and
solving problems (perhaps due to changing mission, as speculated
in next two points).


My rationale is that what OSes provide is good enough for wide uses 
and we can more easily build the right versioned package system on top 
of this than a non-versioned package system on top of one that is 
versioned.


Perhaps some multiple version support can be grafted on later 
satisfactorily.  I'm just surprised by abandoning the problem, after 
PLaneT made a credible first attempt, and before Racket actually got 
much experience with apps built from lots of independently-developed 
packages.


I still suspect that multiple versions support is a good thing and 
doable.  I wonder whether the design of a new packaging system would 
benefited from having worked through the versioning problem in the 
earlier stages of design, rather than after migrating people from one 
system to a new one.  I don't really know.


For example, the various library collections on P1 (like scheme, 
unlib, etc) seems to me a product of the pain of P1 deployment 
encouraging monolithic packages.


There are also lots of small, loosely-coupled packages in PLaneT.  
Certainly, getting things into PLaneT is tricky, and sometimes, even if 
people got one version into PLaneT, sometimes they'd tell people "a 
better version is in Git" because they didn't want to go through PLaneT 
hoops again.  And there are other reasons people make monolithic 
libraries -- this is not at all peculiar to PLaneT.  Which is part of 
why I was planning in my book to push people to developing around 
loosely-coupled reusable modules, with very low friction to moving the 
module to PLaneT.  I was working on tools to make that a reasonable story.



* Related to previous point, it also looks like there *might*
(unclear) be a desire to increasingly centralize or canonicalize
some of the kinds of library work that I've been thinking are
generally best done in a more decentralized and organic manner.
 If so, have to be careful with this.


I assume you are referring to the suggestion to (a) use known 
collections like data, (b) not give things cute names, and (c) not 
name things after developers. 


No, it looked like it might be an implicit, pervasive influence.

This would, for instance, make it so that we have "net/soap" package 
rather than "roap", "unroap", and "super-soap". I think this is a good 
thing. We should be encouraging collaboration to produce excellent 
packages rather than having many 20% solutions.


If one has the resources to pull this off, more power to one.  I'm not 
sure Racket has the resources.  (One way you could do it is if PLT 
Design hired expensive full-time engineers who don't have 
research/teaching commitments.  Or you could do it as projects for 
undergrad team software engineering courses, but I suspect the quality 
of design and implementation would often not be up to what people come 
to Racket for.)


I suspect there's still a big place for grassroots library development 
for Racket.  So I hope the design of the new package system hasn't been 
biased away from grassroots needlessly.


Above are my main points.  Rest of this email is asides, some 
supporting, and some tangential.  All can be skipped.


If you want me to see a response, please CC me.

* * *

Aside #1: On your "net/soap" example... I think a generally better 
practice would be to name it "soap" rather than try to munge a 
conceptual taxonomy into the name as "net/soap", unless "net/" is some 
intertangled framework (which it doesn't seem to be).  The taxonomies 
change over time -- more frequently than the names should.  I think one 
of the PLT lists discussed this before.  Thankfully, people nowadays 
avoid putting these taxonomies as part of the key for most purposes.  
For example, package namespaces for various GNU/Linux distros are flat, 
even if they tend to use taxonomies for UI purposes elsewhere.  For a 
negative example fresh in my mind, CDDB is reviled for using genre as 
part of its key, rather than showing more foresight with their namespace.


Aside #2: Don't be *too* hard on the cutesy names.  Even when projects 
do the officially blessed module with boring name, they tend to wind up 
with better modules arising separate from the official one.  If they do 
eventually move to bring the iconoclast into the fold, blessing it with 
an official generic name, sometimes they tack a "2", "new", "ng", or 
other suffix/prefix onto the old generic name, or sometimes they simply 
break backward compatibility, so you get people talking about which 
version of a language you used for an app when they're really aski

Re: [racket-dev] And/or as procedures when not in application position

[Matthias Felleisen]

Using and and or as higher-order functions, say for (fold (combine f and) #t l) 
has performance implications. It is quite different from (andmap f l). 

We have thought about this for the student languages on and off. And in the end 
I have always come to the conclusion that students must find out about such 
differences and must know about them. We might as well throw them in with the 
first course. 





On Dec 10, 2012, at 6:16 PM, J. Ian Johnson wrote:

> I just made a pull request for making and/or expand to functions that perform 
> and/or following a discussion with stamourv and asumu. Vincent believes these 
> additions should also be made to the student languages, but I thought I'd 
> start a discussion about this before doing that work.
> What are people's thoughts on this?
> -Ian
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev



smime.p7s
Description: S/MIME cryptographic signature
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] And/or as procedures when not in application position

[Carl Eastlund]

I don't like this idea for Racket.  The macros "and" and "or" do not behave
like functions any more than "if" does.  This isn't Haskell, our functions
are eager while our conditional forms are short-circuiting.  If we want
first-order values that perform conjunction and disjunction, but eagerly,
we should give them separate names.  Otherwise we're going to get some very
confusing programs.  For instance, if you treat "and" / "or" as functions,
various program transformations that seem sensible no longer hold.  For
instance,

(and #true 'result (error "oh no"))

is not the same as

(let {[f and]} (f #true 'result (error "oh no")))

...if "and" produces a short-circuiting form in the former case and an
eager function in the latter.

I do agree that functions performing boolean conjunction/disjunction are
useful.  We could call these things andf / orf, and/proc / or/proc, conj /
disj, or any number of other paired names that aren't already taken for
conditional special forms.

Carl Eastlund



On Mon, Dec 10, 2012 at 6:16 PM, J. Ian Johnson  wrote:

> I just made a pull request for making and/or expand to functions that
> perform and/or following a discussion with stamourv and asumu. Vincent
> believes these additions should also be made to the student languages, but
> I thought I'd start a discussion about this before doing that work.
> What are people's thoughts on this?
> -Ian
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] And/or as procedures when not in application position

[J. Ian Johnson]

I just made a pull request for making and/or expand to functions that perform 
and/or following a discussion with stamourv and asumu. Vincent believes these 
additions should also be made to the student languages, but I thought I'd start 
a discussion about this before doing that work.
What are people's thoughts on this?
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] planet2

[Jay McCarthy]

On Sun, Dec 9, 2012 at 1:26 PM, Neil Van Dyke  wrote:

> My biggest comments on planet2...
>
> * I like the general ideas of permitting more decentralized sharing of
> packages (such as through some kind of Git URLs).
>
> * I like the idea of making it easier to modify the source of a package
> and share changes with upstream (which is needlessly cumbersome with PLaneT
> 1).
>
> * I'm very concerned about discarding support for mixing versions of
> packages.  PLaneT 1 didn't fully nail this, but I suspect planet2 is
> punting needlessly, rather than getting data and solving problems (perhaps
> due to changing mission, as speculated in next two points).
>

My rationale is that what OSes provide is good enough for wide uses and we
can more easily build the right versioned package system on top of this
than a non-versioned package system on top of one that is versioned.


> * Other than GitHub support, a lot of what I saw in the planet2
> documentation was not intuitive to me, wrt how I was thinking would be a
> good direction for Racket grassroots package development.  It looks like
> maybe planet2 is biased towards the way core developers work (e.g.,
> centralized, large, monolithic code base, with single version), and/or
> towards modularizing Racket distributions, rather than towards grassroots
> package development.
>

I'm not sure how to respond to this because I don't think it's concrete
enough for me. I'd say that I see P2 has making it easier to not be
centralized and to make smaller packages, because they can provide single
modules of various collections (like a new data/ package) without having to
introduce a whole new namespace. I see a lot of failure in this department
with how P1 was used. For example, the various library collections on P1
(like scheme, unlib, etc) seems to me a product of the pain of P1
deployment encouraging monolithic packages.


> * Related to previous point, it also looks like there *might* (unclear) be
> a desire to increasingly centralize or canonicalize some of the kinds of
> library work that I've been thinking are generally best done in a more
> decentralized and organic manner.  If so, have to be careful with this.
>

I assume you are referring to the suggestion to (a) use known collections
like data, (b) not give things cute names, and (c) not name things after
developers. This would, for instance, make it so that we have "net/soap"
package rather than "roap", "unroap", and "super-soap". I think this is a
good thing. We should be encouraging collaboration to produce excellent
packages rather than having many 20% solutions. It certainly requires more
work, but it seems to have had good results in the Perl, Ruby, and Haskell
communities where this seems to be the common library creation practice.
Nevertheless, these are just guidelines and the system makes no attempt to
enforce them.


> * We'd talked about planet2 on-and-off for years, but I didn't realize
> planet2 was imminent, so I recently somehow managed to spent a lot of
> unpleasant time working on PLaneT tools and such that now look moot in
> light of planet2.  Every now and then, the rug gets pulled out from under a
> non-core developer (this has happened a few times that I know of), and it
> can be a waste of energy and morale, so we should keep trying to avoid
> rug-pulling when practical.
>
> I have numerous small comments, (like, just from glancing at currently
> open browser window) you probably don't want to call anything "PNS", and
> the names "galaxy", "solar-system", and "planet" would be confusing
> (something else already called "planet" that is very related, plus running
> into HtDP "world", "universe", etc.).  Before I'd nitpick at that small
> level of issue, I'd need the bigger questions above addressed, and then I'd
> have to get practical experience with planet2 and comment on that level of
> issue.
>

Although I wrote it, I'm not attached to these particular bike shed
colours. I'd rather rename things to keep the wa than fight about why one
analogy is good and one analogy is bad. All the names you've mentioned have
been given new labels from my first prototypes, and if people would like to
submit patches to rename things that others like, I won't stand in the way.

Jay

-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Contract violation from custodian shutdown

[Neil Toronto]

Randomly. It didn't happen often... maybe 1 in 15 times? I think you 
could open and run this program in a tab and then immediately close it:


#lang racket
(require math/bigfloat)

Do that a lot, and you might see it. :/ You'd have to reenable the 
custodian shutdown callback.


On 12/10/2012 08:57 AM, Matthew Flatt wrote:

It's hard to say where the bug is, but there may be some problem in the
implementation of custodians of `register-custodian-shutdown'. Is it
repeatable?

At Thu, 06 Dec 2012 16:48:37 -0700, Neil Toronto wrote:

I just got this message on my console, I think after closing a tab,
which coincided with DrRacket hanging:


eventspace-shutdown?: contract violation
expected: eventspace?
given: #
context...:
 /home/neil/plt/collects/mred/private/wx/common/queue.rkt:201:0:
shutdown-eventspace!


It's obviously because of this code, which is near the top of
"math/private/bigfloat/mpfr.rkt":


(define mpfr-free-cache (get-mpfr-fun 'mpfr_free_cache (_fun -> _void)))

(define mpfr-shutdown
(register-custodian-shutdown mpfr-free-cache (λ (free) (free


Did I misunderstand something, or is this someone else's bug?

Neil ⊥
_
   Racket Developers list:
   http://lists.racket-lang.org/dev


_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] unicode Delta vs unicode increment

[Robby Findler]

Argh. I confuse easily. I think what's currently pushed is right. Knock on wood.

Robby

On Mon, Dec 10, 2012 at 11:43 AM, Matthew Flatt  wrote:
> No --- it should be 916 (= #x394), which is Greek uppercase delta.
>
> At Mon, 10 Dec 2012 11:34:13 -0600, Robby Findler wrote:
>> Lets just double check. This expression is supposed to return 8710, right?
>>
>> #lang racket
>> (require mrlib/tex-table)
>> (char->integer (string-ref (list-ref (assoc "Delta" tex-shortcut-table) 1) 
>> 0))
>>
>> On Mon, Dec 10, 2012 at 11:30 AM, Matthew Flatt  wrote:
>> > No, I think this commit is actually right. I got confused, and I
>> > managed to confuse Robby...
>> >
>> > At Mon, 10 Dec 2012 11:26:42 -0600, Robby Findler wrote:
>> >> I recently pushed this commit:
>> >>
>> >>
>> http://git.racket-lang.org/plt/commit/6babc9ec56d60fba9f3fe6969901a378da266f82
>> >>
>> >> that changes DrRacket's reponse to typing \Delta.
>> >>
>> >> I see now, however, that this commit changed it FROM U+0394 to U+2206,
>> >> ie from Delta to Increment. Here's the chars in question:
>> >>
>> >>   http://www.fileformat.info/info/unicode/char/2206/index.htm
>> >>   http://www.fileformat.info/info/unicode/char/394/index.htm
>> >>
>> >> But I think this is backwards and the pull request commentary suggests
>> >> that there might be some confusion.
>> >>
>> >> So I think I should probably revert this commit and stick with \Delta
>> >> as the actual Delta character.
>> >>
>> >> Am I getting this right? Or am I backwards yet again...?
>> >>
>> >> Thanks,
>> >> Robby
>> >> _
>> >>   Racket Developers list:
>> >>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] "warning: CRLF will be replaced by LF in {src/worksp/README src/worksp/gracket/gracket.rc src/worksp/racket/racket.rc}" ?

[Matthew Flatt]

I've probably mangled the line endings of those file as I wrestled with
Windows, git, and MinGW.

I'm not sure what you should do right now, but I'll look into fixing
the files, and hopefully that will just fix things on your machine.

At Mon, 10 Dec 2012 12:35:29 -0500, Greg Hendershott wrote:
> Preface: I'm sorry if this is a really basic question, but I'm new to
> this Git workflow, so I'm cautious because I don't want to cause a
> nuisance with some future pull request.
> 
> I just did a `git fetch` of the upstream PLT master, then a `git
> merge` into my master.
> 
> greg@mbp in ~/src/plt/racket on master
> $ git fetch upstream
> remote: Counting objects: 327, done.
> remote: Compressing objects: 100% (72/72), done.
> remote: Total 216 (delta 174), reused 183 (delta 142)
> Receiving objects: 100% (216/216), 40.89 KiB, done.
> Resolving deltas: 100% (174/174), completed with 102 local objects.
> From github.com:plt/racket
>0dfcf63..6aa6dc0  master -> upstream/master
> 
> greg@mbp in ~/src/plt/racket on master
> $ git merge upstream/master
> Merge made by the 'recursive' strategy.
> warning: CRLF will be replaced by LF in src/worksp/README.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in src/worksp/gracket/gracket.rc.
> The file will have its original line endings in your working directory.
> warning: CRLF will be replaced by LF in src/worksp/racket/racket.rc.
> The file will have its original line endings in your working directory.
>  collects/compiler/private/xform.rkt|   54 +-
>  collects/math/private/bigfloat/gmp.rkt |7 +-
>  collects/math/private/bigfloat/mpfr.rkt|   34 +-
>  ... etc. ...
> 
> 
> At the moment, git tells me I have local uncommitted changes:
> 
> greg@mbp in ~/src/plt/racket on master*
> $ git status
> # On branch master
> # Your branch is ahead of 'origin/master' by 22 commits.
> #
> # Changes not staged for commit:
> #   (use "git add ..." to update what will be committed)
> #   (use "git checkout -- ..." to discard changes in working directory)
> #
> # modified:   src/worksp/README
> # modified:   src/worksp/gracket/gracket.rc
> # modified:   src/worksp/racket/racket.rc
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> 
> 
> 1. What is the correct thing for me to do?  Add/commit these to my
> local master, or something else?
> 
> 2. I double-checked with `git config -l`, and I do _not_ have
> core.autocrlf enabled. Is that correct or instead should I enable it?
> 
> Thank you.
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] unicode Delta vs unicode increment

[Matthew Flatt]

No --- it should be 916 (= #x394), which is Greek uppercase delta.

At Mon, 10 Dec 2012 11:34:13 -0600, Robby Findler wrote:
> Lets just double check. This expression is supposed to return 8710, right?
> 
> #lang racket
> (require mrlib/tex-table)
> (char->integer (string-ref (list-ref (assoc "Delta" tex-shortcut-table) 1) 0))
> 
> On Mon, Dec 10, 2012 at 11:30 AM, Matthew Flatt  wrote:
> > No, I think this commit is actually right. I got confused, and I
> > managed to confuse Robby...
> >
> > At Mon, 10 Dec 2012 11:26:42 -0600, Robby Findler wrote:
> >> I recently pushed this commit:
> >>
> >> 
> http://git.racket-lang.org/plt/commit/6babc9ec56d60fba9f3fe6969901a378da266f82
> >>
> >> that changes DrRacket's reponse to typing \Delta.
> >>
> >> I see now, however, that this commit changed it FROM U+0394 to U+2206,
> >> ie from Delta to Increment. Here's the chars in question:
> >>
> >>   http://www.fileformat.info/info/unicode/char/2206/index.htm
> >>   http://www.fileformat.info/info/unicode/char/394/index.htm
> >>
> >> But I think this is backwards and the pull request commentary suggests
> >> that there might be some confusion.
> >>
> >> So I think I should probably revert this commit and stick with \Delta
> >> as the actual Delta character.
> >>
> >> Am I getting this right? Or am I backwards yet again...?
> >>
> >> Thanks,
> >> Robby
> >> _
> >>   Racket Developers list:
> >>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] unicode Delta vs unicode increment

[Robby Findler]

Lets just double check. This expression is supposed to return 8710, right?

#lang racket
(require mrlib/tex-table)
(char->integer (string-ref (list-ref (assoc "Delta" tex-shortcut-table) 1) 0))

On Mon, Dec 10, 2012 at 11:30 AM, Matthew Flatt  wrote:
> No, I think this commit is actually right. I got confused, and I
> managed to confuse Robby...
>
> At Mon, 10 Dec 2012 11:26:42 -0600, Robby Findler wrote:
>> I recently pushed this commit:
>>
>> http://git.racket-lang.org/plt/commit/6babc9ec56d60fba9f3fe6969901a378da266f82
>>
>> that changes DrRacket's reponse to typing \Delta.
>>
>> I see now, however, that this commit changed it FROM U+0394 to U+2206,
>> ie from Delta to Increment. Here's the chars in question:
>>
>>   http://www.fileformat.info/info/unicode/char/2206/index.htm
>>   http://www.fileformat.info/info/unicode/char/394/index.htm
>>
>> But I think this is backwards and the pull request commentary suggests
>> that there might be some confusion.
>>
>> So I think I should probably revert this commit and stick with \Delta
>> as the actual Delta character.
>>
>> Am I getting this right? Or am I backwards yet again...?
>>
>> Thanks,
>> Robby
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] unicode Delta vs unicode increment

[Matthew Flatt]

No, I think this commit is actually right. I got confused, and I
managed to confuse Robby...

At Mon, 10 Dec 2012 11:26:42 -0600, Robby Findler wrote:
> I recently pushed this commit:
> 
> http://git.racket-lang.org/plt/commit/6babc9ec56d60fba9f3fe6969901a378da266f82
> 
> that changes DrRacket's reponse to typing \Delta.
> 
> I see now, however, that this commit changed it FROM U+0394 to U+2206,
> ie from Delta to Increment. Here's the chars in question:
> 
>   http://www.fileformat.info/info/unicode/char/2206/index.htm
>   http://www.fileformat.info/info/unicode/char/394/index.htm
> 
> But I think this is backwards and the pull request commentary suggests
> that there might be some confusion.
> 
> So I think I should probably revert this commit and stick with \Delta
> as the actual Delta character.
> 
> Am I getting this right? Or am I backwards yet again...?
> 
> Thanks,
> Robby
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] unicode Delta vs unicode increment

[Robby Findler]

I recently pushed this commit:

http://git.racket-lang.org/plt/commit/6babc9ec56d60fba9f3fe6969901a378da266f82

that changes DrRacket's reponse to typing \Delta.

I see now, however, that this commit changed it FROM U+0394 to U+2206,
ie from Delta to Increment. Here's the chars in question:

  http://www.fileformat.info/info/unicode/char/2206/index.htm
  http://www.fileformat.info/info/unicode/char/394/index.htm

But I think this is backwards and the pull request commentary suggests
that there might be some confusion.

So I think I should probably revert this commit and stick with \Delta
as the actual Delta character.

Am I getting this right? Or am I backwards yet again...?

Thanks,
Robby
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Safe errno access across platforms.

[Matthew Flatt]

At Wed, 5 Dec 2012 12:46:19 -0800, Nathan wrote:
> Approach 2: Expose underlying error values directly and unambiguously
> without any abstraction.

This sounds ok to me, too. It may be another week from now before I
have a chance to work on it, though.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Contract violation from custodian shutdown

[Matthew Flatt]

It's hard to say where the bug is, but there may be some problem in the
implementation of custodians of `register-custodian-shutdown'. Is it
repeatable?

At Thu, 06 Dec 2012 16:48:37 -0700, Neil Toronto wrote:
> I just got this message on my console, I think after closing a tab, 
> which coincided with DrRacket hanging:
> 
> 
> eventspace-shutdown?: contract violation
>expected: eventspace?
>given: #
>context...:
> /home/neil/plt/collects/mred/private/wx/common/queue.rkt:201:0: 
> shutdown-eventspace!
> 
> 
> It's obviously because of this code, which is near the top of 
> "math/private/bigfloat/mpfr.rkt":
> 
> 
> (define mpfr-free-cache (get-mpfr-fun 'mpfr_free_cache (_fun -> _void)))
> 
> (define mpfr-shutdown
>(register-custodian-shutdown mpfr-free-cache (λ (free) (free
> 
> 
> Did I misunderstand something, or is this someone else's bug?
> 
> Neil ⊥
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev