> Is that enough context to see the issue?
>
> On Tue, Jan 6, 2015 at 11:58 AM, Matthew Flatt wrote:
>
> > At Tue, 06 Jan 2015 14:14:22 -0500, Neil Van Dyke wrote:
> > > Dan Liebgold wrote on 01/06/2015 02:00 PM:
> > > > What is a straightforward way
I'm not sure what you have in mind with some of the steps, such as step
4 (using `raco pkg` or `raco link`?).
The trace suggests that "gui-lib" is linked as a clone at the `raco
pkg` level. Using `raco link -r` to adjust links installed by the
package manager has a difficult-to-predict effect, but
It's supposed to be safe; the behavior in this example is definitely a
bug.
The `#%variable-reference` form used to work only on top-level and
module variables. It seems that I forgot to fill in some pieces when I
made `#%variable-reference` work on local bindings (several years ago,
mainly for us
It wasn't that I forgot to implement pieces, after all. The problem was
a bug in the byte compiler's handling of `#%variable-reference` when
inlining. I've pushed a repair.
At Mon, 12 Jan 2015 19:24:56 -0700, Matthew Flatt wrote:
> It's supposed to be safe; the beha
At Wed, 14 Jan 2015 09:07:08 -0500, Neil Toronto wrote:
> On 01/13/2015 02:00 PM, mfl...@racket-lang.org wrote:
> > 9f3c82c Matthew Flatt 2015-01-13 08:47
> > :
> > | Windows: change `delete-{file,directory}` to attempt permission correction
> > |
> > | If a fi
e:
> Is it perhaps worth being more explicit about this possibility in the
> docs? I'm thinking of a sentence that says "when is
> set, delete-file may have only the effect of changing the permissions
> on the file" or similar.
>
> Robby
>
> On Wed, Jan 14,
We don't have build products handy on a server, but it shouldn't be
difficult to build yourself using Visual Studio 10. I recommend setting
up the command line using "vcvarsall.bat x86_amd64", and then build
from the Git repo using "nmake win32-in-place".
That process will give you debugging infor
I don't think you want to do anything with the compiler or macros.
Instead, it's a matter of having a sufficiently powerful inspector
(which is the concept of "inspectability" turned into a language
construct).
If you have just
(struct a (x))
(a 1)
then the result will print as `#`. But if you
At Wed, 21 Jan 2015 11:22:38 -0500, Tony Garnock-Jones wrote:
> Over the past few months, more and more subsystems have started logging
> at info level as part of regular compilation.
>
> I prefer having PLTSTDERR=info in order to catch log-info that happens
> at runtime, and find the compile-time
Yes, it's a bug in v6.1.1. I've just pushed a repair for the next
build.
Do you need a workaround for v6.1.1? Your variant that sets
`sandbox-namespace-specs` is what I would have tried; unfortunately,
that runs into a second bug in v6.1.1 that I recently fixed. If you
need a workaround other than
At Wed, 28 Jan 2015 16:21:51 -0700, Byron Davies wrote:
> Your code, commented:
>
> (define orig-i (current-inspector)) ; saves the original inspector
> (define sub-i (make-inspector orig-i)) ;make a new inspector whose parent
> is the original inspector
>
> (current-inspector sub-i) ;makes th
At Thu, 29 Jan 2015 15:34:37 -0300, Gustavo Massaccesi wrote:
> If there are some easy technical details and advice, you can write a
> nice blog post about this.
Good idea. I have some advice on finalization (don't do it), and I
could write about how Racket tries to help when you can't follow that
Hi Jan,
Interesting problem!
I think I see what you mean: There's no way to combine the completion
of an event plus saving its value as an atomic operation, except by
putting the synchronization in its own thread. But if you put the
synchronization in its own thread, then there's no way to preven
y summary:
> > 45.1% pkgs/racket-doc/scribblings/raco/
> > 4.7% pkgs/racket-doc/scribblings/reference/
> > 47.5% racket/collects/compiler/
> >
> > ~~
> >
> > fe9a04d Matthew Flatt 2015-01-08 09:11
> > :
> > | d
It's good to know that canceling a filesystem-change event can be
expensive on Windows, in which case they probably shouldn't be used on
Windows when resolving module paths. I'll investigate more and remove
the use.
Meanwhile, there's not a good way to disable the current use in v6.1,
but the hack
Continuing in reverse order:
- My sense is that the switch to `make` so that it updates packages,
which was a result of
http://lists.racket-lang.org/users/archive/2015-January/065345.html
has been a good change for most people most of the time.
The `as-is` target is currently available for bui
At Tue, 17 Feb 2015 14:12:54 -0500, Sam Tobin-Hochstadt wrote:
> Regardless of that, though, I think we should switch to updating only
> "main-distribution" (and perhaps "main-distribution-tests"). I doubt
> people expect `make` in the Racket source tree to update their
> software somewhere else on
At Tue, 17 Feb 2015 19:59:38 -0500, Sam Tobin-Hochstadt wrote:
> On Tue, Feb 17, 2015 at 6:41 PM, Matthew Flatt wrote:
> > At Tue, 17 Feb 2015 14:12:54 -0500, Sam Tobin-Hochstadt wrote:
> > Does another system have a Racket-like in-place option (that works
> > better)?
>
I've been working on a new macro expander for Racket, and I'm starting
to think that it will work. The new expander is not completely
compatible with the current expander --- and that will be an issue if
we eventually go forward with the change --- but most existing code
still works.
Here's a repo
At Thu, 3 Jun 2010 12:49:27 -0400, Sam Tobin-Hochstadt wrote:
> Currently, the following command:
>
> raco make collects/scribblings/tools/tool-lib-extract.rkt
>
> rapidly consumes all available memory, and has to be killed manually.
I'm working on it.
_
At Thu, 3 Jun 2010 13:00:45 -0400, Eli Barzilay wrote:
> On Jun 3, Sam Tobin-Hochstadt wrote:
> >
> > A quick `git bisect' (a great tool, btw) suggests that commit
> > ac69f11 caused the problem.
>
> That's unlikely to be the cause -- only exposing some other bug.
Right. Although `bisect' corre
At Mon, 7 Jun 2010 14:57:56 -0400, Sam Tobin-Hochstadt wrote:
> Right now, the main Racket web page says just "Racket is a programming
> language". Even though we didn't come to an agreement on great text
> to put there, I think just about anything would be better than that.
> What about just usin
At Tue, 8 Jun 2010 12:23:54 -0500, Casey Klein wrote:
> `define-for-syntax' doesn't allow optional or keyword arguments,
> although the documentation suggests it should.
>
> I tried to fix this myself, but I'm getting a mysterious compile error.
> [...]
> collects/racket/private/kw.rkt:708:46: com
I think that `*', `/', `lcm', `expt, and `exp' are the only operations
that produce an exact result when given some inexact arguments. The
`exp' and `expt' cases were documented before, and I've clarified the
rest in the docs.
The docs now also note that `sin', `tan', `asin', and `atan' produce an
My last update was back in January:
http://lists.racket-lang.org/dev/archive/2010-January/002045.html
GRacket2 wasn't done by May, obviously. I still like to think that we
could have something working within a few months, though.
The Racket switch contributed to the delay, but eventspace issues
At Sat, 12 Jun 2010 21:43:09 -0400, Sam Tobin-Hochstadt wrote:
> First, do the difficulties you've had integrating eventspaces with
> modern toolkits suggest that perhaps eventspaces should be designed
> differently?
Not as far as I can tell. The fundamental problem is being able to use
some GUI e
At Sat, 12 Jun 2010 22:06:06 -0400, Sam Tobin-Hochstadt wrote:
> On Sat, Jun 12, 2010 at 9:57 PM, Matthew Flatt wrote:
> > At Sat, 12 Jun 2010 21:43:09 -0400, Sam Tobin-Hochstadt wrote:
> >> First, do the difficulties you've had integrating eventspaces with
> >&
At Tue, 15 Jun 2010 11:01:24 -0400, Sam Tobin-Hochstadt wrote:
> I'd like to produce, with scribble, output similar to what this latex
> produces:
>
> \begin{tabular}{|c|c|c|}
> Header1 & Header2 & Header3
> 11 & 17 & 29
> \end{tabular}
>
> However, I can't seem to figure out how. First, how ca
At Tue, 22 Jun 2010 13:14:44 -0400, Sam Tobin-Hochstadt wrote:
> Using the `struct' form produces static struct info whose constructor
> name is a macro transformer that expands to an inner, hidden, name.
> Currently, there's no way to access this name, which tools such as
> Typed Racket might want
I saw this problem yesterday, too, but I thought I had fixed it.
For me, commit fe60da72c8d6525954f965144ea4dc49b6cf40a4 created the
problem. Commit e78b5d722eb7396478cd8558b2b9786ce9c52537 fixed it.
If you already have the latter, though, there must be some other problem.
At Tue, 29 Jun 2010 09:
At Tue, 29 Jun 2010 09:40:54 -0400, Sam Tobin-Hochstadt wrote:
> When I went to rebuild the latest source this morning, I got the
> following error from 'make install':
>
> racket/racket3m -X "/home/samth/sw/plt/collects" -N "raco setup" -l- setup
> raco setup: bootstrapping from source...
> /home
I haven't been able to replicate the problem, so I'm stumped. For now,
it's probably best to just delete .zo files, and we'll watch out for
the problem on the next version change.
_
For list-related administrative tasks:
http://lists.racket-lang.
I suggested that Kevin let others try parallel mode for a day or two
before making it the default.
At Fri, 2 Jul 2010 19:38:55 -0500, Robby Findler wrote:
> That sounds right to me too.
>
> Robby
>
> On Fri, Jul 2, 2010 at 4:47 PM, Matthias Felleisen
> wrote:
> >
> > Why don't you use make par
At Sun, 04 Jul 2010 14:06:13 +0400, Dmitry Dzhus wrote:
> I think this commit broke building without places support:
> [...]
>
> The attached patch should fix the problem.
Patch pushed to the git repo --- thanks!
_
For list-related administrative
At Sun, 04 Jul 2010 14:17:52 +0400, Dmitry Dzhus wrote:
> I've noticed several problems in `newgc.c` which prevent Racket from
> building with backtrace support and I'm sending you two trivial patches
> which will hopefully help fix these issues properly.
This patch is also pushed - thanks!
At Mon, 5 Jul 2010 22:33:22 -0400, Eli Barzilay wrote:
> * [1] happened on all builds (text below).
Likely it has always happened, but the old `setup' hid all stdout. The
solution is probably to change the lexer to use `log-warning', but I'll
look into it.
> * On this windows build (of the compil
Short version:
I'm planning to change internal-definition expansion (anywhere that
says `body ...' in the Racket documentation) to allow expressions to
mingle with definitions. For example,
(let ()
(define (f) x)
(displayln f)
(define x 1)
(list f x))
would be allowed; the `dis
At Wed, 7 Jul 2010 13:13:31 -0400, Matthias Felleisen wrote:
>
> 1. My most important concern is that begin-with-definitions takes Nx times
> more time to expand than the current body expander. Are you going to use this
> macro or are you going to bake it all into the implementation?
The latte
At Wed, 30 Jun 2010 22:28:48 -0400, Eli Barzilay wrote:
> Back to `data', the problem is that you cannot have two toplevel
> `data' collections -- which means that you cannot have separate
> distributions of `data/foo' and `data/bar' since they must both appear
> in your plt installation or in your
At Sat, 10 Jul 2010 01:48:09 -0400, Eli Barzilay wrote:
> On Jul 9, Matthew Flatt wrote:
> > At Wed, 30 Jun 2010 22:28:48 -0400, Eli Barzilay wrote:
> > > Back to `data', the problem is that you cannot have two toplevel
> > > `data' collections -- whic
At Sat, 10 Jul 2010 09:35:28 -0500, Robby Findler wrote:
> Just to be sure I understand, you're saying that these two may or may
> not refer to the same file:
>
> >> (require foo/blah)
> >> (require "blah.rkt")
>
> right?
Right --- depending on whether the enclosing file is required through
At Sat, 10 Jul 2010 09:49:31 -0500, Robby Findler wrote:
> On Sat, Jul 10, 2010 at 9:47 AM, Matthew Flatt wrote:
> > At Sat, 10 Jul 2010 09:35:28 -0500, Robby Findler wrote:
> >> Just to be sure I understand, you're saying that these two may or may
> >
[Moved to dev list.]
Anyone interested in working on this? The relevant code is in
collects/mred/private/wxme/test.rkt
in `do-redraw'. Look for the use of `outline-brush'.
The current strategy for drawing the selection is to draw the plain
content and then apply a 'hilite brush over that. Und
I think it's best to fix the contract and docs so that #f is a valid
result when the argument has no directory part.
At Thu, 15 Jul 2010 10:10:12 -0600, Jay McCarthy wrote:
> This bug report
>
> http://bugs.racket-lang.org/query/?cmd=view&pr=11012
>
> is due to
>
> path-only
>
> returning #f w
At Mon, 19 Jul 2010 10:47:03 -0400, Ryan Culpepper wrote:
> * Matthew Flatt
> - Racket Tests
> - Languages Tests
> - GRacket Tests (Also check that `gracket -z' and `gracket-text' still
> works in Windows and Mac OS X)
> - mzc Tests
> - mzc --exe
I've pushed a change to the git repo that I don't think will fix the
problem, but I think it will give us better information when you get a
chance to try it.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
At Wed, 21 Jul 2010 17:09:03 -0600, Matthew Flatt wrote:
> I've pushed a change to the git repo that I don't think will fix the
> problem, but I think it will give us better information when you get a
> chance to try it.
The new error message provoked a bug report that led to a
nightly build (version
> 5.0.1.1--2010-07-21(ca106a41343233e3e2e1d6393b97ff6de67e01c4/a) [3m]). Now I
> get the following error message:
>
> cm: no SHA-1 for dependency: (collects #"scheme" #"base" #"lang"
> #"reader.rkt")
>
> Doug
>
&
I'm not sure that any of my items make sense for a release
announcement, but if we need to give a sense that something interesting
happened toward the release, here's an attempt to collect the most
interesting changes into a couple of bullets:
* Changes (as part of 5.0) in the `racket' language
(maybe-compile-zo sha1-only? deps mode path orig-path
> read-src-syntax up-to-date)]
> [(ormap
>(lambda (p)
> ;; (cons 'ext rel-path) => a non-module file (check date)
> ;; rel-path => a module file name (check
At Sun, 25 Jul 2010 11:22:19 -0400, Sam Tobin-Hochstadt wrote:
> On Sun, Jul 25, 2010 at 8:27 AM, Matthew Flatt wrote:
> >
> > It's worrying, though, that you're getting a DrRacket backtrace that
> > covers "cm.rkt". Files in the main installation no
l work well only for collections where that's expected, such as the
possible "data" collection.
At Fri, 9 Jul 2010 13:10:26 -0600, Matthew Flatt wrote:
> At Wed, 30 Jun 2010 22:28:48 -0400, Eli Barzilay wrote:
> > Back to `data', the problem is that you cannot have two to
runs correctly.
> >
> > Also, Robby's suspicion that it would run correctly if "Populate compiled/
> > directories (for faster loading)" is unchecked, seems to be true. It does
> > run when it is unchecked.
> >
> > Doug
> >
> >
> >
At Tue, 27 Jul 2010 23:17:59 -0400, Eli Barzilay wrote:
> * By default `make install' and `raco setup' compile collections in
> parallel on all available processors. (Use `reaco setup -j 1' to
> disable if necessary.)
"reaco" -> "raco"
_
For
At Mon, 2 Aug 2010 04:42:41 -0600, Jay McCarthy wrote:
> These are the commits:
Those are from July 22, one week after the branch for 5.0.1, so they
would not normally be considered candidates for the 5.0.1 release.
_
For list-related administrati
The `racket/gui' re-implementation is starting to come into focus.
DrRacket mostly works, although lots and lots of problems remain.
The code is still hosted here:
http://github.com/mflatt/gr2
The GUI libraries do not work well enough that it's time to submit bug
reports, but DrRacket works wel
At Mon, 2 Aug 2010 17:51:11 -0400, Sam Tobin-Hochstadt wrote:
> On Mon, Aug 2, 2010 at 1:09 PM, Matthew Flatt wrote:
> > The `racket/gui' re-implementation is starting to come into focus.
> > DrRacket mostly works, although lots and lots of problems remain.
>
> It loo
At Mon, 2 Aug 2010 19:12:40 -0400, Sam Tobin-Hochstadt wrote:
> On Mon, Aug 2, 2010 at 7:08 PM, Matthew Flatt wrote:
> > One question: the open/save file
> >> dialogs on Gtk are using the old GRacket dialogs, rather than the
> >> Gtk-native ones. Is this plan
At Tue, 3 Aug 2010 09:21:33 -0400, John Clements wrote:
> Reality check: I can't use the Racket ffi libraries to load 64-bit x86_64
> shared libs, can I?
Right --- not when running a 32-bit racket.
_
For list-related administrative tasks:
http:
At Tue, 03 Aug 2010 14:34:40 -0400, Vincent St-Amour wrote:
> While writing documentation, I came across cases where I would have
> wanted to link to technical terms (using the "tech" function) without
> having the technical term itself be the text of the link.
>
> For example, I wanted to link to
Both problems at
http://lists.racket-lang.org/users/archive/2010-August/040939.html
look like simple omissions in the distribution spec. I've pushed a fix
(hopefully) to the spec.
We need to add "build on Linux from source distribution" to our
release-time checklist. Kevin, can we put that und
I'd go with 1.
At Fri, 6 Aug 2010 17:38:01 -0400, Sam Tobin-Hochstadt wrote:
> On Fri, Aug 6, 2010 at 7:13 AM, Nikita Zuev wrote:
> > Jay McCarthy writes:
> > ...
> >> > make[6]: ../../../racket/gc/../../utils/nicear: Command not found
>
> Are we planning to release a new version of the source
At Thu, 12 Aug 2010 07:28:34 -0400, Eli Barzilay wrote:
> One thing about stability that bugs me is pushing changes and
> extensions that are likely to change. For example, I'm worried about
> Jay's push for a number of new features as a response to a blog post,
> it looks like coding in haste tha
At Wed, 11 Aug 2010 18:56:49 -0400, Gene Diveglia wrote:
> Building as outlined below on OS X 10.6.4 Intel is failing. I'm anxious to
> experiment with places, any suggestions on how to fix this build?
I've pushed a repair to the header files, but GRacket crashes if you
try to run it; I think th
At Sat, 14 Aug 2010 11:25:04 -0600, Jay McCarthy wrote:
> The root of this problem is that "make install" didn't finish. Here's the log:
>
> http://drdr.racket-lang.org/20864/src/build/make-install
>
> It says:
>
> attempted to wait for suspend in nested atomic mode
Hopefully fixed, now.
The p
I changed the name in "libracket.vcproj".
At Mon, 16 Aug 2010 15:58:22 +1000, Paul Steckler wrote:
> In last night's build, the Visual Studio solution file
> src/worksp/racket/racket.sln contains the line:
>
> Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "libracket",
> "..\libracke
The `racket/gui' re-implementation has improved over the past two
weeks. It's still not ready for everyday use or even bug reports, but
it's getting closer. The most visible difference is that controls and
canvases refresh and resize more cleanly. The least visible difference
is that a complete mem
Should be fixed, now.
At Thu, 19 Aug 2010 12:53:48 -0400, Vincent St-Amour wrote:
> I just tried updating racket on my Mac OS PPC machine, and jit.c does
> not compile. The same revision builds fine on linux x86.
_
For list-related administrative
At Thu, 19 Aug 2010 18:45:43 -0400, sa...@racket-lang.org wrote:
> +(define-syntax for*/flvector
> + (lambda (stx)
> +(syntax-case stx ()
> + ((for*/flvector (for-clause ...) body)
> + (syntax/loc stx
> + (list->flvector (for*/list (for-clause ...) body
> + ((for*/f
At Fri, 20 Aug 2010 13:05:12 -0500, "Will M. Farr" wrote:
> Thanks very much for the comments. I'll get to work preparing an updated
> version using #:size soon, and send it to Sam for pushing.
I should have suggested `#:length', since it corresponds to
`vector-length'.
I didn't think of this
At Sun, 22 Aug 2010 15:36:03 -0500, "Will M. Farr" wrote:
> > Either choice --- error or stopping --- interacts awkwardly with
> > `for*/vector'. If you've going to raise an exception, the natural thing
> > to do with `for/vector' would be to stop as soon as the sequence goes
> > too far. But `for*
That's the mechanism, but I think Matthias's question is about the
impact on performance. Assuming so, the answer is that it doesn't seem
to matter much relative to everything else. Even programs that use
mutation heavily don't manage to mutate many of the old-generation
pages between major collect
At Tue, 24 Aug 2010 09:53:21 -0700, Joe Marshall wrote:
> I'm surprised that racket3m uses page protection. Taking a hardware trap
> can often be thousands of times slower than taking an inline conditional
> branch.
The hardware trap happens once per GC-managed page between minor
collections, whi
Here's a program that tries to expose various costs.
On my machine, the output is:
'cons-of-cXr+barrier-set!
cpu time: 13137 real time: 13206 gc time: 552
'cons-of-cXr+free-set!
cpu time: 12832 real time: 12995 gc time: 541
'cons-of-cXr
cpu time: 10023 real time: 10103 gc time: 526
'cons-o
At Tue, 24 Aug 2010 16:03:00 -0700, Joe Marshall wrote:
> On Tue, Aug 24, 2010 at 3:43 PM, Matthew Flatt wrote:
> > At Tue, 24 Aug 2010 09:53:21 -0700, Joe Marshall wrote:
> >> I'm surprised that racket3m uses page protection. Taking a hardware trap
> >> can of
At Wed, 25 Aug 2010 09:42:40 -0400, Sam Tobin-Hochstadt wrote:
> While trying to use futures to parallelize a simple piece of code, I
> was able to remove all of the waiting except for this:
>
> future: 3 waiting for runtime at 1282743524205.783936: [scheme_make_envunbox]
>
> which happens contin
e
the compiler so that it doesn't see how to convert the `let' into a
`letrec'.
At Wed, 25 Aug 2010 10:07:04 -0400, Sam Tobin-Hochstadt wrote:
> On Wed, Aug 25, 2010 at 9:56 AM, Matthew Flatt wrote:
> > At Wed, 25 Aug 2010 09:42:40 -0400, Sam Tobin-Hochstadt wrote:
> >>
At Wed, 25 Aug 2010 08:41:04 -0600, Jay McCarthy wrote:
> > Unfortunately, trying to decompile this file produces an error in the
> > decompiler:
> >
> > [sa...@punge:~/tmp plt] raco decompile mandelbrot.rkt
> > hash-ref: no value found for key: 1128
>
> Blake will see if this is a bug fixed in ou
At Wed, 25 Aug 2010 08:17:32 -0600, Matthew Flatt wrote:
> There's a `set!' implicit in the `letrec' that is implicit in the use
> of internal definitions. Maybe the Typed Racket optimizations confuse
> the compiler so that it doesn't see how to convert the
I've fixed `define-struct' in *SL to omit a reference to the
non-existent `struct:' binding, so `struct-out' now works with the
definitions.
The error message from `struct-out' is also fixed to say "binding"
instead of "import".
At Sat, 28 Aug 2010 16:15:26 -0600, Jay McCarthy wrote:
> The st
At Thu, 2 Sep 2010 12:24:20 -0400, Eric Dobson wrote:
> I am trying to create a patch for 5.0.1 in the form of a plt file that
> will backport fixes to plai. To do this I also need to backport the
> new define-struct.
For my class, I'm using an implementation of `define-type' that is
different fro
At Thu, 2 Sep 2010 23:27:08 -0400 (EDT), Hari Prashanth wrote:
> I am getting the following error... And this is the only message I get...
>
> SIGSEGV MAPERR si_code 1 fault on addr 0xfffc
> This often means 0xfffc isn't getting marked, and was prematurely
> freed
> Aborte
t; > #lang typed/racket
> > (require "que.ss")
> > (head (queue 1 2 3 4))
> >
> >
> > - Original Message -
> > From: "Vincent St-Amour"
> > To: "Matthew Flatt"
> > Cc: "Hari Prashanth" , "dev"
>
See `first-order->higher-order'.
At Sat, 4 Sep 2010 17:00:52 -0400, Nadeem Abdul Hamid wrote:
> Ah, thank you. Now, how about this definition:
>
> (define-syntax (my-macro stx)
> (syntax-case stx (->)
> [(_ (func arg ...) -> rslt)
> #`(length (cons func (list arg ...)))]))
> (provide m
The new implementation of `racket/gui' is almost ready for everyday
use. I've switched to the new implementation for reading and writing
e-mail (i.e., this message was composed using the new implementation),
but I haven't yet switched for using DrRacket or for running Slideshow
in class.
I'm now h
n editor should correctly adapt to the current platform
and theme convention.
At Wed, 14 Jul 2010 07:29:08 -0600, Matthew Flatt wrote:
> [Moved to dev list.]
>
> Anyone interested in working on this? The relevant code is in
>
> collects/mred/private/wxme/test.rkt
>
> in `
At Wed, 15 Sep 2010 14:33:45 -0700, John Clements wrote:
> As the program below illustrates on OS X, threads (and eventspaces and ...)
> stop when a file dialog is open. [...] Is there any chance that
> GRacket2 will fix this magically?
Not at first. GRacket2 at least has a fighting chance, but
I'm preparing to push this patch, but also generalizing `flvector-copy'
to accept start and end positions like `vector-copy'.
At Thu, 16 Sep 2010 20:46:58 -0400, "Will M. Farr" wrote:
> The attached patch against the current git master adds an flvector-copy
> procedure (along with docs and tests)
I think the problem is that the `ptr-ref' and `ptr-set!' operations are
slow. They are slow because they not yet inlined by the JIT, and
they're not yet inlined because they have complicated APIs (including a
"pointer" datatype with many variants).
I haven't worked out a way to make them faster or
One more thought: Do you get to pick whether you use 16-bit integers or
64-bit floating-point numbers? The `flvector-' and `f64vector-'
operations are inlined by the JIT and recognized for unboxing, so using
flonum vectors and operations could be much faster than using raw
pointers and 16-bit integ
At Sun, 26 Sep 2010 10:18:13 -0700, John Clements wrote:
> The function u8vector->cpointer is documented, but doesn't exist; this is
> presumably because the u8vector functions are actually byte-string functions,
> but it's not clear to me whether the absence of u8vector->cpointer is an
> oversi
When you run this program on a 32-bit machine:
#include
void go(float a[4])
{
printf("in go: %d\n", sizeof(a));
}
int main() {
float a[4];
printf("in main: %d\n", sizeof(a));
go(a);
}
you'll see "in main: 16" and "in go: 4".
As far as I know, the "4" in " void go(float a[4])
for making function calls, it is also used
> for specify structures and malloc-ing on behalf of the functions you
> want to call. It is very awkward to make cstructs that are the correct
> size and malloc the right amount without similar functionality to C in
> this regard.
>
At Thu, 30 Sep 2010 20:20:07 -0400, Faré wrote:
> I'm trying to use slideshow on Linux, and I find it annoying that it
> fails to be on top of the KDE panel.
>
> I admit I know next to nothing about the X protocol, and can't help
> much with this issue, but I hope someone who does can do something
At Thu, 30 Sep 2010 22:03:12 -0700, Sam Tobin-Hochstadt wrote:
> This happens for me always in slideshow on my laptop in both GR1 and
> GR2. I'm running Ubuntu 10.04, screen resolution 1440x1050, with
> panels on the top and bottom of the screen (as is usual for Gnome). I
> can provide any other
Currently, every inexact real in Racket is represented by a 64-bit IEEE
floating-point number.
There's an `--enable-float' configuration option that enables support
in Racket for 32-bit floating-point numbers. The use I see for 32-bit
arithmetic is to mimic some other program that uses 32-bit
floa
At Sat, 2 Oct 2010 13:52:40 -0500, Robby Findler wrote:
> Is there any value to, on a 64 bit machine, having 32 bit floats be
> immediate values to avoid boxing?
Sounds plausible. Distinguishing `flonum' from `inexact-real?' would
let us try the experiment more easily.
___
At Sat, 02 Oct 2010 17:12:20 -0600, Neil Toronto wrote:
> @Matthew: is there a problem with declaring "float" to mean
> "platform-dependent floating-point format?" Embedded devices don't
> always easily support 64 bits, and I'd hate to be stuck with 64 if
> 128-bit floats become ubiquitous.
I t
At Sun, 3 Oct 2010 11:17:44 +0100, Noel Welsh wrote:
> On Sat, Oct 2, 2010 at 7:48 PM, Matthew Flatt wrote:
> > With the current memory manager, I don't think there's any potential space
> > gain from using 32-bit floats instead of 64-bit floats. Is there any
>
At Sun, 03 Oct 2010 10:14:04 -0400, Vincent St-Amour wrote:
> At Sun, 3 Oct 2010 05:43:52 -0600,
> Matthew Flatt wrote:
> > Sam and Vincent: Any thoughts on how easy or difficult the change would
> > be for Typed Racket (and its optimizer)?
>
> It depends on how the 32-b
101 - 200 of 1176 matches
Mail list logo
