Re: Efficient Predicate Dispatch [was ANN: Logos v0.6]

2018-11-19 Thread Aleš Roubíček 
It was promoted to contrib since then. 
https://github.com/clojure/core.match/wiki/Crazy-Ideas 
and https://github.com/clojure/core.match are links you are looking for. 

On Monday, November 19, 2018 at 9:50:20 AM UTC+1, Khalid Jebbari wrote:
>
> https://github.com/swannodette/match/wiki/Crazy-Ideas 
> 
>  is 
> 404, as well as https://github.com/swannodette/match 
> 
>
> On Thursday, April 14, 2011 at 5:25:48 PM UTC+2, David Nolen wrote:
>>
>> When things begin to get recursive you may be on the right track :D
>>
>> Initially I was going to implement Nominal Logic Programming for Logos a 
>> la William Byrd's dissertation, but I realized that his implementation 
>> requires pattern matching. All the pattern matching libs I've seen thus far 
>> for Clojure are too naive and too slow. Even more importantly pattern 
>> matching is subsumed by predicate dispatch (CiteSeerX — Efficient 
>> Predicate Dispatching 
>> ).
>>
>> Rich Hickey mentioned many moons ago that he'd like to see a predicate 
>> dispatch implementation for Clojure that didn't have the kind of hardwiring 
>> found in the Chambers/Chen paper. He suggested investigating Datalog. After 
>> much reading, I've decided that a runtime in-memory Datalog that handles 
>> dispatching is going to be too slow for many useful scenarios (an efficient 
>> Datalog based on Binary Decision Diagrams might be possible, but this is an 
>> incredibly complex undertaking in itself, meh).
>>
>> What we want is Standard MLs efficient compilation from decision diagrams 
>> to switch statements (CiteSeerX — Optimizing Pattern Matching 
>> ). 
>> However Standard ML (Haskell, OCaml, Scala as well) pattern-matching has 
>> issues with order among other things (Programming in Standard ML 
>> ).
>>
>> What if we allow a logic engine to drive the compilation of the decision 
>> diagram? This would be done by users mapping logic predicates to Clojure 
>> predicate functions. Relationships between predicates can be added to the 
>> logic engine allowing compilation to produce a very efficient decision 
>> diagram. Nothing is hard coded, everything is driven by the kinds of 
>> predicates and relationships between predicates that a user actually cares 
>> about.
>>
>> All this is to say that this means Logos needs the ability to load 
>> database of facts, index those facts, and to accept new facts and 
>> relationships and update accordingly. So this going to happen sooner rather 
>> then later.
>>
>> I welcome any feedback from anyone who has thoughts on this approach to 
>> implementing predicate dispatch efficiently!
>>
>> Some thoughts on what this might look like is evolving here, 
>> https://github.com/swannodette/match/wiki/Crazy-Ideas.
>>
>> David
>>
>> On Mon, Apr 11, 2011 at 3:08 PM, David Nolen  wrote:
>>
>>> On Mon, Apr 11, 2011 at 2:01 PM, Vagif Verdi  wrote:
>>>
 Can it be used as an inference (rule) engine ?
>>>
>>>
>>> If you mean in the same way that you can build inference (rule) engines 
>>> in Prolog - I don't see why not.
>>>
>>> However there is a bit of work to be done in order to make building 
>>> efficient rule engines easier:
>>>
>>> * Be able to load a database (aka Clojure collection) of facts
>>> * Indexing of facts
>>> * Intelligently use indexed facts
>>>
>>> Currently I'm a bit more interested in exploring type inference (via 
>>> nominal logic) so I'm not sure when exactly I'll get to these, tho I'll 
>>> gladly take patches from people who want such features sooner rather than 
>>> later :)
>>>
>>> David
>>>
>>
>>

-- 
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: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

2018-01-28 Thread Aleš Roubíček 
In Lumo case there is heavy optimisation of startup time in not loading 
CLJS from JS sources at all. They use V8 Startup Snapshots. 
See https://anmonteiro.com/2016/11/the-fastest-clojure-repl-in-the-world/ 
for more details.

Dne sobota 15. července 2017 0:20:28 UTC+2 Didier napsal(a):
>
> This link: 
> https://dev.clojure.org/display/design/Improving+Clojure+Start+Time says 
> that the Java startup time is ~94 ms, while Clojure boot time is ~640 ms. 
> That's a ~680% increase.
>
> On my machine the java start time is: ~1042 ms, and the Clojure start time 
> is around ~3108 ms. A ~298% increase.
>
> When I time the startup time of lumo against node, I get ~1190 ms for 
> node, and ~1523 ms for lumo. A ~128% increase only.
>
> Does Clojure perform more initialization then ClojureScript? And would 
> that explain the much higher overhead Clojure has on top of the JVM, versus 
> ClojureScript?
>

-- 
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: Help ship Clojure 1.9!

2017-09-29 Thread Aleš Roubíček 
The Cljs problem is easily solvable by referencing latest tools.reader:

 [org.clojure/clojurescript "1.9.908" :exclusions [org.clojure/tools.reader]]
 [org.clojure/tools.reader "1.1.0"]




On Thursday, September 28, 2017 at 8:37:11 PM UTC+2, puzzler wrote:
>
> And to be clear, it doesn't only affect people who try to use ##Inf or 
> ##NaN in their Clojurescript code.  It affects all existing Clojurescript 
> code, because running the Clojurescript compiler in a new version of 
> Clojure causes all Clojurescript code to emit these ## characters directly 
> into the javascript for its definition of the core hash function, which is 
> nonsensical javascript.  So all Clojurescript code is broken by running the 
> new release.
>
> On Thu, Sep 28, 2017 at 11:34 AM, Mark Engelberg  > wrote:
>
>> On Thu, Sep 28, 2017 at 11:02 AM, Jeaye  
>> wrote:
>>
>>> This has been the only issue we've run into with 1.9.0-beta1 ( ticket is 
>>> here https://dev.clojure.org/jira/browse/CLJS-2352 ). On our back-end, 
>>> all tests are good, but we can't currently use beta1 (or alpha20) on the 
>>> front-end, since this issue causes CLJS to choke. I'm hoping that a new 
>>> version of CLJS comes out before Clojure 1.9.0 so that people don't get the 
>>> false impression that the latest of each is compatible with the other.
>>>
>>> J
>>>
>>>
>> Agreed.  It is currently not possible to use Clojure 1.9.0 later than 
>> alpha19 with Clojurescript.  Clojurescript as it currently stands can't 
>> handle the new ## tags like ##Inf, ##NaN.  Like a number of people, I got 
>> burned by this when I tried to upgrade and spent some time tracking it 
>> down, only to realize it was already a known incompatibility.  There will 
>> be a lot more confused people if you release Clojure 1.9.0 prior to 
>> releasing a new version of Clojurescript that is compatible. 
>>
>
>

-- 
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: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times

2015-03-09 Thread Aleš Roubíček 
Just wow! Thank you.

On Tuesday, March 10, 2015 at 12:41:45 AM UTC+1, David Nolen wrote:
 ClojureScript, the Clojure compiler that emits JavaScript source code.
 
 
 README and source code: https://github.com/clojure/clojurescript
 
 
 New release version: 0.0-3058
 
 
 Leiningen dependency information:
 
 
     [org.clojure/clojurescript 0.0-3058]
 
 
 This is a significant enhancement release around REPLs and compile times.
 
 
 All builtin REPLs (Nashorn, Node.js, Rhino and the browser REPL) now
 support the helper functions normally available via clojure.repl,
 these include: doc, find-doc, apropos, dir, source, and pst.  All of the
 builtins REPL now also support source mapped stacktraces.
 
 
 This release also includes many enhancements around compile times.
 
 
 ClojureScript now ships with a default :optimizations setting of
 :none. Implicit now when using :none is source map generation and analysis
 caching. Analysis caching significantly speeds up compile times.
 
 
 The standard library (cljs.core) is now AOTed compiled to JavaScript
 along with an AOTed analysis dump and an AOTed source map. This
 dramatically cuts down on cold start compile times. The standard
 library is never actually ever analyzed or compiled in your own
 builds. The result is particularly dramatic for REPLs.
 
 
 ClojureScript is also now available for the first time as a standalone
 AOTed JAR. The Quick Start introduction has been rewritten in terms of
 the standalone JAR:
 https://github.com/clojure/clojurescript/wiki/Quick-Start
 
 
 The new Quick Start is essential reading even if you are a relatively
 experienced ClojureScript developer.
 
 
 As usual feedback welcome!
 
 
 ## 0.0-3058
 
 
 ### Enhancements
 * browser REPL source mapping for Firefox, Safari, Chrome
 * macro support in REPL special functions
 * CLJS-897: AOT core.cljs CLJS-899: AOT cache core.cljs analysis
 * CLJS-1078: Nashorn REPL should use persistent code cache
 * CLJS-1079: add way to execute arbitrary fn upon watch build completion
 * CLJS-1034: Support REPL-defined functions in stacktrace infrastructure
 * source mapping for Rhino
 * CLJS-1071: support symbol keys in :closure-defines
 * CLJS-1014: Support Closure Defines under :none
 * CLJS-1068: node target define
 * CLJS-1069: Generic :jsdoc support
 * CLJS-1030: add `cljs.repl/pst`
 * add `cljs.repl/apropos`, `cljs.repl/find-doc`, `cljs.repl/dir`
 * fix `cljs.analyzer.api/all-ns` docstring
 * add `cljs.analyzer.api/ns-publics`
 * CLJS-1055: cljs.repl/doc should support namespaces and special forms
 * Add ClojureScript special form doc map
 * CLJS-1054: add clojure.repl/source functionality to cljs.repl
 * CLJS-1053: REPLs need import special fn
 
 
 ### Changes
 * move :init up in cljs.repl/repl
 * CLJS-1087: with-out-str unexpectedly affected by *print-newline*
 * CLJS-1093: Better compiler defaults
 * Bump deps latest Closure Compiler, Rhino 1.7R5, data.json 0.2.6, 
 tool.reader 0.8.16
 * more sensible error if cljs.repl/repl arguments after the first incorrectly 
 supplied
 * default REPLs to :cache-analysis true
 * default :output-dir for Nashorn and Node REPLs
 * change ES6 Map `get` support to take additional `not-found` parameter
 * deprecate clojure.reflect namespace now that REPLs are significantly 
 enhanced, static vars, etc.
 
 
 ### Fixes
 * stop blowing away cljs.user in browser REPL so REPL fns/macros remain 
 available
 * CLJS-1098: Browser REPL needs to support :reload and :reload-all
 * CLJS-1097: source map url for AOTed cljs.core is wrong
 * CLJS-1094: read option not used by cljs.repl/repl*
 * CLJS-1089: AOT analysis cache has bad :file paths
 * CLJS-1057: Nashorn REPL should not use EDN rep for errors
 * CLJS-1086: Keyword constants should have stable names
 * CLJS-964: Redefining exists? does not emit a warning like redefining array? 
 does.
 * CLJS-937: local fn name should be lexically munged
 * CLJS-1082: analysis memoization bug
 * CLJS-978: Analysis caching doesn't account for constants table
 * CLJS-865: remove `cljs.js-deps/goog-resource` hack
 * CLJS-1077: analyze-deps infinite recursive loop
 * manually set *e in Rhino on JS exception
 * REPL options merging needs to be more disciplined
 * CLJS-1072: Calling .hasOwnProperty(source) in Clojurescript's 
 string/replace will break with ES6
 * CLJS-1064: ex-info is not printable
 * Fix REPLs emitting code into .repl directory
 * CLJS-1066: Rhino REPL regression
 * be more disciplined about ints in murmur3 code
 * Node.js REPL should work even if :output-dir not supplied
 * Nashorn environment doesn't supply console, setup printing correctly

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

Re: core async and transducers in Clojure 1.6.0

2014-12-30 Thread Aleš Roubíček 
Clojure 1.7 alphas are pretty solid. I use them in production without any 
problems and with benefits of 1.7. 

On Monday, December 29, 2014 5:38:05 PM UTC+1, Udayakumar Rayala wrote:

 Hi,

 We are currently using clojure 1.6.0 and using async channels version 
 0.1.346.0-17112a-alpha. 
 I see that the (chan) function accepts a transducers but transducers are 
 not available in Clojure 1.6.0. 

 Is there any option other than upgrading to Clojure 1.7.0-alpha4? If not, 
 how safe it is right now to use Clojure 1.7.0-alpha4 in production? We 
 really want to use transducers as it makes our code readable.

 Thanks,
 Uday.


-- 
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 does .NET open sourcing mean for ClojureCLR?

2014-11-12 Thread Aleš Roubíček 
Unfortunately startup time of ClojureCLR is much worse because it targets 
DLR.

On Wednesday, November 12, 2014 8:16:19 PM UTC+1, Michael Klishin wrote:

 On 12 November 2014 at 21:50:57, Evan Zamir (zamir...@gmail.com 
 javascript:) wrote: 
  I just read that MS is open sourcing .NET. I assume this means   
  one could now target .NET with ClojureCLR on Linux/Mac environment.   
  Assuming that is true, the natural question seems to be which   
  VM should a Clojure developer be targeting? Is performance going   
  to be similar on both? In that case, then existing libraries
  dependencies would be the deciding factor? Thanks for opinions.   

 Mono has been around for a while and as far as ClojureCLR goes, 
 shouldn't have any [obvious] limitations. In fact, when I have to 
 touch .NET these days, I do all the work on Mono and then simply 
 verify things against .NET on Windows. Usually works like a charm. 

 Mono performance has been excellent for what I do and .NET/Mono startup 
 time is so much better than the JVM one that often now choose F# 
 for scripting. 

 Again, I haven't tried ClojureCLR but running .NET languages on 
 OS X and Linux has been perfectly possible for years.  
 --   
 @michaelklishin, github.com/michaelklishin 


-- 
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: testing platform , midje or specjl ?

2014-10-28 Thread Aleš Roubíček 
Every library is good for different kinds of testing. If you like BDD style 
go with Speclj, if you want to do acceptance testing with table like data 
go with Midje. If you preffer test after go with expectations or 
clojure.test. Test.Check is good addition to test toolbelt for everyone.

On Sunday, October 26, 2014 6:51:11 PM UTC+1, Roelof Wobben wrote:

 Hello, 

 Im learning clojure as the beginnner.
 When im googeling for a testing platform there seems to be two major 
 choices midje and specjl.

 Now I see that my learning course from github uses midje.

 Can I better learn midje and it this one still active maintained or can I 
 better learn specjl. 


 Roelof



-- 
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 best setup to program Clojurescript IF...

2014-10-05 Thread Aleš Roubíček 
LighTable is really friction less.

On Thursday, October 2, 2014 9:13:14 PM UTC+2, Peter Mancini wrote:

 What is the best setup to program Clojurescript IF:

- you hate EMACS
- use linux or windows

 Any suggestions?


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

Understanding how a collection reduce itself

2014-09-24 Thread Aleš Roubíček 
Resulting function is passed to reduction function as an recipe, how to process 
the data. Collections implements CollReduce protocol. When you call reduce 
function it will delegate the work to concrete implementation of the protocol.

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