This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-26
Channels
- # aleph (1)
- # announcements (9)
- # aws (6)
- # babashka (18)
- # babashka-sci-dev (25)
- # beginners (79)
- # calva (30)
- # cider (34)
- # clj-kondo (25)
- # cljsrn (6)
- # clojure (26)
- # clojure-australia (1)
- # clojure-europe (6)
- # clojure-norway (1)
- # clojure-poland (6)
- # clojure-uk (3)
- # clojured (2)
- # clojurescript (14)
- # datomic (19)
- # events (1)
- # google-cloud (1)
- # gratitude (2)
- # helix (1)
- # hyperfiddle (2)
- # interceptors (1)
- # jobs (17)
- # joyride (96)
- # leiningen (5)
- # lsp (20)
- # minecraft (2)
- # nbb (5)
- # other-languages (1)
- # re-frame (34)
- # releases (2)
- # shadow-cljs (15)
- # spacemacs (1)
- # xtdb (19)
Hello! I would like to use progrock in a babashka script, and wondering the best way to do it. from http://book.babashka.org, i can see that progrock is a compatible project. My goal was to add it to my dependencies in my bb.edn So my bb.edn is currently:
{:paths ["src"]
:deps {weavejester/progrock {:mvn/version "0.1.2"}}}
I get this error, though:
Error building classpath. Could not find artifact weavejester:progrock:jar:0.1.2 in central ( )
I am still new to clojure, and the dependency syntax trips me up a bit. progrock is in the mvn repository: https://mvnrepository.com/artifact/progrock/progrock, but available from clojars it looks like?
For babashka, should i adjust the syntax of the dependency map in my above bb.edn? Or would I need to bring in progrock via some other method?
Thank you!Try to put progrock/progrock {:mvn/version "0.1.2"}
instead of weavejester/progrock
I want to introduce some types that people can use with extend-type
etc. SCI has its own way of representing custom record types, so class?
returns false for a (defrecord Foo []) Foo
. From the next version of SCI and babashka on these will return true for (instance? sci.lang.SciType Foo)
.
My question to you:
Do you prefer the names:
sci.lang.Type / sci.lang.SciType
sci.lang.Namespace / sci.lang.SciNamespace
etc. Left or right?Is it important to have the lang
? I was thinking sci.impl.Type
?
Nooooo! .impl
means implementation detail, you should never use .impl
classes /vars from SCI
ah right 😄
then sci.types.Type
maybe?
can add in more stuff later on if needed?
yeah i guess thats a good place then, since its for having types, interfaces etc things
the *.types.*
thought for me was influenced by the way Typescript exports the packages