Fork me on GitHub
#babashka-sci-dev
<
2022-04-15
>
lispyclouds11:04:00

missed out the damned =~ in the shell code 😞

❤️ 1
🚀 1
borkdude11:04:48

at least we can blame bash again with their weird syntax!

lispyclouds11:04:36

also for only having the arm ones and not amd, tested the env parsing bit locally, not sure was that related to this too?

borkdude11:04:53

[clojure.string :as s] , can we use :as str ?

borkdude11:04:20

well, before that everything still worked, so I think it was related to this PR?

borkdude11:04:47

(def snapshot? (str/includes? image-tag "SNAPSHOT"))
(question mark + alias)

lispyclouds11:04:51

> can we use :as str ? i can, just the the colouring gets a bit weird for me as it thinks its the core/str

lispyclouds11:04:00

i can do full string?

borkdude11:04:12

that's a problem of your tool, not of how people usually write clojure ;)

lispyclouds11:04:17

> def snapshot? i was following the recommendation of adding a ? only in preds

borkdude11:04:48

I think it's clearer that way

borkdude11:04:21

I've tried implementing a linter for the ? behavior but it's impossible, people use it in too many different ways

borkdude11:04:49

e.g also in keywords/destructuring, while they're not predicates, I gave up enforcing anything around that

lispyclouds11:04:22

makes sense, i too never understood the consistency of ! and ?

borkdude11:04:00

I think the PR looks good now aside from those minor things. But how can we test if the arches are correct now since they weren't last time? Was the problem that the :latest image was now arm64 instead of amd64?

borkdude11:04:54

Maybe add some debug printlns in there so we can follow more closely what it's doing?

borkdude11:04:24

and then enable in your PR branch so we can test before merge

lispyclouds11:04:50

yeah, but it gets lost in the buildx noise, what im trying to do is run this locally with some prints and the same env vars

lispyclouds11:04:56

will add the prints too

borkdude11:04:05

Ah, the original bash script checked if we were on master, but this script doesn't?

lispyclouds11:04:30

thats the check we are enforcing from circle yaml anyways right?

lispyclouds11:04:37

i thought thats redundant

borkdude11:04:22

I think we should leave it in. Make minimal changes to the logic while porting

borkdude11:04:31

stay as close as possible to the original

lispyclouds12:04:12

this is the log when its merged to master

borkdude12:04:56

Maybe amd64 latest was overwritten with arm64 latest?

lispyclouds12:04:52

ah could be, and now if i put in the same checks as the shell, it wont run, will put it back along with the circle yaml

lispyclouds12:04:25

yes i see the issue, the --platform in buildx is the whole comma separated string not each one

lispyclouds12:04:41

the naming of the vars confused me

lispyclouds12:04:55

the split is there only to make the folders

lispyclouds12:04:27

and its not in the loop, my head hurts

borkdude12:04:56

maybe the problem is that you think too much, just stay as close to the bash script as possible and don't think? :)

borkdude12:04:17

that's what I've basically done with deps.clj too when porting the clojure bash script :P

lispyclouds12:04:13

yeah its me more misreading the $p and $platform and the loops i think

lispyclouds12:04:41

issue was $platform can both have one or more things

borkdude12:04:30

maybe it should be renamed to platforms?

lispyclouds12:04:08

yeah thats what i was trying the clojure side and messed up the loops

lispyclouds12:04:52

i can rename the env var too if this works fine now

borkdude12:04:14

Why is there is a replacement of / to - in the platform names? Why aren't they - in the first place?

cap10morgan16:04:51

docker wants os/arch, tarballs need os-arch. that's all.

borkdude12:04:28

Just a question, not a request for change

lispyclouds12:04:25

my undesrstanding is that / is generally the way to specify it and we use - in the tar gz files

lispyclouds12:04:33

we could keep it to -

lispyclouds12:04:57

the / also aids a bit in putting the bins in the correct place and thats how the http://dockerfile.ci picks it up but all that can be changed to - too

borkdude12:04:51

it's fine, let's not change too much

lispyclouds12:04:34

yeah its mostly driven by the docker convention of / and mapping it to the names we are using in the releases

borkdude12:04:04

ok, all set for merge now?

lispyclouds12:04:30

adding the guards back

lispyclouds13:04:42

should be good now

lispyclouds13:04:04

yeah my lsp inst triggering well

lispyclouds13:04:28

probably wrong project root or something

borkdude13:04:42

ok, let's ask @cap10morgan if he wants to glance over this PR as well https://github.com/babashka/babashka/pull/1243

👀 1
borkdude13:04:54

after that, we merge

lispyclouds13:04:21

yeah more people looking at it, the better

borkdude13:04:24

thanks a lot for the extra work

lispyclouds13:04:36

no worries, sorry for the bumps

❤️ 1
borkdude13:04:56

any ideas when your talk is going to be out on video?

lispyclouds13:04:09

well should be in https://novalug.org/presentations.html but yeah will drop them a mail about it

borkdude13:04:57

don't mean to push them ;)

lispyclouds13:04:26

yeah just a normal "we are excited to see it" mail 😛

lispyclouds13:04:28

ah so if i add {:source-paths ["src" "test" ".circleci/script"]} to .lsp/config.edn the much needed linting and others work

lispyclouds13:04:52

should this be checked in maybe?

borkdude13:04:33

dunno, for me it always works

borkdude13:04:43

regardless of source paths

lispyclouds13:04:20

maybe its via flycheck not lsp?

borkdude13:04:14

could be, but also navigation works for me on any script, even outside of source-paths

lispyclouds13:04:41

yeah i can do that too, just that the linting bit doesnt work somehow :thinking_face:

lispyclouds13:04:01

i just have lsp, no dedicated kondo

borkdude13:04:02

I use linting separately from clojure-lsp so that could be it

borkdude13:04:15

but if nav works then why doesn't linting work, maybe ask in #lsp

borkdude13:04:29

nav depends on clj-kondo analysis

lispyclouds13:04:46

yeah i'll find a minimal repro

borkdude14:04:55

Unintended effect of re-running 0.8.0 release :/ https://github.com/babashka/babashka/issues/1244

borkdude14:04:27

I wouldn't be surprised if other package managers will also be affected by this

lispyclouds14:04:38

yeah, more reminders for the amount of side effects 😕

lispyclouds14:04:19

cant believe its all down to me not noticing the extra ~ in the =

borkdude14:04:07

Arguably this is one of the most dangerous scripts to mess with, but now you've nailed it, the compile script should be far less error prone, as the test suite still comes after that

borkdude14:04:36

don't know what other bash shit we have left

borkdude14:04:01

the uberjar script is quite a monster too, I'll probably rewrite that to tools.build some day

borkdude14:04:23

(we have uberjar + uberjar.bat, both a are pain)

lispyclouds14:04:29

yeah dont think that can be bootstrapped with a bb jar i suppose

lispyclouds14:04:29

if it can be moved to tools.build would be nicely cross platform too i hope

borkdude14:04:28

also can get rid of lein completely then

borkdude14:04:42

but I'll probably save that for a rainy Sunday

borkdude14:04:55

or a boring train trip or so

lispyclouds14:04:51

yeah im just more interested in purging the shell things

lispyclouds14:04:21

bb src itself is the reason bb was built.

borkdude14:04:54

bourne again bb

lispyclouds14:04:18

would tools.build work well on windows? i could maybe take a crack at making compile+uberjar to that?

borkdude14:04:41

We only need tools.build for the uberjar. The compile step should be separate.

borkdude14:04:21

The reason to migrate would be the feature flag stuff which leads to complex shell scripts, but with tools.build this would be easy

borkdude14:04:36

I guess the vid is still being rendered or so by youtube

lispyclouds14:04:19

yeah, all of the intro to the talk is foreshadowing of the fuck ups i did yesterday 😛

🔥 1
borkdude15:04:50

The video is a bit blurry but hopefully youtube is rendering it still for higher quality or so

lispyclouds15:04:35

awesome! thanks a lot!

lispyclouds17:04:28

docker hub looks good to me @borkdude @cap10morgan

🎉 1
borkdude19:04:57

@rahul080327 @cap10morgan I'm doing a 0.8.1 release now, let's pay attention to dockerhub

borkdude19:04:03

in 10 minutes or so

lispyclouds19:04:26

thats a weird failure

borkdude19:04:51

you mean the JVM? it happens sometimes, don't know why

borkdude19:04:58

I will re-run from failure

borkdude19:04:04

when the others are done

borkdude19:04:20

it happens especially when you want to release

lispyclouds19:04:57

i guess we need to update to the cimg circleci images sometime, that deprecation warning we are getting

borkdude19:04:07

yeah as well

lispyclouds19:04:47

well the docker should go through with the failure

borkdude19:04:12

why does it take 2 minutes to push binaries we already have to docker hub again?

borkdude19:04:10

docker job successful, can you check docker hub?

lispyclouds19:04:18

hub looks good

lispyclouds19:04:33

all the arches look okay

lispyclouds19:04:39

> why does it take 2 minutes to push binaries we already have to docker hub again? its building it all over again, so i guess different hashes

borkdude19:04:00

Some golang leaking through in the test output :P

Ran 197 tests containing 580 assertions.
0 failures, 0 errors.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x4f7946

borkdude19:04:13

I guess we don't shut down the pod very nicely

borkdude19:04:56

maybe in the pods library there is a missing shutdown hook or so

lispyclouds19:04:56

we dont have a handler for the exit is it?

borkdude19:04:32

this only happens on the jvm side so it might be in the jvm side of the pods lib

lispyclouds19:04:22

right will check the go ones we have, if we all have a shutdown handler there too

borkdude19:04:55

in sqlite's pod we might want to implement the shutdown op

borkdude19:04:07

if we don't have that

lispyclouds19:04:58

yeah looks like its the sqlite one

lispyclouds19:04:31

but then bb just sends a kill to the pod right? not sure why theres a segfault

borkdude19:04:18

for some reason the linux static binary wasn't uploaded.

lispyclouds19:04:27

awesome 🙏:skin-tone-3:

borkdude19:04:57

Uploading /tmp/release to release
Uploading /tmp/release/babashka-0.8.1-linux-amd64-static.tar.gz (23 MB): DONE
Uploading /tmp/release/linux-amd64-static-metabom.jar (35 kB): DONE

borkdude19:04:04

in the logs it said it did

borkdude19:04:15

I'll do that manually. what a fucking joke this automation is ;)

lispyclouds19:04:35

well this part of the script im yet to explore

lispyclouds19:04:41

which one is it again?

lispyclouds19:04:04

well the tar was there and says its done, then what did it miss?

lispyclouds19:04:12

some github api gaff?

borkdude19:04:51

yeah think so

borkdude19:04:58

same weirdness in the jvm step

borkdude19:04:08

similar API call

borkdude19:04:19

anyway, 0.8.1 is now released, we can call it a day ;)

lispyclouds19:04:30

finally. happy easter 😛

lispyclouds19:04:49

im guess one or more of them had some 400+ status