<<29-04-2013>>

---

01:24:00	*	Trix[a]r_za is now known as Trixar_za
02:40:45	*	fowl joined #nimrod
04:04:21	*	OrionPK quit (Quit: Leaving)
06:41:38	*	Trixar_za is now known as Trix[a]r_za
06:53:02	NimBot	Araq/Nimrod f163ee6 Zahary Karadjov [+0 ±1 -0]: proper compiler output delimiter in the stdin compiler service
09:07:20	*	zahary_ joined #nimrod
09:56:41	Araq	ping zahary
09:57:00	Araq	ping zahary_
09:59:44	zahary_	hi Araq
10:01:26	Araq	one way to do the expr/stmt unification is to introduce a (stmt1; stmt2; e) construct
10:02:41	Araq	this can be done without breaking anything however to distinguish that from a tuple constructor, sometimes you need a leading ';' to introduce a stmt context
10:03:08	Araq	then even this would be possible:
10:03:14	Araq	(; mymacro:
10:03:16	Araq	body
10:03:18	Araq	)
10:03:52	zahary_	what happens without this construct?
10:04:11	Araq	(mymacro: body) # tuple constructor
10:04:19	Araq	aka (field: expr)
10:04:29	zahary_	I see
10:05:02	zahary_	mymacro do: body is possible work around now btw
10:06:24	Araq	true well
10:08:02	Araq	(let x = a(); x) would work without leading ';'
10:08:43	Araq	which is the common use case anyway
10:09:53	Araq	the real question is whether we really want to support
10:09:59	Araq	p(
10:10:05	Araq	body here
10:10:07	Araq	)
10:11:53	fowl	Araq: how do you use ; in a tuple constructor
10:12:19	fowl	(a: 1; b: 2) (4; 2) both fail for me
10:12:52	zahary_	(foo; bar) sounds like a nice construct
10:14:05	zahary_	p((body; body)) looks legal too, but I wound't care for p(body; body)
10:14:28	zahary_	I meant p(
10:14:28	zahary_	body
10:14:28	zahary_	)
10:15:21	zahary_	the recommended way should be to just use p do: in this cases
10:16:45	Araq	fowl: you can't use ';' in a tuple constructor, but the ambiguity resolves too late when you care about parsing with 1 token of lookahead
10:22:03	fowl	o
12:44:20	*	Trix[a]r_za is now known as Trixar_za
13:33:54	*	q66 joined #nimrod
14:14:11	reactormonk	http://www.darkcoding.net/software/rust-what-i-learnt-so-far/ looks like we need similar
14:28:31	Araq	reactormonk: yeah but we still have 'nil' and runtime checked ADTs
14:29:27	Araq	and apparently only Rust and D evolve ...
14:30:16	Araq	in other words most people are busy pulling reasons out of their ass for not using/learning Nimrod
14:31:29	*	fowl quit (Ping timeout: 246 seconds)
14:44:45	Araq	reactormonk: you know ... you could help me test the new JS codegen ...
14:50:16	reactormonk	Araq, if you say so
15:07:48	dom96	hello
15:58:30	*	zahary_ quit (Ping timeout: 256 seconds)
16:02:09	reactormonk	Araq, like how?
16:05:39	Araq	reactormonk: throw what you have against it
16:06:16	reactormonk	Araq, ok
16:08:05	apotheon	Araq: Rust has nil. The Rust guys just call it a different name: "unit".
16:09:14	apotheon	Araq: They also spell it "()" instead of "unit" or "nil".
16:09:25	apotheon	. . . but it's nil, as far as I understand.
16:09:37	Araq	apotheon: it's 'void' as far as I can tell
16:09:44	apotheon	hmm
16:09:44	reactormonk	Araq, gotta say, the new way of stacking functions doesn't make it more readable
16:10:05	Araq	however, it surely has something like 'nil' but it's not part of the type implicitly
16:10:18	apotheon	Araq: I think the biggest problem Nimrod has is that nobody's heard of it, so they don't talk about it, so nobody hears about it.
16:10:20	reactormonk	and it makes scoping kinda confusing too - it relies on the order of code
16:10:34	Araq	reactormonk: what do you mean?
16:10:47	Araq	the produced JS code?
16:10:52	reactormonk	yep
16:11:23	apotheon	Araq: Wouldn't the difference between "void" and "nil" basically be that nil is a type with no value, while void is a lack of typed data altogether?
16:12:00	dom96	apotheon: Yes, we need more people who blog about these things.
16:12:01	apotheon	The unit type in Rust seems to fall in the latter category for me.
16:12:08	dom96	I am currently busy with exams.
16:12:36	dom96	Big bloggers only blog about the "popular" languages
16:12:38	apotheon	dom96: When I have a copyfree implementation of Nimrod and time to start playing with it, I'll happily share what I learn about the language with the world.
16:13:31	dom96	IIRC the new release will be copyfree. Is that right Araq?
16:13:38	apotheon	Yeah, that's what he said.
16:14:18	apotheon	I'm waiting for the release to happen, and trying to carve some time (for playing around with languages that are not central for me right now) out of my schedule.
16:14:37	apotheon	. . . so that I'll be able to start playing with it as soon as I get that copyfree implementation in my hot little hands.
16:15:26	dom96	good
16:15:43	apotheon	I've played around with it a little, but so far I don't really have a favorite amongst Rust, Go, and Nimrod for my own use, in technical terms, which means my priortization of choosing what to use when playing around tends to devolve to the matter of licensing and ease of installation.
16:16:20	Araq	reactormonk: fix it; all you need to do is to make artificial deps to nested procs
16:16:36	apotheon	I think there's a definite uphill battle for popularity because of the sorta automatic boost Go gets due to its connection to Google and the same Rust gets due to its connection to the Mozilla Foundation.
16:16:41	reactormonk	Araq, huh?
16:16:59	apotheon	. . . though honestly the Mozilla connection seems like a negative to me. I'm weird, though. I like my software to show quality, and not just widespread adoption.
16:17:45	Araq	reactormonk: the codegen doesn't compile unused procs; it should do that for nested procs for predictability
16:18:29	reactormonk	Araq, why does the unused proc fail to detect?
16:18:41	Araq	detect what?
16:18:50	reactormonk	that the nested proc is used
16:19:20	Araq	it does detect that
16:19:48	apotheon	I'm also influenced somewhat by the opinions of people I respect in choosing what toys I'll pick up at any given time, when I don't really have the time to properly evaluate the stuff myself, which at the moment mostly means Go. It's the only language of the big four C++ replacements that someone I respect who is unconnected to the project is actually using for anything serious.
16:19:59	reactormonk	so why the dependency?
16:20:13	Araq	for more predictable output?
16:20:18	Araq	it's confusing you
16:20:48	apotheon	It's a lazy-ass way to pick which language, and totally nonscientific, and colored by the fact the people involved are naturally biased toward the most "complete" of them.
16:21:09	apotheon	That means either Go or D, and D is far too C++-like for their taste (and mine, frankly).
16:21:14	reactormonk	Araq, wait, it's just fine.
16:21:26	reactormonk	generates more scope.
16:21:30	apotheon	(plus not available with a fully copyfree implementation)
16:22:11	dom96	apotheon: I trust you mentioned Nimrod to these people? Do they dislike it? or do they simply stay away from it for the same reason you do; licensing?
16:23:00	Araq	Go is spectacularly bad for the resource it's got at its disposal
16:24:55	apotheon	I mentioned it, and I think they're not bothering with it because of its much less settled state than Go. They're basically picking a new implementation language for something related to their business model, so they need something complete enough for production use "now".
16:25:46	apotheon	Araq: I don't know whether I know too little about Go to see how it's spectacularly bad or just disagree with that. I do know that it seems somewhat limited relative to Rust, Nimrod, and D, but given their goals in creating it I'm not surprised at all by that.
16:27:05	apotheon	Someone else I respect is of the opinion that the culture surrounding Go is a little burdened by orthodoxy already, which has its associated annoyances.
16:28:02	apotheon	There's sort of a Pythonesque one-right-way cargo cult code style culture for Go, but where in Python it's enforced by the parser in Go it's enforced by voluntary use of part of the standard library.
16:29:05	apotheon	If you voluntarily fail to use that with Go, you're basically considered the sort of benighted fool who uses goto where while or for loops are appropriate.
16:35:59	dom96	Do you have an example of such a code style in Go?
16:40:30	apotheon	Well . . . the most trivial case is the import() . . . uhh, function? It looks like a function.
16:41:32	apotheon	The orthodoxy requires fmt to be used to enforce code formatting, and fmt ensures that your import function's arguments are always each on their own lines in the code.
16:41:49	apotheon	Thus, for instance, this:
16:41:53	apotheon	import("fmt")
16:42:10	apotheon	. . . turns into this:
16:42:11	apotheon	import (
16:42:11	apotheon	"fmt"
16:42:12	apotheon	)
16:42:19	apotheon	Always.
16:42:29	apotheon	If it doesn't look like that, you're doing it "wrong".
16:44:34	dom96	I love those silly rules. lol.
16:49:20	apotheon	Is that sarcasm?
16:49:26	dom96	yep
16:49:31	apotheon	. . . 'cause I could sarcastically say that I love bureaucratic bullshit, too.
16:50:19	apotheon	Bureaucratic bullshit annoys the crap out of me.
16:51:31	apotheon	In fact, I think fmt annoys me more than Python's parser enforcement of style, because with Python you can just think of it as (a distasteful) part of the language, but with Go you have to take specific steps to invite the bullshit into you life so that people won't deride you as a heathen and refuse to accept your code without insulting you as part of the process.
16:53:06	*	fowl joined #nimrod
16:58:27	Araq	*shrug* I don't mind an enforced coding style all that much unless it makes up valuable screen space
16:58:50	Araq	oh wait ... that's what most coding styles do ...
16:59:30	apotheon	I mind enforced coding styles if A) they're ugly and detract from readability or B) they interfere with my coding. Taking up valuable screen real estate without any significant benefit violates A, so I agree on that.
17:10:20	apotheon	Araq: Given your distaste for coding styles that "take up valuable screen space", I imagine your only problem with this style would be its admonitions against having lines that are too long and guidelines for how to use hard-wraps to avoid too-long lines of code. https://bitbucket.org/copyfree/copyfreesite/src/eb6b6c51e900c8394ad085e41002939e65749fa8/style.md
17:10:57	apotheon	Fuck, I loathe the way bitbucket doesn't seem to offer any way to get shorter URIs for specific files, or any way to specify "the latest version of the file, no matter what version it is".
17:12:51	Araq	no, in fact I agree: long lines suck
17:13:06	apotheon	Oh, I found it! https://bitbucket.org/copyfree/copyfreesite/src/default/style.md
17:13:10	Araq	the nimrod compiler can warn about lines longer than 80 chars
17:13:35	apotheon	Araq: Ah, good! Maybe you can help me propagate this style guide. I wish more people thought this way.
17:14:28	Araq	"The primary reason for limiting visible line lengths to 80 columns is to keep line lengths within a width easily parsed by the human eye without losing place."
17:14:34	apotheon	I like my linebreaks to be conceptual, indentation to be regularized, et cetera.
17:15:11	Araq	that's one reason, another is that many people have an editor open and next to it some other program
17:15:22	apotheon	Yeah, that too.
17:15:24	Araq	(*cough* IRC client)
17:15:28	apotheon	har
17:16:11	apotheon	I usually keep my IRC client on a completely separate workspace. I only need code and IRC open in the same place when my IRC conversation is actually directly related to my coding in somewhat-realtime.
17:16:37	apotheon	. . . but I do typically need other things open beside my code window.
17:20:48	apotheon	Araq: added "another important reason" there reflecting your contribution; thanks
17:21:09	dom96	ugh, another blog post about Rust. These things depress me every time.
17:21:58	apotheon	What exactly is better about Nimrod than Rust? Verifiable, easily understood statements preferred.
17:22:02	Araq	and yet you never write a blog post about nimrod, dom96 :P
17:22:14	dom96	Araq: Like I said, I have exams!
17:22:23	Araq	apotheon: simple: Nimrod doesn't have { ;;; }
17:22:49	apotheon	dom96: Shouldn't you stop reading Rust blog posts, then?
17:22:55	apotheon	Focus on those exams!
17:23:06	dom96	I should stop wasting time on reddit is what I should do lol
17:25:00	Araq	it's MUCH stronger on meta programming
17:25:16	apotheon	Nimrod is stronger on metaprogramming . . . ?
17:25:33	Araq	yes
17:25:35	apotheon	That's nice. It's not something I'm likely to notice early on, so it's good to have it pointed out, I guess.
17:26:07	*	apotheon makes a list.
17:26:18	Araq	also I have a concurrency model that I believe will work out better than Rust's but it's too early to tell really
17:27:25	apotheon	How does Nimrod metaprogramming compare to Go metaprogramming? I don't recall anything about metaprogramming support in Go.
17:27:49	Araq	Go has reflection and so relies on runtime mechanisms for metaprogramming
17:28:09	Araq	Nimrod focuses on compiletime mechanisms
17:28:59	dom96	Nimrod is also the only language out of D, Rust and Go which doesn't use the C-like syntax. But it really depends on your preference whether you consider that an advantage. I sure as hell do.
17:29:42	Araq	Go has no macros; Nimrod pushes the state of the art wrt macros
17:30:12	dom96	Nimrod has generics, Go doesn't.
17:30:31	zahary	D and clay are the closest to nimrod when it comes to meta-programming. Rust can compete when it comes to a richness of the type system, but Go is really too simplistic to be put in that company
17:31:39	apotheon	dom96: I listed C-like syntax in the "warts" section for the other languages in the file of notes I've started. I listed Pythonic syntax in the "warts" section for Nimrod. I think that's a pretty good way to refer to the matter of taste on syntax styles.
17:33:50	apotheon	Araq: Tell me again what you mean by macros in the case of Nimrod, please. Hygienic Lisp macros, C-style preprocessor macros . . . or what?
17:35:00	apotheon	I have never heard of Clay.
17:36:16	Araq	hygienic Lisp macros come close I guess
17:37:15	apotheon	Araq: Would they actually qualify as hygienic?
17:37:57	Araq	you can have hygienic and dirty and any mix you need
17:38:00	apotheon	ah
17:38:28	apotheon	. . . so no enforced hygiene, I take it.
17:39:10	apotheon	Hah. I like the Clay design philosophy: "Efficient, concise, generic - Pick any three."
17:40:05	apotheon	Awesome. Clay even has a copyfree implementation.
17:40:13	*	apotheon adds Clay to the list of stuff to investigate.
17:43:49	zahary	what is copyfree in this context btw? is this the old reference forwarding problem?
17:44:22	apotheon	zahary: http://copyfree.org
17:44:26	Araq	zahary: copyfree = BSD-like, not GPL
17:44:52	zahary	ah :) I though we are discussing technical details
17:44:58	apotheon	Not even Apache License 2.0, with all its restrictions/requirements, for that matter.
17:45:19	Trixar_za	So copyleft == GPL-like and copyfree == BSD-like?
17:45:21	apotheon	zahary: We were, but I'm more inclined to like something with a license that doesn't impose a bunch of bureaucratic bullshit on me.
17:45:28	apotheon	Trixar_za: Kinda, yeah.
17:45:33	apotheon	Trixar_za: http://copyfree.org/standard
17:46:15	zahary	I like my definition of copyfree better. I too can't really start using nimrod until we sort out this problem :)
17:46:42	apotheon	hmm
17:47:02	zahary	it's a long story, but currently nimrod performs more copies than necessary in certain situations
17:47:59	apotheon	What do you mean that it "performs more copies than necessary"? Are you talking about copying data rather than creating new references to the same data, and similar stuff?
17:48:33	zahary	yes, this sort of copies
17:48:43	apotheon	Too much reference use sometimes gets ugly when dealing with edge cases involving nested data structures.
17:49:21	zahary	it's get really messy when you have to be concerned about memory safety
17:49:28	apotheon	For a moment there, I thought you were using the "reference forwarding problem" statement as kind of a metaphor for something, but I was having a devil of a time *what*.
17:49:51	Araq	zahary: I still don't get how that feature is an any way essential
17:50:13	apotheon	I believe I'm missing a little context, so I'll just watch.
17:50:23	Araq	you can rewrite 'x = p()' to 'p(x)' via term rewriting when it really comes to it
17:51:19	Trixar_za	I always end up using CC0 myself
17:51:38	Trixar_za	Checking their Rejected Licenses page says it's the only Copyfree compatible license
17:51:40	Trixar_za	lol
17:51:42	zahary	my estimate is that more than 90% of the accessors in C++ return references - my C++ friends will give a really hard time if I try to convince them to switch to nimrod
17:52:03	apotheon	Trixar_za: CC0 is the only Creative Commons license that's copyfree compatible, yeah.
17:52:35	apotheon	Creative Commons licenses are actually pretty awful. People are just easily impressed with legalism and easily fooled by simple summaries.
17:53:23	Araq	you can use a templates for trivial accessors
17:53:36	Trixar_za	Personally I just want a Public Domain license that can protect my ass if something goes really wrong for the user.
17:53:38	zahary	to remind you, this is problem with writing accessors in nimrod (when we want to return a reference to a data member that has its lifetime bound to the lifetime of the object we are obtaining it from) - true for almost any container
17:53:45	Trixar_za	Otherwise I don't care what they do with the code
17:55:02	Araq	I still don't get it, we have 'var T' (with all its problems)
17:56:34	zahary	yes, var T is the solution. we don't have read-only version of var T and this creates problem as there is conflict between the two aspects: returning reference for performance and providing mutability
17:56:59	zahary	the reference forwarding analysis can solve this potentially, hence my cries about it
17:57:40	Araq	er ... what? "reference forwarding analysis"?
17:57:55	Araq	we talked about that years ago
17:58:31	Araq	and how can it solve it anyway? the reference forwarding analysis is about proving 'var T' to keep memory safety
18:00:34	zahary	are we talking about the same thing. indeed we have discussed it at length - what I mean is that returning a data member obtained from an argument that is passed by reference itself should produce a reference return type
18:01:22	apotheon	Trixar_za: You might consider going with a simple license that roughly equates to public domain, with an attached disclaimer.
18:02:28	apotheon	Trixar_za: The effectiveness of public domain dedications are a bit uncertain, but even to the extent they work there could conceivably be circumstances where that would mean any attached disclaimer doesn't apply as fully as when it's under copyright license.
18:02:58	Araq	zahary: an example would clear up things a lot
18:03:30	apotheon	Trixar_za: . . . plus, to be effective, public domain dedications need to come with a fallback license due at least to jurisdictional issues if for no other reason, which means that an effective public domain dedication plus license ends up being longer than a simple license.
18:04:32	Trixar_za	True, I think CC0 falls back to general public domain definition, which kind of defeats the point of the license.
18:05:30	apotheon	Trixar_za: CC0 is really an attempt at a public domain dedication with a license fallback for cases where public domain dedications are, in and of themselves, ineffective. It's similar to Unlicense that way.
18:06:07	apotheon	Trixar_za: Ultimately, public domain dedication is mostly just a waste of time under current worldwide copyright regime conditions.
18:07:59	apotheon	Trixar_za: In the end, to ensure *anyone* can use the covered work, people need to keep the CC0 text attached, which boils down to being the same essential requirements as simple copyfree licenses that are at least an order of magnitude simpler in construction than CC0.
18:08:44	apotheon	Trixar_za: The only real benefit CC0 offers over something like a BSD license or the MIT/X11 License is the fact CC0 isn't software-specific, but you can get that benefit as well by using the Open Works License or COIL instead.
18:09:07	apotheon	(or Nietzsche Public License if you find it amusing)
18:10:57	*	xcombelle joined #nimrod
18:12:24	zahary	I'll use strings for illustrative purposes. my example will be valid with any expensive-to-copy type
18:12:25	zahary	https://gist.github.com/zah/5483516
18:20:45	Araq	so ... and you can't return 'var string' because the parameters are read-only, right?
18:21:50	Araq	but you can do:
18:22:09	Araq	shallowCopy(result, b.sortedFoos[12].data) # no copy
18:22:35	Araq	it's unsafe too though
18:23:13	apotheon	I kinda think that needing to express the intent of using a reference rather than a copy is how things should be, generally speaking.
18:24:07	apotheon	SML gets around the problems with taking references by using immutable data, but most people want mutable data.
18:24:25	zahary	you are focusing on strings here. as I said, you just don't want to copy the accessed object. also, in my universe non-copyable types are ok to define
18:25:03	zahary	so, with non-copyable types you won't be even able to write the accessor, unless you go all the way to reference types
18:28:01	Araq	so what's the solution for you then; introducing 'const T'?
18:28:01	apotheon	What do you mean by "non-copyable types"? Do you mean something like nil, or are you talking about something like a C string (which is not directly copyable because it's a compound type rather than a primitive type), or what?
18:28:31	Araq	apotheon: it's a type that you mustn't copy for whatever reasons; most common: data abstraction
18:28:40	Araq	you can't copy a socket connection
18:28:45	apotheon	ah, gotcha
18:28:47	zahary	non copyable type is a thread for example? how do you copy a thread? create a new thread that has the exact same callstack?
18:28:54	zahary	ah, Araq beat me to it
18:29:00	apotheon	yeah, got it now
18:29:02	apotheon	Thanks.
18:31:01	Araq	I can't see any other solution for your problem, zahary, you need 'const T' for return types
18:33:38	*	Trixar_za is now known as Trix[a]r_za
18:33:41	Araq	on the other hand ... we can also optimize it away if only this optimization wouldn't requite caller context
18:35:09	zahary	I've spent some time thinking about it - we surely need const T in sem, but it maybe implicitly inserted in many situations with the rules we have discussed many times
18:35:30	Araq	actually ... what about a pragma instead?
18:35:46	Araq	I'm sure we discussed this already, but here we go again:
18:35:57	Araq	var x = f()
18:36:03	Araq	you either
18:36:20	Araq	a) perform some copy in 'f' and then move it into 'x'
18:36:40	Araq	b) perform no copy in f and then copy it into 'x'
18:37:01	Araq	the compiler does a) but it could do b via a pragma
18:37:03	Araq	and then
18:37:13	Araq	let x =f() # can move again
18:37:56	Araq	this works for 'let' but not for 'var'
18:38:20	Araq	well the compiler can easily transform a 'var' into a 'let' should it not be written too
18:38:57	Araq	but that's another optimization which doesn't improve expressivity in any way
18:40:42	zahary	well, b) was the original plan, wasn't it? you compile the function to return a reference and then you perform copying on the callsite only if needed
18:41:15	Araq	b) is not always preferable however
18:41:22	zahary	there are other problem with implicitly using references in the language as optimisation measure - ultimately, this abstraction leaks. consider this:
18:41:22	zahary	https://gist.github.com/zah/f0456fc4e45afb6462cf
18:41:52	zahary	also possible with the other hidden references tricks we are discussing
18:42:00	Araq	for a string builder a) is the preferred implementation
18:42:22	Araq	but that's entirely unrelated IMO
18:42:34	Araq	aliasing sucks ... yeah so what
18:42:35	zahary	what is a string builder in this context?
18:42:51	Araq	any proc that actually builds up a string
18:42:59	Araq	as opposed to a dumb accessor
18:43:38	zahary	but it won't return a reference when applying the rules, because the returned values holding the final result will be a local variable
18:43:47	zahary	so, it must be copied
18:44:25	Araq	result = "" # arguably a copy here
18:44:45	Araq	for x in s: result.add(x.toUpper)
18:45:12	Araq	--> 'result' is fresh and (a) ensures it is not copied
18:45:38	Araq	it's different if strings are not heap allocated, true
18:45:38	zahary	you mean it will use the NRVO path?
18:46:02	Araq	yeah that too
18:46:47	zahary	yes, I agree. when returning a local variable, NRVO is used, but still the reference forwarding trick won't kick in here so b) won't be attempted
18:47:58	Araq	huh? I thought you vote for doing always (b)?
18:48:32	zahary	well, b) is not always technically possible - you must return a reference to something that outlives the function invocation
18:49:26	zahary	these are values obtained indirectly from the parameters or globals
19:06:18	Araq	make an 'accessor' pragma and call it a day? ;-)
19:09:59	Araq	anyway a pragma seems much simpler than a new concept 'const T' which btw introduces a "hidden" pointer like 'var T' which you argued against (leaking abstraction)
19:22:21	zahary	pragma or no pragma, pretty much the same support have to be added in sem and the codegen
19:23:40	Araq	I think there is no need to add it to sem
19:23:50	zahary	just use var?
19:23:52	zahary	tyVar
19:24:04	Araq	I wouldn't even use tyVar
19:24:17	Araq	it's just some T that gets special treatment in the backend
19:24:46	Araq	brb
19:24:53	zahary	have to go through the details - it's hard to tell now
19:25:10	*	xcombelle quit (Remote host closed the connection)
19:29:09	Araq	in fact, it's not even a special *type* it's a special *proc*
19:29:12	Araq	that is compiled differently in the backend
19:29:37	Araq	btw I now think that many of these problems stem from the conflation of the control flow stack with a data stack
19:30:30	Araq	it's interesting to design a language which doesn't do this
19:30:42	Araq	but the details elude me for now
20:06:15	Araq	so ... my flash player doesn't produce any sound anymore (linux mint) ... any ideas?
20:06:24	Araq	I didn't install any updates
20:24:26	dom96	check it's not muted in the mixer
20:29:36	Araq	I did
20:29:37	*	Trix[a]r_za is now known as Trixar_za
20:30:04	dom96	i'm out of ideas then
20:30:19	Araq	that was quick :P
21:15:33	apotheon	Araq: Use an OS that doesn't try to make your decisions for you, so that stuff won't tend to break unless you break it.
21:15:37	apotheon	That's my only idea.
21:21:25	Araq	rm -r ~/.pulse && killall pulseaudio
21:21:26	Araq	this did it ;-)
21:21:54	apotheon	Ahh, the brute force depoettering approach.
21:22:00	apotheon	I should have thought of that.
21:22:23	Araq	no idea how killing the sound system makes it work ...
21:22:49	apotheon	"When in doubt, destroy something Poettering made."
21:23:28	apotheon	Araq: If I had to guess, with so little information, I'd say that pulseaudio and whatever Flash is actually trying to use were fighting over sound hardware access.
21:24:23	Araq	yeah but then html5 didn't produce any sound either; however other programs could produce sound
21:24:33	Araq	except other browsers ...
21:25:00	apotheon	Chances are good there was a lot of stuff relying on whatever pulseaudio wouldn't allow to access sound.
21:25:20	apotheon	In fact, chances are decent that you don't actually need pulseaudio at all.
21:25:52	apotheon	If you do, it's probably because someone packaged one of your applications configured to refuse to use anything except pulseaudio for sound.
21:26:42	Araq	true but then I shouldn't have to know about "pulseaudio" in the first place
21:26:55	Araq	it's no wonder nobody uses linux on the desktop ...
21:27:49	Araq	20 years and yet still fragile
21:27:55	apotheon	Linux has become a bizarre disaster area of kludges and redundancies.
21:29:18	apotheon	Araq: http://yokozar.org/blog/content/linuxaudio.png
21:30:19	apotheon	Meanwhile, the BSD Unix approach has been to make OSS capable of doing everything it needed to do, and I'd never even know that if I hadn't sought out the information for my own interest, because it JustWorks®.
21:45:47	Araq	freebsd didn't "just work" when I last tried it
21:48:14	*	q66 quit (Remote host closed the connection)
21:48:30	*	q66 joined #nimrod
21:53:27	*	q66 quit (Remote host closed the connection)
21:58:53	*	OrionPK joined #nimrod
22:04:13	*	Trixar_za is now known as Trix[a]r_za
22:20:00	apotheon	Araq: What problems did you have with it?
22:20:09	apotheon	(I'd guess none of them were sound related.)
22:20:16	apotheon	(unless it was a long time ago)
22:22:55	Araq	performance in general left things to be desired; it felt sluggish for some reason
22:23:06	apotheon	There's that trade-off in the way these things tend to be set up. FreeBSD might need a little more effort to get working the way you want it to work, but something like Mint might work fine for a little while then break, start getting slow for no discernible reason, develop reliability issues, any of a number of other things that end up being mystifying and difficult to diagnose (let alone fix),
22:23:07	Araq	I also had some hw problems I can't remember ;-)
22:23:12	apotheon	or some combination of those things.
22:23:39	apotheon	For some of the less popular hardware stuff, there's more likely to be a need to tweak some stuff when setting it up.
22:23:50	apotheon	(obviously)
22:24:13	Araq	well it was years ago
22:24:40	apotheon	I have no idea what would make FreeBSD seem sluggish. I've seen greater efficiency and better resource management out of FreeBSD any time I've checked into it, or at least seen these things comparable to Linux-based sytems, and never felt it was any more sluggish.
22:24:49	apotheon	Ah, well, things change.
22:25:49	apotheon	When I first started using FreeBSD, I had to change two settings with sysctl to get it to use multiple channels for sound whenever I set up a laptop. Somewhere along the way, I stopped needing to do that -- but that was the extent of the sound problems I've had with FreeBSD in all the time I've used it.
22:27:34	apotheon	At about the same time, it seemed like ALSA was about 80% likely to work perfectly for all my needs "out of the box", about 10% likely to have very strange mixer settings that needed to be fixed so I could get any sound working at all, about 5% likely to require some byzantine horribleness to figure out how to get it working, and about 5% likely to be completely FUBAR with no way to fix it other
22:27:40	apotheon	than installing something else instead.
22:28:32	Araq	well ... that sound problem doesn't justify switching OSes for now and this system here runs smoothly otherwise
22:28:53	Araq	however that's only because I gave up using printers with linux years ago ;-)
22:28:58	apotheon	Since then, Linux sound has gone downhill, in that ALSA is more likely to JustWork® "out of the box", though the other options are still problematic, and it's not just ALSA that might not work properly now -- Jack, PulseAudio, ESD, and half a dozen other things are common problem sources for sound now.
22:30:18	apotheon	Araq: Yeah, I understand sound isn't a good reason. It's just kind of emblematic of the sort of differences I've seen between Linux-based systems and FreeBSD -- the Linux-based systems tend to do more automated guesswork with complex piles of junk under the hood to get things working the way people think you might want it to work, but are more likely to break and harder to fix, while the FreeBSD
22:30:24	apotheon	stuff is much simpler to manage, configure, and fix.
22:30:54	apotheon	Sometimes, that's not enough, such as the year or two I used Debian on this laptop until FreeBSD 9.1-RELEASE happened, because I didn't have the necessary graphics support for the hardware in this laptop.
22:31:21	apotheon	Ultimately, though, when it is enough, I have a much better experience using FreeBSD than using any Linux distribution.
22:50:01	*	fowl quit (Ping timeout: 268 seconds)
23:18:11	reactormonk	apotheon, pulse works farely well
23:18:53	apotheon	. . . when it works, and sometimes when it works it interferes with something else. That's my experience, anyway.
23:19:19	apotheon	reactormonk: Araq clearly had a problem with pulseaudio earlier.
23:36:25	reactormonk	apotheon, it's a bit of magic :-/
23:52:56	Zor	eh... I've been running mint for 2 years now without any trouble