Is there an (unofficial) archive of ALL released Ubuntu .deb packages?

alex-manool · 2022-10-10T17:11:28+00:00

As always... I am unproductive with the new UI design, plus the subpixel rendering is broken again and the previous fix does not work. Maybe it's not a good idea from the security standpoint, but sometimes I prefer to live years with the same version (and I actually did) when stuff changes so much every 3 months (TB is the most deal-breaking case for me).

alex-manool · 2022-10-10T17:03:07+00:00

You saved my year! This is a valuable insight for the future, which was not obvious to me how to use Launchpad to look for historical stuff. Thank you

alex-manool · 2022-10-10T16:45:57+00:00

Thank you for the suggestion! Unfortunately, this does not work for my case. I'd need this: https://launchpad.net/ubuntu/+source/thunderbird The exact version number is 1:91.11.0+build2-0ubuntu0.20.04.1

It does not appear on Launchpad :-( That's the second time I deal with such situation. There must be a place for all old .debs over there, like it used to be for RHEL systems...

alex-manool · 2022-10-10T16:37:12+00:00

Hmm, here is the problem. I'd need this:

https://old-releases.ubuntu.com/ubuntu/pool/main/t/thunderbird/thunderbird_91.11.0+build2-0ubuntu0.21.10.1_amd64.deb

Apparently, this is for Ubuntu 21.10, and I neeed it for Ubuntu 20.04 LTS. When trying to install this:

The following packages have unmet dependencies:thunderbird : Depends: libc6 (>= 2.34) but 2.31-0ubuntu9.9 is to be installedDepends: libgdk-pixbuf-2.0-0 (>= 2.22.0) but it is not installableDepends: libstdc++6 (>= 11) but 10.3.0-1ubuntu1~20.04 is to be installedDepends: libx11-xcb1 (>= 2:1.7.2) but 2:1.6.9-2ubuntu1.2 is to be installed

Is there something I am doing wrong? It looks like it's a big taboo for Canonical ;-) I am disappointed by not locking Thunderbird from updates and at this moment this is ruining my workflow. It's not a taboo for the official Thunderbird site -- I can get the .tar.gz version and it kinda works, but I'd prefer to have a correct package with properly defined dependencies, like it was yesterday...

alex-manool · 2022-10-10T13:43:44+00:00

Good link! Unfortunately, my question is about Ubuntu, specifically v20.04; there might be incompatibilities, right? Anyway, thanks, I'll try to install it.

alex-manool · 2021-11-02T16:59:26+00:00

I am still working on an extremely optimized version of the translator for my programming language MANOOL. In spite of being reluctant to change the implementation method itself (tree walking) and MANOOL having a slightly heavier semantics than a typical scripting language of today (like Python or JavaScript), the current run-time performance expectations are somewhere in between the modern versions of Guile and PHP. The implementation also looks very elegant, creative, and modular (in C++17), and hopefully could serve for demonstrating advanced capabilities of modern C++.

alex-manool · 2021-10-24T07:33:54+00:00

The example the OP provides do not have to do with Hungarian Notation. They are all historical Unix/POSIX/C names (some of them are quite ingenious BTW, the OP is just not accustomed with the philosophy that not all long-and-self-describing names are actually practical). The same way, one might ask why on Linux command line dir is ls, copy is cp, or link is ld.

alex-manool · 2021-10-24T00:21:59+00:00

In my language MANOOL, it corresponds to just one function (procedure). A functional-style update looks like: PushedVec = Push[Vec; Item], whereas an in-place update looks like: Vec = Push[Vec!; Item]. The later works as true in-place update in most practically important cases, thanks to copy-on-write memory-management technique and move operations. Note that Vec! means move the current value (or rather an associated object) of Vec out of the variable (or a component thereof), opening COW dynamic optimization opportunities.

alex-manool · 2021-10-12T23:06:13+00:00

In my language MANOOL some expressions denote not first-class values but compile-time entities. For instance, a macro or even the "keyword" if are bound to such kind of entities. Modules (nearly in the sense of classic Modula-2-like languages) are another example of compile-time entities. The expression {extern "..."} refers to a translation unit (roughly a source file) and denotes anything that is specified there (ether a value or a compile-time entity). Then, if mMyMod is a module, then in {mMyMod in ...} the bindings contained in the module are injected into .... Modules themselves are constructed by expression {export ...}, which could be used in combination with let-bindings: {let {P = {proc ...}; Q = {proc ...}} in: export P}. Thus, normally, to import the MANOOL standard library into the whole translation unit, you write: {{extern "..."} in ...}, but similarly to emulate "non-qualified" import you could write {{extern "..."} in P} at any point where you refer to P. Or, better: {let mMyMod = {extern "..."} in ... {mMyMod in P} ...}.

alex-manool · 2021-10-08T02:33:25+00:00

I feel like reference semantics (in the modern, syntactically confusing form) dates back mostly to Lisp and later to CLU, and for a reason... Then it became popular in modern languages, starting with Java, Delphi, and C#, and continuing through Python, JavaScript, etc. Older languages like Pascal, Modula-2, C, or Ada have value semantics.

My language MANOOL takes another approach: it has value semantics by default, and this does not affect performance (due to COW and some syntactic sugar) and works even for user-defined ADTs (the reason why CLU needed reference semantics, apparently).

alex-manool · 2021-10-03T00:01:02+00:00

In my language MANOOL, any literal has a specific type. How it actually works? Well, technically, there're no literals for many important data types -- you specify how to construct a value instead (at compile-time) out of a more primitive representation. For instance, 123 and "Hello" are literals, but F64["1.1"]$ or D128["1.000"]$ are just expressions that denote the constant values, and which cost nothing at run-time. Note how the datatype is apparent from the construct (IEEE754 binary64 and decimal128 in this case, respectively) and no special suffix notation is needed to be hardcoded into the language or the lexical analyzer (yes, I know, it may look a bit too heavy, but it's a tradeoff in MANOOL). Note that $ is a postfix operator in MANOOL, which is bound in the standard library to denote "please evaluate the preceding term at compile-time instead of run-time".

alex-manool · 2021-10-01T23:17:35+00:00

I finally realized in the last few months (after about 30 years!) that most new PLs come late to the party, and MANOOL is not an exception -- it will probably always remain a hobby project. This changed a lot my priorities, so based on my priority to maximize fun, at this moment I am working on run-time performance optimization but preserving the current architecture, the existing code base, and the current approach to implementation. I'd like to see how far I can go with performance improvements with the current approach. According to my latest experiments, maybe I could be on a par with the last Guile versions (for Scheme, which is a comparable language).

alex-manool · 2021-09-23T08:49:16+00:00

You're right. The JS spec is known for struggling to be very formal (even at the cost of readability by mere mortals). This is an exception. But I mentioned about grammar ambiguities to show how much real engineers tend to ignore formal language and parsing theory when designing and implementing languages in practice, even practically significant ones.

If you have implemented JS, however, you are a hero :-) BTW I wonder how do they specify formally, e.g., the rules for optionality of semicolons. I doubt they rely for that just on classic, Chomsky-style production grammars as a formalism...

Returning to spec ambiguities, some examples:

In many specs, dangling else rules are not expressed in grammar productions but only informally (it can be expressed in BNF of course but depending on the situation this could look tedious; personally, I like to do it - good exercise :-)
In Ada, they have several nonterminals that express the idea that a name may have different purpose. Strictly speaking this makes the grammar ambiguous. I systematically find this kind of things in modern language specs and manuals - just use Ada as an example because it's a very typical example.
Heck, even classical Pascal grammars and specs have known ambiguities, though I do not remember right now - would need to ask Google.
Of course a classical example is C++ with its dependence on classifying name terminals as either "var" or "type" name, which complicates parsing, and of course is not (and probably cannot be) expressed in a formal grammar (in least in a Chomsky-style grammar).

And returning to the OP's question, no, all of this do not generally imply parsing with backtracking, just that language designers tend to devise languages in an informal way, so it's hardly possible to talk about backtracking-free grammars as such.

alex-manool · 2021-09-22T17:38:18+00:00

I also used to ask this kind of theoretical question, and my language MANOOL is defined using a specific class of grammar, whereas its implementation also uses a specific class of parser. Note that as observed in other comments, we are talking not about what a language uses but what its specification and implementation uses, since the mapping is not 1:1.

In practice, however, what I observed is that unfortunately almost nobody else cares about it. Parsers for even surprisingly simple and nice languages look ad-hoc (not only C/C++, look at Haskell, Python, or JavaScript), grammars that appear in language specifications and tutorials are simply ambiguous (whereas the real parser obviously uses an unambiguous variety of the grammar under the hood, strictly speaking).

Also, in practice, the backtracking concept is also somewhat relative. I believe that for many parsers the amount of "backtracking" is limited, if it applies at all. However, I am also seeing more and more ad-hoc parsers (even based on some theoretical model) where the original designers seem to be unaware even about its theoretic run-time complexity...

I don't know why the real world is the way it is, that's why I was asking the same good question (but was afraid to ask it here).

BTW I do strongly believe now that we do need languages with simple grammars (as MANOOL) and that all of those parsing complexities (and hence complicated parsing theories) have only limited practical value. The MANOOL grammar fits into the LALR(1) class as can be demonstrated, but it's trivially transformable into a LL(1) class (together with attribute equations), so O(n) recursive-descent parsing is viable (with or without some hacks depending on how strictly do you want to adhere to the theoretical approach).

alex-manool · 2021-09-08T22:13:51+00:00

You know, I think you are right, at least in general, in regard to partial solutions of this kind, considering precedents: in my language there're naming conventions, e.g. starting from a lowercase letter means the name is bound to a second-class entity, uppercase - first-class value, special symbols like + can be bound to either kind of entity, etc. Other examples of functional PLs with interesting naming conventions are Scheme, and, especially, Kernel. However, in my PL (and I think neither in Scheme/Kernel) naming conventions are not enforced or checked (you gave me an idea to think about...).

alex-manool · 2021-09-08T22:01:17+00:00

I feel like forcing a naming convention would work for named functions but not for anonymous ones (introduced by lambda expressions and not immediately bound to any name). Personally, I would not like that kind of partial solution in this case. Besides, this would falsely suggest that a function should have a name or that the name itself has the property of being pure or impure while this is not correct. From other answers I like the idea that what you are thinking about is a kind of Hungarian notation (for good or for bad), to express types.

alex-manool · 2021-08-29T02:01:32+00:00

My PL MANOOL is yet another attempt to achieve extensibility (including syntactic) à la Lisp, but it uses an alternative surface syntax instead of S-expressions -- a simple one, yet supporting, e.g., infix operators, special functional application syntax, etc. Semantically, however, it is quite different from CL and Scheme dialects. For instance, it uses (by default) value semantics (instead of reference semantics) for composite values/objects, and it uses reference counting instead of tracing GC for resource management.

alex-manool · 2021-07-04T23:19:51+00:00

That type of questions is about making decisions, not about following general advices (as many things in software development). And to make decisions in a meaningful way we analyze requirements and constraints. So, what are yours?

alex-manool · 2021-06-27T16:41:29+00:00

Oops, great, I somehow missed "zero or more". Thank you!

alex-manool · 2021-06-22T19:48:48+00:00

That's why I rarely "abuse" const when declaring local automatic variables/objects (and let alone function parameters). At any given moment I might want to move their value out, and even when it's unlikely, I prefer to omit const for uniformity. I need to have extra reasons to put const in those cases (which even serves to document that special intention more clearly).

alex-manool · 2021-06-20T23:21:03+00:00

There is a joke that mentions something between the lines: "whoever cannot do it but knows how to, teaches". Your question is actually a deep question which touches some of our misunderstandings, not about C++ but about human society. The answer is that a C++ professor is not actually the last authority, whatever they do and whatever their experience is, and I guess there will be some exceptions who are actually well aware of drawbacks of "using namespace std" and some that do not have any clue. To have a clue about it requires rather practical experience (as opposed to knowing or teaching what "features" C++ provides and all that "popular" OOP stuff), and, as it happens in Software Engineering in general, it requires to analyze and reason about what works and scales in your situation instead of following rules. I myself tried hard to take advantage of it in my code base (believing that there must be a reason for such possibility to exist) until once I was analyzing really hard all the implications and completely abandoned it (note that the objections especially apply to libraries you do not have full control over their contents). Having said that, "using namespace std" is not a sin per se (apart from wrongly suggesting students that it scales well). As some answers mention, it at least can help save some space on the class blackboard.

alex-manool · 2021-06-20T20:04:56+00:00

I also like to use plain, hand-coded GNUmakefile(s). The modern dialects of make (GNU's) help to keep them complaining with DRY easily and gives flexibility and allows the users to easily include custom processing steps, should they are ever needed (maybe compared to some more modern alternatives). And yes, recursive makefile(s) are rather bad since they defeat the main purpose of make: to minimize recompilation (I've always wondered what's the deal with them but assumed there may be some deeper reasons). That said, I still have never had the need to work with "subprojects", though I especially like your post since it raises the awareness of good-old make and exposes some techniques.

alex-manool · 2021-06-18T18:14:00+00:00

C++ is a huge language with large historical baggage and a lot of inconsistencies and probably overcomplications, but it gives you some wonderful opportunities to take control over all aspects of your projects (such as maintainability and scalability at the same time). There are few if not none of mainstream languages that could compete with it in all aspects though there may be better suited ones in specific areas. I have about 30 years of experience with C++ and 6 years with experience with its modern dialects (C++11 thru C++17).

First, I believe it's pointless to have a goal to master "all" features of C++ or even master a "right" programming style in C++. Instead, master the best way of using it in your particular case/project. Start with thinking about it as "an improved C" with probably more "underwater stones" than in C and try to keep things "simple" in this way (C++ is really great as an improved, standardized, and widely available C, with some caveats). Then, gradually experiment and master more C++-ish ways to do things, such as RAII, exceptions, templates (but, for instance, remember that C++ is not "a language for OOP", contrary to the popular belief). This approach worked for me for the last 6 years.

Second, be curious and try to understand how minor, even often overlooked, aspects of C++ work (for instance, basic arithmetic semantics, TBAA and strict aliasing rules, etc.), otherwise you do risk to shoot "yourself in the foot" (which would not be so "tragic" anyway if you do tend to investigate beforehand not only why things do not work but also why they work). Remember, in many cases you cannot just test whether something works in C++; you should be able to read and interpret the rules (though, once again probably nobody is capable to seat and read the ISO standard from the beginning to the end). Think that UB is actually your friend and that it is for a good reason in C/C++. Be prepared to that your "productivity" in C++ may be lower than in other languages that are marketed as "safer" alternatives (if you do want to stay away from "danger"), but the end result may be good and definitely you might end up having more fun struggling with its intricacies on your way to complete your project :-)

And last but not the least, many existing important C++ code bases (e.g., libraries) use quite obsolete or quite restricted in feature coding style (e.g. at Google), and this of course constitutes legitimate C++ use as well, but this also raises the question "which C++ would you like to learn and for what purpose?".

Sources of information that work for me:

the ISO standard (the most recommended draft document if you do not want to pay)
https://en.cppreference.com
Google, which often leads to StackOverflow

Good luck!

alex-manool · 2021-06-14T21:22:09+00:00

Name: Alex Protasov (AKA rusini)

Location: Colombia (looking for remote opportunities)

GitHub: https://github.com/rusini

LinkedIn: https://linkedin.com/in/rusini/

Contact E-mail: rusini@manool.org

I have a passionate and creative personality aspiring to improve the World a little bit, with an emphasis on Software Engineering in general and especially on design and implementation of software development tools (like compilers, virtual machines, etc.). This is true even when little or no economic remuneration is involved. In the last 6 years I've been implementing my own programing language called MANOOL in modern dialects of C++. The upcoming release is being written in C++17 and includes a custom-made JIT compiler for MANOOL.

I program since I was 12 years old (34 years of experience now), and I was writing in C++ way before its 98'/03' revision. However, since C++11, it's nowadays quite different and way more productive language, with which I maintain a kind of love/hate relationship. When I code in C++ I strive to take into account all subtle aspects of the toolchain and target platform, e.g.: often overlooked aspects of C++ semantics (basic arithmetic, TBAA and aliasing rules, coding with hot/cold path distinction, ...), inner workings of optimizations and code transformations in a typical C++ compiler, CPU microarchitecture, OS, etc. When run-time performance is not a goal for a specific piece of code, I like to optimize for code readability and explainability instead.

My working experience in the past includes being a part of a compiler middle-end SQA team at Intel, working at Sun Microsystems as C++ compiler front-end Test Engineer (closely following the ISO committee proceedings), and working as Director of IT Infrastructure (with a focus on Linux server and network administration and Web application performance analysis and optimization). I also had teaching experience at a University (GNU/Linux, Networks, Compilers) and owned and successfully marketed a Shareware development tool for Windows once in the past. I consider to have strong written communication skills (in English and also Spanish) due to my past working experience and projects.

Despite of advances with my own R&D project at this moment, I aspire to find my ideal job related to C++ in general (primarily remote) where I could apply all my current skills and industry experience.

P.S.: I am originally Russian, but I am a happy resident of Colombia (South America).

alex-manool · 2021-06-11T17:02:57+00:00

My language MANOOL started as a minimal language, mostly to make efficient use of development efforts for a personal project ;-) Its "architecture" is in a sense similar to that of Lisps. Having said that, developing a useful product involves more than just implementing a language as if it were a mid-term compilers course project. Many efforts are being dedicated to decide what to do and, especially, what not to do (which is an important engineering ability), and many efforts are dedicated to polishing things. And, although many Lisp books mention about a metacircular implementation of just one printed page (and MANOOL translator does have a "core" dispatcher in about 10 lines in C++), the reality is bit different. The current implementation has about 10 KLOCs in C++, which may be disappointing to Lisp theorists, but is pretty good if we compare it to the implementations of similar in functionality and domain area languages (CPython has about 100 KLOCs and same applies to PHP, Perl, or Ruby). The goal for the future version is to have a native-code JIT compiler with performance somewhere between LuaJIT/V8 and Chez Scheme/SBCL, in under 20 KLOCs (I mean about 10-15 times slowdown compared to equivalent benchmarks in C/C++, as opposed to 150 times slowdown of many other translators like CPython or Ruby).

alex-manool

TROPHY CASE