wysadzenie

Kolega się skarży: wsiadł do autobusa na pętli (+ rower, bo nie chciało mu się na dworzec dymać pedałując w taki żar). Najpierw ustawił się w miejscu na wózek, ale jak pani kierowniczka ruszyła, to postanowił przeleźć na środek, trzymając rower przy sobie, a plecak i torbę z kompuntrem w tych harmoniach gumowych, żeby nie przeszkadzać. Zajęte było 1/4 miejsc siedzących, stojących zero. Minęły trzy przystanki, włazi mama z 500+ w wózku (sama pod 150 kg, ale co koledze do tego), składa parasol nad wózkiem i włazi na właściwe miejsce. Wtedy dopiero zrywa się pani kierowniczka busa, żeby kolega robił wypad, i to dość obcesowo. No to kolega, że napisze reklamację, a pani jakaś z boku "pan się sam reklamuje!". Na pytanie "kto panią pytał o zdanie?" ucichła, choć kolega dla tresury jeszcze kijem przez plery by ją przejechał. Żałuje też, że nie spowodował obstrukcji transportowej pt. "proszę wezwać policję, to wyjdę" - bo podstawy w postaci regulaminu jakoś pani kierowniczka nie była ochocza recytować. Niemniej podjechał dokąd chciał, a że na pętli stał ten sam autobus, to (sprawdziwszy, że okno zamknięte - powodowany wyższym humanitaryzmem), zapodał wprost w kierunku pani kierowniczki flegmę, wzgl. charchę, niestety bez treści z nosa. I skargi ani reklamacji pisać nie musi - jeszcze by się ujawnił. 

Prawu i sprawiedliwości ludowej stało się niniejszym zadość, kolega nawet odetchnął.

Podobno taki jest wewn. przepis kompanii busowej, że dziecki i inwalidy mają pierwszeństwo przed cyklistami. Nie koledze rozsądzać, czy słuszne to czy nie, faktem jest, że kierownice busów mogłyby się w kulturwie osobistej podciągnać. W tym przypadku może jakieś procesy myślowe zostały uruchomione przez obcharchanie jej lewego okienka.

python for dummies

e.g. for me. [tl;dw / ignorant's rant, "Whatever it is, I'm against it"]

    I don't like Python. I don't know it, I fear it, I tried it, I seriously can't stand the amount of hype and naive fanboyism it produces (or gets for free). I'm totally lost in the number of solutions it provides to problems, trivial or otherwise. Recently I made myself watch a video on Python classes (or OOP in Python) and got stuck with the __init__  part, that I would tend to identify with "constructor" but perhaps it's not the pythonic way to call it. The example was an academic one: you have your good old Dog class that keeps the dog's name, age and a void speak() function ("method" is what they call it nowadays, it's a function for me, it does something, may return something, it's not a component or field. Or property, which I don't distinguish from a field, I'm just too ignorant) that prints "Woof!" on the console. Great.

    By the way: it's funny that overriding the virtual speak() implemented in the parent Animal class is done without any extra keywords in the child class. I don't know if it leads to problems and/or ambiguities. I suspect that if I were to code that thing, that would be the case, by Murphy's law. Or perhaps there is automatic overriding and if you want the parent function you use the __super__ thing? Or just define nothing in the child class. I don't know. And I don't need to know. For I decided to avoid classes in Python whenever I use it. (It happens only if the combo of bash, sed and grep results in such utterly unreadable and unmanagable trash, that it's impossible for me to follow, say, after an hour, what was going to happen when the script's supposed job had been done. And after two hours I even forget what the job was; it's more important that it's done and I can proceed further.)

    Anyway, looking at the definition

class Dog:

    def __init__(self, name, age):

        self.name = name

        self.age = age

I asked myself, how the hell The Python Almighty knows the author's intention that name should be a str and age an int. It f....n' doesn't. The author or the user of that class has to take care of this, so it seems. There is some solution for it (or a hundred). This behavior allows of course for great amount of "flexibility", like

dog = Dog("Bernese", 5)

and

otherDog = Dog("Beagle", "four")

which looks weird for someone like me. I'm too simple minded and totally don't get the idea why anyone would actually need different instances of the same class with actually other types of fields/components that have the same names... Division into instance and class variables is something different and I can see some sense here. Like implicit inheriting some global (or external, or static) properties for all the instances. Somewhat similar to what COMMON did for Fortran subroutines.

    The above example may be ok if your only job is printing out the dogs' data, once "Hello world!" is too easy and boring. But what if you want to know the average age of as many dogs as your memory can hold? Well, if you're an OOP maniac, you're perhaps going to wrap an array or list of Dog objects in yet another class and write a function that does the summing (if your average is of arithmetic kind, in the case of geometric or harmonic one, you go to multiplications, divisions, weights turn to powers/exponents etc.) of elements' .ages, casting the result to the float (double?) type, dividing by the list's count (or len), rounding etc. (or calculating roots in the geometric case). And for our Bernese and Beagle, 5 + "four", you're left with an error. Already. Something that in normal C-like languages would not even allow you to compile the damn thing... Of course, if it's user input, you have to check its validity, e.g. if one of your argv[] elements can be turned into an int that the programmer had in mind.

    One of my conclusions is: I don't think that's the way you should teach about objects. I think classes are there to make my life easier. They do, but in Python it's just a retreat to something more difficult. With no

    I read one post (and answers) on SO related to the above problem. It was fun to read, especially people quoting their Language Gurus Who Once Said Something Very Significant About Zen, Simplicity, being Explicit etc. There were some sane and critical posts, pointing out mistakes and misunderstandings which were rather obvious afterwards. But the context of hype and all the fanboys being so eager and enthusiastic... it only added to the fun of it all. It's a bitter kind of fun. I'm happy to read C++/C# or Java related stuff (I don't know Java, but I can more or less follow what's happening), it's just so much more mature.

    Almost everyone and their dog is excited by Python. Just as everyone can be fascinated by the number pi, and some of the weaker minds will burn out trying to "prove" it's rational. Just as some weaker minds in physics (especially retired engineers, turned crackpots) tend to work on cosmology of their own, relativity (or fight and "abolish" relativity fiercely, in favor of "neo-Newtonian" approach or name calling Einstein based on, say, national and/or religious "arguments"...) Others are in neverending search for some new realization of a perpetuum mobile etc. Ok, what can I do about it? Nothing...

    I don't think of Python as giving me freedom in the example above. Lack of type constraints built in in the object's contstructor seems to me like allowing someone to drive their train without the need to set the tracks before. Which is ok if you like to run into cars, cattle, people, buildings etc., and the cars, cattle, people and buildings don't mind being hit by your train. Perhaps you're so fast they don't have time to complain? (The fact that I don't think everyone deserves and is able to acknowledge freedom has nothing to do with that.) In my stiff- and narrow-minded view, Python is too much anarchy in the place where I expect order and rules. Not just for the sake of imposing these on others, but to actually make things easier... It reminds me of an old Soviet joke about their political youth organization, the Komsomol (Kom = Kommunisticheskiy, So  = Soyuz, Mol = Molodezhi, The Communist Youth League, approx.). So, it's Soviet Union, a very hot summer, and some guy is mowing a lawn in a gas mask, using scissors. A girl passing by stops and says, "Why do you work in a mask, why don't you use some machine?" "Well, I'm a member of Komsomol, I can't work without extra difficulty!" "Well, when you're finished, how about us two have some sex?" "Ok, but only in my hammock!". [Round of applause for Fozzie Bear...]

    Well, in normal circumstances, I'd probably either inherit from Dog and create separate DogWithNumericAge and DogWithStringAge or so; or use object as a more universal type, and then cast the constructor's input to specific types later; or make a template, Dog<T> and have the age component be of type T. If I need that, I'd have to create that distinction, and in no way would the "wrong" Dog instance get into my (numerical) averaging function... It seems to me that in Python someone chose the object variant for me and requires me to workaround its dangers or ambiguities somehow, back to the state that I treat as the most basic.

    Can you master Python? If you're young, of course. Especially if you're ok with the hype and following the herd. Warning: "we have to eat crap, billions of flies can't be wrong". Can I master Python? No, probably not. I don't think I ever need it. I hope not to need it. For I see no reason to make it so hard, in such a weird way, at such low a level. And I can't imagine (yet) anything I need done that I can't do using C#. I can't say this about C++, but I will do my best to learn the newer version than the stuff I was "taught" at the university in 1998/9.

    Summing up, long story boring... To me Python is a painful joke, full of strange and unexpected traps, totally weird syntax etc., larger scripts are very hard to debug since you see the syntax errors one per run, if you don't use an IDE. My first approach was to write the Snake game, I made it and then stopped at the problem of listening to keyboard events which just didn't work, for some reason. So, the effect was more like poor man's Snake ("Snake in your pocket", that's how being stingy, not poor, is described in Polish), that would have moved only when the player actually pressed one of the arrow keys.

    It will always be my guilty pleasure to code this or that in Python, just to take a beating. And if I don't get that, I'll redefine the term just to find some, and complain afterwards. And getting beat up is a very important part of life. Take climbing, running or cycling: you get extremely tired. Especially when cycling in Italy, when you're tired not only because the road is steep (cycling in the Alps is my hobby anyway), but because its pavement is so f****g shattered, full of cracks, potholes etc. If you don't believe me and you're into cycling, go to Valle Varaita and have some fun up Colle d'Agnello. Especially from Chianale; it's only about 900 m, but it's super tough if you do it in one push; and the scenery is just breathtaking... Similarly on the French side, but the ascent there is a bit longer (1300+ m) and easier, but it's still very difficult. (Yes, Stelvio is so overrated...) Then go down the road to Piasco (it's where the Alps are just hills and you can see some flat terrain) and perhaps take the most straight route to... Iseo. No, actually don't do that, it's dangerous, especially at night. Hitting a really nasty pothole and having to change two tires that got four punctures each, and it's 2:00am and plenty of mosquitos... it was sick. "What does not kill you, makes you stronger". So, perhaps I won't get suffocated by that bad reptile. But I hope to remain as hateful about it as possible. And write as C-looking code as possible, so as to be able to understand it myself afterwards and annoy others. On the other hand, I doubt they will ever look at it.

struggles with Inkscape's pdflatex extension, II

or the nightmare of pdflatex.py.

<smartass mode="on"> --- I added the time.sleep(50) lines in suitable places in the extension's code, so as to check if the temporary files (latex, pdf, svg) are correct. They are perfect, as expected. Which proves that something goes really wrong when the plugin starts including the temporary svg to the svg that is being edited. The rule seems to be: the more formulas you already have in your svg, the bigger the probability that you get junk when trying to include a new one.

Meanwhile I discovered how big those test files have grown, about 2.5MB; doing nothing smarter than Ctrl-A + Ctrl-C and then pasting to a new file, reduced the size to about 300kB. I also tried pressing "Clean Up Document" which perhaps removes some junk parts/tags from the svg. But the problem with pdflatex still occurs, in fact it becomes unusable and frustrating. ("I'm going to stand here and fix this damn thing every time it jams..." --- RMS!)

So I switched to my older machine which runs inkscape version 0.92, and it's just perfect. I found the extension's code; the way it's done looks different, even the good old dvips is in use there, and some other mechanism for including the newly created svg to the edited one. Perhaps it's worth to combine the two approaches to get something that works ok (not only with new/empty svg). By the way --- importing pdf via File -> Import works fine. I have no idea what happens in pdflatex.py from v. 1.1 --- those set_random_id etc. Looks like some reptilian piece of fxxxxn' witchcraft.

struggles with Inkscape's pdflatex extension

[No, still not working]

I was having problems with wrong formulas generated by pdflatex plugin or extension in inkscape. As long as it was sufficient to click "Apply" a few times to get it right, then remove the wrong versions and proceed—I was almost ok with that. But yesterday's session with Maxwell's equations, resulting in the following picture (I changed the input in the plugin's textbox exactly three times, I mean: I'm not joking)

(The red stuff is supposed to be correct, but the Gauss' law is not—shit, \times instead of nothing or \cdot, yeah, it was late, I was getting mad etc.)—all that made me contact people at Inkscape. Someone called Mc (thanks!) told me to get some insight to temporary files of the pdflatex extension that is located at </usr/share/inkscape/extensions/pdflatex.py>, written apparently by a French-speaking person ;) Looking at the temp files wasn't the option since the proposed version (override?) of some (inherited?) cleanup function,

def clean_up(self):

    pass

didn't force the plugin to keep all its files in /tmp. Some mysterious message about implicit cleanup popped up, so I gave up, not wanting to mess with Python, which I hate.

Meanwhile I produced a .tex file with about ten repetitions of the same line with one formula, and tried importing the pdf file (that pdflatex had made) to inkscape. The import with poppler/cairo worked perfect, the internal one resulted in (repeatable) rubbish.

I though a bit about the possible causes and—not finding any, except for somewhat absurd suspicions that something is really wrong with the way in which tmp files are being handled here—I came up with a temporary idea: why not clean the temporary LaTeX file, just in case, every time it's opened? I looked up the possible commands on SO, and this worked like miracle. No matter how many times I press "Apply", the formula is correct, with no changes...

def write_latex(self, stream):

    stream.seek(0)
    stream.truncate(0)
    """Takes a forumle and wraps it in latex"""
    stream.write(r"""%% processed with pdflatex.py

I still don't know why that thing failed before, I don't know whether the two lines above fix that bevavior for good. It works for me, if you have problems like these, just give it a try.

"Never did so many understood so little about so much".

 

Another way to "solve" the problem seems to be: add stream.flush() at the end of the write_latex function. I don't know if it does the same job, but the output is just ok.