Re: [racket-dev] [racket] Question about round
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 proposal whether it is > still being considered. If so I feel motivated to question it. > ... > So the original confusion was due to round returning an inexact? number. > The above proposal does not address that confusion, but instead makes > integer? return #f for inexact? inputs. So: > > (integer? 1.0) ; would be #f 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 the input was exact. (Correction: "round" does NOT always return an integer, e.g. (round +inf.0) . There are probably other counterexamples, but I haven't thought of them.) Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
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-complement binary representation of an integer"? The English language uses inexact integers all the time. "It's about 5 miles." "It'll take about twenty minutes." "Set your oven to 350 degrees." All of those are continuous physical quantities that happen to have been measured to an accuracy of 1 or more; it could actually be higher or lower by up to a mile, or several minutes, or about ten degrees, respectively. One could even say "There are about fifty students in the class." In this case, I am 100% sure that the number of students is an integer, but less than 100% sure that that integer is 50. How would you represent this number? If you say it's not an integer because it's not exact, you've allowed for fractional students. If you say it must be exact because it's an integer, you've pretended to greater confidence than is justified. Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Creating executables still broken
-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/11 10:59, Marijn wrote: > On 09/05/11 10:03, Marijn wrote: >> Hi Vincent, > >> On 09/02/11 19:33, Vincent St-Amour wrote: >>> At Fri, 02 Sep 2011 09:15:20 +0200, Marijn wrote: I just tried with latest git and nothing has changed for me. Neither the wrong message, nor the failing executable. > >>> You're building executables from DrRacket, right? > >>> Does it work if you build them from the command-line, with >>> `raco exe'? > >>> Vincent > >> No, it doesn't work either: > >> $ cat hello.rkt #lang racket > >> (print "hello") $ raco exe -o hello hello.rkt $ ./hello read >> failed to read all 885871033 bytes from file >> /home/marijn/racketzooi/./hello Aborted > > The above bug is still manifested in today's git. > > Marijn _ For > list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6JwkcACgkQp/VmCx0OL2x5wgCfQLHTHRzxs00DOZjDd4R3AC+U +UUAoMT6tkSNwrbF9S0jjktNtQkHPSeq =zH4m -END PGP SIGNATURE- _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Creating executables still broken
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, since I haven't been able to replicate it. Assuming that the old problem is still there, can you tell me (perhaps again) the platform you're running on and the arguments that you supplied to `configure'? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
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 the input was exact. Not exactly. I wasn't suggesting any change to `round'. I was suggesting changing `integer?' to only return true for exact integers. This means that the results of `round' would usually not return true when passed to `integer?', but they could still be considered inexact integers. But anyway, there is enough opposition to the proposal that things are unlikely to change, at least for now. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Transparent Structures in XML Library
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 say, if any of these make it to a display statement, it isn't pretty. Actually, since the structures also include location information, the result can be (is) larger than the actual XML was. I don't think they are transparent for any reason other than some east of debugging - and for large xml structures it is actually (in my opinion) detrimental to debugging. And, it doesn't help by adding an equality test because of the location information - equal? is pretty much identical to (an extremely slow) eq? in this case. Could we get rid of the #:transparent option on those structures? Or, if they are really there for a reason, at least add a prop:custom-write that limits the potential output from printing an instance? This is the only case where I have run into the 'problem'. But, there may be other places it exists. I am also guilty of using transparent structures sometimes, so I can't be too critical here. Doug _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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 bytes > to tens of megabytes in size. Needless to say, if any of these make > it to a display statement, it isn't pretty. Actually, since the > structures also include location information, the result can be (is) > larger than the actual XML was. If this is printout on the repl then maybe `pretty-print-depth' is the right answer? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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: > > 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 say, if any of these make > > it to a display statement, it isn't pretty. Actually, since the > > structures also include location information, the result can be (is) > > larger than the actual XML was. > > If this is printout on the repl then maybe `pretty-print-depth' is the > right answer? > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: >http://barzilay.org/ Maze is Life! > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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 #:transparent is the problem here; #:transparent means "yes, anyone can use the reflective properties to discover how many fields this structure has, what the mutators are, etc." It's not fundamentally about printing. So I think that a separate control on printing is definitely the right way to go, and in particular, the ~.s choice seems like it might just solve the problem completely. No? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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 create a several tens of megabytes long string just to truncate it. On Mon, Oct 3, 2011 at 3:52 PM, John Clements wrote: > > 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 #:transparent is the problem here; > #:transparent means "yes, anyone can use the reflective properties to > discover how many fields this structure has, what the mutators are, etc." > It's not fundamentally about printing. > > So I think that a separate control on printing is definitely the right way > to go, and in particular, the ~.s choice seems like it might just solve the > problem completely. > > No? > > John > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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 created and then filled - as opposed to building the > substructures and then creating the structure. I really haven't looked. Transparent structures are not automatically mutable, if I understand correctly. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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 substructures and then creating the structure. I really haven't looked. But, in a larger sense, it is what it is. The API provides transparent structures and there may be code that relies on it. I may even rely on it somewhere. So, leaving then as transparent is probably the best way to go - with prop:custom-write properties to limit the resulting print consequence. Rewriting it could always be Neil T's next project. :) Doug On Mon, Oct 3, 2011 at 4:06 PM, John Clements wrote: > > 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 limiting options in my case still walk the entire structure and create > a several tens of megabytes long string just to truncate it. > > I see. I misread your first mail as suggesting that the XML structures > should not be #:transparent. > > John > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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 > limiting options in my case still walk the entire structure and create a > several tens of megabytes long string just to truncate it. I see. I misread your first mail as suggesting that the XML structures should not be #:transparent. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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-write (lambda (x p z) (displayln "" p))) (define y (my "bar")) (displayln y)) (require 'b) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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 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 > substructures and then creating the structure. I really haven't looked. > > But, in a larger sense, it is what it is. The API provides transparent > structures and there may be code that relies on it. I may even rely on it > somewhere. So, leaving then as transparent is probably the best way to go - > with prop:custom-write properties to limit the resulting print consequence. > > Rewriting it could always be Neil T's next project. :) > > Doug > > On Mon, Oct 3, 2011 at 4:06 PM, John Clements > wrote: > > 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 limiting options in my case still walk the entire structure and > > create a several tens of megabytes long string just to truncate it. > > I see. I misread your first mail as suggesting that the XML structures should > not be #:transparent. > > John > > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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 engine when I was doing inference across very large xml documents. I have a trace feature in the inference engine to trace assertions that is very useful for debugging rules. You can imagine the output when I turned it on the first time with one of the large xml documents. Literally, one assertion was 100+ pages. I've pushed a new version of the inference engine that uses ~.s throughout. So, at least it prints it reasonable. But, it is still continually walking the structures and building a huge string (at least 10s of megabytes each at the highest levels). And, it has to do that for every assertion in a trace. At least I have a large memory machine with plenty of memory (and, thanks to you guys, a 64-bit windows version), so it does run. It's just annoying. On Mon, Oct 3, 2011 at 4:34 PM, Matthias Felleisen wrote: > > 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-write (lambda (x p z) (displayln > "" p))) > > (define y (my "bar")) > > (displayln y)) > > (require 'b) > > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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 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 > > substructures and then creating the structure. I really haven't looked. > > Transparent structures are not automatically mutable, if I understand > correctly. > > Robby > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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 potential size to be > the visible behavior. When you write very small XML pieces of data (say something that fits on 80 lines, 80 chars each), this kind of printing is just fine. > Where it was annoying me was in my inference engine when I was doing > inference across very large xml documents. I have a trace feature in the > inference engine to trace assertions that is very useful for debugging rules. > You can imagine the output when I turned it on the first time with one of the > large xml documents. Literally, one assertion was 100+ pages. > > I've pushed a new version of the inference engine that uses ~.s throughout. > So, at least it prints it reasonable. But, it is still continually walking > the structures and building a huge string (at least 10s of megabytes each at > the highest levels). And, it has to do that for every assertion in a trace. I am proposing an alternative approach. Write an adapter module for the XML library that does NOT bother to traverse the structure to create some huge and useless string. Is this possible for your world? -- Matthias > At least I have a large memory machine with plenty of memory (and, thanks to > you guys, a 64-bit windows version), so it does run. It's just annoying. > > On Mon, Oct 3, 2011 at 4:34 PM, Matthias Felleisen > wrote: > > 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-write (lambda (x p z) (displayln > "" p))) > > (define y (my "bar")) > > (displayln y)) > > (require 'b) > > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Transparent Structures in XML Library
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. 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 potential > size to be the visible behavior. > > > > When you write very small XML pieces of data (say something that fits on 80 > lines, 80 chars each), this kind of printing is just fine. > > > Where it was annoying me was in my inference engine when I was doing > inference across very large xml documents. I have a trace feature in the > inference engine to trace assertions that is very useful for debugging > rules. You can imagine the output when I turned it on the first time with > one of the large xml documents. Literally, one assertion was 100+ pages. > > I've pushed a new version of the inference engine that uses ~.s throughout. > So, at least it prints it reasonable. But, it is still continually walking > the structures and building a huge string (at least 10s of megabytes each at > the highest levels). And, it has to do that for every assertion in a trace. > > > > I am proposing an alternative approach. Write an adapter module for the XML > library that does NOT bother to traverse the structure to create some huge > and useless string. > > Is this possible for your world? > > -- Matthias > > > > > At least I have a large memory machine with plenty of memory (and, thanks > to you guys, a 64-bit windows version), so it does run. It's just annoying. > > > > > > > > > > On Mon, Oct 3, 2011 at 4:34 PM, Matthias Felleisen > wrote: > >> >> 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-write (lambda (x p z) (displayln >> "" p))) >> >> (define y (my "bar")) >> >> (displayln y)) >> >> (require 'b) >> >> >> > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
