when you see “also, no #%app is bound” it’s almost always because you need (require (for-syntax racket/base))
Generators allow a more natural coding, but for a chess engine, speed is extremely important, so I guess I’ll stick with let-over-lambda.
Are any of the ideas from the paper, <https://people.seas.harvard.edu/~chong/pubs/oopsla16-auth-contracts.pdf|Extensible Access Control with Authorization Contracts>, available in a library or as an example implementation, somewhere?
I would ask @chrdimo
(who may not be on Slack much, you might email him)
Hi all, just to let you know I updated the package server to have a slightly different flow for password resets and account registrations, for spam prevention reasons. Please email me if you have any trouble.
@tonyg while I have you here …
Thankyou !
Hi all. A question about the racket build/install process from the release sources where I am seeing a major performance degradation when trying to install cs and bc/cgc on the same system.
In the 8.0 linux source release I am running the following. pushd src
make cgc
make bc
make cs
make DESTDIR="/path/to/sandbox/image/" install-cs
make DESTDIR="/path/to/sandbox/image/" install-both When I then go to run racket it takes nearly 12 real seconds to start (tested using time raco). The equivalent tests with racketbc and racketcgc behave as expected (roughtly .3 seconds). Strangely if I reverse this then racket starts as expected and bc and cgc start slowly.
In all cases raco{cs,bc,cgc} setup has been run and the results of compilation are inside the compiled folder. If I run raco setup as root this fixes the issue as well.
Is there some finalizing step during make install that would somehow cause an implementation to lose track of where its compiled artifacts if another make install was run for a different variant?
What configure flags are you using?
The symptoms sounds like the BC and CS variants are fighting for control of the “compiled” subdirectory for “.zo” files, and the most recent setup would win.
./configure
--prefix=/usr
--build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu
--mandir=/usr/share/man
--infodir=/usr/share/info
--datadir=/usr/share
--sysconfdir=/etc
--localstatedir=/var/lib
--libdir=/usr/lib64
--docdir=/usr/share/doc/racket-8.0
--enable-shared
--enable-float
--enable-libffi
--enable-foreign
--disable-libs
--disable-strip
--enable-useprefix
--enable-bc
--disable-bcdefault
--enable-cs
--enable-gracket
--enable-docs
--enable-jit
--enable-places
--enable-futures
--enable-pthread
I had a similar thought about the potential fighting over .zo files but when I aksed about this a while back @samth said that the compiled artifacts for all 3 implementations should be able to exist together
hrm, based on what I’m seeing here, running raco setup does seem to replace the bc .zo files, what is strange is that somehow that isn’t leading to the same degredation in performance for bc
maybe I can invert the order so that cs is installed second and bc will fail-over to the compiled/bc/ folder?
Each racket binary should have its preferred “compiled” directory baked in.
You don’t have a PLT_ZO_PATH enviornment variable set, right?
More direct check: for each variant, what does (use-compiled-file-paths) report?
I do not (that I know of)
tom@athena ~ $ racketbc
Welcome to Racket v8.0 [bc].
> (use-compiled-file-paths)
'(#<path:compiled/bc>)
>
Welcome to Racket v8.0 [cs].
> (use-compiled-file-paths)
'(#<path:compiled>)
>
Welcome to Racket v8.0 [cgc].
> (use-compiled-file-paths)
'(#<path:compiled/bc>)
However, I do not know whether that is the case when running when compiling.
Maybe it has to do with installing with DESTDIR. The setup/unixstyle-install step may not handle overlayed installations.
(The overlay support was intended for development in a Git checkout, and not as an install mode, but probably it can be made to work.)
Looking more, I see that DESTDIR install mode always uses bc, so that’s a problem in any case.
hrm, good to know, the gentoo build system seems to have been making use of it since the 6.x days as far as I can tell since it requires installation into a sandbox prior to merging into the live system
I’ll see if I can install with different DESTDIR for cs and bc to see if it looks like there is a collision
I was looking at the wrong layer, and now I think DESTDIR is probably ok in just-CS mode. But when both CS and BC are enabled, then it uses BC, and that may go wrong.
That is, you may have to configure with --enable-cs and --enable-bc separately.
hrm, as in two completely separate builds? or would it be possible to build with both enabled, then reconfigure to install each separately without having to rebuild the whole thing twice?
You could use the same directory, but run configure , make, make install then configure, make. make install.
if it helps, I’ve seen this behavior when installing with install-bc and install-cgc separately, but it is fixed by running install-both
hrm, I don’t think the ebuild system is supposed to run two sequential make/installs like that, I’ll keep looking into it
I’m mostly skeptical that it’s a good idea to try to overlay the installations. If I inderstand the context, it seems more right to me that CS and BC would be different packages or treated like different versions of the package.
The issue with trying to split them out is how to deal with the common portions, the source code, the docs, etc. Having all 3 overlayed seems to work without issue in practice.
it also keeps the maintenance burden 4x lower as well which is nice (not to mention the total install size)
it seems that inverting the order to run make install-cs after make install-bc causes the following change Welcome to Racket v8.0 [cs].
> (use-compiled-file-paths)
'(#<path:compiled/ta6le>) The issue remains, but now for bc and cgc installs. However it seems that if I were to somehow be able to set things so that cs used compiled/ta6le and bc/cgc used compiled/bc then the issue would be resolved.
Strangely, the installed implementations do actually have this set. (a few minutes later) WAIT. That’s why they aren’t working! There is a misalignment between (use-compiled-file-paths) once installed and during make install-both. Welcome to Racket v8.0 [cgc].
> (use-compiled-file-paths)
'(#<path:compiled/bc>) Welcome to Racket v8.0 [bc].
> (use-compiled-file-paths)
'(#<path:compiled/bc>) As an aside inverting the order of the install commands also results in the cs build being installed as racketcs with the suffix (neither --enable-csdefault nor --disable-csdefault were set).
Extracted issue: There is a misalignment between (use-compiled-file-paths) once installed and during make install-both. During make install it seems that it is '(#<path:compiled>) and at runtime it is '(#<path:compiled/bc) .
somewhat related make install-cs; make install-bc has different behavior than make install-bc; make install-cs
Now that .zo files are architecture-dependent, is it still safe to share .dep files between architectures? (say if you are packaging Racket for a distro…)
I see that each install-… step discards the existing “compiled” directories in the destination.
What if you gave the two make install-… different DESTDIR targets, and then merged the two directories (preserving timestamps) afterward?
I’m betting that would work.
Now if only I had planned ahead and saved that build state …
will ping back after I try that
@asumu yes, but it is for gentoo, so there is no expectation for portability between architectures because if someone is building packages for redistribution between systems they are assumed to be arch dependent
Oh I was asking completely unrelated to your thread. I maintain the Racket PPA on Ubuntu
But thanks
oop, np, and greetings fellow maintainer!
It seems to work when I try its, so I think that’s probably the way to go.
I recommend copying the CS installation on top of the BC installation, just in case. That will make “system.rktd” match CS, at least (but both BC and CS know how to adapt to the other implementation’s “system.rktd”).
On “.dep” files: it’s best not to try to share them.
A “.dep” records a hash that is related to the module’s compiled form. So, “.zo” files created for different platforms will has different machine code and different hashes.
… except if all the compilations went though machine-independent form (as in “built” source distributions). Then, the recorded hash is actually for the machine-independent form, so they can match. But you have to be careful to ensure that all compiled forms happen that way (which the distro-build system does).
Ah, I see. Thanks, I’ll set them to not shared then.
The “collects” directory is currently filed under “shared” for a Unix-style install, at least by default. Since the “compiled” content is machine-dependent, now, does it really belong in “lib”?
Or, the source belongs in “shared” and the “.zo” belongs in “lib”? That would be possible, but it’s trouble and not well supported by the makefiles…
Hrm, the gentoo policies say that anything that is architecture dependent should go in lib. For example the emacs el and elc files can go in share but the new eln files need to go in lib.
You can pick the directory by providing --collectsdir= to configure.
But, again, that’s both “.rkt” and “.zo”.
Yes, unfortunately the issue is that .rkt -> share and .zo -> lib so the split is more between /compiled/ and .rkt (I think). Which would require something like what common lisp implementations do in dissociating their fasl directories from the source directories (or what emacs native-comp does). I’ve never seen a bug report on this for racket specifically, but if someone was mouting /usr/share between different arches, they would definitely hit a bug.
To split “.rkt” and “compiled”, the relevant Racket parameter is current-compiled-file-roots. But it’s currently only configured for startup through an environment variable or command-line flag, not a “config.rktd” entry.
I don’t think it is pressing, but if at some point the option could make it into config.rktd then that would solve the issue. During build time the environment variable could be used without having to modify the makefiles (I think). Happy to submit an issue on github if it would be helpful.
@hyamanak has joined the channel
it seems that you can’t pass --collectsdir= right now because it gets forwarded to src/cs/c/../../rktio/configure which doesn’t know what to do with it and then fails
seems to fix the issue