[CfPart] 17th European Lisp Symposium -- May 6-7, Vienna, Austria

[Didier Verna]

~~
 17th European Lisp Symposium

Call for Participation

 May 6-7 2024
  Sky Lounge, University of Vienna, Austria
  and online

 https://www.european-lisp-symposium.org/2024
~~


Invited Speakers
~~~
* Bias is a bug; but not as we know it!
  Julian Padget -- University of Bath

* Is the Hype Cycle Real?
  Stavros Macrakis -- Amazon OpenSearch

* The Need for Symbolic AI Programming Languages in the Public Sector
  Markus Triska -- Austrian Federal Ministry of Finances


Scope
~

The European Lisp Symposium is a premier forum for the discussion and
dissemination of all aspects of design, implementation, and application
of any of the Lisp dialects, including Common Lisp, Scheme, Emacs
Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen,
Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on.  We encourage
everyone interested in Lisp to participate.

The European Lisp Symposium features high quality papers about novel
research results, insights and lessons learned from practical
applications, educational perspectives, demonstrations, and tutorials.

Topics include but are not limited to:

- context-, aspect-, domain-oriented and generative programming
- macro-, reflective-, meta- and/or rule-based development approaches
- language design and implementation
- language integration, inter-operation, and deployment
- development methodologies, support, and environments
- educational approaches and perspectives
- experience reports and case studies


Programme Chair
~~~
Giuseppe Attardi, University of Pisa, Italy


Organizing Chair

Didier Verna, EPITA, France


Programme Committee
~~~
Ambrose Bonnaire-Sergeant, Untypable LLC
Frederic Peschanski, UPMC/LIP6
Jay McCarthy, UMass Lowell
Jim Newton, EPITA Research Lab
Kai Selgrad, OTH Regensburg
Mark Evenson, not.org
Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux
Robert Smith, HRL Laboratories LLC
Robert P. Goldman, SIFT LLC
Stefan Monnier, Université de Montréal


Local Chair
~~~
Philipp Marek, BRZ, Vienna, Austria


Virtualization Team
~~~
Georgiy Tugai, Configura, Sweden
Michał Herda, Poland
Yukari Hafner, Shirakumo.org, Switzerland

-- 
Resistance is futile. You will be jazzimilated.

Didier Verna 
ELS Steering Committee

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/m15xwik8s6.fsf%40elsaa.org.

[Last CfP] 17th European Lisp Symposium, May 6-7 2024, Vienna

[Didier Verna]

~~
 17th European Lisp Symposium

   Call for Papers

 May 6-7 2024
  Federal Computing Center, Vienna, Austria

 https://www.european-lisp-symposium.org/2024

~~


Important Dates
~~~
- Submission deadline: Feb. 25 2024 ** EXTENDED **
- Author notification: Mar. 24 2024
- Final papers due:Apr. 14 2024
- Symposium:   May 6-7 2024


Scope
~

The European Lisp Symposium is a premier forum for the discussion and
dissemination of all aspects of design, implementation, and application
of any of the Lisp dialects, including Common Lisp, Scheme, Emacs
Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen,
Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on.  We encourage
everyone interested in Lisp to participate.

The European Lisp Symposium invites high quality papers about novel
research results, insights and lessons learned from practical
applications, and educational perspectives.  We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

Topics include but are not limited to:

- context-, aspect-, domain-oriented and generative programming
- macro-, reflective-, meta- and/or rule-based development approaches
- language design and implementation
- language integration, inter-operation, and deployment
- development methodologies, support, and environments
- educational approaches and perspectives
- experience reports and case studies

This year, we suggest an emphasis on best practices, approaches,
and technologies for building highly recursive and self-adapting
architectures, in particular for AI, ML, tool integration and
instruction generation, using dynamic programming languages.


Technical Program
~
We invite submissions in the following forms.

* Papers: technical papers of up to 8 pages that describe original
  results or explain known ideas in new and elegant ways.

* Experience reports: papers of up to 6 pages describing a successful
  use of a Lisp dialect and/or analyzing obstacles that have kept it
  from working in practice.

* Tutorials: abstracts of up to 4 pages for in-depth presentations
  about topics of special interest.

* Demonstrations: abstracts of up to 4 pages for demonstrations of
  tools, libraries, and applications.

All submissions should be formatted following the ACM SIGS guidelines
and include ACM Computing Classification System 2012 concepts and
terms.  Submissions should be uploaded to Easy Chair, at the following
link http://www.easychair.org/conferences/?conf=els2024.

Note: to help us with the review process please indicate the type of
submission by entering either "paper", "demo", or "tutorial" in the
Keywords field.


Programme Chair
~~~
Giuseppe Attardi, University of Pisa, Italy


Organizing Chair

Didier Verna, EPITA, France


Programme Committee
~~~
Ambrose Bonnaire-Sergeant, Untypable LLC
Frederic Peschanski, UPMC/LIP6
Jay McCarthy, UMass Lowell
Jim Newton, EPITA Research Lab
Kai Selgrad, OTH Regensburg
Mark Evenson, not.org
Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux
Robert Smith, HRL Laboratories LLC
Robert P. Goldman, SIFT LLC
Stefan Monnier, Université de Montréal


Local Chair
~~~
Philipp Marek, BRZ, Vienna, Austria


Virtualization Team
~~~
Georgiy Tugai, Configura, Sweden
Michal Herda, Poland
Yukari Hafner, Shirakumo.org, Switzerland

-- 
Resistance is futile. You will be jazzimilated.

Didier Verna 
ELS Steering Committee

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/m21q9a9mb1.fsf%40pc-84.home.

[CfP] 17th European Lisp Symposium, May 6-7 2024, Vienna, Austria

[Didier Verna]

~~
 17th European Lisp Symposium

   Call for Papers

 May 6-7 2024
  Federal Computing Center, Vienna, Austria

 https://www.european-lisp-symposium.org/2024

  Sponsored by EPITA
~~


Important Dates
~~~
- Submission deadline: Feb.  2 2024
- Author notification: Mar. 24 2024
- Final papers due:Apr. 14 2024
- Symposium:   May 6-7 2024


Scope
~

The European Lisp Symposium is a premier forum for the discussion and
dissemination of all aspects of design, implementation, and application
of any of the Lisp dialects, including Common Lisp, Scheme, Emacs
Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen,
Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on.  We encourage
everyone interested in Lisp to participate.

The European Lisp Symposium invites high quality papers about novel
research results, insights and lessons learned from practical
applications, and educational perspectives.  We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

Topics include but are not limited to:

- context-, aspect-, domain-oriented and generative programming
- macro-, reflective-, meta- and/or rule-based development approaches
- language design and implementation
- language integration, inter-operation, and deployment
- development methodologies, support, and environments
- educational approaches and perspectives
- experience reports and case studies

This year, we suggest an emphasis on best practices, approaches,
and technologies for building highly recursive and self-adapting
architectures, in particular for AI, ML, tool integration and
instruction generation, using dynamic programming languages.


Technical Program
~
We invite submissions in the following forms.

* Papers: technical papers of up to 8 pages that describe original
  results or explain known ideas in new and elegant ways.

* Experience reports: papers of up to 6 pages describing a successful
  use of a Lisp dialect and/or analyzing obstacles that have kept it
  from working in practice.

* Tutorials: abstracts of up to 4 pages for in-depth presentations
  about topics of special interest.

* Demonstrations: abstracts of up to 4 pages for demonstrations of
  tools, libraries, and applications.

All submissions should be formatted following the ACM SIGS guidelines
and include ACM Computing Classification System 2012 concepts and
terms.  Submissions should be uploaded to Easy Chair, at the following
link http://www.easychair.org/conferences/?conf=els2024.

Note: to help us with the review process please indicate the type of
submission by entering either "paper", "demo", or "tutorial" in the
Keywords field.


Programme Chair
~~~
Giuseppe Attardi, University of Pisa, Italy


Local Chair
~~~
Philipp Marek, BRZ, Vienna, Austria


Virtualization Team
~~~
Georgiy Tugai, Configura, Sweden
Michał Herda, Poland
Yukari Hafner, Shirakumo.org, Switzerland

-- 
Resistance is futile. You will be jazzimilated.

Didier Verna 
ELS Steering Committee

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/m2fs0nxoia.fsf%40elsaa.org.

Re: [ANN] Discontinuing 4clojure.com

[Didier]

I'm guessing this also means the Android App will no longer work for it?

On Tuesday, July 6, 2021 at 12:12:21 p.m. UTC-7 Robert P. Levy wrote:

> Just wanted to correct a mistake in what I wrote above. Obviously you 
> can't clear the password hashes while retaining a link between people and 
> their accounts, so it would more accurately be stated as all accounts are 
> gone and you have to create a new account.
>
> On Tue, Jul 6, 2021 at 12:42 AM Robert Levy  wrote:
>
>> Hi Alan,
>>
>> Just as a thought.  If it's minimal work on your end (eg. if the folks 
>> from Roam research who chimed in above pick it up) why not clear the 
>> password hashes and let the new maintainer handle the communication that 
>> passwords need to be reset?
>>
>> Rob
>>
>> On Sun, Jul 4, 2021 at 1:26 PM Alan Malloy  wrote:
>>
>>> TL;DR: Turning off 4clojure.com by the end of July 2021
>>>
>>> Hello, 4clojure problem solvers. You've probably noticed SSL errors on 
>>> 4clojure.com over the last week. The old decrepit system 4clojure runs 
>>> on has finally gotten out of date enough that I can't even figure out how 
>>> to get it recent enough that SSL certs will auto-renew anymore.
>>>
>>> In principle I could start from scratch on a new server and move 
>>> 4clojure over, but I won't. 4clojure has been piggybacking along on a 
>>> server that I use for personal reasons, and over the years I have less and 
>>> less reason to keep paying for that server - it's now pretty much just 
>>> 4clojure costing me an embarrassing amount of money every month because I 
>>> haven't wanted to disappoint the community by shutting it down. This SSL 
>>> thing is just what made me finally pull the trigger.
>>>
>>> I don't have a specific EOL date in mind, but sometime near the end of 
>>> the month, since that's the billing cycle. Until that time, 4clojure still 
>>> works, as long as you don't mind clicking through the security warnings - 
>>> it really is still me hosting the site, and since the connection is still 
>>> HTTPS (albeit with an invalid cert) I think that means your data is still 
>>> safe. If you have solutions to problems you're proud of, you've still got 
>>> some time to print them out and put them up on your refrigerator.
>>>
>>> I'm not seeking new maintainers. I'd feel uncomfortable handing over a 
>>> database with so many email addresses and password hashes in it to anyone. 
>>> The service has had a good run - just over a decade since the first 
>>> release 
>>> .
>>>  
>>> I hope you enjoyed it during that time.
>>>
>>> -- 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/clojure/385cdef8-fa40-47ba-b5b1-0b3a7cc34935n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/3c3b7835-ab72-4354-8bfa-71eca12d2e0en%40googlegroups.com.

Re: HP Fortify Security Scanner and Clojure

[Didier]

Reviving an old topic here, does anyone know of a Clojure 1.10 compatible 
security analysis tool? I too thought of just decompiling the .class to 
Java. It also appears Fortify can run on bytecode only, so I might give 
that a try if I can't find anything else.

Regards

On Wednesday, 21 October 2015 15:14:31 UTC-7, Alex Miller wrote:
>
> In general, Clojure code cannot be decompiled from .class to .java as the 
> Clojure generated bytecode does things that cannot be represented in Java. 
> The particular issue below looks like the local-clearing code. It is 
> possible to turn that off during compilation, however there are likely 
> other things as well that cannot be decompiled satisfactorily.
>
> FindBugs works directly from bytecode (not source code) so might be more 
> amenable for this kind of analysis. There is a sonar plugin (
> https://github.com/zmsp/sonar-clojure) which uses Eastwood and Kibit that 
> might also be useful.
>
> FYI, Clojure is registered in CVE with id CVE-2015-4653 (although there 
> are no reports registered yet). I gather that it is useful to create at 
> least one such thing to make it searchable and I have that on my todo list 
> (although it's not a high priority). 
>
> Alex
>
>
> On Wednesday, October 21, 2015 at 3:41:21 PM UTC-5, ryan medlin wrote:
>>
>> A customer requires that we scan our clojure projects with this tool:
>>
>> http://www8.hp.com/us/en/software-solutions/static-code-analysis-sast/
>>
>>
>> They must get some meaningful report from this.
>>
>> So I thought, well why don't I compile and then decompile the class files 
>> and then scan those to at least give them something.
>>
>> However when I do that I get a TON of high security issues in multiple 
>> dependencies (ring, clojure.core)
>>
>> Here is the most prevalent:
>>
>> https://cwe.mitre.org/data/definitions/476.html
>>
>> /* */ package nio;
>> /* */ 
>> /* */ import clojure.lang.AFunction;
>> /* */ import clojure.lang.IFn;
>> /* */ import clojure.lang.RT;
>> /* */ import clojure.lang.Var;
>> /* */ import java.nio.Buffer;
>> /* */ import java.nio.ByteBuffer;
>> /* */ 
>> /* */ public final class core$fn__1869 extends AFunction
>> /* */ {
>> /* 284 */   public static final Var const__0 = 
>> (Var)RT.var("clojure.core", "make-array");
>> /* */ 
>> /* */   public Object invoke(Object x)
>> /* */   {
>> /* 297 */ x = null; Object x = ((ByteBuffer)x).duplicate();
>> /* 298 */ Object array = 
>> ((IFn)const__0.getRawRoot()).invoke(Byte.TYPE, 
>> Integer.valueOf(((Buffer)x).remaining()));
>> /* 299 */ x = null; ((ByteBuffer)x).get((byte[])array); array = null; 
>> return array;
>> /* */   }
>> /* */ }
>>
>>
>> Decompiler:
>>
>> http://jd.benow.ca/
>>
>> Id the decompiler somehow generating code with these security issues and 
>> the actual bytecode does not have them maybe?
>>
>>
>> I have no idea how to move forward with this.  We have to "check a box" 
>> for them in corporate speak yet there is no clear path to run a dependable 
>> security scan against the codebase.
>>
>>
>> Yes I realize this is silly to demand running this tool.
>>
>> Any other tools out there that might be able to scan Clojure code like 
>> this?
>>
>>
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/e8a5a6f9-3a0f-4431-80ba-2138ee0f8d75%40googlegroups.com.

[CfP] ELS 2020, 13th European Lisp Symposium, April 27-28, Zurich

[Didier Verna]

~~

 13th European Lisp Symposium
  Special Focus on Compilers

   Call for papers

  April 27 - April 28, 2020
 GZ Riesbach
 Zürich, Switzerland

 http://www.european-lisp-symposium.org/2020

  Sponsored by EPITA, Igalia S.L.

~~


Invited Speakers

Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework.
Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp.


Important Dates
~~~
- Submission deadline: February 13, 2020
- Author notification: March 16, 2020
- Final papers due:April 6, 2020
- Symposium:   April 27 - 28, 2020


Scope
~
The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp dialects, including
Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp,
ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone
interested in Lisp to participate.

The European Lisp Symposium 2020 invites high quality papers about
novel research results, insights and lessons learned from practical
applications, and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.

This year's focus will be directed towards "Compilers".

We especially invite submissions in the following areas:

- Compiler techniques
- Compiler passes
- Compiler compilers
- Showcasing of industrial or experimental compilers
- Code generation
- Compiler verification
- Compiler optimizations
- JIT compilers

Contributions are also welcome in other areas, including but not
limited to:

- Context-, aspect-, domain-oriented and generative programming
- Macro-, reflective-, meta- and/or rule-based development approaches
- Language design and implementation
- Language integration, inter-operation and deployment
- Development methodologies, support and environments
- Educational approaches and perspectives
- Experience reports and case studies


Technical Program
~
We invite submissions in the following forms:

* Papers: Technical papers of up to 15 pages that describe original
  results or explain known ideas in new and elegant ways.

* Demonstrations: Abstracts of up to 4 pages for demonstrations of
  tools, libraries, and applications.

* Tutorials: Abstracts of up to 4 pages for in-depth presentations
  about topics of special interest for at least 90 minutes and up to
  180 minutes.

All submissions should be formatted following the ACM SIGS guidelines
and include ACM Computing Classification System 2012 concepts and
terms. Submissions should be uploaded to Easy Chair, at the following
http://www.easychair.org/conferences/?conf=els2020

Note: to help us with the review process please indicate the type of
submission by entering either "paper", "demo", or "tutorial" in the
Keywords field.


Programme Chair
~~~
Ioanna M. Dimitriou H. - Igalia, Spain/Germany

Local Chair
~~~
Nicolas Hafner - Shinmera, Switzerland

Programme Committee
~~~
Andy Wingo - Igalia, Spain/France
Asumu Takikawa - Igalia, Spain/USA
Charlotte Herzeel - IMEC, Intel Exascience Lab, Belgium
Christophe Rhodes - Google, UK
Iréne Durand - Université Bordeaux 1, France
Jim Newton - EPITA Research Lab, France
Kent Pitman - HyperMeta, USA
Leonie Dreschler-Fischer - University of Hamburg, Germany
Marco Heisig - FAU Erlangen-Nürnberg, Germany
Mark Evenson - not.org, Austria
Max Rottenkolber - Interstellar Ventures, Germany
Paulo Matos - Igalia, Spain/Germany
Robert Goldman - SIFT, USA
Robert Strandh - Université Bordeaux 1, France

(more PC members to be announced)

-- 
Resistance is futile. You will be jazzimilated.

Didier Verna 
ELS Steering Committee

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/m2pnh1vf8w.fsf%40elsaa.org.

Re: gen-class/AOT considered harmful (in libraries)???

[Didier]

Hum... well, the dependencies normally specify the extent of the AOT, in 
the sense that the AOT follows your code `require chain`. Which is why say 
:dev dependencies or test dependencies normally wouldn't be included in 
your AOT. That said, Clojure is required to AOT, and so it would be on the 
classpath and it will be an implicit require of any namespace, so it will 
get AOTed no matter what. I think that reasoning makes sense.

Still, a Clojure library shouldn't include a dependency on Clojure in my 
opinion, as Clojure will always be provided by the container in those 
cases, unless it is meant to be consumed from Java. The best is to use the 
type of dependency that's like: use the parent specified one, unless there 
is none, then use this one. Can't quite remember all the different dm, but 
I believe lein, maven, etc. all have something like this.

On Monday, 2 September 2019 06:56:50 UTC-7, atdixon wrote:
>
> I was responding to this:
>
> > I'm still torn on whether to actually add Clojure as a proper dependency
>
> The question to have Clojure as a proper dependency doesn't seem to change 
> whether you AOT or not. I take "proper dependency" to mean a Maven/Lein 
> dependency that ships with the dependency list in your library's POM.
>
> I agree that you that you shouldn't ship classes AOT'd outside of your 
> library/its namespaces.  
>
> On Sunday, September 1, 2019 at 10:31:46 PM UTC-5, Didier wrote:
>>
>> AOT does matter, because AOT is transitive. Effectively, all AOT builds 
>> are like Uberjars. They compile your code and the code of your dependencies 
>> and theirs as well into .class files putting everything in the build 
>> folder. Then the package will take all the classes and put them in the Jar.
>>
>> Any library that does that does it wrong. Don't AOT your libraries for 
>> that reason. Or make sure if you do, you are only including .class of your 
>> library code, not any of its dependencies. And even ideally, like I said, 
>> only include the bare minimum, so only .classes required for interop. The 
>> rest package as source.
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/30ecd9df-79c6-4272-ba34-99de339dee88%40googlegroups.com.

Re: gen-class/AOT considered harmful (in libraries)???

[Didier]

AOT does matter, because AOT is transitive. Effectively, all AOT builds are 
like Uberjars. They compile your code and the code of your dependencies and 
theirs as well into .class files putting everything in the build folder. Then 
the package will take all the classes and put them in the Jar.

Any library that does that does it wrong. Don't AOT your libraries for that 
reason. Or make sure if you do, you are only including .class of your library 
code, not any of its dependencies. And even ideally, like I said, only include 
the bare minimum, so only .classes required for interop. The rest package as 
source.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/4516034c-7a15-4424-b0bb-fad483d59ea2%40googlegroups.com.

Re: gen-class/AOT considered harmful (in libraries)???

[Didier]

Clojure does not guarantee binary compatibility between versions, but almost 
always happens to be compatible. Yet, it's best not to distribute your Clojure 
libs as compiled classes, much better to do so as source.

For a gen-class though, it works like Java. Java guarantees backward 
compatibility of classes, as far as I know. So you should be good as long as 
you make sure that none of the Clojure code gets AOTed and included in the jar 
by accident as you compiled the gen-class.

Like keep your gen-class in their own namespace with only the -xyx fns in it. 
And have those instantly delegate to a call to another namespace.

Or what I do is I AOT, but then when I package the Jar, I only include the 
gen-class .class file in it. I hand pick it for inclusion in the Jar, and don't 
include any of the other .class files.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/67955ff9-c70a-44e9-b9be-081056fc10c7%40googlegroups.com.

Re: How to use Clojure core specs in my own library with regards to the EPL license?

[Didier]

Ya, I will just license the modifications to the specs under EPL.

I do feel though specs are a weird grey area. For example, EPL 2.0 says:

> Modified Works shall not include works that contain only declarations, 
> interfaces, types, classes, structures, or files of the Program solely in 
> each case in order to link to, bind by name, or subclass the Program or 
> Modified Works thereof.

And EPL 1 allows a contributor to relicense under EPL 2.

It doesn't list specs explicitly, because it's clearly designed for Java, but I 
feel it begs the question:

If I implement a function of some spec, and then a spec for it. And someone 
implement a function of similar spec, and a spec for it. Now the specs could be 
seen as derivative. It can get tricky. 

Anyways. That's just thoughts. For my project it don't matter. Thanks

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/e2164409-8415-428f-b010-072a629dfd8b%40googlegroups.com.

How to use Clojure core specs in my own library with regards to the EPL license?

[Didier]

I'm looking to publish a Clojure library and would like to release it under 
the MIT license. That said, I needed to modify some core specs so that `fn` 
and `defn` can properly roundtrip between conform and unform.

To do this, I copied the specs for `fn` and `defn` in my own code base, and 
modified them accordingly.

>From what I understand of the EPL, modifications of EPL code must be 
re-licensed under the EPL as well, and what changes were made must be 
documented. But, normally (though the Google vs Oracle lawsuit might change 
that), function signatures are not considered copyrightable. When it comes 
to Spec, things get fuzzy for me, the spec is code, so it probably means it 
is under the EPL. That said, even if I specced `fn` and `defn` myself, 
starting from scratch, chances are I would end up with almost the same 
spec. In some way, a spec is like a function signature as well. So I'm not 
sure how to treat them.

I believe my best bet right now is just either license my whole library 
under EPL, and document the changes I made to the core specs. Or to double 
license, move the specs into their own file with an EPL license, and 
license the rest under MIT.

P.S.: Is it a bug that fn and defn specs can not roundtrip?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/ba126443-0938-4284-8ccf-d9e866a95ed0%40googlegroups.com.

Re: Java Interop on steroids?

[Didier]

Oh, I didn't know about that, pretty funky stuff.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/37f95c64-257b-43c3-9c7c-0bf0f8087e54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Java Interop on steroids?

[Didier]

> They did cite a significant performance boost as a side effect.

I think it isn't very clear from the wording. They didn't just rewrite it in 
Java, they also changed the architecture:

> Storm 2.0.0 introduces a new core featuring a leaner threading model, a 
> blazing fast messaging subsystem and a lightweight back pressure model

So it is hard I think to do an apples to apples comparison. In my opinion, a 
system like Storm will fundamentally be more limited by its architecture in 
performance than the language it uses.

That said, even if I think the performance improvements are probably mostly due 
to architectural changes they also made. It shouldn't come as a surprise that 
Java would be faster than Clojure in most cases. I don't want to make false 
pretenses. Clojure and Java are not equal in semantics, and Java's mutable, 
eager and object grouped methods semantics are almost always going to be more 
performant. Clojure makes a trade offs of performance and memory for simplicity.

When people say Clojure can match Java in performance, it almost always implies 
using escape hatches and changing the semantics back to imperative code. The 
good news though, when you use Clojure's semantics, you benefit in simplicity 
and the performance impact is marginal, so it is still fast enough for almost 
all use cases.

Now, back to type annotations. I really don't think Storm 2.0 performance 
improvements were due to usage of reflection that hadn't been addressed from 
Clojure. But who knows.

Do the framework you're talking about do static analysis of the types? Because 
generic types are erased at runtime, so there wouldn't ever be a way for proxy 
to set them in.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/5a4ad6dc-922a-42ff-b058-faaa94219553%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Calling Java from Clojure

[Didier]

Oh, not when you don't have too. I mean, you can always hand write a class in 
Java and have it call into Clojure. That's effectively gen-class but done 
manually. Otherwise, I favour the Clojure Java API.

But some code base are already using gen-class, and some people do use 
gen-class. Sometimes it works and it's easier then having to write Java and 
modify your build to also use javac and include Java built artifacts.

In those cases, the AOT is problematic, because it brings in dependencies, so 
if you package them as libraries, you get additional classes which can then 
conflict. So you need to find a way to only include the generated class and 
nothing else.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/bf3a22ec-efd0-4508-8e41-895a1329e328%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Calling Java from Clojure

[Didier]

Interesting about impl-ns, I'll have to look into that. If so, it would greatly 
simplify it all.

In my experience, if you only keep the gen-class .class, and delete everything 
else, it all works without issues. If you are actually doing AOT, not for the 
purpose of gen-class, I wouldn't recommend deleting parts of it. From what I 
understand, the gen-class creates a class which will load the Clojure code in 
the static initialize, and look for the Clojure code as a resource on the 
classpath. This seems to work fine if it is only there as a .clj, it will 
perform just in time compilation and everything will work as normal.

Does anyone know of edge cases here? Or has experienced issues with this 
strategy?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/5b75c5de-bdb3-49bb-99ce-65182e53a062%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Calling Java from Clojure

[Didier]

Option #1 and #3 are very much the same, just that Option #3 creates a Java 
layer on top, instead of having everything coupled to the Clojure Java APIs 
directly.

When you go with Option #2, you do not have to AOT everything, but AOT is 
transitive. So as you AOT the gen class, all code it requires and all code they 
in turn require will also be AOT. You can post-process the AOT when jaring, and 
only include the gen-class .class files in the Jar and not the dependencies, 
but that's more work.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/1dd84879-6855-4893-99ee-de15ea6a6329%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] General ML and ETL libraries

[Didier]

Awesome!

On Wednesday, 27 February 2019 09:17:33 UTC-8, Chris Nuernberger wrote:
>
> Clojurians,
>
>
> Good morning from (again) snowy Boulder!
>
>
> Following lots of discussion and interactions with many people around the 
> clojure and ML worlds, TechAscent has built a foundation with the intention 
> to allow the average clojurist to do high quality machine learning of the 
> type they are likely to encounter in their day to day work.
>
>
> This isn't a deep learning framework; I already tried that in a bespoke 
> fashion that and I think the mxnet bindings are great. 
>
>
> This is specifically for the use case where you have data coming in from 
> multiple data sources and you need to do the cleaning, processing, and 
> feature augmentation before running some set of simple models.  Then 
> gridsearch across a range of models and go about your business from there.  
> Think more small to medium sized datomic databases and such.  Everyone has 
> a little data before they have a lot and I think this scale captures a far 
> wider range of possible use cases.
>
>
> The foundation comes in two parts.  
>
>
> The first is the ETL library:
>
> https://github.com/techascent/tech.ml.dataset
>
> This library is a column-store based design sitting on top of tablesaw.  
> The clojure ml group profiled lots of different libraries and we found that 
> tablesaw works great.  
>
> The ETL language is composed of three sub languages.  First a 
> set-invariant column selection language.  Second, a minimal functional math 
> language along the lines of APL or J.  Finally a pipeline concept that 
> allows you to describe an ETL pipeline in data with the idea that you 
> create the pipeline and run it on training data and then it records 
> context.  Then during inference later you just used the saved pipeline from 
> the first operation.  
>
> This is the second large ETL system I have worked on; the first was one 
> named Alteryx.
>
>
> The next library is a general ML framework:
>
> https://github.com/techascent/tech.ml
>
> The library has  bindings to xgboost, smile, and libsvm.  Libsvm doesn't 
> get the credit it deserves, btw, as it works extremely well on small-n 
> problems.  xgboost works well on everything and smile contains lots of 
> different types of models that may or may not work well depending on the 
> problem as well as clustering and a lot of other machine-learny type 
> things.  
>
> For this case, my interest wasn't a clear exposition of all the different 
> things smile can do as it was more just to get a wide enough domain of 
> different model generators to be effective.  For a more thorough binding to 
> smile, check out: 
>
> https://github.com/generateme/fastmath
>
>
> I built a clojure version a very involved kaggle problem example using 
> clojupyter and oz as a proof of concept:
>
>
>
> https://github.com/cnuernber/ames-house-prices/blob/master/ames-housing-prices-clojure.md
>
>
> Enjoy :-).
>
> Complements of the TechAscent Crew & Clojure ML Working Group
>

-- 
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: Closure lang for newbies in 2019

[Didier]

I highly recommend this tutorial series: 
https://aphyr.com/tags/Clojure-from-the-ground-up
Followed by this one: https://kimh.github.io/clojure-by-example/#about
And finally: https://practicalli.github.io/

Regards

On Saturday, 9 March 2019 11:23:12 UTC-8, Eric Calonico wrote:
>
> Hi everybody,
>
> How are you?
>
> I saw some videos about Closure and I really liked the syntax and 
> possibilities, however all tutorials I saw was very old, nothing new is 
> coming out!!
>
> I am coming from OO world, Java, C#, JS. but I am not a professional 
> programmer and I would like to build web apps.
>
> Compared to a newer language like Elixir, there are several more resources 
> to learn from, why is that? Only old tutorials available from Closure.
> It is hard to find tutorials on Pluralsight and Lynda and very few on 
> Udemy based on Closure.
> Very basic ones.
>
> The only resource I found is paid, https://purelyfunctional.tv/
>
> Thanks.
>
>
>
>
>
>

-- 
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.

[ANN] rep 0.1.2

[Didier]

Hum, is there some advantage to using this over just normal `clj -e`?

-- 
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: Compiling with load instead of compile?

[Didier]

Awesome, thanks!

Ya, I guess in that sense root-resource isn't brittle. I meant it more, 
brittle in the context of what other build tools were doing/assuming. Like 
when load-one converts a namespace into its corresponding root resource, 
its not smart. It's just a string replace. So if the namespace name differs 
from the filename, root-resource isn't actually able to find the resource 
for the corresponding namespace.

Anyways, thanks for the response!

On Wednesday, 13 February 2019 19:33:19 UTC-8, Alex Miller wrote:
>
>
>
> On Wednesday, February 13, 2019 at 7:46:43 PM UTC-6, Didier wrote:
>>
>> Hey all,
>>
>> I've been working on internal build tools where I work, and when looking 
>> into how other build tools like lein do their aot :all compilation, it 
>> seems that they all rely on some brittle namespace finder library, which 
>> searches either the classpath, or a folder of files and tries to identity 
>> all the ns declarations.
>>
>
> Or you use a hard-coded list (like the Clojure build itself).
>  
>
>> From that, they call compile in a loop for every namespace they found. 
>> But, compile just goes ahead and converts the namespace into a resource 
>> path in a very brittle way, just replaces dots for forward slashes, and 
>> dashes by underscores.
>>
>
> This is exactly the algorithm used by the runtime to load every Clojure 
> namespace, so I don't think this particular part is brittle at all.
>  
>
>> That's because, `load-one` is actually used to compile, which internally 
>> relies on `load`. Load takes a resource path which needs to be found on the 
>> classpath, not a namespace.
>>
>> Now, there are some packages which have source files that have either a 
>> different ns name then their file name
>>
>
> This is pretty rare as it's impossible for the runtime to load it in the 
> normal way when required (it must be explicitly loaded via one of the load 
> methods).
>  
>
>> , or they use in-ns and are actually evaluating into an existing 
>> namespace defined in another file.
>>
>
> Slightly more common, but still comparatively rare to the very common case 
> of 1 ns per file. (clojure itself does this a number of times)
>  
>
>> Lein actually fails to compile these, because the namespace it finds are 
>> looked up as resources on the classpath by compile and it can't find the 
>> resource, because the resource path does not match the namespace.
>>
>> So, for my build tool aot :all compilation, I decided to instead use 
>> `load` with *compile-files* bound to true. And I just convert each source 
>> file in the source dir to a classpath resource path.
>>
>> From my perspective, this seems a better way to do it, that is more 
>> reliable, and frankly a lot simpler. But since no one
>>
> else did it this way, I'm curious if there is any known issue with this 
>> approach?
>>
>  
> Seems like a reasonable alternative to me.
>
>
>> Regards!
>>
>

-- 
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.

Compiling with load instead of compile?

[Didier]

Hey all,

I've been working on internal build tools where I work, and when looking 
into how other build tools like lein do their aot :all compilation, it 
seems that they all rely on some brittle namespace finder library, which 
searches either the classpath, or a folder of files and tries to identity 
all the ns declarations.

>From that, they call compile in a loop for every namespace they found. But, 
compile just goes ahead and converts the namespace into a resource path in 
a very brittle way, just replaces dots for forward slashes, and dashes by 
underscores. That's because, `load-one` is actually used to compile, which 
internally relies on `load`. Load takes a resource path which needs to be 
found on the classpath, not a namespace.

Now, there are some packages which have source files that have either a 
different ns name then their file name, or they use in-ns and are actually 
evaluating into an existing namespace defined in another file.

Lein actually fails to compile these, because the namespace it finds are 
looked up as resources on the classpath by compile and it can't find the 
resource, because the resource path does not match the namespace.

So, for my build tool aot :all compilation, I decided to instead use `load` 
with *compile-files* bound to true. And I just convert each source file in 
the source dir to a classpath resource path.

>From my perspective, this seems a better way to do it, that is more 
reliable, and frankly a lot simpler. But since no one else did it this way, 
I'm curious if there is any known issue with this approach?

Regards!

-- 
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: Issue when moving to Clojure 1.10

[Didier]

For anyone interested, the approach I ended up taking was to AOT everything all 
the time. But, require the class namespaces to be explicitly defined in the 
build config file for any which needs to be included in the Jar. And when 
packaging the Jar, only the Clojure source and the AOT class files of the 
namespaces that were explicitly listed are included.

I do that by compiling every source files, and then deleting all .class files 
except for the ones that match the explicitly listed namespaces. If no 
namespace are listed, then the resulting Jar is thus similar to a non AOT 
build, and only includes source. 

The advantages are that the AOT compilation bubbles compile issues early at 
build time. And the resulting Jars do not include transitive classes that could 
cause version conflicts. And when you need gen-class, you can include only the 
gen-class .class in the Jar, not even have its containing namespace. Minimizing 
the blast radius of AOT. And if you face the protocol issue, you can specify 
these namespaces as well to ne included in the Jar.

-- 
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: Issue when moving to Clojure 1.10

[Didier]

>
> I think the key is that if you are going to AOT, then everything you 
> depend on should be AOTed. The ideal place to do this is when you build the 
> final application - uberjar and aot the world. To do so, it’s best if libs 
> never AOT to give app compilers the opportunity to do so.
>

The build systems we rely on do not re-build dependent libraries 
unfortunately, and we don't use uberjar for our deployments either. Which 
means I can't delay the AOT to the last possible minute. Also, a lot of 
mixed projects happen, where Java needs the Clojure compiled classes at 
compile time. So these also can't be delayed AOT.

b) compiling only when dependent on things that are compiled
>

This is what we used to do, as we would compile everything, except Clojure 
now depends on something that isn't compiled, core specs, which causes 
conflicts. 

I'll modify our build tooling to somehow filter classes here, I already 
excluded the Clojure directory, so that solved our problem related to 
Clojure. Now I'm just wondering what is best going forward.

The transitive AOT compilation thing is a giant pain but there are ways 
> around it with tooling.
>

With tooling or with code changes? Because you mentioned writing your 
namespaces in a way so that gen-classes limit their AOT imact as much as 
possible. My issue is, I work at a very big company, and I maintain the 
Clojure build tools internally. I can't guide everyone to refactor their 
code to isolate their gen-classes, so I need to make the build tool as 
resilient as possible to all scenarios, assuming no control on the code.

So I have two options:

1) AOT everything all the time, but only include the current project 
classes in the resulting Jar.

2) AOT as little as possible, basically only namespaces with gen-class in 
them. And also only include the current project classes in the resulting 
Jar. Unless there is a dependency with protocol, now these should be 
transiently compiled as well, so I need to give a build options so people 
could specify to include certain transient namespaces into the Jar, in the 
case of protocols.

I'm personally leaning on one, as it seems like it should work in all 
cases. Am I forgetting something?

Regards!

On Saturday, 26 January 2019 15:04:33 UTC-8, Sean Corfield wrote:
>
> 2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9
>
>  
>
> My approach is to isolate the pieces that need to be AOT compiled to as 
> few namespaces as possible and have them only depend on other namespaces at 
> runtime, i.e., avoid :require in the ns clause where possible and use 
> require/resolve in the AOT-compiled functions to get at the larger body of 
> Clojure code. And, of course, to try to avoid gen-class as much as possible 
> too  
>
>  
>
> The transitive AOT compilation thing is a giant pain but there are ways 
> around it with tooling.
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Didier >
> *Sent:* Friday, January 25, 2019 10:11:45 PM
> *To:* Clojure
> *Subject:* Re: Issue when moving to Clojure 1.10 
>  
> So I got to the bottom bottom of the problem here.
>
> This is a scenario:
>
> 1) Library A depends on library B and Clojure 1.10
> 2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9
> 3) Library A does not work, because it is now using the Clojure core spec 
> 1.9 compiled transitively through the Library B AOT, and found in its Jar, 
> since .class get precedence over source files.
>
> So, this means that a library with a dependency on another one that is AOT 
> can cause spec conflicts.
>
> This is new now that spec is out. And so I first caught this when some of 
> our libs were using 1.9, and I started moving others to 1.10.
>
> The way I solved this is by hacking our build, so that the clojure 
> compiled classes from the AOT don't get included in the Jar after they are 
> compiled.
>
> In my opinion, this is a bit of a problem. What would be nice is either to 
> have a way to compile only a gen-class, and not the namespace that contains 
> it. Or not compile things transitively. Or maybe just a way for compile to 
> exclude clojure core namespaces.
>
> Now, if you depend on libraries that don't need AOT, it is not an issue. 
> But if you do, it forces you to re-compile all your dependencies and do a 
> full big bang upgrade to the new Clojure version. You can't just use libs 
> compiled with older versions of spec. While before, you were able to use 
> libs compiled with older version of Clojure from packages that

Re: Issue when moving to Clojure 1.10

[Didier]

Okay, so after reading through the linked issue here: 
https://dev.clojure.org/jira/browse/CLJ-322 I'm not sure, as a tool 
builder, what is the ideal path forward.

This is what I seem to understand would be ideal, let me know if I'm wrong:

1) AOT compile everything. So basically, always AOT every lib. This is to 
make sure that we don't face this issue: 
https://dev.clojure.org/jira/browse/CLJ-1544

2) Figure out some mechanism within the built tooling to only include the 
classes for which the source exist in the current project being built into 
the resulting Jar. Meaning, only namespaces found in the source folder 
should have their compiled classes be included into the Jar.

This setup should minimize conflicts, from what I understand. The only 
thing I'm not sure about is, are classes compiled with an older version of 
Clojure and JDK always going to work with a newer version of Clojure and 
JDK?

On Friday, 25 January 2019 22:11:46 UTC-8, Didier wrote:
>
> So I got to the bottom bottom of the problem here.
>
> This is a scenario:
>
> 1) Library A depends on library B and Clojure 1.10
> 2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9
> 3) Library A does not work, because it is now using the Clojure core spec 
> 1.9 compiled transitively through the Library B AOT, and found in its Jar, 
> since .class get precedence over source files.
>
> So, this means that a library with a dependency on another one that is AOT 
> can cause spec conflicts.
>
> This is new now that spec is out. And so I first caught this when some of 
> our libs were using 1.9, and I started moving others to 1.10.
>
> The way I solved this is by hacking our build, so that the clojure 
> compiled classes from the AOT don't get included in the Jar after they are 
> compiled.
>
> In my opinion, this is a bit of a problem. What would be nice is either to 
> have a way to compile only a gen-class, and not the namespace that contains 
> it. Or not compile things transitively. Or maybe just a way for compile to 
> exclude clojure core namespaces.
>
> Now, if you depend on libraries that don't need AOT, it is not an issue. 
> But if you do, it forces you to re-compile all your dependencies and do a 
> full big bang upgrade to the new Clojure version. You can't just use libs 
> compiled with older versions of spec. While before, you were able to use 
> libs compiled with older version of Clojure from packages that use newer 
> version of Clojure.
>
> On Wednesday, 16 January 2019 20:47:43 UTC-8, Mark Derricutt wrote:
>>
>> On 16 Jan 2019, at 18:17, Alex Miller wrote:
>>
>> Yes, it's one of the downsides of AOT. 
>>
>> I'd say it's not so much a downside of AOT - but of having a single 
>> output path for classes. I've long wanted Chas's patch to be applied, or 
>> something like it.
>>
>> Having everyone reinvent the mechanism whenever they happen to need AOT 
>> is kind of annoying - rare, but still annoying.
>> --
>>
>> "The ease with which a change can be implemented has no relevance at all 
>> to whether it is the right change for the (Java) Platform for all time." — 
>> Mark Reinhold.
>>
>> Mark Derricutt
>> http://www.theoryinpractice.net
>> http://www.chaliceofblood.net
>> http://plus.google.com/+MarkDerricutt
>> http://twitter.com/talios
>> http://facebook.com/mderricutt
>>
>

-- 
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: Issue when moving to Clojure 1.10

[Didier]

So I got to the bottom bottom of the problem here.

This is a scenario:

1) Library A depends on library B and Clojure 1.10
2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9
3) Library A does not work, because it is now using the Clojure core spec 
1.9 compiled transitively through the Library B AOT, and found in its Jar, 
since .class get precedence over source files.

So, this means that a library with a dependency on another one that is AOT 
can cause spec conflicts.

This is new now that spec is out. And so I first caught this when some of 
our libs were using 1.9, and I started moving others to 1.10.

The way I solved this is by hacking our build, so that the clojure compiled 
classes from the AOT don't get included in the Jar after they are compiled.

In my opinion, this is a bit of a problem. What would be nice is either to 
have a way to compile only a gen-class, and not the namespace that contains 
it. Or not compile things transitively. Or maybe just a way for compile to 
exclude clojure core namespaces.

Now, if you depend on libraries that don't need AOT, it is not an issue. 
But if you do, it forces you to re-compile all your dependencies and do a 
full big bang upgrade to the new Clojure version. You can't just use libs 
compiled with older versions of spec. While before, you were able to use 
libs compiled with older version of Clojure from packages that use newer 
version of Clojure.

On Wednesday, 16 January 2019 20:47:43 UTC-8, Mark Derricutt wrote:
>
> On 16 Jan 2019, at 18:17, Alex Miller wrote:
>
> Yes, it's one of the downsides of AOT. 
>
> I'd say it's not so much a downside of AOT - but of having a single output 
> path for classes. I've long wanted Chas's patch to be applied, or something 
> like it.
>
> Having everyone reinvent the mechanism whenever they happen to need AOT is 
> kind of annoying - rare, but still annoying.
> --
>
> "The ease with which a change can be implemented has no relevance at all 
> to whether it is the right change for the (Java) Platform for all time." — 
> Mark Reinhold.
>
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>

-- 
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: Issue when moving to Clojure 1.10

[Didier]

Okay, I think I have a good understanding now.

Internally, I was using the Clojure build which bundles the dependency with it. 
That's why that namespace shows up inside my Clojure Jar.

It makes sense also not to guarantee binary compatibility. We will make sure to 
always build and run using the same version of Clojure from now on. 

Is source compatibility guaranteed to some extent? Lile Clojure 1.10 compiling 
Clojure 1.8 source? I'd assume if so, its only guaranteed backward, like old 
Clojure is not guarantee to support newer Clojure code?

-- 
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: Issue when moving to Clojure 1.10

[Didier]

Okay, I found my issue, mostly. 

It seems that Clojure 1.9 and 1.10 both now have a clojure.core.specs.alpha.clj 
file.

This file seems to be the only file that is not AOT compiled by the maven 
compile script for Clojure. Thus the Jar for Clojure only has it as source, and 
is missing the .classes for it.

We have custom Ant tasks to compile Clojure, where we call compile-ns ourselves 
on our source namespaces.

I was using Clojure 1.9 in our Ant tasks, which meant that as part of running 
compile-ns on our namespace, because they depend on Clojure core as well, 
clojure.core.specs.alpha.clj from the Clojure 1.9 jar was also being compiled.

Thus, our project jar now contained the 1.9 classes for core specs.

Now, we would use Clojure 1.10 to run our project, but the Clojure 1.9 core 
specs fail to validate amp-impl of Clojure 1.10. I'm guessing it was changed 
along with its spec inside core specs.

So we were getting a weird syntax error at runtime for every namespace that 
depend on clojure.core.

I have a few questions based on this:

1) Why is clojure.core.specs.alpha.clj the only thing not AOT compiled in the 
Clojure jar?

2) I realized that I probably shouldn't compile Clojure 1.10 code with Clojure 
1.9, and I bumbed our Ant code to use Clojure 1.10, and that fixed it. So what 
are the compiler compatibility? Can newer Clojure versions compile older 
Clojure code? Is it only two version back? Is this tested? Or should I always 
use equal versions to compile? Is forward compatibility a thing? Etc.

3) Is compile-ns transitive? I was surprised to see that it also compiles 
clojure.core.specs.alpha.

4) Isn't it a bit strange that if I AOT compile my code, my Jar gets .class 
files from Clojure core as well? Even though I don't get the error anymore, I 
still have clojure.core.specs.alpha classes from my jar on the classpath, and 
the source from Clojure on it as well.

Thanks

-- 
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.

Issue when moving to Clojure 1.10

[Didier]

When compiling with Clojure 1.10, I get the following error, which I did 
not use to get on 1.7, 1.8 and 1.9:

Exception in thread "main" Syntax error compiling at (com/org/namespace_test
.clj:1:1).
  at clojure.lang.Compiler.load(Compiler.java:7647)
  at clojure.lang.RT.loadResourceScript(RT.java:381)
  at clojure.lang.RT.loadResourceScript(RT.java:372)
  at clojure.core$load$fn__6824.invoke(core.clj:6126)
  at clojure.core$load.invokeStatic(core.clj:6125)
  at clojure.core$load.doInvoke(core.clj:6109)
  at clojure.lang.RestFn.invoke(RestFn.java:408)
  at clojure.core$load_one.invokeStatic(core.clj:5908)
  at clojure.core$load_one.invoke(core.clj:5903)
  at clojure.core$load_lib$fn__6765.invoke(core.clj:5948)
  at clojure.core$load_lib.invokeStatic(core.clj:5947)
  at clojure.core$load_lib.doInvoke(core.clj:5928)
  at clojure.lang.RestFn.applyTo(RestFn.java:142)
  at clojure.core$apply.invokeStatic(core.clj:667)
  at clojure.core$load_libs.invokeStatic(core.clj:5985)
  at com.org.ant.clojure.test_runner$exec_tests.invoke(test_runner.clj:10)
  at clojure.lang.RestFn.invoke(RestFn.java:397)
  at clojure.lang.AFn.applyToHelper(AFn.java:152)
  at clojure.lang.RestFn.applyTo(RestFn.java:132)
  at com.org.ant.clojure.TestRunner.main(Unknown Source)
Caused by: java.lang.ExceptionInInitializerError
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:348)
  at clojure.lang.RT.classForName(RT.java:2207)
  at clojure.lang.RT.classForName(RT.java:2216)
  at clojure.lang.RT.loadClassForName(RT.java:2235)
  at clojure.lang.RT.load(RT.java:453)
  at clojure.lang.RT.load(RT.java:428)
  at clojure.lang.Compiler.ensureMacroCheck(Compiler.java:6957)
  at clojure.lang.Compiler.checkSpecs(Compiler.java:6969)
  at clojure.lang.Compiler.macroexpand1(Compiler.java:6987)
  at clojure.lang.Compiler.macroexpand(Compiler.java:7074)
  at clojure.lang.Compiler.eval(Compiler.java:7160)
  at clojure.lang.Compiler.load(Compiler.java:7635)
  ... 30 more
Caused by: clojure.lang.ArityException: Wrong number of args (3) passed to: 
clojure.spec.alpha/amp-impl
  at clojure.lang.AFn.throwArity(AFn.java:429)
  at clojure.lang.AFn.invoke(AFn.java:40)
  at clojure.core.specs.alpha$fn__47.invokeStatic(alpha.clj:107)
  at clojure.core.specs.alpha$fn__47.invoke(alpha.clj:107)
  at clojure.core.specs.alpha__init.load(Unknown Source)
  at clojure.core.specs.alpha__init.(Unknown Source)
  ... 43 more


Anyone knows why?

Here's the code at 1:1 :

(ns com.org.namespace-test
  (:require [clojure.test :as test :refer :all]
[com.org.namespace :as namespace])
  (:import [com.org.persistence Response]
   [com.org.encrypt Encrypter]))


-- 
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: GraalVM's native-image incompatible with Clojure's eval?

[Didier]

In my case, substratevm itself pointed to me which class was being reflected 
on. Though it didn't specify which fields or methods, but I just set it to 
allow all methods and fields of the reported classes to be allowed.

-- 
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: GraalVM's native-image incompatible with Clojure's eval?

[Didier]

You can give substratevm a reflection json file though. That did the trick for 
me.

https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md

So you just need to tell it in advance what class you will reflect on and how. 
Then it should work.

-- 
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: GraalVM's native-image incompatible with Clojure's eval?

[Didier]

Hum, I hadn't heard of jaotc. Hopefully it will continue to be developed. A 
slower Clojure which starts mich faster yet is fully compatible would be a nice 
trade off in many cases. 

I found this reading interesting: 
https://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html#using-cds

For using jaoct and appCDs and then clojire.main starts in 0.4 second. 

-- 
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: Who Uses import-vars?

[Didier]

So is there another way then using import-vars tp break up an existing package 
into many new small ones?

-- 
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: [ANN] High Performance Numerics Compiler

[Didier]

Wow, awesome!

On Monday, 12 November 2018 07:46:14 UTC-8, Chris Nuernberger wrote:
>
> Clojurians, we are happy to put forth our work bringing the TVM compiler 
> and infrastructure to clojure.  It has backends for ARM, Intel, OpenCV, 
> Cuda, OpenGL, Vulkan, ROCm, and more.  
>
> This system is currently getting state of the art performance several deep 
> learning kernels and I demonstrate it getting great performance (usually 
> beating by a sound margin but not always) as compared to hand optimized 
> code in OpenCV.
>
> Utilizing years of experience writing doing HPC and GPGPU programming, we 
> researched the best way to integrate clojure at a low level with one of the 
> major NN toolkits.  We didn't want to sit on top of them alone because we 
> believe the underlying technology is useful in a broader context and we 
> believe that Clojure should be a first class citizen in these ecosystems.
>
> So we spent roughly the last 6 months working on and off in infrastructure 
> and support systems and you saw an example of the result earlier this year 
> with the opencv bindings.
>
> So, with no further ado:
>
> 1.  Light description of the overall compiler architecture and theory:
> http://techascent.com/blog/high-performance-compilers.html
>
> 2.  Example of using the compiler:
> http://techascent.com/blog/tvm-for-the-win.html
>
> 3.  Github project (with lots of links to more material):
> https://github.com/tech-ascent/tvm-clj
>
> Happy Monday from snowy Boulder, Colorado :-)
>

-- 
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: Request to review my CLJS using core.async

[Didier]

Do you really need core.async for this?

Seems like you can just normally call the service to get the token once at 
the beginning and then just go in a normal loop of calling for the next 
message -> handling message -> repeat.

I'm not sure there's any reason to use core.async in ClojureScript other 
then if you were doing a bunch of concurrent async IO.

On Monday, 12 November 2018 05:46:17 UTC-8, Kashyap CK wrote:
>
> Hi all,
>
> I am attempting to use core.async to poll a service - 
> https://gist.github.com/ckkashyap/c8423dcfc3a3f28b67e18ae76cc13f53
> Broadly, I need to hit the service endpoint with a secret to get a token 
> and subsequently use the token to poll for messages. 
>
> I'd appreciate any feedback on the approach - particularly around 
> 1. Error handling
> 2. Use of channels
>
> Is there some project out there I could take a look at to learn the 
> right/good way to do this?
>
> Regards,
> Kashyap
>

-- 
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: What if ^:const could inline everything before macroexpanssion?

[Didier]

Ah right, I see now.

Ya, so it seems macros are fully expanded first, and then constant are 
inlined, and then code is evaled.

So there's really no way to specify a global to be used within a macro 
itself, unless you resolve it explicitly within your macro, using resolve 
or eval, or if you use the reader eval when calling you macro.

On Wednesday, 7 November 2018 02:20:06 UTC-8, juan.facorro wrote:
>
> Sorry, I now understand what you mean.
>
> The unfolding logic that I proposed before was completely missing the fact 
> that the foo macro is not:
>
> (defmacro foo
>   [x]
>   `(+ 10 ~x))
>
> But:
>
> (defmacro foo
>   [x]
>   (+ 10 x))
>
> The following assertion from the previous post is blatantly wrong with the 
> correct macro definition above:
>
>> This tries to macroexpand the expression, which in this case will result in 
>> `(foo bar)` being expanded into `(+ 10 foo)`. 
>
> So when evaluating (foo bar) we do get the exception you mention, of 
> course, since on macroexpansion we are trying to add 10 and the symbol bar
> . 
>
> It is still the case as before though that the macroexpansion of (foo 
> bar)happens 
> before the symbol bar is resolved and analyzed as a constant expression.
>
> Sorry for the mess and confusion.
>
> On Wednesday, November 7, 2018 at 11:04:27 AM UTC+1, juan.facorro wrote:
>>
>> That's strange, this is what I get in the REPL when evaluating that 
>> expression:
>>
>> $ clj
>> Clojure 1.9.0
>> user=> (. clojure.lang.Numbers (add 10 100))
>> 110
>> user=>
>>
>>
>>
>> On Wednesday, November 7, 2018 at 10:01:20 AM UTC+1, Didier wrote:
>>>
>>> Hey, thanks for the deep dive, but I'm not sure I either understand, or 
>>> that it is correct.
>>>
>>> So what we end up with is the equivalent to analyzing the expression `(. 
>>>> clojure.lang.Numbers (add 10 100))`. 
>>>>
>>>
>>> When I run my example, I get:
>>>
>>> ClassCastException clojure.lang.Symbol cannot be cast to java.lang.
>>> Number  clojure.lang.Numbers.add
>>>
>>> When I macroexpand-1 my example, I also get the same ClassCastException.
>>>
>>> But if we follow your step by step, you make it sound like it would work 
>>> and return 110.
>>>
>>> So at which step would this exception be thrown? And why?
>>>
>>>
>>> On Thursday, 15 March 2018 11:11:24 UTC-7, Didier wrote:
>>>>
>>>> I was hoping that ^:const would be able to inline any symbol value and 
>>>> that it would do so before macroexpanssion so that:
>>>>
>>>> (def ^:const bar {:a 100})
>>>>
>>>> (defmacro foo
>>>>   [x]
>>>>   (:a x))
>>>>
>>>> (foo bar)
>>>>
>>>> Would return:
>>>>
>>>> 100
>>>>
>>>> The same way that:
>>>>
>>>> (foo {:a 100})
>>>>
>>>> does.
>>>>
>>>> Then I read that ^:const only inlines primitive values (which 
>>>> disappointed me), but so I thought that this would work:
>>>>
>>>> (def ^:const bar 100)
>>>>
>>>> (defmacro foo
>>>>   [x]
>>>>   (+ 10 x))
>>>>
>>>> (foo bar)
>>>>
>>>> but that also doesn't work.
>>>>
>>>> So now I believe that ^:const inlines after macroexpanssion.
>>>>
>>>> I feel it would be really cool to be able to factor some input to 
>>>> macros into constants, is this something I could open a ticket for, to 
>>>> extend ^:const so it can inline all literal values and also does the 
>>>> inlining before macroexpanssion so that the above would work?
>>>>
>>>

-- 
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: What if ^:const could inline everything before macroexpanssion?

[Didier]

Hey, thanks for the deep dive, but I'm not sure I either understand, or 
that it is correct.

So what we end up with is the equivalent to analyzing the expression `(. 
> clojure.lang.Numbers (add 10 100))`. 
>

When I run my example, I get:

ClassCastException clojure.lang.Symbol cannot be cast to java.lang.Number 
 clojure.lang.Numbers.add

When I macroexpand-1 my example, I also get the same ClassCastException.

But if we follow your step by step, you make it sound like it would work 
and return 110.

So at which step would this exception be thrown? And why?


On Thursday, 15 March 2018 11:11:24 UTC-7, Didier wrote:
>
> I was hoping that ^:const would be able to inline any symbol value and 
> that it would do so before macroexpanssion so that:
>
> (def ^:const bar {:a 100})
>
> (defmacro foo
>   [x]
>   (:a x))
>
> (foo bar)
>
> Would return:
>
> 100
>
> The same way that:
>
> (foo {:a 100})
>
> does.
>
> Then I read that ^:const only inlines primitive values (which disappointed 
> me), but so I thought that this would work:
>
> (def ^:const bar 100)
>
> (defmacro foo
>   [x]
>   (+ 10 x))
>
> (foo bar)
>
> but that also doesn't work.
>
> So now I believe that ^:const inlines after macroexpanssion.
>
> I feel it would be really cool to be able to factor some input to macros 
> into constants, is this something I could open a ticket for, to extend 
> ^:const so it can inline all literal values and also does the inlining 
> before macroexpanssion so that the above would work?
>

-- 
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: [ANN] 1.10.0-beta5

[Didier]

Hum, just noticed tap. Seems really interesting. I'm not thinking of any 
concrete usage for now, but I like it!

Also, is the object in the datafy description referring to a Java object? 
If so, is it a way to transform nested Java objects into Clojure data, and 
possibly back?

On Wednesday, 7 November 2018 00:12:44 UTC-8, Khalid Jebbari wrote:
>
> Alex, it's funny that the example you showed about using the new extension 
> mechanism looks very much like implementing lifecycle hooks in React.js 
> (and the various CLJ/CLJS wrappers).
>
> Indeed having value-based extension makes it much more flexible than 
> having to use deftype/defrecord. My understanding is that since it's based 
> on metadata, one could extend after the fact with 
> `reset-meta!`/`alter-meta!` right?
>
> On Tuesday, November 6, 2018 at 2:42:45 PM UTC+1, Alex Miller wrote:
>>
>> 1.10.0-beta5 is now available.
>>
>> You can try it with clj using:
>>
>>   clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version 
>> "1.10.0-beta5"}}}'
>>
>> Changes in 1.10.0-beta5:
>>
>>
>>- In addition to prior methods of extension, values can now extend 
>>protocols by adding metadata where keys are fully-qualified symbols 
>> naming 
>>protocol functions and values are function implementations. Protocol 
>>implementations are checked first for direct definitions (defrecord, 
>>deftype, reify), then metadata definitions, then external extensions 
>>(extend, extend-type, extend-protocol). datafy has been updated to use 
>> this 
>>mechanism.
>>- `symbol` can now be passed vars or keywords to obtain the 
>>corresponding symbol
>>- CLJ-2420  error 
>>reporting enhancements - more refined phase reporting, new 
>>clojure.main/ex-triage split out of clojure.main/ex-str, execution errors 
>>now report the top *user* line in the stack trace omitting frames from 
>>core, enhancements to providing file and line via meta on a form
>>- CLJ-2425  add java 11 
>>javadoc url
>>- CLJ-2424  fix test 
>>bug from CLJ-2417
>>
>> You can read the full 1.10 changelog here: 
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>

-- 
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: What's the end goal for tools.deps?

[Didier]

>
> I’m curious as to how you define this tool: what exactly do you consider a 
> “dependency manager” to be, and what are it’s specific functions/features? 
> You talk about having an “internal dependency manager” – how do you 
> leverage that from Clojure?
>

By dependency manager, I mean a system that defines "packages" and 
dependencies (including transitive) between them. Which can also retrieve 
those packages, and generate the dependency graph.

I'll try to explain, but my work highly values reproducible builds. And so 
everything stems from that. Think of reproducible build as the idea that 
you can regenerate the identical artifact and environment produced by a 
past deployment.

So our packages are managed by some system, each package is just a git repo 
with some config file that defines the dependencies of the package on 
others.

This is what I call the "dependency manager". It tracks package 
dependencies, where in our case, packages are git repos.

You can ask it to generate the dependency graph of a given package, and you 
can also use it to retrieve all packages into a local copy, and generate a 
classpath pointing in the correct order to all the local copies.

At this point, it is a lot like tools.deps. Except that it also has a 
global registry with additional meta data support for packages, like 
versions.

Another difference is that it is tied into our build and deployment 
process. When you build a package, the build system uses the dependency 
manager to pull down all transitive packages of the defined version, it 
then proceeds to build them in order. All artifacts are then cached in an 
artifact repository. The package thus references a git repo, each package 
version maps to an exact commit, and artifact build cache.

When we deploy, it's just the same thing that happens. The host uses the 
dependency manager to build the dependency tree, but the difference here, 
is that, instead of retrieving the git source for the specified commits of 
the specified versions of each package, it will grab there corresponding 
cached artifacts as a performance optimization.

So now, when it comes to Clojure, I can't use lein or tools.deps to 
retrieve package dependencies, since they don't know about our internal 
packages and how to retrieve them. I already have a configuration format to 
specify dependencies on other packages, and a cli tool which can retrieve 
them locally (either their source or their corresponding built artifact) 
from our internal source and artifact repos, and can also generate the 
classpath.

What I don't have though, is a way to perform Clojure build tasks, like run 
tests, generate coverage reports, perform AOT, generate Java classes, etc. 
I can't use lein for that, since I couldn't find how to have it use a 
custom classpath for all of its tasks, it seems to always implicitly 
assumes it will retrieve the packages itself and build the classpath.

So I basically use Ant. Which surprisingly, is one of the last build tool 
that does not complect itself with dependency management as well. So I can 
use it purely to build. And I created custom Ant tasks for the Clojure 
related tasks I needed.

I'd love a standard Clojure build tool that is decoupled from a dependency 
manager, which I could use instead of Ant, and where I didn't have to write 
the Clojure tasks myself. Though since I do a lot of mixed Java/Clojure 
project, it would need to also support Java build tasks. So who knows, I 
might never have the full package I dream off.

Something else that is really painful is bringing in an external Clojure 
package internally. I'm forced to re-write the dependency format to our 
internal one. So if it's project.clj or deps.edn, I need to change it to 
our internal one. Also painful is having to retrieve the source for these, 
and make an internal source copy. I feel like tools.deps might actually 
help me here long term, if everything move to source only dependencies, I 
could leverage it to transitively retrieve and copy over all source and 
their source dependencies.

Sorry for the long wall of text, but this stuff is actually kind of 
complicated.

On Sunday, 4 November 2018 15:35:29 UTC-8, Sean Corfield wrote:

> I guess I see the need for a dependency manager.
>
>  
>
> I’m curious as to how you define this tool: what exactly do you consider a 
> “dependency manager” to be, and what are it’s specific functions/features? 
> You talk about having an “internal dependency manager” – how do you 
> leverage that from Clojure?
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Didier >
> *Sent:* Sunday, November 4, 2018 10:58

Re: What if ^:const could inline everything before macroexpanssion?

[Didier]

>
> Macroexpansion is given the raw forms that are read, and I think 
> that's a good thing. Inside a macro you can always call 
> macroexpand yourself if you want to (or resolve values another 
> way) but there's no way to "undo" automatic macroexpansion. 
>

That's a good point. I guess resolving the constant inside the macro still 
performs the compile time optimization of in-lining.

I guess my question now becomes, when does const actually expands? Or what 
does it do exactly? In my mind, it is supposed to inline its usage. So does 
it do so after expansion?
 
On Thursday, 15 March 2018 18:15:16 UTC-7, Carlo Zancanaro wrote:
>
> On Thu, Mar 15 2018, Didier wrote: 
> > I feel it would be really cool to be able to factor some input 
> > to macros into constants, is this something I could open a 
> > ticket for, to extend ^:const so it can inline all literal 
> > values and also does the inlining before macroexpanssion so that 
> > the above would work? 
>
> Macroexpansion is given the raw forms that are read, and I think 
> that's a good thing. Inside a macro you can always call 
> macroexpand yourself if you want to (or resolve values another 
> way) but there's no way to "undo" automatic macroexpansion. 
>
> As one particular example, how would this work in your world? If 
> the `bar` is replaced ahead of time in the usage of `l` then it 
> cannot be shadowed as an identifier. 
>
>   (def ^:const bar {:a 100}) 
>   (defmacro l [name value & body] 
> `(let [~name ~value] 
>   ~@body)) 
>   (l bar 1 
>  (+ bar 1)) 
>
> If you want to factor out things for macros (particularly macros 
> that you don't control) you can try doing so at read time, with 
> something that evaluates at read time, like so: 
>
>   (def bar {:a 100}) 
>   (defmacro foo [x] 
> (:a x)) 
>   (foo #=(eval bar)) ;; => 100 
>
> It's a bit messy, but it draws attention to the fact that there's 
> something unusual happening with evaluation order. 
>
> Carlo 
>

-- 
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: What's the end goal for tools.deps?

[Didier]

>
> Generally those tools are just Clojure programs with a clojure.main. If 
> you can build a classpath from your dependency manager, then invoke the 
> tool, then yes, all those tools are open to you as well (and for packaging 
> as lein plugins or boot tasks too). There is no magic here. It's just 
> running Clojure programs.
>

Currently, we perform all build tasks using custom Clojure code. We have 
our own test runner, and script to launch cloverage, kibit and eastwood, we 
AOT compile and package a hybrid JAR of source and .class (to support 
consumption from Java and Clojure). But I've always wanted to leverage 
existing work for these, as it can get complicated. I never figured out in 
Lein how to swap the dependency resolution logic with our own, and just 
leverage the build features and the accompanying plugins. There's no way to 
just provide the dependency tree or the classpath to Lein that I could 
find. It seems tools designed for tools.deps might be easier for me to 
leverage, like https://github.com/cognitect-labs/test-runner. This looks 
pretty great, I'll see if I can swap to it instead of out custom 
test-runner.
 

> I know Rich hopes strongly that the Clojure community is a place where 
> people are free and supported when attempting to creatively solve problems 
> in new ways. Certainly Clojure itself wouldn't exist if the community 
> wasn't willing to try something new and different. Sometimes you have to 
> start over, with a new set of assumptions and constraints and see where it 
> goes.
>

Definitely, though I do hope we won't be experimenting with dependencies 
much more. It's hard to keep up, maven, lein, boot, now clj, throw in 
ClojureScript and you need to deal with npm too. It gets quite complicated. 
To me, this is mostly accidental complexity created by the lack of a common 
standard.

At least tools.deps has enough of a differentiator, I can recognize its 
worth the change. Being official is really key to me, so I'm happy.

The risk I see is that you can end up in a place where dependency 
resolution becomes incompatible. Say you depend on package X, and it uses a 
different dependency declaration format. Now you can't resolve its 
dependencies.

This can also happen for build logic. Though it's not as bad a problem in 
Clojure. There's packages that say need to pull in resources, or must 
perform AOT, and if you depend on such a package source, you can't 
transitively build it if the build process declaration is in incompatible 
formats.

Anyways, I was mostly curious, just wanted to understand better the 
rationale. I'll look forward to what happens next, and I assume things will 
standardize around it more and more, which will solve most of my issues. 

-- 
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: What's the end goal for tools.deps?

[Didier]

Thanks everyone.

I guess I see the need for a dependency manager. And I love having a CLI to 
launch Clojure programs. And I understand it is fundamental. That said, it 
always felt like Lein had solved that problem long ago. Maybe it wasn't 
official enough. But Lein could have been bundled with Clojure and effectively 
solved the same problems and more.

That said, I do prefer the tools.deps abstraction. Just feels a little like 
reinventing the wheel. 

I'll be interested to read your blog posts Sean.

At my work, I can't use tools.deps, because we have an internal dependency 
manager. And all dependencies are imported and vetted in it first. So I've 
always wanted a build tool that was decoupled from dependency management. Since 
tools.deps only outputs a classpath, I assume all these extra tools you 
mentioned using to build and run your tests and deploy somehow work only given 
a classpath. They might be useful to me.

Regards

-- 
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.

What's the end goal for tools.deps?

[Didier]

I read the rationale, and I understand that we needed a way to bundle 
depencies for clj and clojure cli. But in practice, I'm seeing a lot of 
people move to it, away from boot or lein, and I fail to see what the end 
goal really is?

Any serious work will need a build tool of some sort. If you use lein, it 
comes with its own dependency management and config. Same for boot (as far 
as I know). So in practice, if I use tools.deps, I've now doubled the 
number of tools I depend on. I need lein and tools.deps.

For me, it seems the benefit would be around unified dependency config 
format and maybe reuse of the resolver logic. Like say Lein and Boot and 
all tools needing to specify dependencies adopted the format of tools.deps. 
This would be nice, especially for source based dependencies, and dealing 
with transitive dependencies in such case.

So, is there any hope/work to adopt the format in Lein and Boot? Or what is 
the end goal otherwise?

Regards

-- 
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: An Error spec?

[Didier]

No, I'm thinking more like:

(defmacro errorable
  [success-spec error-spec]
  `(s/or :success ~success-spec
 :error ~error-spec))

(s/def ::result (errorable string? #{:authentication-failure :missing-input})

(s/conform ::result "Here is a successful and valid result.")

-> [:success "Here is a successful and valid result."]

(s/conform ::result :missing-input)

-> [:error :missing-input]

Now we have a standard spec for something that is either in success or in 
error. And it conforms to standard representations, a vector pair, with first 
being either the :success keyword or the :error keyword.

You can add convenience function to this if you want, like:

(defmacro if-error
  [spec value do-when-success do-when-error]
  ...)

(if-error ::result result
  (display result)
  (display "An error occurred, please try again.")

-- 
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: An Error spec?

[Didier]

> I’m genuinely curious as to what you (and other folks) would like to see 
> added to Clojure to satisfy this “need”.

I'm proposing we add a spec for it, which would conform to success or error.

This would still allow flexibility in that you can choose your own error 
structure, and success structure. But it would also add a convention to at 
least formally specify predictable errors.

You can then know if what you got is an error or not by conforming it against 
the spec.

And you can tell if something can return predictable errors, as well as success 
values and exceptions by seeing that the return is of the errorable spec (or 
some other name we can come up with).

Personally I feel this would be good enough, and it seems to respect the 
general Clojure mindset of dynamism and flexibility and not making concrete 
choices for you. And I'd be happy with that.

You could, though that's not something I care for, go further and provide a 
standard error record in core, or a standard error protocol. That said, I feel 
that would maybe be a bit too far, especially, it feels like it might go a 
little against the spirit of Clojure till now. Since I know of no standard 
records, and very little standard protocols.

-- 
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: An Error spec?

[Didier]

Sean, if you were to Spec your API responses, what would you do for your error 
response?

This is my issue. I operate in a distributed environment. If I produce a set of 
data, but one field failed to compute properly, maybe a downstream system was 
down, maybe some information I was given to compute was corrupted, or missing, 
etc. And say this producing service has no user facing component, failing it is 
not logical. So I need to publish the partial result, and the error field 
should indicate an error. In my case it publishes a document entry in a nosql 
datastore, and events about it.

Now, some other system will eventually consume that document, to display it to 
the user. When it does, it must appropriately handle the fact that some fields 
were in error.

My documents are fully specced. So that consuming services can easily know 
their shapes and structure, so they can be sure to support them fully.

In such scenario, exceptions aren't useful, but only because Java exceptions 
are crap at serialization. So I need to do the same thing you are, marshal my 
exception into an error and serialize that into my document. Then I spec the 
field appropriately. 

Now, I feel a lot of people using Spec would have such a use case, as its a 
logical tool to model data at your boundaries, and so I felt it might make 
sense to offer a spec macro for it.

-- 
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: An Error spec?

[Didier]

Interesting. I understand that, I guess it's because of my usage of spec.

I tend to use spec exclusively at the boundaries. Think serialization. 
Sometimes, I have a producer which can't handle the error, so it must be 
serialized and exchanged to the consumer.

So say the producer couldn't produce the value, for some reason. In some cases, 
that's a bug, and I throw an exception, and fail the producer itself. But 
sometimes, its an expected possibility, in which case, tbe value is an error. 
And the producer must communicate that out.

Unfortunatly, exceptions are not friendly to serialization or spec. So I need 
to roll my own error structure, serialize that, and spec it.

-- 
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.

An Error spec?

[Didier]

I've started to see a pattern in my spec like this:

(s/or :success string?
  :error ::error)

And I've been tempted to create my own spec macro for this. But I also 
thought, maybe Spec itself should have such a spec.

(s/error  )

What do people think?

-- 
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: (type ...) vs (class ...)

[Didier]

Reviving this thread, as I'd like to kmow if someone can explain the purpose of 
the type metadata and what is responsible for adding it?

-- 
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: Prototype code for enhanced CIDER code completion for Java methods

[Didier]

How does the new syntax help the tooling figure out the type?

(def var (SomeType.))
(.method var)

Or

(jvm (var.method))

I'm not sure how you narrow down to only the SomeType methods?

-- 
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.

Prototype code for enhanced CIDER code completion for Java methods

[Didier]

Could you find a way that doesn't require a syntax change?

Maybe a meta hint?

-- 
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.

Pipe shell output into REPL?

[Didier]

Hi all,

I was wondering if there is an easy way I can pipe my shell output into a 
REPL. Something like:

cat /tmp/remus-lighthouse-apis-info.ion | lein repl

When I try this, it starts a REPL, and then each line gets sent one by one 
to the REPL and ran.

I'd like it so that I'm at the REPL, and standard in is ready to be read by 
me, from the REPL, so I can manipulate the input being piped how I see fit 
within the repl session.

Is there anyway to do this?

-- 
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: New developments in beginner-friendly editing/repl environments?

[Didier]

Have you tried maria.cloud? Its only ClojureScript, but in the Jupiter style 
seems to meet your needs.

Though you can't add dependencies to it as far as I know.

-- 
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: Why are mutable fields on deftype not public?

[Didier]

I see, actually that makes a lot of sense. I always kind of disagreed with the 
encapsulation is folly mentra. But if you add to it, of immutable data, it 
makes more sense.

A few more related questions.

1) I gathered the fields are made package restricted. Is that correct?

2) It seems methods defined inline on deftype are different then the ones 
defined with extend. Is there a performance implication here? It appears the 
inline ones would be compiled to methods on the class. So are the extend one 
compiled as seperate classes, and then dispatched too in a more dynamic nature?

-- 
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.

Why are mutable fields on deftype not public?

[Didier]

It seems to contradict the documentation found here datatypes 
:

> Encapsulation of information is folly. Fields are public, use 
protocols/interfaces to avoid dependencies

It is also not documented in the doc-string, and makes it impossible to 
further extend the type. No more ad-hoc polymorphism basically.

So you can't do this:

(deftype MutableBox [^{:volatile-mutable true} contents])

(defprotocol Container
  (inventory [this]))

(extend-type MutableBox
  Container
  (inventory [this] (.-contents this)))

-- 
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.

Is core.async a stackless or stackfull coroutine implementation?

[Didier]

I've read a bit about the difference between stackless and stackfull coroutines.

But I still don't really understand the difference. And I'm trying to know in 
which camp core.async would fall.

Anyone knows?

-- 
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.

This exception tip is a bit confusing.

[Didier]

Vector keys must be integers. Try

(assoc [] 0 :a)

A vector has keys from 0 to (count vector) pointing to elements at the same 
index. It's more like an Array list in this way.

What you're doing would need a map instead. Try

(assoc {} :a 0)

-- 
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: Can someone explains the difference between print-method and print-dup once and for all?

[Didier]

Thanks David. So if I need to extend edn to serialize custom types, I should 
extend print-method? And have it switch on print-readably? Where when true,  
prints a reabale edn literal #x/y ... for example, otherwise it prints as 
standard?

Would that be the correct way?

-- 
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: How to escape a space in a keyword?

[Didier]

Ion is a data serialization format from Amazon http://amzn.github.io/ion-docs/

One lf its supported data type is symbol, defined as: Interned, Unicode 
symbolic atoms (aka identifiers)

I interact with systems that interchange their data using ION. My systems use 
EDN though internally. Thus I need to convert from ION to EDN and back in a 
lossless manner.

If you give me ION with symbols in them, and I convert them to EDN, I need be 
able to go back to the exact same ION symbol when converting my EDN back to ION.

If I make symbols string, I lose the type info, and would convert it back to an 
ION string. This wouod break my clients.

I thought I could get away not having to build a custom representation for them 
in Clojure and EDN, and piggyback on keywords.

It now seems to me like I can still piggyback on keywords when in Clojure, 
since `keyword` and clojure.lang.Keyword appear to support full unicode.

But it seems EDN does not support full unicode serialization for them. So I've 
extended the edn serialization and deserialization so that it does.

I did so by overriding print-method for keywords so that when it prints in an 
unreadable way, it instead outputs a custom literal #myproject/keyword 
"namespace/name". And I've added a reader for this which uses keyword to get a 
Clojure keyword back.

Does any of this seem unsound to anyone?

-- 
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.

Can someone explains the difference between print-method and print-dup once and for all?

[Didier]

Thanks, but I think I need the details. It seems pr, prn and company default to 
using print-method, and print-method implementations check for *print-readably*.

So how exactly would print-dup differ?

I ask specifically in the context of serializing Clojure to EDN and back. Would 
it be best to do so with print-dup true and print-readably true? What would be 
the expected pr-str settings?

-- 
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: How to escape a space in a keyword?

[Didier]

Thanks Andy, ya I actually realized this, I'm using a custom reader literal now 
instead.

> Why are you fighting so hard to make keywords with spaces? If you need things 
> with spaces, use strings.

Why have keywords at all then? What does a space add that somehow negates the 
premise of keywords?

I see keywords over strings give you interning, namespaces, and the semantic 
that this value serves as an identifier. What's wrong with having that and a 
space as well?

Also, to be more specific to my use case. If I convert ION symbols to Clojure 
strings, I've lost information, and can no longer convert back to the same ION.

I need to do ION -> EDN -> ION in a lossless way. Piggybacking on keywords 
seemed easiest. 

-- 
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.

Can someone explains the difference between print-method and print-dup once and for all?

[Didier]

Can someone explains the difference between print-method and print-dup once 
and for all?

Regards

-- 
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: How to escape a space in a keyword?

[Didier]

Reviving an old thread. I have a case where I convert ION to Clojure, and 
ION has a SYMBOL type, which can be any UTF-8 character, including spaces. 
I though of making them keywords in Clojure, since they serve the same 
purpose, to be used as identifiers. I can create such keyword with the 
keyword function, but they don't serialize to EDN and back using the 
default printer and reader.

I'm thinking of extending the printer like tbc++ says so keywords are 
printed as (keyword "string") instead. Does anyone believe there is 
something that's going to bite me later if I do this?

On Tuesday, 13 March 2012 00:14:48 UTC-7, Andy Fingerhut wrote:
>
> Ah, my senior moment was not noticing the invalid example use of symbol in 
> the second example, which was passing strings of decimal digits to symbol. 
>  I went ahead and deleted that one.
>
> Thanks,
> Andy
>
> On Mar 13, 2012, at 12:04 AM, Andy Fingerhut wrote:
>
> Which one?
>
> (symbol 'foo)
>
> (symbol "foo")
>
> (symbol "clojure.core" "foo")
>
> I don't see it, but I'm probably having a senior moment.
>
> clojuredocs.org are editable to anyone willing to create a free account, 
> by the way.  I'm nobody special there.
>
> Andy
>
> On Mar 12, 2012, at 11:53 PM, Meikel Brandmeyer (kotarak) wrote:
>
> Hi,
>
> Am Dienstag, 13. März 2012 07:46:58 UTC+1 schrieb Andy Fingerhut:
>>
>>
>> http://clojuredocs.org/clojure_core/clojure.core/symbol
>>
>>
> And right below is an example of invalid usage.
>
> Sincerely
> Meikel
>  
>
> -- 
> 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 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: What Happened to "java -jar clojure.jar hosehead.clj" ?

[Didier]

I think overall, it makes sense to modularize clojure.

But I'm compassionate to the no internet style mindset. So I wonder if there 
could be a download on the clojure.org website which is an uberjar of Clojure 
and it's latest required dependencies? Specifically for such use case.

-- 
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: Best way to use Lein only as a build tool?

[Didier]

I guess I'm trying to do that but for a custom internal dependency management 
tool.

How would I basically hand over lein the classpath for all its other commands? 
Any way to do that? Since I have something else pulling down all dependencies 
building the classpath?

-- 
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.

Best way to use Lein only as a build tool?

[Didier]

What's the best way to use Lein only as a build tool? If I want to do my own 
dependency resolutions. Or say use tools.deps for dependency resolution, but 
Lein for all other build tasks?

-- 
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: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Didier]

>
> And it’s worth noting that Rich has said nth is “somewhat of a mistake”: 
> https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f#why-cannot-last-be-fast-on-vector
>  
> 


Well, I think this is as canonical to answering the OP as we'll get, at 
least in terms of why there's no polymorphic comb method in Clojure that 
works on everything. 

On Monday, 23 July 2018 11:53:48 UTC-7, Sean Corfield wrote:
>
> But Clojure is geared more towards professional programmers who understand 
> that different data structures have different strengths and weaknesses, and 
> who prefer to use an API that makes those strengths and weaknesses 
> explicit, rather than fooling you into doing something inefficient.  (nth 
> being a notable exception).
>
>  
>
> And it’s worth noting that Rich has said nth is “somewhat of a mistake”: 
> https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f#why-cannot-last-be-fast-on-vector
>
>  
>
> (that whole answer is worth reading, in the context of this thread)
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
> --
> *From:* clo...@googlegroups.com   > on behalf of Mark Engelberg  >
> *Sent:* Sunday, July 22, 2018 11:41:58 PM
> *To:* clojure
> *Subject:* Re: OK idea to replace conj and cons with "prepend" and 
> "append" macros that have consistent behavior and return same types as args? 
>  
> The book "Simply Scheme" teaches Scheme via a library that lets students 
> do things to either the left or right side of the list, even though the 
> operations on the right side of the list are inefficient.  That author 
> found it to be more intuitive to his students.
>
> But Clojure is geared more towards professional programmers who understand 
> that different data structures have different strengths and weaknesses, and 
> who prefer to use an API that makes those strengths and weaknesses 
> explicit, rather than fooling you into doing something inefficient.  (nth 
> being a notable exception).
>
> IMHO, a programming language for professionals will never be the ideal 
> choice for beginners, although Clojure is better than most professional 
> languages for that purpose.
>
> On Sun, Jul 22, 2018 at 7:29 PM, Christian Seberino  > wrote:
>
>>
>> Just what is it that you want to teach? Principles of computation, or 
>>> Clojure? Not the same. If the former, forget Clojure and give them a week 
>>> to work thru The Little Schemer. Then move on to clojure and the much more 
>>> complex stuff involved.
>>>
>>
>> I think you bring up a good point.
>> I wonder if we all have one of 2 mental images of what people mean by a 
>> "Clojure intro class".  Many probably mean something like a real corporate 
>> class where
>> people are trying to train developers on Clojure to get real work done.  
>>  I think more of the SICP/Scheme/MIT class where you have a lot of smart
>> people with no programming experience and you want to give them a solid 
>> academic intro.
>>
>> I agree Scheme is great for that.  However, what I find delicious is that 
>> Clojure is this >| |<--- close to being *both* a super practical 
>> language
>> *and* a better/cleaner teaching language!  This might surprise some but I 
>> actually think some things are more elegant in Clojure than Scheme!
>> For example, I like "fn" over "lambda".  Also, I like the seq abstraction 
>> over nested conses for the fundamental data structure.
>>
>> cs
>>
>>
>> -- 
>> 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 

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Didier]

 | And to be completely clear, I'm not complaining about the design decision in 
Clojure. I'm just trying to really understand what the design is, what are the 
trade-offs and where the confusion might come from.

conj is what is known as a leaky abstraction. Leaky abstractions aren't always 
bad, sometimes they are made leaky by choice. A leaky abstraction is one that 
reveals and requires you to be aware of its underlying concrete implementation.

Generally an abstraction is made leaky when the implementation details are in 
fact very important to the success of using the abstraction for real world use 
cases.

This I think was the choice made for conj. You can see that from the docstring 
itself: "The 'addition' may happen at different 'places' depending on the 
concrete type."

The docstring directly points you towards knowing that the concrete types add 
the element in different places. That knowledge is leaky.

But, its also very important, because in many real world use cases, performance 
of addition will matter, and order of addition will matter, and you'll want to 
choose the correct concrete type to get the order you want with the performance 
you need.

Generally, leaky abstractions are more annoying to use for simple use cases, 
since often you want to say, I don't care about all the little details, but as 
your use case grows, the devil sometimes shows up in thise details, and 
suddenly, that leakyness becomes a blessing.

So, did Clojure made the right choice in making conj leaky? Hard to say, and 
the answer is probably personal and opinionated. That said, I'm sure the intent 
was to force the details onto the user, and force them to be aware of their 
implications when using conj.

-- 
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: How define alias for .indexOf? (def somealias .indexOf) does not work.

[Didier]

The memfn docstring says it can be type hinted to avoid reflection. Any reason 
why it would still be slower then wrapping it in a type hinted function?

-- 
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: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Didier]

Hey Alan,

Nice job on Tupelo by the way. I do find it a bit bloated though, and 
that's why I never use it. Any reason why all the different namespace are 
still mixed together? Seem like they could each be an independent lib, like 
how the datomic namespace was split out.

On Wednesday, 18 July 2018 13:16:15 UTC-7, Alan Thompson wrote:
>
> There is also a function `glue` 
>  for 
> combining like collections:
>
>
> -
> Gluing Together Like Collections
>
> The concat function can sometimes have rather surprising results:
>
> (concat {:a 1} {:b 2} {:c 3} );=>   ( [:a 1] [:b 2] [:c 3] )
>
> In this example, the user probably meant to merge the 3 maps into one. 
> Instead, the three maps were mysteriously converted into length-2 vectors, 
> which were then nested inside another sequence.
>
> The conj function can also surprise the user:
>
> (conj [1 2] [3 4] );=>   [1 2  [3 4] ]
>
> Here the user probably wanted to get [1 2 3 4] back, but instead got a 
> nested vector by mistake.
>
> Instead of having to wonder if the items to be combined will be merged, 
> nested, or converted into another data type, we provide the glue function 
> to *always* combine like collections together into a result collection of 
> the same type:
>
> ; Glue together like collections:
> (is (= (glue [ 1 2] '(3 4) [ 5 6] )   [ 1 2 3 4 5 6 ]  ))   ; all 
> sequential (vectors & lists)
> (is (= (glue {:a 1} {:b 2} {:c 3} )   {:a 1 :c 3 :b 2} ))   ; all maps
> (is (= (glue #{1 2} #{3 4} #{6 5} )  #{ 1 2 6 5 3 4 }  ))   ; all sets
> (is (= (glue "I" " like " \a " nap!" )   "I like a nap!"   ))   ; all text 
> (strings & chars)
> ; If you want to convert to a sorted set or map, just put an empty one first:
> (is (= (glue (sorted-map) {:a 1} {:b 2} {:c 3})   {:a 1 :b 2 :c 3} ))
> (is (= (glue (sorted-set) #{1 2} #{3 4} #{6 5})  #{ 1 2 3 4 5 6  } ))
>
> An Exception will be thrown if the collections to be 'glued' are not all 
> of the same type. The allowable input types are:
>
>- 
>
>all sequential: any mix of lists & vectors (vector result)
>- 
>
>all maps (sorted or not)
>- 
>
>all sets (sorted or not)
>- 
>
>all text: any mix of strings & characters (string result)
>
>
>
> On Wed, Jul 18, 2018 at 1:13 PM, Alan Thompson  > wrote:
>
>> As someone mentioned, the functions `prepend` and `append` exist in the 
>> Tupelo library 
>> 
>>  
>> to prevent this kind of confusion:
>>
>> from the README:
>>
>> 
>> Adding Values to the Beginning or End of a Sequence
>>
>> Clojure has the cons, conj, and concat functions, but it is not obvious 
>> how they should be used to add a new value to the beginning of a vector or 
>> list:
>>
>> ; Add to the end
>> > (concat [1 2] 3);=> IllegalArgumentException
>> > (cons   [1 2] 3);=> IllegalArgumentException
>> > (conj   [1 2] 3);=> [1 2 3]
>> > (conj   [1 2] 3 4)  ;=> [1 2 3 4]
>> > (conj  '(1 2) 3);=> (3 1 2)   ; oops
>> > (conj  '(1 2) 3 4)  ;=> (4 3 1 2) ; oops
>> ; Add to the beginning
>> > (conj 1  [2 3] ) ;=> ClassCastException
>> > (concat   1  [2 3] ) ;=> IllegalArgumentException
>> > (cons 1  [2 3] ) ;=> (1 2 3)
>> > (cons   1 2  [3 4] ) ;=> ArityException
>> > (cons 1 '(2 3) ) ;=> (1 2 3)
>> > (cons   1 2 '(3 4) ) ;=> ArityException
>>
>> Do you know what conj does when you pass it nil instead of a sequence? 
>> It silently replaces it with an empty list: (conj nil 5) ⇒ (5) This can 
>> cause you to accumulate items in reverse order if you aren’t aware of the 
>> default behavior:
>>
>> (-> nil
>>   (conj 1)
>>   (conj 2)
>>   (conj 3));=> (3 2 1)
>>
>> These failures are irritating and unproductive, and the error messages 
>> don’t make it obvious what went wrong. Instead, use the simple prepend 
>> and append functions to add new elements to the beginning or end of a 
>> sequence, respectively:
>>
>> (append [1 2] 3  )   ;=> [1 2 3  ]
>> (append [1 2] 3 4)   ;=> [1 2 3 4]
>>
>> (prepend   3 [2 1])  ;=> [  3 2 1]
>> (prepend 4 3 [2 1])  ;=> [4 3 2 1]
>>
>> Both > style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation
>>
>

-- 
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 

Re: OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Didier]

>
> Concat does the job except for keeping the input collection type.  It will 
> seq anything you throw at it.
>

But that should not matter to a beginner. I mean, if you are at the point 
where you are teaching people the differences between the data structures, 
than teach them the difference between list, vector and seq, and that 
includes the behavior of conj. Otherwise, if not for performance, there's 
no difference between these, they're all ordered collections of items.


On Wednesday, 18 July 2018 04:04:36 UTC-7, Gary Trakhman wrote:
>
> Concat does the job except for keeping the input collection type.  It will 
> seq anything you throw at it.
>
> There's a general trade-off here. When I started working in ocaml recently 
> I was taken aback that the List.map call we used constantly would have to 
> build the new list backwards in linear time, and then reverse it in linear 
> time, with some crazy stack expansions as an optimization for smaller 
> lists. I've said stuff like 'i would be happy to have a map call that 
> changed type on me sometimes', but honestly I've never had to dig that deep 
> for performance, and when I do, it's to switch to a more async-incremental 
> Pipe thing analogous to core.async chans.
>
> On Wed, Jul 18, 2018, 3:16 AM Didier > 
> wrote:
>
>> It's never a good idea to use the wrong data structure for the job.
>>
>> And thus Clojure takes the stance that it won't make bad ideas easy for 
>> you to use. Yet, it will never prevent you from doing anything.
>>
>> If you want to do something bad, you'll need to get your own hands dirty.
>>
>> That's why slow data structure access functions don't exist as standard. 
>> That's why data transforms are lazy by default. And why the non lazy 
>> variant (transducers) do loop fusion for you. That's why mutability is ugly 
>> and requires you to wrap things in extra verbosity. That's why OOP isn't 
>> there, and forces you to use the host interop if you want it. That's why 
>> there's only recursive loops. Etc.
>>
>> The Clojure standard lib is opinionated. It's not trying to make 
>> everything easy and convenient. It's trying to make things simple to reason 
>> about, and promote Rich Hickeys opinion of what is a good idea, and what 
>> isn't.
>>
>> But, it can afford to be this way, because it made itself a Lisp, meaning 
>> it gave you all the power needed to disagree and make your own core, which 
>> follows your own opinions of good and bad.[1]
>>
>> Now, I recommend that everyone should have a core library of their own 
>> that they keep around for cases like this, where they disagree.
>>
>> And for beginners, I mean, what are you trying to teach them? What 
>> problem requires them to add items to the beginning and end of an ordered 
>> collection?
>>
>> Anyways, my advice is to teach them concat. It's even nicer then 
>> append/prepend. You just give it the arguments where you want them to go.
>>
>> (concat [1] [2 3])
>>
>> (concat [1 2] [3])
>>
>> And it works for any type of ordered collections, even arrays.
>>
>> Also, this blog I think does a great job at teaching all this to a 
>> beginner 
>> https://medium.com/@greg_63957/conj-cons-concat-oh-my-1398a2981eab
>>
>>
>>
>> [1] Except for reader macros. Rich didn't want you to be able to change 
>> the whole program syntax in unconstrained ways. That's probably a good 
>> thing to at least keep the foundation universal accross code bases.
>>
>> -- 
>> 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 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.

OK idea to replace conj and cons with "prepend" and "append" macros that have consistent behavior and return same types as args?

[Didier]

It's never a good idea to use the wrong data structure for the job.

And thus Clojure takes the stance that it won't make bad ideas easy for you to 
use. Yet, it will never prevent you from doing anything.

If you want to do something bad, you'll need to get your own hands dirty.

That's why slow data structure access functions don't exist as standard. That's 
why data transforms are lazy by default. And why the non lazy variant 
(transducers) do loop fusion for you. That's why mutability is ugly and 
requires you to wrap things in extra verbosity. That's why OOP isn't there, and 
forces you to use the host interop if you want it. That's why there's only 
recursive loops. Etc.

The Clojure standard lib is opinionated. It's not trying to make everything 
easy and convenient. It's trying to make things simple to reason about, and 
promote Rich Hickeys opinion of what is a good idea, and what isn't.

But, it can afford to be this way, because it made itself a Lisp, meaning it 
gave you all the power needed to disagree and make your own core, which follows 
your own opinions of good and bad.[1]

Now, I recommend that everyone should have a core library of their own that 
they keep around for cases like this, where they disagree.

And for beginners, I mean, what are you trying to teach them? What problem 
requires them to add items to the beginning and end of an ordered collection?

Anyways, my advice is to teach them concat. It's even nicer then 
append/prepend. You just give it the arguments where you want them to go.

(concat [1] [2 3])

(concat [1 2] [3])

And it works for any type of ordered collections, even arrays.

Also, this blog I think does a great job at teaching all this to a beginner 
https://medium.com/@greg_63957/conj-cons-concat-oh-my-1398a2981eab



[1] Except for reader macros. Rich didn't want you to be able to change the 
whole program syntax in unconstrained ways. That's probably a good thing to at 
least keep the foundation universal accross code bases.

-- 
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: What is the minimal Emacs config for practical Clojure development?

[Didier]

There's also inf-clojure, which is pretty minimal.

-- 
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.

core.async buffered channel behavior

[Didier]

I think its due to ctrl+c, not sure what it actually does, but maybe it didn't 
actually kill the blocked thread?

-- 
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.

Spaces between brackets?

[Didier]

Hi,

I've noticed that it seems you can omit the space between brackets, and 
everything still parses as normal. I tend to prefer doing that in some 
instances, for example:

(fn[a b] (+ a b))

It seems to hold in all scenarios, for example:

[1 '...[2 3]]

Yields [1 '... [2 3]]

And

[1[2[3]]]


Yields [1 [2 [3]]]

Or

(defn add[a b] (+ a b))

Etc.

So my question is: *Is this an official parse rule for Clojure and its 
dialects like ClojureScript, ClojureCRL and EDN, or the fact this works is 
accidental, and shouldn't be relied on?*

-- 
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.

[ANN] zprint 0.4.9 -- super fast startup with native image

[Didier]

Can it run on Linux too? Or MacOS only?

-- 
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: Asynchronous http poll

[Didier]

I think I want to simplify some things.

Normally, client/server async is implemented by the client/server framework. 
What happens is the interchange of messages between the client and server 
through the http connection on the socket is made non-blocking. But the entire 
request/response still happens within the context of a single http connection.

This often allows for the server to take in many more requests, and for the 
client to overlap other processing while waiting. That's because open IO 
operations are cheaper then open threads. So modern hardware support many more 
concurrent open connections on a socket then it does open threads.

If that's what you want, you need to move to a different client/server 
framework that supports non-blocking exchanges, such as Netty in the Java world.

If you want to avoid moving framework, or your operations are going to be 
really long, or you want to survive network drop outs. Then you can go for 
something more like what you were trying to go for.

In that case, you need to choose between push and pull.

If pull, you want a distributed map as I said, which is often known as a 
database. A sql table can do, a nosql key/value store also works. I'm a fan of 
DynamoDB for this. Ideally, you want your distributed map to have equal scaling 
capability as your server APIs will, otherwise it will become a bottleneck.

You can also go with a distributed queue, like RabbitMQ or AWS SQS. This allows 
the client to use a reactor evented response handling. Instead of having the 
client poll your get API to know if a response is availaible. You will put a 
message on the queue saying GUID-X is now done. And your client will work 
through the queue, and for every msg in it, it will poll you for the result.

If you want Push, you need the client to expose an endpoint to be contacted on 
when done. You can do this easily with AWS SNS for example. This could mean the 
client exposes a call-when-done(guid, result) API. It tells your server about 
it, and when you are done, you send a request to that API to notify the client. 
It allows the client to know right away that its done, and saves it the CPU 
work of having to poll. But it gets complicated if you fail to reach the 
client's endpoint, what happens? So with push, you can often miss a response. 
To avoid that, people often offer both pull and push.

So my practical recommendation to you would be to first look into a 
non-blocking client/server framework like Netty. Maybe that's all you need.

If not, then look into using DynamoDB or SQS or SNS or similar products.

-- 
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: Asynchronous http poll

[Didier]

Oh, I forgot something important.

If you're hoping to have multiple hosts, and run this application in a 
distributed way, you really should not do this that way. Things get a lot 
more complicated. The problem is, your request queue is local to a host. So 
if the client creates the Future on S1 on host A, and calls for 
get-s1-result, and he is routed to host B? That Future will be missing.

So what you need is to turn that atom map of Futures into a distributed 
one. You could still have the Future atom map, but as the last step of each 
Future, you need to update the distributed map with the result or error. 
And if you want statuses, in your loop, you should also update it for 
status. So on get-s1-result, you just check the value of that distributed 
map. Each host still processes their own share of requests, but the 
distributed map exposes their result and processing status to all other 
hosts.

There's many other ways to handle this issue. For example, I believe you 
can route the client to a direct connection to the particular host who 
handled S1, so that calls to get-s1-result go to that specific host. The 
downside is, it gets harder to evenly distribute the polls. Also, it takes 
more complex infrastructure to do that, all hosts must have their IPs 
exposed to the clients for example. Another way, is the VIP might be able 
to support smarter routing, based on some indicator, or you need to use a 
Master host, which delegates back, and has that logic itself.

An alternate way, is to let go of the polling, and instead have a push 
model. Your server could call the client to tell it the request is handled. 
This also has its own complexities and trade offs.

Anyways, in a distributed environment, async and non-blocking becomes quite 
a bit more complex.


On Monday, 14 May 2018 17:35:39 UTC-7, Didier wrote:
>
> Its hard to answer without additional detail.
>
> I'll make some assumptions, and answer assuming those are true:
>
> 1) I assume your S1 API is blocking, and that each request to it is 
> handled on its own thread, and that those threads come form a fixed size 
> thread pool with a size of 30.
>
> 2) I assume that S2 is also blocking, and that it returns a promise when 
> you call it. And that you need to keep polling another API, that I'll call 
> get-s2-result which takes the promise, and is also blocking, and returns 
> the result, error, or that its still not available.
>
> 3) I assume you want to turn your blocking S1 API, into a pseudo 
> non-blocking behavior.
>
> 4) Thus, you would have S1 return a promise. When called, you do not 
> process the request, but you queue the request in a "to be processed" 
> queue, and you return a promise that eventually, the request will be 
> processed and will have a value, or an error.
>
> 5) Similarly, you need a way for the client to check the promise, thus you 
> will also expose a blocking API that I will call get-s1-result which takes 
> the promise and returns either the result, an error, or that it's not 
> available yet.
>
> 6) Your promise will take the form of a GUID that uniquely identifies the 
> queued request.
>
> 7) This is your APIs design. Your clients can now start work and 
> integration with your APIs, while you implement its functionality.
>
> 8) Now you need to implement the queuing up of requests. This is where you 
> have options, and core.async is one of them. I do agree with the advice of 
> not using core.async unless simpler tools don't work. So I will start with 
> a simpler tool: Future, and a global atom map from promise GUID to request 
> map.
>
> 9) So you create a global atom, which contains a map from GUID -> FUTURE.
>
> 10) On every request to S1, you create a new GUID and Future, and you 
> swap! assoc the GUID with the Future.
>
> 11) The Future is your request handler. So in it, you synchronously handle 
> the request, whatever that means for you. So maybe you do some processing, 
> and then you call S2, and then you loop, and every 100ms, in the loop, you 
> call get-s2-result until it returns an error or a result. Every time you 
> loop, you check that the time its been since the time you started looping 
> is not more then X timeout, so that you don't loop forever. If you 
> eventually get a result or an error, you handle them however you need too, 
> and eventually your future itself returns a result or an error. Its 
> important you design the future task to timeout eventually. So that you 
> don't leak futures that get stuck in infinite loops. So you must be able to 
> deterministically know that the future will finish.
>
> 12) Now you implement get-s1-result. Whenever it is called, you get the 
> future from the global atom map of futures, and you call future-done? on 
> it. If false, you return that the result

Re: Asynchronous http poll

[Didier]

Its hard to answer without additional detail.

I'll make some assumptions, and answer assuming those are true:

1) I assume your S1 API is blocking, and that each request to it is handled 
on its own thread, and that those threads come form a fixed size thread 
pool with a size of 30.

2) I assume that S2 is also blocking, and that it returns a promise when 
you call it. And that you need to keep polling another API, that I'll call 
get-s2-result which takes the promise, and is also blocking, and returns 
the result, error, or that its still not available.

3) I assume you want to turn your blocking S1 API, into a pseudo 
non-blocking behavior.

4) Thus, you would have S1 return a promise. When called, you do not 
process the request, but you queue the request in a "to be processed" 
queue, and you return a promise that eventually, the request will be 
processed and will have a value, or an error.

5) Similarly, you need a way for the client to check the promise, thus you 
will also expose a blocking API that I will call get-s1-result which takes 
the promise and returns either the result, an error, or that it's not 
available yet.

6) Your promise will take the form of a GUID that uniquely identifies the 
queued request.

7) This is your APIs design. Your clients can now start work and 
integration with your APIs, while you implement its functionality.

8) Now you need to implement the queuing up of requests. This is where you 
have options, and core.async is one of them. I do agree with the advice of 
not using core.async unless simpler tools don't work. So I will start with 
a simpler tool: Future, and a global atom map from promise GUID to request 
map.

9) So you create a global atom, which contains a map from GUID -> FUTURE.

10) On every request to S1, you create a new GUID and Future, and you swap! 
assoc the GUID with the Future.

11) The Future is your request handler. So in it, you synchronously handle 
the request, whatever that means for you. So maybe you do some processing, 
and then you call S2, and then you loop, and every 100ms, in the loop, you 
call get-s2-result until it returns an error or a result. Every time you 
loop, you check that the time its been since the time you started looping 
is not more then X timeout, so that you don't loop forever. If you 
eventually get a result or an error, you handle them however you need too, 
and eventually your future itself returns a result or an error. Its 
important you design the future task to timeout eventually. So that you 
don't leak futures that get stuck in infinite loops. So you must be able to 
deterministically know that the future will finish.

12) Now you implement get-s1-result. Whenever it is called, you get the 
future from the global atom map of futures, and you call future-done? on 
it. If false, you return that the result is not available yet. If it is 
done, you deref the future, swap! dessoc the mapEntry for it from your 
global atom, and return the result or error.

The only danger of this approach, is that the Future queue is unbounded. So 
what happens is that clients can call S1 and get-s1-result with at most 30 
concurrent request. That's because I assumed your APIs are blocking and 
bounded on a shared fixed thread pool of size 30.

Now say it takes you 1 second to process on average an S1 request, so your 
future will finish on average in 1 second, and you time them out at 5 
seconds. Now say we go for worst case scenario. This means say S2 is down, 
so all requests take the max of 5 seconds to be handled. Now say your 
clients are also maxing out your concurrency for S1, so you get around 30 
concurrent request constantly. Say S1 takes 100ms to return the promise. 
What you get is this:

* Every second, you are creating 300 Future, because every 100ms, you 
process 30 new S1 requests.

So say we are at the beginning, you have 0 Future, one second later, you 
have 300, 5 second later, you have 1500, but your first 300 timeout, so you 
end up with 1200. At the 6th second, you have 1200 again, since 300 more 
were queued, but 300 more timed out, and from this point on, every second 
you have 1200 open Futures, with a max of 1500.

Thus you need to make sure you can handle 1500 open threads on your host.

Indirectly, this stabilizes because you made sure your Future tasks time 
out at 5 second, and because your S1 API is itself bounded to 30 concurrent 
request max.

If, you'd prefer to not rely on the bound of the S1 requests, and you have 
a hard time knowing the timing of your S1, you can keep track of the count 
of queued Future, and on a request to S1 where the count is above your 
bound, you return an error, instead of a promise, asking the client to wait 
a bit, and retry the call in a bit, where you have more resourced available.

I hope this helps.

On Tuesday, 8 May 2018 13:45:00 UTC-7, Brjánn Ljótsson wrote:
>
> Hi!
>
> I'm writing a server-side (S1) function that initiates an action on 
> another server (S2) 

Re: Custom core.async go threadpools? Using go parking for heavy calculation parallelism throughput?

[Didier]

This seems well suited for tesser 
https://github.com/aphyr/tesser/blob/master/README.markdown

Or you could just look at using fold 
https://clojure.org/reference/reducers#_reduce_and_fold

-- 
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.

Spy - Clojure / ClojureScript library for stubs, spies and mocks

[Didier]

This looks cool for validation.

-- 
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: Clojure/flutter

[Didier]

Honestly, I doubt any project will have more backing then Graal's native image.

So I think its the best shot at Clojure native we've ever had, and probably the 
ideal one at that, since it'll boast all existing libraries.

What could help is to then look at compiler options for Clojure that could help 
leverage native image, and lower the restrictions imposed by native image.

-- 
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: Clojure/flutter

[Didier]

The thing about Clojure->native, is that Clojure needs a pretty powerful 
runtime.

So we'd need to piggy back on something native that similarly has a strong 
runtime. Common Lisp maybe, or Go.

I'd vote for Go.

-- 
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.

Iterate through transient map?

[Didier]

Don't think so.

But the conversion back and forth is O(1). So it shouldn't affect performance.

-- 
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: Clojurists Together is funding CIDER and ClojureScript from May-July

[Didier]

Hey, sweet.

I'm really liking Clojurist together, and I appreciate how its able to give 
competitive-ish salaries to fund the work. Hopefully it grows bigger, but 
even if it remain small and cozy, I think it can bring a lot of value.


On Wednesday, 25 April 2018 14:32:34 UTC-7, Daniel Compton wrote:
>
> Hi folks
>
> Clojurists Together is funding Bozhidar Batsov and Mike Fikes $5,400USD 
> each to work on CIDER and ClojureScript (respectively) from May-July. You 
> can read more about the work they're doing at in the announcement 
> .
>
> We couldn't have done any of this without the support of our company and 
> developer members . If you 
> like the projects that we've been funding, consider joining as a company 
>  or developer 
>  member so we can keep 
> funding projects that are important to the Clojure ecosystem.
>
> Thanks!
>

-- 
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: Understanding GraalVM and Clojure

[Didier]

https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md has 
some details of the limitations around native-image.

Native-image is probably the more interesting part for Clojure, but I'm not 
sure it will fully work given those current limitations.

On Thursday, 19 April 2018 03:00:14 UTC-7, Khalid Jebbari wrote:
>
> Hello,
>
> Oracle has just announced GraalVM 1.0 release candidate: 
> https://blogs.oracle.com/developers/announcing-graalvm
>
> It mentions a few JVM-based language but not Clojure (maybe just because 
> of popularity).
> - Does it mean Clojure is not "compatible" with GraalVM ? 
> - Does it mean Clojure needs to be reimplemented in terms of GraalVM's 
> Truffle framework ?
> - Does it mean Clojure can be run as a native binary with fast startup 
> time and minimized memory footprint ?
>
> If someone with some knowledge could explain to me the relationships 
> between Clojure and GraalVM ? Bonus points if Alex Miller answers and share 
> the plans, if any, about their integration/interaction.
>
> Thanks a lot in advance. really curious to understand more.
>

-- 
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: [ANN] clj-new -- creating new Clojure projects using the clj CLI

[Didier]

Ah, awesome.

I guess I'm starting to think, it would be great if clj supported something 
like:

clj --install alias-name alias-url

So maybe in a repo, you could put a file of a given convention in the root 
with a common name. Clj could pull it, it would contain a clj alias in it, 
and clj would auto add it to your deps.edn file as an alias. You could add 
a -g option to add it to your global deps.edn, if you wanted to "install" 
it globally.

Nothing else would happen.

But then, you could run your newly "installed" clojure program by doing:

clj -A:alias-name args ...

If you omit the alias name, it could default to something specified in the 
alias file.

What that alias url resolves too, I'm not sure. I'm thinking a git url to 
an alias-install.edn file which contains something like:

{:default-alias-name alias-map-to-add-as-an-alias}


And similarly, you could add:

clj --uninstall alias-name

And it would remove the alias from your deps.edn, or if given -g, from your 
global deps.edn config.

Ideally, it would remember the alias-url in the deps.edn file, so you could 
run:

clj --update alias-name

Maybe there could even be a kind of global url repo, with a list of 
registered alias names, so one could do:

clj --install alias-name

And it would know where to pull the alias-install.edn file from based on 
some global repo of distributed Clojure programs.

I'd love this. Would seem like a pretty great way to deliver Clojure 
programs, which does not require any bash script, adding anything to your 
PATH, or having to edit a file.

So for clj-new, ideally one could do:

clj --install -g clj-new

And clj would take care of adding the alias for it in my global deps.edn.

But at the very least, without the alias registry, once could simply do:

clj --install -g clj-new https://github.com/seancorfield/clj-new.git

Which would auto-install the alias from a top level alias-install.edn file 
inside the repo.

Something of the sort.


On Tuesday, 17 April 2018 20:06:16 UTC-7, Sean Corfield wrote:
>
> clj-new -- https://github.com/seancorfield/clj-new 
>
>  
>
> This will generate new projects for you, either based on `clj`, or from 
> any existing Leiningen or Boot template (or, I hope in the future, 
> `clj-template` projects!).
>
>  
>
> You'll probably want to add clj-new as an alias in your 
> ~/.clojure/deps.edn like this:
>
>  
>
> {:aliases
>
> {:new {:extra-deps {seancorfield/clj-new
>
>  {:git/url "https://github.com/seancorfield/clj-new;
>
>   :sha "492bb2e7ad7373a8b5958124a86cddc4c7a123d5"}}
>
> :main-opts ["-m" "clj-new.create"]}}
>
> ...}
>
>  
>
> Create a basic application:
>
>  
>
> clj -A:new app myname/myapp
>
> cd myapp
>
> clj -m myname.myapp
>
>  
>
> Run the tests:
>
>  
>
> clj -A:test:runner
>
>  
>
> Yes, the `deps.edn` generated from the `app` (and `lib`) built-in template 
> includes aliases to include your `test` folder, add `test.check` as a 
> dependency, and bring in and run Cognitect's `test-runner`
>
>  
>
> The project name should either be a qualified Clojure symbol or a 
> multi-segment name -- single segment project names are not allowed!
>
>  
>
> For a qualified Clojure symbol, the first part is typically your GitHub 
> account name or your organization's domain reversed, e.g., `com.acme`, and 
> the second part is the "local" name for your project (and is used as the 
> name of the folder in which the project is created).
>
>  
>
> For a multi-segment project name, such as `foo.bar`, the folder that will 
> be created would be called `foo.bar` and will contain `src/foo/bar.clj`.
>
>  
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>  
>

-- 
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.

[ANN] clj-new -- creating new Clojure projects using the clj CLI

[Didier]

Hum, cool.

First time I realize that clj could become the npm of Clojure.

Couldn't you pull leiningen down from it in a similar fashion? And have a lein 
alias?

-- 
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: Using Clojure for public facing system in a bank - code security scanning - any luck?

[Didier]

I'd love an independent penetration and security audit of the Clojure codebase. 
Especially around the socket repl in a localhost restricted way and making sure 
its not exploitable.

I wonder how much it costs, and if Clojurist together could have one funded.

-- 
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: Anyone spent time with Kawa Scheme?

[Didier]

Haven't tried Kawa, and my only other Lisp experience is Emacs Lisp.

That said, I think Clojure as a Lisp differentiate itself from other Lisps in 
that all its data-structures are built on abstractions. They default to be 
immutable in a performant and low memory profile way. Its got great added 
concurrency constructs like STM, CSP, Atom, Futures, Promises, Delays, etc. Its 
syntax includes very convenient default data-literals that has contributed to 
it having a culture of data-driven logic. EDN is great for serialization of 
code and data. It has powerful support for lazy evaluation, as well as strict. 
Finally, its interop with Java is excellent.

So, I don't know much about scheme and Kawa, but I suspect you'd have to build 
a lot to get all this back.

-- 
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: Anyone spent time with Kawa Scheme?

[Didier]

I'd recommend you try some of the startup optimizations for the JVM that zprint 
does: 
https://github.com/kkinnear/zprint/blob/master/doc/filter.md#we-all-know-that-clojure-startup-is-so-slow-that-this-will-not-work

With it, they've managed to get the Clojure zprint filter to start faster then 
the equivalent ClojureScript one. 

-- 
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.

Proper way to write EDN file, after production bug

[Didier]

Ya, I'd write a wrapping fn, like ->edn which internally binds everything to 
what it should be, maybe even declares some extra print defmethod if you need 
custom edn serialization, and returns the edn.

-- 
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.

What if ^:const could inline everything before macroexpanssion?

[Didier]

I was hoping that ^:const would be able to inline any symbol value and that 
it would do so before macroexpanssion so that:

(def ^:const bar {:a 100})

(defmacro foo
  [x]
  (:a x))

(foo bar)

Would return:

100

The same way that:

(foo {:a 100})

does.

Then I read that ^:const only inlines primitive values (which disappointed 
me), but so I thought that this would work:

(def ^:const bar 100)

(defmacro foo
  [x]
  (+ 10 x))

(foo bar)

but that also doesn't work.

So now I believe that ^:const inlines after macroexpanssion.

I feel it would be really cool to be able to factor some input to macros 
into constants, is this something I could open a ticket for, to extend 
^:const so it can inline all literal values and also does the inlining 
before macroexpanssion so that the above would work?

-- 
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: Any better client then telnet for connecting to a socket repl server?

[Didier]

Okay, for anyone else coming here and looking, you must absolutely try out 
Unravel https://github.com/Unrepl/unravel

Its a command line tool that you install through npm (implemented in 
ClojureScript cool!), and then you can just do:

unravel  

>From your terminal, and it will connect to any standard Clojure 1.8+ socket 
repl and give you a Repl with full emacs like readline, multi-line support, 
auto-complete, and eldoc style instant documentation. No need to add any 
extra dependencies to your Clojure project or setup anything more then just 
activate the socket repl.

Frankly its amazing, and I think everyone who needs to connect to a socket 
repl should give it a go.

P.S.: Also shout out to Spiral https://github.com/Unrepl/spiral, which is 
an emacs package for connecting to a Clojure 1.8+ socket REPL which gives 
you almost as many features as Cider does with nRepl.

On Friday, 2 March 2018 17:49:45 UTC-8, Didier wrote:
>
> I want to connect to a Clojure socket repl server, but telnet is a really 
> terrible repl experience. Anyway I can have a better client to connect to 
> it that would have some better support for history, backspace, maybe even 
> some auto-complete, highlight, etc. Whatever I can get over telnet?
>
> Thanks
>

-- 
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: Macro argument evaluation, and function return value evaluation?

[Didier]

Well, I'm still interested in the above questions, but now I realized that 
spec is even harder to extend, since s/keys doesn't even truly take a 
standard map of keys and vectors, the vector can have an `or` in it, which 
is a non standard or, so a default eval does not handle it properly.

Hopefully the next version of spec might make this easier. Maybe I wish 
spec followed the data > function > macro philosophy, and that took regular 
clojure datastructures instead of this custom DSL it currently uses.

On Monday, 12 March 2018 20:06:43 UTC-7, Didier wrote:
>
> I feel these have been asked many times, but no answers I could find was 
> complete, or satisfactory.
>
> 1) How do you, within a macro, choose to evaluate an argument? So imagine 
> I wanted a macro which had applicative order of evaluation? Not a macro 
> that returns a function which will be evaluated in applicative order, but 
> actually evaluating the argument inside the macro, to resolve its value, 
> whether it be part of a local, a symbol pointing to a var inside a 
> namespace, or a literal value?
>
> I can only think of:
>
> (defmacro applicative-order
>   [& args]
>   (map eval args))
>
> This works with global vars (def and defn), and it works with literal 
> values, but not with locals.
>
> My intuition tells me there's just no way to use locals inside a macro, 
> since the macro is expanded before the locals are created.
>
> 1.1) Is it true that this will always work with globals and literal values?
>
> 1.2) Is there a safer way then using eval, which would similarly work with 
> globals as well as literal values?
>
> 2) How can I force evaluation of a function's return value?
>
> My intuition was, since I want applicative order of evaluation, to just 
> use a function, but a function will return the code unevaluated.
>
> (defn applicative-order
>   [& args]
>   `(~@args))
>
> This works with globals, locals and literal values, but it returns 
> unevaluated code.
>
> So I thought about:
>
> (defn applicative-order
>   [& args]
>   (eval `(~@args)))
>
> This works, and my intuition tells me its totally fine, apart that I want 
> to be sure not to use it with input from a user/file/io.
>
> 2.1) Is there any other way then using eval to do this?
>
> 2.2) Is there anything problematic with using eval like this? Any caveats 
> with eval apart from input safety? Like situation where its missing 
> environment data and thus fails to work as expected?
>
> REMARKS:
>
> Now you might wonder why all this is needed, well it turns out if you want 
> to compose a macro, it can be quite tricky, and something like the above 
> helps. Which macro do I want to compose? Well, in my case, s/keys macro 
> from clojure.spec. If I want to create a spec from a map as such:
>
> (def foo {:req [::a ::b]})
> (let [bar {:req [::x ::y]}]
>   (s/combine-keys foo bar {:req [::baz]})
>
> Thank You.
>

-- 
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: How to validate date (YYYYMMDD) using clojure

[Didier]

(defn valid-mmdd?
  [date]
  ;; Here's the code that you would use in Java, but using Clojure interop, 
which needs to return true/false if valid.
  ;; So an example:
  (try (let [format (java.time.format.DateTimeFormatter/ofPattern 
"MMdd")]
 (java.time.LocalDate/parse date format)
 true)
   (catch java.time.format.DateTimeParseException e
 false)))

(s/def ::mmdd valid-mmdd?)

Now ::mmdd is a spec for strings that formats as MMdd.

On Monday, 12 March 2018 19:04:43 UTC-7, bijay paudel wrote:
>
> Any idea how can I use in Clojure spec?
>
> Thanks!
> Bijay
>
> On Mon, Mar 12, 2018 at 9:02 PM, Didier <did...@gmail.com > 
> wrote:
>
>> Do it as you would in Java, using Clojure/Java interop.
>>
>> If you paste the Java code for how you'd do it, we can help you convert 
>> it to Clojure interop code.
>>
>>
>> On Monday, 12 March 2018 15:28:27 UTC-7, pbi...@gmail.com wrote:
>>>
>>> I am java certified professional.Currently  I am working  Clojure I am 
>>> still learning clojure.
>>> I am trying to validate date ( MMDD) using clojure. Any one have 
>>> idea how can I validate?
>>>
>>> Thanks!
>>> Bijay
>>>
>> -- 
>> 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 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.

Macro argument evaluation, and function return value evaluation?

[Didier]

I feel these have been asked many times, but no answers I could find was 
complete, or satisfactory.

1) How do you, within a macro, choose to evaluate an argument? So imagine I 
wanted a macro which had applicative order of evaluation? Not a macro that 
returns a function which will be evaluated in applicative order, but 
actually evaluating the argument inside the macro, to resolve its value, 
whether it be part of a local, a symbol pointing to a var inside a 
namespace, or a literal value?

I can only think of:

(defmacro applicative-order
  [& args]
  (map eval args))

This works with global vars (def and defn), and it works with literal 
values, but not with locals.

My intuition tells me there's just no way to use locals inside a macro, 
since the macro is expanded before the locals are created.

1.1) Is it true that this will always work with globals and literal values?

1.2) Is there a safer way then using eval, which would similarly work with 
globals as well as literal values?

2) How can I force evaluation of a function's return value?

My intuition was, since I want applicative order of evaluation, to just use 
a function, but a function will return the code unevaluated.

(defn applicative-order
  [& args]
  `(~@args))

This works with globals, locals and literal values, but it returns 
unevaluated code.

So I thought about:

(defn applicative-order
  [& args]
  (eval `(~@args)))

This works, and my intuition tells me its totally fine, apart that I want 
to be sure not to use it with input from a user/file/io.

2.1) Is there any other way then using eval to do this?

2.2) Is there anything problematic with using eval like this? Any caveats 
with eval apart from input safety? Like situation where its missing 
environment data and thus fails to work as expected?

REMARKS:

Now you might wonder why all this is needed, well it turns out if you want 
to compose a macro, it can be quite tricky, and something like the above 
helps. Which macro do I want to compose? Well, in my case, s/keys macro 
from clojure.spec. If I want to create a spec from a map as such:

(def foo {:req [::a ::b]})
(let [bar {:req [::x ::y]}]
  (s/combine-keys foo bar {:req [::baz]})

Thank You.

-- 
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: How to validate date (YYYYMMDD) using clojure

[Didier]

Do it as you would in Java, using Clojure/Java interop.

If you paste the Java code for how you'd do it, we can help you convert it 
to Clojure interop code.

On Monday, 12 March 2018 15:28:27 UTC-7, pbi...@gmail.com wrote:
>
> I am java certified professional.Currently  I am working  Clojure I am 
> still learning clojure.
> I am trying to validate date ( MMDD) using clojure. Any one have idea 
> how can I validate?
>
> Thanks!
> Bijay
>

-- 
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: Developing in Clojure with Emacs: Mastering the Keyboard

[Didier]

I'd second spacemacs, just make sure you go Holy and use Ivy.

Helm I find is way too slow. And with Evil mode, you are now learning 3 things 
at once, Clojure, Emacs and Vim. Unless you already master Vim, then you can go 
Evil.

-- 
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.

[ANN] org.clojure/core.cache & org.clojure/core.memoize 0.7.1 released!

[Didier]

Awesome, thanks for taking the lead and maintaining some of these awesome libs. 

-- 
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.

Any better client then telnet for connecting to a socket repl server?

[Didier]

I want to connect to a Clojure socket repl server, but telnet is a really 
terrible repl experience. Anyway I can have a better client to connect to 
it that would have some better support for history, backspace, maybe even 
some auto-complete, highlight, etc. Whatever I can get over telnet?

Thanks

-- 
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.