Fork me on GitHub
#babashka-sci-dev
<
2022-04-14
>
lispyclouds18:04:17

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

lispyclouds18:04:10

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

lispyclouds18:04:52

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

borkdude18:04:46

I think so yes

lispyclouds18:04:14

reading some persist_to_workspace docs

lispyclouds18:04:30

ah, dont have the attach_to_workspace

lispyclouds19:04:43

this definitely looks nicer

borkdude19:04:30

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

lispyclouds19:04:00

ah, is it more than native ones?

borkdude19:04:21

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

borkdude19:04:43

so maybe it makes sense to split out the uberjar build

lispyclouds19:04:45

yeah i could brach out more

borkdude19:04:10

uberjar doesn't take that much time though

lispyclouds19:04:48

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

lispyclouds19:04:22

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

lispyclouds19:04:02

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

borkdude19:04:25

oh it's 1 minute? more than I thought

lispyclouds19:04:14

well 45s-1m avg

borkdude19:04:25

might be worth it, but feel free to skip it

lispyclouds19:04:11

yeah finer optimisations later, wanna make sure the script works

lispyclouds21:04:17

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

borkdude21:04:55

what's a full push?

lispyclouds21:04:55

saw if the latest and snapshots arrive in dockerhub

borkdude21:04:32

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

lispyclouds21:04:05

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

lispyclouds21:04:37

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

borkdude21:04:47

circleci linter?

lispyclouds21:04:08

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

borkdude21:04:12

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

borkdude21:04:41

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

lispyclouds21:04:58

yessss, personally painful to me

lispyclouds21:04:33

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

lispyclouds21:04:19

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

borkdude21:04:21

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

(babashka.process/sh "ls -la" {:out :inherit :err :inherit})
But since you call check anyway, why not just use (babashka.process/process "ls -la" {:inherit true}) ?

borkdude21:04:49

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

borkdude21:04:18

you can, but it's optional

lispyclouds21:04:18

yeah makes sense

borkdude21:04:44

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

borkdude21:04:00

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

lispyclouds21:04:31

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

borkdude21:04:30

or use process instead of sh

borkdude21:04:46

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

lispyclouds21:04:17

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

borkdude21:04:19

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

borkdude21:04:42

ok, I recommend doing process + check then

lispyclouds21:04:22

yeah this is what im keeping now:

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

borkdude21:04:47

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

lispyclouds21:04:06

that is okay with a vec too?

borkdude21:04:18

shell takes varargs strings

borkdude21:04:27

and an optional first map options arg

borkdude21:04:55

so (shell "tar xzvf" file)

lispyclouds21:04:56

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

borkdude21:04:29

merged

1
🙏 1
lispyclouds21:04:45

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

lispyclouds21:04:39

more bash cleansing soon hopefully

borkdude21:04:45

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

borkdude21:04:03

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

lispyclouds21:04:15

wait til you get the it doesnt run in my emacs

lispyclouds21:04:46

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

borkdude21:04:04

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

lispyclouds21:04:32

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

lispyclouds21:04:15

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. 

borkdude21:04:01

is SCI incompatible with GPL?

lispyclouds21:04:32

well AFAIK EPL and GPL has issues

lispyclouds21:04:48

which version not sure, looking up

borkdude21:04:47

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?

borkdude21:04:29

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.

lispyclouds21:04:54

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.

borkdude21:04:47

ok, fuck emacs then. hello neovim!

lispyclouds21:04:42

there i think you just need to implement their msgpack rpc

lispyclouds21:04:16

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