4 ms·

when I play around with Gambit (gsi) I often end up with bus errors. This implies the word: 'half-assed' to me. So that is directly annoying and will guaranteed

by morphir 17y ago

when I play around with Gambit (gsi) I often end up with bus errors. This implies the word: 'half-assed' to me. So that is directly annoying and will guaranteed put new users off. Crashing is never good.

stuntmouse 17y ago
That's extremely surprising. I'm sure the maintainers would be eager to hear about your experiences. Care to provide example code which triggers a crash with a little detail about version and platform? The best place to post would be the mailing list [1] or the bug tracker [2]. [1] https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-lis... [2] http://www.iro.umontreal.ca/~gambit/bugzilla/ http://www.iro.umontreal.ca/~gambit/bugzilla/
- morphir 17y ago
  3> (define x (lambda (y) (* 2 y))) * WARNING -- defining global variable: x 3> x Bus error Gambit v4.5.2 OSX 10.5 Of course, I do know that x should not be evaluated. For that have to type (x 3). But its still annoying, and very unnecessary. In DrScheme/PLT I get a: > x #<procedure:x> Explicitly telling me its a procedure.
  - stuntmouse 17y ago
    I've reproduced your crash. The issue is that you're using define within a nested REPL, which isn't supported [1]. However, a segfault is really not acceptable. I'll file a report for this. [1] http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Debugging http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Debugg... Relevant section: "Note that some special forms (define in particular) can only be evaluated in the global interaction environment."
    - NikkiA 17y ago
      I'm fairly sure that the nested repl 'define' being allowed at all is a fairly recent change, I seem to recall just getting an error when trying to define in a nested repl in 4.4.x.
      - stuntmouse 17y ago
        Right, it looks like a regression in 4.5.*. 4.4.4 is fine.
  - NikkiA 17y ago
    I've had these crashes, and I can tell you exactly what it is that is causing it... You're not at the top level of the repl, for some reason, defining things at a lower nesting level of the repl sometimes produces crashes, it's annoying yes, but it's not a huge disaster :) if you use ",t" to get back to the top level after an error, you shouldn't see those crashes.
  - stuntmouse 17y ago
    This is fixed in 4.5.3. The crash was caused by printing the value of the procedure in the nested REPL. Using define in nested REPLs works, but you'll get a warning about it.
- deleted 17y ago
  [deleted]
- deleted 17y ago
  [deleted]

by morphir 17y ago

stuntmouse 17y ago

That's extremely surprising. I'm sure the maintainers would be eager to hear about your experiences. Care to provide example code which triggers a crash with a little detail about version and platform? The best place to post would be the mailing list [1] or the bug tracker [2]. [1] https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-lis... [2] http://www.iro.umontreal.ca/~gambit/bugzilla/ http://www.iro.umontreal.ca/~gambit/bugzilla/

morphir 17y ago
3> (define x (lambda (y) (* 2 y))) * WARNING -- defining global variable: x 3> x Bus error Gambit v4.5.2 OSX 10.5 Of course, I do know that x should not be evaluated. For that have to type (x 3). But its still annoying, and very unnecessary. In DrScheme/PLT I get a: > x #<procedure:x> Explicitly telling me its a procedure.
- stuntmouse 17y ago
  I've reproduced your crash. The issue is that you're using define within a nested REPL, which isn't supported [1]. However, a segfault is really not acceptable. I'll file a report for this. [1] http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Debugging http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Debugg... Relevant section: "Note that some special forms (define in particular) can only be evaluated in the global interaction environment."
  - NikkiA 17y ago
    I'm fairly sure that the nested repl 'define' being allowed at all is a fairly recent change, I seem to recall just getting an error when trying to define in a nested repl in 4.4.x.
    - stuntmouse 17y ago
      Right, it looks like a regression in 4.5.*. 4.4.4 is fine.
- NikkiA 17y ago
  I've had these crashes, and I can tell you exactly what it is that is causing it... You're not at the top level of the repl, for some reason, defining things at a lower nesting level of the repl sometimes produces crashes, it's annoying yes, but it's not a huge disaster :) if you use ",t" to get back to the top level after an error, you shouldn't see those crashes.
- stuntmouse 17y ago
  This is fixed in 4.5.3. The crash was caused by printing the value of the procedure in the nested REPL. Using define in nested REPLs works, but you'll get a warning about it.
deleted 17y ago
[deleted]
deleted 17y ago
[deleted]