geiser and guile talk to each other https://jao.io/cgit/geiser-guile/atom?h=0.11 2014-12-31T19:26:13Z 2014-12-31T19:26:13Z Jose Antonio Ortega Ruiz jao@gnu.org 2014-12-31T19:18:19Z urn:sha1:27b7eacc9c062328d189337e02c2229b4be3e3c7 By hooking the pretty-printer, as discovered by Greg in issue #49. To attain nirvana, we would still need (display (list graph)) to work... 2014-12-29T01:46:12Z Jose Antonio Ortega Ruiz jao@gnu.org 2014-12-29T01:46:12Z urn:sha1:0dbd605e631beea9b46f526deda2a7d05928c49f Up to now, we were only displaying images when printed as values by the REPL, but not when image values were explicitly print-ed, write-d or display-ed. This patch solves that problem by installing (semi) appropriate port-{print,write,display}-handler. This is still and incomplete solution in that those handlers (as well as the already installed current-print-handler) don't recurse over a value's structure and won't produce images embedded in other data structures, as discussed in issue #49. 2014-01-18T04:41:04Z Jose Antonio Ortega Ruiz jao@gnu.org 2014-01-18T04:41:04Z urn:sha1:c00e7678d97beb0107740e408263931b88449886 2014-01-18T04:10:08Z Jose Antonio Ortega Ruiz jao@gnu.org 2014-01-18T04:10:08Z urn:sha1:1839c4042013ae2a4002e228ca2ee8bf295190d3 When using our current-load/used-compiled function, we were compiling the syntax of a module using compile, which seems to not honour With luck, this should address bug #14 for real. 2014-01-08T23:55:20Z Jose Antonio Ortega Ruiz jao@gnu.org 2014-01-08T23:48:57Z urn:sha1:826a054761d0f12f243883a001b2392279580a7f When evaluating (re)definitions in a typed module, it's necessary that the form evaluated is wrapped with #%top-interaction, so that typed racket's redefinition of that macro enters into play and the system records the type information of the new value. Many thanks to Sam Tobin-Hochstadt for the tip, and for his encouraging words. 2014-01-08T23:47:30Z Jose Antonio Ortega Ruiz jao@gnu.org 2014-01-08T23:47:30Z urn:sha1:4bb12c208bab5740fdfa0f77b5c2b279fb941b99 We used to check for a good racket version during its start-up, but these days we already have an independent version check before that. 2013-07-02T16:15:02Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-07-02T16:15:02Z urn:sha1:82e47962fc16c037b8b7c6864dfee3a0eedaf183 2013-06-27T17:23:35Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-06-27T17:23:35Z urn:sha1:096dfb84f6ca774c7f241b9ea446b510bbbccaf5 The new submodules and errortrace interact badly, for what i've seen. In particular, even with the submodule[+*] loading correctly, its namespace doesn't have all identifiers bound, and new ones seem to appear in the bindings lists (things like a.1 or b.2, when a and b are the actual identifiers defined inside the module). Since moreover someone mentioned in the devel ML that errortrace is in general terms buggy, i guess we can leave without it for the time being. 2013-06-11T13:51:05Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-06-11T13:51:05Z urn:sha1:0051c9ee4eefe5f8a9ab56d26f96f57b9f2870ef just because we can 2013-06-11T13:29:25Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-06-11T13:29:25Z urn:sha1:5e1b969e20004f49f1174346a612269c56d0d785 Submodule (re)loading is not without pecularities. In particular, module[*+] submodules are not visited the first time one enters its parent, but once you load them once, they're revisited every time we load the parent afterwards--racket's native enter! exhibits the same behaviour, so i'm guessing we'll have to live with that. There is however a glitch in that submodules can only be reloaded then by loading the parent, so we need to confirm that this is expected behaviour and, if it is, automating the parent's load when the submodule's is requested. On the other hand, entering a module[*+] is not working in Geiser yet, and it does in plain racket, so this one is our fault. Working on it.