Clojurians Log v2

It's so fun to see where this thread went. So cool!!

What I wonder is how you managed to stumble across this???

he's just lucky

as part of https://clojure.atlassian.net/browse/CLJ-2920 we're planning to deprecate that stuff (since it hasn't worked in years, and is probably a bad idea anyways)

the idea here way back was to let you look up any javadoc - if it wasn't supported by our built-in mappings / JDK (also perennially out of date), it would do a google search with the "feeling lucky" flag set, which used to just redirect you to the first result automatically.

But in all seriousness... I was going to implement this for bb's REPL, CLJ-2920 is nice info to have, thanks

have you looked at leveraging https://github.com/clojure/java.doc?

I took a quick glance but it has too many deps or the deps overlap with bb in an inefficient manner (e.g. flexmark vs bb's nextjournal.markdown which is based on commonmark), so I'd probably have to port it

I haven't actually tried it. Let me check what it does...

it spits out a mix of markdown and HTML in the REPL, why?

Here are some more examples of how strings can be used:
>
> 

<br />

For REPL usage it could be nice if it printed ANSI codes to make things more readable, unless that's not the idea

or perhaps spit out the HTML page to read in a browser

which javadoc already does I guess

Perhaps clojure/java.doc could get rid of the heavy tools.deps dependency since it only inspects the (current-basis) which is already available via a System property?

FWIW I've never even used clojure.java.javadoc that much, I usually find the class via a search engine, but I should use it more. I just bumped into this because my bb REPL accidentally said it supported javadoc since I copied some text from lein

yeah, java.doc is taking a different approach (trying to display text-ish info in your repl) than core's clojure.java.javdoc (trying to open the javadoc in a browser)

for me, going to a browser breaks flow, so trying to avoid that. clojure.java.doc is invokable as a tool (so that the deps don't pollute your repl), in case that approach is of interest to you. may not be good solution depending on your constraints

I think if people would like it in bb I could re-build it using deps I already have in bb, else it would be a heavy addition

if we could drop tools.build and flexmark, solely relying on Jsoup to parse HTML and produce some markdown, then it would work in bb from source

sorry I meant tools.deps

tools.deps (I assume you meant that) is doing the work to figure out where to download javadocs jars from maven, not sure how much of that you need.

ah I see

it's a nice idea, I'm sure I can work something out in bb to replicate the behavior if people ask for it

since bb now has jline it might be nice to make the output more TUI like if used in a console

For what it's worth, the new-ish "r11y" extracts out Markdown from HTML using only Clojure and Jsoup. It's packaged as a whole application. Perhaps the conversion part could get factored out. https://github.com/dazld/r11y

nice it also works with babashka if I stub out the clojure.data.json function using cheshire.

$ bb -Sdeps '{:deps {io.github.dazld/r11y {:git/sha "1f3b1e80c0304807f0f76837f6e5c0882c14e1bd"}}}' \
    -e '
  (require (quote [cheshire.core :as cheshire]))
  (intern (create-ns (quote clojure.data.json)) (quote read-str) (fn [s & {:keys [key-fn]}] (cheshire/parse-string s key-fn)))
  (require (quote [r11y.lib.html :as html]))
  (println (html/extract-content-from-url "" :format :markdown))
  '

cc @dazld

hah, neat, I hadn’t tried that, it’d be nice to see it being used like this. idea was to keep deps as low as possible on r11y (= readability), but not against swapping in cheshire so it would just work. @ericdallo mentioned that using hato instead of http-kit would facilitate usage in #eca - was going to take a look at that this week, but maybe there’s a simple way to clean up both use cases without complicating matters.

Reader conditionals or macro would work for bb changes. ECA could also switch to bb.http-client ;p

And or isolate the platform changes for bb in a .bb file also works

So make a http://json.bb and json.clj file

And maybe also an http one

bb -Sdeps '{:deps {io.github.dazld/r11y {:git/tag "v1.0.3" :git/sha "472011c"}}}' \
  -e '(require (quote [r11y.lib.html :as html]))
      (println (html/extract-content-from-url "" :format :markdown))'

Nice. Switching from httpkit -> hato increases startup time for bb though (100ms instead of probably much lower). since httpkit is built-in. babashka.http-client is also built-in and offers a very similar API as hato (like hato it is built on the JDK http client). Also babashka.http-client yields smaller binaries than hato (last time I checked).

So perhaps it would benefit both ECA and r11y (native and bb) by switching over but perhaps the benefit is only marginal. not sure

hm, assumed that hato wouldn’t even be visible / fetched by bb? https://github.com/dazld/r11y/blob/main/src/r11y/lib/http.cljc the requires are gated behind conditionals

(ns r11y.lib.http
  #?(:bb (:require [babashka.http-client :as http])
     :clj (:require [hato.client :as hato])))

oh yes, that's great

I assumed that hato was loaded in bb, which is possible, but you already fixed it, great :)

😛

can make .bb files later if needed

this all works fine as it is now, for bb then.

thanks!

lmk how you get on! there’s some better cleanup / markdown formatting that I’m playing with, but it works reasonably already

np!

I think #spam-reports is usually the recommended channel

thanks for the pointer!

They're already deactivated.