Hi Vyzo,
So finally read https://github.com/vyzo/gerbil/blob/master/README.md and all subpages on https://cons.io/ word by word.
I was trying to go through the obvious moves of incremental dev and it crashed down totally. Kindly point out the misunderstandings and any Gerbil customizations that are needed for this obvious usecase:
1. I create a module "a.ss" (this is a typo, should be "a.scm" but i understand Gerbil has an exotic default, query about how to normalize the setting in subsequent email). Code is:
(display "Hello world\n")
2. Compile the module:
The documentation does not disclose how to do this from the REPL, so I do it by
,q GAMBCOMP_VERBOSE=yes gsx a.ss GAMBCOMP_VERBOSE=yes gsi
I see that this works as ~/.gerbil/lib/ now gets a module file (.o*), great. Now,
3. Import the module:
(import "a")
So far, the correct thing happens: The text "Hello world" is printed out.
4. Now, with gsi running, separately in another xterm we alter a.ss (a.scm) a bit, we add two exclamation marks to the string, so the content is now:
(display "Hello world!!\n")
5. In the gsi REPL, we run again:
(import "a")
What happens now is a mysterious nothing!
This shows that Gerbil does not automatically reimport updated dependencies.
Also, no new binary is produced - there is no output showing any gcc invocation (which is the behaviour specified by "GAMBCOMP_VERBOSE=yes"), and also "ls -l ~/.gerbil/lib/" shows that no new .o* files have been produced.
Disaster.
There is no mentioning in the documentation of how to make |import| automatically recompile any module that has been compiled already AND automatically reimport any module in the dependency graph, whose modification timestamps have changed since the previous |import|.
The obvious usecase at hand is that you have more files as dependencies in a code project, and as you go about development you edit them sporadically, and Gerbil will have them auto-recompiled, auto-reimported and their global namespace auto-evaluated (in a.ss's case, a |display|) as you go along, this is essential.
Is this about a Gerbil setting that I need to configure, or a question of deep Gerbil hacking, or is Gerbil unfit for the work and I should leave it altogether?
Thanks, Adam
PS
Following rectification of the above, I would throw in some FFI stuff like
echo "((c-lambda () void "printf("Hi from C\n");"))" >> a.ss
to see that FFI stuff is handled symmetrically in the same fashion as any other Scheme code.
Afficher les réponses par date
I was trying to go through the obvious moves of incremental dev
(import "a") So far, the correct thing happens: The text "Hello world" is printed out. 4. Now, with gsi running, separately in another xterm we alter a.ss 5. In the gsi REPL, we run again: (import "a")
What happens now is a mysterious nothing!
This shows that Gerbil does not automatically reimport updated dependencies.
For better or worse, many (perhaps most) Scheme implementations behave this way. (import ...) is different from (load ...) and does not reload already-loaded modules even if you have edited them.
Often one way to solve it is to use `load` after your edits:
(load "a.ss") (import "a")
I don't know whether this is the "right" way to do it.
Hi Lassi,
Thanks for your response.
Manual load semantics is what you get from Gambit.
The reason for using Gerbil as a layer on top of Gambit, is to get automatic recompile, automatic reimport, automatic reevaluate as automation of exactly that is essential to incremental dev. ""This (detail) is not rocket science"", it's perfectly doable, so I wonder was something switched off or have I misunderstood what Gerbil is etc., so looking forward to Vyzo's clarification.
Adam
On Thu, 3 Oct 2019 at 23:12, Lassi Kortela lassi@lassi.io wrote:
I was trying to go through the obvious moves of incremental dev
(import "a") So far, the correct thing happens: The text "Hello world" is printed
out.
4. Now, with gsi running, separately in another xterm we alter a.ss 5. In the gsi REPL, we run again: (import "a")
What happens now is a mysterious nothing!
This shows that Gerbil does not automatically reimport updated
dependencies.
For better or worse, many (perhaps most) Scheme implementations behave this way. (import ...) is different from (load ...) and does not reload already-loaded modules even if you have edited them.
Often one way to solve it is to use `load` after your edits:
(load "a.ss") (import "a")
I don't know whether this is the "right" way to do it.
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list
Followup:
I discussed the |import| question below with Vyzo and he says he'll reimplement a new flavor of |reload| which will have this described function.
There is a |reload| already (defined in https://github.com/vyzo/gerbil/blob/master/src/std/interactive.ss ) but * it only reimports one given module, not its dependency modules, and in that gist also * does not import added dependencies (it doesn't touch the dependency graph at all).
So Vyzo needs to make an extended |reload| that does that too.
On Thu, 3 Oct 2019 at 10:59, Adam adam.mlmb@gmail.com wrote:
Hi Vyzo,
So finally read https://github.com/vyzo/gerbil/blob/master/README.md and all subpages on https://cons.io/ word by word.
I was trying to go through the obvious moves of incremental dev and it crashed down totally. Kindly point out the misunderstandings and any Gerbil customizations that are needed for this obvious usecase:
- I create a module "a.ss" (this is a typo, should be "a.scm" but i
understand Gerbil has an exotic default, query about how to normalize the setting in subsequent email). Code is:
(display "Hello world\n")
- Compile the module:
The documentation does not disclose how to do this from the REPL, so I do it by
,q GAMBCOMP_VERBOSE=yes gsx a.ss GAMBCOMP_VERBOSE=yes gsi
I see that this works as ~/.gerbil/lib/ now gets a module file (.o*), great. Now,
- Import the module:
(import "a")
So far, the correct thing happens: The text "Hello world" is printed out.
- Now, with gsi running, separately in another xterm we alter a.ss
(a.scm) a bit, we add two exclamation marks to the string, so the content is now:
(display "Hello world!!\n")
- In the gsi REPL, we run again:
(import "a")
What happens now is a mysterious nothing!
This shows that Gerbil does not automatically reimport updated dependencies.
Also, no new binary is produced - there is no output showing any gcc invocation (which is the behaviour specified by "GAMBCOMP_VERBOSE=yes"), and also "ls -l ~/.gerbil/lib/" shows that no new .o* files have been produced.
Disaster.
There is no mentioning in the documentation of how to make |import| automatically recompile any module that has been compiled already AND automatically reimport any module in the dependency graph, whose modification timestamps have changed since the previous |import|.
The obvious usecase at hand is that you have more files as dependencies in a code project, and as you go about development you edit them sporadically, and Gerbil will have them auto-recompiled, auto-reimported and their global namespace auto-evaluated (in a.ss's case, a |display|) as you go along, this is essential.
Is this about a Gerbil setting that I need to configure, or a question of deep Gerbil hacking, or is Gerbil unfit for the work and I should leave it altogether?
Thanks, Adam
PS
Following rectification of the above, I would throw in some FFI stuff like
echo "((c-lambda () void "printf("Hi from C\n");"))" >> a.ss
to see that FFI stuff is handled symmetrically in the same fashion as any other Scheme code.
On Oct 16, 2019, at 4:54 PM, Adam adam.mlmb@gmail.com wrote:
Followup:
I discussed the |import| question below with Vyzo and he says he'll reimplement a new flavor of |reload| which will have this described function.
There is a |reload| already (defined in https://github.com/vyzo/gerbil/blob/master/src/std/interactive.ss ) but
- it only reimports one given module, not its dependency modules, and in that gist also
- does not import added dependencies (it doesn't touch the dependency graph at all).
So Vyzo needs to make an extended |reload| that does that too.
Then please make sure that Gerbil's reload implementation calls
(##remove-registered-module module-ref)
which is defined in lib/_kernel.scm . It removes a module from the registered modules so that the next time it is imported with a (##demand-module …) or (##load-module …) it will be reloaded. Note that .o1 files can only be reloaded if they are recompiled.
Marc