in bb v1.3.184, clojure 1.11.1 Java 20.0.2

bb is based on JDK 19, does this method exist at that version?

this is just a matter of adding the right class to the class configuration in babashka, it's just not included yet

feel free to post an issue

Not sure when this was added, the Java APIdocs mention it in Java SE8: https://docs.oracle.com/javase/8/docs/api/java/util/stream/IntStream.html#count--

Though that documentation looks suspicious;; pretty sure `

return mapToLong(e -> 1L).sum();
 

bb isn't based on java 8 for a long time, don't see how that point is relevant

it's just a config issue with bb

It’s relevant if count was added in jdk20. but I’ll add an issue later today

ah so it's 19 vs 20 issue, that actually makes sense

then why does count show up in the java 8 docs

I don’t understand the java8 documentation 🙂 so I don’t know. I’ll do some experiments first to see when that was added.

This works on Java 19 for me:

(.count (.codePoints "woof🐕"))

so it should also work on bb which is based on 19 right now

yeah looks like its added on java8

Ok i’ll add an issue later today. Thanks!

actually the Stream class also has a count method, so I'd expect this to already work somehow...

somehow this doesn't work:

(let [^java.util.stream.Stream x (.codePoints "woof")] (.count x))

is IntStream not a subclass of Stream?

a fun jungle of classes...

Stream seems to be a sibling of IntStream

adding the class + a cast from a private object to that class seems to work:

$ ./bb -e '(.count (.codePoints "woof🐕"))'
5

Adds 126 kb to bb though :/

how do you pull up that hierarchy?

ah, "tree"

IntStream is a BaseStream

but BaseStream doesn't have .count, this is why it doesn't work in bb currently

@U09N5N31T This currently works in bb as a workaround: (count (iterator-seq (.iterator (.codePoints "woof")))) => 4

https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-tree.html

ok, we'll just add IntStream then, seems fundamental enough for 100kb

guess we can wait for LongStream and DoubleStream until someone runs into it

fixed here: https://github.com/babashka/babashka/pull/1625 use the recommend workaround meanwhile

lol, this test succeeded in the PR but on master:

lein test :only babashka.interop-test/IntStream-test
FAIL in (IntStream-test) (interop_test.clj:46)
expected: (= 5 (bb nil "(.count (.codePoints \"woof?\"))"))
  actual: (not (= 5 6))

Maybe something is off in the source file encoding?

yeah, I'll just let windows deal with windows

just use this for now as a workaround: (count (iterator-seq (.iterator (.codePoints "woof")))) - your original code will work only from the next release on

I will thanks!

I'm trying to look at debugging that

Oh, of note is that I'm using exactly the same com.cognitect.aws/securityhub version in full Clojure with the real Cognitect lib, where it works

And ${MY_ACCOUNT_ID} is replaced with my actual account ID when I execute the code

That stacktrace doesn't seem to contain anything from within awyeah-api, it's all just sci and Java proper, from what I can see...

Ahha, I get a much more readable stacktrace if I try in full Clojure

yeah, I was going to suggest, try the same code in a JVM

Ahha! Think I've got it

hopefully you found it using that approach? cool

https://github.com/griffinbank/awyeah-api/blob/0ead32ccc3504f5e654ebb98f718d5719c8cd8fe/src/com/grzm/awyeah/http_client.clj#L67

Pretty certain that's a typo

That key should be :patch

aaah makes sense. I bet @U0EHU1800 would accept a PR for that

I know my request is a :patch request, so I think we're looking up into there are getting back a nil method

I've just forked to test

He actually has a PR template that explicitly says he doesn't accept PRs and to raise an issue 😉 But I can do that too no worries once I've proved it

👍

That seems prima facie reasonable. I'll take a look tonight. Thanks for digging in!

https://github.com/grzm/awyeah-api/issues/9

Fixed in https://github.com/grzm/awyeah-api/commit/465cacdbe0abd7692987b166c3b7d2134bc62aff Thanks for the detailed report!

@U6SUWNB9N^

Awesome, thanks very much @U0EHU1800 😄

Technically it's very doable though

Are you talking about a JS to Clojure(SCI) compiler/interpreter?

What's the opposite to squinting? 😛

https://docs.racket-lang.org/rhombus/index.html You might look into Rhombus, an experimental version of Racket that provides a more "conventional" syntax for Racket s-expressions, though it is more similar to Python (e.g. syntactically significant indentation) than JS in its notation.

> Are you talking about a JS to Clojure(SCI) compiler/interpreter? I'm talking about a JS/Java-ish to Clojure transpiler which is then being fed into bb. So same APIs, just different syntax

yeah, same idea as rhombus but a syntax that people already know

I think Java (or Kotlin) syntax might make most sense as people who already know the JVM might be more tempted to use bb

I have to admit that I find my use of clojure spurned by my colleagues even if I show that I can perform tasks fast with it.

I wonder how you would express stuff like (-> (foo) :bar :baz) in Java though

->(foo(), ..., ...)

maybe foo().:foo().:bar()

Would you be better starting out with something like C, so that you don't have the weight of classes etc.

yeah, I was planning to just start with a subset of Java, no class stuff

just C-style syntax is the main point

Just for interest what got you thinking down this path?

I'm considering doing more reaching out to non-Clojure developers for babashka, but I wonder if there's any real interest in this from non-Clojure people. I could imagine that there's JVM developers that want to build there bash-like scripts in something they could easily read and still also use JVM interop in places

Groovy support maybe, it's used in Jenkins and you can use it with Spring.

that also crossed my mind

re: the threading example, I think the method chaining is a viable translation, of course the question becomes are keywords an acceptable departure from 'familiar' syntax, and maybe will keywords make sense in method position... I could imagine a really verbose translation that could probably be Java being something like foo().get(new Keyword("bar")).get(new Keyword("baz")) , and maybe somewhere in that spectrum is what's comfortable for a "Java audience".

yeah, the new Keyword thing is what I don't find acceptable compared to Clojure :)

To be clear, I'm not saying this is a desirable outcome per se', but something like a colon could be a (stretched) version of Kotlin's operator overloading. Just to sort of make the argument that a colon followed by a symbol could be somewhat correlated to a curly-braced dialect, I overrode ! on Strings in Kotlin to produce this code which 'works'™️ :

data class Keyword(val name: String)

operator fun String.not() = Keyword(this)

operator fun <T> Map<T, *>?.get(k: T) = if (this != null) this[k]
else null

val m = mapOf(!"bar" to mapOf(!"baz" to "abc"))

m[!"bar"][!"baz"] // "abc"
m[!"bar"][!"bat"] // null

it's not perfect (probably not even good), but it could be a step toward saying "`:abc` could be shimmied into a curly-brace language"

I’ve been thinking about an alternative infix syntax for Clojure for awhile. For what it’s worth, I think something like rhombus or dylan would be a better starting point than a Java-derived syntax.

you can already see how hard it is to properly expose Clojure to a mainstream dialect

A bit more palatable by introducing some helper fns:

In the language could you do the resolving through some kind of import header syntax and so remove the need to the resolve and helper functions?

I guess so, a custom ns form

@U4C3ZU6KX this works now ;)

Special template strings for keywords and symbols:

if you are exposing the idea of a keyword in this mini language why not just use : or do you have to expose the idea of keywords? Also is the idea of a keyword as a function really working in that last example, it seems quite subtle to me.

because : isn't JS syntax, the JS parser I'm using doesn't get that

yes, it works

OK, now I understand where you are coming from.

I was just thinking the get (response, k'status')

that works too

but k and s templates work at compile time

such that the transpiled code is (:status ...)

this doesn't work for calling pr-str in Clojure: ((symbol "pr-str" ...)) but

s`pr-str`(...)

(pr-str ...)

anyway these are just fun hacks, nothing serious