Clojurians
#cljs-dev
<
2016-07-27
>

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

anmonteiro13:07:45

@dnolen: got a patch almost ready for http://dev.clojure.org/jira/browse/CLJS-1700 and only now realized it was assigned to you. should I go ahead and provide the patch anyway?

dnolen14:07:09

@anmonteiro: go for it!

anmonteiro15:07:59

@dnolen: thanks, just attached the patch. pinging you here since I can’t double assign you :wink:

dnolen16:07:04

@anmonteiro cool thanks

juhoteperi22:07:24

I'm just testing namespace aliases with latest commit and noticed this ns doesn't work anymore:

(ns metosin.core.async.debounce
  #?(:cljs (:require-macros [cljs.core.async.macros :as a]))
  (:require #?(:cljs [cljs.core.async :as a]
               :clj [clojure.core.async :as a])))
It is giving error about missing a/go-loop

juhoteperi22:07:55

Is this is a known issue? Is it an issue, is using same alias for macros and regular requires valid? Should I create an issue?

dnolen22:07:35

@juhoteperi: first make it minimal to determine what’s actually going on

dnolen22:07:43

no reader conditionals please, no external tooling either

dnolen22:07:06

@juhoteperi: using the same alias for a macro ns and a runtime ns (when they are differently named), I’m pretty sure if that ever worked it was not intentional

dnolen22:07:17

so I would probably not consider that a real regression

dnolen22:07:51

still if there’s a simple way to recover that ok, if it clashes with the new enhancements - not going to support it

juhoteperi22:07:09

Hmm, okay. I'll create report with minimal code anyway to be sure

anmonteiro22:07:41

@juhoteperi: FWIW it’s also breaking for me with current master, and working fine in 1.9.89

juhoteperi22:07:06

But first I'll try to find a better way to write that which works

anmonteiro22:07:11

this is what I used:

(ns foo.core
  (:require-macros [cljs.core.async.macros :as a])
  (:require [cljs.core.async :as a]))

(let [c (a/chan)]
  (a/go-loop [foo (a/<! c)]))

dnolen22:07:17

sure but I don’t recall anything ever saying that would work

dnolen22:07:24

nor why people believed it should

dnolen22:07:29

I never did that myself since I never knew it worked

anmonteiro22:07:54

I also didn’t know this would work, also why I tried it just now by curiosity

juhoteperi22:07:03

I don't remember if I saw if somewhere or how I found it - but I have found it the easiest way to write cljc code using core.async

dnolen22:07:07

right so this is not a real problem as far as I am concerned

dnolen22:07:22

but if there’s a simple patch to recover the old behavior, this is what I’m OK with

dnolen22:07:46

but I would still consider this super low priority and completely unintended and undefined

anmonteiro23:07:03

@juhoteperi: I attached a patch to JIRA, can you confirm it fixes your issue? http://dev.clojure.org/jira/browse/CLJS-1716