Clojurians
#lumo
<
2017-02-01
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

viebel10:02:14

Hi @anmonteiro

viebel10:02:19

Have u done something special in lumo to support macro implicit loading?

viebel10:02:49

@moxaj created a simple example that works fine in lumo but not in klipse

viebel11:02:04

I thought it was part of cljs 1.9.293

viebel11:02:20

Klipse is on 1.9.456 and yet it doesn’t work :disappointed:

anmonteiro15:02:18

@viebel: I don't recall having done anything special for that to work

viebel15:02:58

Any idea what could make it not working in klipse?

viebel15:02:16

any special flag sent to the compiler?

viebel15:02:26

any trick around update current namespace?

anmonteiro15:02:22

@viebel: "not working" is simply not enough information for me to understand what's going wrong

viebel15:02:55

Here are the full details

viebel15:02:25

(ns klipse-test.a
  #?(:cljs (:require-macros [klipse-test.a])))

(defmacro x [sym]
  `(def ~sym 10))

viebel15:02:58

(ns klipse-test.b
  (:require [klipse-test.a :refer [x]]))

(x asdf)

viebel15:02:09

In lumo, it works fine

viebel15:02:23

(x asdf) calls the macro from klipse_test.a$macros

viebel15:02:01

but in klipse: (x asdf) calls the macro from klipse_test.a

viebel15:02:57

goog.provide("klipse_test.b");
klipse_test.a.x.call(null,klipse_test.b.asdf);

viebel15:02:17

while in lumo:

goog.provide("klipse_test.b");
(function (){
klipse_test.b.asdf = (10);

viebel15:02:31

Is that enough information @anmonteiro ?

viebel15:02:04

for some reason, klipse doesn’t understand that x is a macro!

moxaj15:02:21

@viebel I still strongly suspect that klipse, somehow, is using an outdated cljs. Could you double double check it? ^^

anmonteiro15:02:35

Right. Can't say I know what's going wrong

moxaj15:02:58

@viebel maybe you've cached some stuff and you should flush those

anmonteiro15:02:09

klipse is using 1.9.456

anmonteiro15:02:19

Just evaluate *clojurescript-version*

viebel16:02:31

This is really weird - because if klipse was for some reason an old cljs version (cached somewhere!!??!) then there would be an infinite loop of loading the macro namespace

viebel16:02:38

And it’s not the case!!!

moxaj16:02:43

not necessarily, this is very similar to what i've seen with lumo 1.0 (which used an earlier cljs)

moxaj16:02:55

(I mean the infinite loop)

moxaj16:02:01

it loaded the "macro" with the hidden args instead of the real macro

viebel16:02:09

what version of cljs was used by lumo 1.0?

viebel16:02:39

@anmonteiro implicit macro loading is a feature of 1.9.293 or 1.9.456?

moxaj16:02:30

I believe it's an earlier feature which was fixed for self-hosted in 1.9.293, see https://groups.google.com/forum/#!topic/clojurescript/96RnUYnhq8E

viebel16:02:30

So why it doesn’t work in lumo 1.0 ?

anmonteiro16:02:43

You're talking about 2 different thigs

anmonteiro16:02:04

Implicit macro loading has been around before 1.9.293

anmonteiro16:02:35

What 1.9.293 brought to self-hosted was the possibility of compiling the macro loop pattern

anmonteiro16:02:45

And that should work in Lumo 1.0.0

viebel16:02:10

What’s the official name of the 2nd thing?

anmonteiro16:02:09

I don't think it has been officially baptized

viebel16:02:27

I meant to ask: what is the commit that solves it?

viebel16:02:42

:slightly_smiling_face:

viebel16:02:15

I’m talking about the “Furthermore” part of

viebel16:02:35

>Implicit macro loading: If a namespace is required or used, and that namespace itself requires or uses macros from its own namespace, then the macros will be implicitly required or used using the same specifications. *Furthermore, in this case, macro vars may be included in a :refer or :only spec*.

borkdude19:02:19

In lumo, should I use (.-argv js/process) to get the command line args?

borkdude19:02:27

Another question: I want to use cache with -K but the directory stays empty

borkdude19:02:42

I call it like this: lumo -K script.cljs /tmp/names/current