Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28-12-11 13:18, Matthew Flatt wrote:
> Thanks for all the new info! I don't think that it's a bytcode
> problem. I start to wonder if it's in number parsing...
>
> On line 1102 of "src/racket/src/numstr.c", there's a call to
> STRTOD(). Does it change anything if you wrap that call with calls
> to scheme_push_c_numeric_locale() and
> scheme_pop_c_numeric_locale(loc)?:
>
> { GC_CAN_IGNORE char *loc; loc = scheme_push_c_numeric_locale(); d
> = STRTOD(ffl_buf, &ptr); scheme_pop_c_numeric_locale(loc); }
Hi Matthew,
you're certainly on the right track. I tried starting drracket in this
way:
LC_ALL="en_US.UTF-8" drracket &
and almost all symptoms were gone.
Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk78JkIACgkQp/VmCx0OL2wedgCfSApHFEmJ6GojTYbTGg/fY4fz
LjoAnREzYAr9VYv/BZyAJEWYNunWNK9s
=1ZSi
-END PGP SIGNATURE-
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28-12-11 17:08, Neil Toronto wrote: > On 12/28/2011 05:18 AM, Matthew Flatt wrote: >> Thanks for all the new info! I don't think that it's a bytcode >> problem. I start to wonder if it's in number parsing... >> >> On line 1102 of "src/racket/src/numstr.c", there's a call to >> STRTOD(). Does it change anything if you wrap that call with >> calls to scheme_push_c_numeric_locale() and >> scheme_pop_c_numeric_locale(loc)?: ... > > Locales? Then maybe I wasn't crazy for thinking the bug might > discriminate against people whose first language isn't English? > Laurent speaks French and I think Marijn speaks Dutch. Locales are a beautiful thing, but they also cause many many weird issues... but it is ever so annoying to see a numeric date and have to wonder which is months and which is days (for exmaple in Thunderbird), so I configured my locale to be a wonderful mix of nl_NL and en_US... > (Beautiful country, BTW, Marijn. I was at Avifauna for a > conference.) Thanks! > I had an email about this ready, but then I tried switching > DrRacket's language to French and Dutch to see if I could duplicate > it. I couldn't, so I deleted the email. I think to switch the locale you would have to do some more work, like set an environment variable. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk78KNcACgkQp/VmCx0OL2yOJgCfVmeUIb7/KyJFfkRXGNoNXb8p fksAnRFYz2ez3HpQgEN3AXxK7iFCZ5vP =Nrgv -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29-12-11 09:55, Laurent wrote: >> >> you're certainly on the right track. I tried starting drracket in >> this way: >> >> LC_ALL="en_US.UTF-8" drracket & >> > > Same here: LC_ALL="en_US.UTF-8" gracket > > Welcome to Racket v5.2.0.6. This is a simple window for evaluating > Racket expressions. Quit now and run DrRacket to get a better > window. The current input port always returns eof. >> .3 > 0.3 >> > > Great! > > *However*, this did not work with: LC_ALL="fr_FR.UTF-8" gracket Because the french locale uses comma (,) as the decimal separator like my dutch one and unlike the english one which uses dot (.). So when the locale-aware C number reading function gets to it and sees (.) it fails to recognize is as a valid number character. Now that I've thought about it more the weird behavior where it starts working correctly after having seen a number bigger than 1.0 smells like an unmatched push/pop locale pair. Might this then not also cause quite a big locale stack to be allocated? Finally I wanted to ask if it was possible that the automated tests are run with a non-english or random locale. Matthew, I still wanted to remark that I find it strange that plain racket did not exhibit the same locale-dependence. Do you have an explanation for that? Does it read some >=1.0 float causing the locale stack to become ``seeded'' (due to postulated unmatched push/pop). BTW Perhaps coccinelle (http://coccinelle.lip6.fr/) can help identify (and automatically fix) the unmatched uses of the locale stack. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk78ND0ACgkQp/VmCx0OL2xrMwCgyRftnjOkQfIA3rpWKKwT7dKh KaAAoIDRW5XBM9d87FQ1CbCVUhpXPREm =Sw9a -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] no capturing groups in regexp-split? [was Re: [PATCH] add regexp-split]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
this just appeared on guile-devel, but it seems to have exposed a bug
in racket.
On 29-12-11 10:32, Nala Ginrut wrote:
> hi guilers! It seems like there's no "regexp-split" procedure in
> Guile. What we have is "string-split" which accepted Char only. So
> I wrote one for myself.
>
> --python code-
import re re.split("([^0-9])", "123+456*/")
> [’123’, ’+’, ’456’, ’*’, ’’, ’/’, ’’] code end---
>
> The Guile version:
>
> --guile code--- (regexp-split "([^0-9])" "123+456*/")
> ==>("123" "+" "456" "*" "" "/" "") --code end
>
> Anyone interested in it?
Welcome to Racket v5.2.0.7.
> (regexp-split "([^0-9])" "123+456*/")
'("123" "456" "" "")
should it be considered a bug in racket that it doesn't support
capturing groups in regexp-split? Without the capturing group the
results are identical:
>>> import re re.split("[^0-9]", "123+456*/")
['123', '456', '', '']
> (regexp-split "[^0-9]" "123+456*/")
'("123" "456" "" "")
Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk78QJUACgkQp/VmCx0OL2xi1ACgu2CbR7PPti7KZVkqAHvW9Cep
VO0AnAm0fWP+q6BH/zcqOd3TuaSEiarN
=xuUl
-END PGP SIGNATURE-
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] require does not recognize filenames with '>' in them
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
require doesn't seem to like filename with '>' in them:
$ FILENAME="file-with-long-name"; echo '(module bert racket (displayln
42))' > "${FILENAME}" && racket -e "(require \"${FILENAME}\")"; rm
"${FILENAME}"
42
$ FILENAME="file-with-lo>ng-name"; echo '(module bert racket
(displayln 42))' > "${FILENAME}" && racket -e "(require
\"${FILENAME}\")"; rm "${FILENAME}"
#f::0: require: bad module-path string at: "file-with-lo>ng-name" in:
(require "file-with-lo>ng-name")
=== context ===
/usr/lib64/racket/collects/racket/private/reqprov.rkt:243:14:
transform-simple
/usr/lib64/racket/collects/racket/private/reqprov.rkt:222:2
Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk78SPIACgkQp/VmCx0OL2wP4wCgs0uuuAzzVR/gtE36H3QXL0wy
y7QAn0Uf2qIyjeblQLH07JuQCNqunAe1
=HR6A
-END PGP SIGNATURE-
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] Internal definitions in `define'
Does anyone know of a reason to not have an implicit `begin' in a plain definition, translated into an implicit (let () ...) in racket? When I see things like this: http://stackoverflow.com/questions/8667403 I think that people expect the syntax of `define' to be uniform, so if you can switch these: (define (foo x) (+ x 1)) (define foo (+ 8 1)) then the expectation is for the same to work when there are multiple expressions. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
> > you're certainly on the right track. I tried starting drracket in this > way: > > LC_ALL="en_US.UTF-8" drracket & > Same here: LC_ALL="en_US.UTF-8" gracket Welcome to Racket v5.2.0.6. This is a simple window for evaluating Racket expressions. Quit now and run DrRacket to get a better window. The current input port always returns eof. > .3 0.3 > Great! *However*, this did not work with: LC_ALL="fr_FR.UTF-8" gracket Weird. Thank you, Laurent > and almost all symptoms were gone. > > Marijn > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.18 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk78JkIACgkQp/VmCx0OL2wedgCfSApHFEmJ6GojTYbTGg/fY4fz > LjoAnREzYAr9VYv/BZyAJEWYNunWNK9s > =1ZSi > -END PGP SIGNATURE- > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
At Thu, 29 Dec 2011 10:34:53 +0100, Marijn wrote: > Because the french locale uses comma (,) as the decimal separator like > my dutch one and unlike the english one which uses dot (.). So when > the locale-aware C number reading function gets to it and sees (.) it > fails to recognize is as a valid number character. Now that I've > thought about it more the weird behavior where it starts working > correctly after having seen a number bigger than 1.0 smells like an > unmatched push/pop locale pair. Might this then not also cause quite a > big locale stack to be allocated? Finally I wanted to ask if it was > possible that the automated tests are run with a non-english or random > locale. > > Matthew, I still wanted to remark that I find it strange that plain > racket did not exhibit the same locale-dependence. Do you have an > explanation for that? Does it read some >=1.0 float causing the locale > stack to become ``seeded'' (due to postulated unmatched push/pop). I am not clear on how the LC_NUMERIC locale gets set to anything other than "C". My best guess is that Gtk sets it, and that's why the problem happens only in DrRacket and why the problem showed up relatively recently. There's not really a stack of locales in Racket. Aside from the two clearly matched pairs of scheme_push_c_numeric_locale() and scheme_pop_c_numeric_locale(), Racket sets LC_CTYPE and LC_LOCALE on demand for functions like `bytes->string/locale' or `path->string'. It's possible that Racket and Gtk will interfere with each other and that Racket needs to manage the those settings more tightly (setting them and restoring them more like the LC_NUMERIC handling). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] require does not recognize filenames with '>' in them
You can use a `file' module path to allow ">" in the name:
(require (file "file-with-lo>ng-name"))
A ">" isn't allowed with the portable relative-path form, because ">"
isn't allowed in paths on Windows (roughly speaking).
At Thu, 29 Dec 2011 12:03:14 +0100, Marijn wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> require doesn't seem to like filename with '>' in them:
>
> $ FILENAME="file-with-long-name"; echo '(module bert racket (displayln
> 42))' > "${FILENAME}" && racket -e "(require \"${FILENAME}\")"; rm
> "${FILENAME}"
> 42
> $ FILENAME="file-with-lo>ng-name"; echo '(module bert racket
> (displayln 42))' > "${FILENAME}" && racket -e "(require
> \"${FILENAME}\")"; rm "${FILENAME}"
> #f::0: require: bad module-path string at: "file-with-lo>ng-name" in:
> (require "file-with-lo>ng-name")
>
> === context ===
> /usr/lib64/racket/collects/racket/private/reqprov.rkt:243:14:
> transform-simple
> /usr/lib64/racket/collects/racket/private/reqprov.rkt:222:2
>
> Marijn
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.18 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk78SPIACgkQp/VmCx0OL2wP4wCgs0uuuAzzVR/gtE36H3QXL0wy
> y7QAn0Uf2qIyjeblQLH07JuQCNqunAe1
> =HR6A
> -END PGP SIGNATURE-
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
On Wed, Dec 28, 2011 at 13:18, Matthew Flatt wrote:
> Thanks for all the new info! I don't think that it's a bytcode problem.
> I start to wonder if it's in number parsing...
>
> On line 1102 of "src/racket/src/numstr.c", there's a call to STRTOD().
> Does it change anything if you wrap that call with calls to
> scheme_push_c_numeric_locale() and scheme_pop_c_numeric_locale(loc)?:
>
>{
> GC_CAN_IGNORE char *loc;
> loc = scheme_push_c_numeric_locale();
> d = STRTOD(ffl_buf, &ptr);
> scheme_pop_c_numeric_locale(loc);
>}
>
It works!
Though: I downloaded the nightly Unix sources, and did:
mkdir build
cd build
../configure
make
But no drracket executable appears (did I do something wrong?).
So I did:
gracket/gracket3m
and it took a full minute with 100% CPU to start (same for simply racket3m).
Then
Welcome to Racket v5.2.0.7.
This is a simple window for evaluating Racket expressions.
Quit now and run DrRacket to get a better window.
The current input port always returns eof.
> .3
0.3
>
In case this does not completely solve the issue, here is another
minimalistic interesting interaction in the buggy gracket:
Welcome to Racket v5.2.0.6.
This is a simple window for evaluating Racket expressions.
Quit now and run DrRacket to get a better window.
The current input port always returns eof.
> .3
0.0
> 3.3
3.0
> .3
0.3
So it seems that it's the fact that using a >= 1 floating point number make
the bug go away.
Anyway, I hope this does solves the issue!
Thank you very much,
Laurent
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact->exact: no exact representation for +nan.0)]
I'm not alone! FWIW, I still have that problem in 5.2.0.6. And I confirm the ".1" minimalist test case. When running 'racket' from the command line, this does not occur however: laurent:~$ racket Welcome to Racket v5.2.0.6. Edit ~/.racketrc to modify inits. > .1 0.1 > But this still happens with gracket: Welcome to Racket v5.2.0.6. This is a simple window for evaluating Racket expressions. Quit now and run DrRacket to get a better window. The current input port always returns eof. > .1 0.0 > Probably irrelevant: Could the GPU be in the loop somehow? Good luck, Laurent On Tue, Dec 27, 2011 at 14:26, Marijn wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 24-12-11 16:23, Matthew Flatt wrote: > > At Wed, 14 Dec 2011 16:49:23 +0100, Marijn wrote: > >> #lang racket (* .1 pi) > >> > >> produces 0.0 reliably in a freshly started drracket even when > >> rerunning it, but: > >> > >> $ racket -e '(* .1 pi)' 0.3141592653589793 > >> > >> and the program: > >> > >> #lang racket pi (* .1 pi) > >> > >> on the first run (drracket again) produces: > >> > >> 3.141592653589793 0.0 > >> > >> while on subsequent runs it produces: > >> > >> 3.141592653589793 0.3141592653589793 > > > > Thanks --- this is very helpful! > > > > I'm still stumped, unfortunately. It looks the same as PR 12070, > > which we never figured out: > > > > > http://bugs.racket-lang.org/query/?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=12070 > > Interesting!, > > > though it is a bit hard to read the Audit Trail because > everything is jumbled together. > > I reproduce that bug and step 7) and 8) can be replaced with a single > re-evaluate for me. > > It seems to indicate very clearly that the problem is in the floating > point start-up somehow and has nothing to do with `pi' or variable > references. > > Another possibility would be that multiplication (*) was at fault, but > my new smallest test-case rules that out: > > #lang racket > .1 > > => 0.0 > > And actually it works also directly in the REPL without running any > program: > > Welcome to DrRacket, version 5.2.0.7--2011-12-15(-/f) [3m]. > Language: racket; memory limit: 128 MB. > > .1 > 0.0 > > 1 > 1 > > .1 > 0.0 > > .2 > 0.0 > > .3 > 0.0 > > .4 > 0.0 > > .5 > 0.0 > > .6 > 0.0 > > .7 > 0.0 > > .8 > 0.0 > > .9 > 0.0 > > 1.0 > 1.0 > > .1 > 0.1 > > So should we look at the byte-code produced for this (how does one do > that and what is the expected code)? > Is there some way to invoke racket from the command line in such a way > that it behaves like the drracket initial repl? > How does one run the byte-code? > > What external suspects are there? I suppose gcc, but are there any > other? My CFLAGS are set to a very conservative AFAIK > CFLAGS="-march=native -ggdb -O2 -pipe", currently on version 4.5.3. > > Marijn > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.18 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk75x5IACgkQp/VmCx0OL2xZRACcC8dubYCSNXScyOG8wdJQxxN1 > xAgAnRVKv8YpTWODEKn2qEMMhcXHZLSk > =n+xT > -END PGP SIGNATURE- > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Internal definitions in `define'
I'm mildly against it, since it seems too easy to make parenthesis errors that are very confusing (ie if you move a paren from the end of one define to the end of a following define, the errors will get strange). Robby On Thu, Dec 29, 2011 at 1:08 PM, Eli Barzilay wrote: > Does anyone know of a reason to not have an implicit `begin' in a > plain definition, translated into an implicit (let () ...) in racket? > > When I see things like this: > > http://stackoverflow.com/questions/8667403 > > I think that people expect the syntax of `define' to be uniform, so if > you can switch these: > > (define (foo x) (+ x 1)) > (define foo (+ 8 1)) > > then the expectation is for the same to work when there are multiple > expressions. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] dependencies and racket
Hello list, I've been playing with Racket. I'm impressed, especially with the documentation (both its content and its presentation), the contract system, and its performance. I have been investigating writing a build pack for Heroku to attempt deploying Racket projects with ease. A blocker, though, where I've hit a bit of a documentation gap is how to idiomatically itemize and download dependencies for a Racket program so that the program can exist at run-time without calling PlaneT whenever an application backend starts and hits a locally unfulfilled 'require'. The goal is that a program written, say, three years ago should be able to run the same way it did when it was written, so it's really useful to freeze all the dependencies into the file system somehow and preserve it. To prevent all the ills that can occur if a chunk of software starts up needing an old library as well as the accidental hammering of PLT servers it may also be a good idea to have a mechanism to *disable* network-sourcing of code at run-time. raco distribute seems pretty close and useful for other reasons, but upon my naive inspection, it seems to not save the planet cache required for the program (I guess dynamic-require makes that impossible to do soundly in a complete way). Maybe I'm wrong? This question is probably pretty similar to: "If I wanted to develop non-network connection desktop application X, how do I make sure that I have *everything* the user needs in my distributable". Cheers, and thanks for so many years of excellent work. -- fdr _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] dependencies and racket
Daniel Farina wrote at 12/29/2011 07:59 PM:
The goal is that a program written, say, three
years ago should be able to run the same way it did when it was
written, so it's really useful to freeze all the dependencies into the
file system somehow and preserve it.
Someone else can comment on any automated ways of ``compiling in''
PLaneT packages, and solutions like that.
A so-so solution I *don't* recommend... If you preserved the exact
PLaneT linkage table, and were very careful, then I think you could
preserve the exact versions of PLaneT modules used ("required" directly,
and indirectly). This assumes either: (1) integrity of the PLaneT
server, and trust in your connection to it; or (2) preservation of the
pertinent parts of "~/.racket". Then you'd want to disable attempts to
access the PLaneT server. Perhaps, if you were to automate this, it
could be done safely and reliably.
Something that has been done for a large Racket-based Web app on
production servers is to manually determine all the PLaneT packages that
are used, downloaded and extract these packages (in a directory scheme
that preserves naming and version info), check it all into their
configuration management system, change all the PLaneT module references
to filesystem ones, check it into CM again, and audit. PLaneT server
access is always blocked, except for the manual download. You can make
simple tools to help automate the more mechanical parts of this (I don't
know of any such tools publicly available at this time), but the audit
is mostly human expertise-intensive. This cloning of PLaneT packages
is not something that most people need to do, and it totally spoils the
buzz of ``I'll just add a "(require (planet ...))" and bam!,'' but it's
not too hard to do if you choose to.
PLaneT isn't my baby (I think Jay and Eli are leading it right now), but
I'm looking into funding so that I can put solid chunks of time into
helping with ways to improve PLaneT security. Security is usually a
constant consideration in my Internet consulting work. Part of this
tentative work will address your concerns about stability, and (in my
current thinking) about having the option of removing PLaneT server
dependencies for an app. Much of this work has implications for some
other network software distribution methods, so PLaneT is both a
research testbed and an early practical beneficiary (much like Racket in
general). Stay tuned (I have a lot more experience in solving problems
than in writing research grant proposals).
--
http://www.neilvandyke.org/
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] dependencies and racket
I think that a minor variation on Neil's strategy should not be too
difficult to do (but I'll certainly agree that it is not an ideal
situation). What you'd do is first just download (via the "Bam" method
below :) the planet packages you want. Then, if you look inside this
directory:
(build-path (find-system-path 'addon-dir)
"planet"
"300")
you should find some files with extensions ".plt". Re-build that same
portion of the directory structure to contain those files in the
deployment environment, and then set the PLTPLANETURL environment
variable to something bogus.
This should set you up to re-create the same planet setup. You will
still have the planet install step happening on each machine (each
filesystem with the path above, technically), but setting PLTPLANETURL
will ensure that planet cannot get online to try to find new (possibly
untrusted) versions of things.
hth,
Robby
Also, FWIW, I maintain, in the weakest sense of the word, the current
planet service. (All I really do is react to emergencies that break
things.) Jay and Eli are looking into a whole new thing and have been
talking about it for more than a year, I believe, so hopefully plans
are firming up. Their system should be able to support this kind of
use-case much more effectively. I think that kind of thing is designed
in for them.
On Thu, Dec 29, 2011 at 8:50 PM, Neil Van Dyke wrote:
> Daniel Farina wrote at 12/29/2011 07:59 PM:
>
>> The goal is that a program written, say, three
>> years ago should be able to run the same way it did when it was
>> written, so it's really useful to freeze all the dependencies into the
>> file system somehow and preserve it.
>>
>
>
> Someone else can comment on any automated ways of ``compiling in'' PLaneT
> packages, and solutions like that.
>
> A so-so solution I *don't* recommend... If you preserved the exact PLaneT
> linkage table, and were very careful, then I think you could preserve the
> exact versions of PLaneT modules used ("required" directly, and indirectly).
> This assumes either: (1) integrity of the PLaneT server, and trust in your
> connection to it; or (2) preservation of the pertinent parts of "~/.racket".
> Then you'd want to disable attempts to access the PLaneT server. Perhaps,
> if you were to automate this, it could be done safely and reliably.
>
> Something that has been done for a large Racket-based Web app on production
> servers is to manually determine all the PLaneT packages that are used,
> downloaded and extract these packages (in a directory scheme that preserves
> naming and version info), check it all into their configuration management
> system, change all the PLaneT module references to filesystem ones, check it
> into CM again, and audit. PLaneT server access is always blocked, except
> for the manual download. You can make simple tools to help automate the
> more mechanical parts of this (I don't know of any such tools publicly
> available at this time), but the audit is mostly human expertise-intensive.
> This cloning of PLaneT packages is not something that most people need to
> do, and it totally spoils the buzz of ``I'll just add a "(require (planet
> ...))" and bam!,'' but it's not too hard to do if you choose to.
>
> PLaneT isn't my baby (I think Jay and Eli are leading it right now), but I'm
> looking into funding so that I can put solid chunks of time into helping
> with ways to improve PLaneT security. Security is usually a constant
> consideration in my Internet consulting work. Part of this tentative work
> will address your concerns about stability, and (in my current thinking)
> about having the option of removing PLaneT server dependencies for an app.
> Much of this work has implications for some other network software
> distribution methods, so PLaneT is both a research testbed and an early
> practical beneficiary (much like Racket in general). Stay tuned (I have a
> lot more experience in solving problems than in writing research grant
> proposals).
>
> --
> http://www.neilvandyke.org/
>
>
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
