Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 19 17:59
    fare opened #659
  • Jan 14 23:42
    gambiteer commented on ca8b488
  • Jan 14 22:02
    Windows-mingw build of CI run 486454730 failed
  • Jan 14 21:37

    gambiteer on master

    Speed up implementation of SRFI… (compare)

  • Jan 12 16:17
    feeley commented #658
  • Jan 12 16:11
    jcubic commented #658
  • Jan 12 15:48
    feeley commented #658
  • Jan 12 15:30
    feeley closed #658
  • Jan 12 15:30
    feeley commented #658
  • Jan 12 14:10
    jcubic opened #658
  • Jan 09 18:35
    feeley closed #657
  • Jan 09 18:35
    feeley commented #657
  • Jan 09 15:28
    jcubic opened #657
  • Jan 09 14:42
    Windows-mingw build of CI run 474136150 failed
  • Jan 09 14:15

    feeley on master

    Universal backend: add URL whit… (compare)

  • Jan 08 21:28
    feeley commented #655
  • Jan 08 20:48
    lassik commented #655
  • Jan 08 08:00
    jcubic commented #655
  • Jan 08 07:59
    jcubic commented #655
  • Jan 08 02:00
    Windows-mingw build of CI run 470488801 failed
salotz
@salotz:matrix.org
[m]
I'm interested in spreadsheets and "notebooks"
It's been getting popular for at least 2 years lol
amirouche
@amirouche
I was dreaming for notion so hard, but javascript...
salotz
@salotz:matrix.org
[m]
I tried it but really just didn't like it. Too underpowered for desktop, too complicated for phone
amirouche
@amirouche
I will create a notion database for gambit and gambit js so that one can quickly go through the API
(I won't spend too much time on it, to avoid duplicate work)
as token of gratitude :)
does someone know what scheme is used in try.scheme.org ?
it seems like gambit but...
Marc Feeley
@feeley
yes I’m on the dev group for try.scheme.org and there weren’t too many options for a mature Scheme system running on top of JS
anybody is welcome to add to the discussion at: schemeorg/try.scheme.org#1
we’re currently discussing security issues with running untrusted code in the REPL
the try.scheme.org REPL allows things like (load “http://…”) which is neat but dangerous… I added a whitelist to guard loading untrusted code
try ,help...
amirouche
@amirouche
Excellent work
Marc Feeley
@feeley
there’s a browser local filesystem and URLs can also be opened (if the whitelist contains them or a prefix)
what remains to be done: 1) an online code editor to modify the local filesystem, 2) TAB completion of symbols/variables, 3) support utf8 in files, 4) fix small things that are broken/missing
If anyone would like to help out, you are welcome to join the project… things are advancing quickly (most of the new work was done this past week)
François-René Rideau
@fare
do the write environment of ##wr have an option for print-readably vs not, or better, print the source form or not (just like Racket can print (list 1 2 3) or something rather than (1 2 3) and 'a instead of a) ?
(and if so, how do I trigger that option?)
(or check for it)
Marc Feeley
@feeley
I think “print-evaluably” would be a better term for what you want… this feature is a huge can of worms… (what is doing the evaluation? in which scope? etc) In any case this shouldn’t be implemented in the pretty printer but rather in a preprocessing of the datum before it is passed to the pretty-printer. The procedures##inverse-eval and ##inverse-eval-in-env are used by the REPL for that purpose, but they are rather basic:
> (##inverse-eval 123)
123
> (##inverse-eval (list 1 2 3))    
'(1 2 3)
François-René Rideau
@fare
Is there an extension mechanism for ##inverse-eval ?
François-René Rideau
@fare
I have this in one file, and forgot what it is about. Maybe forcing UTF-8 output?
(##vector-set! ##stdout-port 37 (lambda (port) 218))
Also this in another file:
(##set-debug-settings! 15 3)
François-René Rideau
@fare
Are there thread safety issues with Gambit ports when using the regular green threads???
Looks like I have output that goes to /dev/null and/or is overwritten in buffers?
François-René Rideau
@fare
Is it a bug if letrec* reorders statements? I think it is.
François-René Rideau
@fare

Here is a stripped down example of behavior that really tripped me:

":" ; ( echo -e 'INTERPRETED' ; gsi letrec-star-reordered.scm; echo -e '\nCOMPILED' ; gsc letrec-star-reordered.scm && gsi -e '(load "letrec-star-reordered")' ) 2>&1 | less

(define (displayln . a) (for-each display a) (newline))

(define (reordered)
  (letrec* ((x (begin (displayln 100) 42))
            (_200 (displayln 200))
            (_300 (displayln 300 (list x)))
            (_400 (displayln 400))
            (y (begin (displayln 500) 23)))
    (displayln 600 (list y))))

(reordered)

Note how, when compiling, line 300 is moved below line 500.

Is that a bug in letrec* or in my understanding of its spec as "evaluate left to right" ?
François-René Rideau
@fare
I re-read the r7rs small, and it seems to me that my understanding is correct, and Gambit is in contravention here.
IIUC, the code is compiled by lib/_eval.scm function ##comp-let-like-form but the code is lacking in comments, so it is hard to understand both what is going on and what should be going on.
Drew Crampsie
@drewc
@fare you may want to look at r5rs
drewc @drewc is just thinking off what Gambit may be based on
Bradley Lucier
@gambiteer
r5rs doesn't have letrec*. Are you recommending he not use letrec*?
Drew Crampsie
@drewc
Well., shows how many r5rs's I know the details of lol
I'm fairly certain he's not actually using letrec* but forms that expand to it, so perhaps, yes, yes I am :)
François-René Rideau
@fare
Well, Gerbil expands its def statements to letrec*, so this is a big deal when suddenly the order of statements in Gerbil is not guaranteed and side-effects happen out of order.
In the meantime, I'm nesting let and begin statements (with the nest macro) until this matter is resolved. I wasted too many hours on this. I'd like to fix Gambit, but understanding that code would require serious archaeology to unearth the intent of the code, so I can fix it.
Drew Crampsie
@drewc
@fare I agree with def being out of order is not quite right, and same for letrec* really.
drewc @drewc just realised he's run into that a few times but thought it was thinking CL like, not scheme like, and used let and friends to get over that.
Drew Crampsie
@drewc
@fare It certainly gets weirder
(define (ordered)
  (letrec* ((displayln (lambda a (for-each display a) (newline)))
            (x (begin (displayln 100) 42))
            (_200 (displayln 200))
            (_300 (displayln 300 (list x)))
            (_400 (displayln 400))
            (y (begin (displayln 500) 23)))
    (displayln 600 (list y))))

(ordered)
I was trying to figure out why I thought it was scheme and the lack of order. Took me about 3/4 of an hour and a half cup of coffee, and came up with that.
Drew Crampsie
@drewc
If side effects are ordered within the letrec*, they remain so it seems. I'll give up now and go back to my minimal JS runtime. That's all by rote now :)
François-René Rideau
@fare
Looks like the statements that don't depend on anything previous definition are floated up, even when they shouldn't due to side-effects.
Which is how letrec works, but not how letrec* should work.
François-René Rideau
@fare
ccccccejnbeuelufugjdfbnfgkdkektlcifgcvhbdduf
Marc-André Bélanger
@belmarca
yubikey?
François-René Rideau
@fare
Yes. Grumble.