Re: Possible bug in AOT-compiled Clojure when ns-unmap is used

[Nicola Mometto]

While it's true that AOT has many issues, it's getting better release after 
release and this is definitely a bug. 
I don't understand why you wouldn't expect this to work, you *should*.

OP: can you open a ticket for this bug? I'd love to have a look at this and try 
to fix it.

> On 29 Dec 2015, at 17:28, Stuart Sierra  wrote:
> 
> AOT-compilation breaks almost any code that tries to redefine Vars. I 
> wouldn't expect this to work.
> —S
> 
> 
> On Monday, December 28, 2015, wparker30 wrote:
> I have found what appears to be a bug in AOT-compiled Clojure when ns-unmap 
> is used.  I have the following reduced case:
> 
> (ns unmap-test.core)
> 
> (def a :test-1)
> 
> (ns-unmap 'unmap-test.core 'a)
> 
> (def a :test-2)
> 
> It turns out that a is not resolvable when this namespace is loaded.  When I 
> looked at the compiled bytecode,
> it appears that the following operations occur:
> 
> 1. A call to RT.var withe 'unmap-test.core and 'a returns a Var, which is 
> bound to a constant.
>   This var is added to the namespaces's mapping during this call.
> 2. Same as 1.
> 3. The var from 1 is bound to :test-1.
> 4. ns-unmap is called.
> 5. The var from 2 is bound to :test-2.
> 
> Disclaimer: This is the first time I have had occasion to look directly at 
> bytecode and I could be missing something.
> 
> The basic problem here is that the var is accessible from the load method, 
> but when step 5 executes the var is no longer
> accessible from the namespace mappings.  Thus, the root of the Var is set to 
> :test-2, but that Var is not mapped from the namespace.
> This works when there is no AOT compilation, as well as when I use 
> 
> (ns unmap-test.core)
> 
> (def a :test-1)
> 
> (ns-unmap 'unmap-test.core 'a)
> 
> (intern 'unmap-test.core 'a :test-2)
> 
> I realize that creating defs, unmapping them, and then recreating them is 
> generally poor practice in Clojure.
> We have an odd case in that we need to have an interface and a Var of the 
> same name in the same namespace.  Simply
> doing definterface and then def causes a compilation failure:
> 
> user=> (definterface abc)
> user.abc
> user=> (def abc 1)
> CompilerException java.lang.RuntimeException: Expecting var, but abc is 
> mapped to interface user.abc, 
> compiling:(/private/var/folders/3m/tvc28b5d7p50v5_8q5ntj0pmflbdh9/T/form-init4734176956271823921.clj:1:1)
>  
> 
> Without going into too much detail, this is basically a hack to allow us to 
> refactor our internal framework code
> without immediately changing a very large amount of downstream consumer code. 
>  We get rid of the usage of the interface during macroexpansion,
> but it still needs to exist on the classpath so it can be imported by 
> downstream namespaces.  
> There are a number of other ways to accomplish this, so it isn't a 
> particularly big problem for us, but I thought the issue was worth raising.
> This was just the first thing I tried and I was surprised when it didn't work.
> 
> Note that I used the 1.8.0 RC4 version of Clojure in my sample project, but I 
> had the same behavior on 1.7.0.
> 
> Relevant links:
> 
> 1. Bytecode for the load method of the init class: 
> https://gist.github.com/WilliamParker/d8ef4c0555a30135f35a
> 2. Bytecode for the init0 method: 
> https://gist.github.com/WilliamParker/dc606ad086670915efd9
> 3. Decompiled Java code for the init class.  Note that this does not 
> completely line up with the bytecode as far as I can tell,
> but it is a quicker way to get a general idea of what is happening than the 
> bytecode.
> https://gist.github.com/WilliamParker/4cc47939f613d4595d94
> 4. A simple project containing the code above: 
> https://github.com/WilliamParker/unmap-test
> Note that if you try it without AOT compilation the target folder with any 
> previously compiled classes should be removed.
> 
> I may or may not be able to respond to any replies before next week; I 
> apologize for any delayed responses.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to

Re: Project structure when using reader conditionals

[Dru Sellers]

I was also playing around with a few different models. I was looking at
something like client and server but probably over thinking it from my
static type days:


These would just have needed bootstrapping code

src/apps/app1 - client app
src/apps/app2 - client app
src/apps/app3 - server app

src/features//bar.cljc
src/features//bar.cljc

etc

-d

On Wed, Dec 30, 2015 at 7:53 AM, James Reeves  wrote:

> My directory structure looks like:
>
> src/foo/client/bar.cljs
> src/foo/common/bar.cljc
> src/foo/server/bar.clj
>
> So I divide code by purpose, but they're all in the same source directory.
>
> - James
>
> On 30 December 2015 at 00:56, Alan Moore 
> wrote:
>
>> Yes it would be handy for small projects but IMO larger applications
>> should be broken up into client and server code. Some might argue for
>> breaking up client and server into separate projects altogether but that
>> begs the question about what to do with the .cljc files that are shared
>> (e.g. put them in shared library(ies)?) Again, this probably depends on
>> codebase size, granularity of your deployment and other considerations
>> beyond just the compiler.
>>
>> For now I'm sticking with keeping the .cljc files in the src/clj tree.
>> I'd like to hear what others are doing as well.
>>
>> Did you ask this on the clojurians slack channel? It seems a lot of the
>> more chatty/Q traffic for this list has gone over there.
>>
>> Alan
>>
>>
>> On Friday, December 25, 2015 at 1:00:58 PM UTC-8, Dru Sellers wrote:
>>>
>>> Is it fair to say that the accepted pattern now (with reader
>>> conditionals) is to have a single src/ directory and then letting the file
>>> extension (cljs,clj,cljc) do the heavy lifting rather than having a
>>> directory for each?
>>>
>>> that would be handy if so.
>>>
>>> -d
>>>
>>>
>>> On Friday, May 29, 2015 at 3:10:30 PM UTC-5, Daniel Compton wrote:

 When porting a library to reader conditionals, I found that I only
 needed one source directory for all my cljc and .clj files. Cljsbuild just
 picks up the ones it needs and leaves the .clj ones.

 So in some cases it may not be necessary to have a clj/, cljs/, and
 cljc/ folder, although in applications this structure might make more
 sense.
 On Fri, 29 May 2015 at 10:31 pm Robin Heggelund Hansen <
 skinn...@gmail.com> wrote:

> No, it doesn't. I update with `lein ancient update :all` and committed
> without checking if it worked. It's fixed locally :)
>
>
> fredag 29. mai 2015 12.01.32 UTC+2 skrev Colin Yates følgende:
>
>> Thanks Robin, that was helpful. I notice that you are using garden
>> 1.2.6 - that throws a CNF for garden.core and the garden page recommends
>> not using it - does it work for you?
>>
> On 29 May 2015, at 10:49, Robin Heggelund Hansen 
>> wrote:
>>
>> Take a look at my project.clj file.
>>
>>
>> https://github.com/Skinney/oslo-programmene/blob/development/project.clj
>>
>> fredag 29. mai 2015 11.17.25 UTC+2 skrev Colin Yates følgende:
>>>
>>> In the vein of "there are no stupid questions" :), how does one
>>> structure a combined clj and cljs project that uses reader 
>>> conditionals? At
>>> the moment I am using cljx and have:
>>>  - src/clj for clojure files
>>>  - src/cljs for clojurescript files
>>>  - src/cljx for cljx
>>>  - target/cljx/clj for clojure files compiled (transpiled?) from cljx
>>>  - target/cljx/cljs for clojurescript files compiled (transpiled?)
>>> from clix
>>>
>>> On the source path in cljsbuild for example I have src/cljs and
>>> /target/cljx/cljs
>>>
>>> To remove cljx and use reader conditionals is it sufficient to:
>>>  - replace src/cljx with src/cljc
>>>  - remove target/cljx from cljsbuild source path
>>>  - add src/cljc to cljsbuild source path
>>>  - add src/cljc to leiningen source path
>>>
>>> Thanks!
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>>
>> To post to this group, send email to clo...@googlegroups.com
>>
>>
>> Note that posts from new members are moderated - please be patient
>> with your first post.
>> To unsubscribe from this group, send email to
>>
>> clojure+u...@googlegroups.com
>>
>>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>>
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to clojure+u...@googlegroups.com.
>>
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
> You received this message because you are subscribed to the 

Re: Can I use Clojure to build a mobile chat application?

[Geraldo Lopes de Souza]

https://github.com/tonsky/datascript-chat

On Tuesday, December 29, 2015 at 10:14:50 AM UTC-2, симон wrote:
>
> My project is to use build a simple chat client and I thinking of using 
> clojure since it is the language am currently learning. And am liking it.
>
>
> I don't know weather this is possible and what the 
> possibilities/challenges are.
>
>
> I need advice or suggestions on what projects else I can do with clojure 
> as I just started learning it now and would need some more experience to 
> decide.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Project structure when using reader conditionals

[James Reeves]

My directory structure looks like:

src/foo/client/bar.cljs
src/foo/common/bar.cljc
src/foo/server/bar.clj

So I divide code by purpose, but they're all in the same source directory.

- James

On 30 December 2015 at 00:56, Alan Moore  wrote:

> Yes it would be handy for small projects but IMO larger applications
> should be broken up into client and server code. Some might argue for
> breaking up client and server into separate projects altogether but that
> begs the question about what to do with the .cljc files that are shared
> (e.g. put them in shared library(ies)?) Again, this probably depends on
> codebase size, granularity of your deployment and other considerations
> beyond just the compiler.
>
> For now I'm sticking with keeping the .cljc files in the src/clj tree. I'd
> like to hear what others are doing as well.
>
> Did you ask this on the clojurians slack channel? It seems a lot of the
> more chatty/Q traffic for this list has gone over there.
>
> Alan
>
>
> On Friday, December 25, 2015 at 1:00:58 PM UTC-8, Dru Sellers wrote:
>>
>> Is it fair to say that the accepted pattern now (with reader
>> conditionals) is to have a single src/ directory and then letting the file
>> extension (cljs,clj,cljc) do the heavy lifting rather than having a
>> directory for each?
>>
>> that would be handy if so.
>>
>> -d
>>
>>
>> On Friday, May 29, 2015 at 3:10:30 PM UTC-5, Daniel Compton wrote:
>>>
>>> When porting a library to reader conditionals, I found that I only
>>> needed one source directory for all my cljc and .clj files. Cljsbuild just
>>> picks up the ones it needs and leaves the .clj ones.
>>>
>>> So in some cases it may not be necessary to have a clj/, cljs/, and
>>> cljc/ folder, although in applications this structure might make more
>>> sense.
>>> On Fri, 29 May 2015 at 10:31 pm Robin Heggelund Hansen <
>>> skinn...@gmail.com> wrote:
>>>
 No, it doesn't. I update with `lein ancient update :all` and committed
 without checking if it worked. It's fixed locally :)


 fredag 29. mai 2015 12.01.32 UTC+2 skrev Colin Yates følgende:

> Thanks Robin, that was helpful. I notice that you are using garden
> 1.2.6 - that throws a CNF for garden.core and the garden page recommends
> not using it - does it work for you?
>
 On 29 May 2015, at 10:49, Robin Heggelund Hansen 
> wrote:
>
> Take a look at my project.clj file.
>
>
> https://github.com/Skinney/oslo-programmene/blob/development/project.clj
>
> fredag 29. mai 2015 11.17.25 UTC+2 skrev Colin Yates følgende:
>>
>> In the vein of "there are no stupid questions" :), how does one
>> structure a combined clj and cljs project that uses reader conditionals? 
>> At
>> the moment I am using cljx and have:
>>  - src/clj for clojure files
>>  - src/cljs for clojurescript files
>>  - src/cljx for cljx
>>  - target/cljx/clj for clojure files compiled (transpiled?) from cljx
>>  - target/cljx/cljs for clojurescript files compiled (transpiled?)
>> from clix
>>
>> On the source path in cljsbuild for example I have src/cljs and
>> /target/cljx/cljs
>>
>> To remove cljx and use reader conditionals is it sufficient to:
>>  - replace src/cljx with src/cljc
>>  - remove target/cljx from cljsbuild source path
>>  - add src/cljc to cljsbuild source path
>>  - add src/cljc to leiningen source path
>>
>> Thanks!
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
>
> To post to this group, send email to clo...@googlegroups.com
>
>
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
>
> clojure+u...@googlegroups.com
>
>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
>
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it,