geiser and guile talk to each other https://jao.io/cgit/geiser-guile/atom?h=0.6 2014-01-18T04:41:04Z 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. 2013-06-09T22:06:55Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-06-09T22:06:55Z urn:sha1:7b1a1d046059eb2ce68ea02706a0e7494c39684f ... and used also internally for C-c C-k, although it doesn't yet work as well as i wanted when it comes to load modules. The reason is probably in geiser/enter, where we don't record modification times per submodule but per path, which is not correct in the presence of submodules. 2013-06-09T22:04:30Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-06-09T22:04:30Z urn:sha1:bba166c3ccb136fa8321ad9acc9cfd48a5fed357