This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-14
Channels
- # beginners (53)
- # cider (10)
- # cljs-dev (23)
- # cljsrn (25)
- # clojure (68)
- # clojure-italy (4)
- # clojure-spec (25)
- # clojure-uk (7)
- # clojurebridge-ams (1)
- # clojurescript (10)
- # cursive (20)
- # datomic (21)
- # duct (4)
- # fulcro (1)
- # graphql (4)
- # hoplon (1)
- # java (7)
- # luminus (9)
- # off-topic (111)
- # om-next (2)
- # onyx (14)
- # re-frame (3)
- # reagent (9)
- # shadow-cljs (182)
- # test-check (32)
- # tools-deps (53)
- # uncomplicate (1)
- # vim (94)
- # yada (2)
@andy.fingerhut there is an issue for that.
Is anyone familiar with using ultra long monitor cables (things of the form 50ft - 100ft). I have a powerful server machine, but it is very noisy, so it is stored in another room. However, I'm getting very bad lag when using vnc (even over 1Gig LAN). I'm wondering if there is a way to route my keyboard/mouse (usb) directly to the machine and get the video signal directly back in the form of very long cables.
Most analog video signals do not work well over about 25 feet
Digital should be fine though
Yeah, and the X over Ethernet tends to do something really nasty like VNC over ethernet, unless you spend a lot of money on it
@qqq Think of it this way: 1920x1080x32bitx60fps = 400MB/sec...not Mbit. So they only way you're going to hit that level of performance is with compression, or removal of color depth or frames. All of those are rather nasty.
Best thing I've come up with is a 25ft DVI cable (about the max you want to try), or use SSH/remote desktop into the machine at the far end.
Most methods that use compression will give you a fair amount of lag or compression artifacts that make it rather useless for programming/video editing/graphics, etc.
Would anyone have a good talk to recommend on domain modelling / information models / using ontologies for domain modelling / anything related to these ideas? It doesn’t have to be about Clojure (as a matter of fact I would rather watch a non-implementation-specific talk).
we regularly push video signals 100 ft or more at conferences to run from stage to projector. I am mostly paying people to do that for me, but I believe what they usually do is HDMI through a converter box to SDI and send that over the wire
There are some converter boxes that push HDMI over CAT6. They can be finicky to get right, but they are much cheaper as they are “just” electrical...
granted, this is all pro quality gear
From there, it might be interesting to look into https://en.wikipedia.org/wiki/Process_ontology, as Whitehead apparently had an influence on Clojure
My company helps organizations implement xAPI https://xapi.com/overview/
It tries to bring more semantic understanding to digital learning experiences, so you can get more fine grained analytics of the learner
@john I am wondering if there would be benefits to clearly defining the domain of my application using an ontology, with namespaced keywords for entity types and attributes.
e.g. what types of maps can be floating around, which properties they can contain, attach docstrings to those properties, etc
I also got interested in ontologies in the context of Datomic, which is essentially a triple-store
There have been people doing research for decades on the subject of ontologies and modelling data as “subject predicate object” triples, so I am sure I have something to learn from their work
But there are a lot of “entities” that float around the code. Abstract sytnax trees, inference rules, “failure objects”, etc
and I am toying with the idea of rewriting everything, starting with specifying an ontology for the data flowing around the system
the hope is that it will: - make it clearer what data flows through the system - since an ontology is declarative, provide a way to generate nice documentation on the shape of the data flowing through the system
Maybe I should ask @michaeldrogalis, he did something akin to what I am describing here on Onyx: https://github.com/onyx-platform/onyx/blob/0.12.x/src/onyx/information_model.cljc
I don't have enough experience with theorem provers. But the effort of making an ontology seems more useful for very large problems, or when you need to statically precompute that a network of relationships are sound, like for type checking.
It seems to me that even if the ontology isn’t written down, it’s still “there” to some extent
not necessarily... But in some ways core.typed or core.spec also define flows around programs, right?
I think part of me also just wants to explore ontologies. It seems like a neat solution to the problem
Well, the theorem prover I am working on is small, but it’s also experimental (aka I can afford to try slightly unproductive things on it)
I'd google anything Rich has said about RDF, look into datamic... at least for inspiration on how to go building an ontology of a clojure program. Maybe I'd check out how codeq (http://blog.datomic.com/2012/10/codeq.html) organizes code blocks.
I don't know, there's different kinds of ontologies, so it depends how you want to use it
@john well, I roughly know what I need, I just want to be aware of any work that has been done which could influence my system design
Yeah, when we go labelling datasets so that we can train deep nets, we're essentially building ontological relationships. So what is the best way to structure those labelling systems - those ontologies - such that they provide the most benefit for automated inference
Is this video about Clojure? https://www.youtube.com/watch?v=HpgHGvbTxto If yes, could anybody please translate?
pretty funny one 😜 although the humor is not tremendously clojure-specific. Hitler describes their failed client project using Clojure + Scrum + open source + some dubious custom techniques ("git as a message broker")
@michaeldrogalis Hi! I am busy right now but I will summarise the discussion we just had and the question for you in ~5min! All the messages would be a bit long to get through 😄
:thumbsup:
@michaeldrogalis I am back! I’ll try to summarise this as concisely as possible. I am working on a (small, educative) theorem prover, written in Clojure. There are a lot of different “types of data” flowing through the system. Being a Clojure beginner I wasn’t sure of what was the “best approach” to model that data, so I adopted the convention of including a :type
key in every (well, most) maps of data flowing through the system, with a namespaced keyword indicating the “type” of the entity the map represents. e.g. {:type ::inference-rule ...}
, {:type ::failure ...}
, {:type ::logical-expression ...}
, …
This works nicely in the sense that I can “see” what type of data a function returned (and do some logic, e.g. I have a type called “failure” which is used to represent failure states), however everything is implicit; I have no central place where all those “types” are listed. I was wondering if I could define some sort of ontology with the “type hierarchy” of the application, with information about what the allowed types are, what properties are expected on maps of a given type (there is overlap with clojure.spec here; not sure if I am trying to re-invent the wheel?), attach documentation to types / properties of types, etc.
I thought that if I did the above, I would not only have a clearer specification of what flowed through my system, but also be able to generate documentation on what the “internal language of the system” is. I remembered that you did something akin to this on Onyx with your “information model”, and so I tagged you to hear your views.
Again, I am not familiar enough with Clojure.spec to know if I am re-inventing the wheel, but it seems that what I am trying to achieve goes a bit beyond clojure.spec (although specs could be generated for the “information mode” / “ontology” / “internal language specification” that I am trying to define)
Sounds all good to me -- you're in the right direction. You can use that ontology to in your specs to enforce what you dictated is the truth 🙂
This seems like what should be a well understood problem, so I am looking for references of projects / talks / books on the topic, to avoid re-inventing things in my corner
@michaeldrogalis so you would start from that ontology, then generate specs based on it?
I wouldn't try to programmatically generate specs. It gets messy
You end up writing a custom language inside your ontology and the whole point of doing it gets lost 😕
But yeah - ontology first, specs second IMO.
Not sure how nicely Spec will play given its macros, but this worked nicely with Schema.
@michaeldrogalis thanks for the insight on generating specs! I did try that a while ago and it did get messy… Also, do you think the approach of tagging maps with :type
is sensible?
Yeah, definitely is
@michaeldrogalis I vaguely wondered if it would be sensible to attach that type tag as clojure metadata, in order to be able to tag other things than maps (e.g. numbers, strings, or vectors). Do you think that would also be sensible?
I am not experienced enough in Clojure to know if that would lead down a path of tears and misery
I think putting it in the map is just fine.
Probably just stick with maps as like, an envelope of sorts for your messages
Alright. Thank you @michaeldrogalis! 🙂
@michaeldrogalis oh, unrelated but do you use metadata in intersting ways on Onyx / other projects? It seems to me like a very neat feature that I am unsure when best to use
Its tempting, because sometimes it seems like it's going to be a pretty good solution, but I always end up going back to the map/envelope approach - generally since you can't stick metadata on non-collections
@michaeldrogalis oh also, you said generating specs gets messy: is the answer any different with Schema? It seems a bit sad to have to repeat information between the ontology and the specs/schema
Metadata allows you to augment behavior without changing equality semantics. As such, you shouldn't use metadata to fundamentally change the semantics of your program (unless you're using that hammer on purpose)
I hit fewer problems doing it with Schema than Spec