Fork me on GitHub

Hi, I’m playing with clojure.core/read and its says the stream must be an instance of or some derivee. While this is true in clojure, in babashka 0.6.7 it seems I have to use clojure.lang.LineNumberingPushbackReader instead. If I just use the former, I get

Message:  No implementation of method: :get-line-number of protocol: #'
found for class:
Any idea what the problem is? Here’s the script which prints out all forms read from the file specified as a command line argument:
(ns hello
  (:require [ :as io])
  (:import [ PushbackReader]))

(println (let [reader (PushbackReader. (io/reader (first *command-line-args*)))]
   (binding [*read-eval* false]
     (take-while #(not (identical? ::eof %)) (repeatedly #(read {:eof ::eof} reader))))))


@UUKPL2T9C I didn't know that clojure.core/read worked with any pushbackreader, but in bb clojure.core/read is implemented using edamame which currently requires an indexedreader


This should probably be fixed, so feel free to post an issue


you have to wrap the PushbackReader in LineNumberingPushbackReader indeed


Thanks, let me open that later


For mac users who want to customise their menubar: Here are 2 relatively simple XBAR plugin examples I coded ... in Babashka of course! :star-struck:


That looks very useful, I should try xbar


I looks like Apple is not so developer friendly in terms of backwards compatibility ... the menu items that provided this functionality for me break every new big MacOS update. So I decided to put one abstraction layer in between (xbar) and just write these simple plugins myself 😄


does xbar also work on linux and Windows? that would be even more awesome for cross platform


don't think so 😬


Most of my tools are cross platform because of emacs 🤓 But not these ones :man-shrugging::skin-tone-3: Interesting interface by the way 🙂


Nice, I use xbar and bb is a good implementation choice!

babashka 1

I am using a javascript (npm) program that has an elaborate but complex CLI - I want to send data from my Clojure App to the ClI as input and retrieve the data that is output — Should I be using nbb or Babashka?


does the npm program support a programmatic API as well?


then you could use it directly from nbb


if you need to shell out, then you might as well use bb


It does have a programmable API but it is pure javascript - building objects, promises, etc - so I guess babashka is my best bet — this is for a quick and dirty test until I figure out how to do the full interop — Other than streamlining the npm based API is ther anything Babashka can help me with in regard to CLI calls from a Clojure (not Clojurescript) app?


Do you mean, from a JVM Clojure app you want to call the npm app?


I recommend using babashka.process for this:


This library works with the JVM as well and is also available within babashka


Wow thanks I will check it out - yes it is a JVM app — Juxt’s site to be exact


You need to get the string output from this app? Then it would look something like:

(require '[babashka.process :as process :refer [process]])
(-> (process "node your-thing" {:out :string}) deref :out)


perfect - this is what I was experimenting with and process will be much better: (defn run-cicero-cli "Simple proof of concept for parse from command line -- pretty slow" [contract] (let [cta (str local-dir contract)] (bu/sh "cicero" "parse" cta :out-enc "UTF-8")))


what is bu/sh?


Sorry it is a command line library Jacob O’Bryant wrote for Biff: (defn sh "Runs a shell command. Returns the output if successful; otherwise, throws an exception." [& args] (let [result (apply shell/sh args)] (if (= 0 (:exit result)) (:out result) (throw (ex-info (:err result) result)))))


trouble is it returns everything including some irrelevant stuff that has to be parsed out


yeah, you could also just use if you need string output btw


Any drawbacks or advantages of babashka.process over


babashka.process supports more use cases


Perfect - Thanks - and since I already have the JVM going it should be fairly fast — I’ll give you a report when I get things running


@U04V15CAJ I know this is not totally a Babashka question but I get a file not found error when trying to run ciceor in the process: Execution error (IOException) at java.lang.ProcessImpl/forkAndExec ( ; error=2, No such file or directory My speculation is that the process shell is not the same as my system shell and doesn’t have access to npm - I did find this in Googling What do you think?


can you show me the full incantation?


and on which OS are you?


and the full invocation?


Cicero is my NPM program (def ci '[cicero parse "/Users/tmb/Coding/trustblocks/cicero-template-library/src/latedeliveryandpenalty"]) (-> (process ci {:out :string}) deref :out)


If you are in your default shell, what do you get for which cicero?




this does work for me:

$ bb -e "@(babashka.process/process '[nbb -e (+ 1 2 3)] {:inherit true}) nil"


nbb is also a global installable node CLI


perhaps you can try your same code in bb from your shell. it might have to do something with the PATH setting inside your Java environment


(-> (process ’[nbb -e (+ 1 2 3)]) {:inherit true}))


Execution error (IOException) at java.lang.ProcessImpl/forkAndExec ( ; error=2, No such file or directory


from the command line : ~ bb -e "@(babashka.process/process '[nbb -e (+ 1 2 3)] {:inherit true}) nil" 6


are you running this from IntelliJ or something like this?


Try starting VSCode from your terminal with code .


this should fix the issue I think


It works — still not as fast as I hoped but better than the old way — iIt still returns all the output — Isn’t there a piping command - ie I get: “10:31:23 AM - INFO: Loading a default text/ file. which is an informational message preceeding the output


that CLI should write that to stderr, not stdout


I ran into that before when I was calling out to the CLI and just used Clojure to pull it out since the same heading appears on everything


Sorry for all the confusion — One final Question even with process this is slow - like 4 seconds — It seems to me that the API for the CLI- which is not the same as the low level API in the docs but the CLI interface could be converted to something else- nbb doesn’t really help me since it needs to run from the command line — maybe there is a way to cache nbb in a process - or maybe I need to use shadow (It currently has trouble compiling - it compiles nicely under nbb and it will in shadow with some options. Here is what I found in the CLI Code that is a short sample of how the CLI works. If I could just call Cicero with some args I’d be home free: ‘use strict’; const Logger = require(‘@accordproject/concerto-core’).Logger; const Commands = require(‘./lib/commands’); require('yargs') .scriptName('cicero') .usage('$0 <cmd> [args]') .demandCommand(1, '# Please specify a command') .recommendCommands() .strict() .command('parse', 'parse a contract text', (yargs) => { yargs.option('template', { describe: 'path to the template', type: 'string' });


@U054219BT you could just write this code in a .js file but no matter what, you need to launch node with this js file


to you need to shell out in any case


unless you use a JavaScript engine in Java to load these libraries. GraalVM polyglot can do this


That is the drawback to shadow since I would rather be in the jvm don't babashka/nbb use Graal under the hood couldn't they just run under Graal without the shell


if you run GraalVM's JVM you could start the JS engine once


and then keep using it


their JS engine also works in a regular JVM, but it's slower, maybe performance doesn't matter to you that much


it's called graaljs


Here is an example: I'm not sure if your cicero app depends on any node.js specifics or if it's JS-platform agnostic


Another approach could be to wrap this cicero thing into a Node.js web app and host it as a separate service and make calls to that