#clojure log - Aug 22 2014

The Joy of Clojure
Main Clojure site
Google Group
List of all logged dates

0:01 danielcompton: I had a surprise using lein release today, I used lein release :minor and expected that it would release a new minor version from 0.5.5-SNAPSHOT to 0.6 but it bumped to 0.5.5, pushed a release, then bumped to 0.6.0-SNAPSHOT.

0:02 So if I want to bump a minor release, am I expected to know in advance?

0:11 Or should I manually bump to 0.6 in my project.clj and then run lein release :patch?

0:11 sm0ke: is there a way to do exclusion in lein by organisation like [.. :exclusion [org.slf4j]] ?

0:15 justin_smith: sm0ke: with all due respect, that's weird

0:16 sm0ke: why do you think that?

0:18 also that was an example.. i may have multiple deps with common org

0:19 justin_smith: excluding by org instead of dependency seems odd to me

0:19 danielcompton: you can't pull dependencies by org

0:19 sm0ke: which can be painful to exclude .. i am little confused though

0:20 wait a sec i think i hit a bug

0:20 justin_smith: also, it's :exclusions not :exclusion

0:21 sm0ke: yep, sorry for the typo

0:21 but yea it doesnt work that way?

0:21 i am not sure what is the reason for not having this

0:22 justin_smith: because org is hardly a meaningful grouping for deps?

0:25 sm0ke: also i think although undocumented :exclusion also works

0:26 hurm no it doesnt

0:34 oh i think lein by default assumes if i have something like :exclusion [abc] it is expanded to abc/abc

0:34 that is why it seems to be working at some places for me

0:35 i wish exclusions could also take a #""

0:35 justin_smith: yeah, with one name, it is assumed to be both org and project name

0:36 but it's only incidental if it means blocking the org - excluding "foo" will exclude "foo/foo" but not "foo/bar"

0:39 sm0ke: how about special handling of abc/* ?

0:41 arrdem: random brainfiring.... does anyone here use symbols as values?

0:41 outside of macro writing

0:43 sm0ke: :p never even though about it! why can you use keywords instead

0:43 cant*

0:44 justin_smith: yeah, I have always found it more convenient to use keywords

0:45 sm0ke: ,{:a 'a :b 'b}

0:45 clojurebot: {:b b, :a a}

0:46 arrdem: right. traditionally in a Lisp, you don't have keywords and strings are "expensive" so quoted symbols are how you have programmer significant values.

0:46 I'm just thinking that if the "common case" of Symbols is syntactic bindings, and the common case of Keywords is values, that it may be reasonable to eliminate Symbols entirely (or almost entirely) as legal runtime values because Keywords should be used instead.

0:47 sm0ke: ,((:a {:a 'inc :b 'str}) 1)

0:47 clojurebot: nil

0:47 sm0ke: ,((resolve (:a {:a 'inc :b 'str})) 1)

0:47 clojurebot: 2

0:47 sm0ke: i guess its safe

0:48 * arrdem still pondering a static, better defined Clojure dialect

0:48 joshuafcole_: Is there a simple way to get a list of the symbols in a namespace for exploratory purposes?

0:48 arrdem: joshuafcole_: ns-publics

0:49 joshuafcole_: ah cool thanks

0:49 sm0ke: arrdem: is this for oxcart?

0:49 joshuafcole_: ahh, shoot. Looks like a difference between clojurescript and clojure. Guess that makes sense, the whole concept of ns's is different there. I'll poke into #clojurescript about it

0:49 arrdem: sm0ke: oxlang. oxcart is explictly clojure only

0:51 sm0ke: the oxlnag landing page says about difficulty of porting clojure to other hosts? Do you think CinC would address that?

0:51 oxlang*

0:52 arrdem: maybe. I'm really just researching existing work and sketching ideas at this stage.

0:52 at a high level I don't like that Clojure is implementation defined.

0:52 this makes porting to other hosts a pain.

0:52 I also don't like the way namespaces are implemented or the var structure. They're mutable implementation details that should be cleaned up or hidden.

0:52 Clarice: huh?

0:53 "implementation defined". I don't know what you mean by that.

0:53 sm0ke: true, but also i think 80% of clojure is written in clojure

0:53 justin_smith: the definition is the implementation

0:53 Clarice: clojure-clr is actually chugging along quite well! I haven't heard much about clojurec.

0:53 arrdem: Clarice: there is no hard spec for what "clojure" is.

0:53 Clarice: arrdem: Boohoo

0:53 boodle: Hickey and co are the BD(s)FL

0:53 arrdem: Clarice: you try writing a port when you have to replicate implementation insanity..

0:53 sm0ke: Although reimplementing the remaining 20% is still mamoth task

0:53 arrdem: sm0ke: right. that's the issue.

0:53 Clarice: errr that last one was for ^arrdem

0:54 arrdem: Clarice: I have no issue with Rich and co being BD(s)FL, the lack of spec obstructs ports to other platforms. period.

0:54 justin_smith: Clarice: arrdem put a lot of work into helping clojure be faster to boot, and smaller to deploy - I think his concerns about the definition of clojure (or lack thereof) are worth paying attention to

0:54 arrdem: Clarice: compare clojure vs clojurescript. two totally different languages that share a bunch of semantics.

0:55 sm0ke: beleive me clojure is far better than scala in terms of driving forces

0:55 Clarice: justin_smith: Oh! Didn't know that.

0:55 arrdem: My apologies :P

0:55 arrdem: Clarice: :P no worries

0:55 Clarice: Clojure isn't really at a point where the language is stable, though

0:55 arrdem: I hope I'm being relatively well reasoned in all this anyway.

0:55 sm0ke: Clarice: really?

0:56 arrdem: I'd tend to disagree, but that's my oppinion.

0:56 Clarice: sm0ke: Well, I mean, all the core data structures are being redesigned to work with transducers, right?

0:56 That's a clear semantic change.

0:57 justin_smith: are the semantics of the core data structures actually changing? I would understand refining the impl for transducers, but changing the semantics seems odd

0:57 arrdem: sure, but to my spec point it's not one that comes with any associated documentation/spec changes. it's Rich going "here guys, new core.clj for you... adds a bunch of arities... have fun!"

0:57 sm0ke: are the datastructures being changes? i though only functions operarting on them got new arrity

0:57 arrdem: sm0ke: no datastructure changes I know of.

0:57 Clarice: Oh! I was mistaken.

0:57 arrdem: but I also didn't check very carefully.

0:58 * arrdem digs out clojure.core 1.7.0-SNAPSHOT

0:58 Clarice: arrdem: Starting a specification project would hampen Rich's ability to extend and change the language, wouldn't it?

0:59 arrdem: 2a09172e0c3285ccdf79d1dc4d399d190678b670 is the Transducers commit

0:59 Clarice: arrdem: Unless you made a spec just for 1.7.

0:59 arrdem: adds LazyTransformer and touches a bunch of other stuff, but no datastructure changes.

0:59 Clarice: Gotcha, my mistake then.

1:00 sm0ke: i have found clojure to be very peaceful to work with across version bumps

1:00 justin_smith: I think it's been particularly smooth since 1.2 / 1.3 or so

1:00 arrdem: Clarice: sure it would, but it also represents stability for potential language implementers like myself who want people to be able to run more or less the same code on different platforms or Clojure implementations.

1:00 sm0ke: try scala sometimes, everything will break for a minor version change, dont know about kotlin though

1:01 arrdem: justin_smith: 1.3.0 was the last breaking change, and I suspect will be the last one ever but I may yet be wrong about that.

1:01 Clarice: arrdem: Well, my question is: what's stable, what's not?

1:02 justin_smith: well, as he mentions, 1.3 was the last breaking change, 1.7 is the version that is coming up... it's been at least a couple of years with no breaking changes to the language

1:02 Clarice: That is true.

1:02 arrdem: Clarice: as far as I can tell (and I can't tell very far, I'm new to clojure in the last two years) the language core has reached a fixed point and is unlikely to see major change. It's fast _enough_, it works, and further features like Transducers, EDN, host expressions and soforth aren't breaking. they're feature supersets which provide a safe upgrade path.

1:03 idk

1:03 sm0ke: i agree

1:03 it would be like throing everything away, and hickey is too smart to do that

1:04 Clarice: Okay. Then I don't think there's any obstacle to defining a Clojure Implementation Reference that could act as a de-facto standard since nothing quite like that exists right now.

1:04 arrdem: Were you working on something along those lines? I joined late in whatever conversation this was.

1:05 arrdem: Clarice: sorta kinda. Working on my optimizing compiler over the summer I got frustrated at the lack of such a document and it started me thinking about what Clojure 2.0 could/would look like. this conversation was me spitballing the idea that keywords completely replace symbols as runtime values.

1:05 justin_smith: https://github.com/oxlang/oxcart

1:05 Clarice: arrdem: Oh, that last sentence makes me fidget a tad bit. What are you talking about?

1:05 arrdem: &'foo

1:05 lazybot: ⇒ foo

1:06 arrdem: &:foo

1:06 lazybot: ⇒ :foo

1:06 arrdem: with the former I quoted the symbol "foo", so I could use it as a symbolic value rather than resolving it as an environment binding.

1:07 with the latter I created a keyword :foo, which is self-evaluating and has no meaning besides itself whereas the symbol could be an environment binding

1:07 &(resolve 'clojure.core/conj)

1:07 lazybot: java.lang.SecurityException: You tripped the alarm! resolve is bad!

1:07 * arrdem glares at lazybot

1:07 justin_smith: ,(resolve 'conj)

1:07 clojurebot: #'clojure.core/conj

1:07 arrdem: thanks justin

1:08 justin_smith: :)

1:08 Clarice: arrdem: How do you namespace keywords?

1:08 arrdem: &::foo

1:08 lazybot: ⇒ :clojure.core/foo

1:08 arrdem: &:user/foo

1:08 lazybot: ⇒ :user/foo

1:08 justin_smith: ,::foo

1:08 clojurebot: :sandbox/foo

1:08 arrdem: &(namespace :user/foo)

1:08 lazybot: ⇒ "user"

1:08 arrdem: &(name :user/foo)

1:08 lazybot: ⇒ "foo"

1:09 Clarice: arrdem: In Clojure, what is the difference between the implementation of a keyword and that of a symbol on an object level?

1:09 arrdem: Clarice: clojure.lang.Keyword vs. clojure.lang.Symbol, both implement clojure.lang.Named

1:10 it may be INamed it's been a week since I looked at this stuff last

1:10 catern: arrdem: what is the benefit of replacing symbols with keywords?

1:10 arrdem: catern: clarity. keywords are values, symbols are bindings.

1:10 Clarice: What if I want to talk about the symbol that has a particular function value?

1:11 arrdem: catern: the downside is that symbols are often values in macros, so this doesn't really work.

1:11 catern: arrdem: that's what I was going to say for why you shouldn't replace symbols with keywords

1:11 arrdem: it's more clear to have the two uses strictly separate

1:11 arrdem: catern: eh... I think it'd be reasonable to define ' on symbols only in a macro context...

1:12 catern: arrdem: what would that do?

1:12 arrdem: catern: the idea is just that you create a syntactic distinction between anything that could be a value and anything that could be an environment resolved binding/value.

1:12 this makes more sense in the context of an Oxcart or clojurescript like Clojure dialect where there is no repl, only compiled code.

1:13 catern: are you saying that's how it is currently, or that's how you want it to be?

1:13 arrdem: I'm proposing that that's how it could be and trying to get feedback on whether this is just silly

1:13 catern: keywords are self-evaluating

1:13 that is the feature I like of them

1:15 Clarice: arrdem: You only have this redundancy in Clojure where you can namespace keywords. In Common Lisp, you cannot. keywords all reside in their own namespace where they resolve to themselves.

1:16 arrdem: Clarice: interesting. I didn't know that.

1:17 catern: arrdem: I mean, there's already a syntactic distinction, right? and also a distinction in value/type/whatever. wait, are you proposing just removing symbols?

1:17 I see, interesting

1:17 Clarice: arrdem: Historically it was observed that people were throwing around symbols just to mean literally whatever the symbol referred to, without needing a value associated with it. But this cluttered the symbol space, so they devised a namespace specifically for this purpose.

1:17 arrdem: catern: essentially.

1:17 Clarice: right. exactly what I'm driving at here.

1:17 catern: (I thought you were proposing, like, (eval :conj) gives you the conj function)

1:18 (I was very confused about why you would want that :) )

1:18 arrdem: catern: nah. I'm saying that in general the overwhelming majority of symbols will be resolved to local bindings or to defs, so why have this stupid value case when keywords do that job just as well.

1:18 catern: right

1:19 I don't see how that can possibly be workable when macros exist, though

1:19 Clarice: It can't.

1:19 And if you could make it work, it would become anti-lispy. Excuse me if that sounds zealous or religious or whatever.

1:19 arrdem: it cant _if_ macros run in the true runtime environment.

1:20 Clarice: Which they should.

1:20 arrdem: if you have some interpreted compile time environment, then this could be possible.

1:20 Clarice: how so? that's how it's traditionally done for sure.

1:21 for context: I really am just trying to explore the design space of lisps with this oxlang project. hell I'm exploring type system enforced purity haskell style and a static typechecker.

1:23 Clarice: arrdem: What I was getting at was that if you somehow came up with a way for macros to work without referring to the same symbols that are being bound to functions or variables, you'd probably use keywords (which is wht you're suggesting of course: using only keywords for "values"). But 1) then you've tied the keyword symbols to the regular symbols in some way and 2) you haven't really done anything neat.

1:24 arrdem: Oh, I am, too, actually. But I've gotten stuck on type inference for subtypes. :)

1:25 Some folks have helped me with automatically deriving variance rules for a finite set of type constructors. But I've also shot myself in the foot a little bit because I've designed my type system to just be a DAG you associate with functions at compile time, with the whole languaeg available in its construction. Godelian knot, incoming.

1:25 arrdem: Clarice: I guess I'd disagree with 1, and 2 is really just a design simplification of the language/compier, but yes nothing neat.

1:25 hehe

1:26 Clarice: arrdem: Anyway, like I said, because you can namespace keywords in Clojure, quoting symbols and using keywords symbols do exactly the same thing.

1:27 Which is also what you said

1:27 But you shouldn't remove quoting of symbols, even if you could 'fix' macros.

1:27 arrdem: Clarice: so... keywords are liked to namespaces in Clojure... but the namespace of a keyword need not exist.

1:27 &:my-synthetic-namespace.quxx/foo

1:27 lazybot: ⇒ :my-synthetic-namespace.quxx/foo

1:28 arrdem: aaaand I can't demonstrate that keywords respect require aliasing on namespaces because hiredman is a dick.

1:28 justin_smith: help? <3

1:28 Clarice: arrdem: If anything, you should remove the namespacing of keywords and turn it into its own privileged namespace like common lisp does. :P

1:29 arrdem: I'll look into how keywords get used in CL, but I like the way that Clojure's keywords behave.

1:29 Clarice: Why?

1:29 clojurebot: http://clojure.org/rationale

1:30 arrdem: lol @ clojurebot

1:30 Clarice: No, seriously, why? If ns1/keyword and ns2/keyword resolve to the same thing, why are they namespaced apart from each other?

1:30 arrdem: they don't "resolve" to anything.

1:30 &(= :ns1/foo :ns2/foo)

1:30 lazybot: ⇒ false

1:31 arrdem: nor are they equal

1:31 the common case of keywords, non-namespaced keywords, technically have a nil namespace and this do reside in a "privilaged" namespace.

1:31 Clarice: When would you compare the two?

1:32 arrdem: &(= :fn (:op {:op :fn})) ;; paraphrased code from Oxcart

1:32 lazybot: ⇒ true

1:32 justin_smith: arrdem: sorry, what?

1:33 arrdem: &(:ox/static {:static true}) ;; paraphrased code from Oxcart

1:33 lazybot: ⇒ nil

1:33 arrdem: Clarice: if :static == :X/static, the above would work

1:33 justin_smith: ,(:ox/static {:statuc true})

1:33 clojurebot: nil

1:34 arrdem: justin_smith: oh. I was asking you to do something along the lines of (do (require '[clojure.zip :as z]) :z/foo)

1:34 justin_smith: ,(do (require '[clojure.zip :as z]) :z/foo)

1:34 clojurebot: #<SecurityException java.lang.SecurityException: denied>

1:34 justin_smith: err

1:34 arrdem: AFAIK that will give you :clojure.zip/foo

1:34 justin_smith: I seem to remember that working with clojurebot...

1:34 but yeah, that would

1:35 arrdem: oh well

1:35 justin_smith: (do (require '[clojure.string :as string]) :string/foo)

1:35 ,(do (require '[clojure.string :as string]) :string/foo)

1:35 clojurebot: :string/foo

1:35 arrdem: Clarice: did I answer the question?

1:35 Clarice: arrdem: No, I still don't see why you need to namespace keywords.

1:35 justin_smith: there we go

1:35 Clarice: :(

1:35 justin_smith: but that should have said :clojure.string/foo

1:35 ,(do (require '[clojure.string :as string]) ::string/foo)

1:35 clojurebot: :clojure.string/foo

1:35 justin_smith: et voila!

1:35 we were close

1:35 arrdem: (inc justin_smith)

1:35 lazybot: ⇒ 62

1:37 arrdem: Clarice: it's not a "need to" it's a "want to". as a matter of convenience it's frequently useful to have a set of keywords which are "local" to some namespace. Say I wanted to use :ox/* for compiler analysis tagging, because I wanted to use some keywords like :static which are used "raw" in clojure.core and I don't want a keyword such that it equals the "raw" :static clojure.core uses.

1:38 the :: notation and namespace concept really isn't namespacing, it's syntactic sugar for getting a different or qualified value.

1:38 Clarice: But it wouldn't matter if they equaled each other.

1:38 arrdem: how so?

1:39 Clarice: Because there's no csse where you'd ever want to compare the two keywords and desire them to be not equal.

1:39 Or differentiable, rather.

1:39 justin_smith: the metadata map would be in error, because it can't have two identical keys

1:39 and :static is alreayd used, but :ox/static is different

1:39 arrdem: yeah. what justin_smith said. sorry Clarice that makes no sense.

1:40 Clarice: ._.

1:40 I didn't think about metadata.

1:40 I actually wanted to keep talking about a clojure standard

1:40 Or implementation reference, rather

1:40 arrdem: metadata is just this example case.

1:41 Clojure.core has ^{:static true} on a lot of symbols. my compiler proves that things can be static. I needed a way to annotate symbols (okay fine vars/defs) as static, so I used a namespaced keyword. this worked because of what justin_smith described. hence I like keyword namespacing.

1:42 Clarice: Yeah, for maps that can be useful.

1:42 justin_smith: another example: a request map in ring is used to carry values as various middleware and then the handler are applied. If I use namespaced keywords as keys in that request map, I am less likely to break someone else's middleware

1:42 Clarice: Ok, you win.

1:42 arrdem: :P

1:42 Rich wins

1:42 not me

1:43 Clarice: if you've got a writeup of what you're working on I'd be happy to see it. mailto:me@arrdem dot com

1:44 Clarice: No writeup :'(

1:44 arrdem: ಠ_ಠ

1:44 つ ◕_◕ ༽つ GIVE DOCS つ ◕_◕ ༽つ

1:45 Clarice: Hahahah

1:45 arrdem: in fairness writing docs is hard. I sat down to start putting oxlang ideas in a buffer this evening hence the spam

1:46 Clarice: arrdem: I wouldn't use keywords for the keys in Common Lisp if my map was being thrown across different parts of my code

1:47 arrdem: Clarice: right. that's what I think makes namespaced keywords valuable... they provide "hiding" in that information can be nicely domain/provider localized but without some "real" hiding concept.

1:47 Clarice: No

1:48 arrdem: I'd use a quoted namespaced symbol

1:48 arrdem: or that... idk. you could, it just doesn't buy you anything.

1:48 */more

1:49 Clarice: what would be represented in clojure as {'ns1:key val1 'ns2:key val2}

1:49 arrdem: you could write the exact same thing {:ns1/key 1 :ns2/key 2}

1:49 : vs '

1:49 mod :: and aliased imports

1:50 in which case ::alias/key could be a lot nicer than :my-ungodly-source-namespace/key

1:50 Clarice: Right! They're redundant when you can namespace keywords! You can't in CL, so no redundanch and no loss of functionality :)

1:50 arrdem: :P

1:51 Clarice: Hahahah

1:51 arrdem: Anyway. I'm interested in starting this project with you if you're really serious.

1:51 arrdem: $google mikera kiss

1:52 lazybot: [mikera/kiss · GitHub] https://github.com/mikera/kiss

1:52 arrdem: ^ is the only existing work besides my oxlang spec draf(s).

1:52 $google bbloom eclj

1:52 lazybot: [brandonbloom/eclj · GitHub] https://github.com/brandonbloom/eclj

1:52 arrdem: ^ related but more of a clojure interpreter in clojure

1:53 Clarice: With extensible effects! Neat!

1:53 arrdem: I have a _lot_ of background reading to do on type system prior art and soforth before I'm willing to commit to building a hardcore fork of Clojure. I've been dragging my feet on mikera for exactly that reason.

1:53 Clarice: I wish Haskell would adopt effects as THE way to combine side effects

1:53 Instead of monadT garbage

1:53 arrdem: also I'm an unpaid undergrad with classes to pass :P

1:53 Clarice: Well so am I

1:54 arrdem: welcome to the undergrad clojurist club... you me and Bronsa are the only known members :P

1:54 Clarice: But fortunately, cs has a really low barrier of entry compared to every other discipline out there

1:54 I say that half in jest.

1:58 arrdem: Clarice: what's your background for being interested in this stuff?

1:58 Clarice: What stuff? We've talked about a million things

1:58 arrdem: Lisps/language architecture

1:58 Clarice: arrdem: I like Lisp. A lot more than I like amy other languahe.

1:58 Heh, typos. I'm on my phone, I apologize.

1:59 arrdem: As for language architecture, I'm just a systems junkie. I like the nitty gritty of how things are designed.

2:01 arrdem: Clarice: :D nitty gritty is a lot of fun imo. always where I've been happiest.

2:02 Clarice: arrdem: I'm the local common lisp troll, anyway.

2:02 arrdem: goddamnit... 1am, school resumes in ten days and there're drunks singing in the building already

2:02 (dec college)

2:02 lazybot: ⇒ -1

2:03 arrdem: Clarice: good luck with that :P the zen of #clojure when faced with trolls is legendary, second only to that of #haskell.

2:03 Clarice: arrdem: I badger #haskell, too :P

2:04 arrdem: lol

2:04 Clarice: Once asked how to associate documentation with a function

2:04 "Just write a // comment under the type signature"

2:04 Totally missed the point of what I was saying.

2:06 arrdem: (do-rant "y we no documentation markup language built in")

2:06 Clarice: Meant --

2:07 arrdem: seriously. even having markdown as a defacto format would be better than nothing..

2:07 * arrdem bitter after building http://grimoire.arrdem.com and touching literally every docstring in clojure.core

2:08 Clarice: No, I disagree. If markup is to be used, then the schema should be pluggable through a map or something.

2:09 arrdem: Standardizing a language to be cross platform is tricky. You need to figure out what's implementation defined and what's not, and that's harder than you think.

2:11 arrdem: I think it would be reasonable to annotate the markup type/style of a docstring, sure

2:17 TEttinger: lifenoodles, is your nick an Earthbound reference?

2:17 arrdem: anyway. I'm gonna turn in.. I'd be curious to see a writeup even of general ideas should such a thing come to exist. interesting chatting with you.

2:18 TEttinger: arrdem, have you seen the Wat language and Kernel stuff?

2:18 also, Clarice

2:18 Clarice: Also

2:18 Oh

2:18 No

2:18 TEttinger: it's sorta a different evolutionary tack on Lisp

2:19 there's no intro here but http://axisofeval.blogspot.com/2011/09/kernel-underground.html

2:20 arrdem: TEttinger: don't think I have

2:20 Clarice: Oh, uh, that John Shutt business

2:20 TEttinger: https://github.com/manuel/wat-js it looks pretty lispy

2:20 arrdem: lol @ that haskell picture

2:21 TEttinger: I think this was 40 lines in an earlier version, green threads in the browser with Wat https://github.com/manuel/wat-js/blob/master/modules/fibers.wat

2:24 http://axisofeval.blogspot.com/2013/05/green-threads-in-browser-in-20-lines-of.html 20 apparently, in the old hideous syntax

2:24 * arrdem adds all the linked papers to his heap

2:25 arrdem: holy crap this paper is 416 pages long...

2:25 another day

2:30 TEttinger: thanks for the link, interesting reading

2:32 TEttinger: np, I hope something cool comes out of it

2:32 Clarice: Nothing will

2:32 Fexprs are dumb

2:42 arrdem: is the lambda the ultimate forum a thing? I thought it was inactive...

2:42 * arrdem nerdsniped by axis of eval

3:41 zeebrah: axis of eval is such a cool name for a blog

Logging service provided by n01se.net