Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-05-14

Channels

#babashka
<
2023-05-14
>
Patrick Brown03:05:17

So, I reckoned I'd have a muck about with porting the local file in Duratom to Babashka. It requires j.u.concurrent.locks. Which is not in babashka.impl.classes. I did some digging and found that it's used in nss such as; babashka.impl.server and babashka.impl.clojure.core.server. This appears to maybe be a repl thing, or something else. Either way it doesn't look available to me at runtime. Given my little bit of knowledge can someone enlighten me? How would I ass java.util.concurrent.locks, lock and Reentrant lock. That would help. I kind of think it's important to the whole atom aspect of duratom and don't know how to implement it otherwise. Offending part in REPO is https://github.com/patbrown/bb-duratom/blob/master/src/clojure/duratom/utils.clj. Error when used in a task: 

----- Error --------------------------------------------------------------------
Type:     java.lang.Exception
Message:  Unable to resolve classname: java.util.concurrent.locks.Lock
Location: /Users/pat/.gitlibs/libs/duratom/duratom/396e999bdd445823ef5e5117cc4b50e874eb28b0/src/clojure/duratom/utils.clj:6:3

Bob B03:05:33

afaik, they'd need to be made available in b.impl.classes to be instantiated by userspace/library code

Bob B03:05:44

another option would be to make a pod, especially if that java class in the repo is needed

borkdude06:05:01

I’ll have a look at adding that class, it’s come up before

borkdude07:05:52

I looked into adding. Adding the Lock class isn't the biggest problem. After doing so (and AtomicBoolean) I run into the deftype + Java interfaces problem https://github.com/patbrown/bb-duratom/blob/396e999bdd445823ef5e5117cc4b50e874eb28b0/src/clojure/duratom/core.clj#L44 which isn't supported in SCI. You can however implement IDeref and IAtom in SCI currently since those have special support. Let me know if you want to continue down that road.

borkdude07:05:10

O yes, I also needed to remove the java.sql.BatchException class from the code, which wasn't used.

borkdude07:05:42

You experiment locally with this by running babashka with clj -M:babashka/dev and then adding stuff to babashka/impl/classes.clj

Patrick Brown18:05:05

So if I implement IDeref and IAtom on top of it I'd be using the same API, but I would not have assurances that the durable atom was not changed underneath me? I think for my use case that would be acceptable. At that point I wonder if it wouldn't just be better to use a regular atom in mem and map the usual FS access patterns on top of medley.core/deref-swap! and babashka.fs. That's the same functionality and it's already built in. I ripped out so much of durable atom it ain't really duratom anymore. Honestly, I half want it because it ran from me. I was just bored last night and wanted to understand BB better, so I dug around...

Uli18:05:12

Hey there, maybe asking the 1000th time, but wasn't able to get a good result in duckduckgo... Is there something like deps-new for babashka, where I can create my own "starter-file". I have over and over the same things I use in babashka scripts, like shell, string and babashka.cli... so I'd like to have a file, that starts with e.g. 

#!/usr/bin/env bb
(ns sync-timew
  (:require [babashka.process :refer [shell]]
            [babashka.fs :as fs]
            [clojure.string :as str]
            [babashka.cli :as cli]))

seancorfield18:05:39

You could create your own template for deps-new

seancorfield18:05:25

http://Practical.li has a good guide on writing your own project templates for deps-new

borkdude18:05:01

@U04D7NSH54P And you can use deps-new with babashka via #C03KCV7TM6F 

neil new ...

Uli19:05:40

ah ok, so gonna write my own template and use neil to use it, right?

borkdude19:05:54

> ah ok, so gonna write my own template and use neil to use it, right? yeah