Fork me on GitHub
#off-topic
<
2018-04-14
>
slipset15:04:36

@andy.fingerhut there is an issue for that.

slipset15:04:58

Oh, that’s another issue.

qqq17:04:42

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

akiroz18:04:18

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

akiroz18:04:59

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

tbaldridge18:04:25

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

tbaldridge18:04:37

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

tbaldridge18:04:16

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.

tbaldridge18:04:55

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.

hmaurer18:04:18

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

orestis17:04:44

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

john18:04:55

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

john18:04:27

I actually work with ontologies a lot, incidentally

john18:04:49

I'm still learning about them though

john18:04:29

From there, it might be interesting to look into https://en.wikipedia.org/wiki/Process_ontology, as Whitehead apparently had an influence on Clojure

john18:04:38

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

hmaurer18:04:53

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

john18:04:41

My company helps organizations implement xAPI https://xapi.com/overview/

john18:04:37

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

john18:04:06

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

john18:04:22

It seems like some very powerful stuff

john18:04:11

But the xAPI ecosystem is still pretty young at this point

john19:04:40

@hmaurer what interests you in ontologies?

hmaurer19:04:02

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

hmaurer19:04:22

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

hmaurer19:04:25

if you see what I mean

hmaurer19:04:45

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

hmaurer19:04:54

likely in combination with clojure.spec

hmaurer19:04:25

I also got interested in ontologies in the context of Datomic, which is essentially a triple-store

hmaurer19:04:34

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

hmaurer19:04:14

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

hmaurer19:04:26

I am working on a (fairly basic) theorem prover

john19:04:31

Yeah, what are you modeling?

hmaurer19:04:41

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

hmaurer19:04:04

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

hmaurer19:04:14

Right now everything is ad-hoc

hmaurer19:04:46

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

hmaurer19:04:48

and taking it from there

hmaurer19:04:32

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

john19:04:25

It would certainly do those things

hmaurer19:04:52

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

john19:04:11

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.

hmaurer19:04:15

Do you think it would be a lot of effort?

hmaurer19:04:28

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

hmaurer19:04:38

In the same way that schemaless databases do have a schema

hmaurer19:04:43

but it’s implicit instead of explicit

john19:04:49

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

hmaurer19:04:56

Yep they do

john19:04:04

An generic ontology would be more generic

john19:04:13

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

hmaurer19:04:13

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

john19:04:30

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

john19:04:43

a theorem prover doesn't sound small though 🙂

hmaurer19:04:51

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

john19:04:00

absolutely

john19:04:07

worthy doing the experiment, either way

hmaurer19:04:33

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)

qqq19:04:06

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

hmaurer19:04:14

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

john19:04:41

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.

john19:04:22

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

john19:04:59

core.typed is essentially defining an ontology

hmaurer19:04:16

@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

hmaurer19:04:21

I’ll check out core.typed

john19:04:14

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

john19:04:05

What interests me is the applications of ontologies in AI

hmaurer19:04:27

@john how so? in terms of modeling information?

john19:04:08

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

hmaurer19:04:10

oh, interesting

hmaurer19:04:18

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

john19:04:57

That's fun 🙂

Shantanu Kumar19:04:56

Is this video about Clojure? https://www.youtube.com/watch?v=HpgHGvbTxto If yes, could anybody please translate?

vemv13:04:58

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

vemv13:04:17

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

hmaurer20:04:05

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

hmaurer20:04:47

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

hmaurer20:04:46

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)

hmaurer20:04:42

(and thanks for replying to my ping!)

hmaurer20:04:29

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

michaeldrogalis20:04:58

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 🙂

hmaurer20:04:05

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

hmaurer20:04:49

@michaeldrogalis so you would start from that ontology, then generate specs based on it?

hmaurer20:04:56

well, generate/write specs to enforce it?

michaeldrogalis20:04:53

I wouldn't try to programmatically generate specs. It gets messy

michaeldrogalis20:04:08

You end up writing a custom language inside your ontology and the whole point of doing it gets lost 😕

michaeldrogalis20:04:19

But yeah - ontology first, specs second IMO.

michaeldrogalis20:04:04

Not sure how nicely Spec will play given its macros, but this worked nicely with Schema.

hmaurer20:04:47

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

michaeldrogalis20:04:12

Yeah, definitely is

hmaurer20:04:44

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

hmaurer20:04:56

I am not experienced enough in Clojure to know if that would lead down a path of tears and misery

michaeldrogalis20:04:00

I think putting it in the map is just fine.

michaeldrogalis20:04:17

Probably just stick with maps as like, an envelope of sorts for your messages

hmaurer20:04:59

Alright. Thank you @michaeldrogalis! 🙂

hmaurer20:04:22

@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

michaeldrogalis20:04:16

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

hmaurer20:04:57

@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

john20:04:09

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)

michaeldrogalis20:04:53

I hit fewer problems doing it with Schema than Spec

john20:04:57

Ad hoc instumentations come to mind