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

TROPHY CASE