ELLIOTTCABLE changed the topic of #elliottcable to: Embrace, extend, extuingish.
<alexgordon> joelteon: oh god why
<joelteon> what's up
<alexgordon> re implementing SQL queries in rust
<joelteon> because all ORMs are bad
<alexgordon> actually I was struggling over that in furrow
<alexgordon> trying to work out the best mix of minimalism and syntactic sugar for an ORM
<alexgordon> it's clear that ruby/django's approach SUCKS
<alexgordon> and linq is quite nice
<alexgordon> but it's also a lot of extra stuff
<alexgordon> I mean
<alexgordon> in django this syntax is nice enough
<alexgordon> Person(name="Barry")
<alexgordon> sorry
<alexgordon> Person.objects.get(name="Barry)
<alexgordon> Person.objects.get(name="Barry")
<alexgordon> :P
<alexgordon> the .objects. is a bit dumb
<alexgordon> Person.get(name="Barry") would be fine
<alexgordon> plus it extends nicely to Person.getOrCreate(name="Barry")
<devyn> ELLIOTTCABLE: both ideas are pretty cool, could even be combined so test cases are submitted as 'literate'-style specifications
vigs has quit [Ping timeout: 240 seconds]
vigs has joined #elliottcable
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
jeannicolas has quit [*.net *.split]
akshatj-c has quit [*.net *.split]
vigs has quit [*.net *.split]
inimino has quit [*.net *.split]
irclogger_com has quit [*.net *.split]
katlogic has quit [*.net *.split]
vigs has joined #elliottcable
akshatj-c has joined #elliottcable
inimino has joined #elliottcable
katlogic has joined #elliottcable
irclogger_com has joined #elliottcable
jeannicolas has joined #elliottcable
<vigs> unRIP Freenode
cloudhead has quit [Ping timeout: 252 seconds]
cloudhead has joined #elliottcable
jeannicolas has quit [Excess Flood]
jeannicolas has joined #elliottcable
jeannicolas has quit [Excess Flood]
jeannicolas has joined #elliottcable
eligrey has quit [Quit: Leaving]
TheMathNinja has joined #elliottcable
prophile has joined #elliottcable
TheMathNinja has quit [Ping timeout: 272 seconds]
prophile has quit [Quit: The Game]
<Cheery> the video was interesting
yorick has joined #elliottcable
alexgordon has joined #elliottcable
<ELLIOTTCABLE> alexgordon: what's wrong with "ruby's" approach?
<ELLIOTTCABLE> ooc
<alexgordon> ELLIOTTCABLE: it sucks
<ELLIOTTCABLE> devyn: cucumber-y, you mean?
<alexgordon> I meant rails
<ELLIOTTCABLE> alexgordon: so, ActiveRecord's?
<ELLIOTTCABLE> why? that's probably the single most popular part of rails. People *really* like that approach to building and maintaining models in large projects.
<alexgordon> yah
<ELLIOTTCABLE> no strong opinions on my part, just want insight.
<alexgordon> ELLIOTTCABLE: *shrugs* it's ok most of the time but I dislike putting SQL in a string and passing parameters
<alexgordon> if you're writing a language designed for web programming then something like LINQ is a really good investment
<ELLIOTTCABLE> LINQ?
<alexgordon> ELLIOTTCABLE: in C#
<alexgordon> language integrated query
Sgeo has quit [Read error: Connection reset by peer]
<purr> ¯\(º_o)/¯
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
<Cheery> anyone happens to know, where I could find discussion about finalizers in GC?
<Cheery> should GC close file handles or manage resources other than memory?
<Cheery> the cost of finalizers could be bad
<Cheery> or is it?
<Cheery> why this question is relevant at this point, is the finally: -statement
<Cheery> I'm considering whether to bring it, or not, and how.
<Cheery> observing that if it is brought, it forces GC to walk through the stack if a greenlet is collected
<Cheery> and evaluate, on the gc cycle, the pieces of that stack.
<Cheery> finally statement is neither 'final' in python either
<Cheery> I can always shut down the computer, take that python.
<Cheery> other kinds of python resource management basically fails..
<Cheery> I've seen this happen quite often.
<Cheery> if it drops to the gc, the __del__ never runs.
<Cheery> I would attribute that to python though..
<Cheery> it is possible to implement a deterministically running finalizer with weak key dictionary
<Cheery> hmm..
<Cheery> is it?
<Cheery> weak value dictionary rather
<Cheery> the finalizer is bound to the value dictionary.. then we have finalizers and the values.
<Cheery> when it is detected that the finalizer is no longer in the dictionary, run it.
<Cheery> weak key/value dictionaries present similar problems
prophile has joined #elliottcable
<Cheery> or wait wait.. that's wrong link
<Cheery> this explanation is silly. but it goes for a point.
<Cheery> garbage collection presents an illusion of infinite space to put your things in
<Cheery> whatever links are lost into data, that data is still there
<Cheery> since it is unreachable, it does not matter whether it is there
<Cheery> gc schemes that assume weak keys or finalizers, require idea of grue
<Cheery> sort of a thing, which eats those unreachable, dead objects, and cause things happen.
<Cheery> if greenlet dies, before it finishes, the finalizers would have to run.
<Cheery> if the grue eats it, there's no greenlet to study at
<Cheery> lets consider another silly situation.. lets consider that these things get eaten by grue in different order.
<Cheery> the stack of the greenlet ends up eaten before the greenlet, that held the finalizer
<Cheery> this may happen, if they're in different areas of memory, that happen to be grued in different time.
<Cheery> so when the greenlet is forgotten, the finally statements cannot run, in consistent environment.
<Cheery> unless the environment for those statements is remembered
<Cheery> which might very well, prevent the collection of the greenlet in question.
<Cheery> rendering greenlets uncollectible
<Cheery> katlogic: not sure if I got it right.
<Cheery> this may still permit different kind of finalize -statements
<Cheery> those that run always when the execution passes through.
<alexgordon> Cheery: holy shit scrollback
<alexgordon> Cheery: finalizers should close file handles if they haven't already been closed, but only as a last resort
<alexgordon> it's better to use with/using blocks
<alexgordon> e.g. in python
<alexgordon> with open("file.txt", "r") as f:
oldskirt_ has joined #elliottcable
oldskirt_ has joined #elliottcable
oldskirt has quit [Ping timeout: 272 seconds]
prophile has quit [Quit: The Game]
oldskirt has joined #elliottcable
oldskirt_ has quit [Ping timeout: 252 seconds]
eligrey has joined #elliottcable
prophile has joined #elliottcable
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
prophile has quit [Quit: The Game]
alexgordon has quit [Quit: Textual IRC Client: www.textualapp.com]
<ELLIOTTCABLE> Cheery: greenlet?
<ELLIOTTCABLE> ugh stop quitting alexgordon
<ELLIOTTCABLE> get a goddamn znc or something you anus
<ELLIOTTCABLE> that article raises an interesting point to me.
<ELLIOTTCABLE> garbage collection is a specific case of a general problem of resource-management.
<ELLIOTTCABLE> so if garbage collection is "simulating a machine with infinite memory", can we generalize that to "simulating a machine with infinite resources"?
<Cheery> hm.. maybe
<Cheery> what is exactly 'resource' ?
<joelteon> infinite CPU hz?
alexgordon has joined #elliottcable
gkatsev has quit [Ping timeout: 252 seconds]
gkatsev has joined #elliottcable
gkatsev has quit [Ping timeout: 264 seconds]
Sgeo has joined #elliottcable
prophile has joined #elliottcable
prophile has quit [Quit: The Game]
TheMathNinja has joined #elliottcable
prophile has joined #elliottcable