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
14 matches
Mail list logo
