This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-14
Channels
- # aleph (2)
- # announcements (11)
- # aws (4)
- # babashka (42)
- # babashka-sci-dev (81)
- # beginners (90)
- # biff (2)
- # calva (40)
- # cider (16)
- # clj-kondo (26)
- # clj-on-windows (1)
- # cljdoc (4)
- # cljfx (1)
- # cljsrn (2)
- # clojure (92)
- # clojure-austin (2)
- # clojure-europe (23)
- # clojure-nl (5)
- # clojure-uk (3)
- # clojured (3)
- # clojurescript (19)
- # community-development (3)
- # conjure (1)
- # cursive (4)
- # datalevin (3)
- # datomic (5)
- # emacs (13)
- # events (1)
- # fulcro (26)
- # graphql (1)
- # hugsql (15)
- # introduce-yourself (5)
- # leiningen (1)
- # lsp (29)
- # minecraft (19)
- # music (1)
- # off-topic (36)
- # pathom (12)
- # podcasts-discuss (2)
- # portal (8)
- # re-frame (12)
- # reagent (11)
- # rewrite-clj (4)
- # shadow-cljs (56)
- # spacemacs (2)
- # vim (12)
- # windows (3)
- # xtdb (43)
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?
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?
yeah i could brach out more
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
well 45s-1m avg
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
saw if the latest and snapshots arrive in dockerhub
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
yeah the YAML lsp i have knows the spec of the YAML im editing
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})
But since you call check
anyway, why not just use (babashka.process/process "ls -la" {:inherit true})
?yeah makes sense
> 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}
?
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
yeah this is what im keeping now:
(defn exec
[cmd]
(-> cmd
(proc/process {:out :inherit :err :inherit})
(proc/check)))
that is okay with a vec too?
yeah i guess process+check is a bit verbose and make me remember it too 😛
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.
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.
there i think you just need to implement their msgpack rpc
but would be fun to try out native modules be it nvim, emacs