Older blog entries for async (starting at number 116)

27 May 2005 (updated 27 May 2005 at 03:26 UTC) »
Shoes and ships and crap

I saw jdahlin's post the other day on GObject introspection. I'm glad to see it finally get committed thanks to m. clasen's work.

I was just a bit sad that i wasn't able to have been more active helping out after agitating for it and doing a first incomplete prototype (because of work and stuff, you know how it is?). That's the great thing about open source though.

With respect to the perennial language question: people should definitely be more aware of the fantastic work done on the C++ bindings (gtkmm, etc). (There is still the core platform issue, but regardless, application developers need to be more aware of all the options available to them).

I hate C++ at least 50,000 times as much as the average joe (read back a bit...arg, it's just such a half-assed language wrt what it could have been). But it can be made to work, and it does make a person more productive: for example deriving a new gobject is handled transparently without half-a-ton of boiler plate that always makes one stop and ponder if the usefulness of deriving is worth the pain.

That said, if a person needs to use C++, they should put some time into learning how to avoid the myriad of pitfalls available to them in the language. One good book i read, and recently revisited was John Lakos' book Large-Scale C++ Software Design. It's mostly about things that aren't addressed in other works. The chapters on 'levelization' and cyclic dependencies were very enlightening (for me) -- reading them crystallized a bunch of incipient ideas whose existence i was just beginning to be vaguely aware of.

And of course there's still my favorite (when it's the right tool): Python plus pygtk.

i read the piece in the new york metro about lessig's experience...and, shit, man. just, shit, man. that's all i have to say.

carry on.

i do not like spammers using my domain names for spoofing their headers. i do not like my happy domains being associated with such things. i do not like them sam i am.

5 Oct 2004 (updated 5 Oct 2004 at 14:42 UTC) »
RTFM vs. JATFM:

shlomif, the reason people created the RTFM acronym was so that it would be shorter than answering most any question.

People (I) resent others asking random questions of them out of a sense of fair play, dislike of laziness, and dislike of the arrogance that can be inferred.

if someone asks me a question i am more likely to answer that question if i know the answer directly, i know the person asking, and/or i have been helped by the person asking before (or otherwise have a reason to want to help them (friendship, ass-kissing, impress others with my knowledge, whatever)).

fairplay and failure to scale: this is of course the tragedy of the commons scenerio: even though 1 random person entering a channel and asking a simple question is not onerous, a whole lot of them will become so. with respect to only one person asking, it seems like a person refusing to answer is just being petulant, but when you consider that you might be the 500th person to ask the same question to that person that day, it becomes more understandable that they would refuse: it takes up their time, they get no benefit from it, it is not fun. it in short becomes a job.

if someone feels like they want to help the community by doing that job, i find that admirable and worthy of encouragment, but by simply being in a certain place at a certain time, a person does not consent to fulfill that role, and since most people still have the freedom to do what they like rather than submit to your will or government's will, or what you think would benefit the community etc, they don't have to.

when the questioner enters a place and asks a question, it may be considered presumptious of them, but when that questioner insists that you should tell them the answer because it's easier than arguing or saying 'rtfm', that person is presumptious, arrogant, rude, and annoying.

this quite simply is the bottom line: you are asking for something and you have no inherent right to an answer. if someone is nice enough to give you an answer you should be thankful, if they are not, you should be thankful for the chance to impose, but you should not insist that you deserve (or should otherwise get an answer) because the question is so easy or how quickly it could be answered or because people there should know the answer and it would save you time rather than finding it yourself.

it is annoying, rude, and arrogant. and for the people that see it it day after day every day time after time, it becomes less and less tolerable to be treated that way.

you should be more considerate of others, no matter what you think would help the community.

<person>hp</person>:

alsa does indeed start with the master muted and everything turned down. usually the init scripts should save and restore reasonable volume levels, so the fault lies there. the reasoning is so as not to deafen or kill any listeners or speakers inadvertantly.

PCM should probably changed to something like "Digital Audio".

the master volume issue has come up before: the best thing to do might be this: start out with something sane like all the submixers at 75% and the master at 50%.

the master volume will then act as follows: the 0-X% range will solely fiddle with the master output. towards the extreme end, before hitting a 100% the master will increase the submixers to 100%. (everything unmuted).

if the level's are unequal the 100% should still mean all at 100% (but the relative balance will be restored if you back down).

this is non-optimal but probably good enough for most users. for those that it's not, they can open up the mixer and tweak stuff themselves.

that said, i do take exception to your tone: the indignance reminds me of slashdot. and that's never good. not that it may not be deserved.

Self-Control:

i've been trying to get a suitable version control workflow going: originally, i started with CVS of course, but moved to SVN when it became available. SVN was nice and has gotten nicer, having picked up an ssh-able protocol and a plain-file based backend. the one remaining issue for me is the lack of disconnected or distributed operation.

i gave Arch a try because all the other cool kids were jumping off the bridge, but i never really got into it. (though i must say arch, like svn, has come a long way (as jamesh pointed out to me)).

i found SVK a while back, which is a decentralized system that uses SVN's repository structure and the repository interface libraries. i only recently was able to get it compiled and running.

the setup i will start trying to use is something like this: a primary SVN repository will reside on a hosted server (though the repository isn't public). i then use SVK to mirror the primary repository to a local repository on my laptop/desktop and create a local branch. OK, AND HERE'S THE TRICK!! instead of using SVK to do all the version control on the local side (it has a slightly different working copy setup), i check out the working copy using SVN and use it as normal (well through the fantastic RSVN convenience wrapper (:D)). Finally i can use SVK again to star merge everything back to the primary repository.

the above mentioned trick is only to get around SVK being a bit slow-starting (written in perl) and the feeling that SVN's command-line client is more mature.

CACM has interesting article, News at 11:

September's CACM uncharacteristically contains some interesting content about end-user development (which i consider very important). it details some methods to create end-user programming interfaces that encourage testing, use of assertions, and ease fault localization. i've always found the HCI problems encountered in supporting complex tasks more compelling than the whole which-button-order and where-should-we-put-the-menu sorts of issues (not that they're not important, just that they're boring).

carry on.

BtYacc is the bee's knees! It is yacc but it can backtrack so it can handle conflicts.

this makes writing grammars much happier than using normal yacc: it allows you to write a grammar which more closely mirrors how one might think about the constructs of a language, rather than going through all manner of needless contortions to avoid conflicts. it also allows you to deal with garmmars that are inherently ambiguous.

BUT WAIT THERE'S MORE!

you only incur extra overhead compared to yacc when you actually backtrack.

9 Jul 2004 (updated 9 Jul 2004 at 05:58 UTC) »
on Eiffel

i've been messing with eiffel for the past week or so.

i think i like it, but i'm not sure. it is a substantial improvement over C++, but i'm not sure that's saying much.

getting used to eiffel has proved unsettling. i know a lot of languages coming from various design philosophies, so i didn't expect that i'd find it so jarring. it made me very aware that the languages i use regularly sharing some level of algol blood all look like C to one degree or another (in terms of nomenclature and syntax). perl and python and c++ all look roughly like each other if you squint.

on the other hand you have languages like APL and J which are easy to accept on their own terms because they don't look like much like anything else: you expect they'll be different.

eiffel though occupies a curious position [1]: even though i have experience with pascal and it's ilk, i found myself fighting to write C code (or C++ or python or perl code) in eiffel. i guess i couldn't decide if i wanted to dislike the language because of its resemblance to pascal and it's pedantic attitude ( not quite all the power of C along with lots of padding and helmets and gloves and disclaimers ) or to think of it as a tool providing features which naturally lead to software-engineering best-practices (ie it's not just C for the complete klutz like pascal). i decided to try to adopt the idiom rather than trying to fight it (certainly i would scoff at anyone trying to write C code in lisp).[2]

so i think i like it. especially for writing any code which is complex enough that you would want to sit down and design. [3]

regarding different languages, i like lots of different ones. this is sometimes distressing because i feel i should have a favorite that is 'best' and that i use for everything. but that's dumb. some are useful for different things (matlab v C), and some are useful for the same thing (python vs perl). i think all other things being equal (and i have the choice) sometimes i just want to write something in python or lisp or C depending on my mood or for a change of pace. and i think that's cool

so observations about eiffel

  • arrays starting from 1? dammit i spent 10 years in school to learn how to count from 0 and now you want me to count from 1? (matter of taste, but dijkstra showed that counting from 0 is in general more consistent. also screws with implementing numerical algorithms ; going against common practice increases the possibility for confusion though). (i bet there's some way to change this, since there is no special array syntax)

  • this 
       PROGRAM is do 
    	my_pants
    	hmmm_some_iteration_might_be_nice
    		iterate
    		end --
            huh
            yeah
       end --  program
    
    huh? i thought we all agreed that cobol is silly.

    (NB that code is a parody)

  • one class per file? are you some sort of nazi?
  • pre/post conditions - cool
  • you don't need parens for an empty arg list in a funcall...uhh how am i supposed to know it's a funcall? maybe if i start all the function names with '&'
  • !! is the new 'new' operator? so now you decide cobol *was* silly? also, saying bang-bang is fun.
  • locals declared in separate section? you're not my real father! *run to room slam door* *CRY*
  • 'functionname is do ... end'

    oh so that's where all the extra understood verbs from latin ended up.

  • /= is the new != ? 9 out of 10 cool kids agree: != is !=
  • explicit short-circuit boolean ops ('and then', 'or else') interesting, but a bit chatty.
  • := assignments: it's a pinky workout!
  • the compiler is not the gcc (which we know and love).
  • easy C usage ... cool
  • hmm the docs suck (they aren't organized well)... i guess i need to buy the book.
  • 'inspect foo when... when... else... end '

    ohh someone had their thesaurus handy. (though the switch and case of C never made any particular sense to me)

  • compilation looks at the entire program at once (which can do much better optimization of functions etc) -- yay, no more suffering the run-time inefficiencies of C to make writing code easier.
  • no header files: but how am i going to remember the members of my class if i don't type them out twice?
  • etc...

  1. i remember seeing a well circulated story on research showing that people find it easier to react positively towards visual representations of people if those representations are either completely unlike people or really close to people. however, those visual representations which occupy the middle ground of that continuum are more likely to elicit negative reactions.
  2. even though i still harbor some of the real-men-use-fortran attitude towards pascal, the punks in CS intro class who kept wanting to point out they knew C and complain that this is how things were done in C and why are we learning a useless language like pascal really annoyed the piss out of me: the class was in pascal, get over it.
  3. people calling themselves software engineers should be beaten daily. also i'd love to hear this out of an architect, "i would use it for any bridge that is large enough that you'd actually want to sit down and design it on paper first". i'm not trying to make an analogy or a point about programming (i like to hack and i think its ok though somtimes i miss noticing when a hack is big enough to require some planning and i don't know off hand how to do it). i only want to say 1. software engineers don't take the PE test and 2. taking statements from one context and putting them into another is sometimes funny.

  4. i *heart* run-on sentences.

You owe it to yourself to read these entertaining spams i received a few weeks ago.

for added fun and amusement i suggest doing a google search for this guy's other pages and reading them.

kaeru :

hi, i noticed your article on creating and applying patches. it looks helpful. one issue though: the output you show isn't a unified diff.

the output i get for your example is:

--- db.py       2004-05-20 05:46:43.000000000 -0400
+++ db-mod.py   2004-05-20 05:46:53.000000000 -0400
@@ -1,13 +1,13 @@
-        from pyPgSQL import PgSQL
+       from pyPgSQL import PgSQL
  
         ## note this code is for demo only, don't follow it :)
  
         def initialize():
             try:
                 db = PgSQL.connect (host='localhost',database='test',user='kaeru')
-            except connectionFailed:
-                print "This is a useless exception message and won't help you."-            return db
+                return db
+            except StandardError, detail:
+                print detail
  
         def getPlayers():
             db = initialize()

the unified meaning that both the added and removed sections are shown in the single listing.

unless i'm missing something.

you might consider expanding a bit on the -p option if you have time, since it gets a good amount of use.

thanks for the article; it's always good to have links to give folks on basic skills sorts of things.

elanthis: oh, i think i understand how you mean now. yeah i'd be interested to hear how that would be handled. sounds like funky graph theoretic stuff. maybe by keeping track of depth; it would only be a heuristic though.

107 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!