Fork me on GitHub

@andy.fingerhut there is an issue for that.


Oh, that’s another issue.


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.

Alex Miller (Clojure team)17:04:40

Most analog video signals do not work well over about 25 feet

Alex Miller (Clojure team)17:04:08

Digital should be fine though


You're probably looking for a VGA+USB over Ethernet extender


personally had really bad experience with long HDMI cables....


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).

Alex Miller (Clojure team)18:04:24

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...

Alex Miller (Clojure team)18:04:45

granted, this is all pro quality gear


I thought that was a pretty interesting background on ontologies for engineers


I actually work with ontologies a lot, incidentally


I'm still learning about them though


From there, it might be interesting to look into, as Whitehead apparently had an influence on Clojure


Or at least Rich has mentioned Whitehead a few times, I recall


@john can I ask in what ways you work with ontologies?


My company helps organizations implement xAPI


It tries to bring more semantic understanding to digital learning experiences, so you can get more fine grained analytics of the learner


and use a common language that works across the whole "learning ecosystem"


It seems like some very powerful stuff


But the xAPI ecosystem is still pretty young at this point


@hmaurer what interests you in ontologies?


@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.


To make it easier to document the “internal language” of the application


if you see what I mean


e.g. what types of maps can be floating around, which properties they can contain, attach docstrings to those properties, etc


likely in combination with clojure.spec


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


I can put things in context a little bit if you wish


I am working on a (fairly basic) theorem prover


Yeah, what are you modeling?


by nature, it’s essentially a pure system. No IO. Just a big function


But there are a lot of “entities” that float around the code. Abstract sytnax trees, inference rules, “failure objects”, etc


Right now everything is ad-hoc


and I am toying with the idea of rewriting everything, starting with specifying an ontology for the data flowing around the system


and taking it from there


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


It would certainly do those things


Maybe I should ask @michaeldrogalis, he did something akin to what I am describing here on Onyx:


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.


Do you think it would be a lot of effort?


It seems to me that even if the ontology isn’t written down, it’s still “there” to some extent


In the same way that schemaless databases do have a schema


but it’s implicit instead of explicit


not necessarily... But in some ways core.typed or core.spec also define flows around programs, right?


Yep they do


An generic ontology would be more generic


you could do more with it.. if it's just a map


core.spec does a lot of what I am describing, to be fair


but, if it's a really small problem, I'd grab for those


a theorem prover doesn't sound small though 🙂


I think part of me also just wants to explore ontologies. It seems like a neat solution to the problem




worthy doing the experiment, either way


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)


akiroz, alexmiller, tbaldridge: thanks for feedback on hdmi/video over 50 ft


@john would you have an advice on where to start?


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 ( organizes code blocks.


I don't know, there's different kinds of ontologies, so it depends how you want to use it


core.typed is essentially defining an ontology


@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


I’ll check out core.typed


well it's a fascinating question. I'd be interested to hear where you take it.


What interests me is the applications of ontologies in AI


@john how so? in terms of modeling information?


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


oh, interesting


(I study AIs, but at undergrad level right now)


That's fun 🙂

Shantanu Kumar19:04:56

Is this video about Clojure? 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")


mind if I don't translate, not that clojurey as said


@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 😄


@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)


(and thanks for replying to my ping!)


Let me know if anything I said isn’t clear; I’ll rephrase.


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?


well, generate/write specs to enforce 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


Ad hoc instumentations come to mind