Fork me on GitHub
#lumo
<
2019-10-27
>
dotemacs10:10:44

Hi With lumo 1.7.0

$ echo "{:foo :bar}" > resources/aha.edn
which is started via:
lumo -D aero:1.1.3 -c src:test -d
running this at the REPL:
(require '[aero.core :refer [read-config]])
(read-config "resources/aha.edn")
works as expected. Then tried it with 1.8.0 and that is fine too. But with 1.9.0 or 1.10.1, it fails with:
fs is not defined
         aero$core$read_config_into_tag_wrapper (evalmachine.<anonymous>:829:386)
         Function.aero.core.read_config.cljs$core$IFn$_invoke$arity$2 (evalmachine.<anonymous>:860:61)
         aero$core$read_config (evalmachine.<anonymous>:844:30)
         Function.aero.core.read_config.cljs$core$IFn$_invoke$arity$1 (evalmachine.<anonymous>:865:30)
         aero$core$read_config (evalmachine.<anonymous>:848:30)
         (evalmachine.<anonymous>:1:23)
         Script.runInThisContext (vm.cljs:90:20)
         Object.runInThisContext (vm.cljs:297:38)
         ()
         (Object.lumo.repl.caching_node_eval)

dotemacs10:10:02

My guess is that something changed between Lumo 1.8.0 and the subsequent versions that doesn’t pick up fs node module.

dotemacs10:10:23

This aero version 1.1.3 is the latest stable.

dotemacs10:10:31

Any hints about what could be causing this would be much appreciated. I can will stick with Lumo 1.8.0 for time being. Thanks

futuro12:10:05

When you open the latest lumo, what happens when you try to require the fs module?

dotemacs16:10:48

Hey @futuro This is what happens: On Lumo 1.8

cljs.user=> (require 'fs)
cljs.user=> nil
cljs.user=> (fs.readFile "resources/aha.edn" (fn [_ data] (println data)))
nil
cljs.user=> #object[Buffer {:foo :bar}
]

dotemacs16:10:59

On Lumo 1.10.1

cljs.user=> (require 'fs)
nil
cljs.user=> (fs.readFile "resources/aha.edn" (fn [_ data] (println data)))
fs is not defined
	 (evalmachine.<anonymous>:1:1)
	 Script.runInThisContext (vm.cljs:124:20)
	 Object.runInThisContext (vm.cljs:314:38)
	 ()
	 (Object.lumo.repl.caching_node_eval)
	 (NO_SOURCE_FILE <embedded>:6029:9)
	 z (NO_SOURCE_FILE <embedded>:6030:22)
	 (NO_SOURCE_FILE <embedded>:6025:264)
	 Function.cljs.core.trampoline.cljs$core$IFn$_invoke$arity$1 (NO_SOURCE_FILE <embedded>:1927:142)
	 Function.cljs.core.trampoline.cljs$core$IFn$_invoke$arity$variadic (NO_SOURCE_FILE <embedded>:1927:280)

dotemacs16:10:20

But then in the same REPL session:

cljs.user=> (require '[cljs.nodejs :as nodejs])
nil
cljs.user=> (def fs  (nodejs/require "fs"))
#'cljs.user/fs
cljs.user=> (fs.readFile "resources/aha.edn" (fn [err data] (println data)))
nil
cljs.user=> #object[Buffer {:foo :bar}
]

anmonteiro17:10:40

@dotemacs I’m puzzled — what made you think that . would work to access a namespace’s functions?

anmonteiro17:10:07

if you use (require 'fs) then use fs/readFile

anmonteiro17:10:14

fs.readFile is not a thing for namespaces

futuro18:10:40

@dotemacs reading the aero source, they’re using the fs/readFileSync form, and the only difference is (:require ["fs" :as fs]).

futuro18:10:25

Given that the function access looks right, my guess is that the latest lumo doesn’t like something about the require form.

futuro18:10:25

I don’t know enough about cljs requires and how they work in lumo to hypothesize past that, but hopefully it’s enough to get you moving in the right direction.

futuro18:10:47

The aero maintainers may know more if you open an issue

dotemacs18:10:52

@anmonteiro ok, sorry, my bad. But why does fs.readFile work for Lumo 1.8 and not for Lumo 1.9+?

anmonteiro18:10:06

it might be an implementation detail

anmonteiro18:10:28

we’re not in control of what Node.js exposes in the scope

dotemacs18:10:16

@futuro I’ll open an issue for sure, thanks. But that require that you’ve shared above is in aero 1.1.3. Added here: https://github.com/juxt/aero/pull/59/files If I look in the code for aero 1.1.2, which used to work, for Lumo 1.7.0, it doesn’t work for Lumo 1.8.0. This particular code:

(require '[aero.core :refer [read-config]])
(read-config "resources/aha.edn")
That is invoked via:
lumo -D aero:1.1.2 -c src:test -d
From looking at the aero.core namespace at that release, 1.1.2, fs is not being required at all, but it is being used, like here: https://github.com/juxt/aero/blob/af40928fc77facc4927075c63b7262bc961b6761/src/aero/core.cljc#L359

futuro18:10:50

Ah! I’d missed that you were on an older version.

futuro18:10:25

Does your code work with aero 1.1.3?

futuro18:10:17

If so, my guess is that older versions of lumo have the fs module available as part of environment, and newer versions don’t.

futuro18:10:58

Which would explain the change is from aero 1.1.2->1.1.3

dotemacs18:10:50

Regardless of the aero version used, the code works, up to Lumo 1.8. From Lumo 1.9+, the aero’s read-config throws an exception as per above.

dotemacs18:10:57

How can I ensure that the fs module is part of the environment, so that aero continues to work correctly ?

dotemacs19:10:31

I’ve raised an issue on aero’s repo, adding this here in case somebody else stumbles upon this issue: https://github.com/juxt/aero/issues/80

futuro22:10:06

No clue about fixing aero, but I suspect the maintainers will know.