Re: [racket-users] Persisting large values for debugging long-running programs

> On Sep 14, 2016, at 4:24 PM, 'John Clements' via Racket Users > wrote: > > Just in case this information is useful: > > The “classical” hack here—Eli showed me this, I believe—is to write the data > out in the form of a file that “provide”s the specified

Re: [racket-users] Persisting large values for debugging long-running programs

> On Sep 14, 2016, at 12:38 PM, Jonathan Schuster wrote: > > I have some large (several GB worth) sets of values I'd like to persist > across debugging runs of a program, rather than recomputing them each time. > I'm currently doing this with the built-in "read" and

Re: [racket-users] Persisting large values for debugging long-running programs

'Course you already mentioned a custom encoding, so, yeah, fasl: https://docs.racket-lang.org/reference/fasl.html > On Sep 14, 2016, at 3:47 PM, Jon Zeppieri wrote: > > I think reading and writing fasl should be faster, but don't expect the > format to be compatible across

Re: [racket-users] Persisting large values for debugging long-running programs

I think reading and writing fasl should be faster, but don't expect the format to be compatible across Racket versions. Or, if you know some super-efficient encoding for your data, wrap it in a new struct type and implement your own serialization. > On Sep 14, 2016, at 3:38 PM, Jonathan

Re: [racket-users] Persisting large values for debugging long-running programs

Would a database work for you? SQLite ( https://docs.racket-lang.org/db/connect.html#%28def._%28%28lib._db%2Fmain..rkt%29._sqlite3-connect%29%29) is dead easy and very convenient. Their maximum DB size is 140TB, so they won't have an issue with a few gigs. Dave On Wed, Sep 14, 2016 at 12:38

[racket-users] Persisting large values for debugging long-running programs

I have some large (several GB worth) sets of values I'd like to persist across debugging runs of a program, rather than recomputing them each time. I'm currently doing this with the built-in "read" and "write", but is there a more efficient method, especially for reading the data back in? I could