Clojurians Log v2

continuing on the bash-free bb PR, any good suggestions on which step to pick the uberjar up for boostrapping the build? the current plan is to use the uberjar built with the current HEAD and use it for scripting, cc @cap10morgan

i tried a persist to workspace in the jvm stage, still dont see the jar at the docker stage, something quite stupid im missing for sure

also @borkdude we seem to be building jars at each of the native stages, we could save some time there too right?

I think so yes

reading some persist_to_workspace docs

ah, dont have the attach_to_workspace

this definitely looks nicer

it looks nice but it will slow down the native builds with quite some time since the JVM tests take quite a bit of time

ah, is it more than native ones?

no, but now they can't run in parallel to the native builds

so maybe it makes sense to split out the uberjar build

yeah i could brach out more

yes

uberjar doesn't take that much time though

does it?

yeah not really this is more to check my persist to workspace threory faster 😛

i will split the uberjar and the tests out once i narrow down the issue

yeah doesnt look like is worth it for the head scratching to save about 1min

oh it's 1 minute? more than I thought

well 45s-1m avg

might be worth it, but feel free to skip it

yeah finer optimisations later, wanna make sure the script works

@borkdude seems good to go for me: https://github.com/babashka/babashka/pull/1239 tested it with a full push

what's a full push?

saw if the latest and snapshots arrive in dockerhub

ah nice

so, > enabled: true was removed. what does that mean?

from what i know its the older key to have a root user or something in the machine executors and we dont need it anymore

my linter was telling me it doesnt need it in the spec and i had tried it without it before too

circleci linter?

yeah the YAML lsp i have knows the spec of the YAML im editing

I placed one remark, other than that, seems good to me

good riddance of that bash script, it was probably the most painful one ;)

pushed

yessss, personally painful to me

will be poking the compile one too, bit tricky with the env vars

im using https://github.com/redhat-developer/yaml-language-server fyi, understands most of the well known YAMLs

hmm, with babashka.process/sh :inherit true doesn't work as intended.

(babashka.process/sh "ls -la" {:out :inherit :err :inherit})

you don't even need to separate the string args :)

you can, but it's optional

yeah makes sense

since there's a variable in the middle I see why you did that

> hmm, with babashka.process/sh :inherit true doesn't work as intended. I'll make a bug report of this

so should i keep it to {:out :inherit :err :inherit} ?

yes

or use process instead of sh

sh is more for "get a string" since it resembles http://clojure.java.io/sh

yeah have a habit of doing sh -> check for a while

$ bb -e '(:out (babashka.process/sh "ls -la"))'

ok, I recommend doing process + check then

yeah this is what im keeping now:

(defn exec
  [cmd]
  (-> cmd
      (proc/process {:out :inherit :err :inherit})
      (proc/check)))

or use (babashka.tasks/shell "ls") , that also works and is basically the same

that is okay with a vec too?

shell takes varargs strings

and an optional first map options arg

so (shell "tar xzvf" file)

yeah i guess process+check is a bit verbose and make me remember it too 😛

sure :)

done

merged

wanted to try out contajners too, but the buildx is a pain in it 😕

more bash cleansing soon hopefully

🙌

recently I spoke with someone who was concerned that babashka was becoming a de facto clojure project tool and that he couldn't run it on PPC (IBM something).

I told him: you can always use the uberjar. That was enough to address that concern.

wait til you get the it doesnt run in my emacs

Every program attempts to expand until it can read mail run bb.

What I meant was, like we're using the uberjar in our build now, it's great to have it as a fallback option when you can't run the binary for some reason

yep! but always nice to take a poke at emacs 😉

Probably the next SCI target: https://www.gnu.org/software/emacs/manual/html_node/elisp/Dynamic-Modules.html#:~:text=A%20dynamic%20Emacs%20module%20is,can%20also%20load%20dynamic%20modules.

interesting bit

It should also export a symbol named plugin_is_GPL_compatible to indicate that its code is released under the GPL or compatible license; Emacs will signal an error if your program tries to load modules that don’t export such a symbol. 

is SCI incompatible with GPL?

well AFAIK EPL and GPL has issues

which version not sure, looking up

I can probably release the dynamic module under the GPL, but does that also mean that libraries used in that module should all be GPL?

Anyway, I haven't even started on that, but seemed like a nice thing to try out. Also a headache because of all the pointer stuff.

from https://www.eclipse.org/legal/eplfaq.php

Are the Eclipse Public License (EPL) 1.0 and the General Public License (GPL) compatible?
The EPL 1.0 and the GPL are not compatible in any combination where the result would be considered either: (a) a "derivative work" (which The Eclipse Foundation interprets consistent with the definition of that term in the U.S. Copyright Act ) or (b) a work "based on" the GPL code, as that phrase is used in the GPLv2, GPLv3 or the GPL FAQ as applicable. Further, you may not combine EPL 1.0 and GPL code in any scenario where source code under those licenses are both the same source code module.

Based upon the position of the Free Software Foundation, you may not combine EPL 1.0 and GPL code in any scenario where linking exists between code made available under those licenses. The above applies to both GPL version 2 and GPL version 3.

ok, fuck emacs then. hello neovim!

heh

there i think you just need to implement their msgpack rpc

but would be fun to try out native modules be it nvim, emacs