This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-29
Channels
- # beginners (42)
- # boot (12)
- # cider (3)
- # cljs-dev (277)
- # cljsrn (44)
- # clojure (127)
- # clojure-austin (9)
- # clojure-austria (1)
- # clojure-brasil (14)
- # clojure-canada (1)
- # clojure-dev (22)
- # clojure-dusseldorf (1)
- # clojure-italy (4)
- # clojure-russia (24)
- # clojure-spec (33)
- # clojure-taiwan (1)
- # clojure-uk (21)
- # clojure-ukraine (8)
- # clojurescript (134)
- # core-async (41)
- # core-logic (8)
- # cursive (1)
- # datomic (3)
- # ethereum (1)
- # events (4)
- # funcool (1)
- # leiningen (12)
- # off-topic (21)
- # om (19)
- # onyx (45)
- # overtone (1)
- # parinfer (2)
- # pedestal (3)
- # proton (2)
- # re-frame (103)
- # reagent (48)
- # test-check (27)
- # untangled (51)
- # vim (3)
Hi! I was wondering if anyone would mind if I picked up http://dev.clojure.org/jira/browse/CLJS-1195 as a first contribution? I've signed the CA, so assuming you're happy, and no one else is already looking at it - is this the right place to ask about getting the correct jira permissions to assign to myself?
@jasoncourcoux: go for it
@dnolen Thanks! Is that something I'll need permissions for - and are you the right person to ask for those?
one thing we should think about is whether we should just give up on maintaining cljs.reader
now that we have tools.reader as dep. Perhaps we should just refer to tools.reader for that functionality?
@dnolen I don't understand your comment about require
and data literal files? what do they have to do with it?
@thheller I think in CLJS we’ll have to require
the namespaces that declare a data reader unlike in Clojure because of dependency order
it’s how I interpret David’s statement
@anmonteiro not sure what you mean
@thheller my understanding about the ClojureScript compilation process is that we need to do topological sort on the dependencies
in order for dependents to see populated analysis already
@anmonteiro data literal files aren’t any different from any other ns without an ns form
if you have records in some other ns that you’re going to construct then you will require
I always thought data_readers.clj
was just unfortunately not called data_readers.edn
but if they can contain require
i guess that is a viable use
@dnolen I’m starting to look at what might be needed to do the suggested implementation, but I’m stuck on when should the sub-ns be generated
because a file might have several requires e.g.: require
, require-macros
,etc
@anmonteiro right so that was implied with that I was saying yesterday a bit
once you don’t see an ns form and you see something else you know the ns must be cljs.user.FOO
I can understand that, sure. but then we hit the case of several files might not have ns declarations
if both declare a var with the same name?
@anmonteiro right so I think you’re missing my solution 🙂
probably am
so in bar you’d just refer to x
without requiring anything?
because theoretically they’d be in the same cljs.user
ns
so this is the big idea, the illusion of a big cljs.user
ns, but in fact it’s just Closure namespaces
so in the compiler environment we cram everything into cljs.user
?
“actual location” = filesystem?
or rather, closure namespace
which might or might not map to a file
depending on optimization settings
ah right
so that clears some things up but I still have my initial question
what if the user declares x
in foo and bar?
that’ll probably generate a compiler warning
right, now I get what I was missing
if a user has 2 files without namespace, they are assumed to be cljs.user
so it’s basically a user concern not to have duplicated names in there
yeah, but I somehow was missing that 🙂
there are probably some small corners to think through with respect to REPLs but it seems OK if we have the resolution stuff worked out internally
definitely not a straightforward task, but looks very interesting
@dnolen - sorry got dragged away for a bit - was the tools.reader comment earlier a hint in regards to the processing of command line arguments for Jira 1195? i.e. are you suggesting that the arguments would be passed as a string of clojure data which gets parsed by the reader, and therefore the implementation should look at making use of tools.reader, rather than say either some custom code/lib/java platform to parse standard unix style arguments? Or have I completely missed the point, and your comment was unrelated to this particular issue!
@jasoncourcoux no, unrelated, just a enhancement thought
Haha - okay, thought that was probably the case
@jasoncourcoux I bumped your permissions
Thanks
I'll probably have several questions - just kind of throwing myself in as thought that's the best way to learn
@dnolen by “stop maintaining cljs.reader” do you want to convey we should just delete the namespace in a future release?
@anmonteiro no, just defer to tools.reader for the api
ah makes sense
yep, got it
I’m definitely in favor of that
I got bitten by cljs.reader
before and ended up using tools.reader anyway
@dnolen If I’m thinking correctly about the problem, require
etc support in the analyzer will allow us to delete a good portion of the REPL special functions code, no?
@anmonteiro that would be ideal yes
it’s what I’m starting to realize, at least 🙂
@dnolen am I correct in assuming that we should emit vars as cljs.user.foo = 42
or should it be cljs.user$$gen_ns$$etc
?
@anmonteiro hrm … I hadn’t really thought about the fact that we can change vars from any ns - Closure probably won’t care
so maybe we don’t need the generated name for anything other than to make goog.require
work?
@dnolen I think that’s what I have currently
but there’s 1 problem
goog.provide('cljs.user$$gen_ns$$_asd1084541096');
goog.require('cljs.core');
goog.require('clojure.set');
cljs.user.x = clojure.set.union.call(null,new cljs.core.PersistentHashSet(null, new cljs.core.PersistentArrayMap(null, 1, [(1),null], null), null),new cljs.core.PersistentHashSet(null, new cljs.core.PersistentArrayMap(null, 1, [(3),null], null), null));
this works no problem
and in the REPL I can see (ns-interns ‘cljs.user
=> {x ‘cljs.user}
but whenever I evaluate x
it returns nil
¯\(ツ)/¯
@dnolen I feel I’m missing something simple
but can't pinpoint exactly what
in the REPL?
cljs.user=> js/cljs.user.x
nil
cljs.user=> (fn [] x)
#object[ret__5155__auto__ "function (){
return cljs.user.x;
}"]
@anmonteiro what about js/cljs.user
?
empty object
right
that makes sense
probably because I never goog.require
it anywhere 🙂
so where should I do it?
@anmonteiro I need more context
I’m compiling a src
dir which has a file without NS
running the node REPL and expecting x
to return what I defined
what do you mean?
I’m assuming I have wrong expectations
it does
cljs.user=> (load-file "out/cljs/user$$gen_ns$$_asd1084541096.cljs")
WARNING: x at line 3 is being replaced at line 3 out/cljs/user$$gen_ns$$_asd1084541096.cljs
nil
cljs.user=> x
#{1 3}
#{1 3}
is what I expected to see, great
so now shouldn’t these files be required automatically ?
@dnolen I expected that I could see the definition of x
when I entered the REPL
because it’s supposed to be transparent that it’s the cljs.user
namespace
@anmonteiro no you need to load explicitly
OK wait, does this mean it’s working?
so no need for a custom resolver at all 😛
since we can side-effect the cljs.user
Closure NS
what about the undeclared var warning when loading the file?
or rather, replace
@dnolen should I be seeing this upon entering the REPL?
cljs.user=> (ns-interns 'cljs.user)
{x #'cljs.user/x}
without loading the file
maybe that’s what’s up
well the problem is that the analyzer side-effects the compiler env upon analyzing the file
so x
is in there in the NS’s :defs
still happening
(also this means we don’t need to warn about replacing stuff in cljs.user
already done)
cljs.user=> (load-file "src/asd.cljs")
WARNING: x at line 3 is being replaced at line 3 src/asd.cljs
nil
well you haven’t seen my implementation so I’m most definitely messing something up
@dnolen https://github.com/anmonteiro/clojurescript/commit/c8f402b7af4cf4cf7625cb6417b45eba7d22036a
@anmonteiro the problem is parse-ns
makes total sense
now that you say it 🙂
thanks
@anmonteiro btw for the hash part what we really want is the first few characters of the content-sha of the URI of the file, there’s an example of this in closure.clj (just pointing this out when you have time to get to it)
@dnolen yeah it’s all very WIP still, but I didn’t know that. I’ll do that, thanks
should be this, right?
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1507
@anmonteiro so it looks like this will just be very simple and remove my REPL hacks 😛
@dnolen yes, completely unexpected 🙂
probably still missing the part about :toplevel
checks
yeah… I just wanted to prototype something quickly
and it kinda worked, I’m amazed
@dnolen removing the REPL hacks will probably need to be a different ticket
great
when are you thinking about cutting a CLJS release?
your self-require self-host thing, and Closure bump are high priority for the next release
ah right
well I have a little time to work on this in the next few days, so I should have something ready
agreed
there was a little churn with :rename
& spec stuff
but 1.9.229 seems stable enough
Chelimsky has a successful fix in the works (in transit-java
) that would fix http://dev.clojure.org/jira/browse/CLJS-1761 in the future
ad the async repl bootstrap conversation from #clojurescript channel, this is my proposal (not tested yet): https://github.com/darwin/clojurescript/commit/b7bc7377ca6ea2671629d561df741e0436fc03c9 ^ @bendlas @dnolen - comments welcome, I will craft a JIRA ticket with a proper patch if this looked good to you have to run now
@darwin that patch is a bit too complicated for me - first need to understand what you are trying to accomplish
@dnolen hrm still getting the var replaced warning after fixing parse-ns
so we need to form a hypothesis, what would analyze that code to side effect the environment such that this would happen?
@dnolen I think emit*
would
in cljs.compiler
wait maybe I got the wrong func
oh no, it does, actually
here in my diff^
or maybe I made it analyze everything, let me check
oh it’s not emit*
, I mean emit-source
always have trouble when the diff is not fully expanded
@anmonteiro so that logic in emit :ns
just seems wrong to me
@dnolen it’s emit-source
the diff is misleading when not expanded
@dnolen sorry I might have been running a stale version of the compiler
definitely human error
parse-ns
was definitely the culprit
@anmonteiro ok, yeah it seemed improbable
I tried to follow the instructions at [Building the compiler](https://github.com/clojure/clojurescript/wiki/Building-the-compiler) for windows, and I am getting the following error
Exception in thread "main" java.io.FileNotFoundException: Could not locate cljs/closure__init.class or cljs/closure.clj on classpath., compiling:(C:\Users\tkidd\github\clojurescript\script\aot.clj:1:1)
I looked at the script and see that ./script_aot is trying to run a 'java -server' command
:src/main/clojure:src/main/cljs is at the end of the classpath, so it should be able to find cljs/closure.clj, but it doesn't
I know this is probably specific to my setup, I am using Git Bash to try to do it, but just figured I'd ask in case anyone knew
@tomjkidd might as well be a windows-specific thing. AFAIK there aren’t many people hacking on the compiler using Windows
can you build it in OSX?
FWIW current master builds correctly, I’ve been doing it today 🙂
@tomjkidd also if you find out it’s a windows-specific thing, I think I remember @dnolen saying he would take Windows patches easily!
@anmonteiro works fine on my mac, like you expected.
@tomjkidd so bad news is you have to figure out what’s stopping it from working on Windows
I don’t have a windows machine at hand to help you, sorry
No worries. I'll keep plugging at it, won't spend too much more time if it's not going anywhere.
@tomjkidd well actually, don’t the paths in windows have different slashes or something?
might as well be the classpath that’s being printed out wrong
e.g. src/main/clojure/
when it should be src\main\clojure
@tomjkidd the issue is simple as @anmonteiro notes, that script isn’t cross platform
note that we have a couple of powershell scripts for Windows there, but not one for build
yeah, I was hoping that using Git Bash (which uses MINGW64) I could pull it off. It got pretty far, I've been pushing it along as I encounter new failures
@tomjkidd that would probably almost work, but I suspect it falls down when giving the classpath to Java
Adjusting the classpath to be in the form /c/Users/tkidd... instead of C:\Users\tkidd does get the 'java server' command to run without failing
I was able to use a clojure repl to transform the command, and that's definitely it.
I noticed the maven plugin dependency:build-classpath
is used to create this, and it has some options, but I don't changing it's pathSeparator
or fileSeparator
will do the right thing here
Changing line 7 to mvn -f pom.template.xml dependency:build-classpath -Dmdep.outputFile=$CP_FILE -Dmdep.prefix='' -Dmdep.fileSeparator='//'
and line 15 to java -server -cp "$CLJS_CP;src/main/clojure;src/main/cljs" clojure.main script/aot.clj