Thanks :)
On Tuesday, March 17, 2015 at 12:41:56 PM UTC+1, David Nolen wrote:
>
> Yes I said earlier that you'll want SNAPSHOT releases of both weasel and
> piggieback. The current release of piggieback doesn't include this commit
> https://github.com/cemerick/piggieback/commit/966c811ab817df0e8
We bumped the Closure Compiler dependency which now spews a few innocuous
warnings. Feel free to report this one to the Google Closure mailing list.
I've already reported the Object type one we get now when using browser
REPL.
David
On Tue, Mar 17, 2015 at 5:46 AM, Max Gonzih wrote:
> After upd
Yes I said earlier that you'll want SNAPSHOT releases of both weasel and
piggieback. The current release of piggieback doesn't include this commit
https://github.com/cemerick/piggieback/commit/966c811ab817df0e818404943c473081337b286e
In the case of weasel you might want to try a local install of m
> If that is true, then it is a problem, indicative either of a widespread
> lack of discipline among the tool makers or (more likely) a strong need for
> some additional well-specified (and maintained!) APIs in the compiler for
> tools to hook into.
>
Sometimes it is just a simple bug or la
Both piggieback and weasel unfortunately tapped into undiscussed details.
piggieback's design is fundamentally flawed (being constructed on flawed
implementation details of the standard REPL infrastructure which have since
changed) and I would personally be happy to see piggieback eventually
disapp
If it helps: I am getting a similar error ( goog.require could not find:
cljsjs.react when trying to compile a namespace via weasel-5.0.0 and
piggieback...
On Monday, March 16, 2015 at 7:47:12 PM UTC+1, Fluid Dynamics wrote:
>
>
>
> On Monday, March 16, 2015 at 1:06:31 PM UTC-4, David Nolen wr
On Mon, Mar 16, 2015 at 2:47 PM, Fluid Dynamics wrote:
> If that is true, then it is a problem, indicative either of a widespread
> lack of discipline among the tool makers or (more likely) a strong need for
> some additional well-specified (and maintained!) APIs in the compiler for
> tools to ho
On Monday, March 16, 2015 at 1:06:31 PM UTC-4, David Nolen wrote:
>
> On Mon, Mar 16, 2015 at 1:01 PM, Fluid Dynamics > wrote:
>
>> On Monday, March 16, 2015 at 11:23:14 AM UTC-4, David Nolen wrote:
>>>
>>> Need more information. But that warning is most certainly not something
>>> emitted by t
It appears there was a regression in ClojureScript :foreign-libs support
and Closure optimization passes. Just cut 0.0-3119 to address this.
Jonathan, this may fix your issue but it's unclear as the regression was
around release builds and your error about cljsjs.react seems like it
originated fro
It's up the maintainers down the food chain to keep up with changes and yes
there are
timing issues, not all changes/fixes can be applied synchronously.
That's the idea of having libraries instead of a monolithic soup of code.
Applying your statement to technology in general we would still be us
On Mon, Mar 16, 2015 at 1:01 PM, Fluid Dynamics wrote:
> On Monday, March 16, 2015 at 11:23:14 AM UTC-4, David Nolen wrote:
>>
>> Need more information. But that warning is most certainly not something
>> emitted by the ClojureScript compiler.
>>
>> Make sure you can reproduce without whatever do
On Monday, March 16, 2015 at 11:23:14 AM UTC-4, David Nolen wrote:
>
> Need more information. But that warning is most certainly not something
> emitted by the ClojureScript compiler.
>
> Make sure you can reproduce without whatever downstream tooling you may be
> using: https://github.com/clojur
Need more information. But that warning is most certainly not something
emitted by the ClojureScript compiler.
Make sure you can reproduce without whatever downstream tooling you may be
using: https://github.com/clojure/clojurescript/wiki/Reporting-Issues
There's a good chance it's purely downstr
13 matches
Mail list logo
