Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 13 13:31
    Negdayen opened #703
  • Jun 12 17:16
    CI run 931553101 passed
  • Jun 12 16:37
    feeley commented #700
  • Jun 12 16:37

    feeley on master

    Implement SRFI 26: Notation for… Merge branch 'master' into srfi Merge pull request #700 from Ne… (compare)

  • Jun 12 16:37
    feeley closed #700
  • Jun 12 07:29
    lassik commented on 1502a21
  • Jun 12 06:18
    lassik opened #702
  • Jun 12 01:02
    gambiteer commented on 1502a21
  • Jun 12 01:00
    gambiteer commented on 1502a21
  • Jun 11 22:28
    Windows-mingw build of CI run 929941762 failed
  • Jun 11 22:00

    feeley on master

    Explain ## identifiers in manual Fix according to review Add big table of type specifiers and 2 more (compare)

  • Jun 11 22:00
    feeley closed #701
  • Jun 11 21:08
    lassik commented #701
  • Jun 11 21:07
    lassik synchronize #701
  • Jun 11 20:46
    feeley commented #701
  • Jun 11 19:41
    lassik opened #701
  • Jun 11 14:20
    feeley commented on e05d171
  • Jun 11 04:16
    gambiteer commented on e05d171
  • Jun 11 02:15
    feeley synchronize #700
  • Jun 10 21:18
    Windows-mingw build of CI run 926465553 failed
Tom Elam
@tomelam
@feeley Even though I want to use Lisp on the backend, I think having a real, complete Scheme in the browser is ultra cool. Having a very high quality Scheme that can interact easily with the DOM (Gambit) in the browser is incredibly cool. The high quality of Gambit's documentation and its very active current development are huge plus points, too.
Drew Crampsie
@drewc
@feeley I used to be a CL Lispnik. Ran common-lisp.net and cliki on 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.
drewc @drewc is still in the process of porting his clients over to Gerbil/Gambit from CL but has really enjoyed it thus far :)
Tom Elam
@tomelam

@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 object->u8vector and 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.

Marc Feeley
@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
Marc Feeley
@feeley
@drewc Glad to know that you are leaving the empire and gradually joining the force!
Marc-André Bélanger
@belmarca
talking about the Force... seen on the highway: https://imgur.com/oIKBDbt
Jaime Fournier
@ober
nice
Marc Feeley
@feeley
I’m glad to see he is staying focused and not taking the exit to Laval...
also known as the dark side of the force...
Jaime Fournier
@ober
where the java people live?
Marc Feeley
@feeley
yes… Java the Hutt...
Marc-André Bélanger
@belmarca
haha
I grew up there, beware
Marc Feeley
@feeley
great! you too have left the empire and have joined the force! (I won’t mention where I grew up…)
Marc-André Bélanger
@belmarca
somewhere in the Local Group, one of us.
Drew Crampsie
@drewc
If I say that four twenties is "huitante" does that give a hint as to where I grew up? :) I won't even mention how we say "oi" but I will say that I really enjoy visiting Montweal.
Marc Feeley
@feeley
Where I grew up is the equivalent of Tatooine in Star Wars… a desertic lawless land crawling with smuglers.
Marc Feeley
@feeley
@drewc land of chocolate or fries...
Tom Elam
@tomelam

@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?

Tom Elam
@tomelam
Something that Common Lisp doesn't have?
Marc Feeley
@feeley
@tomelam Yes Gambit allows code to be serialized/deserialized both in the form of procedures/closures and continuations. This means that a process that is executing on one “computational node” (server, client, etc) can be migrated easily to another node by capturing its continuation, sending it to the other node, killing the local process and invoking the continuation in a fresh thread at the destination node. This is an essential feature for the implementation of Termite, a distributed programming language built using Gambit (see http://www.iro.umontreal.ca/~feeley/papers/GermainFeeleyMonnierSW06.pdf).
Tom Elam
@tomelam
@feeley I'm also looking at http://www.iro.umontreal.ca/~feeley/ (selected papers). It looks like textbooks' worth of papers!
Tom Elam
@tomelam

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.

Drew Crampsie
@drewc
@tomelam I do a lot of "webapps" using quasar, vue and Gambit. The nice thing about Quasar is that it allows me to use the same codebase for SPA's, PWA's and Android/iOS and even "desktop" apps, and that codebase is almost entirely "javascript". The basic idea of transferring a closure from "peer" to "peer", in C, JS, Python, and our other universal backends still blows my mind.
I remember seeing it in person before I really understood what it was, and was in shock then. The shock has worn off but it's still electrifying :)
Tom Elam
@tomelam
@drewc :-)
François-René Rideau
@fare
@feeley this migration feature requires code to be compiled from the same source with the same version of gambit and maybe even same compilation options, doesn't it?
@feeley as for the recent change in generation of stamp.h — shouldn't the Makefile leave stamp.h unchanged when it exists and there's no git? Otherwise, how is Nix or Guix supposed to compile an unreleased tarball and supply its timestamp information?
François-René Rideau
@fare
Would you accept a patch where at line 325 of include/makefile.in I insert:
    elif [ -f stamp.h ] ; then \
        echo "Gambit is not being built from a Git clone. Trusting user-supplied stamp.h." ; \
François-René Rideau
@fare
Would there be more places that need to be patched accordingly, to allow build from a non-release tarball?
Marc Feeley
@feeley
@fare Concerning code/task migration it depends… if the code is interpreted then the migration is the least sensitive to compilation options and version… for the migration of compiled code it is best to stick to the same version of Gambit and the same configuration options (but some configuration options are innocuous, like --enable-single-host and --enable-targets=…, and the C compiler “brand” and version that is used, and the endianness and word width of the processor)… One particularly interesting feature is that the code of the different targets of the universal backend (JavaScript, Python, PHP, etc) does not matter. So you can migrate Scheme code that is running on top of JS in the browser to a Scheme program running on top of Python, on inside nodejs on the server). Code cannot be migrated between programs compiled by the C backend and another backend.
The stamp is now contained in two files stamp-release.h and stamp.h. The former gives a stamp of the latest release and only changes at a new release point. The file stamp.h is created from the latest commit information when git is available. It is OK to create an empty stamp.h when 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?
Drew Crampsie
@drewc
@feeley Here's what I needed to do to build a bleeding edge from the git tree WITHOUT the .git directory: https://github.com/drewc/druix/blob/main/doc/scheme/gambit.org#includestamph
So, that patch would get rid of these three lines:
(substitute* "include/makefile.in"
               (("echo > stamp.h;")
                 "echo \"Actually, non, we make one for guix!\"; cat stamp.h;"))
that cat is just so I can see the stamp.h I generate while building so I don't have to wait and see the results of gsc -v :P
Drew Crampsie
@drewc
Personally, I don't think that patch is "needed", but at the same time, the build system is not made to make a package from HEAD of master which is why I do not see a need to even try to shim it that way.
Marc Feeley
@feeley
I’d like to avoid assigning “non standard” stamps to Gambit builds because this will make it harder to diagnose issues when they are reported. The point of having a stamp is to precisely identify the build that is being used and allow building the same thing locally to reproduce the issue. Is the GUIX build expected to be different than a commit on the github repo and if so why?
Drew Crampsie
@drewc
It's exactly the same, but, is functional and relies on the exact same source being compiled that has to match the sha256 you specify. So, ideally., I output the exact same binaries as building from a git repo does, but, I cannot build from a git repo as, gasp, the .git folder is not constant, can change drastically, and is not "secure and functional" from a package management POV as it is constantly changing.
So, whatever your "non-standard" stamps refer to, I am not sure what they are or how to create them. My 'stamp.h' is, bit for bit, identical to the one generated from git describe --tags and the timestamps. :)
These are the three lines that matter:
  (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")
Drew Crampsie
@drewc
Note that they are the scheme version of the start of the stamp: target in include/makefile.in, but have to be run outside of the build because guix is functional and relies on the exact same source tree being built to make it the exact same binary.
Since it also requires a hash, that "builds" a file that has this:
(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")))
There is all the data used to build the stamp.h, as well as the repo, commit, and sha hash. Using that object, I make a gambit-c-unstable package that is almost bit-for-bit identical to the one made by your version of make but is secure and functional and does not rely on constantly changing "cannot be confirmed as secure cannot be identically hashed" .git folder.
Drew Crampsie
@drewc
In case it's not obvious, I'd love to just "build from git", but that is not allowed for a functional package manager and, well, I prefer functional packages these days for staging and production :)