I could. But then everyone who wants to use large xml file in places where
they potentially print would have to do the same thing. And, remember that
'large' in this case is anything other than a rather small XML file.
On Mon, Oct 3, 2011 at 5:49 PM, Matthias Felleisen wrote:
>
> I understand. S
I understand. Specifics:
On Oct 3, 2011, at 7:45 PM, Doug Williams wrote:
> Basically, I'm just suggesting that the xml package have sensible printing of
> its structures. I can't imagine any case where you really want the default
> printing of recursive structures of that complexity and pote
I guess I miss-spoke there - sorry. I don't have a particularly problem in
general with transparent structures.
On Mon, Oct 3, 2011 at 4:23 PM, Robby Findler
wrote:
> On Mon, Oct 3, 2011 at 5:17 PM, Doug Williams
> wrote:
> > The main problem I see with transparent structures is that they are al
Basically, I'm just suggesting that the xml package have sensible printing
of its structures. I can't imagine any case where you really want the
default printing of recursive structures of that complexity and potential
size to be the visible behavior.
Where it was annoying me was in my inference e
What you need is a way to override certain aspects of a transparent struct's
behavior, e.g., printing. -- Matthias
On Oct 3, 2011, at 6:17 PM, Doug Williams wrote:
> The main problem I see with transparent structures is that they are also
> inherently mutable. Some of the operation provided
Doug, does this concrete example concerning printing help:
#lang racket/load
(module a racket/base
(struct xml (bar) #:transparent)
(define x (xml "bar"))
(displayln x)
(provide (struct-out xml) x))
(module b racket/base
(require 'a)
(struct my xml () #:property prop:custom-w
On Oct 3, 2011, at 3:01 PM, Doug Williams wrote:
> The fact that transparent structures also print all of their element - in
> this case recursively, ad nauseam - is more of a side effect. In that case, I
> think prop:custom-write properties should be added. I assume any of the print
> limitin
The main problem I see with transparent structures is that they are also
inherently mutable. Some of the operation provided may well make use of that
- for example removing whitespace. And, internally, it may be that the
structures are created and then filled - as opposed to building the
substructu
On Mon, Oct 3, 2011 at 5:17 PM, Doug Williams
wrote:
> The main problem I see with transparent structures is that they are also
> inherently mutable. Some of the operation provided may well make use of that
> - for example removing whitespace. And, internally, it may be that the
> structures are c
The fact that transparent structures also print all of their element - in
this case recursively, ad nauseam - is more of a side effect. In that case,
I think prop:custom-write properties should be added. I assume any of the
print limiting options in my case still walk the entire structure and creat
On Oct 3, 2011, at 2:13 PM, Doug Williams wrote:
> There are ways around it like that. For example, I'm trying to get in the
> habit of using ~.s in printf's where it might occur. But, I think it would be
> easy in this case to just fix the real problem.
I don't think I would agree that #:tran
There are ways around it like that. For example, I'm trying to get in the
habit of using ~.s in printf's where it might occur. But, I think it would
be easy in this case to just fix the real problem.
On Mon, Oct 3, 2011 at 3:07 PM, Eli Barzilay wrote:
> 10 minutes ago, Doug Williams wrote:
> > M
10 minutes ago, Doug Williams wrote:
> Maybe this is general question or observation, but I specifically
> have the problem with the xml module in Racket. All of the
> structures defined in collects/xml/private/structures.rkt are
> transparent. Most of my xml files are hundreds of thousands of byte
Maybe this is general question or observation, but I specifically have the
problem with the xml module in Racket. All of the structures defined in
collects/xml/private/structures.rkt are transparent. Most of my xml files
are hundreds of thousands of bytes to tens of megabytes in size. Needless to
s
At Sat, 1 Oct 2011 12:41:26 -0400,
Stephen Bloch wrote:
> I think Vincent was proposing that "round" continue to return an
> integer (which makes sense -- that is its raison d'etre) but that all
> integers be exact. At present, "round" always returns an integer, but
> this integer is exact only if
At Mon, 03 Oct 2011 16:10:15 +0200, Marijn wrote:
> creating executables is still broken and seems now to cause lots of
> memory allocation causing my system to start thrashing...
I've fixed the problem that caused `raco exe' to not terminate.
I doubt that the older problem you've seen is fixed,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi list,
creating executables is still broken and seems now to cause lots of
memory allocation causing my system to start thrashing...
$ cat hello.rkt
#lang racket
(print "hello")
$ raco exe -o hello hello.rkt
[.starts thrashing.]
Marijn
On 09/16
On Oct 1, 2011, at 12:54 AM, David T. Pierson wrote:
> On Fri, Sep 30, 2011 at 11:59:25AM -0400, Vincent St-Amour wrote:
>> Here's a proposal:
>> `integer?' becomes the same as `exact-integer?' (which is kept for
>> backwards compatibility).
>
> It is not clear to me from the responses to this p
On Sep 30, 2011, at 11:59 AM, Vincent St-Amour wrote:
> On a more general note, do we really need inexact integers?
>
> The behavior of `integer?' is confusing
Is it MATHEMATICALLY confusing, or is it confusing because most of us were
brought up (in CS) with "integer" meaning "32-bit two's-com
19 matches
Mail list logo
