This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-27
Channels
- # beginners (35)
- # boot (111)
- # cider (12)
- # clojure (295)
- # clojure-android (2)
- # clojure-dev (12)
- # clojure-dusseldorf (9)
- # clojure-finland (1)
- # clojure-greece (7)
- # clojure-italy (24)
- # clojure-norway (1)
- # clojure-poland (7)
- # clojure-russia (14)
- # clojure-sg (1)
- # clojure-spec (29)
- # clojure-uk (25)
- # clojurebridge (1)
- # clojurescript (157)
- # clr (3)
- # cursive (3)
- # datomic (55)
- # docker (6)
- # hoplon (4)
- # juxt (11)
- # leiningen (13)
- # luminus (1)
- # lumo (3)
- # mount (1)
- # off-topic (47)
- # om (43)
- # onyx (35)
- # re-frame (33)
- # reactive (2)
- # reagent (4)
- # rum (3)
- # schema (5)
- # specter (5)
- # test-check (63)
- # vim (15)
- # yada (14)
@noisesmith Yep, fantastic. Thanks for the example
Is it still the case that Java doesn’t have any way to extend an existing class?
I can google this..
right - we can't really expect that to change
with protocols, we can extend the protocol from outside the class
I’m working in ClojureScript. I’m unable to call a few core functions [`get` keys
] due to TypeError: not a function problems.
here’s the trace for keys Uncaught TypeError: coll.cljs$core$ISeqable$_seq$arity$1 is not a function at Object.cljs$core$seq [as seq] (core.cljs:1125) at cljs$core$keys (core.cljs:8331)
wow, that's odd, my first instinct there would be bad caching, second instinct would be a namespace so broken that you get undefined behavior
if it's bad caching and you are using lein, lein clean
would fix it
I deleted the build dirs, still happening.
@drewverlee one valid way to interpret "any way to extend an existing class" is to make it a question about inheritance (which is how you extend things in java), but we use String directly for string literals (I guess an implementation decision could have been made to implement an alternate CharSequence that was also callable but that seems like it is getting out into the weeds quite a bit)
Here’s (:key map)
Uncaught TypeError: o.cljs$core$ILookup$_lookup$arity$2 is not a function
at Function.cljs.core.get.cljs$core$IFn$_invoke$arity$2 (core.cljs:1836)
at cljs.core.Keyword.cljs$core$IFn$_invoke$arity$1 (core.cljs:3172)
umm, arity$2 should be :key with two args, not just one if I'm not mistaken
but :key can take two args so there's still weirdness here
line 3172 calls this for the two args (-invoke [kw coll] (get coll kw))
eg. (:key) in my cljs repl complains that arity$0 is not a function
@jeff.engebretsen oh that explains it
It’s puking here (-lookup ^not-native o k)
in get
that's weird - makes me think something is wrong on a build tool level (though I have seen things go bonkers for odd reasons) - anything suspicious in recent changes to your codebase? you could try selectively undoing changes in a new branch to find the culprit
It’s a relatively new project. Here’s the build call and the top chunk of the single source file.
(cljs.build.api/watch "src/ui"
{:main 'theme-previewer.renderer
:output-dir "app"
:output-to "app/main.js"})
(ns theme-previewer.renderer
(:require [cljs.nodejs :as nodejs]))
(def Electron (nodejs/require "electron"))
(def path (nodejs/require "path"))
(def fs (nodejs/require "fs"))
(.on (.-ipcRenderer Electron) "theme-path",
(fn [sender payload]
(.log js/console payload)
(.log js/console (keys payload))
that seems legit...
hm. I’ll go hammock it out, maybe I can get it working in the morning.
@drewverlee just small help. think about strings, they have an encoding (subtypes of UTF, ISO, other). they are something that is meant to be displayed to a user (or written to an external data store, from which they will ultimately be used for display to the user). keywords don't have these semantics, they are purer (no encoding involved) and their semantics are just a means of communication between you and the compiler
@jeff.engebretsen I'd bisect rather than hammock.
(not necessarily with git bisect
, I normally do that manually, because I always get git bisect
wrong)
There's nothing to bisect, it works without map operators but breaks with.
But it started occurring after something was changed/added. I'd track the culprit commit first.
The change was adding (:key map)
. The project is 1 day old with ~30 lines.
what's a good way to have a function be polymorphic according to an input's type? or is that an anti-pattern?
just use type
?
@josh.freckleton Protocals dispatch via type
its not an anti pattern. I think multimethods are strickly more flexible, but protocals are more performant.