feeley on master
Implement SRFI 26: Notation for… Merge branch 'master' into srfi Merge pull request #700 from Ne… (compare)
feeley on master
Explain ## identifiers in manual Fix according to review Add big table of type specifiers and 2 more (compare)
clikion my servers, developed all of my software in CL and even used/developed a delimited continuation framework that could do something similar to
u8vector->object->u8vectorand store kont's in the database as sexprs that I could intepret. I totally understand where @tomelam is coming from, while at the same time completely agree that running Gambit on both the client and server is the much preferred approach.
@feeley > I don’t understand the link with Common Lisp in your app… it may be better for both the server and the client to run Gambit code (in particular because it allows using
u8vector->object to send objects between the client and server including closures). That may not immediately be needed but a nice feature for advanced uses.
I should really think about sending closures to the server. That is a very interesting and potentially useful capability.
@feeley > not only closures… you can also send continuations… which means that migrating the client code to run on the server (or the other way around) really easy
Thanks! I'll read that, but is there anything special in Gambit that would allow transferring and reusing a continuation?
for details please check the following slides: https://github.com/gambit/gambit-at-30/blob/master/talks/Gambit30-UnivBE.pdf
The picture of the same game running on a desktop and on a mobile phone instantly got me to understand how useful the transfer of a computation to a new environment is. I can see that especially with single page web applications this is a powerful capability, since it would be painful to 'manually' save state information and hope we didn't forget any important part of the state.
stamp.h. The former gives a stamp of the latest release and only changes at a new release point. The file
stamp.his created from the latest commit information when git is available. It is OK to create an empty
stamp.hwhen git is not available or the sources were not obtained using
git clone …. Anyway it should work that way. What is the purpose of you proposed patch?
(substitute* "include/makefile.in" (("echo > stamp.h;") "echo \"Actually, non, we make one for guix!\"; cat stamp.h;"))
catis just so I can see the
stamp.hI generate while building so I don't have to wait and see the results of
.gitfolder is not constant, can change drastically, and is not "secure and functional" from a package management POV as it is constantly changing.
git describe --tagsand the timestamps. :)
(define gdesc (git-repo-describe--tags grepo)) [...] ($cmd "sh" "-c" "TZ=UTC git show --quiet --date='format-local:%Y%m%d' --format=%cd") [...] ($cmd "sh" "-c" "TZ=UTC git show --quiet --date='format-local:%H%M%S' --format=%cd")
(define versions (list (make <druix-version-git> #:major 4 #:minor 9 #:patch 3 #:revision 1427 #:ymd 20210606 #:hms 132415 #:sha256 "0rw595mh2a4b9v03mb5rfmkhmkg0fg4clzzr7b95n4c8w3wj19mk" #:repo "https://github.com/gambit/gambit.git" #:commit "46618e760ae2c8577c704d0e0b07fe5695c9dcb9")))
stamp.h, as well as the repo, commit, and sha hash. Using that object, I make a
gambit-c-unstablepackage that is almost bit-for-bit identical to the one made by your version of
makebut is secure and functional and does not rely on constantly changing "cannot be confirmed as secure cannot be identically hashed"